Re: [FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[Nicolas George]

L'octidi 8 fructidor, an CCXXIV, liu jc a écrit :
> Signed-off-by: liujingchao 
> ---
>  libavformat/tcp.c | 8 
>  1 file changed, 8 insertions(+)
>  mode change 100644 => 100755 libavformat/tcp.c
> 
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> old mode 100644
> new mode 100755
> index c105479..9f7112d
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -122,6 +122,14 @@ static int tcp_open(URLContext *h, const char *uri, int 
> flags)
>  cur_ai = ai;
>  
>   restart:
> +//workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 
> address can not resolve port number.
> +if (cur_ai->ai_family == AF_INET6){
> +struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
> *)cur_ai->ai_addr;
> +if (sockaddr_v6->sin6_port == 0){
> +sockaddr_v6->sin6_port = htons(port);
> +}
> +}
> +
>  fd = ff_socket(cur_ai->ai_family,
> cur_ai->ai_socktype,
> cur_ai->ai_protocol);

Please address all the comments in the previous reviews in a single patch.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Steven Liu]

2016-08-24 18:57 GMT+08:00 Michael Niedermayer :

> On Wed, Aug 24, 2016 at 06:28:08PM +0800, Steven Liu wrote:
> > 2016-08-24 18:23 GMT+08:00 Michael Niedermayer :
> >
> > > On Wed, Aug 24, 2016 at 03:04:59PM +0800, Steven Liu wrote:
> > > > On OSX test:
> > > > localhost:ffmpeg liuqi$ uname -a
> > > > Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19
> 18:36:36
> > > > PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
> > > > localhost:ffmpeg liuqi$ make fate-filter-hls-append
> > > > HOSTCC tests/base64.o
> > > > HOSTLD tests/base64
> > > > HOSTCC tests/tiny_psnr.o
> > > > HOSTLD tests/tiny_psnr
> > > > HOSTCC tests/tiny_ssim.o
> > > > HOSTLD tests/tiny_ssim
> > > > HOSTCC tests/audiomatch.o
> > > > tests/audiomatch.c:102:12: warning: using floating point absolute
> value
> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > > if(fabs(c) > sigamp * 0.94)
> > > >^
> > > > tests/audiomatch.c:102:12: note: use function 'llabs' instead
> > > > if(fabs(c) > sigamp * 0.94)
> > > >^~~~
> > > >llabs
> > > > tests/audiomatch.c:103:40: warning: using floating point absolute
> value
> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > > >^
> > > > tests/audiomatch.c:103:40: note: use function 'abs' instead
> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > > >^~~~
> > > >abs
> > > > tests/audiomatch.c:25:28: note: expanded from macro 'FFMIN'
> > > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> > > >^
> > > > tests/audiomatch.c:103:40: warning: using floating point absolute
> value
> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > > >^
> > > > tests/audiomatch.c:103:40: note: use function 'abs' instead
> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > > >^~~~
> > > >abs
> > > > tests/audiomatch.c:25:34: note: expanded from macro 'FFMIN'
> > > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> > > >  ^
> > > > tests/audiomatch.c:104:12: warning: using floating point absolute
> value
> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > > if(fabs(c)>fabs(bestc)){
> > > >^
> > > > tests/audiomatch.c:104:12: note: use function 'llabs' instead
> > > > if(fabs(c)>fabs(bestc)){
> > > >^~~~
> > > >llabs
> > > > 4 warnings generated.
> > > > HOSTLD tests/audiomatch
> > > > GEN tests/data/hls-list-append.m3u8
> > > > TESTfilter-hls-append
> > > >
> > > >
> > > >
> > > >
> > > > On Linux Test:
> > > > [root@localhost ffmpeg]# make fate-filter-hls-append
> > > > HOSTCC tests/base64.o
> > > > HOSTLD tests/base64
> > > > HOSTCC tests/tiny_psnr.o
> > > > HOSTLD tests/tiny_psnr
> > > > HOSTCC tests/tiny_ssim.o
> > > > HOSTLD tests/tiny_ssim
> > > > HOSTCC tests/audiomatch.o
> > > > tests/audiomatch.c: 在函数‘main’中:
> > > > tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
> > > > HOSTLD tests/audiomatch
> > > > GEN tests/data/hls-list-append.m3u8
> > > > TESTfilter-hls-append
> > > > [root@localhost ffmpeg]# uname -a
> > > > Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
> > > > 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > fails with mingw
> > > ../configure  --cc='ccache i686-w64-mingw32-gcc'  --samples=...
> --arch=x86
> > > --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-gpl
> > > --pkg-config=./pig-config --target_exec=wine
> > >
> > > ...
> > > +0, 873216, 873216, 1152, 2304, 0x823b822c
> > > +0, 874368, 874368, 1152, 2304, 0xa1658479
> > > +0, 875520, 875520, 1152, 2304, 0xdbe58ff7
> > > +0, 876672, 876672, 1152, 2304, 0x725175e2
> > > +0, 877824, 877824, 1152, 2304, 0xb2ae7741
> > > +0, 878976, 878976, 1152, 2304, 0x4de169e4
> > > +0, 880128, 880128, 1152, 2304, 0x3cb18530
> > > +0, 881280, 881280, 1152, 2304, 0x48b95d6c
> > > +0, 882432, 882432, 1152, 2304, 0xcff707ef
> > > Test filter-hls-append failed. Look at tests/data/fate/filter-hls-
> append.err
> > > for details.
> > > make: *** [fate-filter-hls-append] Error 1
> > > make: *** Waiting for unfinished jobs
> > >
> > .. ok, let me find a Windows Environment to fix it.
>
> the failure was on a ubuntu with wine, i dont know if it fails on a
> native windows
> ok, i see, i'll test this patch on windows

Re: [FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[Nicolas George]

L'octidi 8 fructidor, an CCXXIV, liu jc a écrit :
> Signed-off-by: liujingchao 
> ---
>  libavformat/tcp.c | 11 +++
>  1 file changed, 11 insertions(+)
>  mode change 100644 => 100755 libavformat/tcp.c
> 
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> old mode 100644
> new mode 100755
> index c105479..289bcd8
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -122,6 +122,17 @@ static int tcp_open(URLContext *h, const char *uri, int 
> flags)
>  cur_ai = ai;
>  
>   restart:
> +
> +if (cur_ai->ai_family == AF_INET6)
> +{
> +struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
> *)cur_ai->ai_addr;
> +if (sockaddr_v6->sin6_port == 0)
> +{
> +sockaddr_v6->sin6_port = htons(port);
> +}
> +}

Please respect the surrounding coding style.

From my point of view, this is dead code that can be removed. A comment is
needed to avoid that.

> +   

Trailing spaces are forbidden; tools/patcheck would have noticed it.

> + 

Id do not think we need two empty lines here.

>  fd = ff_socket(cur_ai->ai_family,
> cur_ai->ai_socktype,
> cur_ai->ai_protocol);

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Steven Liu]

2016-08-24 18:23 GMT+08:00 Michael Niedermayer :

> On Wed, Aug 24, 2016 at 03:04:59PM +0800, Steven Liu wrote:
> > On OSX test:
> > localhost:ffmpeg liuqi$ uname -a
> > Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36
> > PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
> > localhost:ffmpeg liuqi$ make fate-filter-hls-append
> > HOSTCC tests/base64.o
> > HOSTLD tests/base64
> > HOSTCC tests/tiny_psnr.o
> > HOSTLD tests/tiny_psnr
> > HOSTCC tests/tiny_ssim.o
> > HOSTLD tests/tiny_ssim
> > HOSTCC tests/audiomatch.o
> > tests/audiomatch.c:102:12: warning: using floating point absolute value
> > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > if(fabs(c) > sigamp * 0.94)
> >^
> > tests/audiomatch.c:102:12: note: use function 'llabs' instead
> > if(fabs(c) > sigamp * 0.94)
> >^~~~
> >llabs
> > tests/audiomatch.c:103:40: warning: using floating point absolute value
> > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >^
> > tests/audiomatch.c:103:40: note: use function 'abs' instead
> > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >^~~~
> >abs
> > tests/audiomatch.c:25:28: note: expanded from macro 'FFMIN'
> > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> >^
> > tests/audiomatch.c:103:40: warning: using floating point absolute value
> > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >^
> > tests/audiomatch.c:103:40: note: use function 'abs' instead
> > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >^~~~
> >abs
> > tests/audiomatch.c:25:34: note: expanded from macro 'FFMIN'
> > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> >  ^
> > tests/audiomatch.c:104:12: warning: using floating point absolute value
> > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > if(fabs(c)>fabs(bestc)){
> >^
> > tests/audiomatch.c:104:12: note: use function 'llabs' instead
> > if(fabs(c)>fabs(bestc)){
> >^~~~
> >llabs
> > 4 warnings generated.
> > HOSTLD tests/audiomatch
> > GEN tests/data/hls-list-append.m3u8
> > TESTfilter-hls-append
> >
> >
> >
> >
> > On Linux Test:
> > [root@localhost ffmpeg]# make fate-filter-hls-append
> > HOSTCC tests/base64.o
> > HOSTLD tests/base64
> > HOSTCC tests/tiny_psnr.o
> > HOSTLD tests/tiny_psnr
> > HOSTCC tests/tiny_ssim.o
> > HOSTLD tests/tiny_ssim
> > HOSTCC tests/audiomatch.o
> > tests/audiomatch.c: 在函数‘main’中:
> > tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
> > HOSTLD tests/audiomatch
> > GEN tests/data/hls-list-append.m3u8
> > TESTfilter-hls-append
> > [root@localhost ffmpeg]# uname -a
> > Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
> > 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>
> fails with mingw
> ../configure  --cc='ccache i686-w64-mingw32-gcc'  --samples=... --arch=x86
> --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-gpl
> --pkg-config=./pig-config --target_exec=wine
>
> ...
> +0, 873216, 873216, 1152, 2304, 0x823b822c
> +0, 874368, 874368, 1152, 2304, 0xa1658479
> +0, 875520, 875520, 1152, 2304, 0xdbe58ff7
> +0, 876672, 876672, 1152, 2304, 0x725175e2
> +0, 877824, 877824, 1152, 2304, 0xb2ae7741
> +0, 878976, 878976, 1152, 2304, 0x4de169e4
> +0, 880128, 880128, 1152, 2304, 0x3cb18530
> +0, 881280, 881280, 1152, 2304, 0x48b95d6c
> +0, 882432, 882432, 1152, 2304, 0xcff707ef
> Test filter-hls-append failed. Look at tests/data/fate/filter-hls-append.err
> for details.
> make: *** [fate-filter-hls-append] Error 1
> make: *** Waiting for unfinished jobs
>
.. ok, let me find a Windows Environment to fix it.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[liu jc]

Signed-off-by: liujingchao 
---
 libavformat/tcp.c | 8 
 1 file changed, 8 insertions(+)
 mode change 100644 => 100755 libavformat/tcp.c

diff --git a/libavformat/tcp.c b/libavformat/tcp.c
old mode 100644
new mode 100755
index c105479..fd10a56
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -122,6 +122,14 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 cur_ai = ai;
 
  restart:
+// workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 
address can not resolve port number.
+if (cur_ai->ai_family == AF_INET6){
+struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
*)cur_ai->ai_addr;
+if (!sockaddr_v6->sin6_port){
+sockaddr_v6->sin6_port = htons(port);
+}
+}
+
 fd = ff_socket(cur_ai->ai_family,
cur_ai->ai_socktype,
cur_ai->ai_protocol);
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Michael Niedermayer]

On Wed, Aug 24, 2016 at 06:28:08PM +0800, Steven Liu wrote:
> 2016-08-24 18:23 GMT+08:00 Michael Niedermayer :
> 
> > On Wed, Aug 24, 2016 at 03:04:59PM +0800, Steven Liu wrote:
> > > On OSX test:
> > > localhost:ffmpeg liuqi$ uname -a
> > > Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36
> > > PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
> > > localhost:ffmpeg liuqi$ make fate-filter-hls-append
> > > HOSTCC tests/base64.o
> > > HOSTLD tests/base64
> > > HOSTCC tests/tiny_psnr.o
> > > HOSTLD tests/tiny_psnr
> > > HOSTCC tests/tiny_ssim.o
> > > HOSTLD tests/tiny_ssim
> > > HOSTCC tests/audiomatch.o
> > > tests/audiomatch.c:102:12: warning: using floating point absolute value
> > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > if(fabs(c) > sigamp * 0.94)
> > >^
> > > tests/audiomatch.c:102:12: note: use function 'llabs' instead
> > > if(fabs(c) > sigamp * 0.94)
> > >^~~~
> > >llabs
> > > tests/audiomatch.c:103:40: warning: using floating point absolute value
> > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > >^
> > > tests/audiomatch.c:103:40: note: use function 'abs' instead
> > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > >^~~~
> > >abs
> > > tests/audiomatch.c:25:28: note: expanded from macro 'FFMIN'
> > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> > >^
> > > tests/audiomatch.c:103:40: warning: using floating point absolute value
> > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > >^
> > > tests/audiomatch.c:103:40: note: use function 'abs' instead
> > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> > >^~~~
> > >abs
> > > tests/audiomatch.c:25:34: note: expanded from macro 'FFMIN'
> > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> > >  ^
> > > tests/audiomatch.c:104:12: warning: using floating point absolute value
> > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> > > if(fabs(c)>fabs(bestc)){
> > >^
> > > tests/audiomatch.c:104:12: note: use function 'llabs' instead
> > > if(fabs(c)>fabs(bestc)){
> > >^~~~
> > >llabs
> > > 4 warnings generated.
> > > HOSTLD tests/audiomatch
> > > GEN tests/data/hls-list-append.m3u8
> > > TESTfilter-hls-append
> > >
> > >
> > >
> > >
> > > On Linux Test:
> > > [root@localhost ffmpeg]# make fate-filter-hls-append
> > > HOSTCC tests/base64.o
> > > HOSTLD tests/base64
> > > HOSTCC tests/tiny_psnr.o
> > > HOSTLD tests/tiny_psnr
> > > HOSTCC tests/tiny_ssim.o
> > > HOSTLD tests/tiny_ssim
> > > HOSTCC tests/audiomatch.o
> > > tests/audiomatch.c: 在函数‘main’中:
> > > tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
> > > HOSTLD tests/audiomatch
> > > GEN tests/data/hls-list-append.m3u8
> > > TESTfilter-hls-append
> > > [root@localhost ffmpeg]# uname -a
> > > Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
> > > 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> >
> > fails with mingw
> > ../configure  --cc='ccache i686-w64-mingw32-gcc'  --samples=... --arch=x86
> > --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-gpl
> > --pkg-config=./pig-config --target_exec=wine
> >
> > ...
> > +0, 873216, 873216, 1152, 2304, 0x823b822c
> > +0, 874368, 874368, 1152, 2304, 0xa1658479
> > +0, 875520, 875520, 1152, 2304, 0xdbe58ff7
> > +0, 876672, 876672, 1152, 2304, 0x725175e2
> > +0, 877824, 877824, 1152, 2304, 0xb2ae7741
> > +0, 878976, 878976, 1152, 2304, 0x4de169e4
> > +0, 880128, 880128, 1152, 2304, 0x3cb18530
> > +0, 881280, 881280, 1152, 2304, 0x48b95d6c
> > +0, 882432, 882432, 1152, 2304, 0xcff707ef
> > Test filter-hls-append failed. Look at tests/data/fate/filter-hls-append.err
> > for details.
> > make: *** [fate-filter-hls-append] Error 1
> > make: *** Waiting for unfinished jobs
> >
> .. ok, let me find a Windows Environment to fix it.

the failure was on a ubuntu with wine, i dont know if it fails on a
native windows

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 答复: 答复: 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

[liu jc]

Yes it is better to modify it in all protocol  that need call getaddrinfo. This 
patch just can fix one usage scenarios . I think it is enough  for the Video 
APP that use FFMPEG to pass the APPLEreview for IPv6. Other than that APPLE 
already know this bug i think it will be fix in the future.



发件人: ffmpeg-devel  代表 Steven Liu 

发送时间: 2016年8月24日 7:23
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] 答复: 答复: [PATCH] 
IOS-IPv6-only-network-use-hardcode-IPv4-fix

2016-08-24 15:19 GMT+08:00 liu jc :

> Yes you can. But if you are in the IPv6 only network and use a hardcode
> IPv4 address ,in latest IOS version if you just use a port number as the
> second parameter of function getaddrinfo, you will get a connection fail
> when you connect to you server.
>
> I think you have fixed a bug, but make some new bug with this patch,
Why don't fix the protocol by default work flow?

>
> 
> 发件人: ffmpeg-devel  代表 Steven Liu <
> lingjiujia...@gmail.com>
> 发送时间: 2016年8月24日 2:46
> 收件人: FFmpeg development discussions and patches
> 主题: Re: [FFmpeg-devel] 答复: [PATCH] IOS-IPv6-only-network-use-
> hardcode-IPv4-fix
>
> 2016-08-24 10:40 GMT+08:00 liu jc :
>
> > this  patch just deal with the standard condition (most people use 1935).
> > Although you still can use  the port and service map in mac
> (/etc/services)
> > to cheat. If you rtmp server listen 1936 following the mac services list
> > you can just pass a
> >
> > service name "jetcmeserver" then you tcp connection can establish
> > successful.  But for not resulting ambiguity it is recommend use standard
> > port number for specific service.
> >
> But without this patch, i can publish stream to rtmp server listening 1936
> or other.
>
> >
> >
> > 
> > 发件人: ffmpeg-devel  代表 Steven Liu <
> > lingjiujia...@gmail.com>
> > 发送时间: 2016年8月24日 1:34
> > 收件人: FFmpeg development discussions and patches
> > 主题: Re: [FFmpeg-devel] [PATCH] IOS-IPv6-only-network-use-
> hardcode-IPv4-fix
> >
> > 2016-08-24 9:03 GMT+08:00 liu jc :
> >
> > >
> > >  there is a bug when useing getaddrinfo in IOS when use
> > >  hardcode IPv4 address and in IPv6-only networks.It can not
> > >  accept a port number as second parameter as an alternative
> > >  you can pass a service name  or it will cause connect fail.
> > >  In current video CDN dispatching mechanism the hardcode
> > >  IPv4 is widly used for better performance. This problem
> > >  cause many APP use ffmpeg to play this type CDN dispatched
> > >  video were rejected by APP store. This patch fix this by
> > >  adding a port to name map for widly used port number that
> > >  these CDN use to dispatch video.
> > >
> > > ---
> > >  libavformat/tcp.c |   17 +++--
> > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > >  mode change 100644 => 100755 libavformat/tcp.c
> > >
> > > diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> > > old mode 100644
> > > new mode 100755
> > > index c105479..0de7710
> > > --- a/libavformat/tcp.c
> > > +++ b/libavformat/tcp.c
> > > @@ -72,7 +72,7 @@ static int tcp_open(URLContext *h, const char *uri,
> int
> > > flags)
> > >  char buf[256];
> > >  int ret;
> > >  char hostname[1024],proto[1024],path[1024];
> > > -char portstr[10];
> > > +char portstr[64];
> > >  s->open_timeout = 500;
> > >
> > >  av_url_split(proto, sizeof(proto), NULL, 0, hostname,
> > > sizeof(hostname),
> > > @@ -105,7 +105,19 @@ static int tcp_open(URLContext *h, const char
> *uri,
> > > int flags)
> > >  }
> > >  hints.ai_family = AF_UNSPEC;
> > >  hints.ai_socktype = SOCK_STREAM;
> > > -snprintf(portstr, sizeof(portstr), "%d", port);
> > > +
> > > +   switch (port) {
> > > +case 80:
> > > +snprintf(portstr, sizeof(portstr), "%s", "http");
> > > +break;
> > > +case 1935:
> > > +snprintf(portstr, sizeof(portstr), "%s",
> "macromedia-fcs");
> > > //know as rtmp
> > >
> > i have one quetion: When the rtmp server listen the port 1936, what about
> > the portstr?
> >
> > > +break;
> > > +default:
> > > +snprintf(portstr, sizeof(portstr), "%d", port);
> > > +break;
> > > +}
> > > +
> > >  if (s->listen)
> > >  hints.ai_flags |= AI_PASSIVE;
> > >  if (!hostname[0])
> > > @@ -268,3 +280,4 @@ const URLProtocol ff_tcp_protocol = {
> > >  .flags   = URL_PROTOCOL_FLAG_NETWORK,
> > >  .priv_data_class = _class,
> > >  };
> > > +
> > >
> > delete this line.
> >
> > > --
> > > 1.7.9.5
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[liu jc]

Signed-off-by: liujingchao 
---
 libavformat/tcp.c | 11 +++
 1 file changed, 11 insertions(+)
 mode change 100644 => 100755 libavformat/tcp.c

diff --git a/libavformat/tcp.c b/libavformat/tcp.c
old mode 100644
new mode 100755
index c105479..289bcd8
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -122,6 +122,17 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 cur_ai = ai;
 
  restart:
+
+if (cur_ai->ai_family == AF_INET6)
+{
+struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
*)cur_ai->ai_addr;
+if (sockaddr_v6->sin6_port == 0)
+{
+sockaddr_v6->sin6_port = htons(port);
+}
+}
+
+   
 fd = ff_socket(cur_ai->ai_family,
cur_ai->ai_socktype,
cur_ai->ai_protocol);
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[liu jc]

Signed-off-by: liujingchao 
---
 libavformat/tcp.c | 8 
 1 file changed, 8 insertions(+)
 mode change 100644 => 100755 libavformat/tcp.c

diff --git a/libavformat/tcp.c b/libavformat/tcp.c
old mode 100644
new mode 100755
index c105479..9f7112d
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -122,6 +122,14 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 cur_ai = ai;
 
  restart:
+//workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 
address can not resolve port number.
+if (cur_ai->ai_family == AF_INET6){
+struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
*)cur_ai->ai_addr;
+if (sockaddr_v6->sin6_port == 0){
+sockaddr_v6->sin6_port = htons(port);
+}
+}
+
 fd = ff_socket(cur_ai->ai_family,
cur_ai->ai_socktype,
cur_ai->ai_protocol);
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 答复: [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[liu jc]

 Did you mean empty line?



发件人: Nicolas George 
发送时间: 2016年8月24日 10:01
收件人: FFmpeg development discussions and patches
抄送: liu jc
主题: Re: [FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only 
network use hardcode IPv4 address can not resolve port number.

L'octidi 8 fructidor, an CCXXIV, liu jc a écrit :
> Signed-off-by: liujingchao 
> ---
>  libavformat/tcp.c | 8 
>  1 file changed, 8 insertions(+)
>  mode change 100644 => 100755 libavformat/tcp.c
>
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> old mode 100644
> new mode 100755
> index c105479..9f7112d
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -122,6 +122,14 @@ static int tcp_open(URLContext *h, const char *uri, int 
> flags)
>  cur_ai = ai;
>
>   restart:
> +//workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 
> address can not resolve port number.
> +if (cur_ai->ai_family == AF_INET6){
> +struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
> *)cur_ai->ai_addr;
> +if (sockaddr_v6->sin6_port == 0){
> +sockaddr_v6->sin6_port = htons(port);
> +}
> +}
> +
>  fd = ff_socket(cur_ai->ai_family,
> cur_ai->ai_socktype,
> cur_ai->ai_protocol);

Please address all the comments in the previous reviews in a single patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Oliver Collyer]

Ok thanks, Timo.

So I’ve split this into two patches and revised as per the discussions and they 
are attached here.

The only thing to be decided is whether my conversion code to enable YUV420P10 
support should be included in this or not.

It’s in the attached patch but I’m happy to remove it if necessary.

Regards

Oliver



0001-NVENC-added-support-for-10-bit-HEVC-encoding.patch
Description: Binary data


0002-NVENC-added-support-for-rate-control-lookahead.patch
Description: Binary data


> On 24 Aug 2016, at 12:04, Timo Rothenpieler  wrote:
> 
> Am 24.08.2016 um 10:21 schrieb Oliver Collyer:
>>> In any case, please split the rate control patch from the 10bit patch.
>>> 
>> 
>> Just double-checking this - both changes require a bump of the minimum NVENC 
>> version to 7. Do you still want them as separate patches or does this tie 
>> them together? If they are to be separate patches then obviously one of them 
>> will need to be applied first, so there is a dependency between them.
> 
> Just bump it with the first patch.
> Also remember to bump lavc micro version.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] patchwork update bot

[Michael Niedermayer]

Hi

As i got a bit annoyed by accumulating duplicate and non applicable
patches or rather the need to manually weed them out of patchwork
ive yesterday quickly written the attached script

Does something like this already exist ?
or is this usefull and it would make sense to throw this on some public
git repo (like github/michaelni) ?

currently it will download all patches (they are cached so wont be
downloaded twice) and will
* Detect patches that are actual fate failures (fate failure command
  line output is syntactically a patch)
* Find superseeded patches based on subject and author
* It will list the found cases and provide a single line command to
  update their status but not execute it automatically
  (i intend to automate this but i need to make  more sure it makes no
   big mistakes first)

Example output from today:
pwbot.py
loading: 1, 2, 3, 4, 6, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 21, 20, 17, 19, 
18, 22, 23, 24, 25, 28, 29, 31, 30, 26, 27, 32, 33, 35, 34, 36, 37, 38, 39, 40, 
41, 43, 42, 44, 46, 45, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 63, 64, 58, 62, 
65, 60, 59, 66, 57, 61, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 
82, 81, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 
100, 102, 101, 103, 104, 105, 106, 107, 108, 109, 110, 112, 111, 113, 114, 115, 
116, 117, 118, 119, 120, 121, 122, 123, 124, 127, 125, 126, 128, 129, 131, 130, 
138, 136, 132, 135, 137, 134, 133, 139, 140, 141, 142, 143, 144, 145, 146, 147, 
148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 
164, 165, 166, 167, 168, 170, 169, 172, 171, 174, 173, 176, 175, 177, 180, 178, 
179, 181, 182, 183, 184, 185, 186, 187, 188, 194, 189, 193, 191, 192, 190, 195, 
196, 197, 198, 199, 201, 200, 204, 202, 203, 205, 206, 207, 208, 209, 210, 211, 
218, 214, 217, 215, 216, 212, 213, 219, 220, 221, 222, 224, 223, 
226, 225, 227, 228, 229, 230, 231, 234, 232, 233, 235, 236, 237, 240, 238, 239, 
241, 271, 242, 243, 244, 249, 245, 246, 248, 259, 251, 262, 247, 265, 257, 258, 
261, 253, 263, 256, 250, 255, 264, 252, 254, 260, 266, 267, 268, 269, 270, 272, 
273, 274, 275, 276, 277, 278, 279,
DUP: 276 New 2016-08-24 09:17:05 liu jc  [FFmpeg-devel] 
workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address 
can not resolve port number.
DUP: 277 New 2016-08-24 09:33:42 liu jc  [FFmpeg-devel] 
workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address 
can not resolve port number.
DUP: 278 New 2016-08-24 09:56:07 liu jc  [FFmpeg-devel] 
workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address 
can not resolve port number.
./pwclient update  276 277 278 -s 'Superseded'

PS: cleanup of the script is welcome btw if someone cares about that

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
#!/usr/bin/python
#Michael Niedermayer
#GPL 2+

import os
import pickle
import subprocess
import sys

# This may be needed to be applied to pwclient for it to not crash
#@@ -165,7 +172,7 @@
# # naive way to strip < and > from message-id
# val = string.strip(str(patch["msgid"]), "<>")
# else:
#+val = unicode(patch[fieldname]).encode('utf-8')
#-val = str(patch[fieldname])
#
# return val

pwclient = "./pwclient"

def cached_call( command ):
if not command in cache :
cache[command] = os.popen(command).read()
return cache[command]

def isint(value):
try:
int(value)
return True
except:
return False

id_list = []
status_list = []
subject_list = []
date_list = []
delegate_list = []
submitter_list = []
patch_list = []

def get_patch_list( ):
proc = subprocess.Popen([pwclient, 'list', '-f', '%{id}@#SEP%{state}@#SEP%{name}@#SEP%{date}@#SEP%{delegate}@#SEP%{submitter}'],stdout=subprocess.PIPE)
sys.stderr.write("loading: ")
for line in proc.stdout:
tmp = line.strip().split('@#SEP')
if isint(tmp[0]) :
id_list .append(tmp[0])
status_list .append(tmp[1])
subject_list.append(tmp[2])
date_list   .append(tmp[3])
delegate_list   .append(tmp[4])
submitter_list  .append(tmp[5])

sys.stderr.write(tmp[0] + ", ")
patch_list  .append(cached_call(pwclient +' view ' + tmp[0]))

sys.stderr.write("\n")
return True

cache = {}
try :
f = open("patchbot.cache", 'rb')
cache = pickle.load(f)
f.close()
except : IOError

get_patch_list()


# Find non applicable (fate failure type patches) which havnt been 

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Michael Niedermayer]

On Wed, Aug 24, 2016 at 03:04:59PM +0800, Steven Liu wrote:
> On OSX test:
> localhost:ffmpeg liuqi$ uname -a
> Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36
> PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
> localhost:ffmpeg liuqi$ make fate-filter-hls-append
> HOSTCC tests/base64.o
> HOSTLD tests/base64
> HOSTCC tests/tiny_psnr.o
> HOSTLD tests/tiny_psnr
> HOSTCC tests/tiny_ssim.o
> HOSTLD tests/tiny_ssim
> HOSTCC tests/audiomatch.o
> tests/audiomatch.c:102:12: warning: using floating point absolute value
> function 'fabs' when argument is of integer type [-Wabsolute-value]
> if(fabs(c) > sigamp * 0.94)
>^
> tests/audiomatch.c:102:12: note: use function 'llabs' instead
> if(fabs(c) > sigamp * 0.94)
>^~~~
>llabs
> tests/audiomatch.c:103:40: warning: using floating point absolute value
> function 'fabs' when argument is of integer type [-Wabsolute-value]
> maxshift = FFMIN(maxshift, fabs(pos)+32);
>^
> tests/audiomatch.c:103:40: note: use function 'abs' instead
> maxshift = FFMIN(maxshift, fabs(pos)+32);
>^~~~
>abs
> tests/audiomatch.c:25:28: note: expanded from macro 'FFMIN'
> #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
>^
> tests/audiomatch.c:103:40: warning: using floating point absolute value
> function 'fabs' when argument is of integer type [-Wabsolute-value]
> maxshift = FFMIN(maxshift, fabs(pos)+32);
>^
> tests/audiomatch.c:103:40: note: use function 'abs' instead
> maxshift = FFMIN(maxshift, fabs(pos)+32);
>^~~~
>abs
> tests/audiomatch.c:25:34: note: expanded from macro 'FFMIN'
> #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
>  ^
> tests/audiomatch.c:104:12: warning: using floating point absolute value
> function 'fabs' when argument is of integer type [-Wabsolute-value]
> if(fabs(c)>fabs(bestc)){
>^
> tests/audiomatch.c:104:12: note: use function 'llabs' instead
> if(fabs(c)>fabs(bestc)){
>^~~~
>llabs
> 4 warnings generated.
> HOSTLD tests/audiomatch
> GEN tests/data/hls-list-append.m3u8
> TESTfilter-hls-append
> 
> 
> 
> 
> On Linux Test:
> [root@localhost ffmpeg]# make fate-filter-hls-append
> HOSTCC tests/base64.o
> HOSTLD tests/base64
> HOSTCC tests/tiny_psnr.o
> HOSTLD tests/tiny_psnr
> HOSTCC tests/tiny_ssim.o
> HOSTLD tests/tiny_ssim
> HOSTCC tests/audiomatch.o
> tests/audiomatch.c: 在函数‘main’中:
> tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
> HOSTLD tests/audiomatch
> GEN tests/data/hls-list-append.m3u8
> TESTfilter-hls-append
> [root@localhost ffmpeg]# uname -a
> Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
> 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

fails with mingw
../configure  --cc='ccache i686-w64-mingw32-gcc'  --samples=... --arch=x86 
--target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-gpl 
--pkg-config=./pig-config --target_exec=wine

...
+0, 873216, 873216, 1152, 2304, 0x823b822c
+0, 874368, 874368, 1152, 2304, 0xa1658479
+0, 875520, 875520, 1152, 2304, 0xdbe58ff7
+0, 876672, 876672, 1152, 2304, 0x725175e2
+0, 877824, 877824, 1152, 2304, 0xb2ae7741
+0, 878976, 878976, 1152, 2304, 0x4de169e4
+0, 880128, 880128, 1152, 2304, 0x3cb18530
+0, 881280, 881280, 1152, 2304, 0x48b95d6c
+0, 882432, 882432, 1152, 2304, 0xcff707ef
Test filter-hls-append failed. Look at tests/data/fate/filter-hls-append.err 
for details.
make: *** [fate-filter-hls-append] Error 1
make: *** Waiting for unfinished jobs

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[liu jc]

Signed-off-by: liujingchao 
---
 libavformat/tcp.c | 10 ++
 1 file changed, 10 insertions(+)
 mode change 100644 => 100755 libavformat/tcp.c

diff --git a/libavformat/tcp.c b/libavformat/tcp.c
old mode 100644
new mode 100755
index c105479..61b68ca
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -122,6 +122,16 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 cur_ai = ai;
 
  restart:
+
+if (cur_ai->ai_family == AF_INET6)
+{
+struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
*)cur_ai->ai_addr;
+if (sockaddr_v6->sin6_port == 0)
+{
+sockaddr_v6->sin6_port = htons(port);
+}
+}
+
 fd = ff_socket(cur_ai->ai_family,
cur_ai->ai_socktype,
cur_ai->ai_protocol);
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Moritz Barsnick]

On Wed, Aug 24, 2016 at 15:04:59 +0800, Steven Liu wrote:
> [root@localhost ffmpeg]# make fate-filter-hls-append
[...]
> tests/audiomatch.c: 在函数‘main’中:
> tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化

Just a hint: For improved readability on this list, please use
something like
$ LANG=C make fate-filter-hls-append

(Yes, I know Google Translate translates that just fine. ;-))

It's just a helper tool IIUC, but warnings should be taken seriously.
(The whole tool could make use of some rework, but does anyone really
care?)

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Timo Rothenpieler]

Am 24.08.2016 um 10:21 schrieb Oliver Collyer:
>> In any case, please split the rate control patch from the 10bit patch.
>>
> 
> Just double-checking this - both changes require a bump of the minimum NVENC 
> version to 7. Do you still want them as separate patches or does this tie 
> them together? If they are to be separate patches then obviously one of them 
> will need to be applied first, so there is a dependency between them.

Just bump it with the first patch.
Also remember to bump lavc micro version.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.

[Nicolas George]

L'octidi 8 fructidor, an CCXXIV, liu jc a écrit :
> Signed-off-by: liujingchao 
> ---
>  libavformat/tcp.c | 10 ++
>  1 file changed, 10 insertions(+)
>  mode change 100644 => 100755 libavformat/tcp.c
> 
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> old mode 100644
> new mode 100755
> index c105479..61b68ca
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -122,6 +122,16 @@ static int tcp_open(URLContext *h, const char *uri, int 
> flags)
>  cur_ai = ai;
>  
>   restart:
> +
> +if (cur_ai->ai_family == AF_INET6)
> +{
> +struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 
> *)cur_ai->ai_addr;
> +if (sockaddr_v6->sin6_port == 0)
> +{
> +sockaddr_v6->sin6_port = htons(port);
> +}
> +}

As already pointed out:

Please respect the surrounding coding style.

From my point of view, this is dead code that can be removed. A comment is
needed to avoid that.

Obvious breaks from the coding style: braces placement, braces on trivial
statements, comparison to 0, pointer mark placement.

> +
>  fd = ff_socket(cur_ai->ai_family,
> cur_ai->ai_socktype,
> cur_ai->ai_protocol);


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add lut2 filter

[Paul B Mahol]

Hi,

patch attached.


0001-avfilter-add-lut2-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 答复: 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

[liu jc]

Awesome the second workaround seem a better way i will try it.



发件人: ffmpeg-devel  代表 Michael Niedermayer 

发送时间: 2016年8月24日 8:11
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

On Wed, Aug 24, 2016 at 07:15:29AM +, liu jc wrote:
> It is not a ios hack,  It compatible with any system that in accordance with 
> the POSIX standards. The second parameter of function getaddrinfo  can accept 
> the port name or a service name. If you give a service name to it it will 
> translate it to a  standard port number.

POSIX says this:

http://pubs.opengroup.org/onlinepubs/009695399/functions/freeaddrinfo.html

"If servname is null, the call shall return network-level addresses for the 
specified nodename. If servname is not null, it is a null-terminated character 
string identifying the requested service. This can be either a descriptive name 
or a numeric representation suitable for use with the address family or 
families. If the specified address family is AF_INET, [IP6] [Option Start]  
AF_INET6, [Option End] or AF_UNSPEC, the service can be specified as a string 
specifying a decimal port number."

so port numbers are required to be supported by POSIX
some IOS version fails with that,
that IOS version is buggy, the bug in fact seems known and has been
fixed already IIUC
also see
http://stackoverflow.com/questions/37386161/service-port-is-missed-when-using-getaddrinfo-to-convert-ipv4-addr-to-ipv6-addr

also macromedia-fcs is not in my /etc/services so your patch
would break POSIX systems

If you wish to workaround a IOS bug i dont mind but that has to be
clean and work.
your patch half works on IOS (only 2 port numbers supported) and half
breaks POSIX systems


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Steven Liu]

2016-08-24 17:05 GMT+08:00 Moritz Barsnick :

> On Wed, Aug 24, 2016 at 15:04:59 +0800, Steven Liu wrote:
> > [root@localhost ffmpeg]# make fate-filter-hls-append
> [...]
> > tests/audiomatch.c: 在函数‘main’中:
> > tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
>
>
Sorry, That's Chinese font. Warning in english is:
tests/audiomatch.c:40: warning: ‘bestpos’ may be used uninitialized in this
function



> Just a hint: For improved readability on this list, please use
> something like
> $ LANG=C make fate-filter-hls-append
>
> (Yes, I know Google Translate translates that just fine. ;-))
>
> It's just a helper tool IIUC, but warnings should be taken seriously.
> (The whole tool could make use of some rework, but does anyone really
> care?)
>
Ok, I will send a new patch to fix this warning,
I ignore this warning because it's just on my OS and it is in original code.
Maybe it will not warning at the other  OS.

>
> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add vaguedenoiser filter

[Paul B Mahol]

Hi,

patch attached.


0001-avfilter-add-vaguedenoiser-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.

[Michael Niedermayer]

On Mon, Aug 15, 2016 at 07:04:57PM -0700, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c  |  334 +++-
>  tests/Makefile |1 +
>  tests/fate/mov.mak |   28 +
>  tests/ref/fate/filter-fps-cfr  |1 -
>  tests/ref/fate/gaplessenc-itunes-to-ipod-aac   |   12 +-
>  tests/ref/fate/gaplessenc-pcm-to-mov-aac   |   12 +-
>  tests/ref/fate/gsm-toast   | 1000 
> 
>  tests/ref/fate/h264-invalid-ref-mod|   20 +-
>  tests/ref/fate/mov-1elist-1ctts|   57 ++
>  tests/ref/fate/mov-1elist-ends-last-bframe |   56 ++
>  tests/ref/fate/mov-1elist-noctts   |   57 ++
>  tests/ref/fate/mov-2elist-elist1-ends-bframe   |   51 ++
>  tests/ref/fate/mov-3elist  |   57 ++
>  tests/ref/fate/mov-3elist-1ctts|   57 ++
>  tests/ref/fate/mov-elist-starts-ctts-2ndsample |   57 ++
>  tests/ref/fate/pcm_s16be-stereo|2 +-
>  tests/ref/fate/quickdraw   |   12 +-
>  tests/ref/fate/tscc2-mov   |   20 +-
>  tests/ref/lavf-fate/mov_qtrle_mace6|2 +-
>  19 files changed, 1287 insertions(+), 549 deletions(-)
>  create mode 100644 tests/fate/mov.mak
>  create mode 100644 tests/ref/fate/mov-1elist-1ctts
>  create mode 100644 tests/ref/fate/mov-1elist-ends-last-bframe
>  create mode 100644 tests/ref/fate/mov-1elist-noctts
>  create mode 100644 tests/ref/fate/mov-2elist-elist1-ends-bframe
>  create mode 100644 tests/ref/fate/mov-3elist
>  create mode 100644 tests/ref/fate/mov-3elist-1ctts
>  create mode 100644 tests/ref/fate/mov-elist-starts-ctts-2ndsample

it seems one fate test fails with this patchset
make: *** [fate-mov-2elist-elist1-ends-bframe] Error 134
Assertion !index || ie[-1].timestamp <= timestamp failed at 
libavformat/mov.c:2850
Aborted

I think this didnt happen when i tested a previous revission

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix audiomatch complie warning

[Michael Niedermayer]

On Wed, Aug 24, 2016 at 10:20:11PM +0800, Steven Liu wrote:
> Making sure bestpos is initialized to zero to prevent gcc from kvetching.
> It's harmless (although it's not obvious that it's harmless)
> from code inspection:
> tests/audiomatch.c: In function ‘main’:
> tests/audiomatch.c:40: warning: ‘bestpos’ may be used uninitialized in this
> function
> 
> Thanks to Moritz Barsnick for first bringing this to the attention.
> 
> Signed-off-by: LiuQi 
> ---
>  tests/audiomatch.c |8 
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/audiomatch.c b/tests/audiomatch.c
> index 9752f68..9fb511f 100644
> --- a/tests/audiomatch.c
> +++ b/tests/audiomatch.c
> @@ -37,11 +37,11 @@ int main(int argc, char **argv){
>  FILE *f[2];
>  int i, pos;
>  int siglen, datlen;
> -int bestpos;
> +int bestpos = 0;

> -double bestc=0;
> -double sigamp= 0;
> +double bestc = 0;
> +double sigamp = 0;
>  int16_t *signal, *data;
> -int maxshift= 16384;
> +int maxshift = 16384;

unrelated changes
(these belong in a seperate patch)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: Remove ancient heuristic hack

[Michael Niedermayer]

On Wed, Aug 24, 2016 at 03:55:24PM +0100, Derek Buitenhuis wrote:
> This breaks files with legitimate single-entry edit lists,
> and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
> has no link to any known sample in its commit message, nor
> does it actually fix the problem properly, but instead has
> a one-off heuristic to try and "fix" them at the expense
> of breaking legitimate files.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
> Let's get this out of the way first: I'm not 'returning to FFmpeg'.
> 
> I do not intend to be involved in the community again, nor its
> overall direction and discussions, short of a miracle occurring
> at VideoLAN Dev Days.
> 
> Let's please keep this to technical repleis only. I will ignore
> anything else.
> 
> I am sending this patch in a professional context, as it is
> a problem I have run into at work, with legitimate files,
> produced by x264 and L-SMASH.
> 
> Example file:
> http://chromashift.org/samples/delay_problem.mp4
> 
> Having the DTS delay output on the first packet itself
> is important for things like cutting files.
> 
> The behavioral change can be seen with:
> $ ffprobe -show_packets delay_problem.mp4
> 
> Lastly, I would appreciate it if any replies to this patch set
> use 'Reply All', to CC me directly, because I am not currently
> subscribed to this mailing list, and getting proper IDs to use
> in the In-Reply-To field isn't easy now that Gmane is dead.
> 
> Cheers,
> - Derek
> ---
>  libavformat/mov.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 1bc3800..54c63ad 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2802,12 +2802,8 @@ static void mov_build_index(MOVContext *mov, AVStream 
> *st)
>  sc->time_offset = start_time - empty_duration;
>  current_dts = -sc->time_offset;
>  if (sc->ctts_count>0 && sc->stts_count>0 &&
> -sc->ctts_data[0].duration / FFMAX(sc->stts_data[0].duration, 
> 1) > 16) {
> -/* more than 16 frames delay, dts are likely wrong
> -   this happens with files created by iMovie */
> -sc->wrong_dts = 1;
> +sc->ctts_data[0].duration / FFMAX(sc->stts_data[0].duration, 
> 1) > 16)
>  st->codecpar->video_delay = 1;
> -}

IIRC the removed code tried to detect a reorder delay that is not
possible in a valid file due to the profile constraints. Aka dts and
pts are too far appart for the largest amount of buffers allowed in
any codec.
Quite possibly this limit or the check itself have become wrong
over time ...
Its even possible there has been some misunderstanding in the buffer
cts/pts/dts limitations.

patch probably ok
iam a bit unsure about "st->codecpar->video_delay = 1;" though


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Oliver Collyer]

> On 24 Aug 2016, at 20:57, Carl Eugen Hoyos  wrote:
> 
> Hi!
> 
> 2016-08-24 10:00 GMT+02:00 Oliver Collyer :
>> I’m not sure what would happen - currently the nvenc.c code enforces
>> 10-bit encoding when it gets a 10-bit input pixel format.
> 
> Yes, my question was about what happens if you remove the enforcement /
> force an 8bit profile.
> 

Ok, I’ve been doing some testing.

I have a single test file which is in yuv420p pixel format and has file size 
42,730KB.

I then ran different combinations of -pix_fmt and -profile:v while setting the 
encoder to a constant global quality of 21.

1. pix_fmt = yuv420p and profile is main => output file size 79,769KB
2. pix_fmt = yuv420p and profile is main10 => output file size 79,769KB

Although the file sizes of 1. and 2. are identical, the md5s were not. VLC 
reports both as “Planar YUV 420”, ffprobe reports 1. as having Main profile and 
2. as having Main 10 profile. I suspect this internal labelling is what 
accounts for the md5 difference.

3. pix_fmt = yuv444p16 and profile is main => output file size 72,279KB
4. pix_fmt = yuv444p16 and profile is main10 => output file size 72,279KB

Both file sizes and md5s of 3. and 4. are identical. VLC reports both as 
“Planar YUV 444 10-bit LE”. ffprobe reports both as having Rext profile (why 
not Main 10 I wonder?)

In summary (and this ties-in with the NVidia documentation which details the 
steps for 10-bit encoding):

a) to get 10-bit encoding you need to set up a 10-bit input buffer.
b) if you force an 8-bit profile but give the encoder a 10-bit input buffer it 
treats it as a 10-bit profile
c) you can get some nice savings by converting an 8-bit input to 10-bits and 
encoding in 10-bits, although this comes at the expense of CPU processing when 
doing the 8-bit to 10-bit conversion of the input pixel format.

Regards

Oliver

> And of course if it is possible to encode 10bit with 8bit input?
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Michael Niedermayer]

On Wed, Aug 24, 2016 at 09:40:55PM +0800, Steven Liu wrote:
> 2016-08-24 19:14 GMT+08:00 Steven Liu :
> 
> >
> >
> > 2016-08-24 18:57 GMT+08:00 Michael Niedermayer :
> >
> >> On Wed, Aug 24, 2016 at 06:28:08PM +0800, Steven Liu wrote:
> >> > 2016-08-24 18:23 GMT+08:00 Michael Niedermayer  >> >:
> >> >
> >> > > On Wed, Aug 24, 2016 at 03:04:59PM +0800, Steven Liu wrote:
> >> > > > On OSX test:
> >> > > > localhost:ffmpeg liuqi$ uname -a
> >> > > > Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19
> >> 18:36:36
> >> > > > PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
> >> > > > localhost:ffmpeg liuqi$ make fate-filter-hls-append
> >> > > > HOSTCC tests/base64.o
> >> > > > HOSTLD tests/base64
> >> > > > HOSTCC tests/tiny_psnr.o
> >> > > > HOSTLD tests/tiny_psnr
> >> > > > HOSTCC tests/tiny_ssim.o
> >> > > > HOSTLD tests/tiny_ssim
> >> > > > HOSTCC tests/audiomatch.o
> >> > > > tests/audiomatch.c:102:12: warning: using floating point absolute
> >> value
> >> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> >> > > > if(fabs(c) > sigamp * 0.94)
> >> > > >^
> >> > > > tests/audiomatch.c:102:12: note: use function 'llabs' instead
> >> > > > if(fabs(c) > sigamp * 0.94)
> >> > > >^~~~
> >> > > >llabs
> >> > > > tests/audiomatch.c:103:40: warning: using floating point absolute
> >> value
> >> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> >> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >> > > >^
> >> > > > tests/audiomatch.c:103:40: note: use function 'abs' instead
> >> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >> > > >^~~~
> >> > > >abs
> >> > > > tests/audiomatch.c:25:28: note: expanded from macro 'FFMIN'
> >> > > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> >> > > >^
> >> > > > tests/audiomatch.c:103:40: warning: using floating point absolute
> >> value
> >> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> >> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >> > > >^
> >> > > > tests/audiomatch.c:103:40: note: use function 'abs' instead
> >> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
> >> > > >^~~~
> >> > > >abs
> >> > > > tests/audiomatch.c:25:34: note: expanded from macro 'FFMIN'
> >> > > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
> >> > > >  ^
> >> > > > tests/audiomatch.c:104:12: warning: using floating point absolute
> >> value
> >> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
> >> > > > if(fabs(c)>fabs(bestc)){
> >> > > >^
> >> > > > tests/audiomatch.c:104:12: note: use function 'llabs' instead
> >> > > > if(fabs(c)>fabs(bestc)){
> >> > > >^~~~
> >> > > >llabs
> >> > > > 4 warnings generated.
> >> > > > HOSTLD tests/audiomatch
> >> > > > GEN tests/data/hls-list-append.m3u8
> >> > > > TESTfilter-hls-append
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Linux Test:
> >> > > > [root@localhost ffmpeg]# make fate-filter-hls-append
> >> > > > HOSTCC tests/base64.o
> >> > > > HOSTLD tests/base64
> >> > > > HOSTCC tests/tiny_psnr.o
> >> > > > HOSTLD tests/tiny_psnr
> >> > > > HOSTCC tests/tiny_ssim.o
> >> > > > HOSTLD tests/tiny_ssim
> >> > > > HOSTCC tests/audiomatch.o
> >> > > > tests/audiomatch.c: 在函数‘main’中:
> >> > > > tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
> >> > > > HOSTLD tests/audiomatch
> >> > > > GEN tests/data/hls-list-append.m3u8
> >> > > > TESTfilter-hls-append
> >> > > > [root@localhost ffmpeg]# uname -a
> >> > > > Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
> >> > > > 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> >> > >
> >> > > fails with mingw
> >> > > ../configure  --cc='ccache i686-w64-mingw32-gcc'  --samples=...
> >> --arch=x86
> >> > > --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-gpl
> >> > > --pkg-config=./pig-config --target_exec=wine
> >> > >
> >> > > ...
> >> > > +0, 873216, 873216, 1152, 2304, 0x823b822c
> >> > > +0, 874368, 874368, 1152, 2304, 0xa1658479
> >> > > +0, 875520, 875520, 1152, 2304, 0xdbe58ff7
> >> > > +0, 876672, 876672, 1152, 2304, 0x725175e2
> >> > > +0, 877824, 877824, 1152, 2304, 0xb2ae7741
> >> > > +0, 878976, 878976, 1152, 2304, 0x4de169e4
> >> > > +0, 880128, 880128, 1152, 2304, 0x3cb18530
> >> > > +0, 881280, 881280, 1152, 2304, 0x48b95d6c
> >> > > +0, 882432, 882432, 1152,

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Andy Furniss]

Davinder Singh wrote:

On Tue, Aug 23, 2016 at 5:38 AM Andy Furniss 
wrote:


[...]

Nice I can see the edges are better than the last version.

The doc/filters.texi hunk doesn't apply to git master.

I was going to post some comparisons with mcfps tonight, but I'll
need to redo them to see what's changed.


I am testing with a somewhat artificial sample in that it's a framerate
de-interlace + scale down of a 1080i master, though it is "real" in the
sense that I may want to repair similar files where people have produced
a juddery mess by using yadif=0.

It's very fast and my old (2010 Panasonic plasma) TV can't interpolate
it without artifacting in a few places, it can interpolate a field rate
version flawlessly and both mcfps and minterpolate do a lot better with
a 50fps master version -> 100fps, though they are still not perfect.

As well as being fast it has overlays of varying opacity and some
repeating patterns just to make things even harder.

Some observations while trying to get the best result - given the number
of options only a small subset could be tested:

aobmc vs ombc, vsbmc 0 or 1 = no real difference.

Any me method other than epzs had far too many artifacts to be used.

Raising search_param to 48 or 64 or 128 just causes new artifacts.

Reducing mb_size causes new artifacts.

bilat vs bidir - similar but bilat has some artifacts on a still shot
near the end of the defaults sample uploaded. bidir sometimes has green
near the top of the screen.

There are of course many small artifacts, to be seen by slowmo/framestep
for both minterpolate and mcfps. Viewing fullspeed mcfps artifacts less
on the car when it touches the edges than minterpolate. Frame stepping
shows mcfps doesn't blend/blur as much on really fast moving background
as minterpolate does.

Included in the link below (which is a tar to stop google drive making
terrible low quality/fps previews) are the 25fps master file, mcfps
interpolation to 50fps, minterpolate with default options and
minterpolate with defaults + bidir.

https://drive.google.com/file/d/0BxP5-S1t9VEEM2VrTzlVdGZURVk/view?usp=sharing
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Carl Eugen Hoyos]

2016-08-24 23:24 GMT+02:00 Oliver Collyer :

> In summary (and this ties-in with the NVidia documentation which
> details the steps for 10-bit encoding):
>
> a) to get 10-bit encoding you need to set up a 10-bit input buffer.

Thank you for the tests!

No more comments from me, I cannot test.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.

[Michael Niedermayer]

On Wed, Aug 24, 2016 at 06:42:16PM -0700, Sasi Inguva wrote:
> hmm. strange. I just rebased my branch on top of head, and reran the test,
> and it succeeds along with all other fate tests. I am attaching the 4
> patches again here.

you need to build with
--assert-level=2
to see the failure

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

[liu jc]

It is not a ios hack,  It compatible with any system that in accordance with 
the POSIX standards. The second parameter of function getaddrinfo  can accept 
the port name or a service name. If you give a service name to it it will 
translate it to a  standard port number.



发件人: ffmpeg-devel  代表 compn 
发送时间: 2016年8月24日 2:57
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

On Wed, 24 Aug 2016 01:03:00 +
liu jc  wrote:

>
>  there is a bug when useing getaddrinfo in IOS when use

if this is an IOS hack, it should be ifdef'd?

also i thought we had a policy against putting os bugfixes in our
codebase? although i dislike this policy...


> -snprintf(portstr, sizeof(portstr), "%d", port);
> +
> +   switch (port) {
> +case 80:
> +snprintf(portstr, sizeof(portstr), "%s", "http");
> +break;
> +case 1935:
> +snprintf(portstr, sizeof(portstr), "%s",
> "macromedia-fcs"); //know as rtmp
> +break;
> +default:
> +snprintf(portstr, sizeof(portstr), "%d", port);
> +break;

so only 80, 1935 ? rtmp uses some other ports too. 443 etc.

i am not against patch, i hope there is a way to fix this.

do we have any apple contacts to report this bug?
is it possible to use a different getaddrinfo on ios?

thanks for patch.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 18/21] libavformat/movenc: mov_write_audio_tag writes the proper number of channels, not the hardcoded 2

[Erkki Seppälä]

On 08/23/2016 06:20 PM, Yusuke Nakamura wrote:

-avio_wb16(pb, 2);
+avio_wb16(pb, track->par->channels);

No. the ChannelCount field is templated. It may be fixed to 2 by derived
specs or the specs of codec encapsulations. I mean the current
implemetation is wrong, and your implementation is also wrong. For
instance, ChannelCount of AC-3 in ISOBMFF is always hardcoded to 2 even if
5.1ch. This field is basically not useful for ISOBMFF and the actual
channels shall be referred to Codec specific info.


It seems the part of the standard didn't give the full view on the 
matter. This patch can be dropped.


Thanks for the review!

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 答复: 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

[liu jc]

Yes you can. But if you are in the IPv6 only network and use a hardcode IPv4 
address ,in latest IOS version if you just use a port number as the second 
parameter of function getaddrinfo, you will get a connection fail when you 
connect to you server.



发件人: ffmpeg-devel  代表 Steven Liu 

发送时间: 2016年8月24日 2:46
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

2016-08-24 10:40 GMT+08:00 liu jc :

> this  patch just deal with the standard condition (most people use 1935).
> Although you still can use  the port and service map in mac (/etc/services)
> to cheat. If you rtmp server listen 1936 following the mac services list
> you can just pass a
>
> service name "jetcmeserver" then you tcp connection can establish
> successful.  But for not resulting ambiguity it is recommend use standard
> port number for specific service.
>
But without this patch, i can publish stream to rtmp server listening 1936
or other.

>
>
> 
> 发件人: ffmpeg-devel  代表 Steven Liu <
> lingjiujia...@gmail.com>
> 发送时间: 2016年8月24日 1:34
> 收件人: FFmpeg development discussions and patches
> 主题: Re: [FFmpeg-devel] [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix
>
> 2016-08-24 9:03 GMT+08:00 liu jc :
>
> >
> >  there is a bug when useing getaddrinfo in IOS when use
> >  hardcode IPv4 address and in IPv6-only networks.It can not
> >  accept a port number as second parameter as an alternative
> >  you can pass a service name  or it will cause connect fail.
> >  In current video CDN dispatching mechanism the hardcode
> >  IPv4 is widly used for better performance. This problem
> >  cause many APP use ffmpeg to play this type CDN dispatched
> >  video were rejected by APP store. This patch fix this by
> >  adding a port to name map for widly used port number that
> >  these CDN use to dispatch video.
> >
> > ---
> >  libavformat/tcp.c |   17 +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> >  mode change 100644 => 100755 libavformat/tcp.c
> >
> > diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> > old mode 100644
> > new mode 100755
> > index c105479..0de7710
> > --- a/libavformat/tcp.c
> > +++ b/libavformat/tcp.c
> > @@ -72,7 +72,7 @@ static int tcp_open(URLContext *h, const char *uri, int
> > flags)
> >  char buf[256];
> >  int ret;
> >  char hostname[1024],proto[1024],path[1024];
> > -char portstr[10];
> > +char portstr[64];
> >  s->open_timeout = 500;
> >
> >  av_url_split(proto, sizeof(proto), NULL, 0, hostname,
> > sizeof(hostname),
> > @@ -105,7 +105,19 @@ static int tcp_open(URLContext *h, const char *uri,
> > int flags)
> >  }
> >  hints.ai_family = AF_UNSPEC;
> >  hints.ai_socktype = SOCK_STREAM;
> > -snprintf(portstr, sizeof(portstr), "%d", port);
> > +
> > +   switch (port) {
> > +case 80:
> > +snprintf(portstr, sizeof(portstr), "%s", "http");
> > +break;
> > +case 1935:
> > +snprintf(portstr, sizeof(portstr), "%s", "macromedia-fcs");
> > //know as rtmp
> >
> i have one quetion: When the rtmp server listen the port 1936, what about
> the portstr?
>
> > +break;
> > +default:
> > +snprintf(portstr, sizeof(portstr), "%d", port);
> > +break;
> > +}
> > +
> >  if (s->listen)
> >  hints.ai_flags |= AI_PASSIVE;
> >  if (!hostname[0])
> > @@ -268,3 +280,4 @@ const URLProtocol ff_tcp_protocol = {
> >  .flags   = URL_PROTOCOL_FLAG_NETWORK,
> >  .priv_data_class = _class,
> >  };
> > +
> >
> delete this line.
>
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...



> ffmpeg-devel Info Page
> ffmpeg.org
> This list is about FFmpeg development discussions and patches; but not for
> bug-reports. Please read the Code-of-conduct. To see the collection of
> prior postings to ...
>
>
>
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Steven Liu]

On OSX test:
localhost:ffmpeg liuqi$ uname -a
Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36
PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
localhost:ffmpeg liuqi$ make fate-filter-hls-append
HOSTCC tests/base64.o
HOSTLD tests/base64
HOSTCC tests/tiny_psnr.o
HOSTLD tests/tiny_psnr
HOSTCC tests/tiny_ssim.o
HOSTLD tests/tiny_ssim
HOSTCC tests/audiomatch.o
tests/audiomatch.c:102:12: warning: using floating point absolute value
function 'fabs' when argument is of integer type [-Wabsolute-value]
if(fabs(c) > sigamp * 0.94)
   ^
tests/audiomatch.c:102:12: note: use function 'llabs' instead
if(fabs(c) > sigamp * 0.94)
   ^~~~
   llabs
tests/audiomatch.c:103:40: warning: using floating point absolute value
function 'fabs' when argument is of integer type [-Wabsolute-value]
maxshift = FFMIN(maxshift, fabs(pos)+32);
   ^
tests/audiomatch.c:103:40: note: use function 'abs' instead
maxshift = FFMIN(maxshift, fabs(pos)+32);
   ^~~~
   abs
tests/audiomatch.c:25:28: note: expanded from macro 'FFMIN'
#define FFMIN(a,b) ((a) > (b) ? (b) : (a))
   ^
tests/audiomatch.c:103:40: warning: using floating point absolute value
function 'fabs' when argument is of integer type [-Wabsolute-value]
maxshift = FFMIN(maxshift, fabs(pos)+32);
   ^
tests/audiomatch.c:103:40: note: use function 'abs' instead
maxshift = FFMIN(maxshift, fabs(pos)+32);
   ^~~~
   abs
tests/audiomatch.c:25:34: note: expanded from macro 'FFMIN'
#define FFMIN(a,b) ((a) > (b) ? (b) : (a))
 ^
tests/audiomatch.c:104:12: warning: using floating point absolute value
function 'fabs' when argument is of integer type [-Wabsolute-value]
if(fabs(c)>fabs(bestc)){
   ^
tests/audiomatch.c:104:12: note: use function 'llabs' instead
if(fabs(c)>fabs(bestc)){
   ^~~~
   llabs
4 warnings generated.
HOSTLD tests/audiomatch
GEN tests/data/hls-list-append.m3u8
TESTfilter-hls-append




On Linux Test:
[root@localhost ffmpeg]# make fate-filter-hls-append
HOSTCC tests/base64.o
HOSTLD tests/base64
HOSTCC tests/tiny_psnr.o
HOSTLD tests/tiny_psnr
HOSTCC tests/tiny_ssim.o
HOSTLD tests/tiny_ssim
HOSTCC tests/audiomatch.o
tests/audiomatch.c: 在函数‘main’中:
tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
HOSTLD tests/audiomatch
GEN tests/data/hls-list-append.m3u8
TESTfilter-hls-append
[root@localhost ffmpeg]# uname -a
Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux



2016-08-24 14:18 GMT+08:00 Steven Liu :

> make fate pass on
>
> Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36
> PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
>
> and
>
> Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
> 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>
>
>
> add tests/ref/fate/filter-hls-append for FATE
> add hls-list-append fate use filter make audio data and test hls_flags
> append options
>
> Signed-off-by: LiuQi 
> ---
>  tests/fate/filter-audio.mak  |   13 +
>  tests/ref/fate/filter-hls-append | 1156 ++
> 
>  2 files changed, 1169 insertions(+)
>  create mode 100644 tests/ref/fate/filter-hls-append
>
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index d1d9d59..b7297ac 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-audio.mak
> @@ -143,6 +143,19 @@ FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER
> MPEGTS_DEMUXER AEVALSRC_FIL
>  fate-filter-hls: tests/data/hls-list.m3u8
>  fate-filter-hls: CMD = framecrc -flags +bitexact -i
> $(TARGET_PATH)/tests/data/hls-list.m3u8
>
> +tests/data/hls-list-append.m3u8: TAG = GEN
> +tests/data/hls-list-append.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
> +   $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
> +-f lavfi -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t)::d=20"
> -f segment -segment_time 10 -map 0 -flags +bitexact -codec:a mp2fixed \
> +-segment_list $(TARGET_PATH)/$@ -y 
> $(TARGET_PATH)/tests/data/hls-append-out-%03d.ts
> 2>/dev/null; \
> +$(TARGET_PATH)/ffmpeg -f lavfi -i 
> "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t)::d=20"
> -f hls -hls_time 10 -map 0 -flags +bitexact \
> +-hls_flags append_list -codec:a mp2fixed -hls_segment_filename
> $(TARGET_PATH)/tests/data/hls-append-out-%03d.ts \
> +$(TARGET_PATH)/tests/data/hls-list-append.m3u8 2>/dev/null
> +
> +FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER
> AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-filter-hls-append
> +fate-filter-hls-append: 

Re: [FFmpeg-devel] 答复: 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

[Steven Liu]

2016-08-24 15:19 GMT+08:00 liu jc :

> Yes you can. But if you are in the IPv6 only network and use a hardcode
> IPv4 address ,in latest IOS version if you just use a port number as the
> second parameter of function getaddrinfo, you will get a connection fail
> when you connect to you server.
>
> I think you have fixed a bug, but make some new bug with this patch,
Why don't fix the protocol by default work flow?

>
> 
> 发件人: ffmpeg-devel  代表 Steven Liu <
> lingjiujia...@gmail.com>
> 发送时间: 2016年8月24日 2:46
> 收件人: FFmpeg development discussions and patches
> 主题: Re: [FFmpeg-devel] 答复: [PATCH] IOS-IPv6-only-network-use-
> hardcode-IPv4-fix
>
> 2016-08-24 10:40 GMT+08:00 liu jc :
>
> > this  patch just deal with the standard condition (most people use 1935).
> > Although you still can use  the port and service map in mac
> (/etc/services)
> > to cheat. If you rtmp server listen 1936 following the mac services list
> > you can just pass a
> >
> > service name "jetcmeserver" then you tcp connection can establish
> > successful.  But for not resulting ambiguity it is recommend use standard
> > port number for specific service.
> >
> But without this patch, i can publish stream to rtmp server listening 1936
> or other.
>
> >
> >
> > 
> > 发件人: ffmpeg-devel  代表 Steven Liu <
> > lingjiujia...@gmail.com>
> > 发送时间: 2016年8月24日 1:34
> > 收件人: FFmpeg development discussions and patches
> > 主题: Re: [FFmpeg-devel] [PATCH] IOS-IPv6-only-network-use-
> hardcode-IPv4-fix
> >
> > 2016-08-24 9:03 GMT+08:00 liu jc :
> >
> > >
> > >  there is a bug when useing getaddrinfo in IOS when use
> > >  hardcode IPv4 address and in IPv6-only networks.It can not
> > >  accept a port number as second parameter as an alternative
> > >  you can pass a service name  or it will cause connect fail.
> > >  In current video CDN dispatching mechanism the hardcode
> > >  IPv4 is widly used for better performance. This problem
> > >  cause many APP use ffmpeg to play this type CDN dispatched
> > >  video were rejected by APP store. This patch fix this by
> > >  adding a port to name map for widly used port number that
> > >  these CDN use to dispatch video.
> > >
> > > ---
> > >  libavformat/tcp.c |   17 +++--
> > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > >  mode change 100644 => 100755 libavformat/tcp.c
> > >
> > > diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> > > old mode 100644
> > > new mode 100755
> > > index c105479..0de7710
> > > --- a/libavformat/tcp.c
> > > +++ b/libavformat/tcp.c
> > > @@ -72,7 +72,7 @@ static int tcp_open(URLContext *h, const char *uri,
> int
> > > flags)
> > >  char buf[256];
> > >  int ret;
> > >  char hostname[1024],proto[1024],path[1024];
> > > -char portstr[10];
> > > +char portstr[64];
> > >  s->open_timeout = 500;
> > >
> > >  av_url_split(proto, sizeof(proto), NULL, 0, hostname,
> > > sizeof(hostname),
> > > @@ -105,7 +105,19 @@ static int tcp_open(URLContext *h, const char
> *uri,
> > > int flags)
> > >  }
> > >  hints.ai_family = AF_UNSPEC;
> > >  hints.ai_socktype = SOCK_STREAM;
> > > -snprintf(portstr, sizeof(portstr), "%d", port);
> > > +
> > > +   switch (port) {
> > > +case 80:
> > > +snprintf(portstr, sizeof(portstr), "%s", "http");
> > > +break;
> > > +case 1935:
> > > +snprintf(portstr, sizeof(portstr), "%s",
> "macromedia-fcs");
> > > //know as rtmp
> > >
> > i have one quetion: When the rtmp server listen the port 1936, what about
> > the portstr?
> >
> > > +break;
> > > +default:
> > > +snprintf(portstr, sizeof(portstr), "%d", port);
> > > +break;
> > > +}
> > > +
> > >  if (s->listen)
> > >  hints.ai_flags |= AI_PASSIVE;
> > >  if (!hostname[0])
> > > @@ -268,3 +280,4 @@ const URLProtocol ff_tcp_protocol = {
> > >  .flags   = URL_PROTOCOL_FLAG_NETWORK,
> > >  .priv_data_class = _class,
> > >  };
> > > +
> > >
> > delete this line.
> >
> > > --
> > > 1.7.9.5
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ffmpeg-devel Info Page
> ffmpeg.org
> This list is about FFmpeg development discussions and patches; but not for
> bug-reports. Please read the Code-of-conduct. To see the collection of
> prior postings to ...
>
>
>
> > ffmpeg-devel Info Page
> > ffmpeg.org
> > This list is about FFmpeg development discussions and patches; but not
> for
> > bug-reports. Please read the Code-of-conduct. To see the collection of
> > prior postings to ...
> >
> >
> >
> > >
> > 

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Oliver Collyer]

> On 24 Aug 2016, at 08:31, Carl Eugen Hoyos  wrote:
> 
> Hi!
> 
> 2016-08-23 22:22 GMT+02:00 Oliver Collyer :
>>> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos  wrote:
>>> 2016-08-23 19:10 GMT+02:00 Oliver Collyer :
 +AV_PIX_FMT_YUV420P10LE,
>>> 
>>> I know this is theoretical but the Nvidia header seems to indicate
>>> native endianness to me, so this should be AV_PIX_FMT_YUV420P10
>>> 
 +AV_PIX_FMT_YUV444P10LE
>>> 
>>> But after reading the rest of the patch:
>>> Shouldn't this be AV_PIX_FMT_YUV444P16?
>> 
>> How so - the Nvidia doc is stating that the encoder is taking 10 bits per
>> component, not 16?
> 
> AV_PIX_FMT_YUV444P16 should not need any conversion and therefore
> be measurably faster, the least significant bits are ignored.
> Please test and report back.
> 

Yes, I can confirm AV_PIX_FMT_YUV444P16 works fine so I can now ditch the 
conversion and do a straight plane copy.

Thanks

Oliver

> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Oliver Collyer]

> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos  wrote:
> 
> Hi!
> 
> 2016-08-23 19:10 GMT+02:00 Oliver Collyer :
>> +AV_PIX_FMT_YUV420P10LE,
> 
> I know this is theoretical but the Nvidia header seems to indicate
> native endianness to me, so this should be AV_PIX_FMT_YUV420P10
> 
>> +AV_PIX_FMT_YUV444P10LE
> 
> But after reading the rest of the patch:
> Shouldn't this be AV_PIX_FMT_YUV444P16?
> 
> And instead of YUV420P10, shouldn't you use P010LE?
> 

So I’ve tried with P010 but ran into a problem in that this pixel format is 
only supported as an input format.

In my test I’m reading a yuv420p file and then specifying -pix_fmt P010 but 
this is giving an error message saying the conversion is impossible. ffmpeg 
-pix_fmts confirms it is only valid as an input format.

Of course, if the source is P010 then presumably there is no problem.

What should I do? Maybe support both P010 so that if someone has a source in 
this format it can be encoded natively but also support YUV420P10 with my 
conversion/shifting routine?

Or should I just support P010 and then consider it a limitation of FFmpeg that 
it cannot convert a different format to this one?

Regards

Oliver

> In any case, please split the rate control patch from the 10bit patch.
> 
> Carl Eugen
> 
> who wonders now how the Microsoft headers define the ten bit
> yuv420 semi-planar format...
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 03/21] libavformat/movenc: added ability to use original stream ids as track i ds instead of regenerating them

[Erkki Seppälä]

On 08/23/2016 10:21 PM, Carl Eugen Hoyos wrote:

2016-08-23 11:03 GMT+02:00  :

+/** Assign track ids. If use_stream_ids_as_track_ids is set, the
+stream ids are used as track ids special case is taken to generate
+track ids for generated tracks, which don't have a 1:1 stream to
+copy the stream id from. This the order of tracks is the same in
+both mov->tracks and s->streams (and no holes). */


The last sentence is missing an important word, I think.


In fact probably the whole paragraph needs some rewriting :). Thanks for 
review!


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 13/21] libavformat/mov: basic support for identifying (and reading) timed metadata

[Erkki Seppälä]

On 08/23/2016 10:18 PM, Carl Eugen Hoyos wrote:

2016-08-23 11:03 GMT+02:00  :

+if (id <= 0 &&
+st->codecpar->codec_type == AVMEDIA_TYPE_DATA) {
+id = ff_codec_get_id(ff_codec_metadata_tags, format);
+if (id > 0)



+st->codecpar->codec_type = AVMEDIA_TYPE_DATA;


Is it just me or is this a no-op?


You would be correct. Not only it is never executed, but even if it 
were, it would do nothing :). (I imagine I 
copy-paste-search-and-replaced from the one above it and the editing 
missed this.)


Thanks for review!

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Carl Eugen Hoyos]

Hi!

2016-08-24 9:41 GMT+02:00 Oliver Collyer :
>
>> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos  wrote:
>>
>> 2016-08-23 19:10 GMT+02:00 Oliver Collyer :
>>> +AV_PIX_FMT_YUV420P10LE,
>>
>> I know this is theoretical but the Nvidia header seems to indicate
>> native endianness to me, so this should be AV_PIX_FMT_YUV420P10
>>
>>> +AV_PIX_FMT_YUV444P10LE
>>
>> But after reading the rest of the patch:
>> Shouldn't this be AV_PIX_FMT_YUV444P16?

(Thanks for testing this!)

>> And instead of YUV420P10, shouldn't you use P010LE?
>>
>
> So I’ve tried with P010 but ran into a problem in that this pixel format is
> only supported as an input format.
>
> In my test I’m reading a yuv420p file and then specifying -pix_fmt P010
> but this is giving an error message saying the conversion is impossible.
> ffmpeg -pix_fmts confirms it is only valid as an input format.

Sorry for not realizing this originally!

> Of course, if the source is P010 then presumably there is no problem.

> What should I do? Maybe support both P010 so that if someone has a
> source in this format it can be encoded natively but also support
> YUV420P10 with my conversion/shifting routine?
>
> Or should I just support P010 and then consider it a limitation of FFmpeg
> that it cannot convert a different format to this one?

Imo, both are ok (and the first obviously makes more sense) but wait for
> others to comment.

The ideal solution is of course if you port your conversion routine to
libswscale
(but this will need a little effort I guess and should imo not block
your patch).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Carl Eugen Hoyos]

Hi!

2016-08-24 8:43 GMT+02:00 Oliver Collyer :
> Yes, I can confirm AV_PIX_FMT_YUV444P16 works fine so I can
> now ditch the conversion and do a straight plane copy.

I am curious: If you feed the encoder with
NV_ENC_BUFFER_FORMAT_YUV444_10BIT can you still
select 8bit encoding? Is this technically possible or not?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Oliver Collyer]

> On 24 Aug 2016, at 10:50, Carl Eugen Hoyos  wrote:
> 
> Hi!
> 
> 2016-08-24 9:41 GMT+02:00 Oliver Collyer :
>> 
>>> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos  wrote:
>>> 
>>> 2016-08-23 19:10 GMT+02:00 Oliver Collyer :
 +AV_PIX_FMT_YUV420P10LE,
>>> 
>>> I know this is theoretical but the Nvidia header seems to indicate
>>> native endianness to me, so this should be AV_PIX_FMT_YUV420P10
>>> 
 +AV_PIX_FMT_YUV444P10LE
>>> 
>>> But after reading the rest of the patch:
>>> Shouldn't this be AV_PIX_FMT_YUV444P16?
> 
> (Thanks for testing this!)
> 
>>> And instead of YUV420P10, shouldn't you use P010LE?
>>> 
>> 
>> So I’ve tried with P010 but ran into a problem in that this pixel format is
>> only supported as an input format.
>> 
>> In my test I’m reading a yuv420p file and then specifying -pix_fmt P010
>> but this is giving an error message saying the conversion is impossible.
>> ffmpeg -pix_fmts confirms it is only valid as an input format.
> 
> Sorry for not realizing this originally!
> 
>> Of course, if the source is P010 then presumably there is no problem.
> 
>> What should I do? Maybe support both P010 so that if someone has a
>> source in this format it can be encoded natively but also support
>> YUV420P10 with my conversion/shifting routine?
>> 
>> Or should I just support P010 and then consider it a limitation of FFmpeg
>> that it cannot convert a different format to this one?
> 
> Imo, both are ok (and the first obviously makes more sense) but wait for
>> others to comment.
> 
> The ideal solution is of course if you port your conversion routine to
> libswscale
> (but this will need a little effort I guess and should imo not block
> your patch).
> 

Ok, I’ll wait for more feedback.

There is a certain logic in supporting both since the patch then neatly adds 
10-bit support for all the existing 8-bit formats it currently supports:

i.e. currently it supports...

YUV420P
NV12
YUV444P

…which would become

YUV420P
YUV420P10
NV12
P010
YUV444P
YUV444P16

This appeals to my sense of symmetry :)

Regards

Oliver

> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] 答复: [PATCH] IOS-IPv6-only-network-use-hardcode-IPv4-fix

[Michael Niedermayer]

On Wed, Aug 24, 2016 at 07:15:29AM +, liu jc wrote:
> It is not a ios hack,  It compatible with any system that in accordance with 
> the POSIX standards. The second parameter of function getaddrinfo  can accept 
> the port name or a service name. If you give a service name to it it will 
> translate it to a  standard port number.

POSIX says this:

http://pubs.opengroup.org/onlinepubs/009695399/functions/freeaddrinfo.html

"If servname is null, the call shall return network-level addresses for the 
specified nodename. If servname is not null, it is a null-terminated character 
string identifying the requested service. This can be either a descriptive name 
or a numeric representation suitable for use with the address family or 
families. If the specified address family is AF_INET, [IP6] [Option Start]  
AF_INET6, [Option End] or AF_UNSPEC, the service can be specified as a string 
specifying a decimal port number."

so port numbers are required to be supported by POSIX
some IOS version fails with that,
that IOS version is buggy, the bug in fact seems known and has been
fixed already IIUC
also see
http://stackoverflow.com/questions/37386161/service-port-is-missed-when-using-getaddrinfo-to-convert-ipv4-addr-to-ipv6-addr

also macromedia-fcs is not in my /etc/services so your patch
would break POSIX systems

If you wish to workaround a IOS bug i dont mind but that has to be
clean and work.
your patch half works on IOS (only 2 port numbers supported) and half
breaks POSIX systems


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Oliver Collyer]

> In any case, please split the rate control patch from the 10bit patch.
> 

Just double-checking this - both changes require a bump of the minimum NVENC 
version to 7. Do you still want them as separate patches or does this tie them 
together? If they are to be separate patches then obviously one of them will 
need to be applied first, so there is a dependency between them.

> Carl Eugen
> 
> who wonders now how the Microsoft headers define the ten bit
> yuv420 semi-planar format...
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Fix audiomatch complie warning

[Steven Liu]

Making sure bestpos is initialized to zero to prevent gcc from kvetching.
It's harmless (although it's not obvious that it's harmless)
from code inspection:
tests/audiomatch.c: In function ‘main’:
tests/audiomatch.c:40: warning: ‘bestpos’ may be used uninitialized in this
function

Thanks to Moritz Barsnick for first bringing this to the attention.

Signed-off-by: LiuQi 
---
 tests/audiomatch.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/audiomatch.c b/tests/audiomatch.c
index 9752f68..9fb511f 100644
--- a/tests/audiomatch.c
+++ b/tests/audiomatch.c
@@ -37,11 +37,11 @@ int main(int argc, char **argv){
 FILE *f[2];
 int i, pos;
 int siglen, datlen;
-int bestpos;
-double bestc=0;
-double sigamp= 0;
+int bestpos = 0;
+double bestc = 0;
+double sigamp = 0;
 int16_t *signal, *data;
-int maxshift= 16384;
+int maxshift = 16384;

 if (argc < 3) {
 printf("audiomatch  \n");
--
1.7.1


0001-Fix-audiomatch-complie-warning.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] af_hdcd: for easier maintenance alongside libhdcd

[Burt P]

Mostly just re-arranges some code to make it easier to update this
filter and libhdcd together. filter_frame() is much simpler as a
result.

* use the HDCD detection data structure and functions from libhdcd,
  moved detection code out of filter_frame()
* moved analyze_mode preparation out of filter_frame() into
  hdcd_analyze_prepare(), from libhdcd
* moved some macro definitions to the top so they are all together

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 271 --
 1 file changed, 172 insertions(+), 99 deletions(-)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 2324dc3..0360bc9 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -823,6 +823,20 @@ static const int32_t gaintab[] = {
 0x35fa26
 };
 
+#define HDCD_PROCESS_STEREO_DEFAULT 1
+#define HDCD_MAX_CHANNELS 2
+
+/** convert to float from 4-bit (3.1) fixed-point
+ *  the always-negative value is stored positive, so make it negative */
+#define GAINTOFLOAT(g) (g) ? -(float)(g>>1) - ((g & 1) ? 0.5 : 0.0) : 0.0
+
+/** apply gain, 11-bit (3.8) fixed point,
+ *  always negative but stored positive. */
+#define APPLY_GAIN(s,g) do{int64_t s64 = s; s64 *= gaintab[g]; s = 
(int32_t)(s64 >> 23); }while(0);
+
+/** tone generator: sample_number, frequency, sample_rate, amplitude */
+#define TONEGEN16(sn, f, sr, a) (int16_t)(sin((6.28318530718 * (sn) * (f)) 
/(sr)) * (a) * 0x7fff)
+
 typedef struct {
 uint64_t window;
 unsigned char readahead;
@@ -856,12 +870,14 @@ typedef struct {
 /** occurences of code detect timer expiring without detecting
  *  a code. -1 for timer never set. */
 int count_sustain_expired;
+
+int _ana_snb;   /**< used in the analyze mode tone generator */
 } hdcd_state_t;
 
 typedef enum {
-HDCD_PE_NEVER= 0,
-HDCD_PE_INTERMITTENT = 1,
-HDCD_PE_PERMANENT= 2,
+HDCD_PE_NEVER= 0, /**< All valid packets have PE set to off */
+HDCD_PE_INTERMITTENT = 1, /**< Some valid packets have PE set to on */
+HDCD_PE_PERMANENT= 2, /**< All valid packets have PE set to on  */
 } hdcd_pe_t;
 
 static const char * const pe_str[] = {
@@ -870,25 +886,51 @@ static const char * const pe_str[] = {
 "enabled permanently"
 };
 
-#define HDCD_PROCESS_STEREO_DEFAULT 1
-#define HDCD_MAX_CHANNELS 2
+typedef enum {
+HDCD_NONE= 0,  /**< HDCD packets do not (yet) appear  */
+HDCD_NO_EFFECT   = 1,  /**< HDCD packets appear, but all control codes 
are NOP */
+HDCD_EFFECTUAL   = 2,  /**< HDCD packets appear, and change the output 
in some way */
+} hdcd_detection_t;
 
-/** convert to float from 4-bit (3.1) fixed-point
- *  the always-negative value is stored positive, so make it negative */
-#define GAINTOFLOAT(g) (g) ? -(float)(g>>1) - ((g & 1) ? 0.5 : 0.0) : 0.0
+typedef enum {
+HDCD_PVER_NONE   = 0, /**< No packets (yet) discovered */
+HDCD_PVER_A  = 1, /**< Packets of type A (8-bit control) 
discovered */
+HDCD_PVER_B  = 2, /**< Packets of type B (8-bit control, 8-bit 
XOR) discovered */
+HDCD_PVER_MIX= 3, /**< Packets of type A and B discovered, most 
likely an encoding error */
+} hdcd_pf_t;
+
+static const char * const pf_str[] = {
+"?", "A", "B", "A+B"
+};
+
+typedef struct {
+hdcd_detection_t hdcd_detected;
+hdcd_pf_t packet_type;
+int total_packets; /**< valid packets */
+int errors;/**< detectable errors */
+hdcd_pe_t peak_extend;
+int uses_transient_filter;
+float max_gain_adjustment; /**< in dB, expected in the range -7.5 to 0.0 */
+int cdt_expirations;   /**< -1 for never set, 0 for set but never 
expired */
 
-#define HDCD_ANA_OFF 0
+int _active_count; /**< used internally */
+} hdcd_detection_data_t;
+
+typedef enum {
+HDCD_ANA_OFF= 0,
+HDCD_ANA_LLE= 1,
+HDCD_ANA_PE = 2,
+HDCD_ANA_CDT= 3,
+HDCD_ANA_TGM= 4,
+HDCD_ANA_TOP= 5, /**< used in max value of AVOption */
+} hdcd_ana_mode_t;
+
+/** analyze mode descriptions: macro for AVOption definitions, array of const 
char for mapping mode to string */
 #define HDCD_ANA_OFF_DESC "disabled"
-#define HDCD_ANA_LLE 1
 #define HDCD_ANA_LLE_DESC "gain adjustment level at each sample"
-#define HDCD_ANA_PE  2
 #define HDCD_ANA_PE_DESC  "samples where peak extend occurs"
-#define HDCD_ANA_CDT 3
 #define HDCD_ANA_CDT_DESC "samples where the code detect timer is active"
-#define HDCD_ANA_TGM 4
 #define HDCD_ANA_TGM_DESC "samples where the target gain does not match 
between channels"
-#define HDCD_ANA_TOP 5 /* used in max value of AVOption */
-
 static const char * const ana_mode_str[] = {
 HDCD_ANA_OFF_DESC,
 HDCD_ANA_LLE_DESC,
@@ -917,7 +959,6 @@ typedef struct HDCDContext {
  *  the amplitude to signal some specific aspect of the decoding
  *  process. See docs or HDCD_ANA_* defines. */
 int analyze_mode;
-int 

Re: [FFmpeg-devel] [PATCH 3/3] af_hdcd: for easier maintenance alongside libhdcd

[Burt P.]

On Tue, Aug 23, 2016 at 2:29 PM, Carl Eugen Hoyos  wrote:
> It seems safer to me to use the actual number of channels than the
> channel layout.

Alright, new patch version incoming.

-- 
Burt
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.

[Sasi Inguva]

ping!

On Fri, Aug 19, 2016 at 9:49 AM, Sasi Inguva  wrote:

> I don't know who the owner of MOV demuxer is. If somebody could do a
> deeper review of this patch and approve it that would be great.
>
> Thanks,
> Sasi
>
> On Wed, Aug 17, 2016 at 8:59 AM, Sasi Inguva  wrote:
>
>> Thanks
>>
>> On Aug 17, 2016 6:25 AM, "Clément Bœsch"  wrote:
>>
>>> On Mon, Aug 15, 2016 at 07:04:56PM -0700, Sasi Inguva wrote:
>>> > Changes done. Also commented in the code about the differences between
>>> the add_index_entry function and teh ff_add_index_entry function.
>>> >
>>> > About stream copy, yes there will be a big behavior difference when
>>> doing "-c copy" for files with edit lists.
>>> > Currently, ignoring edit lists we will copy all packets from input to
>>> output. So for videos with edit lists the current way of stream copy is
>>> already semantically wrong. In summary these will be the changes with this
>>> patch
>>> > i) For videos with no edit lists - no change.
>>> > ii) For videos with one edit list in their streams
>>> >   - Only portion of the video from the closest keyframe before
>>> the edit list begins, to the closest keyframe after the edit list ends will
>>> be copied.
>>> >   - All audio from the start of the audio stream to the end of
>>> the edit will be copied.
>>> >
>>> > iii) For videos with multiple edit lists in their streams
>>> >   - For video, the timestamps can be non-monotonocially
>>> increasing. Keyframe packets might be repeated. etc.
>>> >   - For audio too, timestamps can be non-monotonically
>>> increasing. For each edit list we will output packets from the start of the
>>> audio stream, so audio will be repeated.
>>> >
>>> > Though points (ii) and (iii) might look dangerous, we should keep in
>>> mind that it is very hard, and maybe impossible to implement proper stream
>>> copy of only those portions of streams which are inside edit lists. We need
>>> a way to mark some frames as decode-and-discard, and maybe writing edit
>>> lists in case of MOV container is a way but if we are doing  -c copy to
>>> some other container, it won't be possible mostly. If (ii) and (iii) sound
>>> unacceptable I can gate the mov_fix_index function behind a no-stream-copy
>>> condition, if there is a way to do so.
>>> >
>>>
>>> OK.
>>>
>>> So. I've made some test with a bunch of personal samples from different
>>> different sources and it fixes the playback for all of them. I don't have
>>> much more comment as it seems to work well. I'm not the maintainer of the
>>> MOV demuxer though, so don't take this as a OK.
>>>
>>> Someone should probably do a deeper review (hint: look at mov_fix_index()
>>> in particular)
>>>
>>> Thanks
>>>
>>> --
>>> Clément B.
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 05/21] libavformat/movenc: mov_write_ftyp_tag: write the major brand a compatible brand

[Erkki Seppälä]

Hello,

On 08/23/2016 10:00 PM, Carl Eugen Hoyos wrote:

+if (mov->mode == MODE_MP4 && mov->major_brand)
+ffio_wfourcc(pb, mov->major_brand); /* write major brand as a 
compatible brand */


How can I reproduce the issue this is trying to fix?


The issue we were fixing was that in the presence of custom major brand 
(the option "brand" is set) the custom major brand did not end up in the 
compatible brands. (In retrospect, this would have been a great commit 
message..)


Prompted by your comment, we reviewed the specification, and it does not 
seem like that the standard requires this functionality - but it doesn't 
outright prohibit it either.


An alternative for our use case would be adding the option 
"compatible_brands" for setting custom compatible brands from the client 
code. It would probably either replace all custom brands with the ones 
provided, or it would need to collect the custom brands in a list in 
order to remove duplicates (though I imagine allowing duplicates would 
only be a esthetic flaw).


Thanks for the review and input!

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mov: Remove ancient heuristic hack

[Derek Buitenhuis]

This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
has no link to any known sample in its commit message, nor
does it actually fix the problem properly, but instead has
a one-off heuristic to try and "fix" them at the expense
of breaking legitimate files.

Signed-off-by: Derek Buitenhuis 
---
Let's get this out of the way first: I'm not 'returning to FFmpeg'.

I do not intend to be involved in the community again, nor its
overall direction and discussions, short of a miracle occurring
at VideoLAN Dev Days.

Let's please keep this to technical repleis only. I will ignore
anything else.

I am sending this patch in a professional context, as it is
a problem I have run into at work, with legitimate files,
produced by x264 and L-SMASH.

Example file:
http://chromashift.org/samples/delay_problem.mp4

Having the DTS delay output on the first packet itself
is important for things like cutting files.

The behavioral change can be seen with:
$ ffprobe -show_packets delay_problem.mp4

Lastly, I would appreciate it if any replies to this patch set
use 'Reply All', to CC me directly, because I am not currently
subscribed to this mailing list, and getting proper IDs to use
in the In-Reply-To field isn't easy now that Gmane is dead.

Cheers,
- Derek
---
 libavformat/mov.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1bc3800..54c63ad 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2802,12 +2802,8 @@ static void mov_build_index(MOVContext *mov, AVStream 
*st)
 sc->time_offset = start_time - empty_duration;
 current_dts = -sc->time_offset;
 if (sc->ctts_count>0 && sc->stts_count>0 &&
-sc->ctts_data[0].duration / FFMAX(sc->stts_data[0].duration, 
1) > 16) {
-/* more than 16 frames delay, dts are likely wrong
-   this happens with files created by iMovie */
-sc->wrong_dts = 1;
+sc->ctts_data[0].duration / FFMAX(sc->stts_data[0].duration, 
1) > 16)
 st->codecpar->video_delay = 1;
-}
 }
 
 if (!unsupported && st->codecpar->codec_id == AV_CODEC_ID_AAC && 
start_time > 0)
@@ -5352,8 +5348,6 @@ static int mov_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 sc->ctts_index++;
 sc->ctts_sample = 0;
 }
-if (sc->wrong_dts)
-pkt->dts = AV_NOPTS_VALUE;
 } else {
 int64_t next_dts = (sc->current_sample < st->nb_index_entries) ?
 st->index_entries[sc->current_sample].timestamp : st->duration;
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Possible long(er?) term support

[Orion Poplawski]

Hello -

   We're about to get rpmfusion up and running with EL7 support, and we're
debating what version of ffmpeg to start with.  In general on the EL platform
we try to keep versions stable and not introduce any ABI changes unless
absolutely necessary.

  Would the ffmpeg developers be willing treat any particular release as a
long-term-support release and try to do security updates for it?  If so, would
either 3.0 or 3.1 be preferrable for this?  FWIW, 3.1 appears to require
pre-release versions of vlc and kodi, but these may be worth waiting for.

Thank you for your consideration.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add yuvtestsrc source filter

[Paul B Mahol]

Hi,

patch attached.


0001-avfilter-add-yuvtestsrc-source-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: Remove ancient heuristic hack

[Carl Eugen Hoyos]

Hi Derek!

2016-08-24 16:55 GMT+02:00 Derek Buitenhuis :
> This breaks files with legitimate single-entry edit lists,
> and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
> has no link to any known sample in its commit message, nor

I suspect the commit message links to this sample:
http://samples.ffmpeg.org/ffmpeg-bugs/roundup/issue910/

This reminds me that we should try to find the roundup mailing
list archives, I don't think there is an online copy anymore;-(

> does it actually fix the problem properly, but instead has
> a one-off heuristic to try and "fix" them at the expense
> of breaking legitimate files.

Please remove the personal aspects from your commit message.

[...}

> Example file:
> http://chromashift.org/samples/delay_problem.mp4
>
> Having the DTS delay output on the first packet itself
> is important for things like cutting files.
>
> The behavioral change can be seen with:
> $ ffprobe -show_packets delay_problem.mp4

Could you explain in a less technical way (for me to understand)
what is wrong with FFmpeg and this file currently?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Possible long(er?) term support

[Carl Eugen Hoyos]

Hi!

2016-08-24 18:51 GMT+02:00 Orion Poplawski :
>   Would the ffmpeg developers be willing treat any particular release as a
> long-term-support release and try to do security updates for it?

Could you define "long-term"?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

[Carl Eugen Hoyos]

Hi!

2016-08-24 10:00 GMT+02:00 Oliver Collyer :
> I’m not sure what would happen - currently the nvenc.c code enforces
> 10-bit encoding when it gets a 10-bit input pixel format.

Yes, my question was about what happens if you remove the enforcement /
force an 8bit profile.

And of course if it is possible to encode 10bit with 8bit input?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: Remove ancient heuristic hack

[Carl Eugen Hoyos]

2016-08-24 16:55 GMT+02:00 Derek Buitenhuis :
> I am sending this patch in a professional context, as it is
> a problem I have run into at work, with legitimate files,
> produced by x264 and L-SMASH.

Does this patch also fix the issue?
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197817.html

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.

[Carl Eugen Hoyos]

2016-08-24 16:44 GMT+02:00 Sasi Inguva :
> ping!

I will apply this if nobody objects.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 05/21] libavformat/movenc: mov_write_ftyp_tag: write the major brand a compatible brand

[Carl Eugen Hoyos]

Hi!

2016-08-24 16:53 GMT+02:00 Erkki Seppälä :
>
> On 08/23/2016 10:00 PM, Carl Eugen Hoyos wrote:
>>>
>>> +if (mov->mode == MODE_MP4 && mov->major_brand)
>>> +ffio_wfourcc(pb, mov->major_brand); /* write major brand as a
>>> compatible brand */
>>
>> How can I reproduce the issue this is trying to fix?
>
> The issue we were fixing was that in the presence of custom major brand (the
> option "brand" is set) the custom major brand did not end up in the
> compatible brands.

Thanks for explaining!
(I couldn't find the option yesterday.)

> (In retrospect, this would have been a great commit
> message..)

Yes;-)

> An alternative for our use case would be adding the option
> "compatible_brands" for setting custom compatible brands from the client
> code.

The advantage is that I believe users have asked for this.

No more comments from me, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: Remove ancient heuristic hack

[Derek Buitenhuis]

On 8/24/2016 6:50 PM, Carl Eugen Hoyos wrote:
>> This breaks files with legitimate single-entry edit lists,
>> and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
>> has no link to any known sample in its commit message, nor
> 
> I suspect the commit message links to this sample:
> http://samples.ffmpeg.org/ffmpeg-bugs/roundup/issue910/

Sample is good to have, but it's unclear  to me what it was
meant to actually fix...

> This reminds me that we should try to find the roundup mailing
> list archives, I don't think there is an online copy anymore;-(

[...]

>> does it actually fix the problem properly, but instead has
>> a one-off heuristic to try and "fix" them at the expense
>> of breaking legitimate files.
> 
> Please remove the personal aspects from your commit message.

I will remove this part.

>> Example file:
>> http://chromashift.org/samples/delay_problem.mp4
>>
>> Having the DTS delay output on the first packet itself
>> is important for things like cutting files.
>>
>> The behavioral change can be seen with:
>> $ ffprobe -show_packets delay_problem.mp4
> 
> Could you explain in a less technical way (for me to understand)
> what is wrong with FFmpeg and this file currently?

The DTS of the first packet should be -36 due to the edit list
in the file, but the heuristic erroneously removes it and
sets it to AV_NOPTS_VALUE (the effect in ffprobe is that the first
packet is just entirely missing the DTS field. Negative DTS are
normal in MP4 files and can reflect, for example, decoding delay
due to frame reordering.

Also for example, if you do:
$ ffprobe -ignore_editlist 1 -show_packets delay_problem.mp4

You'll see that if the edit list is not applied, the DTS is 0,
and the PTS is 36. It follows that shifting everything backwards
by 36, which is how we currently handle edit lists, should end
up with a DTS of -36.

Cheers,
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] af_hdcd: for easier maintenance alongside libhdcd

[Carl Eugen Hoyos]

Hi!

2016-08-24 16:38 GMT+02:00 Burt P. :
> On Tue, Aug 23, 2016 at 2:29 PM, Carl Eugen Hoyos  wrote:
>> It seems safer to me to use the actual number of channels than the
>> channel layout.
>
> Alright, new patch version incoming.

No more comments from me.
(I hope you tested it...)

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Possible long(er?) term support

[Orion Poplawski]

On 08/24/2016 11:54 AM, Carl Eugen Hoyos wrote:
> Hi!
> 
> 2016-08-24 18:51 GMT+02:00 Orion Poplawski :
>>   Would the ffmpeg developers be willing treat any particular release as a
>> long-term-support release and try to do security updates for it?
> 
> Could you define "long-term"?
> 
> Carl Eugen

Well, EL7 itself will be around for a long time (till 2024), but we don't
expect any open-source project to have support for that long. But something in
the 2-3 year range would be very helpful.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: Remove ancient heuristic hack

[Derek Buitenhuis]

On 8/24/2016 7:00 PM, Carl Eugen Hoyos wrote:
> Does this patch also fix the issue?
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197817.html

It doesn't. The patch I sent fixes a problem with a current workaround
in the mov demuxer. Edit lists are just one way it could have triggered
it. Another way, for example, is a mov with a larger-than-normal gap
between the first DTS and PTS.

The patch linked above is a new implementation of edit lists, which
won't necessarily fix the same thing, except by coincidence.

Cheers,
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add yuvtestsrc source filter

[Josh de Kock]

On 24/08/2016 17:57, Paul B Mahol wrote:

Hi,

patch attached.


This looks fine.

--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add yuvtestsrc source filter

[Nicolas George]

L'octidi 8 fructidor, an CCXXIV, Paul B Mahol a écrit :
> patch attached.

Does it support pixel formats that testsrc2 does not?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add yuvtestsrc source filter

[Paul B Mahol]

On Wednesday, August 24, 2016, Nicolas George  wrote:

> L'octidi 8 fructidor, an CCXXIV, Paul B Mahol a écrit :
> > patch attached.
>
> Does it support pixel formats that testsrc2 does not?
>
>
Because of gradients it creates, afaik it cannot use drawutils.
thus only yuv nonsubsampled are supported.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/fate:Add FATE for hls_flags append option

[Steven Liu]

2016-08-24 19:14 GMT+08:00 Steven Liu :

>
>
> 2016-08-24 18:57 GMT+08:00 Michael Niedermayer :
>
>> On Wed, Aug 24, 2016 at 06:28:08PM +0800, Steven Liu wrote:
>> > 2016-08-24 18:23 GMT+08:00 Michael Niedermayer > >:
>> >
>> > > On Wed, Aug 24, 2016 at 03:04:59PM +0800, Steven Liu wrote:
>> > > > On OSX test:
>> > > > localhost:ffmpeg liuqi$ uname -a
>> > > > Darwin localhost 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19
>> 18:36:36
>> > > > PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
>> > > > localhost:ffmpeg liuqi$ make fate-filter-hls-append
>> > > > HOSTCC tests/base64.o
>> > > > HOSTLD tests/base64
>> > > > HOSTCC tests/tiny_psnr.o
>> > > > HOSTLD tests/tiny_psnr
>> > > > HOSTCC tests/tiny_ssim.o
>> > > > HOSTLD tests/tiny_ssim
>> > > > HOSTCC tests/audiomatch.o
>> > > > tests/audiomatch.c:102:12: warning: using floating point absolute
>> value
>> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
>> > > > if(fabs(c) > sigamp * 0.94)
>> > > >^
>> > > > tests/audiomatch.c:102:12: note: use function 'llabs' instead
>> > > > if(fabs(c) > sigamp * 0.94)
>> > > >^~~~
>> > > >llabs
>> > > > tests/audiomatch.c:103:40: warning: using floating point absolute
>> value
>> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
>> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
>> > > >^
>> > > > tests/audiomatch.c:103:40: note: use function 'abs' instead
>> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
>> > > >^~~~
>> > > >abs
>> > > > tests/audiomatch.c:25:28: note: expanded from macro 'FFMIN'
>> > > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
>> > > >^
>> > > > tests/audiomatch.c:103:40: warning: using floating point absolute
>> value
>> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
>> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
>> > > >^
>> > > > tests/audiomatch.c:103:40: note: use function 'abs' instead
>> > > > maxshift = FFMIN(maxshift, fabs(pos)+32);
>> > > >^~~~
>> > > >abs
>> > > > tests/audiomatch.c:25:34: note: expanded from macro 'FFMIN'
>> > > > #define FFMIN(a,b) ((a) > (b) ? (b) : (a))
>> > > >  ^
>> > > > tests/audiomatch.c:104:12: warning: using floating point absolute
>> value
>> > > > function 'fabs' when argument is of integer type [-Wabsolute-value]
>> > > > if(fabs(c)>fabs(bestc)){
>> > > >^
>> > > > tests/audiomatch.c:104:12: note: use function 'llabs' instead
>> > > > if(fabs(c)>fabs(bestc)){
>> > > >^~~~
>> > > >llabs
>> > > > 4 warnings generated.
>> > > > HOSTLD tests/audiomatch
>> > > > GEN tests/data/hls-list-append.m3u8
>> > > > TESTfilter-hls-append
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Linux Test:
>> > > > [root@localhost ffmpeg]# make fate-filter-hls-append
>> > > > HOSTCC tests/base64.o
>> > > > HOSTLD tests/base64
>> > > > HOSTCC tests/tiny_psnr.o
>> > > > HOSTLD tests/tiny_psnr
>> > > > HOSTCC tests/tiny_ssim.o
>> > > > HOSTLD tests/tiny_ssim
>> > > > HOSTCC tests/audiomatch.o
>> > > > tests/audiomatch.c: 在函数‘main’中:
>> > > > tests/audiomatch.c:40: 警告：此函数中的‘bestpos’在使用前可能未初始化
>> > > > HOSTLD tests/audiomatch
>> > > > GEN tests/data/hls-list-append.m3u8
>> > > > TESTfilter-hls-append
>> > > > [root@localhost ffmpeg]# uname -a
>> > > > Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22
>> > > > 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>> > >
>> > > fails with mingw
>> > > ../configure  --cc='ccache i686-w64-mingw32-gcc'  --samples=...
>> --arch=x86
>> > > --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-gpl
>> > > --pkg-config=./pig-config --target_exec=wine
>> > >
>> > > ...
>> > > +0, 873216, 873216, 1152, 2304, 0x823b822c
>> > > +0, 874368, 874368, 1152, 2304, 0xa1658479
>> > > +0, 875520, 875520, 1152, 2304, 0xdbe58ff7
>> > > +0, 876672, 876672, 1152, 2304, 0x725175e2
>> > > +0, 877824, 877824, 1152, 2304, 0xb2ae7741
>> > > +0, 878976, 878976, 1152, 2304, 0x4de169e4
>> > > +0, 880128, 880128, 1152, 2304, 0x3cb18530
>> > > +0, 881280, 881280, 1152, 2304, 0x48b95d6c
>> > > +0, 882432, 882432, 1152, 2304, 0xcff707ef
>> > > Test filter-hls-append failed. Look at tests/data/fate/filter-hls-app
>> end.err
>> > > for details.
>> > > make: *** [fate-filter-hls-append] Error 1
>> > > make: *** Waiting for unfinished jobs
>> > >
>> > .. ok, let me find a Windows 

Re: [FFmpeg-devel] [PATCH 1/3] fate: add test for af_hdcd analyze mode

[Burt P.]

applied

--
Burt
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] af_hdcd: check return value of av_frame_copy_props()

[Burt P.]

applied

--
Burt
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Possible long(er?) term support

[James Almer]

On 8/24/2016 3:11 PM, Orion Poplawski wrote:
> On 08/24/2016 11:54 AM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> 2016-08-24 18:51 GMT+02:00 Orion Poplawski :
>>>   Would the ffmpeg developers be willing treat any particular release as a
>>> long-term-support release and try to do security updates for it?
>>
>> Could you define "long-term"?
>>
>> Carl Eugen
> 
> Well, EL7 itself will be around for a long time (till 2024), but we don't
> expect any open-source project to have support for that long. But something in
> the 2-3 year range would be very helpful.

Development of FFmpeg is fast and the codebase changes a lot in a years
time, meaning backporting fixes to old releases becomes a hassle the more
time passes, so usually only the most recent four or five releases are
actively maintained.
Important/critical security fixes however are usually backported to almost
every affected branch even if not actively maintained.

In any case, maintainers for old and even more recent releases to take care
of bug and security fixes backporting are always welcome.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add yuvtestsrc source filter

[Moritz Barsnick]

On Wed, Aug 24, 2016 at 18:57:57 +0200, Paul B Mahol wrote:

> +The @code{yuvtestsrc} source generates an YUV test pattern. You should
  ^ a
> +see a y, cb and cr stripe from top to bottom.

This makes it sound like the stripes go from top to bottom, i.e.
they're vertical stripes. But they're horizontal, right? Perhaps write:
"see vertical y, cb and cr stripes".

+static void yuvtest_fill_picture8(AVFilterContext *ctx, AVFrame *frame)
+static void yuvtest_fill_picture16(AVFilterContext *ctx, AVFrame *frame)

This *almost* calls for a function macro. ;)

Are the 8-bit functions actually faster? Just wondering.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel