Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Steven Liu]

2017-09-06 14:06 GMT+08:00 Jeyapal, Karthick :
> Hi Steven,
>
> I am restarting this discussion, just to conclude this thread one way or the 
> other. Maybe I am not thinking correctly. Here is detailed thinking, on why I 
> think this patch will not violate HLS spec.
>
>>if (target_duration <= en->duration)
>>target_duration = (hls->flags & HLS_ROUND_DURATIONS) ?
>>lrint(en->duration) : get_int_from_double(en->duration);
>
> As per the above code, target duration will be maximum of all 
> lrint(en->duration) when HLS_ROUND_DURATIONS is set.
>
>>if (hls->flags & HLS_ROUND_DURATIONS)
>>avio_printf(out, "#EXTINF:%ld,\n",  lrint(en->duration));
>>else
>>avio_printf(out, "#EXTINF:%f,\n", en->duration);
>
> As per this code #EXTINF duration will be lrint(en->duration) when 
> HLS_ROUND_DURATIONS is set.
>
>>https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.3.1
>>
>>4.3.3.1.  EXT-X-TARGETDURATION
>>
>>   The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
>>   duration.  The EXTINF duration of each Media Segment in the Playlist
>>   file, when rounded to the nearest integer, MUST be less than or equal
>>   to the target duration; longer segments can trigger playback stalls
>>   or other errors.  It applies to the entire Playlist file.  Its format
>>   is:
>>
>>   #EXT-X-TARGETDURATION:
>>
>>   where s is a decimal-integer indicating the target duration in
>>   seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.
>
> As rightly pointed by you, spec says “The EXTINF duration of each Media 
> Segment in the Playlist file, when rounded to the nearest integer, MUST be 
> less than or equal to the target duration”. With this patch this is always 
> true, and hence there is no violation of spec.
>
> Maybe I misunderstood and missing out something very obvious. Could you let 
> me know the situation in which this code will generate target duration lesser 
> than the EXTINF duration? Thanks for your help.

segment1.ts   duration = 4.88
ROUND is 5, not 4,  is it?
if its duration = 4.04
ROUND is 4,   the real segment1.ts duration is 4.04,

the safe one is TARGETDURATION = 5, the get_int_from_ double API can
make the truely,

yes, your patch can make 4.88 to 5, and make 4.04 to 4, all
solution's TARGETDURATION is INT, but just make safe, i know the lrint
API, so that is why have not use it, not i don't know lrint.
>
> Regards,
> Karthick
>
> ___
> 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] libswscale/swscale_unscaled: fix DITHER_COPY macro

[Mateusz]

W dniu 2017-09-06 o 02:07, Michael Niedermayer pisze:
> On Wed, Sep 06, 2017 at 01:25:45AM +0200, Mateusz wrote:
>> W dniu 2017-09-05 o 23:37, Michael Niedermayer pisze:
>>> On Tue, Sep 05, 2017 at 04:42:06PM +0200, Mateusz wrote:
 W dniu 2017-09-05 o 15:40, Michael Niedermayer pisze:
> On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote:
>> If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro.
>> The problem is DITHER_COPY macro make images darker (on all planes).
>>
>> In x265 project there is issue #365 which is caused by this DITHER_COPY 
>> bug.
>> I think it is time to fix -- there are more and more high bit-depth 
>> sources.
>>
>> Please review.
>>
>>  libswscale/swscale_unscaled.c | 44 
>> +--
>>  1 file changed, 13 insertions(+), 31 deletions(-)
>
> please provide a git compatible patch with with commit message as produced
> by git format-patch or git send-email
>
> this mail is not accepted as is by git
> Applying: libswscale/swscale_unscaled: fix DITHER_COPY macro
> error: corrupt patch at line 6
> error: could not build fake ancestor
> Patch failed at 0001 libswscale/swscale_unscaled: fix DITHER_COPY macro
>
> [...]

 I've attached the result of git format-patch command.

 Sorry for 1 private e-mail (I clicked wrong button).

 Mateusz
>>>
  swscale_unscaled.c |   44 +---
  1 file changed, 13 insertions(+), 31 deletions(-)
 9973b13b3f74319abe9c97302ee87b2b3468b3b6  
 0001-fix-DITHER_COPY-macro-to-avoid-make-images-darker.patch
 From 9b96d612fef46ccec7e148cd7f8e8666b4e7a4cd Mon Sep 17 00:00:00 2001
 From: Mateusz 
 Date: Tue, 5 Sep 2017 16:09:28 +0200
 Subject: [PATCH] fix DITHER_COPY macro to avoid make images darker

 ---
  libswscale/swscale_unscaled.c | 44 
 +--
  1 file changed, 13 insertions(+), 31 deletions(-)

 diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
 index ef36aec..3b7a5a9 100644
 --- a/libswscale/swscale_unscaled.c
 +++ b/libswscale/swscale_unscaled.c
 @@ -110,24 +110,6 @@ DECLARE_ALIGNED(8, static const uint8_t, 
 dithers)[8][8][8]={
{ 112, 16,104,  8,118, 22,110, 14,},
  }};
  
 -static const uint16_t dither_scale[15][16]={
 -{2,3,3,5,5,5,5,5,5,5,5,5, 
5,5,5,5,},
 -{2,3,7,7,   13,   13,   25,   25,   25,   25,   25,   25, 
   25,   25,   25,   25,},
 -{3,3,4,   15,   15,   29,   57,   57,   57,  113,  113,  113, 
  113,  113,  113,  113,},
 -{3,4,4,5,   31,   31,   61,  121,  241,  241,  241,  241, 
  481,  481,  481,  481,},
 -{3,4,5,5,6,   63,   63,  125,  249,  497,  993,  993, 
  993,  993,  993, 1985,},
 -{3,5,6,6,6,7,  127,  127,  253,  505, 1009, 2017, 
 4033, 4033, 4033, 4033,},
 -{3,5,6,7,7,7,8,  255,  255,  509, 1017, 2033, 
 4065, 8129,16257,16257,},
 -{3,5,6,8,8,8,8,9,  511,  511, 1021, 2041, 
 4081, 8161,16321,32641,},
 -{3,5,7,8,9,9,9,9,   10, 1023, 1023, 2045, 
 4089, 8177,16353,32705,},
 -{3,5,7,8,   10,   10,   10,   10,   10,   11, 2047, 2047, 
 4093, 8185,16369,32737,},
 -{3,5,7,8,   10,   11,   11,   11,   11,   11,   12, 4095, 
 4095, 8189,16377,32753,},
 -{3,5,7,9,   10,   12,   12,   12,   12,   12,   12,   13, 
 8191, 8191,16381,32761,},
 -{3,5,7,9,   10,   12,   13,   13,   13,   13,   13,   13, 
   14,16383,16383,32765,},
 -{3,5,7,9,   10,   12,   14,   14,   14,   14,   14,   14, 
   14,   15,32767,32767,},
 -{3,5,7,9,   11,   12,   14,   15,   15,   15,   15,   15, 
   15,   15,   16,65535,},
 -};
 -
  
  static void fillPlane(uint8_t *plane, int stride, int width, int height, 
 int y,
uint8_t val)
 @@ -1502,22 +1484,22 @@ static int packedCopyWrapper(SwsContext *c, const 
 uint8_t *src[],
  }
  
  #define DITHER_COPY(dst, dstStride, src, srcStride, bswap, dbswap)\
 -uint16_t scale= dither_scale[dst_depth-1][src_depth-1];\
 -int shift= src_depth-dst_depth + 
 dither_scale[src_depth-2][dst_depth-1];\
 +unsigned shift= src_depth-dst_depth, tmp;\
  for (i = 0; i < height; i++) {\
 -const uint8_t *dither= dithers[src_depth-9][i&7];\
 +const uint8_t *dither= dithers[shift-1][i&7];\
  for (j = 0; j < length-7; j+=8){\
 -dst[j+0] = dbswap((bswap(src[j+0]) + 
>>

Re: [FFmpeg-devel] [PATCH] lavd: implement threaded NewTek NDI output

[Marton Balint]

On Tue, 5 Sep 2017, Marton Balint wrote:



On Tue, 5 Sep 2017, Maksym Veremeyenko wrote:


04.09.2017 17:10, Maksym Veremeyenko пише:

Hi,

attached patch implemented threaded NDI output - separate output thread 
for 

each stream. it makes audio preview in my case more smooth.


updated patch allows running audio/video threads separately


If I get this correctly, this patch is needed because you can only 
schedule 1 frame to the NDI API, therefore especially for shorter audio 
frames the buffer may underrun, right?. If that is the case, then I'd 
describe this in a bit more detail in the docs and/or the commit message.


I've given this some more thought, and this only makes sense if NDI is 
throttling the output (e.g via clock_audio or clock_video). If not, then 
using threads should not make any difference, so something different might 
be going on. Do you have an idea what?


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

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Jeyapal, Karthick]

>On 9/6/17, 12:37 PM, "Steven Liu" 
>mailto:lingjiujia...@gmail.com>> wrote:
>segment1.ts   duration = 4.88
>ROUND is 5, not 4,  is it?
>if its duration = 4.04
>ROUND is 4,   the real segment1.ts duration is 4.04,
>
>the safe one is TARGETDURATION = 5, the get_int_from_ double API can
>make the truely,

Yes, when duration of segment1.ts is 4.04, EXTINF duration is 4 when 
HLS_ROUND_DURATIONS is set. After this patch EXT-X-TARGETDURATION will also be 
4(instead of 5), which will be equal to the EXTINF duration and hence there is 
no violation of spec. And when another segment has duration of 4.88 both 
the EXTINF and duration and EXT-X-TARGETDURATION will be 5, still in line with 
the HLS specification. What is reason to be safe when we know deterministically 
that EXTINF duration will always be lesser than or equal to 
EXT-X-TARGETDURATION?

>yes, your patch can make 4.88 to 5, and make 4.04 to 4, all
>solution's TARGETDURATION is INT, but just make safe, i know the lrint
>API, so that is why have not use it, not i don't know lrint.

lrint was already being used for EXTINF duration when HLS_ROUND_DURATIONS is 
set. And this patch kicks in only when HLS_ROUND_DURATIONS is set. It still 
uses the get_int_from_double API otherwise. This patch still doesn’t affect the 
default path when EXTINF is not rounded.

Thanks and Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found

[Hendrik Leppkes]

On Wed, Sep 6, 2017 at 2:27 AM, James Almer  wrote:
> On 9/5/2017 8:47 PM, Hendrik Leppkes wrote:
>> On Wed, Sep 6, 2017 at 12:32 AM, James Almer  wrote:
>>> On 9/5/2017 7:12 PM, Hendrik Leppkes wrote:
 On Tue, Sep 5, 2017 at 11:20 PM, James Almer  wrote:
> On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
>> On Mon, Sep 4, 2017 at 4:47 AM, James Almer  wrote:
>>> Skip the invalid data in an attempt to find one instead, and continue 
>>> decoding from there.
>>>
>>> Fixes ticket #6634
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavformat/aacdec.c | 41 +
>>>  1 file changed, 29 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
>>> index 364b33404f..7aacc88560 100644
>>> --- a/libavformat/aacdec.c
>>> +++ b/libavformat/aacdec.c
>>> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
>>>  return 0;
>>>  }
>>>
>>> +static int resync(AVFormatContext *s)
>>> +{
>>> +uint16_t state;
>>> +
>>> +state = avio_r8(s->pb);
>>> +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
>>> +state = (state << 8) | avio_r8(s->pb);
>>> +if ((state >> 4) != 0xFFF)
>>> +continue;
>>> +avio_seek(s->pb, -2, SEEK_CUR);
>>> +break;
>>> +}
>>> +
>>
>> The ADTS sync code isn't that much of a sync code, maybe it might be
>> more resilient if you try to read the frame size and check if after
>> that the next frame also starts with a valid code?
>
> That will only let me know if at the end of the frame is another frame,
> and not if the frame I'm reading is complete or not.
> Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
> complete and right after it there's garbage. Maybe it's incomplete
> because another ADTS frame started suddenly in the middle of the one i
> tried to read because the source is some weird stream (sample in the
> ticket this fixes), and after reading the reported size of the intended
> frame the demuxer will find itself in the middle of the new one but
> unable to know that's the case.
>
> Really, at the demuxer level i can't do much more than read an ADTS
> header, make sure it's at least seven bytes long and that the reported
> size of the entire frame is bigger than the header size, then make a
> packet out of that. The decoder/parser will handle things from there,
> knowing that at very least for the first few bytes what reaches them is
> an ADTS frame.
>

 We're not talking about validating the ADTS frame, but just making
 sure you really "resync" to the start of a frame, and not some
 arbitrary random position that just happens to be 0xFFF, because that
 code isn't very long or very special.
>>>
>>> Again, what if there's no new ADTS frame after the supposed end of the
>>> one we're reading? How do we interpret that? That the one we read was
>>> wrong or that it was right and there simply is no new ADTS frame right
>>> after it? How does that help us decide if we propagate it or not?
>>>
>>> If anything, i could maybe use avpriv_aac_parse_header(). Barely more
>>> resilient than just looking for a sync code and the size field being >
>>> 7, but it's something i guess.
>>
>> If there is no two consecutive ADTS frames to be found, just stop sending 
>> data.
>
> We're doing exactly that right now. The point of this patch is to not do
> it any longer.
>
>> I don't see the problem.
>
> This patch loses its meaning. I have the feeling you're not getting what
> I'm trying to do here.
> The sample this fixes has several ADTS frames cut at the middle where
> another was injected (Seems to be a raw stream dump). At the reported
> end of the cut frame there isn't a new sync header, there's data from
> the middle of the new unexpected frame. By stopping there, we're barely
> decoding 2 seconds of audio, when there's about 19 that can get decoded
> if we instead move forward trying to find the start of a new frame.
>
> Before the commit that put us in our current situation the demuxer would
> just send everything and let the parser combine data into hopefully
> valid frames. This resulted in things that weren't audio frames being
> propagated, like id3v1 or APE tags, or just garbage.

I don't see how checking for two consecutive frames would really stop
this from decoding further audio?
We lost sync, we try to find the next ADTS sync code, then we validate
it by reading the frame size and checking if after this frame another
one starts - ie. if we're really "synced" to frame starts again.

This still allows you to skip garbage in the middle  and resume
decoding afterwards.

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

Re: [FFmpeg-devel] [PATCHv2 1/2] avcodec: add execute3() api to utilize the main function of avpriv_slicethread_create().

[wm4]

On Wed,  6 Sep 2017 06:57:25 +0700
Ilia Valiakhmetov  wrote:

> Signed-off-by: Ilia Valiakhmetov 
> ---
>  libavcodec/avcodec.h   |  7 ++-
>  libavcodec/options.c   |  1 +
>  libavcodec/pthread_slice.c | 26 --
>  libavcodec/utils.c | 14 ++
>  4 files changed, 45 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 650..712f40c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1089,6 +1089,10 @@ typedef struct RcOverride{
>   */
>  #define AV_CODEC_CAP_AVOID_PROBING   (1 << 17)
>  /**
> + * Codec initializes slice-based threading with a main function
> + */
> +#define AV_CODEC_SLICE_THREAD_HAS_MF (1 << 18)
> +/**
>   * Codec is intra only.
>   */
>  #define AV_CODEC_CAP_INTRA_ONLY   0x4000
> @@ -3233,7 +3237,7 @@ typedef struct AVCodecContext {
>   * - decoding: Set by libavcodec, user can override.
>   */
>  int (*execute2)(struct AVCodecContext *c, int (*func)(struct 
> AVCodecContext *c2, void *arg, int jobnr, int threadnr), void *arg2, int 
> *ret, int count);
> -
> +int (*execute3)(struct AVCodecContext *c, int (*func)(struct 
> AVCodecContext *c2, void *arg, int jobnr, int threadnr), int (*m_func)(struct 
> AVCodecContext *c3), void *arg2, int *ret, int count);
>  /**
>   * noise vs. sse weight for the nsse comparison function
>   * - encoding: Set by user.
> @@ -5774,6 +5778,7 @@ const char *avcodec_profile_name(enum AVCodecID 
> codec_id, int profile);
>  
>  int avcodec_default_execute(AVCodecContext *c, int (*func)(AVCodecContext 
> *c2, void *arg2),void *arg, int *ret, int count, int size);
>  int avcodec_default_execute2(AVCodecContext *c, int (*func)(AVCodecContext 
> *c2, void *arg2, int, int),void *arg, int *ret, int count);
> +int avcodec_default_execute3(AVCodecContext *c, int (*func)(AVCodecContext 
> *c2, void *arg2, int jobnr, int threadnr), int (*m_func)(struct 
> AVCodecContext *c3), void *arg, int *ret, int count);
>  //FIXME func typedef
>  
>  /**
> diff --git a/libavcodec/options.c b/libavcodec/options.c
> index 82e1217..6d63bdb 100644
> --- a/libavcodec/options.c
> +++ b/libavcodec/options.c
> @@ -117,6 +117,7 @@ static int init_context_defaults(AVCodecContext *s, const 
> AVCodec *codec)
>  s->get_format  = avcodec_default_get_format;
>  s->execute = avcodec_default_execute;
>  s->execute2= avcodec_default_execute2;
> +s->execute3= avcodec_default_execute3;
>  s->sample_aspect_ratio = (AVRational){0,1};
>  s->pix_fmt = AV_PIX_FMT_NONE;
>  s->sw_pix_fmt  = AV_PIX_FMT_NONE;
> diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
> index c781d35..3aff816 100644
> --- a/libavcodec/pthread_slice.c
> +++ b/libavcodec/pthread_slice.c
> @@ -38,11 +38,13 @@
>  
>  typedef int (action_func)(AVCodecContext *c, void *arg);
>  typedef int (action_func2)(AVCodecContext *c, void *arg, int jobnr, int 
> threadnr);
> +typedef int (main_func)(AVCodecContext *c);
>  
>  typedef struct SliceThreadContext {
>  AVSliceThread *thread;
>  action_func *func;
>  action_func2 *func2;
> +main_func *m_func;
>  void *args;
>  int *rets;
>  int job_size;
> @@ -54,6 +56,12 @@ typedef struct SliceThreadContext {
>  pthread_mutex_t *progress_mutex;
>  } SliceThreadContext;
>  
> +static void main_function(void *priv) {
> +AVCodecContext *avctx = priv;
> +SliceThreadContext *c = avctx->internal->thread_ctx;
> +c->m_func(avctx);
> +}
> +
>  static void worker_func(void *priv, int jobnr, int threadnr, int nb_jobs, 
> int nb_threads)
>  {
>  AVCodecContext *avctx = priv;
> @@ -99,7 +107,8 @@ static int thread_execute(AVCodecContext *avctx, 
> action_func* func, void *arg, i
>  c->func = func;
>  c->rets = ret;
>  
> -avpriv_slicethread_execute(c->thread, job_count, 0);
> +avpriv_slicethread_execute(c->thread, job_count, !!c->m_func);
> +
>  return 0;
>  }
>  
> @@ -110,10 +119,20 @@ static int thread_execute2(AVCodecContext *avctx, 
> action_func2* func2, void *arg
>  return thread_execute(avctx, NULL, arg, ret, job_count, 0);
>  }
>  
> +static int thread_execute3(AVCodecContext *avctx, action_func2* func2, 
> main_func* m_func, void *arg, int *ret, int job_count)
> +{
> +SliceThreadContext *c = avctx->internal->thread_ctx;
> +c->func2 = func2;
> +c->m_func = m_func;
> +return thread_execute(avctx, NULL, arg, ret, job_count, 0);
> +}
> +
> +
>  int ff_slice_thread_init(AVCodecContext *avctx)
>  {
>  SliceThreadContext *c;
>  int thread_count = avctx->thread_count;
> +static void (*m_f)(void *);
>  
>  #if HAVE_W32THREADS
>  w32thread_init();
> @@ -142,7 +161,9 @@ int ff_slice_thread_init(AVCodecContext *avctx)
>  }
>  
>  avctx->internal->thread_ctx = c = av_mallocz(sizeof(*c));
> -if (!c || (thread_count = avpriv_slicethread_cr

Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.

[wm4]

On Tue, 5 Sep 2017 22:14:39 -0300
James Almer  wrote:

> On 9/5/2017 5:38 AM, wm4 wrote:
> > On Tue, 5 Sep 2017 10:03:11 +0200
> > Clément Bœsch  wrote:
> >   
> >> On Mon, Sep 04, 2017 at 08:35:17PM +0200, wm4 wrote:
> >> [...]  
> >> Can't we just remove this codec? It has no use other than causing
> >> potential security issues and maintenance.  
> >
> > I agree about removing the encoder, but the decoder is needed for
> > existing streams. Unless everyone just argues it has no real world
> > samples for being an avcodec-only toy codec.
> >
> > If you send a patch removing the encoder without also trying to remove
> > all the things that currently depend on it (One or two filters i think)
> > then I'll +1 it. ffv1 and mpeg4 encoders are enough for any kind of
> > testing, fate or otherwise, that might require a native encoder.  
> 
>  I find it a bit offensive that people suggest to remove the encoder i
>  maintain.
> >>>
> >>> Can I add my own unused fringe codec with no users, as long as I
> >>> maintain it?
> >>
> >> Is there any reason to be so obsessed with snow? There are plenty of other
> >> "fringe" codecs in the codebase that only one person in the world cared
> >> about 10 years ago. Snow is one of the rare wavelet codecs, and as a
> >> result is much more valuable than many random basic game flavored codecs.
> >> And somehow, no one ever mention those.  
> > 
> > Those game codecs have actually some use. There are files in the wild
> > that are available to many, and that aren't just demo/test files. But
> > it's true that all these game codecs bloat the codebase, cause
> > maintenance and security issues, and have little use. They barely have
> > a justification to exist too.  
> 
> Don't be one of those that go "h264/aac/mov is all ffmpeg should care
> about".

I didn't argue that at all. I'm arguing that FFmpeg probably shouldn't
support a codec that was used by 1 or 2 released games, and for which
we can't guarantee security. Obscure features are a pretty big and
popular attack surface.

That's very different from arguing that we should drop all codecs but 3.

> > 
> > The only argument for snow is that it's a nice ideas. It might serve as
> > some proof of concept. As a real codec, it appears to be unusable.
> >   
> >> I don't personally care about game codecs or snow myself (probably nobody
> >> does), but I don't support this snow/swscale/whatever-michael-did killing
> >> circle jerk. This really feels like some form of constant harassment (I'm
> >> not even talking about IRC), and that's not acceptable.  
> > 
> > Well, michael could just cut back on trying to force insane stuff. His
> > obstinate attitude to force ridiculous patches and defending them like
> > they're the only choice doesn't help. Even when we try to remove some
> > of his sins, he'll defend it to death, no matter how crazy and stupid
> > the code was (side data merging comes to mind).  
> 
> Seeing that stuff is effectively deprecated, i don't think he defended
> it to death. Everyone argued it was a pointless feature, and he
> ultimately conceded.

He only "conceded" after I put all of my energy into it, and even then
he was letting us know that he thought side data merging was great. And
of course this whole thing was not without claiming that side data
merging was part of the ABI, which is pure BS (but he probably did that
so that I had even more work with creating separate version guards).

Shit like this happens every fucking time. I'm tired of it, so excuse
me if I sometimes get "rude".

> > 
> > If you feel like what I'm doing is harassment, I can end my involvement
> > with michael to avoid this - but only if you stop him from doing bad
> > things.  
> 
> You're very critical of all his patches. In many cases you give a
> detailed technical explanation of why you disagree, but most times you
> just make a snarky comment or are otherwise kinda rude.
> Even when you were proven wrong (the runtime cpu flag stuff) you answer

I wasn't proven wrong in this case. You can change the CPU flags at
runtime, but, as I pointed out, it obviously doesn't work if there's
anything still "running". It shows that

 1. runtime modification doesn't really work, i.e. it's an obscure case
that didn't work before, and all the heckmeck Michael is creating
is probably only passive aggressive BS to "prove" his point
 2. the various API to change CPU flags are a bad idea, and we should
go into the opposite direction

It blows my mind that some developer argues FFmpeg should adapt to
runtime CPU changes. This is obviously batshit, because it's highly
complex, the rest of _all_ the code doesn't handle it, and the API is
global mutable state anyway.

Getting back to this bit:

> You're very critical of all his patches. In many cases you give a
> detailed technical explanation of why you disagree, but most times you
> just make a snarky comment or are oth

[FFmpeg-devel] [PATCH 3/7] build: add check_apple_framework()

[Clément Bœsch]

From: Clément Bœsch 

This will be used in the following commits.
---
 configure | 9 +
 1 file changed, 9 insertions(+)

diff --git a/configure b/configure
index 442ef606e0..158f9ba24b 100755
--- a/configure
+++ b/configure
@@ -1120,6 +1120,15 @@ check_header_objcc(){
 } | check_objcc && check_stat "$TMPO" && enable_safe $header
 }
 
+check_apple_framework(){
+log check_apple_framework "$@"
+framework="$1"
+name="$(tolower $framework)"
+header="${framework}/${framework}.h"
+disable $name
+check_header_objcc $header && enable $name && add_extralibs "-framework 
$framework"
+}
+
 check_func(){
 log check_func "$@"
 func=$1
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/7] lavfi/coreimage: reduce dependency scope from QuartzCore to CoreImage

[Clément Bœsch]

From: Clément Bœsch 

What is required by the filter is CoreImage, there is no QuartzCore
usage. QuartzCore/CoreImage.h is simply an include to
CoreImage/CoreImage.h.
---
 configure  | 8 
 libavfilter/vf_coreimage.m | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 54fe846fea..442ef606e0 100755
--- a/configure
+++ b/configure
@@ -5588,8 +5588,8 @@ frei0r_filter_extralibs='$ldl'
 frei0r_src_filter_extralibs='$ldl'
 ladspa_filter_extralibs='$ldl'
 nvenc_extralibs='$ldl'
-coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework 
OpenGL"
-coreimagesrc_filter_extralibs="-framework QuartzCore -framework AppKit 
-framework OpenGL"
+coreimage_filter_extralibs="-framework CoreImage -framework AppKit -framework 
OpenGL"
+coreimagesrc_filter_extralibs="-framework CoreImage -framework AppKit 
-framework OpenGL"
 
 if ! disabled network; then
 check_func getaddrinfo $network_extralibs
@@ -5837,8 +5837,8 @@ enabled cuda_sdk  && require cuda_sdk cuda.h 
cuCtxCreate -lcuda
 enabled cuvid && { enabled cuda ||
die "ERROR: CUVID requires CUDA"; }
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
-enabled coreimage_filter  && { check_header_objcc QuartzCore/CoreImage.h || 
disable coreimage_filter; }
-enabled coreimagesrc_filter && { check_header_objcc QuartzCore/CoreImage.h || 
disable coreimagesrc_filter; }
+enabled coreimage_filter  && { check_header_objcc CoreImage/CoreImage.h || 
disable coreimage_filter; }
+enabled coreimagesrc_filter && { check_header_objcc CoreImage/CoreImage.h || 
disable coreimagesrc_filter; }
 enabled decklink  && { { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; } &&
{ check_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API 
version must be >= 10.6.1."; } }
 enabled libndi_newtek && { check_header Processing.NDI.Lib.h || die 
"ERROR: Processing.NDI.Lib.h header not found"; }
diff --git a/libavfilter/vf_coreimage.m b/libavfilter/vf_coreimage.m
index 9c8db02858..323a28caa1 100644
--- a/libavfilter/vf_coreimage.m
+++ b/libavfilter/vf_coreimage.m
@@ -23,7 +23,7 @@
  * Video processing based on Apple's CoreImage API
  */
 
-#import 
+#import 
 #import 
 
 #include "avfilter.h"
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 6/7] build: cleanup audiotoolbox handling

[Clément Bœsch]

From: Clément Bœsch 

*_at codecs only need the AudioToolbox framework, which is now checked
like the other Apple frameworks.
---
 configure | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/configure b/configure
index 1e36cde447..a91bc9f58a 100755
--- a/configure
+++ b/configure
@@ -2610,10 +2610,6 @@ zlib_encoder_select="zlib"
 zmbv_decoder_select="zlib"
 zmbv_encoder_select="zlib"
 
-# platform codecs
-audiotoolbox_deps="AudioToolbox_AudioToolbox_h"
-audiotoolbox_extralibs="-framework CoreFoundation -framework AudioToolbox 
-framework CoreMedia"
-
 # hardware accelerators
 crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
 cuda_deps_any="dlopen LoadLibrary"
@@ -5718,7 +5714,6 @@ check_func_headers glob.h glob
 enabled xlib &&
 check_func_headers "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute 
-lXv -lX11 -lXext
 
-check_header AudioToolbox/AudioToolbox.h
 check_header d3d11.h
 check_header direct.h
 check_header dirent.h
@@ -5761,6 +5756,7 @@ check_lib psapi"windows.h psapi.h"
GetProcessMemoryInfo -lpsapi
 
 check_lib coreservices "CoreServices/CoreServices.h" UTGetOSTypeFromString 
"-framework CoreServices"
 
+enabled audiotoolbox && check_apple_framework AudioToolbox
 enabled avfoundation && check_apple_framework AVFoundation
 enabled coreimage&& check_apple_framework CoreImage
 
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 4/7] build: add --disable-avfoundation autodetect switch

[Clément Bœsch]

From: Clément Bœsch 

---
 configure | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 158f9ba24b..a4c2d81dee 100755
--- a/configure
+++ b/configure
@@ -202,6 +202,7 @@ External library support:
   themselves, not all their features will necessarily be usable by FFmpeg.
 
   --disable-alsa   disable ALSA support [autodetect]
+  --disable-avfoundation   disable Apple AVFoundation framework [autodetect]
   --enable-avisynthenable reading of AviSynth script files [no]
   --disable-bzlib  disable bzlib [autodetect]
   --enable-chromaprint enable audio fingerprinting with chromaprint [no]
@@ -1498,6 +1499,7 @@ EXAMPLE_LIST="
 
 EXTERNAL_AUTODETECT_LIBRARY_LIST="
 alsa
+avfoundation
 bzlib
 iconv
 jack
@@ -3023,8 +3025,8 @@ xwma_demuxer_select="riffdec"
 # indevs / outdevs
 alsa_indev_deps="alsa"
 alsa_outdev_deps="alsa"
-avfoundation_indev_deps="pthreads"
-avfoundation_indev_extralibs="-framework Foundation -framework AVFoundation 
-framework CoreVideo -framework CoreMedia"
+avfoundation_indev_deps="avfoundation pthreads"
+avfoundation_indev_extralibs="-framework Foundation -framework CoreVideo 
-framework CoreMedia"
 bktr_indev_deps_any="dev_bktr_ioctl_bt848_h machine_ioctl_bt848_h 
dev_video_bktr_ioctl_bt848_h dev_ic_bt8xx_h"
 caca_outdev_deps="libcaca"
 decklink_indev_deps="decklink threads"
@@ -5755,6 +5757,13 @@ check_lib psapi"windows.h psapi.h"
GetProcessMemoryInfo -lpsapi
 
 check_lib coreservices "CoreServices/CoreServices.h" UTGetOSTypeFromString 
"-framework CoreServices"
 
+enabled avfoundation && check_apple_framework AVFoundation
+
+enabled avfoundation && {
+check_lib avfoundation CoreGraphics/CoreGraphics.h   
CGGetActiveDisplayList "-framework CoreGraphics" ||
+check_lib avfoundation ApplicationServices/ApplicationServices.h 
CGGetActiveDisplayList "-framework ApplicationServices"; }
+
+
 check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
 
 check_type "windows.h dxva.h" "DXVA_PicParams_HEVC" 
-DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D_CRT_BUILD_DESKTOP_APP=0
@@ -5839,9 +5848,6 @@ for func in $COMPLEX_FUNCS; do
 done
 
 # these are off by default, so fail if requested and not available
-enabled avfoundation_indev && { check_header_objcc AVFoundation/AVFoundation.h 
|| disable avfoundation_indev; }
-enabled avfoundation_indev && { check_lib avfoundation_indev 
CoreGraphics/CoreGraphics.h CGGetActiveDisplayList -framework CoreGraphics ||
-check_lib avfoundation_indev 
ApplicationServices/ApplicationServices.h CGGetActiveDisplayList -framework 
ApplicationServices; }
 enabled cuda_sdk  && require cuda_sdk cuda.h cuCtxCreate -lcuda
 enabled cuvid && { enabled cuda ||
die "ERROR: CUVID requires CUDA"; }
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/7] build: fix objcc header check

[Clément Bœsch]

From: Clément Bœsch 

$headers is a variable set in the context of other functions (we don't
use the "local" keyword in our scripts, so those variables are global).

Currently, when checking for AVFoundation/AVFoundation.h, the actual
enabled header is math.h.

Similarly, when testing for QuartzCore/CoreImage.h, the actual enabled
header is CoreGraphics/CoreGraphics.h.

This is completely broken and may be the reason why these checks are
made in random places.
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 2f3fa2ba3d..54fe846fea 100755
--- a/configure
+++ b/configure
@@ -1117,7 +1117,7 @@ check_header_objcc(){
 {
echo "#include <$header>"
echo "int main(void) { return 0; }"
-} | check_objcc && check_stat "$TMPO" && enable_safe $headers
+} | check_objcc && check_stat "$TMPO" && enable_safe $header
 }
 
 check_func(){
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 7/7] build: cleanup videotoolbox

[Clément Bœsch]

From: Clément Bœsch 

- there is no need for kCVImageBufferColorPrimaries_ITU_R_2020 checks,
  it's done at runtime
- VideoToolbox presence is now checked with check_apple_framework()
- link to CoreServices is only done when videotoolbox is enabled
---
 configure | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configure b/configure
index a91bc9f58a..b52aad49f4 100755
--- a/configure
+++ b/configure
@@ -1607,7 +1607,6 @@ EXTERNAL_LIBRARY_LIST="
 openal
 opencl
 opengl
-videotoolbox
 "
 
 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -1621,7 +1620,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
 vaapi
 vda
 vdpau
-videotoolbox_hwaccel
+videotoolbox
 xvmc
 "
 
@@ -2178,7 +2177,6 @@ CONFIG_EXTRA="
 vp3dsp
 vp56dsp
 vp8dsp
-vt_bt2020
 wma_freqs
 wmv2dsp
 "
@@ -2936,11 +2934,9 @@ libx265_encoder_deps="libx265"
 libxavs_encoder_deps="libxavs"
 libxvid_encoder_deps="libxvid"
 libzvbi_teletext_decoder_deps="libzvbi"
-videotoolbox_deps="VideoToolbox_VideoToolbox_h"
 videotoolbox_extralibs="-framework CoreFoundation -framework VideoToolbox 
-framework CoreMedia -framework CoreVideo"
 videotoolbox_encoder_deps="videotoolbox 
VTCompressionSessionPrepareToEncodeFrames"
-videotoolbox_encoder_suggest="vda_framework vt_bt2020"
-vt_bt2020_deps="kCVImageBufferColorPrimaries_ITU_R_2020"
+videotoolbox_encoder_suggest="vda_framework"
 
 # demuxers / muxers
 ac3_demuxer_select="ac3_parser"
@@ -5737,9 +5733,7 @@ check_header termios.h
 check_header unistd.h
 check_header valgrind/valgrind.h
 check_header VideoDecodeAcceleration/VDADecoder.h
-check_header VideoToolbox/VideoToolbox.h
 check_func_headers VideoToolbox/VTCompressionSession.h 
VTCompressionSessionPrepareToEncodeFrames -framework VideoToolbox
-enabled videotoolbox && check_func_headers CoreVideo/CVImageBuffer.h 
kCVImageBufferColorPrimaries_ITU_R_2020 -framework CoreVideo
 check_header windows.h
 check_header X11/extensions/XvMClib.h
 check_header asm/types.h
@@ -5754,16 +5748,17 @@ check_lib shell32  "windows.h shellapi.h" 
CommandLineToArgvW   -lshell32
 check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
 
-check_lib coreservices "CoreServices/CoreServices.h" UTGetOSTypeFromString 
"-framework CoreServices"
-
 enabled audiotoolbox && check_apple_framework AudioToolbox
 enabled avfoundation && check_apple_framework AVFoundation
 enabled coreimage&& check_apple_framework CoreImage
+enabled videotoolbox && check_apple_framework VideoToolbox
 
 enabled avfoundation && {
 check_lib avfoundation CoreGraphics/CoreGraphics.h   
CGGetActiveDisplayList "-framework CoreGraphics" ||
 check_lib avfoundation ApplicationServices/ApplicationServices.h 
CGGetActiveDisplayList "-framework ApplicationServices"; }
 
+enabled videotoolbox &&
+check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
"-framework CoreServices"
 
 check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
 
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 5/7] build: add --disable-coreimage autodetect switch

[Clément Bœsch]

From: Clément Bœsch 

---
 configure | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index a4c2d81dee..1e36cde447 100755
--- a/configure
+++ b/configure
@@ -205,6 +205,7 @@ External library support:
   --disable-avfoundation   disable Apple AVFoundation framework [autodetect]
   --enable-avisynthenable reading of AviSynth script files [no]
   --disable-bzlib  disable bzlib [autodetect]
+  --disable-coreimage  disable Apple CoreImage framework [autodetect]
   --enable-chromaprint enable audio fingerprinting with chromaprint [no]
   --enable-frei0r  enable frei0r video filtering [no]
   --enable-gcrypt  enable gcrypt, needed for rtmp(t)e support
@@ -1501,6 +1502,7 @@ EXTERNAL_AUTODETECT_LIBRARY_LIST="
 alsa
 avfoundation
 bzlib
+coreimage
 iconv
 jack
 libxcb
@@ -3134,6 +3136,10 @@ blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
 bs2b_filter_deps="libbs2b"
 colormatrix_filter_deps="gpl"
+coreimage_filter_deps="coreimage"
+coreimage_filter_extralibs="-framework OpenGL -framework AppKit"
+coreimagesrc_filter_deps="coreimage"
+coreimagesrc_filter_extralibs="-framework OpenGL -framework AppKit"
 cover_rect_filter_deps="avcodec avformat gpl"
 cropdetect_filter_deps="gpl"
 deinterlace_qsv_filter_deps="libmfx"
@@ -5599,8 +5605,6 @@ frei0r_filter_extralibs='$ldl'
 frei0r_src_filter_extralibs='$ldl'
 ladspa_filter_extralibs='$ldl'
 nvenc_extralibs='$ldl'
-coreimage_filter_extralibs="-framework CoreImage -framework AppKit -framework 
OpenGL"
-coreimagesrc_filter_extralibs="-framework CoreImage -framework AppKit 
-framework OpenGL"
 
 if ! disabled network; then
 check_func getaddrinfo $network_extralibs
@@ -5758,6 +5762,7 @@ check_lib psapi"windows.h psapi.h"
GetProcessMemoryInfo -lpsapi
 check_lib coreservices "CoreServices/CoreServices.h" UTGetOSTypeFromString 
"-framework CoreServices"
 
 enabled avfoundation && check_apple_framework AVFoundation
+enabled coreimage&& check_apple_framework CoreImage
 
 enabled avfoundation && {
 check_lib avfoundation CoreGraphics/CoreGraphics.h   
CGGetActiveDisplayList "-framework CoreGraphics" ||
@@ -5852,8 +5857,6 @@ enabled cuda_sdk  && require cuda_sdk cuda.h 
cuCtxCreate -lcuda
 enabled cuvid && { enabled cuda ||
die "ERROR: CUVID requires CUDA"; }
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
-enabled coreimage_filter  && { check_header_objcc CoreImage/CoreImage.h || 
disable coreimage_filter; }
-enabled coreimagesrc_filter && { check_header_objcc CoreImage/CoreImage.h || 
disable coreimagesrc_filter; }
 enabled decklink  && { { check_header DeckLinkAPI.h || die "ERROR: 
DeckLinkAPI.h header not found"; } &&
{ check_cpp_condition DeckLinkAPIVersion.h 
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API 
version must be >= 10.6.1."; } }
 enabled libndi_newtek && { check_header Processing.NDI.Lib.h || die 
"ERROR: Processing.NDI.Lib.h header not found"; }
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Steven Liu]

2017-09-06 16:46 GMT+08:00 Jeyapal, Karthick :
>>On 9/6/17, 12:37 PM, "Steven Liu" 
>>mailto:lingjiujia...@gmail.com>> wrote:
>>segment1.ts   duration = 4.88
>>ROUND is 5, not 4,  is it?
>>if its duration = 4.04
>>ROUND is 4,   the real segment1.ts duration is 4.04,
>>
>>the safe one is TARGETDURATION = 5, the get_int_from_ double API can
>>make the truely,
>
> Yes, when duration of segment1.ts is 4.04, EXTINF duration is 4 when 
> HLS_ROUND_DURATIONS is set. After this patch EXT-X-TARGETDURATION will also 
> be 4(instead of 5), which will be equal to the EXTINF duration and hence 
> there is no violation of spec. And when another segment has duration of 
> 4.88 both the EXTINF and duration and EXT-X-TARGETDURATION will be 5, 
> still in line with the HLS specification. What is reason to be safe when we 
> know deterministically that EXTINF duration will always be lesser than or 
> equal to EXT-X-TARGETDURATION?
>
>>yes, your patch can make 4.88 to 5, and make 4.04 to 4, all
>>solution's TARGETDURATION is INT, but just make safe, i know the lrint
>>API, so that is why have not use it, not i don't know lrint.
>
> lrint was already being used for EXTINF duration when HLS_ROUND_DURATIONS is 
> set. And this patch kicks in only when HLS_ROUND_DURATIONS is set. It still 
> uses the get_int_from_double API otherwise. This patch still doesn’t affect 
> the default path when EXTINF is not rounded.

when 4.04, the after ROUND  EXTINF value is lesser than segment duration.
>
> Thanks and Regards,
> Karthick
> ___
> 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 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Jeyapal, Karthick]

>On 9/6/17, 3:43 PM, "Steven Liu" 
>mailto:lingjiujia...@gmail.com>> wrote:
>
>>2017-09-06 16:46 GMT+08:00 Jeyapal, Karthick 
>>mailto:kjeya...@akamai.com>>:
>>>On 9/6/17, 12:37 PM, "Steven Liu" >>gmail.com>> at gmail.com>> wrote:
>>>segment1.ts   duration = 4.88
>>>ROUND is 5, not 4,  is it?
>>>if its duration = 4.04
>>>ROUND is 4,   the real segment1.ts duration is 4.04,
>>>
>>>the safe one is TARGETDURATION = 5, the get_int_from_ double API can
>>>make the truely,
>>
>> Yes, when duration of segment1.ts is 4.04, EXTINF duration is 4 when 
>> HLS_ROUND_DURATIONS is set. After this patch EXT-X-TARGETDURATION will also 
>> be 4(instead of 5), which will be equal to the EXTINF duration and hence 
>> there is no violation of spec. And when another segment has duration of 
>> 4.88 both the EXTINF and duration and EXT-X-TARGETDURATION will be 5, 
>> still in line with the HLS specification. What is reason to be safe when we 
>> know deterministically that EXTINF duration will always be lesser than or 
>> equal to EXT-X-TARGETDURATION?
>>
>>>yes, your patch can make 4.88 to 5, and make 4.04 to 4, all
>>>solution's TARGETDURATION is INT, but just make safe, i know the lrint
>>>API, so that is why have not use it, not i don't know lrint.
>>
>> lrint was already being used for EXTINF duration when HLS_ROUND_DURATIONS is 
>> set. And this patch kicks in only when HLS_ROUND_DURATIONS is set. It still 
>> uses the get_int_from_double API otherwise. This patch still doesn’t affect 
>> the default path when EXTINF is not rounded.

>when 4.04, the after ROUND  EXTINF value is lesser than segment duration.

Thanks for the reply. Yes, that is true. But as per the HLS spec in 
https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#page-21 
specifies “The EXTINF duration of each Media Segment in the Playlist file, when 
rounded to the nearest integer, MUST be less than or equal to the target 
duration;” for target duration. Please note that phrase “when rounded to the 
nearest integer” in that line. HLS specification allows you to specify target 
duration as maximum of segment duration “after rounding to the nearest integer”.

Just to add a little more justification, we have been running Apple’s 
mediastreamvalidator in our daily regression tests with this patch, and it has 
never warned about the target duration. While I agree Apple’s 
mediastreamvalidator is not a conformance tool to check all kinds of HLS 
errors, but they definitely have quite a few checks in place that flags several 
duration related errors.

>>
>> Thanks and Regards,
>> Karthick
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel at 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 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Steven Liu]

2017-09-06 18:31 GMT+08:00 Jeyapal, Karthick :
>
>
>>On 9/6/17, 3:43 PM, "Steven Liu" 
>>mailto:lingjiujia...@gmail.com>> wrote:
>>
>>>2017-09-06 16:46 GMT+08:00 Jeyapal, Karthick 
>>>mailto:kjeya...@akamai.com>>:
On 9/6/17, 12:37 PM, "Steven Liu" >>>gmail.com>> wrote:
segment1.ts   duration = 4.88
ROUND is 5, not 4,  is it?
if its duration = 4.04
ROUND is 4,   the real segment1.ts duration is 4.04,

the safe one is TARGETDURATION = 5, the get_int_from_ double API can
make the truely,
>>>
>>> Yes, when duration of segment1.ts is 4.04, EXTINF duration is 4 when 
>>> HLS_ROUND_DURATIONS is set. After this patch EXT-X-TARGETDURATION will also 
>>> be 4(instead of 5), which will be equal to the EXTINF duration and hence 
>>> there is no violation of spec. And when another segment has duration of 
>>> 4.88 both the EXTINF and duration and EXT-X-TARGETDURATION will be 5, 
>>> still in line with the HLS specification. What is reason to be safe when we 
>>> know deterministically that EXTINF duration will always be lesser than or 
>>> equal to EXT-X-TARGETDURATION?
>>>
yes, your patch can make 4.88 to 5, and make 4.04 to 4, all
solution's TARGETDURATION is INT, but just make safe, i know the lrint
API, so that is why have not use it, not i don't know lrint.
>>>
>>> lrint was already being used for EXTINF duration when HLS_ROUND_DURATIONS 
>>> is set. And this patch kicks in only when HLS_ROUND_DURATIONS is set. It 
>>> still uses the get_int_from_double API otherwise. This patch still doesn’t 
>>> affect the default path when EXTINF is not rounded.
>
>>when 4.04, the after ROUND  EXTINF value is lesser than segment duration.
>
> Thanks for the reply. Yes, that is true. But as per the HLS spec in 
> https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#page-21 
> specifies “The EXTINF duration of each Media Segment in the Playlist file, 
> when rounded to the nearest integer, MUST be less than or equal to the target 
> duration;” for target duration. Please note that phrase “when rounded to the 
> nearest integer” in that line. HLS specification allows you to specify target 
> duration as maximum of segment duration “after rounding to the nearest 
> integer”.
>
> Just to add a little more justification, we have been running Apple’s 
> mediastreamvalidator in our daily regression tests with this patch, and it 
> has never warned about the target duration. While I agree Apple’s 
> mediastreamvalidator is not a conformance tool to check all kinds of HLS 
> errors, but they definitely have quite a few checks in place that flags 
> several duration related errors.

That is not perfect solution, because that just " that phrase 'when
rounded to the nearest integer' in that line", not write in the spec,
it not said the EXTINF value is "when rounded to the nearest integer",
and now it support have not problem, or can you reproduce problem when
not apply this modify?

>
>>>
>>> Thanks and Regards,
>>> Karthick
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avdevice/decklink: new options 'list_pixelformats' and 'pixelformat_code' to allow pixelformat selection by code

[Gildas Fargeas]

Alright, this should do the trick:
- use named const for raw_format option
- deprecate bm_v210
- bumped avdevice micro version

---
 libavdevice/decklink_common.cpp |  2 +-
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 43 ++---
 libavdevice/decklink_dec_c.c|  6 ++
 libavdevice/version.h   |  2 +-
 5 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index cbb591ce64..ff2df95909 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -241,7 +241,7 @@ int ff_decklink_set_format(AVFormatContext *avctx,
 if (ctx->bmd_mode == bmdModeUnknown)
 return -1;
 if (direction == DIRECTION_IN) {
-if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
+if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, (BMDPixelFormat) 
cctx->raw_format,
bmdVideoOutputFlagDefault,
&support, NULL) != S_OK)
 return -1;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index e263480474..5616ab32f9 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -49,6 +49,7 @@ struct decklink_cctx {
 int video_input;
 int draw_bars;
 char *format_code;
+int raw_format;
 int64_t queue_size;
 };
 
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index c271ff3639..ccbb6f09f5 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -651,6 +651,11 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 return AVERROR_EXIT;
 }
 
+if (cctx->v210) {
+av_log(avctx, AV_LOG_WARNING, "The bm_v210 option is deprecated and 
will be removed. Please use the -raw_format yuv422p10.\n");
+cctx->raw_format = MKBETAG('v','2','1','0');
+}
+
 strcpy (fname, avctx->filename);
 tmp=strchr (fname, '@');
 if (tmp != NULL) {
@@ -723,15 +728,39 @@ av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)
 st->time_base.num  = ctx->bmd_tb_num;
 av_stream_set_r_frame_rate(st, av_make_q(st->time_base.den, 
st->time_base.num));
 
-if (cctx->v210) {
-st->codecpar->codec_id= AV_CODEC_ID_V210;
-st->codecpar->codec_tag   = MKTAG('V', '2', '1', '0');
-st->codecpar->bit_rate= av_rescale(ctx->bmd_width * 
ctx->bmd_height * 64, st->time_base.den, st->time_base.num * 3);
-} else {
+switch((BMDPixelFormat)cctx->raw_format) {
+case bmdFormat8BitYUV:
 st->codecpar->codec_id= AV_CODEC_ID_RAWVIDEO;
-st->codecpar->format  = AV_PIX_FMT_UYVY422;
 st->codecpar->codec_tag   = MKTAG('U', 'Y', 'V', 'Y');
+st->codecpar->format  = AV_PIX_FMT_UYVY422;
 st->codecpar->bit_rate= av_rescale(ctx->bmd_width * 
ctx->bmd_height * 16, st->time_base.den, st->time_base.num);
+break;
+case bmdFormat10BitYUV:
+st->codecpar->codec_id= AV_CODEC_ID_V210;
+st->codecpar->codec_tag   = MKTAG('V','2','1','0');
+st->codecpar->bit_rate= av_rescale(ctx->bmd_width * 
ctx->bmd_height * 64, st->time_base.den, st->time_base.num * 3);
+st->codecpar->bits_per_coded_sample = 10;
+break;
+case bmdFormat8BitARGB:
+st->codecpar->codec_id= AV_CODEC_ID_RAWVIDEO;
+st->codecpar->codec_tag   = avcodec_pix_fmt_to_codec_tag((enum 
AVPixelFormat)st->codecpar->format);;
+st->codecpar->format= AV_PIX_FMT_ARGB;
+break;
+case bmdFormat8BitBGRA:
+st->codecpar->codec_id= AV_CODEC_ID_RAWVIDEO;
+st->codecpar->codec_tag   = avcodec_pix_fmt_to_codec_tag((enum 
AVPixelFormat)st->codecpar->format);
+st->codecpar->format= AV_PIX_FMT_BGRA;
+break;
+case bmdFormat10BitRGB:
+st->codecpar->codec_id= AV_CODEC_ID_R210;
+st->codecpar->codec_tag   = MKTAG('R','2','1','0');
+st->codecpar->format= AV_PIX_FMT_RGB48LE;
+st->codecpar->bits_per_coded_sample = 10;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Raw Format %.4s not supported\n", (char*) 
&cctx->raw_format);
+ret = AVERROR(EINVAL);
+goto error;
 }
 
 switch (ctx->bmd_field_dominance) {
@@ -776,7 +805,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 }
 
 result = ctx->dli->EnableVideoInput(ctx->bmd_mode,
-cctx->v210 ? bmdFormat10BitYUV : 
bmdFormat8BitYUV,
+(BMDPixelFormat) cctx->raw_format,
 bmdVideoInputFlagDefault);
 
 if (result != S_OK) {
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index e2118a619c..464cf760d2 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_

Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found

[James Almer]

On 9/6/2017 6:09 AM, Hendrik Leppkes wrote:
> On Wed, Sep 6, 2017 at 2:27 AM, James Almer  wrote:
>> On 9/5/2017 8:47 PM, Hendrik Leppkes wrote:
>>> On Wed, Sep 6, 2017 at 12:32 AM, James Almer  wrote:
 On 9/5/2017 7:12 PM, Hendrik Leppkes wrote:
> On Tue, Sep 5, 2017 at 11:20 PM, James Almer  wrote:
>> On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
>>> On Mon, Sep 4, 2017 at 4:47 AM, James Almer  wrote:
 Skip the invalid data in an attempt to find one instead, and continue 
 decoding from there.

 Fixes ticket #6634

 Signed-off-by: James Almer 
 ---
  libavformat/aacdec.c | 41 +
  1 file changed, 29 insertions(+), 12 deletions(-)

 diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
 index 364b33404f..7aacc88560 100644
 --- a/libavformat/aacdec.c
 +++ b/libavformat/aacdec.c
 @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
  return 0;
  }

 +static int resync(AVFormatContext *s)
 +{
 +uint16_t state;
 +
 +state = avio_r8(s->pb);
 +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
 +state = (state << 8) | avio_r8(s->pb);
 +if ((state >> 4) != 0xFFF)
 +continue;
 +avio_seek(s->pb, -2, SEEK_CUR);
 +break;
 +}
 +
>>>
>>> The ADTS sync code isn't that much of a sync code, maybe it might be
>>> more resilient if you try to read the frame size and check if after
>>> that the next frame also starts with a valid code?
>>
>> That will only let me know if at the end of the frame is another frame,
>> and not if the frame I'm reading is complete or not.
>> Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
>> complete and right after it there's garbage. Maybe it's incomplete
>> because another ADTS frame started suddenly in the middle of the one i
>> tried to read because the source is some weird stream (sample in the
>> ticket this fixes), and after reading the reported size of the intended
>> frame the demuxer will find itself in the middle of the new one but
>> unable to know that's the case.
>>
>> Really, at the demuxer level i can't do much more than read an ADTS
>> header, make sure it's at least seven bytes long and that the reported
>> size of the entire frame is bigger than the header size, then make a
>> packet out of that. The decoder/parser will handle things from there,
>> knowing that at very least for the first few bytes what reaches them is
>> an ADTS frame.
>>
>
> We're not talking about validating the ADTS frame, but just making
> sure you really "resync" to the start of a frame, and not some
> arbitrary random position that just happens to be 0xFFF, because that
> code isn't very long or very special.

 Again, what if there's no new ADTS frame after the supposed end of the
 one we're reading? How do we interpret that? That the one we read was
 wrong or that it was right and there simply is no new ADTS frame right
 after it? How does that help us decide if we propagate it or not?

 If anything, i could maybe use avpriv_aac_parse_header(). Barely more
 resilient than just looking for a sync code and the size field being >
 7, but it's something i guess.
>>>
>>> If there is no two consecutive ADTS frames to be found, just stop sending 
>>> data.
>>
>> We're doing exactly that right now. The point of this patch is to not do
>> it any longer.
>>
>>> I don't see the problem.
>>
>> This patch loses its meaning. I have the feeling you're not getting what
>> I'm trying to do here.
>> The sample this fixes has several ADTS frames cut at the middle where
>> another was injected (Seems to be a raw stream dump). At the reported
>> end of the cut frame there isn't a new sync header, there's data from
>> the middle of the new unexpected frame. By stopping there, we're barely
>> decoding 2 seconds of audio, when there's about 19 that can get decoded
>> if we instead move forward trying to find the start of a new frame.
>>
>> Before the commit that put us in our current situation the demuxer would
>> just send everything and let the parser combine data into hopefully
>> valid frames. This resulted in things that weren't audio frames being
>> propagated, like id3v1 or APE tags, or just garbage.
> 
> I don't see how checking for two consecutive frames would really stop
> this from decoding further audio?
> We lost sync, we try to find the next ADTS sync code, then we validate
> it by reading the frame size and checking if after this frame another
> one starts - ie. if we're really "synced" to frame starts again.

What if after the frame i'm checking there's an id

Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.

[James Almer]

On 9/6/2017 6:55 AM, wm4 wrote:
> On Tue, 5 Sep 2017 22:14:39 -0300
> James Almer  wrote:
> 
>> On 9/5/2017 5:38 AM, wm4 wrote:
>>> On Tue, 5 Sep 2017 10:03:11 +0200
>>> Clément Bœsch  wrote:
>>>   
 On Mon, Sep 04, 2017 at 08:35:17PM +0200, wm4 wrote:
 [...]  
 Can't we just remove this codec? It has no use other than causing
 potential security issues and maintenance.  
>>>
>>> I agree about removing the encoder, but the decoder is needed for
>>> existing streams. Unless everyone just argues it has no real world
>>> samples for being an avcodec-only toy codec.
>>>
>>> If you send a patch removing the encoder without also trying to remove
>>> all the things that currently depend on it (One or two filters i think)
>>> then I'll +1 it. ffv1 and mpeg4 encoders are enough for any kind of
>>> testing, fate or otherwise, that might require a native encoder.  
>>
>> I find it a bit offensive that people suggest to remove the encoder i
>> maintain.
>
> Can I add my own unused fringe codec with no users, as long as I
> maintain it?

 Is there any reason to be so obsessed with snow? There are plenty of other
 "fringe" codecs in the codebase that only one person in the world cared
 about 10 years ago. Snow is one of the rare wavelet codecs, and as a
 result is much more valuable than many random basic game flavored codecs.
 And somehow, no one ever mention those.  
>>>
>>> Those game codecs have actually some use. There are files in the wild
>>> that are available to many, and that aren't just demo/test files. But
>>> it's true that all these game codecs bloat the codebase, cause
>>> maintenance and security issues, and have little use. They barely have
>>> a justification to exist too.  
>>
>> Don't be one of those that go "h264/aac/mov is all ffmpeg should care
>> about".
> 
> I didn't argue that at all. I'm arguing that FFmpeg probably shouldn't
> support a codec that was used by 1 or 2 released games, and for which
> we can't guarantee security. Obscure features are a pretty big and
> popular attack surface.
> 
> That's very different from arguing that we should drop all codecs but 3.
> 
>>>
>>> The only argument for snow is that it's a nice ideas. It might serve as
>>> some proof of concept. As a real codec, it appears to be unusable.
>>>   
 I don't personally care about game codecs or snow myself (probably nobody
 does), but I don't support this snow/swscale/whatever-michael-did killing
 circle jerk. This really feels like some form of constant harassment (I'm
 not even talking about IRC), and that's not acceptable.  
>>>
>>> Well, michael could just cut back on trying to force insane stuff. His
>>> obstinate attitude to force ridiculous patches and defending them like
>>> they're the only choice doesn't help. Even when we try to remove some
>>> of his sins, he'll defend it to death, no matter how crazy and stupid
>>> the code was (side data merging comes to mind).  
>>
>> Seeing that stuff is effectively deprecated, i don't think he defended
>> it to death. Everyone argued it was a pointless feature, and he
>> ultimately conceded.
> 
> He only "conceded" after I put all of my energy into it,

Nicolas and others agreed with you that it was a pointless feature.
Nobody sided with Michael's views on the feature, so it was a lost battle.

> and even then
> he was letting us know that he thought side data merging was great. And
> of course this whole thing was not without claiming that side data
> merging was part of the ABI, which is pure BS (but he probably did that
> so that I had even more work with creating separate version guards).

You have no reason to assume this kind of malice. At all.

Also, had you also removed the automated merging parts of the code
without waiting for a major bump, if a pre-removal lavf were to send a
packet to a post-removal lavc, the latter would shit the bed with all
the packets full of unexpected data it doesn't understand.
The major bump patch i sent effectively gets rid of the ABI part of this
feature as you scheduled it. It's no longer an issue.

Maybe we should just bump major versions with every release instead and
forget about backwards compatibility? libav essentially does that since
they release once a year or less often. No two of their releases share
major versions.
It would certainly get rid of a lot of headaches for us.

> 
> Shit like this happens every fucking time. I'm tired of it, so excuse
> me if I sometimes get "rude".
> 
>>>
>>> If you feel like what I'm doing is harassment, I can end my involvement
>>> with michael to avoid this - but only if you stop him from doing bad
>>> things.  
>>
>> You're very critical of all his patches. In many cases you give a
>> detailed technical explanation of why you disagree, but most times you
>> just make a snarky comment or are otherwise kinda rude.
>> Even when you were proven wrong (t

Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.

[wm4]

On Wed, 6 Sep 2017 11:33:05 -0300
James Almer  wrote:

> Also, had you also removed the automated merging parts of the code
> without waiting for a major bump, if a pre-removal lavf were to send a
> packet to a post-removal lavc, the latter would shit the bed with all
> the packets full of unexpected data it doesn't understand.

Yes, because that's such a common and well-working configuration. Only
lesser Linux distros will do this anyway, and they don't matter. How
many other changes did we make and ignore such issues completely?

You also forget that pre-bump libavformat was still supposed to generate
merged side data, because otherwise it would "break" applications. So
basically the BS was rubbed in my face.

> Maybe we should just bump major versions with every release instead and
> forget about backwards compatibility? libav essentially does that since
> they release once a year or less often. No two of their releases share
> major versions.
> It would certainly get rid of a lot of headaches for us.

Yes, it would be an improvement over doing complicated work for
absolutely no reason.

> > What could we possibly lose at this point.  
> 
> Time, patience, hair, etc. Lot of things.

I lost much of those.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: migrate to new encode API

[Philip Langdale]

On Sat,  2 Sep 2017 21:27:03 +0200
Timo Rothenpieler  wrote:

> Signed-off-by: Timo Rothenpieler 
> ---
>  libavcodec/nvenc.c  | 65
> -
> libavcodec/nvenc.h  |  6 + libavcodec/nvenc_h264.c |  6 +
>  libavcodec/nvenc_hevc.c |  4 +++
>  4 files changed, 70 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 744e5e0e01..b54cb1275b 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -1807,8 +1807,7 @@ static int output_ready(AVCodecContext *avctx,
> int flush) return (nb_ready > 0) && (nb_ready + nb_pending >=
> ctx->async_depth); }
>  
> -int ff_nvenc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> -  const AVFrame *frame, int *got_packet)
> +int ff_nvenc_send_frame(AVCodecContext *avctx, const AVFrame *frame)
>  {
>  NVENCSTATUS nv_status;
>  CUresult cu_res;
> @@ -1823,12 +1822,16 @@ int ff_nvenc_encode_frame(AVCodecContext
> *avctx, AVPacket *pkt, NV_ENC_PIC_PARAMS pic_params = { 0 };
>  pic_params.version = NV_ENC_PIC_PARAMS_VER;
>  
> +if (!ctx->cu_context || !ctx->nvencoder)
> +return AVERROR(EINVAL);
> +
> +if (ctx->encoder_flushing)
> +return AVERROR_EOF;
> +
>  if (frame) {
>  inSurf = get_free_frame(ctx);
> -if (!inSurf) {
> -av_log(avctx, AV_LOG_ERROR, "No free surfaces\n");
> -return AVERROR_BUG;
> -}
> +if (!inSurf)
> +return AVERROR(EAGAIN);
>  
>  cu_res = dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context);
>  if (cu_res != CUDA_SUCCESS) {
> @@ -1876,6 +1878,7 @@ int ff_nvenc_encode_frame(AVCodecContext
> *avctx, AVPacket *pkt, nvenc_codec_specific_pic_params(avctx,
> &pic_params); } else {
>  pic_params.encodePicFlags = NV_ENC_PIC_FLAG_EOS;
> +ctx->encoder_flushing = 1;
>  }
>  
>  cu_res = dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context);
> @@ -1914,7 +1917,23 @@ int ff_nvenc_encode_frame(AVCodecContext
> *avctx, AVPacket *pkt, }
>  }
>  
> -if (output_ready(avctx, !frame)) {
> +return 0;
> +}
> +
> +int ff_nvenc_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> +{
> +CUresult cu_res;
> +CUcontext dummy;
> +NvencSurface *tmpoutsurf;

You can remove tmpoutsurf in ff_nvenc_send_frame

> +int res;
> +
> +NvencContext *ctx = avctx->priv_data;
> +NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
> +
> +if (!ctx->cu_context || !ctx->nvencoder)
> +return AVERROR(EINVAL);
> +
> +if (output_ready(avctx, ctx->encoder_flushing)) {
>  av_fifo_generic_read(ctx->output_surface_ready_queue,
> &tmpoutsurf, sizeof(tmpoutsurf), NULL); 
>  cu_res = dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context);
> @@ -1935,10 +1954,34 @@ int ff_nvenc_encode_frame(AVCodecContext
> *avctx, AVPacket *pkt, return res;
>  
>  av_fifo_generic_write(ctx->unused_surface_queue,
> &tmpoutsurf, sizeof(tmpoutsurf), NULL); -
> -*got_packet = 1;
> +} else if (ctx->encoder_flushing) {
> +return AVERROR_EOF;
>  } else {
> +return AVERROR(EAGAIN);
> +}
> +
> +return 0;
> +}
> +
> +int ff_nvenc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> +  const AVFrame *frame, int *got_packet)
> +{
> +NvencContext *ctx = avctx->priv_data;
> +int res;
> +
> +if (!ctx->encoder_flushing) {
> +res = ff_nvenc_send_frame(avctx, frame);
> +if (res < 0)
> +return res;
> +}
> +
> +res = ff_nvenc_receive_packet(avctx, pkt);
> +if (res == AVERROR(EAGAIN) || res == AVERROR_EOF) {
>  *got_packet = 0;
> +} else if (res < 0) {
> +return res;
> +} else {
> +*got_packet = 1;
>  }
>  
>  return 0;
> diff --git a/libavcodec/nvenc.h b/libavcodec/nvenc.h
> index 2c682275da..afb93cc22c 100644
> --- a/libavcodec/nvenc.h
> +++ b/libavcodec/nvenc.h
> @@ -116,6 +116,8 @@ typedef struct NvencContext
>  AVFifoBuffer *output_surface_ready_queue;
>  AVFifoBuffer *timestamp_list;
>  
> +int encoder_flushing;
> +
>  struct {
>  CUdeviceptr ptr;
>  NV_ENC_REGISTERED_PTR regptr;
> @@ -169,6 +171,10 @@ int ff_nvenc_encode_init(AVCodecContext *avctx);
>  
>  int ff_nvenc_encode_close(AVCodecContext *avctx);
>  
> +int ff_nvenc_send_frame(AVCodecContext *avctx, const AVFrame *frame);
> +
> +int ff_nvenc_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
> +
>  int ff_nvenc_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
>const AVFrame *frame, int *got_packet);
>  
> diff --git a/libavcodec/nvenc_h264.c b/libavcodec/nvenc_h264.c
> index 9adbe9f909..c3b4bac749 100644
> --- a/libavcodec/nvenc_h264.c
> +++ b/libavcodec/nvenc_h264.c
> @@ -164,6 +164,8 @@ AVCodec ff_nvenc_encoder = {
>  .type   = AVMEDIA_TYPE_VIDEO,
>  .id = AV_CODEC_ID_H264,
>  .init   

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: migrate to new encode API

[Timo Rothenpieler]

+int ff_nvenc_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
+{
+CUresult cu_res;
+CUcontext dummy;
+NvencSurface *tmpoutsurf;


You can remove tmpoutsurf in ff_nvenc_send_frame


But it's used in it? At the very end, to move the frames between queues.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: new options 'list_pixelformats' and 'pixelformat_code' to allow pixelformat selection by code

[Marton Balint]

On Wed, 6 Sep 2017, Gildas Fargeas wrote:


Alright, this should do the trick:
- use named const for raw_format option
- deprecate bm_v210
- bumped avdevice micro version

---
libavdevice/decklink_common.cpp |  2 +-
libavdevice/decklink_common_c.h |  1 +
libavdevice/decklink_dec.cpp| 43 ++---
libavdevice/decklink_dec_c.c|  6 ++
libavdevice/version.h   |  2 +-
5 files changed, 45 insertions(+), 9 deletions(-)


Documentation is still missing for the new option from doc/indevs.texi.



diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index cbb591ce64..ff2df95909 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -241,7 +241,7 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if (ctx->bmd_mode == bmdModeUnknown)
return -1;
if (direction == DIRECTION_IN) {
-if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
+if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, (BMDPixelFormat) 
cctx->raw_format,
   bmdVideoOutputFlagDefault,
   &support, NULL) != S_OK)
return -1;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index e263480474..5616ab32f9 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -49,6 +49,7 @@ struct decklink_cctx {
int video_input;
int draw_bars;
char *format_code;
+int raw_format;
int64_t queue_size;
};

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index c271ff3639..ccbb6f09f5 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -651,6 +651,11 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
return AVERROR_EXIT;
}

+if (cctx->v210) {
+av_log(avctx, AV_LOG_WARNING, "The bm_v210 option is deprecated and will be 
removed. Please use the -raw_format yuv422p10.\n");
+cctx->raw_format = MKBETAG('v','2','1','0');
+}
+
strcpy (fname, avctx->filename);
tmp=strchr (fname, '@');
if (tmp != NULL) {
@@ -723,15 +728,39 @@ av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)
st->time_base.num  = ctx->bmd_tb_num;
av_stream_set_r_frame_rate(st, av_make_q(st->time_base.den, 
st->time_base.num));

-if (cctx->v210) {
-st->codecpar->codec_id= AV_CODEC_ID_V210;
-st->codecpar->codec_tag   = MKTAG('V', '2', '1', '0');
-st->codecpar->bit_rate= av_rescale(ctx->bmd_width * ctx->bmd_height * 
64, st->time_base.den, st->time_base.num * 3);
-} else {
+switch((BMDPixelFormat)cctx->raw_format) {
+case bmdFormat8BitYUV:
st->codecpar->codec_id= AV_CODEC_ID_RAWVIDEO;
-st->codecpar->format  = AV_PIX_FMT_UYVY422;
st->codecpar->codec_tag   = MKTAG('U', 'Y', 'V', 'Y');
+st->codecpar->format  = AV_PIX_FMT_UYVY422;
st->codecpar->bit_rate= av_rescale(ctx->bmd_width * ctx->bmd_height * 16, 
st->time_base.den, st->time_base.num);
+break;
+case bmdFormat10BitYUV:
+st->codecpar->codec_id= AV_CODEC_ID_V210;
+st->codecpar->codec_tag   = MKTAG('V','2','1','0');
+st->codecpar->bit_rate= av_rescale(ctx->bmd_width * ctx->bmd_height * 
64, st->time_base.den, st->time_base.num * 3);
+st->codecpar->bits_per_coded_sample = 10;
+break;
+case bmdFormat8BitARGB:
+st->codecpar->codec_id= AV_CODEC_ID_RAWVIDEO;
+st->codecpar->codec_tag   = avcodec_pix_fmt_to_codec_tag((enum 
AVPixelFormat)st->codecpar->format);;
+st->codecpar->format= AV_PIX_FMT_ARGB;
+break;
+case bmdFormat8BitBGRA:
+st->codecpar->codec_id= AV_CODEC_ID_RAWVIDEO;
+st->codecpar->codec_tag   = avcodec_pix_fmt_to_codec_tag((enum 
AVPixelFormat)st->codecpar->format);
+st->codecpar->format= AV_PIX_FMT_BGRA;
+break;
+case bmdFormat10BitRGB:
+st->codecpar->codec_id= AV_CODEC_ID_R210;
+st->codecpar->codec_tag   = MKTAG('R','2','1','0');
+st->codecpar->format= AV_PIX_FMT_RGB48LE;
+st->codecpar->bits_per_coded_sample = 10;


You may want to add bitrates to the new formats.


+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Raw Format %.4s not supported\n", (char*) 
&cctx->raw_format);
+ret = AVERROR(EINVAL);
+goto error;
}

switch (ctx->bmd_field_dominance) {
@@ -776,7 +805,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
}

result = ctx->dli->EnableVideoInput(ctx->bmd_mode,
-cctx->v210 ? bmdFormat10BitYUV : 
bmdFormat8BitYUV,
+(BMDPixelFormat) cctx->raw_format,
bmdVideoInputFlagDefault);

if (result != S_OK) {
diff --git a/libavdevice/decklink_

[FFmpeg-devel] [PATCH] avfilter: add Haas stereo enhancer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  64 ++
 libavfilter/Makefile |   1 +
 libavfilter/af_haas.c| 226 +++
 libavfilter/allfilters.c |   1 +
 4 files changed, 292 insertions(+)
 create mode 100644 libavfilter/af_haas.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 7790367..c3c54fd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2770,6 +2770,70 @@ Set delay-line interpolation, @var{linear} or 
@var{quadratic}.
 Default is @var{linear}.
 @end table
 
+@section haas
+Apply Haas effect to audio.
+
+Note that this makes most sense to apply on mono signals.
+With this filter applied to mono signals it give some directionality and
+streches its stereo image.
+
+The filter accepts the following options:
+
+@table @option
+@item level_in
+Set input level. By default is @var{1}, or 0dB
+
+@item level_out
+Set output level. By default is @var{1}, or 0dB.
+
+@item side_gain
+Set gain applied to side part of signal. By default is @var{1}.
+
+@item middle_source
+Set kind of middle source. Can be one of the following:
+
+@table @samp
+@item left
+Pick left channel.
+
+@item right
+Pick right channel.
+
+@item mid
+Pick middle part signal of stereo image.
+
+@item side
+Pick side part signal of stereo image.
+@end table
+
+@item middle_phase
+Change middle phase. By default is disabled.
+
+@item left_delay
+Set left channel delay. By default is @var{2.05} milliseconds.
+
+@item left_balance
+Set left channel balance. By default is @var{-1}.
+
+@item left_gain
+Set left channel gain. By default is @var{1}.
+
+@item left_phase
+Change left phase. By default is disabled.
+
+@item right_delay
+Set right channel delay. By defaults is @var{2.12} milliseconds.
+
+@item right_balance
+Set right channel balance. By default is @var{1}.
+
+@item right_gain
+Set right channel gain. By default is @var{1}.
+
+@item right_phase
+Change right phase. By default is enabled.
+@end table
+
 @section hdcd
 
 Decodes High Definition Compatible Digital (HDCD) data. A 16-bit PCM stream 
with
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1e460ab..4268633 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -91,6 +91,7 @@ OBJS-$(CONFIG_EQUALIZER_FILTER)  += af_biquads.o
 OBJS-$(CONFIG_EXTRASTEREO_FILTER)+= af_extrastereo.o
 OBJS-$(CONFIG_FIREQUALIZER_FILTER)   += af_firequalizer.o
 OBJS-$(CONFIG_FLANGER_FILTER)+= af_flanger.o 
generate_wave_table.o
+OBJS-$(CONFIG_HAAS_FILTER)   += af_haas.o
 OBJS-$(CONFIG_HDCD_FILTER)   += af_hdcd.o
 OBJS-$(CONFIG_HEADPHONE_FILTER)  += af_headphone.o
 OBJS-$(CONFIG_HIGHPASS_FILTER)   += af_biquads.o
diff --git a/libavfilter/af_haas.c b/libavfilter/af_haas.c
new file mode 100644
index 000..a9761bd
--- /dev/null
+++ b/libavfilter/af_haas.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright (c) 2001-2010 Vladimir Sadovnikov
+ *
+ * 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 FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+typedef struct HaasContext {
+const AVClass *class;
+
+int par_m_source;
+int par_delay0;
+int par_delay1;
+int par_phase0;
+int par_phase1;
+int par_middle_phase;
+double par_side_gain;
+double par_gain0;
+double par_gain1;
+double par_balance0;
+double par_balance1;
+double level_in;
+double level_out;
+
+double *buffer;
+int buffer_size;
+uint32_t write_ptr;
+uint32_t delay[2];
+double balance_l[2];
+double balance_r[2];
+double phase0;
+double phase1;
+} HaasContext;
+
+#define OFFSET(x) offsetof(HaasContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption haas_options[] = {
+{ "level_in",  "set level in",  OFFSET(level_in), 
AV_OPT_TYPE_DOUBLE,  {.dbl=1}, 0.015625,  64, A },
+{ "level_out", "set level out", OFFSET(level_out),
AV_OPT_TYPE_DOUBLE,  {.dbl=1}, 0.015625,  64, A },
+{ "side_gain", "set side gain", OFFSET(par_side_gain),
AV_OPT_TYPE_DOUBLE,  {.dbl=1}, 0.015625,  64, A },
+

Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.

[Ronald S. Bultje]

Hi,

On Wed, Sep 6, 2017 at 10:33 AM, James Almer  wrote:

> But i also agree with him that, currently, the
> tree is littered with error messages that go "$spec_field is out of
> range" or whatever, and that they have not been seen as an issue before.
> He basically argues that wanting to make new ones debug level is not
> consistent with the existing code, so the proper approach would be to
> change all of them to debug in the long run, or keep adding new ones as
> error (as long as they are at least understandable).


I'm happy to help replace them with ff_dlog() or remove them, for the sake
of resolving the "consistency" argument.

Why care now? I don't mind minor issues, our tree is littered with them,
but with the amount of changes Michael is making in this area, this isn't
"minor" anymore, and it's growing. It's better to resolve such issues
before it grows out of hand and we're stuck with another MpegEncContext or
DspUtil.

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

Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found

[Hendrik Leppkes]

On Wed, Sep 6, 2017 at 3:51 PM, James Almer  wrote:
> On 9/6/2017 6:09 AM, Hendrik Leppkes wrote:
>> On Wed, Sep 6, 2017 at 2:27 AM, James Almer  wrote:
>>> On 9/5/2017 8:47 PM, Hendrik Leppkes wrote:
 On Wed, Sep 6, 2017 at 12:32 AM, James Almer  wrote:
> On 9/5/2017 7:12 PM, Hendrik Leppkes wrote:
>> On Tue, Sep 5, 2017 at 11:20 PM, James Almer  wrote:
>>> On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
 On Mon, Sep 4, 2017 at 4:47 AM, James Almer  wrote:
> Skip the invalid data in an attempt to find one instead, and continue 
> decoding from there.
>
> Fixes ticket #6634
>
> Signed-off-by: James Almer 
> ---
>  libavformat/aacdec.c | 41 +
>  1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
> index 364b33404f..7aacc88560 100644
> --- a/libavformat/aacdec.c
> +++ b/libavformat/aacdec.c
> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
>  return 0;
>  }
>
> +static int resync(AVFormatContext *s)
> +{
> +uint16_t state;
> +
> +state = avio_r8(s->pb);
> +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
> +state = (state << 8) | avio_r8(s->pb);
> +if ((state >> 4) != 0xFFF)
> +continue;
> +avio_seek(s->pb, -2, SEEK_CUR);
> +break;
> +}
> +

 The ADTS sync code isn't that much of a sync code, maybe it might be
 more resilient if you try to read the frame size and check if after
 that the next frame also starts with a valid code?
>>>
>>> That will only let me know if at the end of the frame is another frame,
>>> and not if the frame I'm reading is complete or not.
>>> Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
>>> complete and right after it there's garbage. Maybe it's incomplete
>>> because another ADTS frame started suddenly in the middle of the one i
>>> tried to read because the source is some weird stream (sample in the
>>> ticket this fixes), and after reading the reported size of the intended
>>> frame the demuxer will find itself in the middle of the new one but
>>> unable to know that's the case.
>>>
>>> Really, at the demuxer level i can't do much more than read an ADTS
>>> header, make sure it's at least seven bytes long and that the reported
>>> size of the entire frame is bigger than the header size, then make a
>>> packet out of that. The decoder/parser will handle things from there,
>>> knowing that at very least for the first few bytes what reaches them is
>>> an ADTS frame.
>>>
>>
>> We're not talking about validating the ADTS frame, but just making
>> sure you really "resync" to the start of a frame, and not some
>> arbitrary random position that just happens to be 0xFFF, because that
>> code isn't very long or very special.
>
> Again, what if there's no new ADTS frame after the supposed end of the
> one we're reading? How do we interpret that? That the one we read was
> wrong or that it was right and there simply is no new ADTS frame right
> after it? How does that help us decide if we propagate it or not?
>
> If anything, i could maybe use avpriv_aac_parse_header(). Barely more
> resilient than just looking for a sync code and the size field being >
> 7, but it's something i guess.

 If there is no two consecutive ADTS frames to be found, just stop sending 
 data.
>>>
>>> We're doing exactly that right now. The point of this patch is to not do
>>> it any longer.
>>>
 I don't see the problem.
>>>
>>> This patch loses its meaning. I have the feeling you're not getting what
>>> I'm trying to do here.
>>> The sample this fixes has several ADTS frames cut at the middle where
>>> another was injected (Seems to be a raw stream dump). At the reported
>>> end of the cut frame there isn't a new sync header, there's data from
>>> the middle of the new unexpected frame. By stopping there, we're barely
>>> decoding 2 seconds of audio, when there's about 19 that can get decoded
>>> if we instead move forward trying to find the start of a new frame.
>>>
>>> Before the commit that put us in our current situation the demuxer would
>>> just send everything and let the parser combine data into hopefully
>>> valid frames. This resulted in things that weren't audio frames being
>>> propagated, like id3v1 or APE tags, or just garbage.
>>
>> I don't see how checking for two consecutive frames would really stop
>> this from decoding further audio?
>> We lost sync, we try to find the next ADTS sync code, then we validate
>> it by reading the frame size and c

Re: [FFmpeg-devel] [PATCH] configure: Fix DEF file post-processing with LTO enabled.

[Kacper Michajlow]

2017-08-22 21:26 GMT+02:00 Kacper Michajłow :

> With LTO enabled exported symbol entry looks like:
> av_audio_convert @3 DATA
>
> In order to maintain valid format we need to strip everything after @.
>
> This patch fixes linking libraries compiled with MinGW toolchain with LTO
> enabled.
>
> Signed-off-by: Kacper Michajłow 
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
>
Bump after two weeks.

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

Re: [FFmpeg-devel] [PATCH 1/7] build: fix objcc header check

[Thilo Borgmann]

Hi,

Am 06.09.17 um 11:58 schrieb Clément Bœsch:
> From: Clément Bœsch 
> 
> $headers is a variable set in the context of other functions (we don't
> use the "local" keyword in our scripts, so those variables are global).
> 
> Currently, when checking for AVFoundation/AVFoundation.h, the actual
> enabled header is math.h.
> 
> Similarly, when testing for QuartzCore/CoreImage.h, the actual enabled
> header is CoreGraphics/CoreGraphics.h.
> 
> This is completely broken and may be the reason why these checks are
> made in random places.

thus it was just a typo like the patch 1 suggested?

Patch 1-5 ok!
For patch 6-7 maybe someone else can have a closer look.

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

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

[Ashish Pratap Singh]

From: Ashish Singh 

Hi, this patch changes previous one to framesync2.
SIMD is a work in progress for this filter.

Signed-off-by: Ashish Singh 
---
 Changelog   |   1 +
 doc/filters.texi|  16 ++
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_vmafmotion.c | 413 
 libavfilter/vmaf_motion.h   |  42 +
 6 files changed, 474 insertions(+)
 create mode 100644 libavfilter/vf_vmafmotion.c
 create mode 100644 libavfilter/vmaf_motion.h

diff --git a/Changelog b/Changelog
index cae5254..883e08f 100644
--- a/Changelog
+++ b/Changelog
@@ -43,6 +43,7 @@ version :
 - add --disable-autodetect build switch
 - drop deprecated qtkit input device (use avfoundation instead)
 - despill video filter
+- vmafmotion video filter
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/doc/filters.texi b/doc/filters.texi
index 7790367..9a348b6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -15488,6 +15488,22 @@ vignette='PI/4+random(1)*PI/50':eval=frame
 
 @end itemize
 
+@section vmafmotion
+
+Obtain the average vmaf motion score between two input videos.
+It is one of the component filters of VMAF.
+
+This filter takes two input videos.
+
+The obtained average motion score is printed through the logging system.
+
+In the below example the input file @file{main.mpg} being processed is compared
+with the reference file @file{ref.mpg}.
+
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmafmotion -f null -
+@end example
+
 @section vstack
 Stack input videos vertically.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1e460ab..de46649 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -328,6 +328,7 @@ OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
 OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += vidstabutils.o 
vf_vidstabdetect.o
 OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += vidstabutils.o 
vf_vidstabtransform.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
+OBJS-$(CONFIG_VMAFMOTION_FILTER) += vf_vmafmotion.o framesync2.o
 OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync2.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9a2cfea..31f1971 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -339,6 +339,7 @@ static void register_all(void)
 REGISTER_FILTER(VIDSTABDETECT,  vidstabdetect,  vf);
 REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
 REGISTER_FILTER(VIGNETTE,   vignette,   vf);
+REGISTER_FILTER(VMAFMOTION, vmafmotion, vf);
 REGISTER_FILTER(VSTACK, vstack, vf);
 REGISTER_FILTER(W3FDIF, w3fdif, vf);
 REGISTER_FILTER(WAVEFORM,   waveform,   vf);
diff --git a/libavfilter/vf_vmafmotion.c b/libavfilter/vf_vmafmotion.c
new file mode 100644
index 000..873d00f
--- /dev/null
+++ b/libavfilter/vf_vmafmotion.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright (c) 2017 Ronald S. Bultje 
+ * Copyright (c) 2017 Ashish Pratap Singh 
+ *
+ * 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 FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Calculate VMAF Motion score between two input videos.
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "drawutils.h"
+#include "formats.h"
+#include "framesync2.h"
+#include "internal.h"
+#include "vmaf_motion.h"
+#include "video.h"
+
+typedef struct VMAFMotionContext {
+const AVClass *class;
+FFFrameSync fs;
+const AVPixFmtDescriptor *desc;
+int filter[5];
+int width;
+int height;
+uint16_t *prev_blur_data;
+uint16_t *blur_data;
+uint16_t *temp_data;
+double motion_sum;
+uint64_t nb_frames;
+} VMAFMotionContext;
+
+#define MAX_ALIGN 32
+#define ALIGN_CEIL(x) ((x) + ((x) % MAX_ALIGN ? MAX_ALIGN - (x) % MAX_ALIGN : 
0))
+
+static const AVOption vmafmotion_options[] = {
+{ NULL }
+};
+
+FRAMESYNC_DEFINE_CLASS(vmafmotion, VMAFMotionContext, fs);
+
+static uint64_t image_sad(const uint16_t *img1, const uint16_t *img2, int w, 
i

Re: [FFmpeg-devel] [PATCH] avfilter/interlace: prevent over-sharpening with the complex low-pass filter

[Thomas Mundt]

2017-09-01 1:55 GMT+02:00 Thomas Mundt :

> 2017-09-01 1:22 GMT+02:00 Michael Niedermayer :
>
>> On Fri, Sep 01, 2017 at 01:18:11AM +0200, Michael Niedermayer wrote:
>> > On Thu, Aug 31, 2017 at 10:40:12PM +0200, Thomas Mundt wrote:
>> > > 2017-08-31 21:42 GMT+02:00 Michael Niedermayer > >:
>> > >
>> > > > On Wed, Aug 30, 2017 at 03:54:08AM +0200, Thomas Mundt wrote:
>> > > > > Hi,
>> > > > >
>> > > > > we did a transcoding cascade test at work were over-sharpening
>> became
>> > > > > visible with the complex low-pass filter. This patch rectifies the
>> > > > > behaviour.
>> > > > >
>> > > > > Please comment...
>> > > >
>> > > > did you perform subjective and or objective tests ?
>> > > >
>> > > > objective being some metric like PSNR vs correctly sampled data
>> > > > subjective being double blind tests with humans about which they
>> prefer
>> > > >
>> > >
>> > > The tests have been subjective with a team of video engineers and
>> > > technicians with several test files.
>> > >
>> > > I did a quick SSIM/PSNR check with the first generation of an HD->SD
>> file
>> > > as a reference against the 6th generation.
>> >
>> > if its better then iam fine with it. No more comments from me
>>
>> ahh, forgot, you may want tp add the tests you did and their results
>> to the commit message
>
>
> Sure, new patch attached.
>

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

[FFmpeg-devel] [PATCH] vf_fps: uses the last frame duration to duplicate it if needed

[Thierry Foucu]

---
 libavfilter/vf_fps.c| 40 +++-
 tests/ref/fate/filter-fps   |  6 ++
 tests/ref/fate/filter-fps-r |  4 
 3 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 20ccd797d1..a231da415c 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -137,13 +137,43 @@ static int request_frame(AVFilterLink *outlink)
 AVFrame *buf;
 
 av_fifo_generic_read(s->fifo, &buf, sizeof(buf), NULL);
-buf->pts = av_rescale_q(s->first_pts, ctx->inputs[0]->time_base,
-outlink->time_base) + s->frames_out;
+if (av_fifo_size(s->fifo)) {
+buf->pts = av_rescale_q(s->first_pts, 
ctx->inputs[0]->time_base,
+outlink->time_base) + s->frames_out;
 
-if ((ret = ff_filter_frame(outlink, buf)) < 0)
-return ret;
+if ((ret = ff_filter_frame(outlink, buf)) < 0)
+return ret;
 
-s->frames_out++;
+s->frames_out++;
+} else {
+/* This is the last frame, we may have to duplicate it to match
+ * the last frame duration */
+int j;
+int delta = av_rescale_q_rnd(buf->pts + buf->pkt_duration - 
s->first_pts,
+ ctx->inputs[0]->time_base,
+ outlink->time_base, s->rounding) 
- s->frames_out ;
+if (delta > 0 ) {
+for (j = 0; j < delta; j++) {
+AVFrame *dup = av_frame_clone(buf);
+
+av_log(ctx, AV_LOG_DEBUG, "Duplicating frame.\n");
+dup->pts = av_rescale_q(s->first_pts, 
ctx->inputs[0]->time_base,
+outlink->time_base) + 
s->frames_out;
+
+if ((ret = ff_filter_frame(outlink, dup)) < 0)
+return ret;
+
+s->frames_out++;
+}
+} else {
+buf->pts = av_rescale_q(s->first_pts, 
ctx->inputs[0]->time_base,
+outlink->time_base) + 
s->frames_out;
+
+if ((ret = ff_filter_frame(outlink, buf)) < 0)
+return ret;
+s->frames_out++;
+}
+}
 }
 return 0;
 }
diff --git a/tests/ref/fate/filter-fps b/tests/ref/fate/filter-fps
index 55712cfb1c..242fb04e85 100644
--- a/tests/ref/fate/filter-fps
+++ b/tests/ref/fate/filter-fps
@@ -85,3 +85,9 @@
 0, 79, 79,1,30576, 0xa2fcd06f
 0, 80, 80,1,30576, 0xa2fcd06f
 0, 81, 81,1,30576, 0xd4150aad
+0, 82, 82,1,30576, 0xd4150aad
+0, 83, 83,1,30576, 0xd4150aad
+0, 84, 84,1,30576, 0xd4150aad
+0, 85, 85,1,30576, 0xd4150aad
+0, 86, 86,1,30576, 0xd4150aad
+0, 87, 87,1,30576, 0xd4150aad
diff --git a/tests/ref/fate/filter-fps-r b/tests/ref/fate/filter-fps-r
index 826b1ed6c6..c1bc7d1547 100644
--- a/tests/ref/fate/filter-fps-r
+++ b/tests/ref/fate/filter-fps-r
@@ -72,3 +72,7 @@
 0, 79, 79,1,30576, 0xa2fcd06f
 0, 80, 80,1,30576, 0xa2fcd06f
 0, 82, 82,1,30576, 0xd4150aad
+0, 83, 83,1,30576, 0xd4150aad
+0, 84, 84,1,30576, 0xd4150aad
+0, 85, 85,1,30576, 0xd4150aad
+0, 86, 86,1,30576, 0xd4150aad
-- 
2.14.1.581.gf28d330327-goog

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

Re: [FFmpeg-devel] [PATCH] vf_fps: uses the last frame duration to duplicate it if needed

[Nicolas George]

Le decadi 20 fructidor, an CCXXV, Thierry Foucu a écrit :
> ---
>  libavfilter/vf_fps.c| 40 +++-
>  tests/ref/fate/filter-fps   |  6 ++
>  tests/ref/fate/filter-fps-r |  4 
>  3 files changed, 45 insertions(+), 5 deletions(-)

Already explained: no, pkt_duration is not part of the information taken
into account by libavfilter. The correct way of obtaining the end
timestamp is to use the link's timestamp after EOF. There is an old
patch series to ensure it is accurate, but it has been delayed by
bikeshedding.

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] avcodec/nvenc: migrate to new encode API

[Philip Langdale]

On Wed, 6 Sep 2017 18:14:17 +0200
Timo Rothenpieler  wrote:

> >> +int ff_nvenc_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> >> +{
> >> +CUresult cu_res;
> >> +CUcontext dummy;
> >> +NvencSurface *tmpoutsurf;  
> > 
> > You can remove tmpoutsurf in ff_nvenc_send_frame  
> 
> But it's used in it? At the very end, to move the frames between
> queues.
> 

Yes, I mis-read that. Ship it.

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

Re: [FFmpeg-devel] [PATCH] vf_fps: uses the last frame duration to duplicate it if needed

[Paul B Mahol]

On 9/6/17, Nicolas George  wrote:
> Le decadi 20 fructidor, an CCXXV, Thierry Foucu a ecrit :
>> ---
>>  libavfilter/vf_fps.c| 40
>> +++-
>>  tests/ref/fate/filter-fps   |  6 ++
>>  tests/ref/fate/filter-fps-r |  4 
>>  3 files changed, 45 insertions(+), 5 deletions(-)
>
> Already explained: no, pkt_duration is not part of the information taken
> into account by libavfilter.

Why?

> The correct way of obtaining the end
> timestamp is to use the link's timestamp after EOF. There is an old
> patch series to ensure it is accurate, but it has been delayed by
> bikeshedding.

And why was it bikesheded?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_fps: uses the last frame duration to duplicate it if needed

[Nicolas George]

Le decadi 20 fructidor, an CCXXV, Paul B Mahol a écrit :
> Why?

Several reasons that I have explained in the past. To make it short, the
information there is not reliable, not filled by the applications, not
updated by many filters and likely to be inconsistent. Is that enough?

> And why was it bikesheded?

For completely unrelated reason within the code of ffmpeg.c.

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 2/2] lavfi/atempo: Avoid false triggering an assertion failure

[Marton Balint]

On Tue, 5 Sep 2017, Marton Balint wrote:



On Sun, 3 Sep 2017, pkoshe...@gmail.com wrote:


From: Pavel Koshevoy 

Steps to reproduce:
1. revert 4240e5b047379b29c33dd3f4438bc4e610527b83
2. ./ffmpeg -f lavfi -i sine=d=1 -af aselect=e=0,atempo=0.5 -y atempo.wav
---
libavfilter/af_atempo.c | 5 +
1 file changed, 5 insertions(+)

diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 9eee8a63a8..41c8c0382a 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -914,6 +914,11 @@ static int yae_flush(ATempoContext *atempo,

atempo->state = YAE_FLUSH_OUTPUT;

+if (!atempo->nfrag) {
+  // there is nothing to flush:
+  return 0;
+}
+
if (atempo->position[0] == frag->position[0] + frag->nsamples &&
atempo->position[1] == frag->position[1] + frag->nsamples) {
// the current fragment is already flushed:


Thanks, this does the trick. Will apply in 1-2 days.


Applied the series, thanks.

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

Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.

[Michael Niedermayer]

On Wed, Sep 06, 2017 at 11:55:41AM +0200, wm4 wrote:
> On Tue, 5 Sep 2017 22:14:39 -0300
> James Almer  wrote:
> 
> > On 9/5/2017 5:38 AM, wm4 wrote:
> > > On Tue, 5 Sep 2017 10:03:11 +0200
> > > Clément Bœsch  wrote:
> > >   
> > >> On Mon, Sep 04, 2017 at 08:35:17PM +0200, wm4 wrote:
[...]
> > > 
> > > The only argument for snow is that it's a nice ideas. It might serve as
> > > some proof of concept. As a real codec, it appears to be unusable.
> > >   
> > >> I don't personally care about game codecs or snow myself (probably nobody
> > >> does), but I don't support this snow/swscale/whatever-michael-did killing
> > >> circle jerk. This really feels like some form of constant harassment (I'm
> > >> not even talking about IRC), and that's not acceptable.  
> > > 
> > > Well, michael could just cut back on trying to force insane stuff. His
> > > obstinate attitude to force ridiculous patches and defending them like
> > > they're the only choice doesn't help. Even when we try to remove some
> > > of his sins, he'll defend it to death, no matter how crazy and stupid
> > > the code was (side data merging comes to mind).  
> > 
> > Seeing that stuff is effectively deprecated, i don't think he defended
> > it to death. Everyone argued it was a pointless feature, and he
> > ultimately conceded.
> 
> He only "conceded" after I put all of my energy into it, and even then

> he was letting us know that he thought side data merging was great.

This is a false statement about me
Its my oppinion that
side data merging gave FFmpeg a strategic advantage over Libav at
the time it was added.
Without a competition at the time i would not have supported adding
it most likely.


[...]

Iam refraining from commenting on some of the snipped aggression
above


> Getting back to this bit:
> 
> > You're very critical of all his patches. In many cases you give a
> > detailed technical explanation of why you disagree, but most times you
> > just make a snarky comment or are otherwise kinda rude.
> 
> In general, Michael often tends to post new patches with exactly the
> same bad issues as past patches, even though there was lengthy
> discussion about them, how they were bad, and how Michael shouldn't do
> that. So excuse me if I don't repeat myself every time.
> 
> We had this discussion about fine grained error messages for fuzzed
> samples before too. Several times. Michael doesn't learn, or most
> likely, doesn't want to learn. It's rude to ignore our comments. Why are
> you complaining about me again?

I think you misunderstand or at least we have a different understanding
of the situation

In FFmpeg each piece of code has a maintainer. In fact
thats true everywhere, theres always someone or more who does the work.

And in general, not specific to FFmpeg
The people doing the work most of the time have the
authority about how to do it or they tend to be paid.

In FFmpeg, the person doing the work has the final decission on how the
code is written. Within the rules of our development policy.
For snow, a few others and defacto jpeg2000 thats me

jpeg 2000 is btw a terrible codec, i would be more than happy to give
the maintainer hat to someone else.

git shortlog -sn libavcodec/jpeg2000*
   317  Michael Niedermayer
14  Luca Barbato
 9  Carl Eugen Hoyos
 9  Hendrik Leppkes
 7  Nicolas Bertrand
 6  Vittorio Giovara
 4  James Almer
 4  Janne Grunau
 3  Diego Biurrun
 3  Ganesh Ajjanagadde
 3  Paul B Mahol
 2  Anton Khirnov
 2  Clément Bœsch
 1  Derek Buitenhuis
 1  Lou Logan
 1  Lukasz Marek
 1  Martin Storsjö
 1  Reimar Döffinger

If the mainatiner of some code has a preferrance that differs from
your preferrance thats nothing to be upset about.

And i stated repeatedly that iam happy to follow the community
preferrance.
But instead of an attempt to poll the community for everyones
preferrance. there are 3 or 4 people who keep telling me
with increased aggression to do what they say. That is with mails
worded as if there was alot of authority behind them.
I find these mails quite rude honestly. Rude toward the community and
toward me.

Thus you have the current situation where patches i write for code
maintained by people who stated they want "no error messages" to have
no such messages. (unless i forget)

And patches writen for code maintained by me and others who didnt
state anything often contain error messages. (unless i forget)

Thats not ignoring people, i try to respect everyones preferrance in
code they maintain. And i would wish they would respect mine in code
i maintain, but some dont do that.

If somone explicitly objects to a patch i have always refrained from
pushing it.

And it seems people very easily get upset if I propose changes to code
i maintain that they previously told me they dont like.
"Why" really is beyond my comperhension. Iam the one maintaining this
code, and even have only proposed the changes in a posted patch.


> 
> > I tried to find

Re: [FFmpeg-devel] [PATCH] avformat/mux: stop delaying writing the header

[James Almer]

On 5/26/2017 5:08 PM, James Almer wrote:
> There's no need to wait for the first packet of every stream now that
> every bitstream filter behaves as intended.
> 
> Signed-off-by: James Almer 
> ---
> What should we do with the AVFMT_FLAG_AUTO_BSF flag? Do we deprecate
> it and force the automatic insertion of muxer-required bitstream
> filters now that the generic muxing code will always behave the same,
> or keep it to give the user a choice to apply said bitstream filters?
> I ask because some filters, like vp9_superframe, are necessary to
> avoid creating broken files, so it's not wise to allow the user to
> disable it.
> It would also go in line with AVCodec.bsfs, which is essentially a
> non-optional (for reasons made obvious in fa1749dd34) autobsf at the
> codec level instead of container level.
> 
> The change to fate-rgb24-mkv is a regression that can be prevented by
> committing https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211311.html
> or a similar solution, maybe using avformat_init_output(), to make sure
> ffmpeg.c sets AVCodecParameters->field_order for the output stream before
> calling avformat_write_header().
> 

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

Re: [FFmpeg-devel] [PATCH] flvdec: Check the avio_seek return value after reading a metadata packet

[Steven Liu]

2017-09-06 0:38 GMT+08:00 Steven Liu :
> COPY FROM libav Martin Storsjö 
>
> If the metadata packet is corrupted, flv_read_metabody can accidentally
> read past the start of the next packet. If the start of the next packet
> had been flushed out of the IO buffer, we would be unable to seek to
> the right position (on a nonseekable stream).
>
> Prefer to clearly error out instead of silently trying to read from a
> desynced stream which will only be interpreted as garbage.
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/flvdec.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 2e70352c53..2d89bef15f 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -1015,7 +1015,13 @@ retry:
> "Skipping flv packet: type %d, size %d, flags %d.\n",
> type, size, flags);
>  skip:
> -avio_seek(s->pb, next, SEEK_SET);
> +if (avio_seek(s->pb, next, SEEK_SET) != next) {
> + // This can happen if flv_read_metabody above read past
> + // next, on a non-seekable input, and the preceding data has
> + // been flushed out from the IO buffer.
> + av_log(s, AV_LOG_ERROR, "Unable to seek to the next 
> packet\n");
> + return AVERROR_INVALIDDATA;
> +}
>  ret = FFERROR_REDO;
>  goto leave;
>  }
> --
> 2.11.0 (Apple Git-81)
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/fitsdec: write output to frame directly

[James Almer]

On 9/2/2017 4:07 PM, Paras Chadha wrote:
> Signed-off-by: Paras Chadha 
> ---
> This fixes the failed fate tests on mingw32:
> http://fate.ffmpeg.org/report.cgi?time=20170902182311&slot=x86_32-mingw-w64-dll-windows-native
> 
>  libavcodec/fitsdec.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/fitsdec.c b/libavcodec/fitsdec.c
> index 616a837..ec15248 100644
> --- a/libavcodec/fitsdec.c
> +++ b/libavcodec/fitsdec.c
> @@ -264,11 +264,10 @@ static int fits_decode_frame(AVCodecContext *avctx, 
> void *data, int *got_frame,
>  for (j = 0; j < avctx->width; j++) { \
>  t = rd; \
>  if (!header.blank_found || t != header.blank) { \
> -t = ((t - header.data_min) * ((1 << (sizeof(type) * 8)) 
> - 1)) / (header.data_max - header.data_min); \
> +*dst++ = ((t - header.data_min) * ((1 << (sizeof(type) * 
> 8)) - 1)) / (header.data_max - header.data_min); \
>  } else { \
> -t = fitsctx->blank_val; \
> +*dst++ = fitsctx->blank_val; \
>  } \
> -*dst++ = (type) t; \
>  ptr8 += abs(cas) >> 3; \
>  } \
>  } \
> --
> 2.4.11

Pushed, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_tonemap: don't use NAN constant as an initializer

[James Almer]

Netbsd:
src/libavfilter/vf_tonemap.c:314: error: initializer element is not constant
src/libavfilter/vf_tonemap.c:314: error: (near initialization for 
'tonemap_options[8].default_val.dbl')

DJGPP
src/libavfilter/vf_tonemap.c:314:87: error: initializer element is not constant
 { "param","tonemap parameter", OFFSET(param), AV_OPT_TYPE_DOUBLE, 
{.dbl = NAN}, DBL_MIN, DBL_MAX, FLAGS },

   ^
src/libavfilter/vf_tonemap.c:314:87: note: (near initialization for 
'tonemap_options[8].default_val.dbl')

Signed-off-by: James Almer 
---
 libavfilter/vf_tonemap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_tonemap.c b/libavfilter/vf_tonemap.c
index 10308bdb16..d2c7ffa831 100644
--- a/libavfilter/vf_tonemap.c
+++ b/libavfilter/vf_tonemap.c
@@ -311,7 +311,7 @@ static const AVOption tonemap_options[] = {
 { "reinhard", 0, 0, AV_OPT_TYPE_CONST, {.i64 = TONEMAP_REINHARD},  
0, 0, FLAGS, "tonemap" },
 { "hable",0, 0, AV_OPT_TYPE_CONST, {.i64 = TONEMAP_HABLE}, 
0, 0, FLAGS, "tonemap" },
 { "mobius",   0, 0, AV_OPT_TYPE_CONST, {.i64 = TONEMAP_MOBIUS},
0, 0, FLAGS, "tonemap" },
-{ "param","tonemap parameter", OFFSET(param), AV_OPT_TYPE_DOUBLE, 
{.dbl = NAN}, DBL_MIN, DBL_MAX, FLAGS },
+{ "param","tonemap parameter", OFFSET(param), AV_OPT_TYPE_DOUBLE, 
{.dbl = nan("")}, DBL_MIN, DBL_MAX, FLAGS },
 { "desat","desaturation strength", OFFSET(desat), 
AV_OPT_TYPE_DOUBLE, {.dbl = 2}, 0, DBL_MAX, FLAGS },
 { "peak", "signal peak override", OFFSET(peak), 
AV_OPT_TYPE_DOUBLE, {.dbl = 0}, 0, DBL_MAX, FLAGS },
 { NULL }
-- 
2.13.3

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

Re: [FFmpeg-devel] [PATCH] RFC: drop VDA

[James Almer]

On 9/5/2017 10:57 AM, Clément Bœsch wrote:
> From: Clément Bœsch 
> 
> I'm reworking the Apple Framework dependencies in the build system, and
> unfortunately I can't test VDA (because OSX doesn't have it anymore).
> I'll either break it badly without being able to fix it, or won't be
> able to do any the rework in the build system.
> ---
>  MAINTAINERS |   1 -
>  Makefile|   3 -
>  configure   |  15 +-
>  ffmpeg.h|   2 -
>  ffmpeg_opt.c|   6 +-
>  ffmpeg_videotoolbox.c   |  45 +--
>  libavcodec/Makefile |   7 +-
>  libavcodec/allcodecs.c  |   3 -
>  libavcodec/h264_slice.c |   5 -
>  libavcodec/vda.c|  84 -
>  libavcodec/vda.h| 230 -
>  libavcodec/vda_h264.c   | 425 
> 
>  libavcodec/vda_h264_dec.c   | 263 ---
>  libavcodec/videotoolbox.c   |  10 +-
>  libavcodec/{vda_vt_internal.h => vt_internal.h} |  15 +-
>  libavutil/pixdesc.c |  10 -
>  libavutil/pixfmt.h  |   4 +-
>  17 files changed, 15 insertions(+), 1113 deletions(-)
>  delete mode 100644 libavcodec/vda.c
>  delete mode 100644 libavcodec/vda.h
>  delete mode 100644 libavcodec/vda_h264.c
>  delete mode 100644 libavcodec/vda_h264_dec.c
>  rename libavcodec/{vda_vt_internal.h => vt_internal.h} (81%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8a6ac9840f..7c34912ee6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -244,7 +244,6 @@ Codecs:
>txd.c Ivo van Poorten
>vc2*  Rostislav Pehlivanov
>vcr1.cMichael Niedermayer
> -  vda_h264_dec.cXidorn Quan

https://ffmpeg.org/pipermail/ffmpeg-devel/2015-April/171118.html

You could CC him to see if he still cares about this code, but judging
by that email (second to last he's ever sent), I'd say this patch can go
in as it's pretty much a superfluous feature now that Videotoolbox exists.

>videotoolboxenc.c Rick Kern
>vima.cPaul B Mahol
>vorbisdec.c   Denes Balatoni, David Conrad

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