Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors

[Mateusz]

W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze:
> Am 07.12.2017 20:40 schrieb "Mateusz" :
> 
> W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
>> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz  wrote:
>>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
>>> we have included windows.h in much more files and we should
>>> avoid conflicts with defines/function declarations.
>>>
>>> We should declare compatible variables for atomic compat wrappers
>>> that expect fixed size variables in atomic_compare_exchange* macro.
>>>
>>> Signed-off-by: Mateusz Brzostek 
>>> ---
>>>  libavcodec/jpegls.h   |  2 ++
>>>  libavcodec/mjpegdec.h |  2 ++
>>>  libavcodec/mss2.c |  6 +++---
>>>  libavcodec/utils.c| 12 
>>>  libavformat/mxfenc.c  |  2 +-
>>>  5 files changed, 20 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/jpegls.h b/libavcodec/jpegls.h
>>> index c8997c7861..6b89b2afa3 100644
>>> --- a/libavcodec/jpegls.h
>>> +++ b/libavcodec/jpegls.h
>>> @@ -32,6 +32,8 @@
>>>  #include "avcodec.h"
>>>  #include "internal.h"
>>>
>>> +#undef near /* This file uses struct member 'near' which in windows.h
> is defined as empty. */
>>> +
>>>  typedef struct JpeglsContext {
>>>  AVCodecContext *avctx;
>>>  } JpeglsContext;
>>> diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
>>> index c84a40aa6e..c36fba5f22 100644
>>> --- a/libavcodec/mjpegdec.h
>>> +++ b/libavcodec/mjpegdec.h
>>> @@ -39,6 +39,8 @@
>>>  #include "hpeldsp.h"
>>>  #include "idctdsp.h"
>>>
>>> +#undef near /* This file uses struct member 'near' which in windows.h
> is defined as empty. */
>>> +
>>>  #define MAX_COMPONENTS 4
>>>
>>>  typedef struct MJpegDecodeContext {
>>> diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
>>> index 9e7cc466de..3180af1d60 100644
>>> --- a/libavcodec/mss2.c
>>> +++ b/libavcodec/mss2.c
>>> @@ -464,9 +464,9 @@ static int decode_wmv9(AVCodecContext *avctx, const
> uint8_t *buf, int buf_size,
>>>  return 0;
>>>  }
>>>
>>> -typedef struct Rectangle {
>>> +struct Rectangle {
>>>  int coded, x, y, w, h;
>>> -} Rectangle;
>>> +};
>>>
>>>  #define MAX_WMV9_RECTANGLES 20
>>>  #define ARITH2_PADDING 2
>>> @@ -485,7 +485,7 @@ static int mss2_decode_frame(AVCodecContext *avctx,
> void *data, int *got_frame,
>>>
>>>  int keyframe, has_wmv9, has_mv, is_rle, is_555, ret;
>>>
>>> -Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>>> +struct Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>>>  int used_rects = 0, i, implicit_rect = 0, av_uninit(wmv9_mask);
>>>
>>>  if ((ret = init_get_bits8(, buf, buf_size)) < 0)
>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>> index baf09119fe..70a0764714 100644
>>> --- a/libavcodec/utils.c
>>> +++ b/libavcodec/utils.c
>>> @@ -1943,7 +1943,13 @@ int av_lockmgr_register(int (*cb)(void **mutex,
> enum AVLockOp op))
>>>
>>>  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>>  {
>>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) &&
> !defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>>> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) &&
> !defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>>>  _Bool exp = 0;
>>> +#else
>>> +atomic_bool exp = 0;
>>> +#endif
>>> +
>>>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> !codec->init)
>>>  return 0;
>>>
>>> @@ -1969,7 +1975,13 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
> const AVCodec *codec)
>>>
>>>  int ff_unlock_avcodec(const AVCodec *codec)
>>>  {
>>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) &&
> !defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>>> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) &&
> !defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>>>  _Bool exp = 1;
>>> +#else
>>> +atomic_bool exp = 1;
>>> +#endif
>>> +
>>>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
> !codec->init)
>>>  return 0;
>>>
>>
>> These ifdefs here are very ugly, and as mentioned in another mail, the
>> atomics in those two functions arent even required - all access to
>> those variables is supposed to be protected by the lockmgr anyway.
>> So it would be easier to just remove any atomic nature of those
>> variables (or at the very lease replace the compare_exchange with a
>> store to solve this problem at hand).
> 
> I'm not sure but are you proposed to revert commit
> https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d
> 47a559a461
> 
> 
> Basically, yes. Atomics are not needed for this variable, as access to it
> should be serialized anyways.

OK for me. I've sent smaller patch (only near/Rectangle stuff).

Mateusz

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

[FFmpeg-devel] [PATCH] fix MSVC compilation errors

[Mateusz]

After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
we have included windows.h in much more files and we should
avoid conflicts with defines/function declarations.

Signed-off-by: Mateusz Brzostek 
---
 libavcodec/jpegls.h   | 2 ++
 libavcodec/mjpegdec.h | 2 ++
 libavcodec/mss2.c | 6 +++---
 libavformat/mxfenc.c  | 2 +-
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavcodec/jpegls.h b/libavcodec/jpegls.h
index c8997c7861..6b89b2afa3 100644
--- a/libavcodec/jpegls.h
+++ b/libavcodec/jpegls.h
@@ -32,6 +32,8 @@
 #include "avcodec.h"
 #include "internal.h"
 
+#undef near /* This file uses struct member 'near' which in windows.h is 
defined as empty. */
+
 typedef struct JpeglsContext {
 AVCodecContext *avctx;
 } JpeglsContext;
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index c84a40aa6e..c36fba5f22 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -39,6 +39,8 @@
 #include "hpeldsp.h"
 #include "idctdsp.h"
 
+#undef near /* This file uses struct member 'near' which in windows.h is 
defined as empty. */
+
 #define MAX_COMPONENTS 4
 
 typedef struct MJpegDecodeContext {
diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
index 9e7cc466de..3180af1d60 100644
--- a/libavcodec/mss2.c
+++ b/libavcodec/mss2.c
@@ -464,9 +464,9 @@ static int decode_wmv9(AVCodecContext *avctx, const uint8_t 
*buf, int buf_size,
 return 0;
 }
 
-typedef struct Rectangle {
+struct Rectangle {
 int coded, x, y, w, h;
-} Rectangle;
+};
 
 #define MAX_WMV9_RECTANGLES 20
 #define ARITH2_PADDING 2
@@ -485,7 +485,7 @@ static int mss2_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 
 int keyframe, has_wmv9, has_mv, is_rle, is_555, ret;
 
-Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
+struct Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
 int used_rects = 0, i, implicit_rect = 0, av_uninit(wmv9_mask);
 
 if ((ret = init_get_bits8(, buf, buf_size)) < 0)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ed6ecbf541..407acdcaaa 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1444,7 +1444,7 @@ static int mxf_write_header_metadata_sets(AVFormatContext 
*s)
 AVStream *st = NULL;
 int i;
 
-MXFPackage packages[2] = {};
+MXFPackage packages[2] = {{NULL}};
 int package_count = 2;
 packages[0].type = MaterialPackage;
 packages[1].type = SourcePackage;
-- 
2.15.1.windows.2

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

Re: [FFmpeg-devel] [PATCH 3/4] opus: Add Special Hybrid Folding (per RFC8251)

[Andrew D'Addesio]

On Wed Dec 6 21:42:48 EET 2017, James Almer 
wrote:
> Valgrind apparently complains about this commit, as i mentioned in
> another reply to this thread

Hi James, thanks for reporting the issue. There's indeed a problem
with patch #3 (use-of-uninitialized-memory in norm[] and norm2[]).

libopus organizes the norm[] variable into bands with *room for* 8
MDCT coefficients in each band (even though the actual number of
coefficients per band is 1, 2, 4, or 8 for 2.5ms, 5ms, 10ms, or 20ms
CELT frames, respectively).

Whereas Libav/FFmpeg changes the organization of norm[] slightly and
packs the bands contiguously (i.e. each band is allocated the
necessary amount of 1 << f->size MDCT coefficients, and no more),
leaving some unused space at the end of norm[].

Hence, every instance of "8 * xxx" in my patch should really be
"xxx << f->size". That got rid of all errors in valgrind/MSAN.

Rostislav has applied the change to master with Commit
4678339e745dac8fa428 ("opus: fix hybrid folding indexing during band
quantization"), so the bug should be fixed now. Thanks for catching
it!

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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[wm4]

On Fri, 8 Dec 2017 06:52:20 +0100
Michael Niedermayer  wrote:

> On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> > On 12/8/2017 12:26 AM, wm4 wrote:  
> > > On Thu, 7 Dec 2017 23:23:51 +0100
> > > Michael Niedermayer  wrote:
> > >   
> > >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:  
> > >>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:
> >  On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> > > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> > >  wrote:
> > >> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> > >>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > >>>  wrote:
> >  On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> >    
> > > 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > > :
> > >> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos 
> > >> wrote:
> > >>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > >>> :
> >  Hi all
> > 
> >  I intend to make 3.4.1 very soon
> > >>>
> > >>> Shouldn't we first decide on how to proceed with #6775?
> > >>
> > >> This would be ideal.
> > >>
> > >> IIUC this is a regression from 
> > >> bddb2343b6e594e312dadb5d21b408702929ae04
> > >
> > > This was confirmed by more than one developer, yes.
> > >
> > >> I see a patch that is said to improve 6775, can that be applied 
> > >> and
> > >> would that resolve this ?
> > >
> > > Iiuc, it would not completely resolve the issue, see:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > >
> > >> If so why was it not applied yet ?
> > >
> > > The patch did not get support here, see:
> > > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet 
> > > after EOF
> > > in compat_decode
> > 
> > 
> >  Is someone working on fixing this better than with the available 
> >  patch ?
> > 
> > >>>
> > >>> I don't even agree this needs fixing. Those projects use the API 
> > >>> wrong.
> > >>
> > >> Had we documented the correct/wrong use precissely in the past when
> > >> these wrong uses where written ?
> > >>
> > >> Because if it was documented then few should have made the mistake.
> > >> But it seems this affects multiple projects, so i wonder if our API
> > >> really excluded the use
> > >>
> > >
> > > Apparently not well enough, but I also don't even understand why you
> > > would *want* to drain in the middle of decoding.
> > >
> > > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > > new API was introduced) do include the "at the end", however.
> > >
> > > From CODEC_CAP_DELAY:
> > >  * Decoders:
> > >  * The decoder has a non-zero delay and needs to be fed with 
> > > avpkt->data=NULL,
> > >  * avpkt->size=0 at the end to get the delayed data until the decoder 
> > > no longer
> > >  * returns frames.
> > >
> > > From avcodec_decode_video2
> > > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have 
> > > a delay
> > > * between input and output, these need to be fed with 
> > > avpkt->data=NULL,
> > > * avpkt->size=0 at the end to return the remaining frames.
> > >
> > > There is a few more mentions of the same concept, but as far as I can
> > > see all include the key words "at the end".
> > > 
> >  
> > > For the suggested patch, draining and flushing in the middle of a
> > > bitstream is still going to result in problems, though, since it
> > > removes all reference frames, for example.
> > > The original behavior cannot really be stored, which was to just keep
> > > feeding frames into the decoder after a drain without a flush.
> > > However, some decoders actually crashed when you did this, so this was
> > > a rather unsafe action to begin with (not an issue any longer, since
> > > this pattern is now blocked).
> > 
> >  Did the previous code really work if the frame after a flush was not a
> >  new keyframe or there was some use of previous references ?
> > >>>
> > >>> ping
> > >>>
> > >>> so what is the status of this?
> > >>>
> > >>> Ticket 6775 is still open, neither a workaround was applied nor was
> > >>> it closed as invalid. Only one workaround was proposed which was
> > >>> claimed to be worse than the code before.
> > >>> It seems the 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Fri, Dec 08, 2017 at 01:09:50AM -0300, James Almer wrote:
> On 12/8/2017 12:26 AM, wm4 wrote:
> > On Thu, 7 Dec 2017 23:23:51 +0100
> > Michael Niedermayer  wrote:
> > 
> >> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
> >>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:  
>  On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:  
> > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> >  wrote:  
> >> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:  
> >>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> >>>  wrote:  
>  On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> > 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > :  
> >> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:  
> >>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> >>> :  
>  Hi all
> 
>  I intend to make 3.4.1 very soon  
> >>>
> >>> Shouldn't we first decide on how to proceed with #6775?  
> >>
> >> This would be ideal.
> >>
> >> IIUC this is a regression from 
> >> bddb2343b6e594e312dadb5d21b408702929ae04  
> >
> > This was confirmed by more than one developer, yes.
> >  
> >> I see a patch that is said to improve 6775, can that be applied and
> >> would that resolve this ?  
> >
> > Iiuc, it would not completely resolve the issue, see:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> >  
> >> If so why was it not applied yet ?  
> >
> > The patch did not get support here, see:
> > [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after 
> > EOF
> > in compat_decode  
> 
> 
>  Is someone working on fixing this better than with the available 
>  patch ?
>   
> >>>
> >>> I don't even agree this needs fixing. Those projects use the API 
> >>> wrong.  
> >>
> >> Had we documented the correct/wrong use precissely in the past when
> >> these wrong uses where written ?
> >>
> >> Because if it was documented then few should have made the mistake.
> >> But it seems this affects multiple projects, so i wonder if our API
> >> really excluded the use
> >>  
> >
> > Apparently not well enough, but I also don't even understand why you
> > would *want* to drain in the middle of decoding.
> >
> > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > new API was introduced) do include the "at the end", however.
> >
> > From CODEC_CAP_DELAY:
> >  * Decoders:
> >  * The decoder has a non-zero delay and needs to be fed with 
> > avpkt->data=NULL,
> >  * avpkt->size=0 at the end to get the delayed data until the decoder 
> > no longer
> >  * returns frames.
> >
> > From avcodec_decode_video2
> > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> > delay
> > * between input and output, these need to be fed with avpkt->data=NULL,
> > * avpkt->size=0 at the end to return the remaining frames.
> >
> > There is a few more mentions of the same concept, but as far as I can
> > see all include the key words "at the end".
> >   
>    
> > For the suggested patch, draining and flushing in the middle of a
> > bitstream is still going to result in problems, though, since it
> > removes all reference frames, for example.
> > The original behavior cannot really be stored, which was to just keep
> > feeding frames into the decoder after a drain without a flush.
> > However, some decoders actually crashed when you did this, so this was
> > a rather unsafe action to begin with (not an issue any longer, since
> > this pattern is now blocked).  
> 
>  Did the previous code really work if the frame after a flush was not a
>  new keyframe or there was some use of previous references ?  
> >>>
> >>> ping
> >>>
> >>> so what is the status of this?
> >>>
> >>> Ticket 6775 is still open, neither a workaround was applied nor was
> >>> it closed as invalid. Only one workaround was proposed which was
> >>> claimed to be worse than the code before.
> >>> It seems the discussion died down.
> >>> If theres no activity on this in the next days then i intend to make
> >>> the release with whats in release/3.4 at the time. I dont think
> >>> blind waiting will do any good, id rather release early and often ...
> >>>
> >>> Also if someone wants to write some release notes about this issue,
> >>> that is IMO a good idea ...  
> >>
> >> So this code is completely unmaintained ?
> 

[FFmpeg-devel] [PATCH] lavc/utils: remove unnecessary locking

[Rostislav Pehlivanov]

Its already done by lockmgr.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/utils.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index baf09119fe..796d24dcbb 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -115,7 +115,6 @@ static int (*lockmgr_cb)(void **mutex, enum AVLockOp op) = 
NULL;
 #endif
 
 
-static atomic_bool ff_avcodec_locked;
 static atomic_int entangled_thread_counter = ATOMIC_VAR_INIT(0);
 static void *codec_mutex;
 static void *avformat_mutex;
@@ -1943,7 +1942,6 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum 
AVLockOp op))
 
 int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
 {
-_Bool exp = 0;
 if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
 return 0;
 
@@ -1959,21 +1957,17 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const 
AVCodec *codec)
atomic_load(_thread_counter));
 if (!lockmgr_cb)
 av_log(log_ctx, AV_LOG_ERROR, "No lock manager is set, please see 
av_lockmgr_register()\n");
-atomic_store(_avcodec_locked, 1);
 ff_unlock_avcodec(codec);
 return AVERROR(EINVAL);
 }
-av_assert0(atomic_compare_exchange_strong(_avcodec_locked, , 1));
 return 0;
 }
 
 int ff_unlock_avcodec(const AVCodec *codec)
 {
-_Bool exp = 1;
 if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
 return 0;
 
-av_assert0(atomic_compare_exchange_strong(_avcodec_locked, , 0));
 atomic_fetch_add(_thread_counter, -1);
 if (lockmgr_cb) {
 if ((*lockmgr_cb)(_mutex, AV_LOCK_RELEASE))
-- 
2.15.1.424.g9478a66081

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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[James Almer]

On 12/8/2017 1:33 AM, Carl Eugen Hoyos wrote:
> 2017-12-08 5:09 GMT+01:00 James Almer :
> 
>> When the old decode API was turned into a wrapper for the
>> new, some applications using said API this way started to
>> experience issues/crashes that did not happen before.
> 
> Where was a crash reported?
> 
> Carl Eugen

I said issues/crashes because i wasn't sure which kind was reported.
Looking at the ticket, i guess it was the former.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: add flag to discard timestamps on corrupted frames

[Carl Eugen Hoyos]

2017-12-08 5:23 GMT+01:00 Rodger Combs :

> +if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT_TS) &&
> +(pkt->flags & AV_PKT_FLAG_CORRUPT)) {

The brackets look ugly.

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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Carl Eugen Hoyos]

2017-12-08 5:09 GMT+01:00 James Almer :

> When the old decode API was turned into a wrapper for the
> new, some applications using said API this way started to
> experience issues/crashes that did not happen before.

Where was a crash reported?

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

[FFmpeg-devel] [PATCH 3/3] lavf/utils: add flag to fill unset timestamps from wallclock offset

[Rodger Combs]

---
 libavformat/avformat.h  |  1 +
 libavformat/internal.h  |  5 +
 libavformat/options_table.h |  1 +
 libavformat/utils.c | 12 
 4 files changed, 19 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index d10d583dff..a039a2764d 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1451,6 +1451,7 @@ typedef struct AVFormatContext {
 #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
stream stops.
 #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as requested 
by the muxer
 #define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
frames marked corrupt
+#define AVFMT_FLAG_FILL_WALLCLOCK_DTS 0x80 ///< Fill missing or discarded 
DTS values from wallclock (for live streams)
 
 /**
  * Maximum size of the data read from input for determining
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 36a57214ce..3abf1dc720 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -192,6 +192,11 @@ struct AVStreamInternal {
 int need_context_update;
 
 FFFrac *priv_pts;
+
+/**
+ * The wallclock timestamp of the most recent read packet (if 
AVFMT_FLAG_FILL_WALLCLOCK_DTS is set)
+ */
+int64_t cur_wallclock_time;
 };
 
 #ifdef __GNUC__
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 515574d3e0..64febc7a21 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -59,6 +59,7 @@ static const AVOption avformat_options[] = {
 {"shortest", "stop muxing with the shortest stream", 0, AV_OPT_TYPE_CONST, { 
.i64 = AVFMT_FLAG_SHORTEST }, 0, 0, E, "fflags" },
 {"autobsf", "add needed bsfs automatically", 0, AV_OPT_TYPE_CONST, { .i64 = 
AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
 {"discardcorruptts", "discard timestamps on corrupted frames", 0, 
AV_OPT_TYPE_CONST, { .i64 = AVFMT_FLAG_DISCARD_CORRUPT_TS }, 0, 0, E, "fflags" 
},
+{"fillwallclockdts", "fill missing or discarded DTS values from wallclock (for 
live streams)", 0, AV_OPT_TYPE_CONST, { .i64 = AVFMT_FLAG_FILL_WALLCLOCK_DTS }, 
0, 0, E, "fflags" },
 {"analyzeduration", "specify how many microseconds are analyzed to probe the 
input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0, 
INT64_MAX, D},
 {"cryptokey", "decryption key", OFFSET(key), AV_OPT_TYPE_BINARY, {.dbl = 0}, 
0, 0, D},
 {"indexmem", "max memory used for timestamp index (per stream)", 
OFFSET(max_index_size), AV_OPT_TYPE_INT, {.i64 = 1<<20 }, 0, INT_MAX, D},
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 98af941e9f..22cefb2975 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -881,6 +881,18 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
pkt->stream_index);
 }
 
+if (s->flags & AVFMT_FLAG_FILL_WALLCLOCK_DTS) {
+int64_t cur_wallclock_time = av_gettime_relative();
+if (pkt->dts == AV_NOPTS_VALUE && st->cur_dts != AV_NOPTS_VALUE && 
st->internal->cur_wallclock_time) {
+int64_t wallclock_offset = 
av_rescale_q(st->internal->cur_wallclock_time - cur_wallclock_time, 
AV_TIME_BASE_Q, st->time_base);
+pkt->dts = st->cur_dts + FFMAX(wallclock_offset, 1);
+av_log(s, AV_LOG_VERBOSE,
+   "Filled timestamp from wallclock (stream = %d; last = 
%"PRId64"; val = %"PRId64")\n",
+   pkt->stream_index, st->cur_dts, pkt->dts);
+}
+st->internal->cur_wallclock_time = cur_wallclock_time;
+}
+
 pkt->dts = wrap_timestamp(st, pkt->dts);
 pkt->pts = wrap_timestamp(st, pkt->pts);
 
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 1/3] lavf/mpegts: mark packets with TEI flag as corrupted

[Rodger Combs]

---
 libavformat/mpegts.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 53cbcfb543..0a3ad05726 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2296,6 +2296,14 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 }
 }
 
+if (packet[1] & 0x80) {
+av_log(ts->stream, AV_LOG_DEBUG, "Packet had TEI flag set; marking as 
corrupt\n");
+if (tss->type == MPEGTS_PES) {
+PESContext *pc = tss->u.pes_filter.opaque;
+pc->flags |= AV_PKT_FLAG_CORRUPT;
+}
+}
+
 p = packet + 4;
 if (has_adaptation) {
 int64_t pcr_h;
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 2/3] lavf/utils: add flag to discard timestamps on corrupted frames

[Rodger Combs]

---
 libavformat/avformat.h  | 1 +
 libavformat/options_table.h | 1 +
 libavformat/utils.c | 8 
 3 files changed, 10 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 4f2798a871..d10d583dff 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
 #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate seeks 
for some formats
 #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
stream stops.
 #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as requested 
by the muxer
+#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
frames marked corrupt
 
 /**
  * Maximum size of the data read from input for determining
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index b8fa47c6fd..515574d3e0 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -58,6 +58,7 @@ static const AVOption avformat_options[] = {
 {"bitexact", "do not write random/volatile data", 0, AV_OPT_TYPE_CONST, { .i64 
= AVFMT_FLAG_BITEXACT }, 0, 0, E, "fflags" },
 {"shortest", "stop muxing with the shortest stream", 0, AV_OPT_TYPE_CONST, { 
.i64 = AVFMT_FLAG_SHORTEST }, 0, 0, E, "fflags" },
 {"autobsf", "add needed bsfs automatically", 0, AV_OPT_TYPE_CONST, { .i64 = 
AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
+{"discardcorruptts", "discard timestamps on corrupted frames", 0, 
AV_OPT_TYPE_CONST, { .i64 = AVFMT_FLAG_DISCARD_CORRUPT_TS }, 0, 0, E, "fflags" 
},
 {"analyzeduration", "specify how many microseconds are analyzed to probe the 
input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0, 
INT64_MAX, D},
 {"cryptokey", "decryption key", OFFSET(key), AV_OPT_TYPE_BINARY, {.dbl = 0}, 
0, 0, D},
 {"indexmem", "max memory used for timestamp index (per stream)", 
OFFSET(max_index_size), AV_OPT_TYPE_INT, {.i64 = 1<<20 }, 0, INT_MAX, D},
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 84e49208b8..98af941e9f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -873,6 +873,14 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 st->cur_dts = wrap_timestamp(st, st->cur_dts);
 }
 
+if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT_TS) &&
+(pkt->flags & AV_PKT_FLAG_CORRUPT)) {
+pkt->pts = pkt->dts = AV_NOPTS_VALUE;
+av_log(s, AV_LOG_WARNING,
+   "Discarded timestamp on corrupted packet (stream = %d)\n",
+   pkt->stream_index);
+}
+
 pkt->dts = wrap_timestamp(st, pkt->dts);
 pkt->pts = wrap_timestamp(st, pkt->pts);
 
-- 
2.14.3

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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[James Almer]

On 12/8/2017 12:26 AM, wm4 wrote:
> On Thu, 7 Dec 2017 23:23:51 +0100
> Michael Niedermayer  wrote:
> 
>> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
>>> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:  
 On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:  
> On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
>  wrote:  
>> On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:  
>>> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
>>>  wrote:  
 On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> :  
>> On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:  
>>> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
>>> :  
 Hi all

 I intend to make 3.4.1 very soon  
>>>
>>> Shouldn't we first decide on how to proceed with #6775?  
>>
>> This would be ideal.
>>
>> IIUC this is a regression from 
>> bddb2343b6e594e312dadb5d21b408702929ae04  
>
> This was confirmed by more than one developer, yes.
>  
>> I see a patch that is said to improve 6775, can that be applied and
>> would that resolve this ?  
>
> Iiuc, it would not completely resolve the issue, see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
>  
>> If so why was it not applied yet ?  
>
> The patch did not get support here, see:
> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF
> in compat_decode  


 Is someone working on fixing this better than with the available patch 
 ?
  
>>>
>>> I don't even agree this needs fixing. Those projects use the API wrong. 
>>>  
>>
>> Had we documented the correct/wrong use precissely in the past when
>> these wrong uses where written ?
>>
>> Because if it was documented then few should have made the mistake.
>> But it seems this affects multiple projects, so i wonder if our API
>> really excluded the use
>>  
>
> Apparently not well enough, but I also don't even understand why you
> would *want* to drain in the middle of decoding.
>
> The only mention of sending NULL/0 packets (in 3.0 docs, before the
> new API was introduced) do include the "at the end", however.
>
> From CODEC_CAP_DELAY:
>  * Decoders:
>  * The decoder has a non-zero delay and needs to be fed with 
> avpkt->data=NULL,
>  * avpkt->size=0 at the end to get the delayed data until the decoder no 
> longer
>  * returns frames.
>
> From avcodec_decode_video2
> * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> delay
> * between input and output, these need to be fed with avpkt->data=NULL,
> * avpkt->size=0 at the end to return the remaining frames.
>
> There is a few more mentions of the same concept, but as far as I can
> see all include the key words "at the end".
>   
   
> For the suggested patch, draining and flushing in the middle of a
> bitstream is still going to result in problems, though, since it
> removes all reference frames, for example.
> The original behavior cannot really be stored, which was to just keep
> feeding frames into the decoder after a drain without a flush.
> However, some decoders actually crashed when you did this, so this was
> a rather unsafe action to begin with (not an issue any longer, since
> this pattern is now blocked).  

 Did the previous code really work if the frame after a flush was not a
 new keyframe or there was some use of previous references ?  
>>>
>>> ping
>>>
>>> so what is the status of this?
>>>
>>> Ticket 6775 is still open, neither a workaround was applied nor was
>>> it closed as invalid. Only one workaround was proposed which was
>>> claimed to be worse than the code before.
>>> It seems the discussion died down.
>>> If theres no activity on this in the next days then i intend to make
>>> the release with whats in release/3.4 at the time. I dont think
>>> blind waiting will do any good, id rather release early and often ...
>>>
>>> Also if someone wants to write some release notes about this issue,
>>> that is IMO a good idea ...  
>>
>> So this code is completely unmaintained ?
>> Noone cares about pushing a workaround ?
>> Noone cares about closing the ticket as wont fix ?
>> Noone cares about explaining why neither should be done ?
>>
>> I intend to make the release tomorrow or as soon as i have time, we
>> have waited too long already. I can of course wait more if 

Re: [FFmpeg-devel] [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert

[Neil Birkbeck]

On Sat, Dec 2, 2017 at 5:25 PM, Carl Eugen Hoyos  wrote:

> 2017-12-01 20:08 GMT+01:00 Neil Birkbeck :
> > On Thu, Nov 30, 2017 at 9:52 AM, Michael Niedermayer wrote:
>
> >> > For that sample, I feel like it may be incorrectly tagged as pc/full.
> >>
> >> is it stored in the file or taken from:
> >> ff_generate_avci_extradata()
> >> maybe theres a bug in the AVCIntra handling
> >
> > It seems avci100_1080i_extradata may be the one that is signalling full
> > range for the AVCI100.mov sample. I tested changing the range flag:
> > -0x3c, 0x60, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03,
> > +0x3c, 0x20, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03,
>
> If you believe it is safe (or a bug), please change it.
>

I've looked at a few avci-100 files that I could find, and the ones I came
across had data that appeared to be tv range. Unless there is some spec
that says it should be pc/full, I'd say tv (or unspecified) may be a better
default. Let me look into the other avci modes to confirm.

I also attached an updated patch with fate tests. In it, for each
configuration {8-bit/10-bit, scaled/unscaled}, the checksum should be the
same when in_range is set explicitly (or implicitly). And output explicit
to tv or unset is is the same. There is still the issue of whether having
out_range be "unspecified" should give "tv" range (that is what happens for
8-bit at the moment).

Samples are here:
https://github.com/nbirkbeck/ffmpeg-test-samples/tree/master/color-range/data

In the patch, I'd put them in ffmpeg-synthetic/color.
From caa75c6d5d323415647c93d1c7c1d5326f8cf825 Mon Sep 17 00:00:00 2001
From: Neil Birkbeck 
Date: Tue, 28 Nov 2017 15:56:12 -0800
Subject: [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert

On higher bit depth YUV inputs with range metadata signaled as PC/full levels,
this change makes the results of scaling without explicitly
setting the input range on vf_scale as if it were explicitly set.

For example, the results with implicit color settings from the frame:
-vf scale=-1:-1:out_range=mpeg,format=yuv420p

Are the same as the correct result when set explicitly in the scaler:
-vf scale=-1:-1:in_range=jpeg:out_range=mpeg,format=yuv420p

The results are consistent with a similar yuv420p(pc) test input
(e.g., implicit and explicit setting of in_range on vf_scale both work).

Fate passes without the checks (or with a more specific check for >= 8).
If this seems sane, I'll write some tests.

I tried to reproduce the old results from before and after the commit
that I think the previous comment was referring to
4959a4fcf76e7c595dbb23c4e3bf59abf2e60ea4
but failed to repro (I may be testing the wrong thing). Using the samples
from (https://trac.ffmpeg.org/ticket/2939), without the check:
ffmpeg -i /tmp/progressive.jpg -vf format=rgb24 /tmp/progressive.png
is still treated as full range input (treating it as studio causes clipping
in the rgb).

There are still some other edge cases where range conversion doesn't work
unless explicitly set (e.g., when no scale is happening)

New fate samples from:
https://github.com/nbirkbeck/ffmpeg-test-samples/tree/master/color-range/data

Signed-off-by: Neil Birkbeck 
---
 libswscale/utils.c |  4 +-
 tests/fate/filter-video.mak| 67 ++
 .../filter-scale-yuv444p-pc-scaled-in-pc-out-tv| 10 
 ...filter-scale-yuv444p-pc-scaled-in-pc-out-unspec | 10 
 ...filter-scale-yuv444p-pc-scaled-in-unspec-out-tv | 10 
 ...er-scale-yuv444p-pc-scaled-in-unspec-out-unspec | 10 
 .../filter-scale-yuv444p-pc-unscaled-in-pc-out-tv  | 10 
 ...lter-scale-yuv444p-pc-unscaled-in-pc-out-unspec | 10 
 ...lter-scale-yuv444p-pc-unscaled-in-unspec-out-tv | 10 
 ...-scale-yuv444p-pc-unscaled-in-unspec-out-unspec | 10 
 .../filter-scale-yuv444p10-pc-scaled-in-pc-out-tv  | 10 
 ...lter-scale-yuv444p10-pc-scaled-in-pc-out-unspec | 10 
 ...lter-scale-yuv444p10-pc-scaled-in-unspec-out-tv | 10 
 ...-scale-yuv444p10-pc-scaled-in-unspec-out-unspec | 10 
 ...filter-scale-yuv444p10-pc-unscaled-in-pc-out-tv | 10 
 ...er-scale-yuv444p10-pc-unscaled-in-pc-out-unspec | 10 
 ...er-scale-yuv444p10-pc-unscaled-in-unspec-out-tv | 10 
 ...cale-yuv444p10-pc-unscaled-in-unspec-out-unspec | 10 
 18 files changed, 228 insertions(+), 3 deletions(-)
 create mode 100644 tests/ref/fate/filter-scale-yuv444p-pc-scaled-in-pc-out-tv
 create mode 100644 tests/ref/fate/filter-scale-yuv444p-pc-scaled-in-pc-out-unspec
 create mode 100644 tests/ref/fate/filter-scale-yuv444p-pc-scaled-in-unspec-out-tv
 create mode 100644 tests/ref/fate/filter-scale-yuv444p-pc-scaled-in-unspec-out-unspec
 create mode 100644 tests/ref/fate/filter-scale-yuv444p-pc-unscaled-in-pc-out-tv
 create mode 100644 tests/ref/fate/filter-scale-yuv444p-pc-unscaled-in-pc-out-unspec
 create mode 100644 

Re: [FFmpeg-devel] FFmpeg 3.4.1

[wm4]

On Thu, 7 Dec 2017 23:23:51 +0100
Michael Niedermayer  wrote:

> On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
> > On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:  
> > > On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:  
> > > > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> > > >  wrote:  
> > > > > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:  
> > > > >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > > > >>  wrote:  
> > > > >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:  
> > > > >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > > > >> >> :  
> > > > >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos 
> > > > >> >> > wrote:  
> > > > >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > > > >> >> >> :  
> > > > >> >> >> > Hi all
> > > > >> >> >> >
> > > > >> >> >> > I intend to make 3.4.1 very soon  
> > > > >> >> >>
> > > > >> >> >> Shouldn't we first decide on how to proceed with #6775?  
> > > > >> >> >
> > > > >> >> > This would be ideal.
> > > > >> >> >
> > > > >> >> > IIUC this is a regression from 
> > > > >> >> > bddb2343b6e594e312dadb5d21b408702929ae04  
> > > > >> >>
> > > > >> >> This was confirmed by more than one developer, yes.
> > > > >> >>  
> > > > >> >> > I see a patch that is said to improve 6775, can that be applied 
> > > > >> >> > and
> > > > >> >> > would that resolve this ?  
> > > > >> >>
> > > > >> >> Iiuc, it would not completely resolve the issue, see:
> > > > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > > > >> >>  
> > > > >> >> > If so why was it not applied yet ?  
> > > > >> >>
> > > > >> >> The patch did not get support here, see:
> > > > >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet 
> > > > >> >> after EOF
> > > > >> >> in compat_decode  
> > > > >> >
> > > > >> >
> > > > >> > Is someone working on fixing this better than with the available 
> > > > >> > patch ?
> > > > >> >  
> > > > >>
> > > > >> I don't even agree this needs fixing. Those projects use the API 
> > > > >> wrong.  
> > > > >
> > > > > Had we documented the correct/wrong use precissely in the past when
> > > > > these wrong uses where written ?
> > > > >
> > > > > Because if it was documented then few should have made the mistake.
> > > > > But it seems this affects multiple projects, so i wonder if our API
> > > > > really excluded the use
> > > > >  
> > > > 
> > > > Apparently not well enough, but I also don't even understand why you
> > > > would *want* to drain in the middle of decoding.
> > > > 
> > > > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > > > new API was introduced) do include the "at the end", however.
> > > > 
> > > > From CODEC_CAP_DELAY:
> > > >  * Decoders:
> > > >  * The decoder has a non-zero delay and needs to be fed with 
> > > > avpkt->data=NULL,
> > > >  * avpkt->size=0 at the end to get the delayed data until the decoder 
> > > > no longer
> > > >  * returns frames.
> > > > 
> > > > From avcodec_decode_video2
> > > > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> > > > delay
> > > > * between input and output, these need to be fed with avpkt->data=NULL,
> > > > * avpkt->size=0 at the end to return the remaining frames.
> > > > 
> > > > There is a few more mentions of the same concept, but as far as I can
> > > > see all include the key words "at the end".
> > > >   
> > >   
> > > > For the suggested patch, draining and flushing in the middle of a
> > > > bitstream is still going to result in problems, though, since it
> > > > removes all reference frames, for example.
> > > > The original behavior cannot really be stored, which was to just keep
> > > > feeding frames into the decoder after a drain without a flush.
> > > > However, some decoders actually crashed when you did this, so this was
> > > > a rather unsafe action to begin with (not an issue any longer, since
> > > > this pattern is now blocked).  
> > > 
> > > Did the previous code really work if the frame after a flush was not a
> > > new keyframe or there was some use of previous references ?  
> > 
> > ping
> > 
> > so what is the status of this?
> > 
> > Ticket 6775 is still open, neither a workaround was applied nor was
> > it closed as invalid. Only one workaround was proposed which was
> > claimed to be worse than the code before.
> > It seems the discussion died down.
> > If theres no activity on this in the next days then i intend to make
> > the release with whats in release/3.4 at the time. I dont think
> > blind waiting will do any good, id rather release early and often ...
> > 
> > Also if someone wants to write some release notes about this issue,
> > that is IMO a good idea ...  
> 
> So this code is completely unmaintained ?
> Noone 

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: ICQ/VCM/QVBR are not avilable on Linux

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, December 8, 2017 8:39 AM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: ICQ/VCM/QVBR are
> not avilable on Linux
> 
> 2017-12-07 7:24 GMT+01:00 Zhong Li :
> > Signed-off-by: Zhong Li 
> > ---
> >  libavcodec/qsvenc.h | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h index
> > 5cfd174..fae98e1 100644
> > --- a/libavcodec/qsvenc.h
> > +++ b/libavcodec/qsvenc.h
> > @@ -44,9 +44,16 @@
> >  #define QSV_HAVE_LA QSV_VERSION_ATLEAST(1, 7)
> >  #define QSV_HAVE_LA_DS  QSV_VERSION_ATLEAST(1, 8)  #define
> > QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
> > +
> > +#if defined(_WIN32)
> >  #define QSV_HAVE_ICQQSV_VERSION_ATLEAST(1, 8)
> >  #define QSV_HAVE_VCMQSV_VERSION_ATLEAST(1, 8)
> >  #define QSV_HAVE_QVBR   QSV_VERSION_ATLEAST(1, 11)
> > +#else
> > +#define QSV_HAVE_ICQ0
> > +#define QSV_HAVE_VCM0
> > +#define QSV_HAVE_QVBR   0
> > +#endif
> 
> Perhaps "... are only available on Windows" would put the commit message
> and the patch more in-line.

Good suggestion, will update.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: ICQ/VCM/QVBR are not avilable on Linux

[Carl Eugen Hoyos]

2017-12-07 7:24 GMT+01:00 Zhong Li :
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc.h | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index 5cfd174..fae98e1 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -44,9 +44,16 @@
>  #define QSV_HAVE_LA QSV_VERSION_ATLEAST(1, 7)
>  #define QSV_HAVE_LA_DS  QSV_VERSION_ATLEAST(1, 8)
>  #define QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
> +
> +#if defined(_WIN32)
>  #define QSV_HAVE_ICQQSV_VERSION_ATLEAST(1, 8)
>  #define QSV_HAVE_VCMQSV_VERSION_ATLEAST(1, 8)
>  #define QSV_HAVE_QVBR   QSV_VERSION_ATLEAST(1, 11)
> +#else
> +#define QSV_HAVE_ICQ0
> +#define QSV_HAVE_VCM0
> +#define QSV_HAVE_QVBR   0
> +#endif

Perhaps "... are only available on Windows" would put
the commit message and the patch more in-line.

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

Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: add AVFMT_VARIABLE_FPS flag to mimic mpegtsenc

[Carl Eugen Hoyos]

2017-12-08 1:14 GMT+01:00 Aman Gupta :
> From: Aman Gupta 
>
> Previously, using a filter that changed frame_rate/time_base would work
> as expected with mpegtsenc, but duplicate frames when used with hlsenc
> (which uses mpegtsenc underneath).
>
> For instance, using https://tmm1.s3.amazonaws.com/720p.ts:
>
> $ ffmpeg -i 720p.ts -c:v libx264 -an -filter:v 
> "yadif=mode=send_field:deint=interlaced" -f mpegts -y single.ts
> $ ffmpeg -i 720p.ts -c:v libx264 -an -filter:v 
> "yadif=mode=send_field:deint=interlaced" -f hls -hls_time 30 -y segment.m3u8
>
> One would expect single.ts and segment0.ts to be identical, however comparing 
> them shows:
>
> single.ts:   120 fps,  59.94 tbr, 90k tbn, 239.76 tbc
> segment0.ts: 120 fps, 119.88 tbr, 90k tbn, 239.76 tbc
>
> Without AVFMT_VARIABLE_FPS set, ffmpeg.c was duplicating frames in the hlsenc
> case and generating segments with double the r_frame_rate.
>
> After this commit, the two muxers generate identical output.

But the mp4 muxer does not support variable frame rate output...

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

[FFmpeg-devel] [PATCH] libavformat/hlsenc: add AVFMT_VARIABLE_FPS flag to mimic mpegtsenc

[Aman Gupta]

From: Aman Gupta 

Previously, using a filter that changed frame_rate/time_base would work
as expected with mpegtsenc, but duplicate frames when used with hlsenc
(which uses mpegtsenc underneath).

For instance, using https://tmm1.s3.amazonaws.com/720p.ts:

$ ffmpeg -i 720p.ts -c:v libx264 -an -filter:v 
"yadif=mode=send_field:deint=interlaced" -f mpegts -y single.ts
$ ffmpeg -i 720p.ts -c:v libx264 -an -filter:v 
"yadif=mode=send_field:deint=interlaced" -f hls -hls_time 30 -y segment.m3u8

One would expect single.ts and segment0.ts to be identical, however comparing 
them shows:

single.ts:   120 fps,  59.94 tbr, 90k tbn, 239.76 tbc
segment0.ts: 120 fps, 119.88 tbr, 90k tbn, 239.76 tbc

Without AVFMT_VARIABLE_FPS set, ffmpeg.c was duplicating frames in the hlsenc
case and generating segments with double the r_frame_rate.

After this commit, the two muxers generate identical output.
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7dc8f4237b..d256498244 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2335,7 +2335,7 @@ AVOutputFormat ff_hls_muxer = {
 .audio_codec= AV_CODEC_ID_AAC,
 .video_codec= AV_CODEC_ID_H264,
 .subtitle_codec = AV_CODEC_ID_WEBVTT,
-.flags  = AVFMT_NOFILE | AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH,
+.flags  = AVFMT_NOFILE | AVFMT_GLOBALHEADER | AVFMT_VARIABLE_FPS | 
AVFMT_ALLOW_FLUSH,
 .write_header   = hls_write_header,
 .write_packet   = hls_write_packet,
 .write_trailer  = hls_write_trailer,
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v2] libavcodec/mpegvideo_parser: improve detection of progressive mpeg2

[Aman Gupta]

From: Aman Gupta 

Previously many progressive mpeg2video samples were detected as interlaced
by ffmpeg/ffprobe. For example, https://tmm1.s3.amazonaws.com/720p.ts

Before:

Input #0, mpegts, from 'https://tmm1.s3.amazonaws.com/720p.ts':
  Duration: 00:00:08.62, start: 18974.073233, bitrate: 9734 kb/s
  Program 2
Stream #0:0[0x12eb]: Video: mpeg2video (Main), yuv420p(tv, bottom 
first), 1280x720 ...

After:

Input #0, mpegts, from 'https://tmm1.s3.amazonaws.com/720p.ts':
  Duration: 00:00:08.62, start: 18974.073233, bitrate: 9734 kb/s
  Program 2
Stream #0:0[0x12eb]: Video: mpeg2video (Main), yuv420p(tv, 
progressive), 1280x720 ...

Signed-off-by: Michael Niedermayer 
---
 libavcodec/mpegvideo_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index de70cd5632..be240b6890 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/libavcodec/mpegvideo_parser.c
@@ -131,7 +131,7 @@ static void mpegvideo_extract_headers(AVCodecParserContext 
*s,
 }
 }
 
-if (!pc->progressive_sequence) {
+if (!pc->progressive_sequence && !progressive_frame) {
 if (top_field_first)
 s->field_order = AV_FIELD_TT;
 else
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Tomas Härdin]

On Thu, 2017-12-07 at 14:45 -0800, Mark Reid wrote:
> On Dec 7, 2017 7:45 AM, "Tomas Härdin"  wrote:
> 
> On 2017-12-05 05:46, Mark Reid wrote:
> 
> > ---
> >   libavformat/mxf.h|  1 +
> >   libavformat/mxfenc.c | 42 +++--
> > -
> >   2 files changed, 36 insertions(+), 7 deletions(-)
> > 
> > 
> > @@ -1476,6 +1495,15 @@ static int
> > mxf_write_header_metadata_sets(AVFormatContext
> > *s)
> >   }
> >   }
> >   +entry = av_dict_get(s->metadata, "reel_name", NULL, 0);
> > +if (entry) {
> > +packages[2].name = entry->value;
> > +packages[2].type = SourcePackage;
> > +packages[2].instance = 2;
> > +packages[1].ref = [2];
> > +package_count = 3;
> > +}
> > 
> 
> I guess we can have it check track metadata later if we feel like it.
> Did a
> patch moving reel_name into AVFormatContext make it into mxfdec yet?
> mxfenc's output surviving a roundtrip through mxfdec + mxfenc might
> be
> desirable:
> 
> ffmpeg -i somefile_with_reel_name.mkv output.mxf
> ffmpeg -i output.mxf -vcodec copy -acodec copy remuxed.mxf
> 
> Ideally remuxed.mxf is identical to output.mxf
> 
> /Tomas
> 
> 
> Yes I agree that such behaviour is desirable.
> I haven't taken a look at mxfdec yet. Looking in steams for reel_name
> might
> be necessary, as I believe that's where mov,MP4 store it. But I was
> trying
> to keep it simple at first and addressed this specific issue a future
> patch.

Fair enough. I guess we can commit this patch series then. Michael?

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

[Bjorn Roche]

Hey all,

Just wondering what else is needed to get this merged? Is there anything
else I can do?

Thanks,

bjorn

On Thu, Nov 30, 2017 at 12:33 PM, Bjorn Roche  wrote:

> We've done a bit more testing on this and it looks good here.
>
> On Thu, Nov 30, 2017 at 12:26 PM, Bjorn Roche  wrote:
>
>>
>>
>> On Mon, Nov 27, 2017 at 7:12 PM, Carl Eugen Hoyos 
>> wrote:
>>
>>> 2017-11-28 1:07 GMT+01:00 Bjorn Roche :
>>> > On Mon, Nov 27, 2017 at 5:41 PM, Carl Eugen Hoyos 
>>> > wrote:
>>>
>>> >> >> Does remuxing animated gif with transparency work with your patch?
>>> >> >
>>> >> > A command like this:
>>> >> >
>>> >> > ffmpeg -i in.gif out.gif
>>> >> >
>>> >> > seems to produce the same output as before: transparency replaces
>>> >> > with opacity.
>>> >>
>>> >> remuxing == -vcodec copy
>>> >>
>>> >> What about ffmpeg -i in.gif -vcodec copy out.gif ?
>>> >>
>>> >
>>> > That doesn't work. Weather I use my patch or not it aborts:
>>>
>>> Of course, ticket #6640.
>>
>>
>> I'm going to see if this is something I can tackle separately.
>>
>> bjorn
>>
>>
>> --
>>
>>
>> Bjorn Roche
>>
>> Sr. Video Pipeline Engineer
>>
>> bj...@giphy.com
>>
>
>
>
> --
>
>
> Bjorn Roche
>
> Sr. Video Pipeline Engineer
>
> bj...@giphy.com
>



-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

[FFmpeg-devel] [PATCH] libavcodec/hevcdsp: compilation error fixed for ARM

[Ihor Bobalo]

This e-mail may contain privileged and confidential information. If you are not 
the intended recipient, be aware that any use, disclosure, copying or 
distribution of this e-mail or any attachments is prohibited. If you have 
received this e-mail in error, please notify us immediately by returning it to 
the sender and delete this copy from your system. Thank you.


0001-libavcodec-hevcdsp-compilation-error-fixed-for-ARM.patch
Description: 0001-libavcodec-hevcdsp-compilation-error-fixed-for-ARM.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf/utils: add flag to discard timestamps on corrupted frames

[Rodger Combs]

> On Dec 7, 2017, at 16:53, Hendrik Leppkes  wrote:
> 
> On Thu, Dec 7, 2017 at 9:46 PM, Michael Niedermayer
> > wrote:
>> On Thu, Dec 07, 2017 at 03:37:38AM -0600, Rodger Combs wrote:
>>> ---
>>> libavformat/avformat.h  |  1 +
>>> libavformat/internal.h  |  5 +
>>> libavformat/options_table.h |  1 +
>>> libavformat/utils.c | 12 
>>> 4 files changed, 19 insertions(+)
>>> 
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index 4f2798a871..e2d88280a8 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
>>> #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate 
>>> seeks for some formats
>>> #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
>>> stream stops.
>>> #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as 
>>> requested by the muxer
>>> +#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
>>> frames marked corrupt (replacing with wallclock offset from last 
>>> non-corrupt frame)
>> 
>> Using wallclock to fill in timestamps feels wrong
>> if you discard a timestamp it should be set to AV_NOPTS_VALUE or
>> recomputed based on information from the specification where this is
>> possible, fps when constant or other hard information.
>> 
> 
> I agree, discard should be just that, set it to invalid. Wallclock is
> meaningless on anything but a live stream.

My intended use-case is live streams, where wallclock can be more useful than 
deriving from fps if e.g. entire packets are dropped. I could have one flag to 
unset timestamps on corrupt packets, and another to fill unset DTS from 
wallclock?

> 
> - Hendrik
> ___
> 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 2/2] lavf/utils: add flag to discard timestamps on corrupted frames

[Hendrik Leppkes]

On Thu, Dec 7, 2017 at 9:46 PM, Michael Niedermayer
 wrote:
> On Thu, Dec 07, 2017 at 03:37:38AM -0600, Rodger Combs wrote:
>> ---
>>  libavformat/avformat.h  |  1 +
>>  libavformat/internal.h  |  5 +
>>  libavformat/options_table.h |  1 +
>>  libavformat/utils.c | 12 
>>  4 files changed, 19 insertions(+)
>>
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index 4f2798a871..e2d88280a8 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
>>  #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate 
>> seeks for some formats
>>  #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
>> stream stops.
>>  #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as 
>> requested by the muxer
>> +#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
>> frames marked corrupt (replacing with wallclock offset from last non-corrupt 
>> frame)
>
> Using wallclock to fill in timestamps feels wrong
> if you discard a timestamp it should be set to AV_NOPTS_VALUE or
> recomputed based on information from the specification where this is
> possible, fps when constant or other hard information.
>

I agree, discard should be just that, set it to invalid. Wallclock is
meaningless on anything but a live stream.

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

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Mark Reid]

On Dec 7, 2017 7:45 AM, "Tomas Härdin"  wrote:

On 2017-12-05 05:46, Mark Reid wrote:

> ---
>   libavformat/mxf.h|  1 +
>   libavformat/mxfenc.c | 42 +++---
>   2 files changed, 36 insertions(+), 7 deletions(-)
>
>
> @@ -1476,6 +1495,15 @@ static int 
> mxf_write_header_metadata_sets(AVFormatContext
> *s)
>   }
>   }
>   +entry = av_dict_get(s->metadata, "reel_name", NULL, 0);
> +if (entry) {
> +packages[2].name = entry->value;
> +packages[2].type = SourcePackage;
> +packages[2].instance = 2;
> +packages[1].ref = [2];
> +package_count = 3;
> +}
>

I guess we can have it check track metadata later if we feel like it. Did a
patch moving reel_name into AVFormatContext make it into mxfdec yet?
mxfenc's output surviving a roundtrip through mxfdec + mxfenc might be
desirable:

ffmpeg -i somefile_with_reel_name.mkv output.mxf
ffmpeg -i output.mxf -vcodec copy -acodec copy remuxed.mxf

Ideally remuxed.mxf is identical to output.mxf

/Tomas


Yes I agree that such behaviour is desirable.
I haven't taken a look at mxfdec yet. Looking in steams for reel_name might
be necessary, as I believe that's where mov,MP4 store it. But I was trying
to keep it simple at first and addressed this specific issue a future patch.


___
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] libavcodec/mpegvideo_parser: set field_order correctly for progressive mpeg2

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 07:47:58PM +, Aman Gupta wrote:
> On Thu, Dec 7, 2017 at 11:42 AM Michael Niedermayer 
> wrote:
> 
> > On Wed, Dec 06, 2017 at 02:54:50PM -0800, Aman Gupta wrote:
> > > From: Aman Gupta 
> > >
> > > ---
> > >  libavcodec/mpegvideo_parser.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/mpegvideo_parser.c
> > b/libavcodec/mpegvideo_parser.c
> > > index de70cd5632..be240b6890 100644
> > > --- a/libavcodec/mpegvideo_parser.c
> > > +++ b/libavcodec/mpegvideo_parser.c
> > > @@ -131,7 +131,7 @@ static void
> > mpegvideo_extract_headers(AVCodecParserContext *s,
> > >  }
> > >  }
> > >
> > > -if (!pc->progressive_sequence) {
> > > +if (!pc->progressive_sequence &&
> > !progressive_frame) {
> >
> > Iam not against this if it results in more correct interlaced detection
> > in practice
> 
> 
> In my experience, most progressive mpeg2 samples are reported as interlaced
> by ffprobe before this change. See for example
> https://tmm1.s3.amazonaws.com/720p.ts

ok, can you make the commit message convey this more clearly?
as its now it looks like this is a fix for some spec non compliance


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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] FFmpeg 3.4.1

[Michael Niedermayer]

On Tue, Nov 21, 2017 at 07:58:18PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 18, 2017 at 09:11:17PM +0100, Michael Niedermayer wrote:
> > On Sat, Nov 18, 2017 at 09:50:33AM +0100, Hendrik Leppkes wrote:
> > > On Sat, Nov 18, 2017 at 3:05 AM, Michael Niedermayer
> > >  wrote:
> > > > On Fri, Nov 17, 2017 at 09:55:47AM +0100, Hendrik Leppkes wrote:
> > > >> On Fri, Nov 17, 2017 at 5:00 AM, Michael Niedermayer
> > > >>  wrote:
> > > >> > On Thu, Nov 16, 2017 at 01:51:34PM +0100, Carl Eugen Hoyos wrote:
> > > >> >> 2017-11-16 13:44 GMT+01:00 Michael Niedermayer 
> > > >> >> :
> > > >> >> > On Thu, Nov 16, 2017 at 01:04:27AM +0100, Carl Eugen Hoyos wrote:
> > > >> >> >> 2017-11-15 13:34 GMT+01:00 Michael Niedermayer 
> > > >> >> >> :
> > > >> >> >> > Hi all
> > > >> >> >> >
> > > >> >> >> > I intend to make 3.4.1 very soon
> > > >> >> >>
> > > >> >> >> Shouldn't we first decide on how to proceed with #6775?
> > > >> >> >
> > > >> >> > This would be ideal.
> > > >> >> >
> > > >> >> > IIUC this is a regression from 
> > > >> >> > bddb2343b6e594e312dadb5d21b408702929ae04
> > > >> >>
> > > >> >> This was confirmed by more than one developer, yes.
> > > >> >>
> > > >> >> > I see a patch that is said to improve 6775, can that be applied 
> > > >> >> > and
> > > >> >> > would that resolve this ?
> > > >> >>
> > > >> >> Iiuc, it would not completely resolve the issue, see:
> > > >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881536
> > > >> >>
> > > >> >> > If so why was it not applied yet ?
> > > >> >>
> > > >> >> The patch did not get support here, see:
> > > >> >> [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after 
> > > >> >> EOF
> > > >> >> in compat_decode
> > > >> >
> > > >> >
> > > >> > Is someone working on fixing this better than with the available 
> > > >> > patch ?
> > > >> >
> > > >>
> > > >> I don't even agree this needs fixing. Those projects use the API wrong.
> > > >
> > > > Had we documented the correct/wrong use precissely in the past when
> > > > these wrong uses where written ?
> > > >
> > > > Because if it was documented then few should have made the mistake.
> > > > But it seems this affects multiple projects, so i wonder if our API
> > > > really excluded the use
> > > >
> > > 
> > > Apparently not well enough, but I also don't even understand why you
> > > would *want* to drain in the middle of decoding.
> > > 
> > > The only mention of sending NULL/0 packets (in 3.0 docs, before the
> > > new API was introduced) do include the "at the end", however.
> > > 
> > > From CODEC_CAP_DELAY:
> > >  * Decoders:
> > >  * The decoder has a non-zero delay and needs to be fed with 
> > > avpkt->data=NULL,
> > >  * avpkt->size=0 at the end to get the delayed data until the decoder no 
> > > longer
> > >  * returns frames.
> > > 
> > > From avcodec_decode_video2
> > > * @note Codecs which have the AV_CODEC_CAP_DELAY capability set have a 
> > > delay
> > > * between input and output, these need to be fed with avpkt->data=NULL,
> > > * avpkt->size=0 at the end to return the remaining frames.
> > > 
> > > There is a few more mentions of the same concept, but as far as I can
> > > see all include the key words "at the end".
> > > 
> > 
> > > For the suggested patch, draining and flushing in the middle of a
> > > bitstream is still going to result in problems, though, since it
> > > removes all reference frames, for example.
> > > The original behavior cannot really be stored, which was to just keep
> > > feeding frames into the decoder after a drain without a flush.
> > > However, some decoders actually crashed when you did this, so this was
> > > a rather unsafe action to begin with (not an issue any longer, since
> > > this pattern is now blocked).
> > 
> > Did the previous code really work if the frame after a flush was not a
> > new keyframe or there was some use of previous references ?
> 
> ping
> 
> so what is the status of this?
> 
> Ticket 6775 is still open, neither a workaround was applied nor was
> it closed as invalid. Only one workaround was proposed which was
> claimed to be worse than the code before.
> It seems the discussion died down.
> If theres no activity on this in the next days then i intend to make
> the release with whats in release/3.4 at the time. I dont think
> blind waiting will do any good, id rather release early and often ...
> 
> Also if someone wants to write some release notes about this issue,
> that is IMO a good idea ...

So this code is completely unmaintained ?
Noone cares about pushing a workaround ?
Noone cares about closing the ticket as wont fix ?
Noone cares about explaining why neither should be done ?

I intend to make the release tomorrow or as soon as i have time, we
have waited too long already. I can of course wait more if people want
but then please have a plan on resolving the issue that the release is
delayed for

Thanks

[...]

Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors

[Hendrik Leppkes]

Am 07.12.2017 20:40 schrieb "Mateusz" :

W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz  wrote:
>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
>> we have included windows.h in much more files and we should
>> avoid conflicts with defines/function declarations.
>>
>> We should declare compatible variables for atomic compat wrappers
>> that expect fixed size variables in atomic_compare_exchange* macro.
>>
>> Signed-off-by: Mateusz Brzostek 
>> ---
>>  libavcodec/jpegls.h   |  2 ++
>>  libavcodec/mjpegdec.h |  2 ++
>>  libavcodec/mss2.c |  6 +++---
>>  libavcodec/utils.c| 12 
>>  libavformat/mxfenc.c  |  2 +-
>>  5 files changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/jpegls.h b/libavcodec/jpegls.h
>> index c8997c7861..6b89b2afa3 100644
>> --- a/libavcodec/jpegls.h
>> +++ b/libavcodec/jpegls.h
>> @@ -32,6 +32,8 @@
>>  #include "avcodec.h"
>>  #include "internal.h"
>>
>> +#undef near /* This file uses struct member 'near' which in windows.h
is defined as empty. */
>> +
>>  typedef struct JpeglsContext {
>>  AVCodecContext *avctx;
>>  } JpeglsContext;
>> diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
>> index c84a40aa6e..c36fba5f22 100644
>> --- a/libavcodec/mjpegdec.h
>> +++ b/libavcodec/mjpegdec.h
>> @@ -39,6 +39,8 @@
>>  #include "hpeldsp.h"
>>  #include "idctdsp.h"
>>
>> +#undef near /* This file uses struct member 'near' which in windows.h
is defined as empty. */
>> +
>>  #define MAX_COMPONENTS 4
>>
>>  typedef struct MJpegDecodeContext {
>> diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
>> index 9e7cc466de..3180af1d60 100644
>> --- a/libavcodec/mss2.c
>> +++ b/libavcodec/mss2.c
>> @@ -464,9 +464,9 @@ static int decode_wmv9(AVCodecContext *avctx, const
uint8_t *buf, int buf_size,
>>  return 0;
>>  }
>>
>> -typedef struct Rectangle {
>> +struct Rectangle {
>>  int coded, x, y, w, h;
>> -} Rectangle;
>> +};
>>
>>  #define MAX_WMV9_RECTANGLES 20
>>  #define ARITH2_PADDING 2
>> @@ -485,7 +485,7 @@ static int mss2_decode_frame(AVCodecContext *avctx,
void *data, int *got_frame,
>>
>>  int keyframe, has_wmv9, has_mv, is_rle, is_555, ret;
>>
>> -Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>> +struct Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>>  int used_rects = 0, i, implicit_rect = 0, av_uninit(wmv9_mask);
>>
>>  if ((ret = init_get_bits8(, buf, buf_size)) < 0)
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..70a0764714 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1943,7 +1943,13 @@ int av_lockmgr_register(int (*cb)(void **mutex,
enum AVLockOp op))
>>
>>  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>  {
>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>>  _Bool exp = 0;
>> +#else
>> +atomic_bool exp = 0;
>> +#endif
>> +
>>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
!codec->init)
>>  return 0;
>>
>> @@ -1969,7 +1975,13 @@ int ff_lock_avcodec(AVCodecContext *log_ctx,
const AVCodec *codec)
>>
>>  int ff_unlock_avcodec(const AVCodec *codec)
>>  {
>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) &&
!defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>>  _Bool exp = 1;
>> +#else
>> +atomic_bool exp = 1;
>> +#endif
>> +
>>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE ||
!codec->init)
>>  return 0;
>>
>
> These ifdefs here are very ugly, and as mentioned in another mail, the
> atomics in those two functions arent even required - all access to
> those variables is supposed to be protected by the lockmgr anyway.
> So it would be easier to just remove any atomic nature of those
> variables (or at the very lease replace the compare_exchange with a
> store to solve this problem at hand).

I'm not sure but are you proposed to revert commit
https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d
47a559a461


Basically, yes. Atomics are not needed for this variable, as access to it
should be serialized anyways.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 1/3] avformat/mxfenc: use track count to generate component instance uuid

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 10:50:37PM +0100, Tomas Härdin wrote:
> On Thu, 2017-12-07 at 22:40 +0100, Michael Niedermayer wrote:
> > On Thu, Dec 07, 2017 at 04:41:09PM +0100, Tomas Härdin wrote:
> > > On 2017-12-05 05:46, Mark Reid wrote:
> > > > @@ -1398,16 +1397,26 @@ static void
> > > > mxf_write_package(AVFormatContext *s, MXFPackage *package)
> > > >  mxf_write_uuid(pb, SubDescriptor, 0);
> > > >  }
> > > > +/*
> > > > + * for every 1 track in a package there is 1 sequence and 1
> > > > component.
> > > > + * all 3 of these elements share the same instance number
> > > > for generating
> > > > + * there instance uuids. mxf->track_instance_count stores
> > > > this value.
> > > > + * mxf->track_instance_count is incremented after a group of
> > > > all 3 of
> > > > + * these elements are written.
> > > > + */
> > > > +
> > > 
> > > Excellent.
> > > 
> > > Patch looks good to me :)
> > 
> > any reason why you didnt apply it ?
> 
> No access. Plus waiting for feedback on my other comment

ok, if theres anythig i should apply then clearly say so.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH v3 1/3] avformat/mxfenc: use track count to generate component instance uuid

[Tomas Härdin]

On Thu, 2017-12-07 at 22:40 +0100, Michael Niedermayer wrote:
> On Thu, Dec 07, 2017 at 04:41:09PM +0100, Tomas Härdin wrote:
> > On 2017-12-05 05:46, Mark Reid wrote:
> > > @@ -1398,16 +1397,26 @@ static void
> > > mxf_write_package(AVFormatContext *s, MXFPackage *package)
> > >  mxf_write_uuid(pb, SubDescriptor, 0);
> > >  }
> > > +/*
> > > + * for every 1 track in a package there is 1 sequence and 1
> > > component.
> > > + * all 3 of these elements share the same instance number
> > > for generating
> > > + * there instance uuids. mxf->track_instance_count stores
> > > this value.
> > > + * mxf->track_instance_count is incremented after a group of
> > > all 3 of
> > > + * these elements are written.
> > > + */
> > > +
> > 
> > Excellent.
> > 
> > Patch looks good to me :)
> 
> any reason why you didnt apply it ?

No access. Plus waiting for feedback on my other comment

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

[FFmpeg-devel] [PATCH] vf_zscale: Fix alpha destination graph for floating point pixel formats

[Vittorio Giovara]

This was setting the input pixel type instead of the output one,
leading to incorrect data being fed to the library.

Signed-off-by: Vittorio Giovara 
---
 libavfilter/vf_zscale.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 865910bd87..6e1d36cb4c 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -615,7 +615,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 s->alpha_dst_format.width = out->width;
 s->alpha_dst_format.height = out->height;
 s->alpha_dst_format.depth = odesc->comp[0].depth;
-s->alpha_dst_format.pixel_type = (desc->flags & 
AV_PIX_FMT_FLAG_FLOAT) ? ZIMG_PIXEL_FLOAT : odesc->comp[0].depth > 8 ? 
ZIMG_PIXEL_WORD : ZIMG_PIXEL_BYTE;
+s->alpha_dst_format.pixel_type = (odesc->flags & 
AV_PIX_FMT_FLAG_FLOAT) ? ZIMG_PIXEL_FLOAT : odesc->comp[0].depth > 8 ? 
ZIMG_PIXEL_WORD : ZIMG_PIXEL_BYTE;
 s->alpha_dst_format.color_family = ZIMG_COLOR_GREY;
 
 zimg_filter_graph_free(s->alpha_graph);
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH v3 1/3] avformat/mxfenc: use track count to generate component instance uuid

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 04:41:09PM +0100, Tomas Härdin wrote:
> On 2017-12-05 05:46, Mark Reid wrote:
> >@@ -1398,16 +1397,26 @@ static void mxf_write_package(AVFormatContext *s, 
> >MXFPackage *package)
> >  mxf_write_uuid(pb, SubDescriptor, 0);
> >  }
> >+/*
> >+ * for every 1 track in a package there is 1 sequence and 1 component.
> >+ * all 3 of these elements share the same instance number for generating
> >+ * there instance uuids. mxf->track_instance_count stores this value.
> >+ * mxf->track_instance_count is incremented after a group of all 3 of
> >+ * these elements are written.
> >+ */
> >+
> 
> Excellent.
> 
> Patch looks good to me :)

any reason why you didnt apply it ?


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD

[Paul B Mahol]

On 12/7/17, Martin Vignali  wrote:
> Hello,
>
> Patch in attach add a checkasm test for vf_hflip (byte and short)
>
> Martin
>

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

Re: [FFmpeg-devel] [PATCH 2/2] WIP: steps to ditch YUVJ formats

[Paul B Mahol]

On 12/7/17, Michael Niedermayer  wrote:
> On Wed, Dec 06, 2017 at 09:10:22PM +0100, Paul B Mahol wrote:
> [...]
>> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
>> index 2fd9c90d84..be6dcb9307 100644
>> --- a/libavfilter/vf_scale.c
>> +++ b/libavfilter/vf_scale.c
>> @@ -578,6 +578,7 @@ static const AVOption scale_options[] = {
>>  {  "in_range", "set input color range",  OFFSET( in_range),
>> AV_OPT_TYPE_INT, {.i64 = AVCOL_RANGE_UNSPECIFIED }, 0, 2, FLAGS, "range"
>> },
>>  { "out_range", "set output color range", OFFSET(out_range),
>> AV_OPT_TYPE_INT, {.i64 = AVCOL_RANGE_UNSPECIFIED }, 0, 2, FLAGS, "range"
>> },
>>  { "auto",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> AVCOL_RANGE_UNSPECIFIED }, 0, 0, FLAGS, "range" },
>> +{ "unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 =
>> AVCOL_RANGE_UNSPECIFIED }, 0, 0, FLAGS, "range" },
>>  { "full",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_JPEG}, 0,
>> 0, FLAGS, "range" },
>>  { "jpeg",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_JPEG}, 0,
>> 0, FLAGS, "range" },
>>  { "mpeg",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_MPEG}, 0,
>> 0, FLAGS, "range" },
>> --
>
> The change to libavfilter/vf_scale.c is ok

I cannot grasp how to get color_range set by -color_range as encoder option
for mjpeg encoder to pick it up into scale filter insertion as last step
in filtergraph.

Idea is to have user set color_range as encoding option for jpeg
(could be auto added later) and then have scale filter auto inserted
at end of filtergraph and before buffersink so it converts from one
range to another if required.

Please help if you can!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libopenjpeg: support version 2.3.0 and later

[Rodger Combs]

Yup, I did.

> On Dec 7, 2017, at 08:04, James Almer  wrote:
> 
> On 12/7/2017 6:17 AM, Rodger Combs wrote:
>> ---
>> configure   |  2 ++
>> libavcodec/libopenjpegdec.c | 29 +++--
>> libavcodec/libopenjpegenc.c | 29 +++--
>> 3 files changed, 48 insertions(+), 12 deletions(-)
> 
> ?
> 
> Did you send an old patchset by mistake?
> ___
> 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] avfilter/x86/vf_threshold : add SSE4 and AVX2 for threshold 16

[Martin Vignali]

>
> You should also change the cglobal line for x86_32, right below this else
>
>
new patch in attach


0001-avfilter-x86-vf_threshold-add-threshold16-SIMD-SSE4.patch
Description: Binary data


0002-checkasm-vf_threshold-add-test-for-threshold16.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] WIP: steps to ditch YUVJ formats

[Michael Niedermayer]

On Wed, Dec 06, 2017 at 09:10:22PM +0100, Paul B Mahol wrote:
[...]
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index 2fd9c90d84..be6dcb9307 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -578,6 +578,7 @@ static const AVOption scale_options[] = {
>  {  "in_range", "set input color range",  OFFSET( in_range), 
> AV_OPT_TYPE_INT, {.i64 = AVCOL_RANGE_UNSPECIFIED }, 0, 2, FLAGS, "range" },
>  { "out_range", "set output color range", OFFSET(out_range), 
> AV_OPT_TYPE_INT, {.i64 = AVCOL_RANGE_UNSPECIFIED }, 0, 2, FLAGS, "range" },
>  { "auto",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_UNSPECIFIED 
> }, 0, 0, FLAGS, "range" },
> +{ "unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_UNSPECIFIED 
> }, 0, 0, FLAGS, "range" },
>  { "full",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_JPEG}, 0, 0, 
> FLAGS, "range" },
>  { "jpeg",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_JPEG}, 0, 0, 
> FLAGS, "range" },
>  { "mpeg",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_RANGE_MPEG}, 0, 0, 
> FLAGS, "range" },
> -- 

The change to libavfilter/vf_scale.c is ok

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] avfilter/x86/vf_threshold : add SSE4 and AVX2 for threshold 16

[James Almer]

On 12/7/2017 5:10 PM, Martin Vignali wrote:
> 2017-12-03 21:28 GMT+01:00 Martin Vignali :
> 
>>
>>
>> 2017-12-03 21:15 GMT+01:00 James Darnley :
>>
>>> On 2017-12-03 19:30, Martin Vignali wrote:
  libavfilter/x86/vf_threshold.asm| 19 ++-
  libavfilter/x86/vf_threshold_init.c | 34
>>> --
  2 files changed, 34 insertions(+), 19 deletions(-)

 diff --git a/libavfilter/x86/vf_threshold.asm
>>> b/libavfilter/x86/vf_threshold.asm
 index fb008c376a..7b929c6bd2 100644
 --- a/libavfilter/x86/vf_threshold.asm
 +++ b/libavfilter/x86/vf_threshold.asm
 @@ -27,14 +27,21 @@
  SECTION_RODATA

  pb_128: times 16 db 128
 +pb_128_0 : times 16 dw 32768
>>>
>>> No.  Please use db and the values you want.
>>>
>>> I assume this is supposed to be "times 8 db 0, 128".
>>
>>
>>
> Hello,
> 
> new patch in attach (you're right, it's "times 8 db 0, 128")
> 
> 
> Martin
> From ac91cb26724b6e8fe294e0bf9ad2dd17fe0eada9 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Thu, 7 Dec 2017 21:06:43 +0100
> Subject: [PATCH 1/2] avfilter/x86/vf_threshold : add threshold16 SIMD (SSE4 
>  and AVX2)
> 
> ---
>  libavfilter/x86/vf_threshold.asm| 19 +--
>  libavfilter/x86/vf_threshold_init.c | 34 --
>  2 files changed, 33 insertions(+), 20 deletions(-)
> 
> diff --git a/libavfilter/x86/vf_threshold.asm 
> b/libavfilter/x86/vf_threshold.asm
> index 56a6c242d8..dc42cd4971 100644
> --- a/libavfilter/x86/vf_threshold.asm
> +++ b/libavfilter/x86/vf_threshold.asm
> @@ -25,12 +25,14 @@
>  SECTION_RODATA
>  
>  pb_128: times 16 db 128
> +pb_128_0 : times 8 db 0, 128
>  
>  SECTION .text
>  
> -%macro THRESHOLD_8 0
> +;%1 depth (8 or 16) ; %2 b or w ; %3 constant
> +%macro THRESHOLD 3
>  %if ARCH_X86_64
> -cglobal threshold8, 10, 13, 5, in, threshold, min, max, out, ilinesize, 
> tlinesize, flinesize, slinesize, olinesize, w, h, x
> +cglobal threshold%1, 10, 13, 5, in, threshold, min, max, out, ilinesize, 
> tlinesize, flinesize, slinesize, olinesize, w, h, x
>  mov wd, dword wm
>  mov hd, dword hm
>  %else

You should also change the cglobal line for x86_32, right below this else

> @@ -43,7 +45,10 @@ cglobal threshold8, 5, 7, 5, in, threshold, min, max, out, 
> w, x
>  %define olinesizeq  r9mp
>  %define hd  r11mp
>  %endif
> -VBROADCASTI128  m4, [pb_128]
> +VBROADCASTI128  m4, [%3]
> +%if %1 == 16
> +add wq, wq ; w *= 2 (16 bits instead of 8)
> +%endif
>  addinq, wq
>  add thresholdq, wq
>  add   minq, wq
> @@ -60,7 +65,7 @@ cglobal threshold8, 5, 7, 5, in, threshold, min, max, out, 
> w, x
>  movum3, [maxq + xq]
>  pxorm0, m4
>  pxorm1, m4
> -pcmpgtb m0, m1
> +pcmpgt%2m0, m1
>  PBLENDVBm3, m2, m0
>  movu   [outq + xq], m3
>  add xq, mmsize
> @@ -77,9 +82,11 @@ RET
>  %endmacro
>  
>  INIT_XMM sse4
> -THRESHOLD_8
> +THRESHOLD 8, b, pb_128
> +THRESHOLD 16, w, pb_128_0
>  
>  %if HAVE_AVX2_EXTERNAL
>  INIT_YMM avx2
> -THRESHOLD_8
> +THRESHOLD 8, b, pb_128
> +THRESHOLD 16, w, pb_128_0
>  %endif
> diff --git a/libavfilter/x86/vf_threshold_init.c 
> b/libavfilter/x86/vf_threshold_init.c
> index db0559533d..8e42296791 100644
> --- a/libavfilter/x86/vf_threshold_init.c
> +++ b/libavfilter/x86/vf_threshold_init.c
> @@ -23,20 +23,19 @@
>  #include "libavutil/x86/cpu.h"
>  #include "libavfilter/threshold.h"
>  
> -void ff_threshold8_sse4(const uint8_t *in, const uint8_t *threshold,
> -const uint8_t *min, const uint8_t *max,
> -uint8_t *out,
> -ptrdiff_t ilinesize, ptrdiff_t tlinesize,
> -ptrdiff_t flinesize, ptrdiff_t slinesize,
> -ptrdiff_t olinesize,
> -int w, int h);
> -void ff_threshold8_avx2(const uint8_t *in, const uint8_t *threshold,
> -const uint8_t *min, const uint8_t *max,
> -uint8_t *out,
> -ptrdiff_t ilinesize, ptrdiff_t tlinesize,
> -ptrdiff_t flinesize, ptrdiff_t slinesize,
> -ptrdiff_t olinesize,
> -int w, int h);
> +#define THRESHOLD_FUNC(depth, opt) \
> +void ff_threshold##depth##_##opt(const uint8_t *in, const uint8_t 
> *threshold,\
> +const uint8_t *min, const uint8_t *max, \
> +uint8_t *out,   \
> +ptrdiff_t ilinesize, ptrdiff_t tlinesize,   \
> +ptrdiff_t flinesize, ptrdiff_t slinesize,   \
> +

[FFmpeg-devel] checkasm/vf_hflip : add test for vf_hflip SIMD

[Martin Vignali]

Hello,

Patch in attach add a checkasm test for vf_hflip (byte and short)

Martin


0001-avfilter-vf_hflip-move-context-func-init-in.patch
Description: Binary data


0002-checkasm-vf_hflip-add-test-for-vf_hflip-byte-and-sho.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf/utils: add flag to discard timestamps on corrupted frames

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 03:37:38AM -0600, Rodger Combs wrote:
> ---
>  libavformat/avformat.h  |  1 +
>  libavformat/internal.h  |  5 +
>  libavformat/options_table.h |  1 +
>  libavformat/utils.c | 12 
>  4 files changed, 19 insertions(+)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 4f2798a871..e2d88280a8 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
>  #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate 
> seeks for some formats
>  #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
> stream stops.
>  #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as 
> requested by the muxer
> +#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
> frames marked corrupt (replacing with wallclock offset from last non-corrupt 
> frame)

Using wallclock to fill in timestamps feels wrong
if you discard a timestamp it should be set to AV_NOPTS_VALUE or
recomputed based on information from the specification where this is
possible, fps when constant or other hard information.

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH] lavf/mov: atom box parsing return eof cause play fail

[Michael Niedermayer]

On Thu, Dec 07, 2017 at 05:47:46PM +0800, tiejun.peng wrote:
> fix eof lead to play fail.
> 
> Signed-off-by: tiejun.peng 
> ---
>  libavformat/mov.c | 47 ---
>  1 file changed, 36 insertions(+), 11 deletions(-)

please split the addition of warning messages from the change to
EOF behavior

did you check that every EOF return case is safe to continue as if
no error occured ?
That change has quite wide effects possibly unless i misunderstand.


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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] doc/filters: document max luma and chroma matrix size

[Moritz Barsnick]

On Wed, Dec 06, 2017 at 17:03:10 -0900, Lou Logan wrote:

> doc/filters: document max luma and chroma matrix size

You might want to mention that it's for the unsharp filter.

> +Note that the sum of @code{lx}+@code{ly} or @code{cx}+@code{cy} must
> +not exceed a value equal to or greater than 26.

"not exceed" and "greater than" - one of the terms is obsolete.

Thanks for improving the docs,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/x86/vf_threshold : add SSE4 and AVX2 for threshold 16

[Martin Vignali]

2017-12-03 21:28 GMT+01:00 Martin Vignali :

>
>
> 2017-12-03 21:15 GMT+01:00 James Darnley :
>
>> On 2017-12-03 19:30, Martin Vignali wrote:
>> >  libavfilter/x86/vf_threshold.asm| 19 ++-
>> >  libavfilter/x86/vf_threshold_init.c | 34
>> --
>> >  2 files changed, 34 insertions(+), 19 deletions(-)
>> >
>> > diff --git a/libavfilter/x86/vf_threshold.asm
>> b/libavfilter/x86/vf_threshold.asm
>> > index fb008c376a..7b929c6bd2 100644
>> > --- a/libavfilter/x86/vf_threshold.asm
>> > +++ b/libavfilter/x86/vf_threshold.asm
>> > @@ -27,14 +27,21 @@
>> >  SECTION_RODATA
>> >
>> >  pb_128: times 16 db 128
>> > +pb_128_0 : times 16 dw 32768
>>
>> No.  Please use db and the values you want.
>>
>> I assume this is supposed to be "times 8 db 0, 128".
>
>
>
Hello,

new patch in attach (you're right, it's "times 8 db 0, 128")


Martin


0001-avfilter-x86-vf_threshold-add-threshold16-SIMD-SSE4.patch
Description: Binary data


0002-checkasm-vf_threshold-add-test-for-threshold16.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/video: pick sar from link

[Paul B Mahol]

On 12/7/17, Nicolas George  wrote:
> Paul B Mahol (2017-12-07):
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavfilter/video.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> Please explain (in the commit message) why you think this patch is
> needed.

It should not be needed for each filter that sets sample aspect ratio
to set it explicitly also for each and every frame, instead that is
automatically done in get_buffer call.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3 2/2] libavcodec/hevcdec: implement skip_frame

[Stefan _]

On 07.12.2017 at 17:41 Michael Niedermayer wrote:
> The move and the functional change should be in seperate patches
> that keeps changes easy to read and understand
>
> [...]


>From abeb2b106a64d96b216912d4272a734b123b62e2 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Thu, 7 Dec 2017 20:40:35 +0100
Subject: [PATCH 2/2] libavcodec/hevcdec: implement skip_frame

---
 libavcodec/hevcdec.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 433a7056ea..4bfae8c12b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2905,6 +2905,13 @@ static int decode_nal_unit(HEVCContext *s, const H2645NAL *nal)
 if (ret < 0)
 return ret;
 
+if (
+(s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type == HEVC_SLICE_B) ||
+(s->avctx->skip_frame >= AVDISCARD_NONINTRA && s->sh.slice_type != HEVC_SLICE_I) ||
+(s->avctx->skip_frame >= AVDISCARD_NONKEY && !IS_IDR(s))) {
+break;
+}
+
 if (s->sh.first_slice_in_pic_flag) {
 if (s->max_ra == INT_MAX) {
 if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
@@ -3028,7 +3035,14 @@ static int decode_nal_units(HEVCContext *s, const uint8_t *buf, int length)
 
 /* decode the NAL units */
 for (i = 0; i < s->pkt.nb_nals; i++) {
-ret = decode_nal_unit(s, >pkt.nals[i]);
+H2645NAL *nal = >pkt.nals[i];
+
+if (s->avctx->skip_frame >= AVDISCARD_ALL ||
+(s->avctx->skip_frame >= AVDISCARD_NONREF
+&& ff_hevc_nal_is_nonref(nal->type)))
+continue;
+
+ret = decode_nal_unit(s, nal);
 if (ret < 0) {
 av_log(s->avctx, AV_LOG_WARNING,
"Error parsing NAL unit #%d.\n", i);
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] libavcodec/mpegvideo_parser: set field_order correctly for progressive mpeg2

[Aman Gupta]

On Thu, Dec 7, 2017 at 11:42 AM Michael Niedermayer 
wrote:

> On Wed, Dec 06, 2017 at 02:54:50PM -0800, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  libavcodec/mpegvideo_parser.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/mpegvideo_parser.c
> b/libavcodec/mpegvideo_parser.c
> > index de70cd5632..be240b6890 100644
> > --- a/libavcodec/mpegvideo_parser.c
> > +++ b/libavcodec/mpegvideo_parser.c
> > @@ -131,7 +131,7 @@ static void
> mpegvideo_extract_headers(AVCodecParserContext *s,
> >  }
> >  }
> >
> > -if (!pc->progressive_sequence) {
> > +if (!pc->progressive_sequence &&
> !progressive_frame) {
>
> Iam not against this if it results in more correct interlaced detection
> in practice


In my experience, most progressive mpeg2 samples are reported as interlaced
by ffprobe before this change. See for example
https://tmm1.s3.amazonaws.com/720p.ts


> But the spec uses progressive_sequence alone to determine the output
>
> ISO/IEC 13818-2: 1995 (E) / Recommendation ITU-T H.262 (1995 E)
>
> If progressive_sequence is 0 the period between two successive fields
> at the output of the decoding
> process is half of the reciprocal of the frame_rate. See Figure 7-20.
>
> So the commit message seems wrong or inprecisse
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
> ___
> 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 v3 1/2] libavcodec/hevc_filter: move AVDISCARD_NONREF switch-case into function

[Stefan _]

On 07.12.2017 at 17:41 Michael Niedermayer wrote:
> The move and the functional change should be in seperate patches
> that keeps changes easy to read and understand
>
> [...]


>From b5d6c40c6516b90abeeffb7cf8ecd1ca1c3f7cb2 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Thu, 7 Dec 2017 20:37:48 +0100
Subject: [PATCH 1/2] libavcodec/hevc_filter: move AVDISCARD_NONREF switch-case
 into function

In preparation for implementation of skip_frame.
---
 libavcodec/hevc_filter.c | 20 +++-
 libavcodec/hevcdec.h | 20 
 2 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c
index 94fb7cd3d1..6b9824088c 100644
--- a/libavcodec/hevc_filter.c
+++ b/libavcodec/hevc_filter.c
@@ -842,29 +842,15 @@ void ff_hevc_deblocking_boundary_strengths(HEVCContext *s, int x0, int y0,
 void ff_hevc_hls_filter(HEVCContext *s, int x, int y, int ctb_size)
 {
 int x_end = x >= s->ps.sps->width  - ctb_size;
-int skip = 0, is_n = 0;
-switch (s->nal_unit_type) {
-case HEVC_NAL_TRAIL_N:
-case HEVC_NAL_TSA_N:
-case HEVC_NAL_STSA_N:
-case HEVC_NAL_RADL_N:
-case HEVC_NAL_RASL_N:
-case HEVC_NAL_VCL_N10:
-case HEVC_NAL_VCL_N12:
-case HEVC_NAL_VCL_N14:
-case HEVC_NAL_BLA_N_LP:
-case HEVC_NAL_IDR_N_LP:
-is_n = 1;
-break;
-default: break;
-}
+int skip = 0;
 if (s->avctx->skip_loop_filter >= AVDISCARD_ALL ||
 (s->avctx->skip_loop_filter >= AVDISCARD_NONKEY && !IS_IDR(s)) ||
 (s->avctx->skip_loop_filter >= AVDISCARD_NONINTRA &&
  s->sh.slice_type != HEVC_SLICE_I) ||
 (s->avctx->skip_loop_filter >= AVDISCARD_BIDIR &&
  s->sh.slice_type == HEVC_SLICE_B) ||
-(s->avctx->skip_loop_filter >= AVDISCARD_NONREF && is_n))
+(s->avctx->skip_loop_filter >= AVDISCARD_NONREF &&
+ff_hevc_nal_is_nonref(s->nal_unit_type)))
 skip = 1;
 
 if (!skip)
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index ef918f4fb2..b311edc8ae 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -548,6 +548,26 @@ int ff_hevc_frame_nb_refs(HEVCContext *s);
 
 int ff_hevc_set_new_ref(HEVCContext *s, AVFrame **frame, int poc);
 
+static av_always_inline int ff_hevc_nal_is_nonref(enum HEVCNALUnitType type)
+{
+switch (type) {
+case HEVC_NAL_TRAIL_N:
+case HEVC_NAL_TSA_N:
+case HEVC_NAL_STSA_N:
+case HEVC_NAL_RADL_N:
+case HEVC_NAL_RASL_N:
+case HEVC_NAL_VCL_N10:
+case HEVC_NAL_VCL_N12:
+case HEVC_NAL_VCL_N14:
+case HEVC_NAL_BLA_N_LP:
+case HEVC_NAL_IDR_N_LP:
+return 1;
+break;
+default: break;
+}
+return 0;
+}
+
 /**
  * Find next frame in output order and put a reference to it in frame.
  * @return 1 if a frame was output, 0 otherwise
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] libavcodec/mpegvideo_parser: set field_order correctly for progressive mpeg2

[Michael Niedermayer]

On Wed, Dec 06, 2017 at 02:54:50PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/mpegvideo_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
> index de70cd5632..be240b6890 100644
> --- a/libavcodec/mpegvideo_parser.c
> +++ b/libavcodec/mpegvideo_parser.c
> @@ -131,7 +131,7 @@ static void 
> mpegvideo_extract_headers(AVCodecParserContext *s,
>  }
>  }
>  
> -if (!pc->progressive_sequence) {
> +if (!pc->progressive_sequence && !progressive_frame) 
> {

Iam not against this if it results in more correct interlaced detection
in practice
But the spec uses progressive_sequence alone to determine the output

ISO/IEC 13818-2: 1995 (E) / Recommendation ITU-T H.262 (1995 E)

If progressive_sequence is 0 the period between two successive fields at 
the output of the decoding
process is half of the reciprocal of the frame_rate. See Figure 7-20.

So the commit message seems wrong or inprecisse 

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors

[Mateusz]

W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz  wrote:
>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
>> we have included windows.h in much more files and we should
>> avoid conflicts with defines/function declarations.
>>
>> We should declare compatible variables for atomic compat wrappers
>> that expect fixed size variables in atomic_compare_exchange* macro.
>>
>> Signed-off-by: Mateusz Brzostek 
>> ---
>>  libavcodec/jpegls.h   |  2 ++
>>  libavcodec/mjpegdec.h |  2 ++
>>  libavcodec/mss2.c |  6 +++---
>>  libavcodec/utils.c| 12 
>>  libavformat/mxfenc.c  |  2 +-
>>  5 files changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/jpegls.h b/libavcodec/jpegls.h
>> index c8997c7861..6b89b2afa3 100644
>> --- a/libavcodec/jpegls.h
>> +++ b/libavcodec/jpegls.h
>> @@ -32,6 +32,8 @@
>>  #include "avcodec.h"
>>  #include "internal.h"
>>
>> +#undef near /* This file uses struct member 'near' which in windows.h is 
>> defined as empty. */
>> +
>>  typedef struct JpeglsContext {
>>  AVCodecContext *avctx;
>>  } JpeglsContext;
>> diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
>> index c84a40aa6e..c36fba5f22 100644
>> --- a/libavcodec/mjpegdec.h
>> +++ b/libavcodec/mjpegdec.h
>> @@ -39,6 +39,8 @@
>>  #include "hpeldsp.h"
>>  #include "idctdsp.h"
>>
>> +#undef near /* This file uses struct member 'near' which in windows.h is 
>> defined as empty. */
>> +
>>  #define MAX_COMPONENTS 4
>>
>>  typedef struct MJpegDecodeContext {
>> diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
>> index 9e7cc466de..3180af1d60 100644
>> --- a/libavcodec/mss2.c
>> +++ b/libavcodec/mss2.c
>> @@ -464,9 +464,9 @@ static int decode_wmv9(AVCodecContext *avctx, const 
>> uint8_t *buf, int buf_size,
>>  return 0;
>>  }
>>
>> -typedef struct Rectangle {
>> +struct Rectangle {
>>  int coded, x, y, w, h;
>> -} Rectangle;
>> +};
>>
>>  #define MAX_WMV9_RECTANGLES 20
>>  #define ARITH2_PADDING 2
>> @@ -485,7 +485,7 @@ static int mss2_decode_frame(AVCodecContext *avctx, void 
>> *data, int *got_frame,
>>
>>  int keyframe, has_wmv9, has_mv, is_rle, is_555, ret;
>>
>> -Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>> +struct Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>>  int used_rects = 0, i, implicit_rect = 0, av_uninit(wmv9_mask);
>>
>>  if ((ret = init_get_bits8(, buf, buf_size)) < 0)
>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> index baf09119fe..70a0764714 100644
>> --- a/libavcodec/utils.c
>> +++ b/libavcodec/utils.c
>> @@ -1943,7 +1943,13 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum 
>> AVLockOp op))
>>
>>  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>>  {
>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) && 
>> !defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) && 
>> !defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>>  _Bool exp = 0;
>> +#else
>> +atomic_bool exp = 0;
>> +#endif
>> +
>>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>>  return 0;
>>
>> @@ -1969,7 +1975,13 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const 
>> AVCodec *codec)
>>
>>  int ff_unlock_avcodec(const AVCodec *codec)
>>  {
>> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) && 
>> !defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
>> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) && 
>> !defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>>  _Bool exp = 1;
>> +#else
>> +atomic_bool exp = 1;
>> +#endif
>> +
>>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>>  return 0;
>>
> 
> These ifdefs here are very ugly, and as mentioned in another mail, the
> atomics in those two functions arent even required - all access to
> those variables is supposed to be protected by the lockmgr anyway.
> So it would be easier to just remove any atomic nature of those
> variables (or at the very lease replace the compare_exchange with a
> store to solve this problem at hand).

I'm not sure but are you proposed to revert commit
https://github.com/FFmpeg/FFmpeg/commit/590136e78da3d091ea99ab5432543d47a559a461
?

If commit 590136e should stay we could use atomic_intptr_t/intptr_t
for ff_avcodec_locked/exp -- it will be working with all wrappers without
ugly ifdefs.

Mateusz

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

[FFmpeg-devel] [PATCH] avcodec/Makefile: Fix opus parser dependency.

[Jacob Trimble]

The opus.c file uses variables that are defined in opustab.c.  The
opus parser needs to include that file to avoid linker errors when
not including the opus encoder/decoder.

Signed-off-by: Jacob Trimble 
---
 libavcodec/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ab7893f560..ca72138c02 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1005,7 +1005,7 @@ OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
 OBJS-$(CONFIG_MPEGAUDIO_PARSER)+= mpegaudio_parser.o
 OBJS-$(CONFIG_MPEGVIDEO_PARSER)+= mpegvideo_parser.o\
   mpeg12.o mpeg12data.o
-OBJS-$(CONFIG_OPUS_PARSER) += opus_parser.o opus.o vorbis_data.o
+OBJS-$(CONFIG_OPUS_PARSER) += opus_parser.o opus.o opustab.o 
vorbis_data.o
 OBJS-$(CONFIG_PNG_PARSER)  += png_parser.o
 OBJS-$(CONFIG_PNM_PARSER)  += pnm_parser.o pnm.o
 OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
-- 
2.15.1.424.g9478a66081-goog

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

Re: [FFmpeg-devel] [PATCH] avcodec/nvdec: Fix capability check with old drivers.

[Jacob Trimble]

On Thu, Nov 30, 2017 at 12:35 PM, Jacob Trimble  wrote:
> Copied the check from cuviddec.c (*_cuvid decoders) to allow the
> capability check to be optional for older drivers.
>
> Signed-off-by: Jacob Trimble 
> ---
>  libavcodec/nvdec.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index c7a02ff40f..e9e6ea0f8b 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavcodec/nvdec.c
> @@ -91,6 +91,18 @@ static int nvdec_test_capabilities(NVDECDecoder *decoder,
>  caps.eChromaFormat   = params->ChromaFormat;
>  caps.nBitDepthMinus8 = params->bitDepthMinus8;
>
> +if (!decoder->cvdl->cuvidGetDecoderCaps) {
> +av_log(logctx, AV_LOG_WARNING, "Used Nvidia driver is too old to 
> perform a capability check.\n");
> +av_log(logctx, AV_LOG_WARNING, "The minimum required version is "
> +#if defined(_WIN32) || defined(__CYGWIN__)
> +"378.66"
> +#else
> +"378.13"
> +#endif
> +". Continuing blind.\n");
> +return 0;
> +}
> +
>  err = decoder->cvdl->cuvidGetDecoderCaps();
>  if (err != CUDA_SUCCESS) {
>  av_log(logctx, AV_LOG_ERROR, "Failed querying decoder 
> capabilities\n");
> --
> 2.15.0.531.g2ccb3012c9-goog
>

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

Re: [FFmpeg-devel] [PATCH] avfilter/video: pick sar from link

[Nicolas George]

Paul B Mahol (2017-12-07):
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/video.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Please explain (in the commit message) why you think this patch is
needed.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v2] libavcodec/hevc_filter: implement skip_frame

[Michael Niedermayer]

On Wed, Dec 06, 2017 at 06:52:53PM +, Stefan _ wrote:
> On 06.12.2017 at 18:32 Michael Niedermayer wrote:
> > This is duplicated, it should be moved into a seperate function
> >
> > [...]
> >
> Done.
> 

>  hevc_filter.c |   20 +++-
>  hevcdec.c |   16 +++-
>  hevcdec.h |   20 
>  3 files changed, 38 insertions(+), 18 deletions(-)
> 93e3d5a1ccae9cbd0f5774e2666055e5ca4e8dd1  
> 0001-libavcodec-hevc_filter-implement-skip_frame.patch
> From 7a9651040c1c4815d82712cb98dbd7bcf8c085bb Mon Sep 17 00:00:00 2001
> From: sfan5 
> Date: Tue, 5 Dec 2017 23:26:14 +0100
> Subject: [PATCH] libavcodec/hevc_filter: implement skip_frame
> 
> Also move AVDISCARD_NONREF check into inline function.

The move and the functional change should be in seperate patches
that keeps changes easy to read and understand

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

[FFmpeg-devel] [PATCH] avcodec/amrwbdec: Fix division by 0 in voice_factor()

[Michael Niedermayer]

The added value matches "Digital cellular telecommunications system (Phase 2+) 
(GSM); Universal Mobile Telecommunications System (UMTS); LTE; Extended 
Adaptive Multi-Rate - Wideband (AMR-WB+) codec; Floating-point ANSI-C code 
(3GPP TS 26.304 version 14.0.0 Release 14)
Extended Adaptive Multi-Rate - Wideband (AMR-WB+) codec; Floating-point ANSI-C 
code"

Fixes: runtime error: division by zero
Fixes: 4415/clusterfuzz-testcase-minimized-4677752314658816

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/amrwbdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/amrwbdec.c b/libavcodec/amrwbdec.c
index 57aed874cc..7f2874d35f 100644
--- a/libavcodec/amrwbdec.c
+++ b/libavcodec/amrwbdec.c
@@ -611,7 +611,7 @@ static float voice_factor(float *p_vector, float p_gain,
   AMRWB_SFR_SIZE) *
 f_gain * f_gain;
 
-return (p_ener - f_ener) / (p_ener + f_ener);
+return (p_ener - f_ener) / (p_ener + f_ener + 0.01);
 }
 
 /**
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH v3 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Tomas Härdin]

On 2017-12-05 05:46, Mark Reid wrote:

---
  libavformat/mxf.h|  1 +
  libavformat/mxfenc.c | 42 +++---
  2 files changed, 36 insertions(+), 7 deletions(-)


@@ -1476,6 +1495,15 @@ static int 
mxf_write_header_metadata_sets(AVFormatContext *s)
  }
  }
  
+entry = av_dict_get(s->metadata, "reel_name", NULL, 0);

+if (entry) {
+packages[2].name = entry->value;
+packages[2].type = SourcePackage;
+packages[2].instance = 2;
+packages[1].ref = [2];
+package_count = 3;
+}


I guess we can have it check track metadata later if we feel like it. 
Did a patch moving reel_name into AVFormatContext make it into mxfdec 
yet? mxfenc's output surviving a roundtrip through mxfdec + mxfenc might 
be desirable:


    ffmpeg -i somefile_with_reel_name.mkv output.mxf
    ffmpeg -i output.mxf -vcodec copy -acodec copy remuxed.mxf

Ideally remuxed.mxf is identical to output.mxf

/Tomas

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

Re: [FFmpeg-devel] [PATCH v3 1/3] avformat/mxfenc: use track count to generate component instance uuid

[Tomas Härdin]

On 2017-12-05 05:46, Mark Reid wrote:

@@ -1398,16 +1397,26 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
  mxf_write_uuid(pb, SubDescriptor, 0);
  }
  
+/*

+ * for every 1 track in a package there is 1 sequence and 1 component.
+ * all 3 of these elements share the same instance number for generating
+ * there instance uuids. mxf->track_instance_count stores this value.
+ * mxf->track_instance_count is incremented after a group of all 3 of
+ * these elements are written.
+ */
+


Excellent.

Patch looks good to me :)

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

Re: [FFmpeg-devel] [PATCH] lavc/libopenjpeg: support version 2.3.0 and later

[James Almer]

On 12/7/2017 6:17 AM, Rodger Combs wrote:
> ---
>  configure   |  2 ++
>  libavcodec/libopenjpegdec.c | 29 +++--
>  libavcodec/libopenjpegenc.c | 29 +++--
>  3 files changed, 48 insertions(+), 12 deletions(-)

?

Did you send an old patchset by mistake?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

[wm4]

On Wed,  6 Dec 2017 17:27:43 +0800
"tiejun.peng"  wrote:

> fix #6895: https://trac.ffmpeg.org/ticket/6895
> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3
> 
> Signed-off-by: tiejun.peng 
> ---
>  libavformat/mp3dec.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index a76fe32..286eb68 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -73,6 +73,7 @@ static int mp3_read_probe(AVProbeData *p)
>  int frames, ret;
>  uint32_t header;
>  const uint8_t *buf, *buf0, *buf2, *end;
> +int match_size = 0;
>  
>  buf0 = p->buf;
>  end = p->buf + p->buf_size - sizeof(uint32_t);
> @@ -92,6 +93,7 @@ static int mp3_read_probe(AVProbeData *p)
>  if (ret != 0)
>  break;
>  buf2 += h.frame_size;
> +match_size += h.frame_size;
>  }
>  max_frames = FFMAX(max_frames, frames);
>  if(buf == buf0) {
> @@ -104,6 +106,8 @@ static int mp3_read_probe(AVProbeData *p)
>  // issues with MPEG-files!
>  if   (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1;
>  else if(max_frames>200)return AVPROBE_SCORE_EXTENSION;
> +// over 50% of probe size is valid
> +else if (p->buf_size > 1 && match_size > (p->buf_size/2)) return 
> AVPROBE_SCORE_EXTENSION;
>  else if(max_frames>=4 && max_frames >= p->buf_size/1) return 
> AVPROBE_SCORE_EXTENSION / 2;
>  else if(ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) && 
> 2*ff_id3v2_tag_len(buf0) >= p->buf_size)
> return p->buf_size < PROBE_BUF_MAX ? 
> AVPROBE_SCORE_EXTENSION / 4 : AVPROBE_SCORE_EXTENSION - 2;

That doesn't necessarily affect whether this patch should be applied,
but: I think this mp4 probe should really be cleaned up. It's one of
the most complex probe functions, and it doesn't even work correctly.
It still detects some ELF files as mp3 (or mp1/2), for example.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] lavc: add back AD_HOC method for DXVA2/D3D11/VAAPI/VDPAU

[Thomas Guillem]

---
 libavcodec/hwaccel.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
index 16ee822920..292a87f6b5 100644
--- a/libavcodec/hwaccel.h
+++ b/libavcodec/hwaccel.h
@@ -75,15 +75,15 @@ typedef struct AVCodecHWConfigInternal {
 }
 
 #define HWACCEL_DXVA2(codec) \
-HW_CONFIG_HWACCEL(DXVA2_VLD, 0,  DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
+HW_CONFIG_HWACCEL(DXVA2_VLD, 1,  DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
 #define HWACCEL_D3D11VA2(codec) \
-HW_CONFIG_HWACCEL(D3D11, 0,  D3D11VA, ff_ ## codec ## 
_d3d11va2_hwaccel)
+HW_CONFIG_HWACCEL(D3D11, 1,  D3D11VA, ff_ ## codec ## 
_d3d11va2_hwaccel)
 #define HWACCEL_NVDEC(codec) \
 HW_CONFIG_HWACCEL(CUDA,  0, CUDA,ff_ ## codec ## _nvdec_hwaccel)
 #define HWACCEL_VAAPI(codec) \
-HW_CONFIG_HWACCEL(VAAPI, 0,  VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
+HW_CONFIG_HWACCEL(VAAPI, 1,  VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
 #define HWACCEL_VDPAU(codec) \
-HW_CONFIG_HWACCEL(VDPAU, 0,  VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
+HW_CONFIG_HWACCEL(VDPAU, 1,  VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
 #define HWACCEL_VIDEOTOOLBOX(codec) \
 HW_CONFIG_HWACCEL(VIDEOTOOLBOX, 0, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/2] lavc: change HW_CONFIG_HWACCEL arguments

[Thomas Guillem]

Add a boolean to specify if an API can work with
AV_CODEC_HW_CONFIG_METHOD_AD_HOC.
---
 libavcodec/hwaccel.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
index ae55527c2f..16ee822920 100644
--- a/libavcodec/hwaccel.h
+++ b/libavcodec/hwaccel.h
@@ -42,12 +42,13 @@ typedef struct AVCodecHWConfigInternal {
 
 // These macros are used to simplify AVCodecHWConfigInternal definitions.
 
-#define HW_CONFIG_HWACCEL(format, device, name) \
+#define HW_CONFIG_HWACCEL(format, ad_hoc, device, name) \
 &(const AVCodecHWConfigInternal) { \
 .public  = { \
 .pix_fmt = AV_PIX_FMT_ ## format, \
 .methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX | \
-   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX, \
+   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX | \
+   ad_hoc ? AV_CODEC_HW_CONFIG_METHOD_AD_HOC : 0, \
 .device_type = AV_HWDEVICE_TYPE_ ## device, \
 }, \
 .hwaccel = , \
@@ -74,17 +75,17 @@ typedef struct AVCodecHWConfigInternal {
 }
 
 #define HWACCEL_DXVA2(codec) \
-HW_CONFIG_HWACCEL(DXVA2_VLD, DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
+HW_CONFIG_HWACCEL(DXVA2_VLD, 0,  DXVA2,   ff_ ## codec ## _dxva2_hwaccel)
 #define HWACCEL_D3D11VA2(codec) \
-HW_CONFIG_HWACCEL(D3D11, D3D11VA, ff_ ## codec ## _d3d11va2_hwaccel)
+HW_CONFIG_HWACCEL(D3D11, 0,  D3D11VA, ff_ ## codec ## 
_d3d11va2_hwaccel)
 #define HWACCEL_NVDEC(codec) \
-HW_CONFIG_HWACCEL(CUDA,  CUDA,ff_ ## codec ## _nvdec_hwaccel)
+HW_CONFIG_HWACCEL(CUDA,  0, CUDA,ff_ ## codec ## _nvdec_hwaccel)
 #define HWACCEL_VAAPI(codec) \
-HW_CONFIG_HWACCEL(VAAPI, VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
+HW_CONFIG_HWACCEL(VAAPI, 0,  VAAPI,   ff_ ## codec ## _vaapi_hwaccel)
 #define HWACCEL_VDPAU(codec) \
-HW_CONFIG_HWACCEL(VDPAU, VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
+HW_CONFIG_HWACCEL(VDPAU, 0,  VDPAU,   ff_ ## codec ## _vdpau_hwaccel)
 #define HWACCEL_VIDEOTOOLBOX(codec) \
-HW_CONFIG_HWACCEL(VIDEOTOOLBOX, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
+HW_CONFIG_HWACCEL(VIDEOTOOLBOX, 0, VIDEOTOOLBOX, ff_ ## codec ## 
_videotoolbox_hwaccel)
 
 #define HWACCEL_D3D11VA(codec) \
 HW_CONFIG_AD_HOC_HWACCEL(D3D11VA_VLD, ff_ ## codec ## _d3d11va_hwaccel)
-- 
2.11.0

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

[FFmpeg-devel] [PATCH] Added Turing codec to ffmpeg

[Matteo Naccari]

- This patch contains the changes required to interface the Turing codec
  (http://turingcodec.org/) to ffmpeg
---
 Changelog  |   1 +
 LICENSE.md |   1 +
 configure  |   6 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libturing.c | 338 +
 6 files changed, 348 insertions(+)
 create mode 100644 libavcodec/libturing.c

diff --git a/Changelog b/Changelog
index a1a7557..9ed18b5 100644
--- a/Changelog
+++ b/Changelog
@@ -25,6 +25,7 @@ version :
 - AMD AMF H.264 and HEVC encoders
 - video fillborders filter
 - video setrange filter
+- Added support to interface with the Turing codec
 
 
 version 3.4:
diff --git a/LICENSE.md b/LICENSE.md
index ba65b05..03787c0 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -84,6 +84,7 @@ The following libraries are under GPL:
 - frei0r
 - libcdio
 - librubberband
+- libturing
 - libvidstab
 - libx264
 - libx265
diff --git a/configure b/configure
index d053886..9be1fcb 100755
--- a/configure
+++ b/configure
@@ -260,6 +260,7 @@ External library support:
   --enable-libssh  enable SFTP protocol via libssh [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
+  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -1551,6 +1552,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
 frei0r
 libcdio
 librubberband
+libturing
 libvidstab
 libx264
 libx265
@@ -2963,6 +2965,7 @@ libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
+libturing_encoder_deps="libturing"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
@@ -5889,6 +5892,9 @@ enabled libssh&& require_pkg_config libssh 
libssh libssh/sftp.h sftp
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
+enabled libturing && require_pkg_config libturing libturing turing.h 
turing_version &&
+ { check_cpp_condition turing.h 
"TURING_API_VERSION > 1" ||
+   die "ERROR: libturing requires turing api 
version 2 or greater."; }
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
  { check_lib libtwolame twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ab7893f..1c8d945 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -952,6 +952,7 @@ OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
+OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
 OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ed1e7ab..b42630d 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -551,6 +551,7 @@ static void register_all(void)
 REGISTER_ENCODER(LIBSHINE,  libshine);
 REGISTER_ENCDEC (LIBSPEEX,  libspeex);
 REGISTER_ENCODER(LIBTHEORA, libtheora);
+REGISTER_ENCODER(LIBTURING, libturing);
 REGISTER_ENCODER(LIBTWOLAME,libtwolame);
 REGISTER_ENCODER(LIBVO_AMRWBENC,libvo_amrwbenc);
 REGISTER_ENCDEC (LIBVORBIS, libvorbis);
diff --git a/libavcodec/libturing.c b/libavcodec/libturing.c
new file mode 100644
index 000..ac64797
--- /dev/null
+++ b/libavcodec/libturing.c
@@ -0,0 +1,338 @@
+/*
+ * libturing encoder
+ *
+ * Copyright (c) 2017 Turing Codec contributors
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or 

Re: [FFmpeg-devel] [PATCH] fix MSVC compilation errors

[Hendrik Leppkes]

On Thu, Dec 7, 2017 at 2:02 AM, Mateusz  wrote:
> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
> we have included windows.h in much more files and we should
> avoid conflicts with defines/function declarations.
>
> We should declare compatible variables for atomic compat wrappers
> that expect fixed size variables in atomic_compare_exchange* macro.
>
> Signed-off-by: Mateusz Brzostek 
> ---
>  libavcodec/jpegls.h   |  2 ++
>  libavcodec/mjpegdec.h |  2 ++
>  libavcodec/mss2.c |  6 +++---
>  libavcodec/utils.c| 12 
>  libavformat/mxfenc.c  |  2 +-
>  5 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/jpegls.h b/libavcodec/jpegls.h
> index c8997c7861..6b89b2afa3 100644
> --- a/libavcodec/jpegls.h
> +++ b/libavcodec/jpegls.h
> @@ -32,6 +32,8 @@
>  #include "avcodec.h"
>  #include "internal.h"
>
> +#undef near /* This file uses struct member 'near' which in windows.h is 
> defined as empty. */
> +
>  typedef struct JpeglsContext {
>  AVCodecContext *avctx;
>  } JpeglsContext;
> diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
> index c84a40aa6e..c36fba5f22 100644
> --- a/libavcodec/mjpegdec.h
> +++ b/libavcodec/mjpegdec.h
> @@ -39,6 +39,8 @@
>  #include "hpeldsp.h"
>  #include "idctdsp.h"
>
> +#undef near /* This file uses struct member 'near' which in windows.h is 
> defined as empty. */
> +
>  #define MAX_COMPONENTS 4
>
>  typedef struct MJpegDecodeContext {
> diff --git a/libavcodec/mss2.c b/libavcodec/mss2.c
> index 9e7cc466de..3180af1d60 100644
> --- a/libavcodec/mss2.c
> +++ b/libavcodec/mss2.c
> @@ -464,9 +464,9 @@ static int decode_wmv9(AVCodecContext *avctx, const 
> uint8_t *buf, int buf_size,
>  return 0;
>  }
>
> -typedef struct Rectangle {
> +struct Rectangle {
>  int coded, x, y, w, h;
> -} Rectangle;
> +};
>
>  #define MAX_WMV9_RECTANGLES 20
>  #define ARITH2_PADDING 2
> @@ -485,7 +485,7 @@ static int mss2_decode_frame(AVCodecContext *avctx, void 
> *data, int *got_frame,
>
>  int keyframe, has_wmv9, has_mv, is_rle, is_555, ret;
>
> -Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
> +struct Rectangle wmv9rects[MAX_WMV9_RECTANGLES], *r;
>  int used_rects = 0, i, implicit_rect = 0, av_uninit(wmv9_mask);
>
>  if ((ret = init_get_bits8(, buf, buf_size)) < 0)
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index baf09119fe..70a0764714 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1943,7 +1943,13 @@ int av_lockmgr_register(int (*cb)(void **mutex, enum 
> AVLockOp op))
>
>  int ff_lock_avcodec(AVCodecContext *log_ctx, const AVCodec *codec)
>  {
> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) && 
> !defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) && 
> !defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>  _Bool exp = 0;
> +#else
> +atomic_bool exp = 0;
> +#endif
> +
>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>  return 0;
>
> @@ -1969,7 +1975,13 @@ int ff_lock_avcodec(AVCodecContext *log_ctx, const 
> AVCodec *codec)
>
>  int ff_unlock_avcodec(const AVCodec *codec)
>  {
> +#if !defined(COMPAT_ATOMICS_DUMMY_STDATOMIC_H) && 
> !defined(COMPAT_ATOMICS_PTHREAD_STDATOMIC_H) && \
> +!defined(COMPAT_ATOMICS_SUNCC_STDATOMIC_H) && 
> !defined(COMPAT_ATOMICS_WIN32_STDATOMIC_H)
>  _Bool exp = 1;
> +#else
> +atomic_bool exp = 1;
> +#endif
> +
>  if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE || !codec->init)
>  return 0;
>

These ifdefs here are very ugly, and as mentioned in another mail, the
atomics in those two functions arent even required - all access to
those variables is supposed to be protected by the lockmgr anyway.
So it would be easier to just remove any atomic nature of those
variables (or at the very lease replace the compare_exchange with a
store to solve this problem at hand).

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

[FFmpeg-devel] [PATCH] lavf/mov: atom box parsing return eof cause play fail

[tiejun.peng]

fix eof lead to play fail.

Signed-off-by: tiejun.peng 
---
 libavformat/mov.c | 47 ---
 1 file changed, 36 insertions(+), 11 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index c901859..6c3567f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1991,8 +1991,10 @@ static int mov_read_stco(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->chunk_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STCO atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2522,8 +2524,10 @@ int ff_mov_read_stsd_entries(MOVContext *c, AVIOContext 
*pb, int entries)
 sc->stsd_count++;
 }
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSD atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2624,8 +2628,10 @@ static int mov_read_stsc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->stsc_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSC atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2676,8 +2682,10 @@ static int mov_read_stps(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->stps_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STPS atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2723,8 +2731,10 @@ static int mov_read_stss(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->keyframe_count = i;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSS atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2808,8 +2818,10 @@ static int mov_read_stsz(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 av_free(buf);
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STSZ atom\n");
 return AVERROR_EOF;
+}
 
 return 0;
 }
@@ -2870,8 +2882,10 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 sc->duration_for_fps  += duration;
 sc->nb_frames_for_fps += total_sample_count;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted STTS atom\n");
 return AVERROR_EOF;
+}
 
 st->nb_frames= total_sample_count;
 if (duration)
@@ -2948,8 +2962,10 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->ctts_count = ctts_count;
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted CTTS atom\n");
 return AVERROR_EOF;
+}
 
 av_log(c->fc, AV_LOG_TRACE, "dts shift %d\n", sc->dts_shift);
 
@@ -2995,7 +3011,12 @@ static int mov_read_sbgp(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->rap_group_count = i;
 
-return pb->eof_reached ? AVERROR_EOF : 0;
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted SBGP atom\n");
+return AVERROR_EOF;
+}
+
+return 0;
 }
 
 /**
@@ -4720,8 +4741,10 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 fix_frag_index_entries(>frag_index, next_frag_index,
frag->track_id, entries);
 
-if (pb->eof_reached)
+if (pb->eof_reached) {
+av_log(c->fc, AV_LOG_WARNING, "reached eof, corrupted TRUN atom\n");
 return AVERROR_EOF;
+}
 
 frag->implicit_offset = offset;
 
@@ -6609,7 +6632,9 @@ static int mov_read_header(AVFormatContext *s)
 do {
 if (mov->moov_retry)
 avio_seek(pb, 0, SEEK_SET);
-if ((err = mov_read_default(mov, pb, atom)) < 0) {
+/* EOF don't mean the file to play fail*/
+err = mov_read_default(mov, pb, atom);
+if (err < 0 && err != AVERROR_EOF) {
 av_log(s, AV_LOG_ERROR, "error reading header\n");
 mov_read_close(s);
 return err;
-- 
2.7.4



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

[FFmpeg-devel] [PATCH 1/2] lavf/mpegts: mark packets with TEI flag as corrupted

[Rodger Combs]

---
 libavformat/mpegts.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 53cbcfb543..0a3ad05726 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2296,6 +2296,14 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 }
 }
 
+if (packet[1] & 0x80) {
+av_log(ts->stream, AV_LOG_DEBUG, "Packet had TEI flag set; marking as 
corrupt\n");
+if (tss->type == MPEGTS_PES) {
+PESContext *pc = tss->u.pes_filter.opaque;
+pc->flags |= AV_PKT_FLAG_CORRUPT;
+}
+}
+
 p = packet + 4;
 if (has_adaptation) {
 int64_t pcr_h;
-- 
2.14.3

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

[FFmpeg-devel] [PATCH 2/2] lavf/utils: add flag to discard timestamps on corrupted frames

[Rodger Combs]

---
 libavformat/avformat.h  |  1 +
 libavformat/internal.h  |  5 +
 libavformat/options_table.h |  1 +
 libavformat/utils.c | 12 
 4 files changed, 19 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 4f2798a871..e2d88280a8 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1450,6 +1450,7 @@ typedef struct AVFormatContext {
 #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate seeks 
for some formats
 #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
stream stops.
 #define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as requested 
by the muxer
+#define AVFMT_FLAG_DISCARD_CORRUPT_TS 0x40 ///< Discard timestamps of 
frames marked corrupt (replacing with wallclock offset from last non-corrupt 
frame)
 
 /**
  * Maximum size of the data read from input for determining
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 36a57214ce..39a69cf630 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -192,6 +192,11 @@ struct AVStreamInternal {
 int need_context_update;
 
 FFFrac *priv_pts;
+
+/**
+ * The wallclock timestamp of the most recent read packet (if 
AVFMT_FLAG_DISCARD_CORRUPT_TS is set)
+ */
+int64_t cur_wallclock_time;
 };
 
 #ifdef __GNUC__
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index b8fa47c6fd..515574d3e0 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -58,6 +58,7 @@ static const AVOption avformat_options[] = {
 {"bitexact", "do not write random/volatile data", 0, AV_OPT_TYPE_CONST, { .i64 
= AVFMT_FLAG_BITEXACT }, 0, 0, E, "fflags" },
 {"shortest", "stop muxing with the shortest stream", 0, AV_OPT_TYPE_CONST, { 
.i64 = AVFMT_FLAG_SHORTEST }, 0, 0, E, "fflags" },
 {"autobsf", "add needed bsfs automatically", 0, AV_OPT_TYPE_CONST, { .i64 = 
AVFMT_FLAG_AUTO_BSF }, 0, 0, E, "fflags" },
+{"discardcorruptts", "discard timestamps on corrupted frames", 0, 
AV_OPT_TYPE_CONST, { .i64 = AVFMT_FLAG_DISCARD_CORRUPT_TS }, 0, 0, E, "fflags" 
},
 {"analyzeduration", "specify how many microseconds are analyzed to probe the 
input", OFFSET(max_analyze_duration), AV_OPT_TYPE_INT64, {.i64 = 0 }, 0, 
INT64_MAX, D},
 {"cryptokey", "decryption key", OFFSET(key), AV_OPT_TYPE_BINARY, {.dbl = 0}, 
0, 0, D},
 {"indexmem", "max memory used for timestamp index (per stream)", 
OFFSET(max_index_size), AV_OPT_TYPE_INT, {.i64 = 1<<20 }, 0, INT_MAX, D},
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 84e49208b8..1adb007244 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -873,6 +873,18 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 st->cur_dts = wrap_timestamp(st, st->cur_dts);
 }
 
+if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT_TS)) {
+int64_t cur_wallclock_time = av_gettime_relative();
+if (pkt->flags & AV_PKT_FLAG_CORRUPT) {
+int64_t wallclock_offset = 
av_rescale_q(st->internal->cur_wallclock_time - cur_wallclock_time, 
AV_TIME_BASE_Q, st->time_base);
+pkt->pts = pkt->dts = st->cur_dts + FFMAX(wallclock_offset, 1);
+av_log(s, AV_LOG_WARNING,
+   "Discarded timestamp on corrupted packet (stream = 
%d)\n",
+   pkt->stream_index);
+}
+st->internal->cur_wallclock_time = cur_wallclock_time;
+}
+
 pkt->dts = wrap_timestamp(st, pkt->dts);
 pkt->pts = wrap_timestamp(st, pkt->pts);
 
-- 
2.14.3

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

Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail

[Tiejun.Peng]

Playback of the mp3 file sounds very good with VLC media player 2.2.2 
Weatherwax (revision 2.2.2-0-g6259d80)


Tiejun Peng

-- Original --
From:  "Carl Eugen Hoyos";;
Send time: Thursday, Dec 7, 2017 0:00 AM
To: "FFmpeg development discussions and patches"; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



2017-12-06 10:27 GMT+01:00 tiejun.peng :
> fix #6895: https://trac.ffmpeg.org/ticket/6895

The patch breaks issue3327-libc-2.17.so

> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3

Which player does something useful with this file?

I am not saying there can't be an issue, but not detecting
severely broken files does not sound necessarily wrong
to me.

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

[FFmpeg-devel] [PATCH] avfilter/video: pick sar from link

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/video.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavfilter/video.c b/libavfilter/video.c
index 6f9020b9fe..7a8e587798 100644
--- a/libavfilter/video.c
+++ b/libavfilter/video.c
@@ -43,6 +43,7 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w, 
int h)
 
 AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int w, int h)
 {
+AVFrame *frame = NULL;
 int pool_width = 0;
 int pool_height = 0;
 int pool_align = 0;
@@ -86,7 +87,13 @@ AVFrame *ff_default_get_video_buffer(AVFilterLink *link, int 
w, int h)
 }
 }
 
-return ff_frame_pool_get(link->frame_pool);
+frame = ff_frame_pool_get(link->frame_pool);
+if (!frame)
+return NULL;
+
+frame->sample_aspect_ratio = link->sample_aspect_ratio;
+
+return frame;
 }
 
 AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h)
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] configure: Allow users to disable all hwaccel libraries

[Gyan Doshi]

On 12/7/2017 12:59 PM, Tobias Rapp wrote:


Why not add the HWACCEL_AUTODETECT_LIBRARY_LIST to --disable-hwaccels?


That is a better choice but there wasn't a bespoke case for 
'--disable-hwaccels', so originally ignored that possibility. Added it 
in attached (new) patch.


Either one - this or original patch - works for me.

Regards,
Gyan
From f5c02c73ad3560a2173611ec1e76a460cf70d944 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Thu, 7 Dec 2017 14:44:01 +0530
Subject: [PATCH] configure - extend disable_hwaccels to disable autodetected
 hwaccel libs

---
 configure | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index d05388638d..77812759fd 100755
--- a/configure
+++ b/configure
@@ -159,7 +159,7 @@ Individual component options:
   --disable-decoders   disable all decoders
   --disable-hwaccel=NAME   disable hwaccel NAME
   --enable-hwaccel=NAMEenable hwaccel NAME
-  --disable-hwaccels   disable all hwaccels
+  --disable-hwaccels   disable all hwaccels and autodetected hwaccel libs
   --disable-muxer=NAME disable muxer NAME
   --enable-muxer=NAME  enable muxer NAME
   --disable-muxers disable all muxers
@@ -3630,6 +3630,9 @@ for opt do
 --extra-libs=*)
 add_extralibs $optval
 ;;
+--disable-hwaccels)
+disable $HWACCEL_LIST $HWACCEL_AUTODETECT_LIBRARY_LIST
+;;
 --disable-devices)
 disable $INDEV_LIST $OUTDEV_LIST
 ;;
-- 
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/libopenjpeg: support version 2.3.0 and later

[Rodger Combs]

---
 configure   |  2 ++
 libavcodec/libopenjpegdec.c | 29 +++--
 libavcodec/libopenjpegenc.c | 29 +++--
 3 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/configure b/configure
index ae0eddac6c..27bed3a20d 100755
--- a/configure
+++ b/configure
@@ -1934,6 +1934,7 @@ HEADERS_LIST="
 openjpeg_2_1_openjpeg_h
 openjpeg_2_0_openjpeg_h
 openjpeg_1_5_openjpeg_h
+opj_config_h
 OpenGL_gl3_h
 poll_h
 soundcard_h
@@ -5972,6 +5973,7 @@ enabled libopenjpeg   && { { check_lib libopenjpeg 
openjpeg-2.2/openjpeg.h o
{ check_lib libopenjpeg openjpeg-2.0/openjpeg.h 
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
{ check_lib libopenjpeg openjpeg-1.5/openjpeg.h 
opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
{ check_lib libopenjpeg openjpeg.h opj_version 
-lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+   { use_pkg_config libopenjpeg libopenjp2 
openjpeg.h opj_version && check_header opj_config.h; } ||
die "ERROR: libopenjpeg not found"; }
 enabled libopenmpt&& require_pkg_config libopenmpt "libopenmpt >= 
0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create
 enabled libopus   && {
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 1210123265..822140c181 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -36,18 +36,37 @@
 
 #if HAVE_OPENJPEG_2_2_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(2, 2, 0)
 #elif HAVE_OPENJPEG_2_1_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(2, 1, 0)
 #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(2, 0, 0)
 #elif HAVE_OPENJPEG_1_5_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(1, 5, 0)
 #else
 #  include 
 #endif
 
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H || 
HAVE_OPENJPEG_2_0_OPENJPEG_H
-#  define OPENJPEG_MAJOR_VERSION 2
+#if HAVE_OPJ_CONFIG_H
+#  include 
+#  ifndef OPJ_VERSION_INT
+#define OPJ_VERSION_INT AV_VERSION_INT(OPJ_VERSION_MAJOR, 
OPJ_VERSION_MINOR, OPJ_VERSION_BUILD)
+#  endif
+#endif
+
+#ifndef OPJ_VERSION_INT
+#  define OPJ_VERSION_INT AV_VERSION_INT(1, 0, 0)
+#endif
+
+#ifndef OPJ_VERSION_MAJOR
+#  define AV_VERSION_MAJOR AV_VERSION_MAJOR(OPJ_VERSION_INT)
+#endif
+
+#if OPJ_VERSION_MAJOR >= 2
+#  define OPENJPEG_MAJOR_VERSION OPJ_VERSION_MAJOR
 #  define OPJ(x) OPJ_##x
 #else
 #  define OPENJPEG_MAJOR_VERSION 1
@@ -431,12 +450,10 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 opj_stream_set_read_function(stream, stream_read);
 opj_stream_set_skip_function(stream, stream_skip);
 opj_stream_set_seek_function(stream, stream_seek);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if OPJ_VERSION_INT >= AV_VERSION_INT(2, 1, 0)
 opj_stream_set_user_data(stream, , NULL);
-#elif HAVE_OPENJPEG_2_0_OPENJPEG_H
-opj_stream_set_user_data(stream, );
 #else
-#error Missing call to opj_stream_set_user_data
+opj_stream_set_user_data(stream, );
 #endif
 opj_stream_set_user_data_length(stream, avpkt->size);
 // Decode the header only.
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index b67e533d1d..6c2e4c5ea6 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -34,18 +34,37 @@
 
 #if HAVE_OPENJPEG_2_2_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(2, 2, 0)
 #elif HAVE_OPENJPEG_2_1_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(2, 1, 0)
 #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(2, 0, 0)
 #elif HAVE_OPENJPEG_1_5_OPENJPEG_H
 #  include 
+#  define OPJ_VERSION_INT AV_VERSION_INT(1, 5, 0)
 #else
 #  include 
 #endif
 
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H || 
HAVE_OPENJPEG_2_0_OPENJPEG_H
-#  define OPENJPEG_MAJOR_VERSION 2
+#if HAVE_OPJ_CONFIG_H
+#  include 
+#  ifndef OPJ_VERSION_INT
+#define OPJ_VERSION_INT AV_VERSION_INT(OPJ_VERSION_MAJOR, 
OPJ_VERSION_MINOR, OPJ_VERSION_BUILD)
+#  endif
+#endif
+
+#ifndef OPJ_VERSION_INT
+#  define OPJ_VERSION_INT AV_VERSION_INT(1, 0, 0)
+#endif
+
+#ifndef OPJ_VERSION_MAJOR
+#  define AV_VERSION_MAJOR AV_VERSION_MAJOR(OPJ_VERSION_INT)
+#endif
+
+#if OPJ_VERSION_MAJOR >= 2
+#  define OPENJPEG_MAJOR_VERSION OPJ_VERSION_MAJOR
 #  define OPJ(x) OPJ_##x
 #else
 #  define OPENJPEG_MAJOR_VERSION 1
@@ -771,12 +790,10 @@ static int libopenjpeg_encode_frame(AVCodecContext 
*avctx, AVPacket *pkt,
 opj_stream_set_write_function(stream, stream_write);
 opj_stream_set_skip_function(stream, stream_skip);
 opj_stream_set_seek_function(stream, stream_seek);
-#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H

[FFmpeg-devel] [PATCH] build: fix build with OpenCL

[Rodger Combs]

---
 fftools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/Makefile b/fftools/Makefile
index 094f6d6265..9b211aa4d5 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -21,7 +21,7 @@ OBJS-ffserver  += 
fftools/ffserver_config.o
 
 define DOFFTOOL
 OBJS-$(1)-$(CONFIG_OPENCL) += fftools/cmdutils_opencl.o
-OBJS-$(1) += fftools/cmdutils.o fftools/$(1).o $(OBJS-$(1)-yes)
+OBJS-$(1) += fftools/cmdutils.o fftools/$(1).o $$(OBJS-$(1)-yes)
 $(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1))
 $$(OBJS-$(1)): | fftools
 $$(OBJS-$(1)): CFLAGS  += $(CFLAGS-$(1))
-- 
2.14.3

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