Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol

2018-03-21 Thread Sven Dueking 


> -Ursprüngliche Nachricht-
> Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von
> Diego Biurrun
> Gesendet: Mittwoch, 21. März 2018 15:54
> An: libav development
> Betreff: Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol
> 
> On Wed, Mar 21, 2018 at 03:00:37PM +0100, Luca Barbato wrote:
> > On 21/03/2018 11:46, Diego Biurrun wrote:
> > > What is it? libsrt or opensrt?
> >
> > You have an opensource implementation of the protocol SRT.
> >
> > I prefer to call it libsrt as configure option.
> >
> > > Where does the opensrt name come from?
> >
> > The protocol is srt (secure reliable transport), the support for it
> > uses an external opensource implementation, as mentioned in many
> places.
> >
> > I edited opensrt to libsrt for the configuration option since it fits
> > the normal pattern better. Probably to be consistent renaming all the
> > other occurrences of opensrt to libsrt would be an option.
> 
> I don't see the opensrt name appearing anywhere. Plain srt should be
> the name for an internal implementation, for external-library-backed
> ones a lib prefix to the name of the protocol is appropriate.
> 
> Diego

Haivison calls the packet OpenSRT and I think that´s a good idea to avoid any 
conflicts with SRT (subtitle). 

> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol

2018-03-21 Thread Diego Biurrun 
On Wed, Mar 21, 2018 at 03:00:37PM +0100, Luca Barbato wrote:
> On 21/03/2018 11:46, Diego Biurrun wrote:
> > What is it? libsrt or opensrt?
> 
> You have an opensource implementation of the protocol SRT.
> 
> I prefer to call it libsrt as configure option.
> 
> > Where does the opensrt name come from?
> 
> The protocol is srt (secure reliable transport), the support for it uses an
> external opensource implementation, as mentioned in many places.
> 
> I edited opensrt to libsrt for the configuration option since it fits the
> normal pattern better. Probably to be consistent renaming all the other
> occurrences of opensrt to libsrt would be an option.

I don't see the opensrt name appearing anywhere. Plain srt should be the
name for an internal implementation, for external-library-backed ones a
lib prefix to the name of the protocol is appropriate.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol

2018-03-21 Thread Luca Barbato 

On 21/03/2018 11:46, Diego Biurrun wrote:

On Wed, Mar 21, 2018 at 08:41:30AM +0100, Luca Barbato wrote:

From: Sven Dueking 

protocol requires libsrt (https://github.com/Haivision/srt) to be
installed

Signed-off-by: Sven Dueking 
Signed-off-by: Luca Barbato 
---

Here the patch with all the changes folded in, I'll push it tonight if
nobody has further comments.


Did the new formats checklist get out of fashion lately?

https://www.libav.org/documentation/developer.html#New-codecs-or-formats-checklist


It isn't a format or a codec.


What is it? libsrt or opensrt?


You have an opensource implementation of the protocol SRT.

I prefer to call it libsrt as configure option.


Do you have to escape '&'? I don't remember offhand.


IIRC @ is the only symbol that needs escaping in texinfo.


Where does the opensrt name come from?


The protocol is srt (secure reliable transport), the support for it uses 
an external opensource implementation, as mentioned in many places.


I edited opensrt to libsrt for the configuration option since it fits 
the normal pattern better. Probably to be consistent renaming all the 
other occurrences of opensrt to libsrt would be an option.


Sven what sounds better for you?

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] lavu/hwcontext_qsv: Add support for pix_fmt RGB32.

2018-03-21 Thread Maxym Dmytrychenko 
Clean and specific patch is always good, agree with you on removal here.

On Tue, Mar 20, 2018 at 9:18 AM, Li, Zhong  wrote:

> > From: libav-devel [mailto:libav-devel-boun...@libav.org] On Behalf Of
> > Maxym Dmytrychenko
> > Sent: Monday, March 19, 2018 5:56 PM
> > To: libav development 
> > Cc: Liu, ChaoX A 
> > Subject: Re: [libav-devel] [PATCH 2/2] lavu/hwcontext_qsv: Add support
> for
> > pix_fmt RGB32.
> >
> > indentation can be adjusted ,
>
> It is to support RGB format overlay (e.g. lena-rgba.png).
>
> > AV_PIX_FMT_YUYV422  - we add it but dont use?
>
> If the overlay input movie format is 4:2:2, it will be used. But I prefer
> to remove it in this patch to make it clearer.
> How do you think?
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Add Haivision Open SRT protocol

2018-03-21 Thread Diego Biurrun 
On Wed, Mar 21, 2018 at 08:41:30AM +0100, Luca Barbato wrote:
> From: Sven Dueking 
> 
> protocol requires libsrt (https://github.com/Haivision/srt) to be
> installed
> 
> Signed-off-by: Sven Dueking 
> Signed-off-by: Luca Barbato 
> ---
> 
> Here the patch with all the changes folded in, I'll push it tonight if
> nobody has further comments.

Did the new formats checklist get out of fashion lately?

https://www.libav.org/documentation/developer.html#New-codecs-or-formats-checklist

> --- a/configure
> +++ b/configure
> @@ -1371,6 +1372,7 @@ EXTERNAL_LIBRARY_LIST="
>  libspeex
> +libsrt
>  libtheora
> @@ -2522,6 +2524,8 @@ librtmpt_protocol_deps="librtmp"
>  mmst_protocol_select="network"
> +opensrt_protocol_select="network"
> +opensrt_protocol_deps="libsrt"
>  rtmp_protocol_conflict="librtmp_protocol"

What is it? libsrt or opensrt?

> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -655,6 +655,145 @@ To play back the first stream announced on one the 
> default IPv6 SAP multicast ad
>  avplay sap://[ff0e::2:7ffe]
>  @end example
> 
> +@section srt
> +
> +Haivision Secure Reliable Transport Protocol via libsrt.
> +
> +The supported syntax for a SRT url is:

URL

> +@example
> +srt://@var{hostname}:@var{port}[?@var{options}]
> +@end example
> +
> +@var{options} contains a list of &-separated options of the form

Do you have to escape '&'? I don't remember offhand.

> +
> +or
> +
> +@example
> +@var{options} srt://@var{hostname}:@var{port}
> +@end example
> +
> +@var{options} contains a list of '-@var{key} @var{val}'
> +options.
> +
> +This protocol accepts the following options.
> +
> +@table @option
> +@item connect_timeout
> +Connection timeout. SRT cannot connect for RTT > 1500 msec

Connection timeout;

> +@item fc=@var{bytes}
> +Flight Flag Size (Window Size), in bytes. FC is actually an

ffs? loool ;)

> +internal parameter and you should set it to not less than
> +@option{recv_buffer_size} and @option{mss}. The default value
> +is relatively large, therefore unless you set a very large receiver buffer,
> +you do not need to change this option. Default value is 25600.

This sounds like it should not be a user-tunable parameter, but that
the implementation should take care of it instead. Oh well ..

> +@item inputbw=@var{bytes/seconds}
> +Sender nominal input rate, in bytes per seconds. Used along with
> +@option{oheadbw}, when @option{maxbw} is set to relative (0), to
> +calculate maximum sending rate when recovery packets are sent
> +along with main media stream:

with the

> +@option{inputbw} * (100 + @option{oheadbw}) / 100
> +if @option{inputbw} is not set while @option{maxbw} is set to
> +relative (0), the actual ctual input rate is evaluated inside

ctual?

> +@item maxbw=@var{bytes/seconds}
> +Maximum sending bandwidth, in bytes per seconds.
> +-1 infinite (CSRTCC limit is 30mbps)
> +0 relative to input rate (see @option{inputbw})
> +>0 absolute limit value
> +Default value is 0 (relative)
> +
> +@item mode=@var{caller|listener|rendezvous}
> +Connection mode.
> +caller opens client connection.
> +listener starts server to listen for incoming connections.
> +rendezvous use Rendez-Vous connection mode.

The values should have @option markup.

> +Default valus is caller.

s/valus/value/

> +@item mss=@var{bytes}
> +Maximum Segment Size, in bytes. Used for buffer allocation
> +and rate calculation using packet counter assuming fully

a packet counter

> +filled packets. The smallest MSS between the peers is
> +used. This is 1500 by default in the overall internet.
> +This is the maximum size of the UDP packet and can be
> +only decreased, unless you have some unusual dedicated
> +network settings. Default value is 1500.
> +
> +@item nakreport=@var{1|0}
> +If set to 1, Receiver will send `UMSG_LOSSREPORT` messages
> +periodically until the lost packet is retransmitted or

s/the/a/ I assume

> +
> +@item oheadbw=@var{percents}
> +Recovery bandwidth overhead above input rate, in percents.
> +See @option{inputbw}. Default value is 25%.
> +
> +@item passphrase=@var{string}
> +HaiCrypt Encryption/Decryption Passphrase string, length
> +from 10 to 79 characters. The passphrase is the shared
> +secret between the sender and the receiver. It is used
> +to generate the Key Encrypting Key using PBKDF2
> +(Password-Based Key Deriviation Function). It is used

Deriv_ation

> +only if @option{pbkeylen} is non-zero. It is used on
> +the receiver only if the received data is encrypted.
> +The configured passphrase cannot be get back (write-only).

s/get back/recovered/

> +@item recv_buffer_size=@var{bytes}
> +Set receive buffer size, expressed bytes.
> +
> +@item send_buffer_size=@var{bytes}
> +Set send buffer size, expressed bytes.

expressed in

> +@item rw_timeout
> +Set raise error timeout.

rw?

> +This option is only relevant in read mode:
> +if no data arrived in more than this time
> +interval, raise error.
> +
>

[libav-devel] [PATCH] Add Haivision Open SRT protocol

2018-03-21 Thread Luca Barbato 
From: Sven Dueking 

protocol requires libsrt (https://github.com/Haivision/srt) to be
installed

Signed-off-by: Sven Dueking 
Signed-off-by: Luca Barbato 
---

Here the patch with all the changes folded in, I'll push it tonight if
nobody has further comments.

 configure   |   5 +
 doc/protocols.texi  | 139 
 libavformat/Makefile|   1 +
 libavformat/opensrt.c   | 575 
 libavformat/protocols.c |   1 +
 5 files changed, 721 insertions(+)
 create mode 100644 libavformat/opensrt.c

diff --git a/configure b/configure
index 95e6006440..c966cd2572 100755
--- a/configure
+++ b/configure
@@ -229,6 +229,7 @@ External library support:
   --enable-libxcb-xfixes X11 mouse rendering [auto]
   --enable-libxvid   MPEG-4 ASP video encoding
   --enable-openssl   crypto
+  --enable-libsrtenable Haivision Open SRT protocol [no]
   --enable-zlib  compression [autodetect]

   The following libraries provide various hardware acceleration features:
@@ -1371,6 +1372,7 @@ EXTERNAL_LIBRARY_LIST="
 libschroedinger
 libsnappy
 libspeex
+libsrt
 libtheora
 libtwolame
 libvorbis
@@ -2522,6 +2524,8 @@ librtmpt_protocol_deps="librtmp"
 librtmpte_protocol_deps="librtmp"
 mmsh_protocol_select="http_protocol"
 mmst_protocol_select="network"
+opensrt_protocol_select="network"
+opensrt_protocol_deps="libsrt"
 rtmp_protocol_conflict="librtmp_protocol"
 rtmp_protocol_select="tcp_protocol"
 rtmp_protocol_suggest="zlib"
@@ -4668,6 +4672,7 @@ enabled libopenjpeg   && { check_lib libopenjpeg 
openjpeg.h opj_version -lop
require_pkg_config libopenjpeg libopenjpeg1 
openjpeg.h opj_version -DOPJ_STATIC; }
 enabled libopus   && require_pkg_config libopus opus 
opus_multistream.h opus_multistream_decoder_create
 enabled libpulse  && require_pkg_config libpulse libpulse-simple 
pulse/simple.h pa_simple_new
+enabled libsrt&& require_pkg_config libsrt "srt >= 1.2.0" 
srt/srt.h srt_socket
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled libschroedinger   && require_pkg_config libschroedinger 
schroedinger-1.0 schroedinger/schro.h schro_init
 enabled libsnappy && require libsnappy snappy-c.h snappy_compress 
-lsnappy
diff --git a/doc/protocols.texi b/doc/protocols.texi
index c136c74e41..56d43e9e8a 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -655,6 +655,145 @@ To play back the first stream announced on one the 
default IPv6 SAP multicast ad
 avplay sap://[ff0e::2:7ffe]
 @end example

+@section srt
+
+Haivision Secure Reliable Transport Protocol via libsrt.
+
+The supported syntax for a SRT url is:
+@example
+srt://@var{hostname}:@var{port}[?@var{options}]
+@end example
+
+@var{options} contains a list of &-separated options of the form
+@var{key}=@var{val}.
+
+or
+
+@example
+@var{options} srt://@var{hostname}:@var{port}
+@end example
+
+@var{options} contains a list of '-@var{key} @var{val}'
+options.
+
+This protocol accepts the following options.
+
+@table @option
+@item connect_timeout
+Connection timeout. SRT cannot connect for RTT > 1500 msec
+(2 handshake exchanges) with the default connect timeout of
+3 seconds. This option applies to the caller and rendezvous
+connection modes. The connect timeout is 10 times the value
+set for the rendezvous mode (which can be used as a
+workaround for this connection problem with earlier versions).
+
+@item fc=@var{bytes}
+Flight Flag Size (Window Size), in bytes. FC is actually an
+internal parameter and you should set it to not less than
+@option{recv_buffer_size} and @option{mss}. The default value
+is relatively large, therefore unless you set a very large receiver buffer,
+you do not need to change this option. Default value is 25600.
+
+@item inputbw=@var{bytes/seconds}
+Sender nominal input rate, in bytes per seconds. Used along with
+@option{oheadbw}, when @option{maxbw} is set to relative (0), to
+calculate maximum sending rate when recovery packets are sent
+along with main media stream:
+@option{inputbw} * (100 + @option{oheadbw}) / 100
+if @option{inputbw} is not set while @option{maxbw} is set to
+relative (0), the actual ctual input rate is evaluated inside
+the library. Default value is 0.
+
+@item iptos=@var{tos}
+IP Type of Service. Applies to sender only. Default value is 0xB8.
+
+@item ipttl=@var{ttl}
+IP Time To Live. Applies to sender only. Default value is 64.
+
+@item listen_timeout
+Set socket listen timeout.
+
+@item maxbw=@var{bytes/seconds}
+Maximum sending bandwidth, in bytes per seconds.
+-1 infinite (CSRTCC limit is 30mbps)
+0 relative to input rate (see @option{inputbw})
+>0 absolute limit value
+Default value is 0 (relative)
+
+@item mode=@var{caller|listener|rendezvous}
+Connection mode.
+caller opens client connection.

Re: [libav-devel] [libva-devel] [PATCH] avformat/srt: add Haivision SRT protocol

2018-03-21 Thread Sven Dueking 


> -Ursprüngliche Nachricht-
> Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von
> Luca Barbato
> Gesendet: Montag, 19. März 2018 15:44
> An: libav-devel@libav.org
> Betreff: Re: [libav-devel] [libva-devel] [PATCH] avformat/srt: add
> Haivision SRT protocol
> 
> On 19/03/2018 15:16, Luca Barbato wrote:
> > On 19/03/2018 15:07, Sven Dueking wrote:
> >> Thanks for your quick feedback, I will double check this and come
> >> back to you asap.
> >
> > To give you a little more context I tested with:
> >
> > ./avplay -mode listener srt://localhost:12345
> >
> > ./avconv -filter_complex testsrc -f mpegts srt://localhost:12345
> >
> > If I switch to SOCK_DGRAM I receive a "Connection does not exist."
> error.
> >
> 
> And once I add srt_accept() in the right place it seems working just
> fine (tree updated, I'll fold everything in a single patch one you
> confirm I'm not making mistakes)
> 
> How is the rendez-vous mode should be tested?
> 
> lu

Hi Lu,

Thanks again, your changes looks good.

Regarding the rendezvous mode, the following command line works for me:

LD_LIBRARY_PATH=/usr/local/lib ./avconv -filter_complex testsrc -f mpegts 
srt://localhost:12345?mode=rendezvous

also, patch from attachment is needed in order to make rendezvous mode 
functional

(otherwise, without patch, the following error appears: [srt @ 0x20a4220] 
Operation not supported: Cannot call connect on UNBOUND socket in rendezvous 
connection setup.)

> 
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel


0001-rendezvous-requires-bind.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel