Re: [FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.

[Steven Liu]

> On 3 Apr 2018, at 14:06, Richard Shaffer  wrote:
> 
> On Mon, Apr 2, 2018 at 10:15 PM, Steven Liu  wrote:
>> 
>> 
>>> On 3 Apr 2018, at 12:33, Richard Shaffer  wrote:
>>> 
>>> On Mon, Apr 2, 2018 at 8:31 PM, Steven Liu  wrote:
 
 
> On 3 Apr 2018, at 09:12, rshaf...@tunein.com wrote:
> 
> From: Richard Shaffer 
> 
> The rw_timeout option is currently not applied when opening media 
> playlist,
> segment, or encryption key URLs. This can cause the HLS demuxer to block
> indefinitely, even when the rw_timeout option has been specified. This 
> change
> simply enables carrying over the rw_timeout option when the demuxer opens 
> these
> URLs.
> ---
> libavformat/hls.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index c578bf86e3..6663244ddf 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1661,7 +1661,7 @@ static int save_avio_options(AVFormatContext *s)
> {
>   HLSContext *c = s->priv_data;
>   static const char * const opts[] = {
> -"headers", "http_proxy", "user_agent", "user-agent", "cookies", 
> "referer", NULL };
> +"headers", "http_proxy", "user_agent", "user-agent", "cookies", 
> "referer", "rw_timeout", NULL };
 This table is used for http header.
 You could add the option into hls_options.
>>> 
>>> Thanks for looking at the change. While the options currently in the
>>> table are related to HTTP and rw_timeout is more general, I'm not
>>> aware of a reason not to preserve the rw_timeout option here as well.
>>> It seems unnecessary to define another HLS-specific option for
>>> rw_timeout when the existing option exists and does what is intended.
>>> I'm not sure whether you're objecting to the change and/or have a
>>> different suggestion. Do you mind elaborating on your comment?
>> Is the rw_timeout in to HTTP RFC? If yes, this is ok, If not, i think that 
>> is a ffmpeg option , not a http header content.
> 
> http_proxy isn't tied to an HTTP header value, either. There isn't any
> indication that avio_opts is intended for specifically HTTP options,
> or that using it to store other avio options would break something. If
> you have a reason why this shouldn't be used for other (non-HTTP)
> options, can you please help me understand your thinking?
> 
> I also want to spend some more time working on this, because I see
> that there are multiple fields in HLSContext dealing with avio
> options: There is the avio_opts field, but also referer, user_agent,
> cookies, headers and http_proxy. avio_opts seems to be used when
> opening segments and encryption key URIs, but the other fields are
> used when reloading a playlist or parsing variant playlist URLs from a
> master playlist. It's not clear why the options are stored in separate
> places or whether that is necessary. If you have any insight into that
> as well, it would be appreciated.

Look at the code:

 205 char *referer;   ///< holds HTTP referer set as an 
AVOption to the HTTP protocol context
 206 char *user_agent;///< holds HTTP user agent set as 
an AVOption to the HTTP protocol context
 207 char *cookies;   ///< holds HTTP cookie values set 
in either the initial response or as an AVOption to the HTTP protocol context
 208 char *headers;   ///< holds HTTP headers set as an 
AVOption to the HTTP protocol context
 209 char *http_proxy;///< holds the address of the 
HTTP proxy server

There have some comment for the options.
and reference the code in: hls_read_header / open_input and use the options.


> 
>>> 
>   const char * const * opt = opts;
>   uint8_t *buf;
>   int ret = 0;
> --
> 2.15.1 (Apple Git-101)
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 
 Thanks
 Steven
 
 
 
 
 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> Thanks
>> Steven
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH v3 1/3] avutil/log: rename and initialize global log flags variable

[Tobias Rapp]

On 29.03.2018 20:40, Michael Niedermayer wrote:

On Wed, Mar 28, 2018 at 05:03:38PM +0200, Tobias Rapp wrote:

Rename global variable for symmetry with av_log_level.

Signed-off-by: Tobias Rapp 
---
  libavutil/log.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavutil/log.c b/libavutil/log.c
index 9b7d484..0a99d01 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -52,7 +52,7 @@ static AVMutex mutex = AV_MUTEX_INITIALIZER;
  #endif
  
  static int av_log_level = AV_LOG_INFO;

-static int flags;
+static int av_log_flags = 0;


This prefix is confusing as the av prefix is intended for
exported public symbols which a static symbol cannot be


Stumbled over the generic name of this global variable when working on 
the av_log_set_opts function. As that patch is dropped I consider this 
patch as irrelevant.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

[Tobias Rapp]

On 29.03.2018 20:38, Michael Niedermayer wrote:

On Wed, Mar 28, 2018 at 05:03:39PM +0200, Tobias Rapp wrote:

Allows to set log level and flag values from string.

Signed-off-by: Tobias Rapp 
---
  doc/APIchanges  |  3 +++
  libavutil/log.c | 76 +
  libavutil/log.h | 16 +++
  libavutil/version.h |  2 +-
  4 files changed, 96 insertions(+), 1 deletion(-)


iam not intending to override anyone blocking this but as i looked at the code
and it LGTM


Thanks for review. Moved code into fftools/cmdutils.c and pushed to 
master. Will send a separate patch to ML for the missing documentation 
update.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH] doc: update loglevel option documentation

[Tobias Rapp]

Updates documentation after the changes to loglevel flag prefix parsing
in 4b736bc921ed96ad6d312ce0cbe0de29b9e3fe81.

Signed-off-by: Tobias Rapp 
---
 doc/fftools-common-opts.texi | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 185ec21..d4ee19d 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -168,14 +168,24 @@ The returned list cannot be assumed to be always complete.
 ffmpeg -sinks pulse,server=192.168.0.4
 @end example
 
-@item -loglevel [repeat+]@var{loglevel} | -v [repeat+]@var{loglevel}
-Set the logging level used by the library.
-Adding "repeat+" indicates that repeated log output should not be compressed
-to the first line and the "Last message repeated n times" line will be
-omitted. "repeat" can also be used alone.
-If "repeat" is used alone, and with no prior loglevel set, the default
-loglevel will be used. If multiple loglevel parameters are given, using
-'repeat' will not change the loglevel.
+@item -loglevel [@var{flags}+]@var{loglevel} | -v [@var{flags}+]@var{loglevel}
+Set logging level and flags used by the library.
+
+The optional @var{flags} prefix can consist of the following values:
+@table @samp
+@item repeat
+Indicates that repeated log output should not be compressed to the first line
+and the "Last message repeated n times" line will be omitted.
+@item level
+Indicates that log output should add a @code{[level]} prefix to each message
+line. This can be used as an alternative to log coloring, e.g. when dumping the
+log to file.
+@end table
+Flags can also be used alone by adding a '+'/'-' prefix to set/reset a
+single flag without affecting other flags or changing the log level. When
+setting both, flags and level, a '+' separator is expected between last
+flag and before level.
+
 @var{loglevel} is a string or a number containing one of the following values:
 @table @samp
 @item quiet, -8
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

[Paul B Mahol]

On 4/3/18, Tobias Rapp  wrote:
> On 29.03.2018 20:38, Michael Niedermayer wrote:
>> On Wed, Mar 28, 2018 at 05:03:39PM +0200, Tobias Rapp wrote:
>>> Allows to set log level and flag values from string.
>>>
>>> Signed-off-by: Tobias Rapp 
>>> ---
>>>   doc/APIchanges  |  3 +++
>>>   libavutil/log.c | 76
>>> +
>>>   libavutil/log.h | 16 +++
>>>   libavutil/version.h |  2 +-
>>>   4 files changed, 96 insertions(+), 1 deletion(-)
>>
>> iam not intending to override anyone blocking this but as i looked at the
>> code
>> and it LGTM
>
> Thanks for review. Moved code into fftools/cmdutils.c and pushed to
> master. Will send a separate patch to ML for the missing documentation
> update.

This was blocked, please revert ASAP!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/clearvideo: add inter-frame decoding

[Paul B Mahol]

On 4/3/18, Michael Niedermayer  wrote:
> On Mon, Apr 02, 2018 at 08:18:02PM +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/clearvideo.c | 2394
>> ++-
>>  1 file changed, 2378 insertions(+), 16 deletions(-)
>>
> [...]
>
>> @@ -271,6 +2022,332 @@ static int decode_mb(CLVContext *c, int x, int y)
>>  return 0;
>>  }
>>
>> +static MV pred(MV a, MV b, MV c)
>> +{
>> +MV mv;
>> +
>> +if (a.x < b.x) {
>> +if (b.x < c.x) {
>> +mv.x = b.x;
>> +} else {
>> +if (a.x < c.x) {
>> +mv.x = c.x;
>> +} else {
>> +mv.x = a.x;
>> +}
>> +}
>> +} else {
>> +if (b.x < c.x) {
>> +if (a.x < c.x) {
>> +mv.x = a.x;
>> +} else {
>> +mv.x = c.x;
>> +}
>> +} else {
>> +mv.x = b.x;
>> +}
>> +}
>> +
>> +if (a.y < b.y) {
>> +if (b.y < c.y) {
>> +mv.y = b.y;
>> +} else {
>> +if (a.y < c.y) {
>> +mv.y = c.y;
>> +} else {
>> +mv.y = a.y;
>> +}
>> +}
>> +} else {
>> +if (b.y < c.y) {
>> +if (a.y < c.y) {
>> +mv.y = a.y;
>> +} else {
>> +mv.y = c.y;
>> +}
>> +} else {
>> +mv.y = b.y;
>> +}
>> +}
>
> is this mid_pred() ?

Yes. Fixed locally.

>
>
> [...]
>> @@ -290,7 +2367,13 @@ static int clv_decode_frame(AVCodecContext *avctx,
>> void *data,
>>
>>  frame_type = bytestream2_get_byte(&gb);
>>
>> -if (frame_type & 0x2) {
>
>> +if (frame_type & 0x7f == 0x30) {
>
> missing ()

Added locally.

>
>
> [...]
> --
> 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.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

[Tobias Rapp]

On 03.04.2018 10:25, Paul B Mahol wrote:

On 4/3/18, Tobias Rapp  wrote:

On 29.03.2018 20:38, Michael Niedermayer wrote:

On Wed, Mar 28, 2018 at 05:03:39PM +0200, Tobias Rapp wrote:

Allows to set log level and flag values from string.

Signed-off-by: Tobias Rapp 
---
   doc/APIchanges  |  3 +++
   libavutil/log.c | 76
+
   libavutil/log.h | 16 +++
   libavutil/version.h |  2 +-
   4 files changed, 96 insertions(+), 1 deletion(-)


iam not intending to override anyone blocking this but as i looked at the
code
and it LGTM


Thanks for review. Moved code into fftools/cmdutils.c and pushed to
master. Will send a separate patch to ML for the missing documentation
update.


This was blocked, please revert ASAP!


As far as I understood the responses from wm4 and Michael it was blocked 
to be added in libavutil/log.c but accepted to be added in 
fftools/cmdutils.c (as in version 2 of the patch it was only a 
suggestion to move the code to libavutil).


Regards,
Tobias

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

Re: [FFmpeg-devel] swscale/swscale_unscaled : add X86_64 (SSE2, AVX) for uyvyto422

[Hendrik Leppkes]

On Tue, Apr 3, 2018 at 2:10 AM, James Almer  wrote:
> On 4/2/2018 8:33 PM, Carl Eugen Hoyos wrote:
>> 2018-04-02 23:26 GMT+02:00, Martin Vignali :
>>
>>> Around 20% faster  (on a "benchmark cmd", who test pix_fmt conversion)
>>> (4.2s with the patch, 5.2s without)
>>>
>>> Pass fate test for me.
>>>
>>> Checkasm result :
>>> uyvytoyuv422_c: 14146.6
>>> uyvytoyuv422_mmx: 13696.4
>>> uyvytoyuv422_mmxext: 19395.9
>>
>> Something looks wrong here...
>>
>> Carl Eugen
>
> On a Haswell using GCC i get
>
> uyvytoyuv422_c: 44884.2
> uyvytoyuv422_mmx: 15284.5
> uyvytoyuv422_mmxext: 28656.5
> uyvytoyuv422_sse2: 10921.8
> uyvytoyuv422_avx: 10606.5
>
> Martin is using a Clang version that is for some reason ignoring our
> attempts at disabling tree vectorization, so his C function is optimized
> with simd by the compiler, hence the good result.
>
> The mmxext version being slower than the mmx one seems however to be an
> existing issue in the tree, which we should probably deal with. Unless
> of course the test is wrong.

Its mmx, dealing with it would probably entail just deleting it. Can
leave the ordinary mmx and remove the ext version, or perhaps just
both.

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

Re: [FFmpeg-devel] [PATCH] use bcrypt instead of the old wincrypt API

[Steve Lhomme]

Le 31/03/2018 à 16:46, Derek Buitenhuis a écrit :

On 3/30/2018 1:44 PM, Steve Lhomme wrote:

+if (BCRYPT_SUCCESS(ret)) {
+NTSTATUS ret = BCryptGenRandom(algo_handle, &seed, sizeof(seed), 0);
+BCryptCloseAlgorithmProvider(algo_handle, 0);
+if (BCRYPT_SUCCESS(ret))
  return seed;
  }

How does this behave in the case of failure?


It falls through the rest of the code until something works, like 
get_generic_seed().




- Derek
___
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] use bcrypt instead of the old wincrypt API

[Steve Lhomme]

Le 01/04/2018 à 03:37, Michael Niedermayer a écrit :

On Fri, Mar 30, 2018 at 02:44:52PM +0200, Steve Lhomme wrote:

Remove the wincrypt API calls since we don't support XP anymore and bcrypt is
available since Vista, even on Windows Store builds.
---
  configure   |  6 +++---
  libavutil/random_seed.c | 20 ++--
  2 files changed, 13 insertions(+), 13 deletions(-)

fails to build on ubuntu mingw64

CC  libavutil/random_seed.o
In file included from src/libavutil/random_seed.c:30:0:
/usr/share/mingw-w64/include/bcrypt.h:23:3: error: unknown type name ‘LONG’
typedef LONG NTSTATUS,*PNTSTATUS;
^


Updated patch incoming.



[...]


___
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] use bcrypt instead of the old wincrypt API

[Steve Lhomme]

Remove the wincrypt API calls since we don't support XP anymore and bcrypt is
available since Vista, even on Windows Store builds.
---
 configure   |  6 +++---
 libavutil/random_seed.c | 19 ++-
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/configure b/configure
index 08d6fc5983..9a85ad59ad 100755
--- a/configure
+++ b/configure
@@ -2141,10 +2141,10 @@ SYSTEM_FUNCS="
 "
 
 SYSTEM_LIBRARIES="
+bcrypt
 vaapi_drm
 vaapi_x11
 vdpau_x11
-wincrypt
 "
 
 TOOLCHAIN_FEATURES="
@@ -3443,7 +3443,7 @@ avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia bcrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -5823,9 +5823,9 @@ check_header asm/types.h
 check_builtin stdatomic stdatomic.h "atomic_int foo, bar = 
ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0)"
 
 check_lib advapi32 "windows.h"RegCloseKey  -ladvapi32
+check_lib bcrypt   "windows.h bcrypt.h"   BCryptGenRandom  -lbcrypt
 check_lib ole32"windows.h"CoTaskMemFree-lole32
 check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
-check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
 
 check_lib android android/native_window.h ANativeWindow_acquire -landroid
diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
index 881c23c8c8..70dc509d2f 100644
--- a/libavutil/random_seed.c
+++ b/libavutil/random_seed.c
@@ -26,9 +26,9 @@
 #if HAVE_IO_H
 #include 
 #endif
-#if HAVE_WINCRYPT
+#if HAVE_BCRYPT
 #include 
-#include 
+#include 
 #endif
 #include 
 #include 
@@ -121,13 +121,14 @@ uint32_t av_get_random_seed(void)
 {
 uint32_t seed;
 
-#if HAVE_WINCRYPT
-HCRYPTPROV provider;
-if (CryptAcquireContext(&provider, NULL, NULL, PROV_RSA_FULL,
-CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) {
-BOOL ret = CryptGenRandom(provider, sizeof(seed), (PBYTE) &seed);
-CryptReleaseContext(provider, 0);
-if (ret)
+#if HAVE_BCRYPT
+BCRYPT_ALG_HANDLE algo_handle;
+NTSTATUS ret = BCryptOpenAlgorithmProvider(&algo_handle, 
BCRYPT_RNG_ALGORITHM,
+   MS_PRIMITIVE_PROVIDER, 0);
+if (BCRYPT_SUCCESS(ret)) {
+NTSTATUS ret = BCryptGenRandom(algo_handle, (UCHAR*)&seed, 
sizeof(seed), 0);
+BCryptCloseAlgorithmProvider(algo_handle, 0);
+if (BCRYPT_SUCCESS(ret))
 return seed;
 }
 #endif
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[Vittorio Giovara]

On Thu, Mar 29, 2018 at 03:30:43PM +0200, wm4 wrote:
>* PSEUDOPAL pixel formats are not paletted, but carried a palette with the
*>* intention of allowing code to treat unpaletted formats as paletted. The
*>* palette simply mapped the byte values to the resulting RGB values,
*>* making it some sort of LUT for RGB conversion.
*> >* It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
*>* GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
*>* formats. The last one, GRAY8, is more common, but its treatment is
*>* grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
*>* from typical Y video planes was not mapped to the correct RGB values.
*>* Also, nothing actually used the PSEUDOPAL palette data, except xwdenc.
*>* All other code had to treat it as a special case, just to ignore or
*>* propagate palette data.
*> >* In conclusion, this was just a very strange old hack that has no real
*>* justification to exist. It's negatively useful, because API users who
*>* allocate their own pixel data have to be aware that they need to
*>* allocate the palette, or FFmpeg will crash on them in _some_ situations.
*>* On top of this, there was no API to allocate the pseuo palette outside
*>* of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not public,
*>* which is good, because GRAY8 treatment is broken.)
*> >* This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
*>* the pseudo palette optional. Nothing accesses it anymore, though if it's
*>* set, it's propagated. It's still allocated and initialized for
*>* compatibility with API users that rely on this feature. But new API
*>* users do not need to allocate it. This was an explicit goal of this
*>* patch.
*> >* Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
*>* first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
*>* macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
*> >* Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
*>* FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
*>* functions manually changed to not allocating a palette.
*>* ---*

set looks good to me
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] spdifenc: support ac3 core+eac3 dependent streams

[Hendrik Leppkes]

Such streams are found on Blu-ray, and identified as EAC3 type in
avformat, while the bitstream of the core stream is actually a pure AC3
frame.

Adjust the parsing accordingly, since AC3 frames always hold 6 blocks
and the numblkscod syntax element is not present.
---
 libavformat/spdifenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c
index 3a50aebbef..9514ff8e10 100644
--- a/libavformat/spdifenc.c
+++ b/libavformat/spdifenc.c
@@ -118,7 +118,8 @@ static int spdif_header_eac3(AVFormatContext *s, AVPacket 
*pkt)
 static const uint8_t eac3_repeat[4] = {6, 3, 2, 1};
 int repeat = 1;
 
-if ((pkt->data[4] & 0xc0) != 0xc0) /* fscod */
+int bsid = pkt->data[5] >> 3;
+if (bsid > 10 && (pkt->data[4] & 0xc0) != 0xc0) /* fscod */
 repeat = eac3_repeat[(pkt->data[4] & 0x30) >> 4]; /* numblkscod */
 
 ctx->hd_buf = av_fast_realloc(ctx->hd_buf, &ctx->hd_buf_size, 
ctx->hd_buf_filled + pkt->size);
-- 
2.16.1.windows.4

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

[FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/utvideodec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index 82cb038ccd..99b37aa0f3 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#define CACHED_BITSTREAM_READER
 #define UNCHECKED_BITSTREAM_READER 1
 
 #include "libavutil/intreadwrite.h"
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 2/3] doc/libav-merge: bitstream reader is now merged

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/libav-merge.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
index 4ba08fc588..6821d0f196 100644
--- a/doc/libav-merge.txt
+++ b/doc/libav-merge.txt
@@ -95,7 +95,6 @@ Stuff that didn't reach the codebase:
   - 0cef06df0 checkasm: add HEVC MC tests
   - e7078e842 hevcdsp: add x86 SIMD for MC
   - 7993ec19a hevc: Add hevc_get_pixel_4/8/12/16/24/32/48/64
-- new bitstream reader (see 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html)
 - use av_cpu_max_align() instead of hardcoding alignment requirements (see 
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215834.html)
   - f44ec22e0 lavc: use av_cpu_max_align() instead of hardcoding alignment 
requirements
   - 4de220d2e frame: allow align=0 (meaning automatic) for 
av_frame_get_buffer()
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/3] avcodec/get_bits: add cached bitstream reader

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/get_bits.h | 268 +-
 libavcodec/golomb.h   | 151 
 2 files changed, 393 insertions(+), 26 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index d7cf286378..64e1643e34 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -1,5 +1,6 @@
 /*
- * copyright (c) 2004 Michael Niedermayer 
+ * Copyright (c) 2004 Michael Niedermayer 
+ * Copyright (c) 2016 Alexandra Hájková
  *
  * This file is part of FFmpeg.
  *
@@ -55,6 +56,10 @@
 
 typedef struct GetBitContext {
 const uint8_t *buffer, *buffer_end;
+#ifdef CACHED_BITSTREAM_READER
+uint64_t cache;
+unsigned bits_left;
+#endif
 int index;
 int size_in_bits;
 int size_in_bits_plus8;
@@ -107,12 +112,16 @@ typedef struct GetBitContext {
  * For examples see get_bits, show_bits, skip_bits, get_vlc.
  */
 
-#ifdef LONG_BITSTREAM_READER
+#ifdef CACHED_BITSTREAM_READER
+#   define MIN_CACHE_BITS 64
+#elif defined LONG_BITSTREAM_READER
 #   define MIN_CACHE_BITS 32
 #else
 #   define MIN_CACHE_BITS 25
 #endif
 
+#ifndef CACHED_BITSTREAM_READER
+
 #define OPEN_READER_NOSIZE(name, gb)\
 unsigned int name ## _index = (gb)->index;  \
 unsigned int av_unused name ## _cache
@@ -197,20 +206,113 @@ typedef struct GetBitContext {
 
 #define GET_CACHE(name, gb) ((uint32_t) name ## _cache)
 
+#endif
+
 static inline int get_bits_count(const GetBitContext *s)
 {
+#ifdef CACHED_BITSTREAM_READER
+return s->index - s->bits_left;
+#else
 return s->index;
+#endif
 }
 
-static inline void skip_bits_long(GetBitContext *s, int n)
+static inline void refill_32(GetBitContext *s)
 {
-#if UNCHECKED_BITSTREAM_READER
-s->index += n;
+#ifdef CACHED_BITSTREAM_READER
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache   = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << 
s->bits_left | s->cache;
 #else
-s->index += av_clip(n, -s->index, s->size_in_bits_plus8 - s->index);
+s->cache   = s->cache | (uint64_t)AV_RB32(s->buffer + (s->index >> 3)) 
<< (32 - s->bits_left);
+#endif
+s->index += 32;
+s->bits_left += 32;
+#endif
+}
+
+static inline void refill_64(GetBitContext *s)
+{
+#ifdef CACHED_BITSTREAM_READER
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache = AV_RL64(s->buffer + (s->index >> 3));
+#else
+s->cache = AV_RB64(s->buffer + (s->index >> 3));
+#endif
+s->index += 64;
+s->bits_left = 64;
+#endif
+}
+
+#ifdef CACHED_BITSTREAM_READER
+static inline uint64_t get_val(GetBitContext *s, unsigned n, int is_le)
+{
+uint64_t ret;
+av_assert2(n>0 && n<=63);
+if (is_le) {
+ret = s->cache & ((UINT64_C(1) << n) - 1);
+s->cache >>= n;
+} else {
+ret = s->cache >> (64 - n);
+s->cache <<= n;
+}
+s->bits_left -= n;
+return ret;
+}
+#endif
+
+#ifdef CACHED_BITSTREAM_READER
+static inline unsigned show_val(const GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+return s->cache & ((UINT64_C(1) << n) - 1);
+#else
+return s->cache >> (64 - n);
+#endif
+}
+#endif
+
+/**
+ * Show 1-25 bits.
+ */
+static inline unsigned int show_bits(GetBitContext *s, int n)
+{
+register int tmp;
+#ifdef CACHED_BITSTREAM_READER
+if (n > s->bits_left)
+refill_32(s);
+
+tmp = show_val(s, n);
+#else
+OPEN_READER_NOSIZE(re, s);
+av_assert2(n>0 && n<=25);
+UPDATE_CACHE(re, s);
+tmp = SHOW_UBITS(re, s, n);
 #endif
+return tmp;
 }
 
+#ifdef CACHED_BITSTREAM_READER
+static inline void skip_remaining(GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+s->cache >>= n;
+#else
+s->cache <<= n;
+#endif
+s->bits_left -= n;
+}
+#endif
+
 /**
  * Read MPEG-1 dc-style VLC (sign bit + mantissa with no MSB).
  * if MSB not set it is negative
@@ -218,6 +320,13 @@ static inline void skip_bits_long(GetBitContext *s, int n)
  */
 static inline int get_xbits(GetBitContext *s, int n)
 {
+#ifdef CACHED_BITSTREAM_READER
+int32_t cache = show_bits(s, 32);
+int sign = ~cache >> 31;
+skip_remaining(s, n);
+
+return uint32_t)(sign ^ cache)) >> (32 - n)) ^ sign) - sign;
+#else
 register int sign;
 register int32_t cache;
 OPEN_READER(re, s);
@@ -228,8 +337,10 @@ static inline int get_xbits(GetBitContext *s, int n)
 LAST_SKIP_BITS(re, s, n);
 CLOSE_READER(re, s);
 return (NEG_USR32(sign ^ cache, n) ^ sign) - sign;
+#endif
 }
 
+#ifndef CACHED_BITSTREAM_READER
 static inline int get_xbits_le(GetBitContext *s, int n)
 {
 register int sign;
@@ -243,31 +354,53 @@ static inline int get_xbits_le(GetBitContext *s, int n)
 CLOSE_READER(re, s);
 return (zero_extend(sign ^ cache, n) ^ sign) - sign;
 }
+#endif
 
-static inline int

[FFmpeg-devel] [PATCH] avcodec/imgconvert: fix possible null pointer dereference

[Simon Thelen]

regression since 354b26a3945eadd4ed8fcd801dfefad2566241de
---
 libavcodec/imgconvert.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
index 7b0005b308..1fd636c83d 100644
--- a/libavcodec/imgconvert.c
+++ b/libavcodec/imgconvert.c
@@ -72,11 +72,12 @@ enum AVPixelFormat avcodec_find_best_pix_fmt_of_list(const 
enum AVPixelFormat *p
 int loss;
 
 for (i=0; pix_fmt_list[i] != AV_PIX_FMT_NONE; i++) {
-loss = *loss_ptr;
+loss = loss_ptr ? *loss_ptr : 0;
 best = avcodec_find_best_pix_fmt_of_2(best, pix_fmt_list[i], 
src_pix_fmt, has_alpha, &loss);
 }
 
-*loss_ptr = loss;
+if (loss_ptr)
+*loss_ptr = loss;
 return best;
 }
 
-- 
2.16.3

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

Re: [FFmpeg-devel] swscale/swscale_unscaled : add X86_64 (SSE2, AVX) for uyvyto422

[Martin Vignali]

Hello,

>
> > The mmxext version being slower than the mmx one seems however to be an
> > existing issue in the tree, which we should probably deal with. Unless
> > of course the test is wrong.
>
> Its mmx, dealing with it would probably entail just deleting it. Can
> leave the ordinary mmx and remove the ext version, or perhaps just
> both.
>
>
> I think there is two option for that (in swscale)
Remove (at least for unscaled part), the include of template for mmxext (in
swscale/x86/rgb2rgb.c)
Or disable MMXExt version, only if there is a checkasm test.
The previous SIMD and checkasm test (for RGBA shuffle), show same kind of
result (mmxext slower than mmx).

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

Re: [FFmpeg-devel] [PATCH] spdifenc: support ac3 core+eac3 dependent streams

[Anssi Hannula]

Hi,

Hendrik Leppkes kirjoitti 2018-04-03 13:35:

Such streams are found on Blu-ray, and identified as EAC3 type in
avformat, while the bitstream of the core stream is actually a pure AC3
frame.

Adjust the parsing accordingly, since AC3 frames always hold 6 blocks
and the numblkscod syntax element is not present.
---
 libavformat/spdifenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c
index 3a50aebbef..9514ff8e10 100644
--- a/libavformat/spdifenc.c
+++ b/libavformat/spdifenc.c
@@ -118,7 +118,8 @@ static int spdif_header_eac3(AVFormatContext *s,
AVPacket *pkt)
 static const uint8_t eac3_repeat[4] = {6, 3, 2, 1};
 int repeat = 1;

-if ((pkt->data[4] & 0xc0) != 0xc0) /* fscod */
+int bsid = pkt->data[5] >> 3;
+if (bsid > 10 && (pkt->data[4] & 0xc0) != 0xc0) /* fscod */
 repeat = eac3_repeat[(pkt->data[4] & 0x30) >> 4]; /* 
numblkscod */


 ctx->hd_buf = av_fast_realloc(ctx->hd_buf, &ctx->hd_buf_size,
ctx->hd_buf_filled + pkt->size);



Looks good to me.


Thanks,
--
Anssi Hannula
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/filters: some more details and modified example to, zmq/azmq

[Bodecs Bela]

Dear All,

I added some more information about default value of bind_address option 
and its abbreviated
version (b). I modified the example to have named instanced filter and 
to show

its use.

please review this patch.

thanky you in advance,

best regards,

Bela Bodecs

>From 5464b56e6d21f1e87166ada31affc7e63cf6f90d Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Tue, 3 Apr 2018 16:18:02 +0200
Subject: [PATCH] doc/filters: some more details and modified example to
 zmq/azmq

Info about default value of bind_address option and its abbreviated
version (b). Example modified to have named instanced filter and to show
its use.


Signed-off-by: Bela Bodecs 
---
 doc/filters.texi | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index bf2b94e..6665bfa 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -221,6 +221,7 @@ Here is a BNF description of the filtergraph syntax:
 @var{FILTERGRAPH}  ::= [sws_flags=@var{flags};] @var{FILTERCHAIN} 
[;@var{FILTERGRAPH}]
 @end example
 
+@anchor{filtergraph escaping}
 @section Notes on filtergraph escaping
 
 Filtergraph description composition entails several levels of
@@ -20267,7 +20268,8 @@ filters in the filtergraph.
 
 @code{zmq} and @code{azmq} work as a pass-through filters. @code{zmq}
 must be inserted between two video filters, @code{azmq} between two
-audio filters.
+audio filters. Both of them are capable to send messages to any filter
+type.
 
 To enable these filters you need to install the libzmq library and
 headers and configure FFmpeg with @code{--enable-libzmq}.
@@ -20277,7 +20279,10 @@ For more information about libzmq see:
 
 The @code{zmq} and @code{azmq} filters work as a libzmq server, which
 receives messages sent through a network interface defined by the
-@option{bind_address} option.
+@option{bind_address} option. (An alternative, abbreviated  name of this
+option is @option{b}.) Default value of this option is
+"tcp://*:". You may want to alter this value to your needs,
+but don't forget to escape ':' signs. (See @ref{filtergraph escaping} section.)
 
 The received message must be in the form:
 @example
@@ -20285,7 +20290,10 @@ The received message must be in the form:
 @end example
 
 @var{TARGET} specifies the target of the command, usually the name of
-the filter class or a specific filter instance name.
+the filter class or a specific filter instance name. The default
+filter instance name is something like this "Parsed__",
+but you can override this by using filter_name@@id syntax.
+(See @ref{Filtergraph syntax} section.)
 
 @var{COMMAND} specifies the name of the command for the target filter.
 
@@ -20307,14 +20315,17 @@ will send a reply to the client, adopting the format:
 Look at @file{tools/zmqsend} for an example of a zmq client which can
 be used to send commands processed by these filters.
 
-Consider the following filtergraph generated by @command{ffplay}
+Consider the following filtergraph generated by @command{ffplay},
+We specify instance name for the 1st overlay filter only,
+the other ones will have default instance names.
+
 @example
 ffplay -dumpgraph 1 -f lavfi "
 color=s=100x100:c=red  [l];
 color=s=100x100:c=blue [r];
 nullsrc=s=200x100, zmq [bg];
-[bg][l]   overlay  [bg+l];
-[bg+l][r] overlay=x=100 "
+[bg][l]   overlay [bg+l];
+[bg+l][r] overlay@@my=x=100 "
 @end example
 
 To change the color of the left side of the video, the following
@@ -20328,6 +20339,12 @@ To change the right side:
 echo Parsed_color_1 c pink | tools/zmqsend
 @end example
 
+To change the position of the right side:
+@example
+echo overlay@@my x 150 | tools/zmqsend
+@end example
+
+
 @c man end MULTIMEDIA FILTERS
 
 @chapter Multimedia Sources
-- 
2.5.3.windows.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: fix possible null pointer dereference

[Paul B Mahol]

On 4/3/18, Simon Thelen  wrote:
> regression since 354b26a3945eadd4ed8fcd801dfefad2566241de
> ---
>  libavcodec/imgconvert.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
> index 7b0005b308..1fd636c83d 100644
> --- a/libavcodec/imgconvert.c
> +++ b/libavcodec/imgconvert.c
> @@ -72,11 +72,12 @@ enum AVPixelFormat
> avcodec_find_best_pix_fmt_of_list(const enum AVPixelFormat *p
>  int loss;
>
>  for (i=0; pix_fmt_list[i] != AV_PIX_FMT_NONE; i++) {
> -loss = *loss_ptr;
> +loss = loss_ptr ? *loss_ptr : 0;
>  best = avcodec_find_best_pix_fmt_of_2(best, pix_fmt_list[i],
> src_pix_fmt, has_alpha, &loss);
>  }
>
> -*loss_ptr = loss;
> +if (loss_ptr)
> +*loss_ptr = loss;
>  return best;
>  }
>
> --
> 2.16.3
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

[wm4]

On Tue, 3 Apr 2018 10:25:56 +0200
Paul B Mahol  wrote:

> On 4/3/18, Tobias Rapp  wrote:
> > On 29.03.2018 20:38, Michael Niedermayer wrote:  
> >> On Wed, Mar 28, 2018 at 05:03:39PM +0200, Tobias Rapp wrote:  
> >>> Allows to set log level and flag values from string.
> >>>
> >>> Signed-off-by: Tobias Rapp 
> >>> ---
> >>>   doc/APIchanges  |  3 +++
> >>>   libavutil/log.c | 76
> >>> +
> >>>   libavutil/log.h | 16 +++
> >>>   libavutil/version.h |  2 +-
> >>>   4 files changed, 96 insertions(+), 1 deletion(-)  
> >>
> >> iam not intending to override anyone blocking this but as i looked at the
> >> code
> >> and it LGTM  
> >
> > Thanks for review. Moved code into fftools/cmdutils.c and pushed to
> > master. Will send a separate patch to ML for the missing documentation
> > update.  
> 
> This was blocked, please revert ASAP!

Looks fine to me. None of what was pushed was blocked.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[wm4]

On Tue, 3 Apr 2018 12:07:43 +0200
Vittorio Giovara  wrote:

> On Thu, Mar 29, 2018 at 03:30:43PM +0200, wm4 wrote:
> >* PSEUDOPAL pixel formats are not paletted, but carried a palette with the
> *>* intention of allowing code to treat unpaletted formats as paletted. The
> *>* palette simply mapped the byte values to the resulting RGB values,
> *>* making it some sort of LUT for RGB conversion.  
> *> >* It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,  
> *>* GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
> *>* formats. The last one, GRAY8, is more common, but its treatment is
> *>* grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
> *>* from typical Y video planes was not mapped to the correct RGB values.
> *>* Also, nothing actually used the PSEUDOPAL palette data, except xwdenc.
> *>* All other code had to treat it as a special case, just to ignore or
> *>* propagate palette data.  
> *> >* In conclusion, this was just a very strange old hack that has no real  
> *>* justification to exist. It's negatively useful, because API users who
> *>* allocate their own pixel data have to be aware that they need to
> *>* allocate the palette, or FFmpeg will crash on them in _some_ situations.
> *>* On top of this, there was no API to allocate the pseuo palette outside
> *>* of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not public,
> *>* which is good, because GRAY8 treatment is broken.)  
> *> >* This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also 
> makes  
> *>* the pseudo palette optional. Nothing accesses it anymore, though if it's
> *>* set, it's propagated. It's still allocated and initialized for
> *>* compatibility with API users that rely on this feature. But new API
> *>* users do not need to allocate it. This was an explicit goal of this
> *>* patch.  
> *> >* Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I  
> *>* first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
> *>* macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.  
> *> >* Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,  
> *>* FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
> *>* functions manually changed to not allocating a palette.
> *>* ---*  
> 
> set looks good to me

Thanks. Pushed with version bump/APIchanges entry added, and slightly
modified commit messages.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

On 4/3/2018 4:15 AM, wm4 wrote:
> So I think all what you've been writing can be reduced to: should this
> really be side data, or would it be better to just make it a new
> AVStream field.

I don't really have an opinion on this one way or another.

Do others?

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[wm4]

On Tue, 3 Apr 2018 17:06:03 +0100
Derek Buitenhuis  wrote:

> On 4/3/2018 4:15 AM, wm4 wrote:
> > So I think all what you've been writing can be reduced to: should this
> > really be side data, or would it be better to just make it a new
> > AVStream field.  
> 
> I don't really have an opinion on this one way or another.
> 
> Do others?

Uh no idea. One angle:

The idea with AVStream side data is that it can be attached as AVPacket
side data. So if an API user is fine with treating all kinds of side
data per AVPacket, it can call av_format_inject_global_side_data() and
ignore AVStream side data. Basically, you could ask the question
whether this kind of side data makes sense as per-AVPacket, and if not,
then it should be AVStream side data. Maybe.

Another angle is that the API better because side data would not add
yet another AVStream field. It makes the API more discoverable: the API
user can easily detect an unsupported side data type and handle it as
soon as he has a sample, instead of having to go over every AVStream
field during the initial implementation, and wondering what the hell it
does (and things going wrong when not handling explicitly). I probably
didn't word that too well, but I hope you get what I mean.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.

[Richard Shaffer]

On Tue, Apr 3, 2018 at 12:13 AM, Steven Liu  wrote:

>
>
> > On 3 Apr 2018, at 14:06, Richard Shaffer  wrote:
> >
> > On Mon, Apr 2, 2018 at 10:15 PM, Steven Liu  wrote:
> >>
> >>
> >>> On 3 Apr 2018, at 12:33, Richard Shaffer  wrote:
> >>>
> >>> On Mon, Apr 2, 2018 at 8:31 PM, Steven Liu  wrote:
> 
> 
> > On 3 Apr 2018, at 09:12, rshaf...@tunein.com wrote:
> >
> > From: Richard Shaffer 
> >
> > The rw_timeout option is currently not applied when opening media
> playlist,
> > segment, or encryption key URLs. This can cause the HLS demuxer to
> block
> > indefinitely, even when the rw_timeout option has been specified.
> This change
> > simply enables carrying over the rw_timeout option when the demuxer
> opens these
> > URLs.
> > ---
> > libavformat/hls.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index c578bf86e3..6663244ddf 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -1661,7 +1661,7 @@ static int save_avio_options(AVFormatContext
> *s)
> > {
> >   HLSContext *c = s->priv_data;
> >   static const char * const opts[] = {
> > -"headers", "http_proxy", "user_agent", "user-agent",
> "cookies", "referer", NULL };
> > +"headers", "http_proxy", "user_agent", "user-agent",
> "cookies", "referer", "rw_timeout", NULL };
>  This table is used for http header.
>  You could add the option into hls_options.
> >>>
> >>> Thanks for looking at the change. While the options currently in the
> >>> table are related to HTTP and rw_timeout is more general, I'm not
> >>> aware of a reason not to preserve the rw_timeout option here as well.
> >>> It seems unnecessary to define another HLS-specific option for
> >>> rw_timeout when the existing option exists and does what is intended.
> >>> I'm not sure whether you're objecting to the change and/or have a
> >>> different suggestion. Do you mind elaborating on your comment?
> >> Is the rw_timeout in to HTTP RFC? If yes, this is ok, If not, i think
> that is a ffmpeg option , not a http header content.
> >
> > http_proxy isn't tied to an HTTP header value, either. There isn't any
> > indication that avio_opts is intended for specifically HTTP options,
> > or that using it to store other avio options would break something. If
> > you have a reason why this shouldn't be used for other (non-HTTP)
> > options, can you please help me understand your thinking?
> >
> > I also want to spend some more time working on this, because I see
> > that there are multiple fields in HLSContext dealing with avio
> > options: There is the avio_opts field, but also referer, user_agent,
> > cookies, headers and http_proxy. avio_opts seems to be used when
> > opening segments and encryption key URIs, but the other fields are
> > used when reloading a playlist or parsing variant playlist URLs from a
> > master playlist. It's not clear why the options are stored in separate
> > places or whether that is necessary. If you have any insight into that
> > as well, it would be appreciated.
>
> Look at the code:
>
>  205 char *referer;   ///< holds HTTP referer set
> as an AVOption to the HTTP protocol context
>  206 char *user_agent;///< holds HTTP user agent
> set as an AVOption to the HTTP protocol context
>  207 char *cookies;   ///< holds HTTP cookie
> values set in either the initial response or as an AVOption to the HTTP
> protocol context
>  208 char *headers;   ///< holds HTTP headers set
> as an AVOption to the HTTP protocol context
>  209 char *http_proxy;///< holds the address of
> the HTTP proxy server
>
> There have some comment for the options.
> and reference the code in: hls_read_header / open_input and use the
> options.
>
>
That's pretty clear. What I was asking is why the options are stored both
in these fields as well as avio_opts, and this doesn't answer my question.
I was also asking why you object to storing the timeout option in
avio_opts, but I'm not understanding the logic in your responses.


> >
> >>>
> >   const char * const * opt = opts;
> >   uint8_t *buf;
> >   int ret = 0;
> > --
> > 2.15.1 (Apple Git-101)
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
>  Thanks
>  Steven
> 
> 
> 
> 
> 
> >>> ___
> >>> ffmpeg-devel mailing list
> >>> ffmpeg-devel@ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> Thanks
> >> Steven
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: fix possible null pointer dereference

[Michael Niedermayer]

On Tue, Apr 03, 2018 at 02:41:33PM +0200, Simon Thelen wrote:
> regression since 354b26a3945eadd4ed8fcd801dfefad2566241de
> ---
>  libavcodec/imgconvert.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Thanks alot !

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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/libaomdec: remove duplicate code

[James Almer]

On 4/1/2018 4:59 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
> libaom generates all files as I4xx16 right now, so the code i'm
> removing here is unused. And even if it ends up generating I4xx files
> down the road, it's safe to assume the bit_depth field in aom_image_t
> will still be populated.
> 

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

[FFmpeg-devel] No '.dav' conversion implemented?

[ykerb2]

Hi, i tried this 
ffmpeg -y -i /media/kerb/DVR-Video/NVR.dav -vcodec libx264 -crf 24 -filter:v 
"setpts=1*PTS" ~/Vidéos/ioutput-file.mp4

It says :
Error while decoding stream #0:0: Invalid data found when processing 
inputkbits/s
[NULL @ 0x198c340] missing picture in access unit with size 
39trate=1138.4kbits/s dup=1 drop=0
[h264 @ 0x2194000] data partitioning is not implemented. Update your FFmpeg 
version to the newest one from Git. If the problem still occurs, it means that 
your file has a feature which has not been implemented.
[h264 @ 0x2194000] If you want to help, upload a sample of this file to 
ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. 
(ffmpeg-devel@ffmpeg.org)
[h264 @ 0x2194000] no frame!
Error while decoding stream #0:0: Invalid data found when processing input

Is it that '.dav' is not implemented?
Do you want the file to improve? 

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/get_bits: add cached bitstream reader

[Michael Niedermayer]

On Tue, Apr 03, 2018 at 01:38:12PM +0200, Paul B Mahol wrote:
[...]

>  
> -static inline void skip_bits_long(GetBitContext *s, int n)
> +static inline void refill_32(GetBitContext *s)
>  {
> -#if UNCHECKED_BITSTREAM_READER
> -s->index += n;
> +#ifdef CACHED_BITSTREAM_READER
> +#if !UNCHECKED_BITSTREAM_READER
> +if (s->index >> 3 >= s->buffer_end - s->buffer)
> +return;
> +#endif
> +
> +#ifdef BITSTREAM_READER_LE
> +s->cache   = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << 
> s->bits_left | s->cache;
>  #else
> -s->index += av_clip(n, -s->index, s->size_in_bits_plus8 - s->index);
> +s->cache   = s->cache | (uint64_t)AV_RB32(s->buffer + (s->index >> 
> 3)) << (32 - s->bits_left);
> +#endif
> +s->index += 32;
> +s->bits_left += 32;
> +#endif
> +}

please split the movement of code into a seperate patch, this is unreadable


> +
> +static inline void refill_64(GetBitContext *s)
> +{
> +#ifdef CACHED_BITSTREAM_READER
> +#if !UNCHECKED_BITSTREAM_READER
> +if (s->index >> 3 >= s->buffer_end - s->buffer)
> +return;
> +#endif
> +
> +#ifdef BITSTREAM_READER_LE
> +s->cache = AV_RL64(s->buffer + (s->index >> 3));
> +#else
> +s->cache = AV_RB64(s->buffer + (s->index >> 3));
> +#endif
> +s->index += 64;
> +s->bits_left = 64;
> +#endif
> +}

all uses of refill_64 are under CACHED_BITSTREAM_READER, so there should
not be a need for an empty function
and the ifdef can be then merged with the next, simplifying the code


> +
> +#ifdef CACHED_BITSTREAM_READER
> +static inline uint64_t get_val(GetBitContext *s, unsigned n, int is_le)
> +{
> +uint64_t ret;
> +av_assert2(n>0 && n<=63);
> +if (is_le) {
> +ret = s->cache & ((UINT64_C(1) << n) - 1);
> +s->cache >>= n;
> +} else {
> +ret = s->cache >> (64 - n);
> +s->cache <<= n;
> +}
> +s->bits_left -= n;
> +return ret;
> +}
> +#endif
> +
> +#ifdef CACHED_BITSTREAM_READER

these 2 ifdef CACHED_BITSTREAM_READER can be merged


> +static inline unsigned show_val(const GetBitContext *s, unsigned n)
> +{
> +#ifdef BITSTREAM_READER_LE
> +return s->cache & ((UINT64_C(1) << n) - 1);
> +#else
> +return s->cache >> (64 - n);
> +#endif
> +}
> +#endif
> +

> +/**
> + * Show 1-25 bits.
> + */
> +static inline unsigned int show_bits(GetBitContext *s, int n)
> +{
> +register int tmp;
> +#ifdef CACHED_BITSTREAM_READER
> +if (n > s->bits_left)
> +refill_32(s);
> +
> +tmp = show_val(s, n);
> +#else
> +OPEN_READER_NOSIZE(re, s);
> +av_assert2(n>0 && n<=25);
> +UPDATE_CACHE(re, s);
> +tmp = SHOW_UBITS(re, s, n);
>  #endif
> +return tmp;
>  }

This is more moved code in which it is impossible to see what is changed


[...]
>  
> -static inline int get_sbits(GetBitContext *s, int n)
> +/**
> + * Read 1-25 bits.
> + */
> +static inline unsigned int get_bits(GetBitContext *s, int n)

also unreadable and confusing, the code moves make these matchup incorrectly


>  {
>  register int tmp;
> +#ifdef CACHED_BITSTREAM_READER
> +
> +av_assert2(n>0 && n<=32);
> +if (n > s->bits_left) {
> +refill_32(s);
> +if (s->bits_left < 32)
> +s->bits_left = n;
> +}
> +
> +#ifdef BITSTREAM_READER_LE
> +tmp = get_val(s, n, 1);
> +#else
> +tmp = get_val(s, n, 0);
> +#endif
> +#else
>  OPEN_READER(re, s);
>  av_assert2(n>0 && n<=25);
>  UPDATE_CACHE(re, s);
> -tmp = SHOW_SBITS(re, s, n);
> +tmp = SHOW_UBITS(re, s, n);
>  LAST_SKIP_BITS(re, s, n);
>  CLOSE_READER(re, s);
> +#endif
>  return tmp;
>  }
>  

> -/**
> - * Read 1-25 bits.
> - */
> -static inline unsigned int get_bits(GetBitContext *s, int n)
> +static inline int get_sbits(GetBitContext *s, int n)
>  {
>  register int tmp;
> +#ifdef CACHED_BITSTREAM_READER
> +av_assert2(n>0 && n<=25);
> +tmp = sign_extend(get_bits(s, n), n);
> +#else
>  OPEN_READER(re, s);
>  av_assert2(n>0 && n<=25);
>  UPDATE_CACHE(re, s);
> -tmp = SHOW_UBITS(re, s, n);
> +tmp = SHOW_SBITS(re, s, n);
>  LAST_SKIP_BITS(re, s, n);
>  CLOSE_READER(re, s);
> +#endif
>  return tmp;
>  }

more mismatched functions that are diffed against each other

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Michael Niedermayer]

On Tue, Apr 03, 2018 at 01:38:14PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/utvideodec.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
> index 82cb038ccd..99b37aa0f3 100644
> --- a/libavcodec/utvideodec.c
> +++ b/libavcodec/utvideodec.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  
> +#define CACHED_BITSTREAM_READER
>  #define UNCHECKED_BITSTREAM_READER 1
>  
>  #include "libavutil/intreadwrite.h"

tested, seems to work

thanks

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Increase support for common encryption.

[Jacob Trimble]

>>
>> Ping again.  I know this is low priority, but I would like to get
>> these merged soon.
>
> Ping.  Despite being almost 2 months old, these patches still apply
> cleanly.  Please take a look.  These have been in review for almost 3
> months.

Ping (going to keep pinging this until someone merges this or tells me
why not).  Day after tomorrow this will be in review for 4 months!!!

Also noticed a bug when integrating this, so here is an updated patch.
From 282effab6026341c49a52950cf8ba11afc9dc6aa Mon Sep 17 00:00:00 2001
From: Jacob Trimble 
Date: Wed, 6 Dec 2017 16:17:54 -0800
Subject: [PATCH] avformat/mov: Increase support for common encryption.

- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.

This doesn't support:
- Different sample descriptor holding different encryption info.
  - Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.

Signed-off-by: Jacob Trimble 
---
 libavformat/isom.h |  14 +
 libavformat/mov.c  | 396 -
 tests/fate/mov.mak |   8 +
 tests/ref/fate/mov-frag-encrypted  |  57 
 tests/ref/fate/mov-tenc-only-encrypted |  57 
 5 files changed, 450 insertions(+), 82 deletions(-)
 create mode 100644 tests/ref/fate/mov-frag-encrypted
 create mode 100644 tests/ref/fate/mov-tenc-only-encrypted

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 4da34142f0..eb942cf882 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#include "libavutil/encryption_info.h"
 #include "libavutil/mastering_display_metadata.h"
 #include "libavutil/spherical.h"
 #include "libavutil/stereo3d.h"
@@ -108,12 +109,20 @@ typedef struct MOVSbgp {
 unsigned int index;
 } MOVSbgp;
 
+typedef struct MOVEncryptionIndex {
+// Individual encrypted samples.  If there are no elements, then the default
+// settings will be used.
+unsigned int nb_encrypted_samples;
+AVEncryptionInfo **encrypted_samples;
+} MOVEncryptionIndex;
+
 typedef struct MOVFragmentStreamInfo {
 int id;
 int64_t sidx_pts;
 int64_t first_tfra_pts;
 int64_t tfdt_dts;
 int index_entry;
+MOVEncryptionIndex *encryption_index;
 } MOVFragmentStreamInfo;
 
 typedef struct MOVFragmentIndexItem {
@@ -215,6 +224,7 @@ typedef struct MOVStreamContext {
 
 int has_sidx;  // If there is an sidx entry for this stream.
 struct {
+// TODO: Remove once old methods are removed from mov.c
 int use_subsamples;
 uint8_t* auxiliary_info;
 uint8_t* auxiliary_info_end;
@@ -223,7 +233,11 @@ typedef struct MOVStreamContext {
 uint8_t* auxiliary_info_sizes;
 size_t auxiliary_info_sizes_count;
 int64_t auxiliary_info_index;
+
 struct AVAESCTR* aes_ctr;
+unsigned int per_sample_iv_size;  // Either 0, 8, or 16.
+AVEncryptionInfo *default_encrypted_sample;
+MOVEncryptionIndex *encryption_index;
 } cenc;
 } MOVStreamContext;
 
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e7c32e6148..8a83b0f805 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1330,6 +1330,7 @@ static int update_frag_index(MOVContext *c, int64_t offset)
 frag_stream_info[i].tfdt_dts = AV_NOPTS_VALUE;
 frag_stream_info[i].first_tfra_pts = AV_NOPTS_VALUE;
 frag_stream_info[i].index_entry = -1;
+frag_stream_info[i].encryption_index = NULL;
 }
 
 if (index < c->frag_index.nb_items)
@@ -5755,57 +5756,250 @@ static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 return 0;
 }
 
+/**
+ * Gets the current encryption info and associated current stream context.  If
+ * we are parsing a track fragment, this will return the specific encryption
+ * info for this fragment; otherwise this will return the global encryption
+ * info for the current stream.
+ */
+static int get_current_encryption_info(MOVContext *c, MOVEncryptionIndex **encryption_index, MOVStreamContext **sc)
+{
+MOVFragmentStreamInfo *frag_stream_info;
+AVStream *st;
+int i;
+
+frag_stream_info = get_current_frag_stream_info(&c->frag_index);
+if (frag_stream_info) {
+for (i = 0; i < c->fc->nb_streams; i++) {
+if (c->fc->streams[i]->id == frag_stream_info->id) {
+  st = c->fc->streams[i];
+  break;
+}
+}
+if (i == c->fc->nb_streams)
+return 0;
+*sc = st->priv_data;
+
+if (!frag_stream_info->encryption_index) {
+frag_stream_info->encryption_index = av_mallocz(sizeof(*frag_stream_info->encryption_index));
+if (!frag_stream_info->encryption_ind

Re: [FFmpeg-devel] [PATCH] use bcrypt instead of the old wincrypt API

[Michael Niedermayer]

On Tue, Apr 03, 2018 at 11:44:25AM +0200, Steve Lhomme wrote:
> Remove the wincrypt API calls since we don't support XP anymore and bcrypt is
> available since Vista, even on Windows Store builds.
> ---
>  configure   |  6 +++---
>  libavutil/random_seed.c | 19 ++-
>  2 files changed, 13 insertions(+), 12 deletions(-)

no build failures with this (compared to the last iteration)

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.

[Steven Liu]

>>
>> Look at the code:
>>
>>  205 char *referer;   ///< holds HTTP referer set
>> as an AVOption to the HTTP protocol context
>>  206 char *user_agent;///< holds HTTP user agent
>> set as an AVOption to the HTTP protocol context
>>  207 char *cookies;   ///< holds HTTP cookie
>> values set in either the initial response or as an AVOption to the HTTP
>> protocol context
>>  208 char *headers;   ///< holds HTTP headers set
>> as an AVOption to the HTTP protocol context
>>  209 char *http_proxy;///< holds the address of
>> the HTTP proxy server
>>
>> There have some comment for the options.
>> and reference the code in: hls_read_header / open_input and use the
>> options.
>>
>>
> That's pretty clear. What I was asking is why the options are stored both
> in these fields as well as avio_opts, and this doesn't answer my question.
> I was also asking why you object to storing the timeout option in
> avio_opts, but I'm not understanding the logic in your responses.

no logic problem, just that option be used to HTTP, is that ok?

BTW, how should i reproduce the problem you said?

"
The rw_timeout option is currently not applied when opening media playlist,
segment, or encryption key URLs. This can cause the HLS demuxer to block
indefinitely, even when the rw_timeout option has been specified. This change
simply enables carrying over the rw_timeout option when the demuxer opens these
URLs.
"

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.

[Steven Liu]

2018-04-04 7:53 GMT+08:00 Steven Liu :
>>>
>>> Look at the code:
>>>
>>>  205 char *referer;   ///< holds HTTP referer set
>>> as an AVOption to the HTTP protocol context
>>>  206 char *user_agent;///< holds HTTP user agent
>>> set as an AVOption to the HTTP protocol context
>>>  207 char *cookies;   ///< holds HTTP cookie
>>> values set in either the initial response or as an AVOption to the HTTP
>>> protocol context
>>>  208 char *headers;   ///< holds HTTP headers set
>>> as an AVOption to the HTTP protocol context
>>>  209 char *http_proxy;///< holds the address of
>>> the HTTP proxy server
>>>
>>> There have some comment for the options.
>>> and reference the code in: hls_read_header / open_input and use the
>>> options.
>>>
>>>
>> That's pretty clear. What I was asking is why the options are stored both
>> in these fields as well as avio_opts, and this doesn't answer my question.
>> I was also asking why you object to storing the timeout option in
>> avio_opts, but I'm not understanding the logic in your responses.
>
> no logic problem, just that option be used to HTTP, is that ok?
>
> BTW, how should i reproduce the problem you said?
>
> "
> The rw_timeout option is currently not applied when opening media playlist,
> segment, or encryption key URLs. This can cause the HLS demuxer to block
> indefinitely, even when the rw_timeout option has been specified. This change
> simply enables carrying over the rw_timeout option when the demuxer opens 
> these
> URLs.
> "

So i think add option timeout to do it maybe better than this way. you
can find another formats do it like this.
>
>>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse all ID3 tags present between ADTS frames

[Michael Niedermayer]

On Tue, Apr 03, 2018 at 07:58:53AM +0200, Mattias Amnefelt wrote:
> Yes, my feeling was also that it's better to handle this when possible.
> 
> You are of course correct that the two tags needs to be inbetween frames.
> Sorry about that, I stripped the sample down too much. I updated with a
> sample which has two frames. This new sample fails the test without the
> patch.
> 
> /mattiasa
> 
> On 2018-04-02 23:25, Richard Shaffer wrote:
> >It seems like some software can insert an additional ID3v2 tag instead
> >of appending a frame to an existing one. One could argue that that is
> >somewhat broken, but I agree it's better to handle it instead of
> >returning an error. The changes in aacdec.c look ok to me.
> >
> >The fate sample you provided has two tags at the beginning of the
> >file. These will actually get parsed by avformat_open_input calling
> >ff_id3v2_read_dict and not by the adts demuxer. The ff_id3v2_read_dict
> >code path will already parse multiple tags, which is why the test
> >passes. In order to exercise your code change, the ID3v2 tags would
> >have to be between ADTS frames.
> >
> >-Richard
> >
> >On Mon, Apr 2, 2018 at 4:35 AM, Mattias Amnefelt  wrote:
> >>This is a follow-up to https://patchwork.ffmpeg.org/patch/7477/ and changes
> >>so all ID3 tags between ADTS frames gets parsed, not just the first one.
> >>
> >>Sample media for the included fate test is available at
> >>http://mattias.amnefe.lt/tmp/id3v2_two_tags.aac
> >>
> >>
> >>
> >>___
> >>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
> 
> 

>  libavformat/aacdec.c |   14 
>  tests/fate/demux.mak |3 
>  tests/ref/fate/adts-id3v2-two-tags-demux |  475 
> +++
>  3 files changed, 486 insertions(+), 6 deletions(-)
> 95d2c77bc7fa82503377e09da98fe17e1b3eb302  
> 0001-libavformat-aac-Parse-all-ID3-tags-present-between-A.patch
> From 8d587983b6cc5c535e29f0898d4cac433cd0a609 Mon Sep 17 00:00:00 2001
> From: Mattias Amnefelt 
> Date: Mon, 2 Apr 2018 11:30:40 +0200
> Subject: [PATCH] libavformat/aac: Parse all ID3 tags present between ADTS
>  frames
> 
> Some ADTS streams can have multiple ID3 tags between frames. This
> change parses all of them, rather than just the first one.

uploaded aac fate sample

the patch should be ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement

[Michael Niedermayer]

On Sun, Apr 01, 2018 at 11:42:34PM +0200, Bodecs Bela wrote:
> Dear All,
> 
> currently when specifying the program id you can only decide to select
> all stream of the specified program (e.g. p:103 will select all streams
> of program 103) or narrow the selection to a specific stream sub index
> (e.g. p:145:1 will select 2nd stream of program 145.) But you can not
> specify like all audio streams of program 145 or 3rd video stream of
> program 311.
> In some case, mainly working with multiprogram mpeg-ts containers as
> input, this feature would be handy.
> This patch makes it possible to narrow the stream selection among
> streams of the specified program by stream type and optionally its
> index. Handled types: a, v, s, d.
> Examples: p:601:a  will select all audio streams of program 601,
> p:603:a:1 will select 2nd audio streams of program 603,
> p:604:v:0 will select first video stream of program 604.
> This syntax enhancement does not interfere in any way with
> current/exiting syntax or working command lines

I think this is a good idea.
Can you also add fate test(s) for this ? (can be in a seperate patch
later of course)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: fix failure to decode PAFF

[Aman Gupta]

On Wed, Mar 28, 2018 at 9:19 PM, Rodger Combs 
wrote:

> ---
>  libavcodec/videotoolbox.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index f82c31c5df..57b6698e1b 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -326,11 +326,8 @@ static int videotoolbox_set_frame(AVCodecContext
> *avctx, AVFrame *frame)
>
>  CVPixelBufferRef *ref = (CVPixelBufferRef *)frame->buf[0]->data;
>
> -if (*ref) {
> -av_log(avctx, AV_LOG_ERROR, "videotoolbox: frame already set?\n");
> -av_frame_unref(frame);
> -return AVERROR_EXTERNAL;
> -}
> +if (*ref)
> +CVPixelBufferRelease(*ref);
>
>  *ref = vtctx->frame;
>  vtctx->frame = NULL;
>

LGTM. Do you have a sample PAFF file that now works after this patch?

Aman


> --
> 2.16.2
>
> ___
> 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] libavformat/aac: Parse all ID3 tags present between ADTS frames

[Carl Eugen Hoyos]

2018-04-03 7:58 GMT+02:00, Mattias Amnefelt :
> Yes, my feeling was also that it's better to handle this when possible.
>
> You are of course correct that the two tags needs to be inbetween
> frames. Sorry about that, I stripped the sample down too much. I updated
> with a sample which has two frames. This new sample fails the test
> without the patch.

> +fate-adts-id3v2-two-tags-demux: CMD = framecrc -f aac -i 
> $(TARGET_SAMPLES)/aac/id3v2_two_tags.aac -c:a copy

The "-f aac" looks like a bad idea to me.
It's also true for the tests above, but that's still not reason to
add more.

Please avoid top-posting here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse all ID3 tags present between ADTS frames

[James Almer]

On 4/3/2018 10:33 PM, Carl Eugen Hoyos wrote:
> 2018-04-03 7:58 GMT+02:00, Mattias Amnefelt :
>> Yes, my feeling was also that it's better to handle this when possible.
>>
>> You are of course correct that the two tags needs to be inbetween
>> frames. Sorry about that, I stripped the sample down too much. I updated
>> with a sample which has two frames. This new sample fails the test
>> without the patch.
> 
>> +fate-adts-id3v2-two-tags-demux: CMD = framecrc -f aac -i 
>> $(TARGET_SAMPLES)/aac/id3v2_two_tags.aac -c:a copy
> 
> The "-f aac" looks like a bad idea to me.
> It's also true for the tests above, but that's still not reason to
> add more.
> 
> Please avoid top-posting here, Carl Eugen

At least in one of them it was added because the sample had too few
frames and probing was detecting it with a score of 1, which seemed too
fragile.
If that's not the case with this new sample then i agree with you it's
not a good idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] doc/libav-merge: bitstream reader is now merged

[Carl Eugen Hoyos]

2018-04-03 13:38 GMT+02:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  doc/libav-merge.txt | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
> index 4ba08fc588..6821d0f196 100644
> --- a/doc/libav-merge.txt
> +++ b/doc/libav-merge.txt
> @@ -95,7 +95,6 @@ Stuff that didn't reach the codebase:
>- 0cef06df0 checkasm: add HEVC MC tests
>- e7078e842 hevcdsp: add x86 SIMD for MC
>- 7993ec19a hevc: Add hevc_get_pixel_4/8/12/16/24/32/48/64
> -- new bitstream reader (see
> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html)

Could be merged into the first patch.

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utvideodec: use cached bitstream reader

[Carl Eugen Hoyos]

2018-04-03 13:38 GMT+02:00, Paul B Mahol :
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/utvideodec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
> index 82cb038ccd..99b37aa0f3 100644
> --- a/libavcodec/utvideodec.c
> +++ b/libavcodec/utvideodec.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>
> +#define CACHED_BITSTREAM_READER

Some numbers in the commit message would make
sense imo.

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

Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse all ID3 tags present between ADTS frames

[Carl Eugen Hoyos]

2018-04-04 3:38 GMT+02:00, James Almer :
> On 4/3/2018 10:33 PM, Carl Eugen Hoyos wrote:
>> 2018-04-03 7:58 GMT+02:00, Mattias Amnefelt :
>>> Yes, my feeling was also that it's better to handle this when possible.
>>>
>>> You are of course correct that the two tags needs to be inbetween
>>> frames. Sorry about that, I stripped the sample down too much. I updated
>>> with a sample which has two frames. This new sample fails the test
>>> without the patch.
>>
>>> +fate-adts-id3v2-two-tags-demux: CMD = framecrc -f aac -i
>>> $(TARGET_SAMPLES)/aac/id3v2_two_tags.aac -c:a copy
>>
>> The "-f aac" looks like a bad idea to me.
>> It's also true for the tests above, but that's still not reason to
>> add more.
>>
>> Please avoid top-posting here, Carl Eugen
>
> At least in one of them it was added because the sample had too few
> frames and probing was detecting it with a score of 1, which seemed too
> fragile.

I believe that it is good to have a sample that is detected with
a small score as part of fate.

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

Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse all ID3 tags present between ADTS frames

[James Almer]

On 4/3/2018 10:40 PM, Carl Eugen Hoyos wrote:
> 2018-04-04 3:38 GMT+02:00, James Almer :
>> On 4/3/2018 10:33 PM, Carl Eugen Hoyos wrote:
>>> 2018-04-03 7:58 GMT+02:00, Mattias Amnefelt :
 Yes, my feeling was also that it's better to handle this when possible.

 You are of course correct that the two tags needs to be inbetween
 frames. Sorry about that, I stripped the sample down too much. I updated
 with a sample which has two frames. This new sample fails the test
 without the patch.
>>>
 +fate-adts-id3v2-two-tags-demux: CMD = framecrc -f aac -i
 $(TARGET_SAMPLES)/aac/id3v2_two_tags.aac -c:a copy
>>>
>>> The "-f aac" looks like a bad idea to me.
>>> It's also true for the tests above, but that's still not reason to
>>> add more.
>>>
>>> Please avoid top-posting here, Carl Eugen
>>
>> At least in one of them it was added because the sample had too few
>> frames and probing was detecting it with a score of 1, which seemed too
>> fragile.
> 
> I believe that it is good to have a sample that is detected with
> a small score as part of fate.
> 
> Carl Eugen

When i asked it was suggested to just force the demuxer. I have no
opinion one way or another, so feel free to change it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_scale: Set full range for RGB formats

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_scale.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f741419e7e..bd5c63aa9b 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -406,6 +406,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 AVFilterLink *outlink = link->dst->outputs[0];
 AVFrame *out;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
+const AVPixFmtDescriptor *out_desc = av_pix_fmt_desc_get(outlink->format);
 char buf[32];
 int in_range;
 
@@ -496,7 +497,11 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
  table, out_full,
  brightness, contrast, saturation);
 
-out->color_range = out_full ? AVCOL_RANGE_JPEG : AVCOL_RANGE_MPEG;
+// color_range describes YUV, it is undefined for RGB
+if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) && out_desc->nb_components 
!= 1) {
+out->color_range = AVCOL_RANGE_JPEG;
+} else
+out->color_range = out_full ? AVCOL_RANGE_JPEG : AVCOL_RANGE_MPEG;
 }
 
 av_reduce(&out->sample_aspect_ratio.num, &out->sample_aspect_ratio.den,
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Michael Niedermayer]

On Tue, Apr 03, 2018 at 01:30:32AM +0200, Michael Niedermayer wrote:
> On Mon, Apr 02, 2018 at 11:52:42AM +0200, Vittorio Giovara wrote:
> > On 3/20/18, Michael Niedermayer  > > wrote:
> > >* Signed-off-by: Michael Niedermayer  > >>
> > *>* ---
> > *>*  libavfilter/vf_scale.c | 7 ++-
> > *>*  1 file changed, 6 insertions(+), 1 deletion(-)
> > *>>* diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > *>* index 9f45032e85..2f6fa4791d 100644
> > *>* --- a/libavfilter/vf_scale.c
> > *>* +++ b/libavfilter/vf_scale.c
> > *>* @@ -407,6 +407,7 @@ static int filter_frame(AVFilterLink *link, AVFrame 
> > *in)
> > *>*  AVFilterLink *outlink = link->dst->outputs[0];
> > *>*  AVFrame *out;
> > *>*  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
> > *>* +const AVPixFmtDescriptor *out_desc =
> > *>* av_pix_fmt_desc_get(outlink->format);
> > *>*  char buf[32];
> > *>*  int in_range;
> > *>>* @@ -497,7 +498,11 @@ static int filter_frame(AVFilterLink *link, 
> > AVFrame
> > *>* *in)
> > *>*   table, out_full,
> > *>*   brightness, contrast, saturation);
> > *>>* -out->color_range = out_full ? AVCOL_RANGE_JPEG : 
> > AVCOL_RANGE_MPEG;
> > *>* +// color_range describes YUV, it is undefined for RGB
> > *>* +if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) &&
> > *>* out_desc->nb_components != 1) {
> > *>* +out->color_range = AVCOL_RANGE_UNSPECIFIED;
> > *>* +} else
> > *>* +out->color_range = out_full ? AVCOL_RANGE_JPEG :
> > *>* AVCOL_RANGE_MPEG;
> > *>*  }
> > *>>*  av_reduce(&out->sample_aspect_ratio.num,
> > &out->sample_aspect_ratio.den,
> > *>* --
> > *>* 2.16.2
> > *
> > 
> > shouldn't color_range be always set to FULL when outputting RGB? This would
> > simplify conversions towards YUV (which assumes UNSPEC == LIMITED) and
> > something that other libraries already assume (ie zimg).
> 
> ill need to test but if FULL simplifies things, it could be used instead
> yes

will post a patch that does this

thx


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: allow setting attached_pic disposition

[Michael Niedermayer]

On Mon, Apr 02, 2018 at 11:36:56AM +0300, Timo Teräs wrote:
> This is used to signal that image should be stored in metadata
> as cover image.
> 
> Signed-off-by: Timo Teräs 
> ---
>  fftools/ffmpeg.c | 1 +
>  1 file changed, 1 insertion(+)

will apply
thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/movenc: add rtp_hinting_needed() helper function

[Michael Niedermayer]

On Mon, Apr 02, 2018 at 11:36:57AM +0300, Timo Teräs wrote:
> This is shared test and this simplifies code a bit. Follow up
> commit will have additional tests for this function.
> 
> Signed-off-by: Timo Teräs 
> ---
>  libavformat/movenc.c | 30 --
>  1 file changed, 12 insertions(+), 18 deletions(-)

will apply

thx

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH 1/5 v2] avformat/utils: make AVPacketList helper functions shared

[James Almer]

On 3/30/2018 2:28 PM, James Almer wrote:
> On 3/27/2018 7:48 PM, James Almer wrote:
>> Based on a patch by Luca Barbato.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/internal.h | 38 +
>>  libavformat/utils.c| 57 
>> +-
>>  2 files changed, 71 insertions(+), 24 deletions(-)
> 
> Ping.

I'll push this set later tonight or tomorrow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] No '.dav' conversion implemented?

[Carl Eugen Hoyos]

2018-04-03 17:56 GMT+02:00, yke...@free.fr :

> [h264 @ 0x2194000] data partitioning is not implemented. Update your FFmpeg
> version to the newest one from Git. If the problem still occurs, it means
> that your file has a feature which has not been implemented.

Please provide the sample.

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

Re: [FFmpeg-devel] [PATCH 1/5 v2] avformat/utils: make AVPacketList helper functions shared

[James Almer]

On 4/3/2018 10:57 PM, James Almer wrote:
> On 3/30/2018 2:28 PM, James Almer wrote:
>> On 3/27/2018 7:48 PM, James Almer wrote:
>>> Based on a patch by Luca Barbato.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavformat/internal.h | 38 +
>>>  libavformat/utils.c| 57 
>>> +-
>>>  2 files changed, 71 insertions(+), 24 deletions(-)
>>
>> Ping.
> 
> I'll push this set later tonight or tomorrow.

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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the general developers list

[Steven Liu]

> On 3 Apr 2018, at 11:29, Steven Liu  wrote:
> 
> 
> 
>> On 3 Apr 2018, at 07:24, Jun Zhao  wrote:
>> 
>> Want to close work with this community, so I request as
>> a general developer.
>> <0001-MAINTAINERS-add-myself-to-the-general-developers-lis.patch>___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> LGTM

Pushed

Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the general developers list

[Steven Liu]

> On 4 Apr 2018, at 12:06, Steven Liu  wrote:
> 
> 
> 
>> On 3 Apr 2018, at 11:29, Steven Liu  wrote:
>> 
>> 
>> 
>>> On 3 Apr 2018, at 07:24, Jun Zhao  wrote:
>>> 
>>> Want to close work with this community, so I request as
>>> a general developer.
>>> <0001-MAINTAINERS-add-myself-to-the-general-developers-lis.patch>___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> LGTM
> 
> Pushed
No, not pushed, ignore this one
> 
> Thanks
> Steven
> 
> 
> 

Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH] lavf/hls: Remove the dead code in parse_playlist()

[Steven Liu]

> On 2 Apr 2018, at 10:18, Steven Liu  wrote:
> 
> 
> 
>> On 2 Apr 2018, at 07:09, Jun Zhao  wrote:
>> 
>> <0001-lavf-hls-Remove-the-dead-code-in-parse_playlist.patch>
> 
> From 96de206d191264d2a5aacff5f877caad1d861439 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Sun, 1 Apr 2018 11:17:45 +0800
> Subject: [PATCH] lavf/hls: Remove the dead code in  parse_playlist()
> 
> Signed-off-by: Jun Zhao 
> ---
> libavformat/hls.c | 7 ---
> 1 file changed, 7 deletions(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index c578bf86e3..ae0545a086 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -743,7 +743,6 @@ static int parse_playlist(HLSContext *c, const char *url,
> }
> 
> if (!in) {
> -#if 1
> AVDictionary *opts = NULL;
> /* Some HLS servers don't like being sent the range header */
> av_dict_set(&opts, "seekable", "0", 0);
> @@ -766,12 +765,6 @@ static int parse_playlist(HLSContext *c, const char *url,
> c->playlist_pb = in;
> else
> close_in = 1;
> -#else
> -ret = open_in(c, &in, url);
> -if (ret < 0)
> -return ret;
> -close_in = 1;
> -#endif
> }
> 
> if (av_opt_get(in, "location", AV_OPT_SEARCH_CHILDREN, &new_url) >= 0)
> -- 
> 2.14.1
> 
> 
> 
> 
> 
> should be ok!
Pushed
> 
> Thanks
> Steven
> 
> 
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





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

[FFmpeg-devel] [PATCH] avformat/flacenc: support writing attached pictures

[James Almer]

From: Rodger Combs 

Signed-off-by: James Almer 
---
Now using the packet list API instead of duplicating the code locally.

 libavformat/flacenc.c | 274 +++---
 1 file changed, 238 insertions(+), 36 deletions(-)

diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index b894f9ef61..99f4ce7bad 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -21,10 +21,13 @@
 
 #include "libavutil/channel_layout.h"
 #include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
 #include "libavcodec/flac.h"
 #include "avformat.h"
 #include "avio_internal.h"
 #include "flacenc.h"
+#include "id3v2.h"
+#include "internal.h"
 #include "vorbiscomment.h"
 #include "libavcodec/bytestream.h"
 
@@ -33,8 +36,16 @@ typedef struct FlacMuxerContext {
 const AVClass *class;
 int write_header;
 
+int audio_stream_idx;
+AVPacket *pics;
+int nb_pics, waiting_pics;
+/* audio packets are queued here until we get all the attached pictures */
+AVPacketList *queue, *queue_end;
+
 /* updated streaminfo sent by the encoder at the end */
 uint8_t *streaminfo;
+
+unsigned attached_types;
 } FlacMuxerContext;
 
 static int flac_write_block_padding(AVIOContext *pb, unsigned int 
n_padding_bytes,
@@ -74,31 +85,157 @@ static int flac_write_block_comment(AVIOContext *pb, 
AVDictionary **m,
 return 0;
 }
 
-static int flac_write_header(struct AVFormatContext *s)
+static int flac_write_picture(struct AVFormatContext *s, AVPacket *pkt)
 {
-int ret;
-int padding = s->metadata_header_padding;
-AVCodecParameters *par = s->streams[0]->codecpar;
-FlacMuxerContext *c   = s->priv_data;
-
-if (!c->write_header)
+FlacMuxerContext *c = s->priv_data;
+AVIOContext *pb = s->pb;
+const AVPixFmtDescriptor *pixdesc;
+const CodecMime *mime = ff_id3v2_mime_tags;
+AVDictionaryEntry *e;
+const char *mimetype = NULL, *desc = "";
+const AVStream *st = s->streams[pkt->stream_index];
+int i, mimelen, desclen, type = 0;
+
+if (!pkt->data)
 return 0;
 
-if (s->nb_streams > 1) {
-av_log(s, AV_LOG_ERROR, "only one stream is supported\n");
+while (mime->id != AV_CODEC_ID_NONE) {
+if (mime->id == st->codecpar->codec_id) {
+mimetype = mime->str;
+break;
+}
+mime++;
+}
+if (!mimetype) {
+av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d, cannot "
+   "write an attached picture.\n", st->index);
+return AVERROR(EINVAL);
+}
+mimelen = strlen(mimetype);
+
+/* get the picture type */
+e = av_dict_get(st->metadata, "comment", NULL, 0);
+for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
+if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
+type = i;
+break;
+}
+}
+
+if ((c->attached_types & (1 << type)) & 0x6) {
+av_log(s, AV_LOG_ERROR, "Duplicate attachment for type '%s'\n", 
ff_id3v2_picture_types[type]);
 return AVERROR(EINVAL);
 }
-if (par->codec_id != AV_CODEC_ID_FLAC) {
-av_log(s, AV_LOG_ERROR, "unsupported codec\n");
+
+if (type == 1 && (st->codecpar->codec_id != AV_CODEC_ID_PNG ||
+  st->codecpar->width != 32 ||
+  st->codecpar->height != 32)) {
+av_log(s, AV_LOG_ERROR, "File icon attachment must be a 32x32 PNG");
 return AVERROR(EINVAL);
 }
 
+c->attached_types |= (1 << type);
+
+/* get the description */
+if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
+desc = e->value;
+desclen = strlen(desc);
+
+avio_w8(pb, 0x06);
+avio_wb24(pb, 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 + 
pkt->size);
+
+avio_wb32(pb, type);
+
+avio_wb32(pb, mimelen);
+avio_write(pb, mimetype, mimelen);
+
+avio_wb32(pb, desclen);
+avio_write(pb, desc, desclen);
+
+avio_wb32(pb, st->codecpar->width);
+avio_wb32(pb, st->codecpar->height);
+if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
+avio_wb32(pb, av_get_bits_per_pixel(pixdesc));
+else
+avio_wb32(pb, 0);
+avio_wb32(pb, 0);
+
+avio_wb32(pb, pkt->size);
+avio_write(pb, pkt->data, pkt->size);
+return 0;
+}
+
+static int flac_finish_header(struct AVFormatContext *s)
+{
+FlacMuxerContext *c = s->priv_data;
+int i, ret, padding = s->metadata_header_padding;
 if (padding < 0)
 padding = 8192;
 /* The FLAC specification states that 24 bits are used to represent the
  * size of a metadata block so we must clip this value to 2^24-1. */
 padding = av_clip_uintp2(padding, 24);
 
+for (i = 0; i < c->nb_pics; i++) {
+ret = flac_write_picture(s, &c->pics[i]);
+av_packet_unref(&c->pics[i]);
+if (ret)
+return ret;
+}
+
+ret = flac_write_block_comment(s->pb, &s->metadata, !padding,
+   

Re: [FFmpeg-devel] [PATCH] avformat/flacenc: support writing attached pictures

[Timo Teras]

On Wed,  4 Apr 2018 01:30:54 -0300
James Almer  wrote:

> From: Rodger Combs 
> 
> Signed-off-by: James Almer 
> ---
> Now using the packet list API instead of duplicating the code locally.
> 
>  libavformat/flacenc.c | 274
> +++--- 1 file changed,
> 238 insertions(+), 36 deletions(-)
> 
> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index b894f9ef61..99f4ce7bad 100644
>[snip]
> -c->streaminfo = av_malloc(FLAC_STREAMINFO_SIZE);
> -if (!c->streaminfo)
> -return AVERROR(ENOMEM);
> -memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
> +/* warn only once for each stream */
> +if (s->streams[pkt->stream_index]->nb_frames == 1) {
> +av_log(s, AV_LOG_WARNING, "Got more than one picture in
> stream %d,"
> +   " ignoring.\n", pkt->stream_index);
> +}
> +if (!c->waiting_pics ||
> s->streams[pkt->stream_index]->nb_frames >= 1)
> +return 0;
> +
> +if (index > c->audio_stream_idx)
> +index--;
> +
> +if ((ret = av_packet_ref(&c->pics[index], pkt)) < 0)
> +return ret;
> +c->waiting_pics--;
> +
> +/* flush the buffered audio packets */
> +if (!c->waiting_pics &&
> +(ret = flac_queue_flush(s)) < 0)
> +return ret;
>  }
>  
> -if (pkt->size)
> -avio_write(s->pb, pkt->data, pkt->size);
>  return 0;
>  }
>  

I've submitted attached picture support to movenc just now. Instead of
defining separate pictures queue, I'm reusing the AVStream.attached_pic
to hold it. Would it make sense to share this small piece of code in
some utility function (and use also AVStream.attached_pic here)?

See: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227708.html


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

Re: [FFmpeg-devel] [PATCH] avformat/flacenc: support writing attached pictures

[James Almer]

On 4/4/2018 2:11 AM, Timo Teras wrote:
> On Wed,  4 Apr 2018 01:30:54 -0300
> James Almer  wrote:
> 
>> From: Rodger Combs 
>>
>> Signed-off-by: James Almer 
>> ---
>> Now using the packet list API instead of duplicating the code locally.
>>
>>  libavformat/flacenc.c | 274
>> +++--- 1 file changed,
>> 238 insertions(+), 36 deletions(-)
>>
>> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
>> index b894f9ef61..99f4ce7bad 100644
>> [snip]
>> -c->streaminfo = av_malloc(FLAC_STREAMINFO_SIZE);
>> -if (!c->streaminfo)
>> -return AVERROR(ENOMEM);
>> -memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
>> +/* warn only once for each stream */
>> +if (s->streams[pkt->stream_index]->nb_frames == 1) {
>> +av_log(s, AV_LOG_WARNING, "Got more than one picture in
>> stream %d,"
>> +   " ignoring.\n", pkt->stream_index);
>> +}
>> +if (!c->waiting_pics ||
>> s->streams[pkt->stream_index]->nb_frames >= 1)
>> +return 0;
>> +
>> +if (index > c->audio_stream_idx)
>> +index--;
>> +
>> +if ((ret = av_packet_ref(&c->pics[index], pkt)) < 0)
>> +return ret;
>> +c->waiting_pics--;
>> +
>> +/* flush the buffered audio packets */
>> +if (!c->waiting_pics &&
>> +(ret = flac_queue_flush(s)) < 0)
>> +return ret;
>>  }
>>  
>> -if (pkt->size)
>> -avio_write(s->pb, pkt->data, pkt->size);
>>  return 0;
>>  }
>>  
> 
> I've submitted attached picture support to movenc just now. Instead of
> defining separate pictures queue, I'm reusing the AVStream.attached_pic
> to hold it. Would it make sense to share this small piece of code in
> some utility function (and use also AVStream.attached_pic here)?
> 
> See: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227708.html

What's being done in this patch is not a picture queue, but an audio
packet queue until the first video frame (the picture to be attached)
shows up, and then all the audio is flushed to the output.

(Re-sending to the mailing list now, since my email client is kinda
stupid with its reply button in some situations)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/flacenc: support writing attached pictures

[Timo Teras]

On Wed, 4 Apr 2018 02:30:34 -0300
James Almer  wrote:

> On 4/4/2018 2:11 AM, Timo Teras wrote:
> > On Wed,  4 Apr 2018 01:30:54 -0300
> > James Almer  wrote:
> > 
> >> From: Rodger Combs 
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> Now using the packet list API instead of duplicating the code
> >> locally.
> >>
> >>  libavformat/flacenc.c | 274
> >> +++--- 1 file changed,
> >> 238 insertions(+), 36 deletions(-)
> >>
> >> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> >> index b894f9ef61..99f4ce7bad 100644
> >> [snip]
> >> -c->streaminfo = av_malloc(FLAC_STREAMINFO_SIZE);
> >> -if (!c->streaminfo)
> >> -return AVERROR(ENOMEM);
> >> -memcpy(c->streaminfo, streaminfo, FLAC_STREAMINFO_SIZE);
> >> +/* warn only once for each stream */
> >> +if (s->streams[pkt->stream_index]->nb_frames == 1) {
> >> +av_log(s, AV_LOG_WARNING, "Got more than one picture
> >> in stream %d,"
> >> +   " ignoring.\n", pkt->stream_index);
> >> +}
> >> +if (!c->waiting_pics ||
> >> s->streams[pkt->stream_index]->nb_frames >= 1)
> >> +return 0;
> >> +
> >> +if (index > c->audio_stream_idx)
> >> +index--;
> >> +
> >> +if ((ret = av_packet_ref(&c->pics[index], pkt)) < 0)
> >> +return ret;
> >> +c->waiting_pics--;
> >> +
> >> +/* flush the buffered audio packets */
> >> +if (!c->waiting_pics &&
> >> +(ret = flac_queue_flush(s)) < 0)
> >> +return ret;
> >>  }
> >>  
> >> -if (pkt->size)
> >> -avio_write(s->pb, pkt->data, pkt->size);
> >>  return 0;
> >>  }
> >>  
> > 
> > I've submitted attached picture support to movenc just now. Instead
> > of defining separate pictures queue, I'm reusing the
> > AVStream.attached_pic to hold it. Would it make sense to share this
> > small piece of code in some utility function (and use also
> > AVStream.attached_pic here)?
> > 
> > See:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227708.html
> 
> What's being done in this patch is not a picture queue, but an audio
> packet queue until the first video frame (the picture to be attached)
> shows up, and then all the audio is flushed to the output.

Sorry for using word 'queue'. But to me you are adding "AVPacket *pics;"
which is practically "a queue" of one packet or just a packet store for
picture per stream. Pictures are stored there until all of them are
received. I do the same, I just store it in the existing
AVStream.attached_pic. So this is exactly the same functional thing.
Please see my patch: the first hunk, and second last hunk modifying
mov_write_packet().

My suggestion is to have helper function like
avformat_set_attached_picture() or similar that would reference given
AVPacket in AVStream.attached_pic and handle the warning logging and
discarding of extra packets. Would this work?

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