Re: [FFmpeg-devel] [PATCH] ffprobe: move abort() call to after the print statements

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 5:14 AM, Michael Niedermayer
 wrote:
> On Wed, Oct 28, 2015 at 09:55:56AM +0100, wm4 wrote:
>> On Tue, 27 Oct 2015 20:21:11 -0400
>> Ganesh Ajjanagadde  wrote:
>>
>> > This fixes warning C4702 "unreachable code" reported in MSVC:
>> > http://fate.ffmpeg.org/log.cgi?time=20151026165907=compile=x86_64-msvc12-windows-native,
>> > and also likely fixes the intended behavior.
>> >
>> > Signed-off-by: Ganesh Ajjanagadde 
>> > ---
>> >  ffprobe.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/ffprobe.c b/ffprobe.c
>> > index 02e2c48..0374cd9 100644
>> > --- a/ffprobe.c
>> > +++ b/ffprobe.c
>> > @@ -1890,9 +1890,9 @@ static void show_frame(WriterContext *w, AVFrame 
>> > *frame, AVStream *stream,
>> >  print_str("side_data_type", name ? name : "unknown");
>> >  print_int("side_data_size", sd->size);
>> >  if (sd->type == AV_FRAME_DATA_DISPLAYMATRIX && sd->size >= 
>> > 9*4) {
>> > -abort();
>> >  writer_print_integers(w, "displaymatrix", sd->data, 9, " 
>> > %11d", 3, 4, 1);
>> >  print_int("rotation", av_display_rotation_get((int32_t 
>> > *)sd->data));
>> > +abort();
>> >  }
>> >  writer_print_section_footer(w);
>> >  }
>>
>> Why the heck is there an abort()?
>
> It looks like mistake (used for testing/debuging), ill remove it
>
> Thanks

goes without saying, but patch dropped since abort has been removed.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
>
> ___
> 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] [PATCHv2] all: fix enum definition for large values

[Ronald S. Bultje]

Hi,

On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde  wrote:

> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> ISO C restricts enumerator values to the range of int. Thus (for
> instance)
> >> 0x8000
> >> unfortunately does not work, and throws a warning with -Wpedantic on
> >> clang 3.7.
> >>
> >> This fixes it by using alternative expressions that result in identical
> >> values but do not have this issue.
> >>
> >> Tested with FATE.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavcodec/dca_syncwords.h | 26 --
> >>  libavformat/cinedec.c  |  2 +-
> >>  libavformat/mov_chan.c |  2 +-
> >>  3 files changed, 14 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
> >> index 3466b6b..6981cb8 100644
> >> --- a/libavcodec/dca_syncwords.h
> >> +++ b/libavcodec/dca_syncwords.h
> >> @@ -19,19 +19,17 @@
> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
> >>  #define AVCODEC_DCA_SYNCWORDS_H
> >>
> >> -enum DCASyncwords {
> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
> >> -};
> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
> >
> >
> > This one is fine.
> >
> >>
> >> --- a/libavformat/cinedec.c
> >> +++ b/libavformat/cinedec.c
> >> @@ -50,7 +50,7 @@ enum {
> >>  CFA_BAYER = 3,  /**< GB/RG */
> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
> >>
> >> -CFA_TLGRAY= 0x8000,
> >> +CFA_TLGRAY= INT32_MIN,
> >>  CFA_TRGRAY= 0x4000,
> >>  CFA_BLGRAY= 0x2000,
> >>  CFA_BRGRAY= 0x1000
> >> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
> >> index a2fa8d6..f6181e2 100644
> >> --- a/libavformat/mov_chan.c
> >> +++ b/libavformat/mov_chan.c
> >> @@ -45,7 +45,7 @@
> >>   *do not specify a particular ordering of those channels."
> >>   */
> >>  enum MovChannelLayoutTag {
> >> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
> >> +MOV_CH_LAYOUT_UNKNOWN   = -( 1 << 16),
> >>  MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
> >>  MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
> >>  MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,
> >> --
> >> 2.6.2
> >
> >
> > I personally don't really like these... I think both obfuscate the
> meaning
> > of the flag values, particularly the first one.
>
> There is no real solution (recall apedec and the INT32_MIN final
> solution), barring adding a comment signifying our intent (ie the
> desired hex mask). I can do this if you think it helps.


The solution is to not care about ISO C if it doesn't fix real issues. :)

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

Re: [FFmpeg-devel] [PATCH] avutil/avstring: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 3:41 AM, Hendrik Leppkes  wrote:
> On Wed, Oct 28, 2015 at 4:17 AM, Ganesh Ajjanagadde
>  wrote:
>> On Thu, Oct 15, 2015 at 6:05 PM, Ganesh Ajjanagadde
>>  wrote:
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/avstring.h | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/libavutil/avstring.h b/libavutil/avstring.h
>>> index a306e89..a46d012 100644
>>> --- a/libavutil/avstring.h
>>> +++ b/libavutil/avstring.h
>>> @@ -339,6 +339,7 @@ enum AVEscapeMode {
>>>   * @return the length of the allocated string, or a negative error code in 
>>> case of error
>>>   * @see av_bprint_escape()
>>>   */
>>> +av_warn_unused_result
>>>  int av_escape(char **dst, const char *src, const char *special_chars,
>>>enum AVEscapeMode mode, int flags);
>>>
>>> @@ -378,6 +379,7 @@ int av_escape(char **dst, const char *src, const char 
>>> *special_chars,
>>>   * @return >= 0 in case a sequence was successfully read, a negative
>>>   * value in case of invalid sequence
>>>   */
>>> +av_warn_unused_result
>>>  int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t 
>>> *buf_end,
>>> unsigned int flags);
>>>
>>> --
>>> 2.6.1
>>>
>>
>> In the absence of any comments on this (or other avutil patches, in
>> spite of the general ping), the lack of a maintainer in MAINTAINERS,
>> and the inactivity/absence of a significant fraction of the people
>> listed by a git blame on this file, I took point 12 of the official
>> development policy and pushed the change.
>>
>> Please take this as a call to review the others if interested by this
>> weekend, else will begin pushing others at my discretion keeping the
>> development policy in view.
>
> Common practice in such a case is to at least ping a change that went
> without review once, just in case it was missed on the ML on a busy
> day.

I did do a general ping for the avutil stuff (on one of the other
patches), no response whatsoever. Unless you like a ping on ~20
messages in your inbox (perfectly fine with me), I thought pinging one
of them was sufficient.

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

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
>  wrote:
>>
>> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
>> > 
>> > wrote:
>> >>
>> >> ISO C restricts enumerator values to the range of int. Thus (for
>> >> instance)
>> >> 0x8000
>> >> unfortunately does not work, and throws a warning with -Wpedantic on
>> >> clang 3.7.
>> >>
>> >> This fixes it by using alternative expressions that result in identical
>> >> values but do not have this issue.
>> >>
>> >> Tested with FATE.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavcodec/dca_syncwords.h | 26 --
>> >>  libavformat/cinedec.c  |  2 +-
>> >>  libavformat/mov_chan.c |  2 +-
>> >>  3 files changed, 14 insertions(+), 16 deletions(-)
>> >>
>> >> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
>> >> index 3466b6b..6981cb8 100644
>> >> --- a/libavcodec/dca_syncwords.h
>> >> +++ b/libavcodec/dca_syncwords.h
>> >> @@ -19,19 +19,17 @@
>> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>> >>  #define AVCODEC_DCA_SYNCWORDS_H
>> >>
>> >> -enum DCASyncwords {
>> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
>> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
>> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
>> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
>> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
>> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
>> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
>> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
>> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
>> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
>> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
>> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
>> >> -};
>> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
>> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
>> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
>> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
>> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
>> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
>> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
>> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
>> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
>> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
>> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
>> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
>> >
>> >
>> > This one is fine.
>> >
>> >>
>> >> --- a/libavformat/cinedec.c
>> >> +++ b/libavformat/cinedec.c
>> >> @@ -50,7 +50,7 @@ enum {
>> >>  CFA_BAYER = 3,  /**< GB/RG */
>> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
>> >>
>> >> -CFA_TLGRAY= 0x8000,
>> >> +CFA_TLGRAY= INT32_MIN,
>> >>  CFA_TRGRAY= 0x4000,
>> >>  CFA_BLGRAY= 0x2000,
>> >>  CFA_BRGRAY= 0x1000
>> >> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
>> >> index a2fa8d6..f6181e2 100644
>> >> --- a/libavformat/mov_chan.c
>> >> +++ b/libavformat/mov_chan.c
>> >> @@ -45,7 +45,7 @@
>> >>   *do not specify a particular ordering of those channels."
>> >>   */
>> >>  enum MovChannelLayoutTag {
>> >> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
>> >> +MOV_CH_LAYOUT_UNKNOWN   = -( 1 << 16),
>> >>  MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
>> >>  MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
>> >>  MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,
>> >> --
>> >> 2.6.2
>> >
>> >
>> > I personally don't really like these... I think both obfuscate the
>> > meaning
>> > of the flag values, particularly the first one.
>>
>> There is no real solution (recall apedec and the INT32_MIN final
>> solution), barring adding a comment signifying our intent (ie the
>> desired hex mask). I can do this if you think it helps.
>
>
> The solution is to not care about ISO C if it doesn't fix real issues. :)

This is where we will just have to agree to disagree, I consider this
issue "real enough" - it is a violation of the standard, and POSIX
says nothing contrariwise unlike the function pointer/data pointer
thing.

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

Re: [FFmpeg-devel] [PATCH 2/3] lavc/mjpegdec: honor skip_frame option

[Matthieu Bouron]

On Wed, Oct 28, 2015 at 02:57:14AM +0100, Michael Niedermayer wrote:
> On Tue, Oct 27, 2015 at 11:15:29PM +0100, Matthieu Bouron wrote:
> > On Sun, Oct 18, 2015 at 11:06:50AM +0200, Matthieu Bouron wrote:
> > [...]
> > > 
> > > Patch updated, the markers are now properly skipped (which also fixes a
> > > crash).
> > 
> > Patch updated. It fixes an issue with mjpeg streams (and in particular with
> > the fate sample ffmpeg-issue-897.avi) due to the EOI marker not handled when
> > skip_frame is set to AVDISCARD_ALL.
> > 
> > Matthieu
> 
> >  mjpegdec.c |   26 ++
> >  1 file changed, 26 insertions(+)
> > 36d41f1bded2f864394843c6a49d8cc24933688c  
> > 0002-lavc-mjpegdec-honor-skip_frame-option.patch
> > From 7325810d812c4182cd42946687a1f4abc04999d1 Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron 
> > Date: Fri, 9 Oct 2015 15:15:15 +0200
> > Subject: [PATCH 2/3] lavc/mjpegdec: honor skip_frame option
> > 
> > ---
> >  libavcodec/mjpegdec.c | 26 ++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > index 1a86b7b..b4ff83c 100644
> > --- a/libavcodec/mjpegdec.c
> > +++ b/libavcodec/mjpegdec.c
> > @@ -2038,6 +2038,22 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, 
> > void *data, int *got_frame,
> >  return AVERROR(ENOSYS);
> >  }
> >  
> > +if (avctx->skip_frame == AVDISCARD_ALL) {
> > +int i, found = 0;
> > +static const int start_codes[] = { SOF0,
> > +SOF1, SOF2, SOF3, SOF48, SOI, EOI };
> > +
> > +for (i = 0; i < FF_ARRAY_ELEMS(start_codes); i++) {
> > +if (start_code == start_codes[i]) {
> > +found = 1;
> > +break;
> > +}
> > +}
> > +if (!found) {
> > +goto skip;
> > +}
> > +}
> > +
> >  switch (start_code) {
> >  case SOI:
> >  s->restart_interval = 0;
> > @@ -2103,6 +2119,10 @@ eoi_parser:
> >  if (s->bottom_field == !s->interlace_polarity)
> >  break;
> >  }
> > +if (avctx->skip_frame == AVDISCARD_ALL) {
> > +s->got_picture = 0;
> 
> > +goto the_end;
> 
> this would jump to all kinds of post scale and convert code
> that should probably be skiped over just to be sure it doesnt run
> otherwise patch LGTM and seems not breaking anything i tested
>

Patch updated, the post processing part is now skipped. The SOS marker is
now handled properly so the scan counter is incremented.
The decoder will also still error out if there is a SOF marker but no SOS
markers.

Thanks for all the feedback.

Matthieu
>From 46a8815eb5764e1212e3b6b329fba9dfbeb9c352 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Fri, 9 Oct 2015 15:15:15 +0200
Subject: [PATCH 2/3] lavc/mjpegdec: honor skip_frame option

---
 libavcodec/mjpegdec.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1a86b7b..96a2b4a 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2038,6 +2038,22 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
 return AVERROR(ENOSYS);
 }
 
+if (avctx->skip_frame == AVDISCARD_ALL) {
+int i, found = 0;
+static const int start_codes[] = { SOF0,
+SOF1, SOF2, SOF3, SOF48, SOI, SOS, EOI };
+
+for (i = 0; i < FF_ARRAY_ELEMS(start_codes); i++) {
+if (start_code == start_codes[i]) {
+found = 1;
+break;
+}
+}
+if (!found) {
+goto skip;
+}
+}
+
 switch (start_code) {
 case SOI:
 s->restart_interval = 0;
@@ -2103,6 +2119,10 @@ eoi_parser:
 if (s->bottom_field == !s->interlace_polarity)
 break;
 }
+if (avctx->skip_frame == AVDISCARD_ALL) {
+s->got_picture = 0;
+goto the_end_no_picture;
+}
 if ((ret = av_frame_ref(frame, s->picture_ptr)) < 0)
 return ret;
 *got_frame = 1;
@@ -2126,6 +2146,9 @@ eoi_parser:
 goto the_end;
 case SOS:
 s->cur_scan++;
+if (avctx->skip_frame == AVDISCARD_ALL)
+break;
+
 if ((ret = ff_mjpeg_decode_sos(s, NULL, 0, NULL)) < 0 &&
 (avctx->err_recognition & AV_EF_EXPLODE))
 goto fail;
@@ -2148,6 +2171,7 @@ eoi_parser:
 break;
 }
 
+skip:
 /* eof process start code */
 buf_ptr += (get_bits_count(>gb) + 7) / 8;
 av_log(avctx, AV_LOG_DEBUG,
@@ -2158,6 +2182,7 @@ 

Re: [FFmpeg-devel] PATCH: gdigrab work for DPI in windows

[Matt Oliver]

On 5 October 2015 at 20:05, Matt Oliver  wrote:

> On 5 October 2015 at 19:29, Matt Oliver  wrote:
>
>> On 30 September 2015 at 02:48, wm4  wrote:
>>
>>> On Wed, 23 Sep 2015 12:04:43 -0600
>>> Roger Pack  wrote:
>>>
>>> > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001
>>> > From: rogerdpack 
>>> > Date: Wed, 23 Sep 2015 12:03:27 -0600
>>> > Subject: [PATCH] gdigrab: grab right desktop size if DPI in use, based
>>> on
>>> >  patch from Alexander Brotzge
>>> >
>>> > Signed-off-by: rogerdpack 
>>> > ---
>>> >  libavdevice/gdigrab.c | 44
>>> +---
>>> >  1 file changed, 29 insertions(+), 15 deletions(-)
>>> >
>>> > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
>>> > index 9a185d4..b0faf45 100644
>>> > --- a/libavdevice/gdigrab.c
>>> > +++ b/libavdevice/gdigrab.c
>>> > @@ -235,6 +235,9 @@ gdigrab_read_header(AVFormatContext *s1)
>>> >  AVStream   *st   = NULL;
>>> >
>>> >  int bpp;
>>> > +int vertres;
>>> > +int desktopvertres;
>>> > +float scale;
>>> >  RECT virtual_rect;
>>> >  RECT clip_rect;
>>> >  BITMAP bmp;
>>> > @@ -263,14 +266,34 @@ gdigrab_read_header(AVFormatContext *s1)
>>> >  goto error;
>>> >  }
>>> >
>>> > -if (hwnd) {
>>> > -GetClientRect(hwnd, _rect);
>>> > -} else {
>>> > +/* This will get the device context for the selected window, or if
>>> > + * none, the primary screen */
>>> > +source_hdc = GetDC(hwnd);
>>> > +if (!source_hdc) {
>>> > +WIN32_API_ERROR("Couldn't get window device context");
>>> > +ret = AVERROR(EIO);
>>> > +goto error;
>>> > +}
>>> > +bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
>>> > +
>>> > +scale = 1.0;
>>> > +if (hwnd == NULL) {
>>> > +  /* desktop -- get the right height and width for scaling DPI */
>>> > +  vertres = GetDeviceCaps(source_hdc, VERTRES);
>>> > +  desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
>>> > +  scale = (float) desktopvertres / (float) vertres;
>>> > +}
>>>
>>
>> This seems a little redundant as scale is only being set when hwnd is
>> null however in the below lines its then being used in the opposite
>> conditional. Since this checks for hwnd essentially being non null then
>> scale is always going to be the inital value of 1.
>>
>>
>>> > + if (hwnd) {
>>> > + GetClientRect(hwnd, _rect);
>>> > + virtual_rect.right = virtual_rect.right * scale;
>>> > + virtual_rect.bottom = virtual_rect.bottom * scale;
>>> > + } else {
>>> >  virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
>>> >  virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
>>> > -virtual_rect.right = virtual_rect.left +
>>> GetSystemMetrics(SM_CXVIRTUALSCREEN);
>>> > -virtual_rect.bottom = virtual_rect.top +
>>> GetSystemMetrics(SM_CYVIRTUALSCREEN);
>>> > -}
>>> > +virtual_rect.right = (virtual_rect.left +
>>> GetSystemMetrics(SM_CXVIRTUALSCREEN)) * scale;
>>> > +virtual_rect.bottom = (virtual_rect.top +
>>> GetSystemMetrics(SM_CYVIRTUALSCREEN)) * scale;
>>> > + }
>>>
>>
>> This if else could be combined with the above if as scale is only a value
>> different to 1 in the 'else' case. Also as wm4 said it would probably be
>> better to keep the scale factors as ints.
>>
>>
>>> >
>>> >  /* If no width or height set, use full screen/window area */
>>> >  if (!gdigrab->width || !gdigrab->height) {
>>> > @@ -299,15 +322,6 @@ gdigrab_read_header(AVFormatContext *s1)
>>> >  goto error;
>>> >  }
>>> >
>>> > -/* This will get the device context for the selected window, or if
>>> > - * none, the primary screen */
>>> > -source_hdc = GetDC(hwnd);
>>> > -if (!source_hdc) {
>>> > -WIN32_API_ERROR("Couldn't get window device context");
>>> > -ret = AVERROR(EIO);
>>> > -goto error;
>>> > -}
>>> > -bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
>>> >
>>> >  if (name) {
>>> >  av_log(s1, AV_LOG_INFO,
>>
>>
>> However I think the basic dpi scaling technique is correct. However I
>> would think it should be more along the lines of the modifications Ive
>> attached.
>>
>
> Woops, allow me to try that again without windows messing up the patches
> line endings.
>

Does anyone have any issues with the updated patch or can it be pushed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

[Bodecs Bela]

ping

2015.10.18. 14:06 keltezéssel, Bodecs Bela írta:

Dear Marton Balint,

see may comments below.

2015.10.18. 1:10 keltezéssel, Marton Balint írta:


On Thu, 15 Oct 2015, Bodecs Bela wrote:

[...]


My enhancement does not alter the current behaviour in any way.


Are you sure? What if somebody matched a semicolon, or a string 
which contained a semicolon in a metadata value? E.g.: 
m:timecode:00:00:00:00





yes, indeed.
This question still stands. Will the m:timecode:00:00:00:00 specifier 
work the same way as it did after your patch? I think it will not.


[...]

I do not understand this. My patch only gives an opportunity to use 
multiple specifiers in the same expression, it is not mandatory to 
use it. The patch does not affect any existing command line in any way.


I don't agree, I think your patch changes existing behaviour and the 
proposed syntax limits future extensibility.

ok.


I also accept your concern about the future, but double semicilon 
always will works for optional parameters. But may I ask: would it 
be better to introduce a "special character" for separating 
specifiers in the same expression?


IMHO yes. You also have to know from the start that you are dealing 
with a complex specifier, in order not to break existing simple 
specifiers.


I accept it if you suggest one. I only need the functionality to be 
able to give more criteria to select a stream as opposed to current 
oppurtunities. I am not stuck to my suggestion.
Anyway, You may see my enhancement as you get many optional 
parameters for the existing type, metadata and program_id 
specifiers. :)


It can be anything if it does not change existing behaviour, a 
complex specifier can be split to basic specifiers without worrying 
about the syntax of the basic specifier and if there is a well 
defined rule for escaping special characters. Also if it is readable 
to the user, that is a plus.


The exact solution can be a bit about personal taste as well, but 
maybe something like


(specifier)(specifier)

I like this version. So, there would be the original case: specifier, 
and if you want to use more specifier, you should put each of them 
into parenthesis (round brackets): (specifier)(specifier)

I think it really won't break any current code


or

+specifier+specifier

I think () is more readible and rarely used in specifiers.  If it is 
ok for you and others I would implement it.



can work and is readable. Knowing that you are dealing with a complex 
expression also means that the special characters separating the 
basic specifiers needs escaping, I guess av_get_token can be used to 
get the proper unescaped basic specifiers when parsing the complex one.


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


best regards,

bb

___
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/3] lavc/pngdec: honor skip_frame option

[Michael Niedermayer]

On Mon, Oct 19, 2015 at 10:28:18AM +0200, Matthieu Bouron wrote:
> On Sat, Oct 17, 2015 at 10:34:22PM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > ---
> >  libavcodec/pngdec.c | 34 ++
> >  1 file changed, 34 insertions(+)
> > 
> > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> > index 4cfdc58..5b2befe 100644
> > --- a/libavcodec/pngdec.c
> > +++ b/libavcodec/pngdec.c
> > @@ -1087,6 +1087,13 @@ static int decode_frame_common(AVCodecContext 
> > *avctx, PNGDecContext *s,
> >  for (;;) {
> >  length = bytestream2_get_bytes_left(>gb);
> >  if (length <= 0) {
> > +
> > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > +avctx->skip_frame == AVDISCARD_ALL) {
> > +av_frame_set_metadata(p, metadata);
> > +return 0;
> > +}
> > +
> >  if (CONFIG_APNG_DECODER && avctx->codec_id == AV_CODEC_ID_APNG 
> > && length == 0) {
> >  if (!(s->state & PNG_IDAT))
> >  return 0;
> > @@ -1114,6 +1121,22 @@ static int decode_frame_common(AVCodecContext 
> > *avctx, PNGDecContext *s,
> >  ((tag >> 8) & 0xff),
> >  ((tag >> 16) & 0xff),
> >  ((tag >> 24) & 0xff), length);
> > +
> > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > +avctx->skip_frame == AVDISCARD_ALL) {
> > +int i, found = 0;
> > +static const int tags[] = { MKTAG('I', 'H', 'D', 'R'), 
> > MKTAG('t', 'E', 'X', 't'), MKTAG('I', 'D', 'A', 'T') };
> > +for (i = 0; i < FF_ARRAY_ELEMS(tags); i++) {
> > +if (tag == tags[i]) {
> > +found = 1;
> > +break;
> > +}
> > +}
> > +if (!found) {
> > +goto skip_tag;
> > +}
> > +}
> > +
> >  switch (tag) {
> >  case MKTAG('I', 'H', 'D', 'R'):
> >  if ((ret = decode_ihdr_chunk(avctx, s, length)) < 0)
> > @@ -1181,6 +1204,11 @@ skip_tag:
> >  }
> >  }
> >  exit_loop:
> > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > +avctx->skip_frame == AVDISCARD_ALL) {
> > +av_frame_set_metadata(p, metadata);
> > +return 0;
> > +}
> >  
> >  if (s->bits_per_pixel <= 4)
> >  handle_small_bpp(s, p);
> > @@ -1278,6 +1306,12 @@ static int decode_frame_png(AVCodecContext *avctx,
> >  if ((ret = decode_frame_common(avctx, s, p, avpkt)) < 0)
> >  goto the_end;
> >  
> > +if (avctx->skip_frame == AVDISCARD_ALL) {
> > +*got_frame = 0;
> > +ret = bytestream2_tell(>gb);
> > +goto the_end;
> > +}
> > +
> >  if ((ret = av_frame_ref(data, s->picture.f)) < 0)
> >  return ret;
> >  
> > -- 
> > 2.6.1
> > 
> 
> Patch updated, the SAR is not discarded anymore.
> 
> Matthieu

>  pngdec.c |   39 +++
>  1 file changed, 39 insertions(+)
> eddfb042e2653025b37f9deacc0357ac3e5e5148  
> 0001-lavc-pngdec-honor-skip_frame-option.patch
> From ca6362457eb27e623eadcadb0e33a84ea461180f Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Fri, 9 Oct 2015 15:14:11 +0200
> Subject: [PATCH 1/3] lavc/pngdec: honor skip_frame option
> 
> ---
>  libavcodec/pngdec.c | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 4cfdc58..cb99dbe 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -1087,6 +1087,13 @@ static int decode_frame_common(AVCodecContext *avctx, 
> PNGDecContext *s,
>  for (;;) {
>  length = bytestream2_get_bytes_left(>gb);
>  if (length <= 0) {
> +
> +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> +avctx->skip_frame == AVDISCARD_ALL) {
> +av_frame_set_metadata(p, metadata);
> +return 0;
> +}
> +
>  if (CONFIG_APNG_DECODER && avctx->codec_id == AV_CODEC_ID_APNG 
> && length == 0) {
>  if (!(s->state & PNG_IDAT))
>  return 0;
> @@ -1114,6 +1121,27 @@ static int decode_frame_common(AVCodecContext *avctx, 
> PNGDecContext *s,
>  ((tag >> 8) & 0xff),
>  ((tag >> 16) & 0xff),
>  ((tag >> 24) & 0xff), length);
> +
> +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> +avctx->skip_frame == AVDISCARD_ALL) {

> +int i, found = 0;
> +static const int tags[] = {
> +MKTAG('I', 'H', 'D', 'R'),
> +MKTAG('p', 'H', 'Y', 's'),
> +MKTAG('t', 'E', 'X', 't'),
> +MKTAG('I', 'D', 'A', 'T'),
> +};
> +for (i = 0; i < FF_ARRAY_ELEMS(tags); i++) {
> +if (tag == tags[i]) {
> +found = 1;
> +  

Re: [FFmpeg-devel] [PATCH 2/3] lavc/mjpegdec: honor skip_frame option

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 02:57:14AM +0100, Michael Niedermayer wrote:
> On Tue, Oct 27, 2015 at 11:15:29PM +0100, Matthieu Bouron wrote:
> > On Sun, Oct 18, 2015 at 11:06:50AM +0200, Matthieu Bouron wrote:
> > [...]
> > > 
> > > Patch updated, the markers are now properly skipped (which also fixes a
> > > crash).
> > 
> > Patch updated. It fixes an issue with mjpeg streams (and in particular with
> > the fate sample ffmpeg-issue-897.avi) due to the EOI marker not handled when
> > skip_frame is set to AVDISCARD_ALL.
> > 
> > Matthieu
> 
> >  mjpegdec.c |   26 ++
> >  1 file changed, 26 insertions(+)
> > 36d41f1bded2f864394843c6a49d8cc24933688c  
> > 0002-lavc-mjpegdec-honor-skip_frame-option.patch
> > From 7325810d812c4182cd42946687a1f4abc04999d1 Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron 
> > Date: Fri, 9 Oct 2015 15:15:15 +0200
> > Subject: [PATCH 2/3] lavc/mjpegdec: honor skip_frame option
> > 
> > ---
> >  libavcodec/mjpegdec.c | 26 ++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > index 1a86b7b..b4ff83c 100644
> > --- a/libavcodec/mjpegdec.c
> > +++ b/libavcodec/mjpegdec.c
> > @@ -2038,6 +2038,22 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, 
> > void *data, int *got_frame,
> >  return AVERROR(ENOSYS);
> >  }
> >  
> > +if (avctx->skip_frame == AVDISCARD_ALL) {
> > +int i, found = 0;
> > +static const int start_codes[] = { SOF0,
> > +SOF1, SOF2, SOF3, SOF48, SOI, EOI };
> > +
> > +for (i = 0; i < FF_ARRAY_ELEMS(start_codes); i++) {
> > +if (start_code == start_codes[i]) {
> > +found = 1;
> > +break;
> > +}
> > +}
> > +if (!found) {
> > +goto skip;
> > +}

i think this would be simpler and shorter if implemented as a
switch(start_code)/case

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH 1/8] lavu/aes: test CBC functionality

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 05:39:32AM -0500, Rodger Combs wrote:
> ---
>  libavutil/aes.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)

LGTM

thx

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] [PATCH] avutil/mathematics: correct documentation for av_gcd

[Ganesh Ajjanagadde]

On Tue, Oct 27, 2015 at 8:18 PM, Ganesh Ajjanagadde
 wrote:
> av_gcd is now always defined regardless of input. This documents this
> change in the "documented API". Two benefits (closely related):
> 1. The function is robust, and there is no need to worry about INT64_MIN, etc.
>
> 2. Clients of av_gcd, like av_reduce, can now be made fully correct. 
> Currently,
> av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to
> integer overflow in the FFABS. Furthermore, this undefined behavior is
> completely undocumented, and could be a fuzzer's paradise. The FFABS was 
> needed in the past as
> av_gcd was undefined for negative inputs. In order to make av_reduce
> robust, it is essential to guarantee that av_gcd works for all int64_t.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/mathematics.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h
> index ac94488..6fc2577 100644
> --- a/libavutil/mathematics.h
> +++ b/libavutil/mathematics.h
> @@ -77,9 +77,9 @@ enum AVRounding {
>  };
>
>  /**
> - * Return the greatest common divisor of a and b.
> - * If both a and b are 0 or either or both are <0 then behavior is
> - * undefined.
> + * Compute the greatest common divisor of a and b.
> + *
> + * @return gcd of a and b up to sign; if a and b are both zero returns 0
>   */
>  int64_t av_const av_gcd(int64_t a, int64_t b);
>
> --
> 2.6.2
>

Patch dropped for now, undefined behavior is still possible with
av_gcd: take a and b to be both INT64_MIN. Need to examine this a
little more closely to make it robust without losing performance.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc/mjpegdec: honor skip_frame option

[Matthieu Bouron]

On Wed, Oct 28, 2015 at 12:58:53PM +0100, Michael Niedermayer wrote:
> On Wed, Oct 28, 2015 at 02:57:14AM +0100, Michael Niedermayer wrote:
> > On Tue, Oct 27, 2015 at 11:15:29PM +0100, Matthieu Bouron wrote:
> > > On Sun, Oct 18, 2015 at 11:06:50AM +0200, Matthieu Bouron wrote:
> > > [...]
> > > > 
> > > > Patch updated, the markers are now properly skipped (which also fixes a
> > > > crash).
> > > 
> > > Patch updated. It fixes an issue with mjpeg streams (and in particular 
> > > with
> > > the fate sample ffmpeg-issue-897.avi) due to the EOI marker not handled 
> > > when
> > > skip_frame is set to AVDISCARD_ALL.
> > > 
> > > Matthieu
> > 
> > >  mjpegdec.c |   26 ++
> > >  1 file changed, 26 insertions(+)
> > > 36d41f1bded2f864394843c6a49d8cc24933688c  
> > > 0002-lavc-mjpegdec-honor-skip_frame-option.patch
> > > From 7325810d812c4182cd42946687a1f4abc04999d1 Mon Sep 17 00:00:00 2001
> > > From: Matthieu Bouron 
> > > Date: Fri, 9 Oct 2015 15:15:15 +0200
> > > Subject: [PATCH 2/3] lavc/mjpegdec: honor skip_frame option
> > > 
> > > ---
> > >  libavcodec/mjpegdec.c | 26 ++
> > >  1 file changed, 26 insertions(+)
> > > 
> > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > > index 1a86b7b..b4ff83c 100644
> > > --- a/libavcodec/mjpegdec.c
> > > +++ b/libavcodec/mjpegdec.c
> > > @@ -2038,6 +2038,22 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, 
> > > void *data, int *got_frame,
> > >  return AVERROR(ENOSYS);
> > >  }
> > >  
> > > +if (avctx->skip_frame == AVDISCARD_ALL) {
> > > +int i, found = 0;
> > > +static const int start_codes[] = { SOF0,
> > > +SOF1, SOF2, SOF3, SOF48, SOI, EOI };
> > > +
> > > +for (i = 0; i < FF_ARRAY_ELEMS(start_codes); i++) {
> > > +if (start_code == start_codes[i]) {
> > > +found = 1;
> > > +break;
> > > +}
> > > +}
> > > +if (!found) {
> > > +goto skip;
> > > +}
> 
> i think this would be simpler and shorter if implemented as a
> switch(start_code)/case
> 

Patch updated using a switch/case to implement the skip logic.

[...]
>From cb09375d6cf5051ce51e43a2787f0242bd6450bc Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Fri, 9 Oct 2015 15:15:15 +0200
Subject: [PATCH 2/3] lavc/mjpegdec: honor skip_frame option

---
 libavcodec/mjpegdec.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1a86b7b..e17b213 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2038,6 +2038,22 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
 return AVERROR(ENOSYS);
 }
 
+if (avctx->skip_frame == AVDISCARD_ALL) {
+switch(start_code) {
+case SOF0:
+case SOF1:
+case SOF2:
+case SOF3:
+case SOF48:
+case SOI:
+case SOS:
+case EOI:
+break;
+default:
+goto skip;
+}
+}
+
 switch (start_code) {
 case SOI:
 s->restart_interval = 0;
@@ -2103,6 +2119,10 @@ eoi_parser:
 if (s->bottom_field == !s->interlace_polarity)
 break;
 }
+if (avctx->skip_frame == AVDISCARD_ALL) {
+s->got_picture = 0;
+goto the_end_no_picture;
+}
 if ((ret = av_frame_ref(frame, s->picture_ptr)) < 0)
 return ret;
 *got_frame = 1;
@@ -2126,6 +2146,9 @@ eoi_parser:
 goto the_end;
 case SOS:
 s->cur_scan++;
+if (avctx->skip_frame == AVDISCARD_ALL)
+break;
+
 if ((ret = ff_mjpeg_decode_sos(s, NULL, 0, NULL)) < 0 &&
 (avctx->err_recognition & AV_EF_EXPLODE))
 goto fail;
@@ -2148,6 +2171,7 @@ eoi_parser:
 break;
 }
 
+skip:
 /* eof process start code */
 buf_ptr += (get_bits_count(>gb) + 7) / 8;
 av_log(avctx, AV_LOG_DEBUG,
@@ -2344,6 +2368,7 @@ the_end:
 av_dict_copy(avpriv_frame_get_metadatap(data), s->exif_metadata, 0);
 av_dict_free(>exif_metadata);
 
+the_end_no_picture:
 av_log(avctx, AV_LOG_DEBUG, "decode frame unused %"PTRDIFF_SPECIFIER" bytes\n",
buf_end - buf_ptr);
 //  return buf_end - buf_ptr;
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH 4/8] tools/crypto_bench: add AES-192 and AES-256

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 05:39:35AM -0500, Rodger Combs wrote:
> ---
>  tools/crypto_bench.c | 82 
> 
>  1 file changed, 82 insertions(+)
> 
> diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
> index b3b24a6..ad20f95 100644
> --- a/tools/crypto_bench.c
> +++ b/tools/crypto_bench.c
> @@ -118,6 +118,24 @@ static void run_lavu_aes128(uint8_t *output,

should be ok

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde 
> wrote:
>>
>> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
>> >  wrote:
>> >>
>> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> ISO C restricts enumerator values to the range of int. Thus (for
>> >> >> instance)
>> >> >> 0x8000
>> >> >> unfortunately does not work, and throws a warning with -Wpedantic on
>> >> >> clang 3.7.
>> >> >>
>> >> >> This fixes it by using alternative expressions that result in
>> >> >> identical
>> >> >> values but do not have this issue.
>> >> >>
>> >> >> Tested with FATE.
>> >> >>
>> >> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> >> ---
>> >> >>  libavcodec/dca_syncwords.h | 26 --
>> >> >>  libavformat/cinedec.c  |  2 +-
>> >> >>  libavformat/mov_chan.c |  2 +-
>> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
>> >> >>
>> >> >> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
>> >> >> index 3466b6b..6981cb8 100644
>> >> >> --- a/libavcodec/dca_syncwords.h
>> >> >> +++ b/libavcodec/dca_syncwords.h
>> >> >> @@ -19,19 +19,17 @@
>> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
>> >> >>
>> >> >> -enum DCASyncwords {
>> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
>> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
>> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
>> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
>> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
>> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
>> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
>> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
>> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
>> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
>> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
>> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
>> >> >> -};
>> >> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
>> >> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
>> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
>> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
>> >> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
>> >> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
>> >> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
>> >> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
>> >> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
>> >> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
>> >> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
>> >> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
>> >> >
>> >> >
>> >> > This one is fine.
>> >> >
>> >> >>
>> >> >> --- a/libavformat/cinedec.c
>> >> >> +++ b/libavformat/cinedec.c
>> >> >> @@ -50,7 +50,7 @@ enum {
>> >> >>  CFA_BAYER = 3,  /**< GB/RG */
>> >> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
>> >> >>
>> >> >> -CFA_TLGRAY= 0x8000,
>> >> >> +CFA_TLGRAY= INT32_MIN,
>> >> >>  CFA_TRGRAY= 0x4000,
>> >> >>  CFA_BLGRAY= 0x2000,
>> >> >>  CFA_BRGRAY= 0x1000
>> >> >> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
>> >> >> index a2fa8d6..f6181e2 100644
>> >> >> --- a/libavformat/mov_chan.c
>> >> >> +++ b/libavformat/mov_chan.c
>> >> >> @@ -45,7 +45,7 @@
>> >> >>   *do not specify a particular ordering of those
>> >> >> channels."
>> >> >>   */
>> >> >>  enum MovChannelLayoutTag {
>> >> >> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
>> >> >> +MOV_CH_LAYOUT_UNKNOWN   = -( 1 << 16),
>> >> >>  MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
>> >> >>  MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
>> >> >>  MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,
>> >> >> --
>> >> >> 2.6.2
>> >> >
>> >> >
>> >> > I personally don't really like these... I think both obfuscate the
>> >> > meaning
>> >> > of the flag values, particularly the first one.
>> >>
>> >> There is no real solution (recall apedec and the INT32_MIN final
>> >> solution), barring adding a comment signifying our intent (ie the
>> >> desired hex mask). I can do this if you think it helps.
>> >
>> >
>> > The solution is to not care about ISO C if it doesn't fix real issues.
>> > :)
>>
>> This is where we will just have to agree to disagree, I consider this
>> issue "real enough" - it is a violation of the standard, and POSIX
>> says nothing 

Re: [FFmpeg-devel] [PATCH 1/3] lavc/pngdec: honor skip_frame option

[Matthieu Bouron]

On Wed, Oct 28, 2015 at 12:59:54PM +0100, Michael Niedermayer wrote:
> On Mon, Oct 19, 2015 at 10:28:18AM +0200, Matthieu Bouron wrote:
> > On Sat, Oct 17, 2015 at 10:34:22PM +0200, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > > 
> > > ---
> > >  libavcodec/pngdec.c | 34 ++
> > >  1 file changed, 34 insertions(+)
> > > 
> > > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> > > index 4cfdc58..5b2befe 100644
> > > --- a/libavcodec/pngdec.c
> > > +++ b/libavcodec/pngdec.c
> > > @@ -1087,6 +1087,13 @@ static int decode_frame_common(AVCodecContext 
> > > *avctx, PNGDecContext *s,
> > >  for (;;) {
> > >  length = bytestream2_get_bytes_left(>gb);
> > >  if (length <= 0) {
> > > +
> > > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > > +avctx->skip_frame == AVDISCARD_ALL) {
> > > +av_frame_set_metadata(p, metadata);
> > > +return 0;
> > > +}
> > > +
> > >  if (CONFIG_APNG_DECODER && avctx->codec_id == 
> > > AV_CODEC_ID_APNG && length == 0) {
> > >  if (!(s->state & PNG_IDAT))
> > >  return 0;
> > > @@ -1114,6 +1121,22 @@ static int decode_frame_common(AVCodecContext 
> > > *avctx, PNGDecContext *s,
> > >  ((tag >> 8) & 0xff),
> > >  ((tag >> 16) & 0xff),
> > >  ((tag >> 24) & 0xff), length);
> > > +
> > > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > > +avctx->skip_frame == AVDISCARD_ALL) {
> > > +int i, found = 0;
> > > +static const int tags[] = { MKTAG('I', 'H', 'D', 'R'), 
> > > MKTAG('t', 'E', 'X', 't'), MKTAG('I', 'D', 'A', 'T') };
> > > +for (i = 0; i < FF_ARRAY_ELEMS(tags); i++) {
> > > +if (tag == tags[i]) {
> > > +found = 1;
> > > +break;
> > > +}
> > > +}
> > > +if (!found) {
> > > +goto skip_tag;
> > > +}
> > > +}
> > > +
> > >  switch (tag) {
> > >  case MKTAG('I', 'H', 'D', 'R'):
> > >  if ((ret = decode_ihdr_chunk(avctx, s, length)) < 0)
> > > @@ -1181,6 +1204,11 @@ skip_tag:
> > >  }
> > >  }
> > >  exit_loop:
> > > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > > +avctx->skip_frame == AVDISCARD_ALL) {
> > > +av_frame_set_metadata(p, metadata);
> > > +return 0;
> > > +}
> > >  
> > >  if (s->bits_per_pixel <= 4)
> > >  handle_small_bpp(s, p);
> > > @@ -1278,6 +1306,12 @@ static int decode_frame_png(AVCodecContext *avctx,
> > >  if ((ret = decode_frame_common(avctx, s, p, avpkt)) < 0)
> > >  goto the_end;
> > >  
> > > +if (avctx->skip_frame == AVDISCARD_ALL) {
> > > +*got_frame = 0;
> > > +ret = bytestream2_tell(>gb);
> > > +goto the_end;
> > > +}
> > > +
> > >  if ((ret = av_frame_ref(data, s->picture.f)) < 0)
> > >  return ret;
> > >  
> > > -- 
> > > 2.6.1
> > > 
> > 
> > Patch updated, the SAR is not discarded anymore.
> > 
> > Matthieu
> 
> >  pngdec.c |   39 +++
> >  1 file changed, 39 insertions(+)
> > eddfb042e2653025b37f9deacc0357ac3e5e5148  
> > 0001-lavc-pngdec-honor-skip_frame-option.patch
> > From ca6362457eb27e623eadcadb0e33a84ea461180f Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron 
> > Date: Fri, 9 Oct 2015 15:14:11 +0200
> > Subject: [PATCH 1/3] lavc/pngdec: honor skip_frame option
> > 
> > ---
> >  libavcodec/pngdec.c | 39 +++
> >  1 file changed, 39 insertions(+)
> > 
> > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> > index 4cfdc58..cb99dbe 100644
> > --- a/libavcodec/pngdec.c
> > +++ b/libavcodec/pngdec.c
> > @@ -1087,6 +1087,13 @@ static int decode_frame_common(AVCodecContext 
> > *avctx, PNGDecContext *s,
> >  for (;;) {
> >  length = bytestream2_get_bytes_left(>gb);
> >  if (length <= 0) {
> > +
> > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > +avctx->skip_frame == AVDISCARD_ALL) {
> > +av_frame_set_metadata(p, metadata);
> > +return 0;
> > +}
> > +
> >  if (CONFIG_APNG_DECODER && avctx->codec_id == AV_CODEC_ID_APNG 
> > && length == 0) {
> >  if (!(s->state & PNG_IDAT))
> >  return 0;
> > @@ -1114,6 +1121,27 @@ static int decode_frame_common(AVCodecContext 
> > *avctx, PNGDecContext *s,
> >  ((tag >> 8) & 0xff),
> >  ((tag >> 16) & 0xff),
> >  ((tag >> 24) & 0xff), length);
> > +
> > +if (avctx->codec_id == AV_CODEC_ID_PNG &&
> > +avctx->skip_frame == AVDISCARD_ALL) {
> 
> > +int i, found = 0;
> > +static const int tags[] = {
> > +

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ronald S. Bultje]

Hi,

On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde  wrote:

> On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
> >> >  wrote:
> >> >>
> >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje <
> rsbul...@gmail.com>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> ISO C restricts enumerator values to the range of int. Thus (for
> >> >> >> instance)
> >> >> >> 0x8000
> >> >> >> unfortunately does not work, and throws a warning with -Wpedantic
> on
> >> >> >> clang 3.7.
> >> >> >>
> >> >> >> This fixes it by using alternative expressions that result in
> >> >> >> identical
> >> >> >> values but do not have this issue.
> >> >> >>
> >> >> >> Tested with FATE.
> >> >> >>
> >> >> >> Signed-off-by: Ganesh Ajjanagadde 
> >> >> >> ---
> >> >> >>  libavcodec/dca_syncwords.h | 26 --
> >> >> >>  libavformat/cinedec.c  |  2 +-
> >> >> >>  libavformat/mov_chan.c |  2 +-
> >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
> >> >> >>
> >> >> >> diff --git a/libavcodec/dca_syncwords.h
> b/libavcodec/dca_syncwords.h
> >> >> >> index 3466b6b..6981cb8 100644
> >> >> >> --- a/libavcodec/dca_syncwords.h
> >> >> >> +++ b/libavcodec/dca_syncwords.h
> >> >> >> @@ -19,19 +19,17 @@
> >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
> >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
> >> >> >>
> >> >> >> -enum DCASyncwords {
> >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
> >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
> >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
> >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
> >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
> >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
> >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
> >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
> >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
> >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
> >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
> >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
> >> >> >> -};
> >> >> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
> >> >> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
> >> >> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
> >> >> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
> >> >> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
> >> >> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
> >> >> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
> >> >> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
> >> >> >
> >> >> >
> >> >> > This one is fine.
> >> >> >
> >> >> >>
> >> >> >> --- a/libavformat/cinedec.c
> >> >> >> +++ b/libavformat/cinedec.c
> >> >> >> @@ -50,7 +50,7 @@ enum {
> >> >> >>  CFA_BAYER = 3,  /**< GB/RG */
> >> >> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
> >> >> >>
> >> >> >> -CFA_TLGRAY= 0x8000,
> >> >> >> +CFA_TLGRAY= INT32_MIN,
> >> >> >>  CFA_TRGRAY= 0x4000,
> >> >> >>  CFA_BLGRAY= 0x2000,
> >> >> >>  CFA_BRGRAY= 0x1000
> >> >> >> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
> >> >> >> index a2fa8d6..f6181e2 100644
> >> >> >> --- a/libavformat/mov_chan.c
> >> >> >> +++ b/libavformat/mov_chan.c
> >> >> >> @@ -45,7 +45,7 @@
> >> >> >>   *do not specify a particular ordering of those
> >> >> >> channels."
> >> >> >>   */
> >> >> >>  enum MovChannelLayoutTag {
> >> >> >> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
> >> >> >> +MOV_CH_LAYOUT_UNKNOWN   = -( 1 << 16),
> >> >> >>  MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
> >> >> >>  MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
> >> >> >>  MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,
> >> >> >> --
> >> >> >> 2.6.2
> >> >> >
> >> >> >
> >> >> > I personally don't really like these... I think both obfuscate the
> >> >> > meaning
> >> >> > of the flag values, particularly the first one.
> >> >>
> >> >> There is no real solution (recall apedec and the INT32_MIN final
> >> >> solution), barring adding a comment signifying our 

Re: [FFmpeg-devel] [PATCH] avutil/avstring: add av_warn_unused_result

[Hendrik Leppkes]

On Wed, Oct 28, 2015 at 4:17 AM, Ganesh Ajjanagadde
 wrote:
> On Thu, Oct 15, 2015 at 6:05 PM, Ganesh Ajjanagadde
>  wrote:
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/avstring.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavutil/avstring.h b/libavutil/avstring.h
>> index a306e89..a46d012 100644
>> --- a/libavutil/avstring.h
>> +++ b/libavutil/avstring.h
>> @@ -339,6 +339,7 @@ enum AVEscapeMode {
>>   * @return the length of the allocated string, or a negative error code in 
>> case of error
>>   * @see av_bprint_escape()
>>   */
>> +av_warn_unused_result
>>  int av_escape(char **dst, const char *src, const char *special_chars,
>>enum AVEscapeMode mode, int flags);
>>
>> @@ -378,6 +379,7 @@ int av_escape(char **dst, const char *src, const char 
>> *special_chars,
>>   * @return >= 0 in case a sequence was successfully read, a negative
>>   * value in case of invalid sequence
>>   */
>> +av_warn_unused_result
>>  int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t 
>> *buf_end,
>> unsigned int flags);
>>
>> --
>> 2.6.1
>>
>
> In the absence of any comments on this (or other avutil patches, in
> spite of the general ping), the lack of a maintainer in MAINTAINERS,
> and the inactivity/absence of a significant fraction of the people
> listed by a git blame on this file, I took point 12 of the official
> development policy and pushed the change.
>
> Please take this as a call to review the others if interested by this
> weekend, else will begin pushing others at my discretion keeping the
> development policy in view.

Common practice in such a case is to at least ping a change that went
without review once, just in case it was missed on the ML on a busy
day.

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

[FFmpeg-devel] [PATCH] fix nvenc potential profile error when encoding yuv444p

[Agatha Hu]

---
 libavcodec/nvenc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 0e6ef43..083e494 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -912,6 +912,11 @@ static av_cold int nvenc_encode_init(AVCodecContext 
*avctx)

 goto error;
 }
 }
+// force setting profile as high444p if input is AV_PIX_FMT_YUV444P
+if (avctx->pix_fmt == AV_PIX_FMT_YUV444P) {
+ctx->encode_config.profileGUID = 
NV_ENC_H264_PROFILE_HIGH_444_GUID;

+avctx->profile = FF_PROFILE_H264_HIGH_444_PREDICTIVE;
+}


ctx->encode_config.encodeCodecConfig.h264Config.chromaFormatIDC = 
avctx->profile == FF_PROFILE_H264_HIGH_444_PREDICTIVE ? 3 : 1;


@@ -1452,7 +1457,7 @@ static const enum AVPixelFormat pix_fmts_nvenc[] = {
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
 { "preset", "Set the encoding preset (one of slow = hq 2pass, 
medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default)", 
OFFSET(preset), AV_OPT_TYPE_STRING, { .str = "hq" }, 0, 0, VE },
-{ "profile", "Set the encoding profile (high, main or baseline)", 
OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "profile", "Set the encoding profile (high, main, baseline or 
high444p)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
 { "level", "Set the encoding level restriction (auto, 1.0, 1.0b, 
1.1, 1.2, ..., 4.2, 5.0, 5.1)", OFFSET(level), AV_OPT_TYPE_STRING, { 0 
}, 0, 0, VE },
 { "tier", "Set the encoding tier (main or high)", OFFSET(tier), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
 { "cbr", "Use cbr encoding mode", OFFSET(cbr), AV_OPT_TYPE_BOOL, { 
.i64 = 0 }, 0, 1, VE },

--
1.9.5.github.0

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

[FFmpeg-devel] [PATCH] fix nvenc potential profile error when encoding yuv444p

[Agatha Hu]

---
 libavcodec/nvenc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 0e6ef43..083e494 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -912,6 +912,11 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 goto error;
 }
 }
+// force setting profile as high444p if input is AV_PIX_FMT_YUV444P
+if (avctx->pix_fmt == AV_PIX_FMT_YUV444P) {
+ctx->encode_config.profileGUID = NV_ENC_H264_PROFILE_HIGH_444_GUID;
+avctx->profile = FF_PROFILE_H264_HIGH_444_PREDICTIVE;
+}
 
 ctx->encode_config.encodeCodecConfig.h264Config.chromaFormatIDC = 
avctx->profile == FF_PROFILE_H264_HIGH_444_PREDICTIVE ? 3 : 1;
 
@@ -1452,7 +1457,7 @@ static const enum AVPixelFormat pix_fmts_nvenc[] = {
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
 { "preset", "Set the encoding preset (one of slow = hq 2pass, medium = hq, 
fast = hp, hq, hp, bd, ll, llhq, llhp, default)", OFFSET(preset), 
AV_OPT_TYPE_STRING, { .str = "hq" }, 0, 0, VE },
-{ "profile", "Set the encoding profile (high, main or baseline)", 
OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "profile", "Set the encoding profile (high, main, baseline or 
high444p)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
 { "level", "Set the encoding level restriction (auto, 1.0, 1.0b, 1.1, 1.2, 
..., 4.2, 5.0, 5.1)", OFFSET(level), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
 { "tier", "Set the encoding tier (main or high)", OFFSET(tier), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
 { "cbr", "Use cbr encoding mode", OFFSET(cbr), AV_OPT_TYPE_BOOL, { .i64 = 
0 }, 0, 1, VE },
-- 
1.9.5.github.0

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

Re: [FFmpeg-devel] [PATCH] fix nvenc potential profile error when encoding yuv444p

[Agatha Hu]

在 2015/10/28 14:53, Agatha Hu 写道:

---
  libavcodec/nvenc.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 0e6ef43..083e494 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -912,6 +912,11 @@ static av_cold int nvenc_encode_init(AVCodecContext
*avctx)
  goto error;
  }
  }
+// force setting profile as high444p if input is
AV_PIX_FMT_YUV444P
+if (avctx->pix_fmt == AV_PIX_FMT_YUV444P) {
+ctx->encode_config.profileGUID =
NV_ENC_H264_PROFILE_HIGH_444_GUID;
+avctx->profile = FF_PROFILE_H264_HIGH_444_PREDICTIVE;
+}


ctx->encode_config.encodeCodecConfig.h264Config.chromaFormatIDC =
avctx->profile == FF_PROFILE_H264_HIGH_444_PREDICTIVE ? 3 : 1;

@@ -1452,7 +1457,7 @@ static const enum AVPixelFormat pix_fmts_nvenc[] = {
  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
  static const AVOption options[] = {
  { "preset", "Set the encoding preset (one of slow = hq 2pass,
medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default)",
OFFSET(preset), AV_OPT_TYPE_STRING, { .str = "hq" }, 0, 0, VE },
-{ "profile", "Set the encoding profile (high, main or baseline)",
OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
+{ "profile", "Set the encoding profile (high, main, baseline or
high444p)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
  { "level", "Set the encoding level restriction (auto, 1.0, 1.0b,
1.1, 1.2, ..., 4.2, 5.0, 5.1)", OFFSET(level), AV_OPT_TYPE_STRING, { 0
}, 0, 0, VE },
  { "tier", "Set the encoding tier (main or high)", OFFSET(tier),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
  { "cbr", "Use cbr encoding mode", OFFSET(cbr), AV_OPT_TYPE_BOOL, {
.i64 = 0 }, 0, 1, VE },


The original nvenc.c misses "yuv444p" in option explanation, and since 
yuv444p is only for AV_PIX_FMT_YUV444P input, force setting the profile 
to prevent error.


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

Re: [FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Matt Oliver]

On 26 October 2015 at 04:46, James Almer  wrote:

> On 10/25/2015 1:39 PM, Matt Oliver wrote:
> > On 26 October 2015 at 00:43, Hendrik Leppkes 
> wrote:
> >
> >> On Sun, Oct 25, 2015 at 12:30 PM, Matt Oliver 
> >> wrote:
> >>> On 25 October 2015 at 22:16, Hendrik Leppkes 
> >> wrote:
> >>>
>  On Sun, Oct 25, 2015 at 11:26 AM, Matt Oliver 
>  wrote:
> > On 25 October 2015 at 12:22, Ganesh Ajjanagadde 
>  wrote:
> >
> >> On Sat, Oct 24, 2015 at 7:03 PM, James Almer 
> >> wrote:
> >>> On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
>  On Sat, Oct 24, 2015 at 6:08 PM, James Almer 
>  wrote:
> > This gives the compiler some flexibility
> >
> > Signed-off-by: James Almer 
> > ---
> >  libavutil/x86/intmath.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> > index 7881e3c..10d3e7f 100644
> > --- a/libavutil/x86/intmath.h
> > +++ b/libavutil/x86/intmath.h
> > @@ -36,7 +36,7 @@ static av_always_inline av_const int
> >> ff_ctzll_x86(long long v)
> >  {
> >  #   if ARCH_X86_64
> >  uint64_t c;
> > -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
> > +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
> >  return c;
> >  #   else
> >  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v
> 
> >> 32)) + 32 : _bit_scan_forward((uint32_t)v);
> > --
> > 2.6.2
> 
>  This question may be silly, but can you clarify when this asm
> >> code is
>  used instead of __builtin_ctzll? For instance, I think on
> >> GNU/Linux,
>  x86-64, sufficiently modern GCC (even with asm enabled), we should
>  always use the builtin: the compiler knows best what to do with
> >> its
>  builtin.
> >>>
> >>> This is ICC/ICL, not GCC.
> >>
> >> Ah, now I recall that _bit_scan_forward64 was not always available
> on
> >> ICC. Anyway, this is just a heads up to whoever uses ICC/ICL and the
> >> like: you may want to find out to which versions this built in
> >> applies.
> >
> >
> > bit_scan_forward64 isnt available on ICL at all, hence the use of
> asm.
> >
> 
>  Intels intrinsic guide lists _BitScanForward64 as the intrinsic to
> use,
>  however.
> 
> 
> >>
> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=Other=373
> >>>
> >>>
> >>>  _BitScanForward64 is a msvc intrinsic only available on windows
> >> platforms
> >>> so not usable with ICC. The native asm implementation also performs
> >> better
> >>> with ICL hence its use.
> >>
> >> The "Intel(R) C++ Compiler User and Reference Guide" would care to
> >> disagree with you.
> >>
> >
> > Well ill be... I dont have ICC on hand to check it but ill take Intels
> word
> > for it. Its interesting that Intel decided to support that intrinsic as
> > opposed to just extending there own version to 64b (i.e.
> > _bit_scan_forward64). _BitScanForward64 as far as I know was introduced
> by
> > msvc and made available in "winnt.h" hence the different naming
> convention
> > to other intrinsics. That said the inline asm version is still preferable
> > with Intel as the intrinsic passes the result via pointer which when
> tested
> > with msvc11 and 12 crt's resulted in horrible performance hits as the
> > compiler didnt optimise out the memory access in order to keep the result
> > in register (works fine with newer ICL 16 and msvcrt14 though).
>
> Tried ICC 13 x86_64 from https://gcc.godbolt.org/ and it doesn't recognize
> _BitScanForward64, or _BitScanForward for that matter.
>

I didnt know about godbolt, definitely a nice tool, thanks for checking.
I was a little surprised as I swore I checked those (and others) intrinsics
several years ago and they were windows only. Atleast now I know my memory
is not completely shot.


> >
> > Using tzcnt would be the more interesting option. Changing the asm to
> tzcnt
> > works with ICL. But also the use of the tzcnt intrinsic (_tzcnt_u64)
> would
> > be possible with both intel and msvc. I dont have anything older than
> > Haswell or Piledriver to double check but I have seen its use in several
> > other projects without issue so in theory it shouldnt be a problem.
> >
> > If tzcnt is preferable I can make up a patch to convert the intel and
> msvc
> > versions to use the required intrinsic.
>

> IIRC tzcnt (rep bsf) is only slower than plain bsf on really ancient
> machines, e.g. 80486 and such, so there's not really any downside of
> using it.


Well in that case the optimizations can be heavily simplified to those in
the attached patch.

[FFmpeg-devel] [PATCH] avformat: add 3dostr demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/3dostr.c | 169 +++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 3 files changed, 171 insertions(+)
 create mode 100644 libavformat/3dostr.c

diff --git a/libavformat/3dostr.c b/libavformat/3dostr.c
new file mode 100644
index 000..7df36b9
--- /dev/null
+++ b/libavformat/3dostr.c
@@ -0,0 +1,169 @@
+/*
+ * 3DO STR demuxer
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * 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/bswap.h"
+#include "avformat.h"
+#include "internal.h"
+
+static int threedostr_probe(AVProbeData *p)
+{
+if (memcmp(p->buf, "CTRL", 4) &&
+memcmp(p->buf, "SHDR", 4) &&
+memcmp(p->buf, "SNDS", 4))
+return 0;
+
+return AVPROBE_SCORE_MAX / 3 * 2;
+}
+
+static int threedostr_read_header(AVFormatContext *s)
+{
+unsigned chunk, codec = 0, size, ctrl_size = -1, found_shdr = 0;
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codec->codec_type = AVMEDIA_TYPE_AUDIO;
+
+while (!avio_feof(s->pb) && !found_shdr) {
+chunk = avio_rl32(s->pb);
+size  = avio_rb32(s->pb);
+
+if (size < 8)
+return AVERROR_INVALIDDATA;
+size -= 8;
+
+switch (chunk) {
+case MKTAG('C','T','R','L'):
+ctrl_size = size;
+break;
+case MKTAG('S','N','D','S'):
+if (size < 56)
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 8);
+if (avio_rl32(s->pb) != MKTAG('S','H','D','R'))
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 24);
+st->codec->sample_rate = avio_rb32(s->pb);
+st->codec->channels= avio_rb32(s->pb);
+if (st->codec->channels <= 0)
+return AVERROR_INVALIDDATA;
+codec  = avio_rl32(s->pb);
+avio_skip(s->pb, 4);
+if (ctrl_size == 20 || ctrl_size == 3 || ctrl_size == -1)
+st->duration   = (avio_rb32(s->pb) - 1) / 
st->codec->channels;
+else
+st->duration   = avio_rb32(s->pb) * 16 / 
st->codec->channels;
+size -= 56;
+found_shdr = 1;
+break;
+case MKTAG('S','H','D','R'):
+if (size >  0x78) {
+avio_skip(s->pb, 0x74);
+size -= 0x78;
+if (avio_rl32(s->pb) == MKTAG('C','T','R','L') && size > 4) {
+ctrl_size = avio_rb32(s->pb);
+size -= 4;;
+}
+}
+break;
+default:
+av_log(s, AV_LOG_DEBUG, "skipping unknown chunk: %X\n", chunk);
+break;
+}
+
+avio_skip(s->pb, size);
+}
+
+switch (codec) {
+case MKTAG('S','D','X','2'):
+st->codec->codec_id= AV_CODEC_ID_SDX2_DPCM;
+st->codec->block_align = 1 * st->codec->channels;
+break;
+default:
+avpriv_request_sample(s, "codec %X", codec);
+return AVERROR_PATCHWELCOME;
+}
+
+avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
+
+return 0;
+}
+
+static int threedostr_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+unsigned chunk, size, found_ssmp = 0;
+AVStream *st = s->streams[0];
+int64_t pos;
+int ret = 0;
+
+while (!found_ssmp) {
+if (avio_feof(s->pb))
+return AVERROR_EOF;
+
+pos   = avio_tell(s->pb);
+chunk = avio_rl32(s->pb);
+size  = avio_rb32(s->pb);
+
+if (!size)
+continue;
+
+if (size < 8)
+return AVERROR_INVALIDDATA;
+size -= 8;
+
+switch (chunk) {
+case MKTAG('S','N','D','S'):
+if (size <= 16)
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 8);
+if (avio_rl32(s->pb) != MKTAG('S','S','M','P'))
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 4);
+size -= 16;
+ret = av_get_packet(s->pb, pkt, size);
+pkt->pos = pos;
+pkt->stream_index = 0;
+

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[wm4]

On Wed, 28 Oct 2015 01:06:38 +0100
Michael Niedermayer  wrote:

> On Tue, Oct 27, 2015 at 10:14:49AM +0100, wm4 wrote:
> > On Mon, 26 Oct 2015 13:15:39 -0700
> > Dale Curtis  wrote:
> >   
> > > On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje 
> > > wrote:  
> > > >
> > > > So this is likely because we init all tables instead of just these that 
> > > > we
> > > > need, right? So how about having one ff_once per table? That should be
> > > > trivial to implement.
> > > >
> > > 
> > > (from the right account this time)
> > > 
> > > Just so we're all on the same page, this is trivial, but will get a bit
> > > messy unless I'm missing something. The ff_thread_once() API only takes a
> > > void(void) function, so unless there's partial specialization hiding
> > > somewhere we need prototypes for each partial initialization. I.e.
> > > ff_init_ff_cos_static_table_init_4(), 
> > > ff_init_ff_cos_static_table_init_5(),
> > > ff_init_ff_cos_static_table_init_6(), etc for 4..16. We would also then
> > > have an array of AVOnce items for entries 4..16 where each entry would
> > > correspond to calling the paired initialization function.
> > > 
> > > Is this what everyone had in mind?  
> > 
> > Now that you're saying it, this is inconvenient. You could just
> > initialize a static mutex (using AVOnce, since we don't have a static
> > mutex initializer that works on all platforms), and guard
> > initialization with this mutex.  
> 
> hmm
> but if we can create a static mutex portably with ff_thread_once()
> then we could write a simple and portable API to do this
> 
> like:
> FF_DECLARE_STATIC_MUTEX(my_mutex);
> 
> FF_INIT_STATIC_MUTEX(my_mutex);
> 
> the first would declare a mutex, AVOnce and a trivial init function to
> create the mutex
> the second would use ff_thread_once() to call that init function
> 
> that should hide all the complexity behind 2 lines of code
> 
> and it might be usefull elsewhere too
> 

Sounds very fine to me, though some might complain about potential
memory leaks due to not freeing the mutex. (But at least on Linux, an
unlocked mutex uses no OS resources. I'm not sure how it is on Windows,
OSX, or other unixes.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

[Michael Niedermayer]

On Sun, Oct 18, 2015 at 02:06:12PM +0200, Bodecs Bela wrote:
> Dear Marton Balint,
> 
> see may comments below.
> 
> 2015.10.18. 1:10 keltezéssel, Marton Balint írta:
> >
> >On Thu, 15 Oct 2015, Bodecs Bela wrote:
> >
> >[...]
> >
> My enhancement does not alter the current behaviour in any way.
> >>>
> >>>Are you sure? What if somebody matched a semicolon, or a
> >>>string which contained a semicolon in a metadata value? E.g.:
> >>>m:timecode:00:00:00:00
> >>>
> >
> yes, indeed.
> >This question still stands. Will the m:timecode:00:00:00:00
> >specifier work the same way as it did after your patch? I think it
> >will not.
> >
> >[...]
> >
> >>I do not understand this. My patch only gives an opportunity to
> >>use multiple specifiers in the same expression, it is not
> >>mandatory to use it. The patch does not affect any existing
> >>command line in any way.
> >
> >I don't agree, I think your patch changes existing behaviour and
> >the proposed syntax limits future extensibility.
> ok.
> >
> >>I also accept your concern about the future, but double
> >>semicilon always will works for optional parameters. But may I
> >>ask: would it be better to introduce a "special character" for
> >>separating specifiers in the same expression?
> >
> >IMHO yes. You also have to know from the start that you are
> >dealing with a complex specifier, in order not to break existing
> >simple specifiers.
> >
> >>I accept it if you suggest one. I only need the functionality to
> >>be able to give more criteria to select a stream as opposed to
> >>current oppurtunities. I am not stuck to my suggestion.
> >>Anyway, You may see my enhancement as you get many optional
> >>parameters for the existing type, metadata and program_id
> >>specifiers. :)
> >
> >It can be anything if it does not change existing behaviour, a
> >complex specifier can be split to basic specifiers without
> >worrying about the syntax of the basic specifier and if there is a
> >well defined rule for escaping special characters. Also if it is
> >readable to the user, that is a plus.
> >
> >The exact solution can be a bit about personal taste as well, but
> >maybe something like
> >
> >(specifier)(specifier)
> >
> I like this version. So, there would be the original case:
> specifier, and if you want to use more specifier, you should put
> each of them into parenthesis (round brackets):
> (specifier)(specifier)
> I think it really won't break any current code
> 
> >or
> >
> >+specifier+specifier
> >
> I think () is more readible and rarely used in specifiers.  If it is
> ok for you and others I would implement it.

i dont know which syntax is best but i agree with marton that the
initial patch was not optimal.
Also it seems the original patch changed the code quite deeply
it would be better independant of syntax to have a more minimal
change, that is if you intend to reimplement it anyway


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

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


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

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Clément Bœsch]

On Wed, Oct 28, 2015 at 10:34:37AM -0400, Ronald S. Bultje wrote:
[...]
> You could do the same for the last 4 values of the cinething changes, they
> are clearly not enums, but flags. Flags are always unsigned, so if enums
> are unsigned and that causes an issue (as it does here), it makes sense to
> fix that at its root, i.e. by making the value unsigned and it thus also
> being a macro instead of an enum. Again, only the last 4 elements, the
> first 5 appear to be genuine enums.

I support this (or just remove the entries altogether since unused).

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avformat: implement SChannel SSP TLS protocol

[Hendrik Leppkes]

On Wed, Oct 21, 2015 at 1:52 PM, Hendrik Leppkes  wrote:
> This implementation does not support TLS listen sockets and loading
> CA/Certs from files.
>
> The Windows API does not support loading PEM certs, and would either
> require a manual loader or instead be limited to loading Windows PFX
> certificates
>
> TLS listen sockets would have to be implemented quite separately, as many
> of the APIs are different for server-mode (as opposed to client mode).
> ---
>
> Because of the limitations in comparison to OpenSSL or GnuTLS,
> we might make this implementation not active by default, if someone feels
> like thats a better course of action.
>
>
>  configure  |  20 +-
>  libavformat/Makefile   |   1 +
>  libavformat/allformats.c   |   1 +
>  libavformat/tls.h  |   2 +-
>  libavformat/tls_schannel.c | 601 
> +
>  5 files changed, 621 insertions(+), 4 deletions(-)
>  create mode 100644 libavformat/tls_schannel.c
>
> diff --git a/configure b/configure
> index 5e7ded1..6b9b99c 100755
> --- a/configure
> +++ b/configure
> @@ -280,6 +280,8 @@ External library support:
>--enable-opengl  enable OpenGL rendering [no]
>--enable-openssl enable openssl, needed for https support
> if gnutls is not used [no]
> +  --disable-schannel   disable SChannel SSP, needed for TLS support on
> +   Windows if openssl and gnutls are not used 
> [autodetect]
>--disable-sdldisable sdl [autodetect]
>--disable-securetransport disable Secure Transport, needed for TLS support
> on OSX if openssl and gnutls are not used 
> [autodetect]
> @@ -1465,6 +1467,7 @@ EXTERNAL_LIBRARY_LIST="
>  opencl
>  opengl
>  openssl
> +schannel
>  sdl
>  securetransport
>  x11grab
> @@ -2754,13 +2757,15 @@ sctp_protocol_deps="struct_sctp_event_subscribe"
>  sctp_protocol_select="network"
>  srtp_protocol_select="rtp_protocol"
>  tcp_protocol_select="network"
> -tls_gnutls_protocol_deps="gnutls !tls_securetransport_protocol"
> +tls_gnutls_protocol_deps="gnutls !tls_schannel_protocol 
> !tls_securetransport_protocol"
>  tls_gnutls_protocol_select="tcp_protocol"
> -tls_openssl_protocol_deps="openssl !tls_securetransport_protocol 
> !tls_gnutls_protocol"
> +tls_openssl_protocol_deps="openssl !tls_schannel_protocol 
> !tls_securetransport_protocol !tls_gnutls_protocol"
>  tls_openssl_protocol_select="tcp_protocol"
> +tls_schannel_protocol_deps="schannel"
> +tls_schannel_protocol_select="tcp_protocol"
>  tls_securetransport_protocol_deps="securetransport"
>  tls_securetransport_protocol_select="tcp_protocol"
> -tls_protocol_deps_any="tls_securetransport_protocol tls_gnutls_protocol 
> tls_openssl_protocol"
> +tls_protocol_deps_any="tls_schannel_protocol tls_securetransport_protocol 
> tls_gnutls_protocol tls_openssl_protocol"
>  udp_protocol_select="network"
>  udplite_protocol_select="network"
>  unix_protocol_deps="sys_un_h"
> @@ -5501,6 +5506,15 @@ disabled securetransport || { check_func 
> SecIdentityCreate "-Wl,-framework,CoreF
>  check_lib2 "Security/SecureTransport.h Security/Security.h" 
> "SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation 
> -Wl,-framework,Security" &&
>  enable securetransport; }
>
> +if ! disabled schannel; then
> +check_cc < +#define SECURITY_WIN32
> +#include 
> +#include 
> +int main(void) { InitializeSecurityContext(NULL, NULL, NULL, 0, 0, 0, NULL, 
> 0, NULL, NULL, NULL, NULL); return 0; }
> +EOF
> +fi
> +
>  makeinfo --version > /dev/null 2>&1 && enable makeinfo  || disable makeinfo
>  enabled makeinfo \
>  && [ 0$(makeinfo --version | grep "texinfo" | sed 
> 's/.*texinfo[^0-9]*\([0-9]*\)\..*/\1/') -ge 5 ] \
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index ded2d54..b2d6057 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -535,6 +535,7 @@ OBJS-$(CONFIG_SUBFILE_PROTOCOL)  += subfile.o
>  OBJS-$(CONFIG_TCP_PROTOCOL)  += tcp.o
>  OBJS-$(CONFIG_TLS_GNUTLS_PROTOCOL)   += tls_gnutls.o tls.o
>  OBJS-$(CONFIG_TLS_OPENSSL_PROTOCOL)  += tls_openssl.o tls.o
> +OBJS-$(CONFIG_TLS_SCHANNEL_PROTOCOL) += tls_schannel.o tls.o
>  OBJS-$(CONFIG_TLS_SECURETRANSPORT_PROTOCOL) += tls_securetransport.o tls.o
>  OBJS-$(CONFIG_UDP_PROTOCOL)  += udp.o
>  OBJS-$(CONFIG_UDPLITE_PROTOCOL)  += udp.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 40fea8e..dad2644 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -387,6 +387,7 @@ void av_register_all(void)
>  REGISTER_PROTOCOL(SRTP, srtp);
>  REGISTER_PROTOCOL(SUBFILE,  subfile);
>  REGISTER_PROTOCOL(TCP,  tcp);
> +REGISTER_PROTOCOL(TLS_SCHANNEL, tls_schannel);
>  REGISTER_PROTOCOL(TLS_SECURETRANSPORT, tls_securetransport);
>  

Re: [FFmpeg-devel] [PATCH 3/3] WIP: lavf/utils: try to avoid decoding a frame to get the codec parameters

[Michael Niedermayer]

On Sat, Oct 17, 2015 at 10:34:24PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> Avoid decoding twice images such as jpeg and png, once in the
> avformat_find_stream_info and once when the actual decode is made.
> 
> The decoder must honor the skip_frame option in order to skip
> decoding. For now the AVDISCARD_ALL flag is only set for the mjpeg and
> png decoders.
> ---
>  libavformat/utils.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 689473e..67dfffc 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2676,11 +2676,16 @@ static int has_codec_parameters(AVStream *st, const 
> char **errmsg_ptr)
>  static int try_decode_frame(AVFormatContext *s, AVStream *st, AVPacket 
> *avpkt,
>  AVDictionary **options)
>  {
> +int i;
>  const AVCodec *codec;
>  int got_picture = 1, ret = 0;
>  AVFrame *frame = av_frame_alloc();
>  AVSubtitle subtitle;
>  AVPacket pkt = *avpkt;
> +int skip_frame;
> +static const enum AVCodecID no_decode_codecs[] = {
> +AV_CODEC_ID_MJPEG, AV_CODEC_ID_PNG,
> +};
>  
>  if (!frame)
>  return AVERROR(ENOMEM);
> @@ -2719,6 +2724,14 @@ static int try_decode_frame(AVFormatContext *s, 
> AVStream *st, AVPacket *avpkt,
>  goto fail;
>  }
>  
> +skip_frame = st->codec->skip_frame;
> +for (i = 0; i < FF_ARRAY_ELEMS(no_decode_codecs); i++) {
> +if (st->codec->codec_id == no_decode_codecs[i]) {
> +st->codec->skip_frame = AVDISCARD_ALL;
> +break;
> +}
> +}
> +
>  while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
> ret >= 0 &&
> (!has_codec_parameters(st, NULL) || 
> !has_decode_delay_been_guessed(st) ||
> @@ -2753,6 +2766,8 @@ static int try_decode_frame(AVFormatContext *s, 
> AVStream *st, AVPacket *avpkt,
>  if (!pkt.data && !got_picture)
>  ret = -1;
>  
> +st->codec->skip_frame = skip_frame;

iam slightly unhappy about the possibility that someone could add
a if(whatever) goto fail between these 2 and it would leave
skip_frame in the modified state
otherwise LGTM

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

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


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

[FFmpeg-devel] [PATCH] vp9_parser: don't overwrite cached timestamps with nopts.

[Ronald S. Bultje]

---
 libavcodec/vp9_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
index 0437097..6713850 100644
--- a/libavcodec/vp9_parser.c
+++ b/libavcodec/vp9_parser.c
@@ -64,7 +64,7 @@ static int parse_frame(AVCodecParserContext *ctx, const 
uint8_t *buf, int size)
 if (ctx->pts == AV_NOPTS_VALUE)
 ctx->pts = s->pts;
 s->pts = AV_NOPTS_VALUE;
-} else {
+} else if (ctx->pts != AV_NOPTS_VALUE) {
 s->pts = ctx->pts;
 ctx->pts = AV_NOPTS_VALUE;
 }
-- 
2.1.2

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

Re: [FFmpeg-devel] [PATCH 2/3] lavc/mjpegdec: honor skip_frame option

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 03:10:00PM +0100, Matthieu Bouron wrote:
> On Wed, Oct 28, 2015 at 12:58:53PM +0100, Michael Niedermayer wrote:
> > On Wed, Oct 28, 2015 at 02:57:14AM +0100, Michael Niedermayer wrote:
> > > On Tue, Oct 27, 2015 at 11:15:29PM +0100, Matthieu Bouron wrote:
> > > > On Sun, Oct 18, 2015 at 11:06:50AM +0200, Matthieu Bouron wrote:
> > > > [...]
> > > > > 
> > > > > Patch updated, the markers are now properly skipped (which also fixes 
> > > > > a
> > > > > crash).
> > > > 
> > > > Patch updated. It fixes an issue with mjpeg streams (and in particular 
> > > > with
> > > > the fate sample ffmpeg-issue-897.avi) due to the EOI marker not handled 
> > > > when
> > > > skip_frame is set to AVDISCARD_ALL.
> > > > 
> > > > Matthieu
> > > 
> > > >  mjpegdec.c |   26 ++
> > > >  1 file changed, 26 insertions(+)
> > > > 36d41f1bded2f864394843c6a49d8cc24933688c  
> > > > 0002-lavc-mjpegdec-honor-skip_frame-option.patch
> > > > From 7325810d812c4182cd42946687a1f4abc04999d1 Mon Sep 17 00:00:00 2001
> > > > From: Matthieu Bouron 
> > > > Date: Fri, 9 Oct 2015 15:15:15 +0200
> > > > Subject: [PATCH 2/3] lavc/mjpegdec: honor skip_frame option
> > > > 
> > > > ---
> > > >  libavcodec/mjpegdec.c | 26 ++
> > > >  1 file changed, 26 insertions(+)
> > > > 
> > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > > > index 1a86b7b..b4ff83c 100644
> > > > --- a/libavcodec/mjpegdec.c
> > > > +++ b/libavcodec/mjpegdec.c
> > > > @@ -2038,6 +2038,22 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, 
> > > > void *data, int *got_frame,
> > > >  return AVERROR(ENOSYS);
> > > >  }
> > > >  
> > > > +if (avctx->skip_frame == AVDISCARD_ALL) {
> > > > +int i, found = 0;
> > > > +static const int start_codes[] = { SOF0,
> > > > +SOF1, SOF2, SOF3, SOF48, SOI, EOI };
> > > > +
> > > > +for (i = 0; i < FF_ARRAY_ELEMS(start_codes); i++) {
> > > > +if (start_code == start_codes[i]) {
> > > > +found = 1;
> > > > +break;
> > > > +}
> > > > +}
> > > > +if (!found) {
> > > > +goto skip;
> > > > +}
> > 
> > i think this would be simpler and shorter if implemented as a
> > switch(start_code)/case
> > 
> 
> Patch updated using a switch/case to implement the skip logic.
> 
> [...]

>  mjpegdec.c |   25 +
>  1 file changed, 25 insertions(+)
> 2db19e21ec69adc30ec5a3fdf03bd0c60257cb65  
> 0002-lavc-mjpegdec-honor-skip_frame-option.patch
> From cb09375d6cf5051ce51e43a2787f0242bd6450bc Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Fri, 9 Oct 2015 15:15:15 +0200
> Subject: [PATCH 2/3] lavc/mjpegdec: honor skip_frame option

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 3/3] WIP: lavf/utils: try to avoid decoding a frame to get the codec parameters

[Ronald S. Bultje]

Hi,

On Sat, Oct 17, 2015 at 4:34 PM, Matthieu Bouron 
wrote:

> From: Matthieu Bouron 
>
> Avoid decoding twice images such as jpeg and png, once in the
> avformat_find_stream_info and once when the actual decode is made.
>
> The decoder must honor the skip_frame option in order to skip
> decoding. For now the AVDISCARD_ALL flag is only set for the mjpeg and
> png decoders.
> ---
>  libavformat/utils.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 689473e..67dfffc 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2676,11 +2676,16 @@ static int has_codec_parameters(AVStream *st,
> const char **errmsg_ptr)
>  static int try_decode_frame(AVFormatContext *s, AVStream *st, AVPacket
> *avpkt,
>  AVDictionary **options)
>  {
> +int i;
>  const AVCodec *codec;
>  int got_picture = 1, ret = 0;
>  AVFrame *frame = av_frame_alloc();
>  AVSubtitle subtitle;
>  AVPacket pkt = *avpkt;
> +int skip_frame;
> +static const enum AVCodecID no_decode_codecs[] = {
> +AV_CODEC_ID_MJPEG, AV_CODEC_ID_PNG,
> +};
>
>  if (!frame)
>  return AVERROR(ENOMEM);
> @@ -2719,6 +2724,14 @@ static int try_decode_frame(AVFormatContext *s,
> AVStream *st, AVPacket *avpkt,
>  goto fail;
>  }
>
> +skip_frame = st->codec->skip_frame;
> +for (i = 0; i < FF_ARRAY_ELEMS(no_decode_codecs); i++) {
> +if (st->codec->codec_id == no_decode_codecs[i]) {
> +st->codec->skip_frame = AVDISCARD_ALL;
> +break;
> +}
> +}


I tend to find this kind of specific code in general interfaces fairly
questionable. Why is this necessary?

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

Re: [FFmpeg-devel] [PATCH] avformat: implement SChannel SSP TLS protocol

[Hendrik Leppkes]

On Wed, Oct 28, 2015 at 6:07 PM, Derek Buitenhuis
 wrote:
> Enjoy my half-assed / useless review.
>
>> +#ifndef SECBUFFER_ALERT
>> +#define SECBUFFER_ALERT17
>> +#endif
>
> Why?

I think it was needed on some configuration, I'll verify.

>
>> +SecPkgContext_StreamSizes Sizes;
>
> Accidental capital?
>
>> +if (c->enc_buf == NULL) {
>> +c->enc_buf_offset = 0;
>> +c->enc_buf_size = SCHANNEL_INITIAL_BUFFER_SIZE;
>> +ret = av_reallocp(>enc_buf, c->enc_buf_size);
>> +if (ret < 0)
>> +goto fail;
>
> I can never remember if _close() is guaranteed to be called. I'll assume yes.
>
>> +while (1)
>> +{
>> +if (c->enc_buf_size - c->enc_buf_offset < 
>> SCHANNEL_FREE_BUFFER_SIZE) {
>
> Can enc_buf_offset ever end up bigger? e.. if data keeps being read, and you 
> keep
> getting SEC_E_INCOMPLETE_MESSAGE.

Bigger than what, buf_size? it should grow that as necessary when data
is received.

>
>> +/* input buffers */
>> +InitSecBuffer([0], SECBUFFER_TOKEN, 
>> av_malloc(c->enc_buf_offset), c->enc_buf_offset);
>
> Is this a unchecked malloc, or is it passed into inbuf[0].pvBuffer?

Yes this ends up in inbuf[0].pvBuffer which is then checked.
I could make it explicit before if people like.

>
>> +
>> +sspi_ret = InitializeSecurityContext(>cred_handle, 
>> >ctxt_handle, s->host, c->request_flags,
>> + 0, 0, _desc, 0, NULL, 
>> _desc, >context_flags,
>> + >ctxt_timestamp);
>> +av_freep([0].pvBuffer);
>
> Double checking: is this safe?

Since this is the buffer we av_malloc'ed before, yes.

>
>
>> +/* SChannel Options */
>> +memset(_cred, 0, sizeof(schannel_cred));
>
> SCHANNEL_CRED schannel_cred = { 0 };
>
>> +cleanup:
>> +size = len < c->dec_buf_offset ? len : c->dec_buf_offset;
>> +if (size) {
>> +memcpy(buf, c->dec_buf, size);
>> +memmove(c->dec_buf, c->dec_buf + size, c->dec_buf_offset - size);
>> +c->dec_buf_offset -= size;
>> +
>> +return size;
>> +}
>> +
>> +if (ret == 0 && !c->connection_closed)
>> +ret = AVERROR(EAGAIN);
>> +
>> +return ret < 0 ? ret : 0;
>> +
>> +fail:
>> +return ret;
>
> No cleanup in case of failure?

fail is only used for serious unrecoverable failures, like socket read
failure or mem allocation failure. It could still call that code, I
suppose, just in case some valid data is stuck in the decrypted
buffer.

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

Re: [FFmpeg-devel] [PATCH 3/3] WIP: lavf/utils: try to avoid decoding a frame to get the codec parameters

[Hendrik Leppkes]

On Sat, Oct 17, 2015 at 10:34 PM, Matthieu Bouron
 wrote:
> From: Matthieu Bouron 
>
> Avoid decoding twice images such as jpeg and png, once in the
> avformat_find_stream_info and once when the actual decode is made.
>
> The decoder must honor the skip_frame option in order to skip
> decoding. For now the AVDISCARD_ALL flag is only set for the mjpeg and
> png decoders.
> ---
>  libavformat/utils.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 689473e..67dfffc 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2676,11 +2676,16 @@ static int has_codec_parameters(AVStream *st, const 
> char **errmsg_ptr)
>  static int try_decode_frame(AVFormatContext *s, AVStream *st, AVPacket 
> *avpkt,
>  AVDictionary **options)
>  {
> +int i;
>  const AVCodec *codec;
>  int got_picture = 1, ret = 0;
>  AVFrame *frame = av_frame_alloc();
>  AVSubtitle subtitle;
>  AVPacket pkt = *avpkt;
> +int skip_frame;
> +static const enum AVCodecID no_decode_codecs[] = {
> +AV_CODEC_ID_MJPEG, AV_CODEC_ID_PNG,
> +};

Hardcoded lists of codecs in random places are never a good thing to have.
If this is a feature we agree to have, its codecs should just get an
internal capability that tells this code if it can parse all params
without decoding.

>
>  if (!frame)
>  return AVERROR(ENOMEM);
> @@ -2719,6 +2724,14 @@ static int try_decode_frame(AVFormatContext *s, 
> AVStream *st, AVPacket *avpkt,
>  goto fail;
>  }
>
> +skip_frame = st->codec->skip_frame;
> +for (i = 0; i < FF_ARRAY_ELEMS(no_decode_codecs); i++) {
> +if (st->codec->codec_id == no_decode_codecs[i]) {
> +st->codec->skip_frame = AVDISCARD_ALL;
> +break;
> +}
> +}
> +
>  while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
> ret >= 0 &&
> (!has_codec_parameters(st, NULL) || 
> !has_decode_delay_been_guessed(st) ||
> @@ -2753,6 +2766,8 @@ static int try_decode_frame(AVFormatContext *s, 
> AVStream *st, AVPacket *avpkt,
>  if (!pkt.data && !got_picture)
>  ret = -1;
>
> +st->codec->skip_frame = skip_frame;
> +
>  fail:
>  av_frame_free();
>  return ret;
> --
> 2.6.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/asrc_sine: fix options typos

[Kyle Swanson]

Signed-off-by: Kyle Swanson 
---
 libavfilter/asrc_sine.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/asrc_sine.c b/libavfilter/asrc_sine.c
index f361faa..2a2f3c3 100644
--- a/libavfilter/asrc_sine.c
+++ b/libavfilter/asrc_sine.c
@@ -69,8 +69,8 @@ typedef struct {
 static const AVOption sine_options[] = {
 OPT_DBL("frequency", frequency,440, 0, DBL_MAX,   "set 
the sine frequency",),
 OPT_DBL("f", frequency,440, 0, DBL_MAX,   "set 
the sine frequency",),
-OPT_DBL("beep_factor",   beep_factor,0, 0, DBL_MAX,   "set 
the beep fequency factor",),
-OPT_DBL("b", beep_factor,0, 0, DBL_MAX,   "set 
the beep fequency factor",),
+OPT_DBL("beep_factor",   beep_factor,0, 0, DBL_MAX,   "set 
the beep frequency factor",),
+OPT_DBL("b", beep_factor,0, 0, DBL_MAX,   "set 
the beep frequency factor",),
 OPT_INT("sample_rate",   sample_rate,44100, 1, INT_MAX,   "set 
the sample rate",),
 OPT_INT("r", sample_rate,44100, 1, INT_MAX,   "set 
the sample rate",),
 OPT_DUR("duration",  duration,   0, 0, INT64_MAX, "set 
the audio duration",),
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 11:38 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Oct 28, 2015 at 11:00 AM, Ganesh Ajjanagadde
>  wrote:
>>
>> On Wed, Oct 28, 2015 at 10:53 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde
>> >  wrote:
>> >>
>> >> On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje
>> >> >> 
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
>> >> >> >  wrote:
>> >> >> >>
>> >> >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
>> >> >> >> > 
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> ISO C restricts enumerator values to the range of int. Thus
>> >> >> >> >> (for
>> >> >> >> >> instance)
>> >> >> >> >> 0x8000
>> >> >> >> >> unfortunately does not work, and throws a warning with
>> >> >> >> >> -Wpedantic
>> >> >> >> >> on
>> >> >> >> >> clang 3.7.
>> >> >> >> >>
>> >> >> >> >> This fixes it by using alternative expressions that result in
>> >> >> >> >> identical
>> >> >> >> >> values but do not have this issue.
>> >> >> >> >>
>> >> >> >> >> Tested with FATE.
>> >> >> >> >>
>> >> >> >> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> >> >> >> ---
>> >> >> >> >>  libavcodec/dca_syncwords.h | 26 --
>> >> >> >> >>  libavformat/cinedec.c  |  2 +-
>> >> >> >> >>  libavformat/mov_chan.c |  2 +-
>> >> >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
>> >> >> >> >>
>> >> >> >> >> diff --git a/libavcodec/dca_syncwords.h
>> >> >> >> >> b/libavcodec/dca_syncwords.h
>> >> >> >> >> index 3466b6b..6981cb8 100644
>> >> >> >> >> --- a/libavcodec/dca_syncwords.h
>> >> >> >> >> +++ b/libavcodec/dca_syncwords.h
>> >> >> >> >> @@ -19,19 +19,17 @@
>> >> >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>> >> >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
>> >> >> >> >>
>> >> >> >> >> -enum DCASyncwords {
>> >> >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
>> >> >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
>> >> >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
>> >> >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
>> >> >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
>> >> >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
>> >> >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
>> >> >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
>> >> >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
>> >> >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
>> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
>> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
>> >> >> >> >> -};
>> >> >> >> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
>> >> >> >> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
>> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
>> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
>> >> >> >> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
>> >> >> >> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
>> >> >> >> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
>> >> >> >> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
>> >> >> >> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
>> >> >> >> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
>> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
>> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > This one is fine.
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> --- a/libavformat/cinedec.c
>> >> >> >> >> +++ b/libavformat/cinedec.c
>> >> >> >> >> @@ -50,7 +50,7 @@ enum {
>> >> >> >> >>  CFA_BAYER = 3,  /**< GB/RG */
>> >> >> >> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
>> >> >> >> >>
>> >> >> >> >> -CFA_TLGRAY= 0x8000,
>> >> >> >> >> +CFA_TLGRAY= INT32_MIN,
>> >> >> >> >>  CFA_TRGRAY= 0x4000,
>> >> >> >> >>  CFA_BLGRAY= 0x2000,
>> >> >> >> >>  CFA_BRGRAY= 0x1000
>> >> >> >> >> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
>> >> >> >> >> index a2fa8d6..f6181e2 100644
>> >> >> >> >> --- a/libavformat/mov_chan.c
>> >> >> >> >> +++ b/libavformat/mov_chan.c
>> >> >> >> >> @@ -45,7 +45,7 @@
>> >> >> >> >>   *do not specify a particular ordering of those
>> >> >> >> >> 

Re: [FFmpeg-devel] [PATCH] fix nvenc potential profile error when encoding yuv444p

[Philip Langdale]

On Wed, 28 Oct 2015 14:53:42 +0800
Agatha Hu  wrote:

> ---
>   libavcodec/nvenc.c | 7 ++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 0e6ef43..083e494 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -912,6 +912,11 @@ static av_cold int
> nvenc_encode_init(AVCodecContext *avctx)
>   goto error;
>   }
>   }
> +// force setting profile as high444p if input is
> AV_PIX_FMT_YUV444P
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV444P) {
> +ctx->encode_config.profileGUID = 
> NV_ENC_H264_PROFILE_HIGH_444_GUID;
> +avctx->profile = FF_PROFILE_H264_HIGH_444_PREDICTIVE;
> +}
> 
>  
> ctx->encode_config.encodeCodecConfig.h264Config.chromaFormatIDC = 
> avctx->profile == FF_PROFILE_H264_HIGH_444_PREDICTIVE ? 3 : 1;
> 
> @@ -1452,7 +1457,7 @@ static const enum AVPixelFormat
> pix_fmts_nvenc[] = { #define VE AV_OPT_FLAG_VIDEO_PARAM |
> AV_OPT_FLAG_ENCODING_PARAM static const AVOption options[] = {
>   { "preset", "Set the encoding preset (one of slow = hq 2pass, 
> medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default)", 
> OFFSET(preset), AV_OPT_TYPE_STRING, { .str = "hq" }, 0, 0, VE },
> -{ "profile", "Set the encoding profile (high, main or
> baseline)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> +{ "profile", "Set the encoding profile (high, main, baseline or 
> high444p)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
>   { "level", "Set the encoding level restriction (auto, 1.0,
> 1.0b, 1.1, 1.2, ..., 4.2, 5.0, 5.1)", OFFSET(level),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
>   { "tier", "Set the encoding tier (main or high)", OFFSET(tier), 
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
>   { "cbr", "Use cbr encoding mode", OFFSET(cbr),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },

Seems reasonable to me.


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

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 11:33 AM, Hendrik Leppkes  wrote:
> On Wed, Oct 28, 2015 at 4:00 PM, Ganesh Ajjanagadde
>  wrote:
>> On Wed, Oct 28, 2015 at 10:53 AM, Ronald S. Bultje  
>> wrote:
>>> Hi,
>>>
>>> On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde
>>>  wrote:

 On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje 
 wrote:
 > Hi,
 >
 > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde
 > 
 > wrote:
 >>
 >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje 
 >> wrote:
 >> > Hi,
 >> >
 >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
 >> >  wrote:
 >> >>
 >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje
 >> >> 
 >> >> wrote:
 >> >> > Hi,
 >> >> >
 >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
 >> >> > 
 >> >> > wrote:
 >> >> >>
 >> >> >> ISO C restricts enumerator values to the range of int. Thus (for
 >> >> >> instance)
 >> >> >> 0x8000
 >> >> >> unfortunately does not work, and throws a warning with -Wpedantic
 >> >> >> on
 >> >> >> clang 3.7.
 >> >> >>
 >> >> >> This fixes it by using alternative expressions that result in
 >> >> >> identical
 >> >> >> values but do not have this issue.
 >> >> >>
 >> >> >> Tested with FATE.
 >> >> >>
 >> >> >> Signed-off-by: Ganesh Ajjanagadde 
 >> >> >> ---
 >> >> >>  libavcodec/dca_syncwords.h | 26 --
 >> >> >>  libavformat/cinedec.c  |  2 +-
 >> >> >>  libavformat/mov_chan.c |  2 +-
 >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
 >> >> >>
 >> >> >> diff --git a/libavcodec/dca_syncwords.h
 >> >> >> b/libavcodec/dca_syncwords.h
 >> >> >> index 3466b6b..6981cb8 100644
 >> >> >> --- a/libavcodec/dca_syncwords.h
 >> >> >> +++ b/libavcodec/dca_syncwords.h
 >> >> >> @@ -19,19 +19,17 @@
 >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
 >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
 >> >> >>
 >> >> >> -enum DCASyncwords {
 >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
 >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
 >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
 >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
 >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
 >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
 >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
 >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
 >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
 >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
 >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
 >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
 >> >> >> -};
 >> >> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
 >> >> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
 >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
 >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
 >> >> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
 >> >> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
 >> >> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
 >> >> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
 >> >> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
 >> >> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
 >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
 >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
 >> >> >
 >> >> >
 >> >> > This one is fine.
 >> >> >
 >> >> >>
 >> >> >> --- a/libavformat/cinedec.c
 >> >> >> +++ b/libavformat/cinedec.c
 >> >> >> @@ -50,7 +50,7 @@ enum {
 >> >> >>  CFA_BAYER = 3,  /**< GB/RG */
 >> >> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
 >> >> >>
 >> >> >> -CFA_TLGRAY= 0x8000,
 >> >> >> +CFA_TLGRAY= INT32_MIN,
 >> >> >>  CFA_TRGRAY= 0x4000,
 >> >> >>  CFA_BLGRAY= 0x2000,
 >> >> >>  CFA_BRGRAY= 0x1000
 >> >> >> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
 >> >> >> index a2fa8d6..f6181e2 100644
 >> >> >> --- a/libavformat/mov_chan.c
 >> >> >> +++ b/libavformat/mov_chan.c
 >> >> >> @@ -45,7 +45,7 @@
 >> >> >>   *do not specify a particular ordering of those
 >> >> >> channels."
 >> >> >>   */
 >> >> >>  enum MovChannelLayoutTag {
 >> >> >> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
 >> >> >> +

Re: [FFmpeg-devel] [PATCH] avfilter/asrc_sine: fix options typos

[Nicolas George]

Le septidi 7 brumaire, an CCXXIV, Kyle Swanson a écrit :
> Signed-off-by: Kyle Swanson 
> ---
>  libavfilter/asrc_sine.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Of course ok, thanks.

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] [PATCHv2] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 11:44 AM, Clément Bœsch  wrote:
> On Wed, Oct 28, 2015 at 10:34:37AM -0400, Ronald S. Bultje wrote:
> [...]
>> You could do the same for the last 4 values of the cinething changes, they
>> are clearly not enums, but flags. Flags are always unsigned, so if enums
>> are unsigned and that causes an issue (as it does here), it makes sense to
>> fix that at its root, i.e. by making the value unsigned and it thus also
>> being a macro instead of an enum. Again, only the last 4 elements, the
>> first 5 appear to be genuine enums.
>
> I support this (or just remove the entries altogether since unused).

I will change this, only issue of contention is the mov_chan one for
which I still feel my solution is better than proposed alternatives.

>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ronald S. Bultje]

Hi,

On Wed, Oct 28, 2015 at 2:31 PM, Ganesh Ajjanagadde 
wrote:

> On Wed, Oct 28, 2015 at 11:38 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Wed, Oct 28, 2015 at 11:00 AM, Ganesh Ajjanagadde
> >  wrote:
> >>
> >> On Wed, Oct 28, 2015 at 10:53 AM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde
> >> >  wrote:
> >> >>
> >> >> On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje <
> rsbul...@gmail.com>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje
> >> >> >> 
> >> >> >> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
> >> >> >> >  wrote:
> >> >> >> >>
> >> >> >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje
> >> >> >> >> 
> >> >> >> >> wrote:
> >> >> >> >> > Hi,
> >> >> >> >> >
> >> >> >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
> >> >> >> >> > 
> >> >> >> >> > wrote:
> >> >> >> >> >>
> >> >> >> >> >> ISO C restricts enumerator values to the range of int. Thus
> >> >> >> >> >> (for
> >> >> >> >> >> instance)
> >> >> >> >> >> 0x8000
> >> >> >> >> >> unfortunately does not work, and throws a warning with
> >> >> >> >> >> -Wpedantic
> >> >> >> >> >> on
> >> >> >> >> >> clang 3.7.
> >> >> >> >> >>
> >> >> >> >> >> This fixes it by using alternative expressions that result
> in
> >> >> >> >> >> identical
> >> >> >> >> >> values but do not have this issue.
> >> >> >> >> >>
> >> >> >> >> >> Tested with FATE.
> >> >> >> >> >>
> >> >> >> >> >> Signed-off-by: Ganesh Ajjanagadde 
> >> >> >> >> >> ---
> >> >> >> >> >>  libavcodec/dca_syncwords.h | 26 --
> >> >> >> >> >>  libavformat/cinedec.c  |  2 +-
> >> >> >> >> >>  libavformat/mov_chan.c |  2 +-
> >> >> >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
> >> >> >> >> >>
> >> >> >> >> >> diff --git a/libavcodec/dca_syncwords.h
> >> >> >> >> >> b/libavcodec/dca_syncwords.h
> >> >> >> >> >> index 3466b6b..6981cb8 100644
> >> >> >> >> >> --- a/libavcodec/dca_syncwords.h
> >> >> >> >> >> +++ b/libavcodec/dca_syncwords.h
> >> >> >> >> >> @@ -19,19 +19,17 @@
> >> >> >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
> >> >> >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
> >> >> >> >> >>
> >> >> >> >> >> -enum DCASyncwords {
> >> >> >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
> >> >> >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
> >> >> >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
> >> >> >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
> >> >> >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
> >> >> >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
> >> >> >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
> >> >> >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
> >> >> >> >> >> -};
> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
> >> >> >> >> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
> >> >> >> >> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
> >> >> >> >> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
> >> >> >> >> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
> >> >> >> >> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
> >> >> >> >> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
> >> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
> >> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > This one is fine.
> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> --- a/libavformat/cinedec.c
> >> >> >> >> >> +++ b/libavformat/cinedec.c
> >> >> >> >> >> @@ -50,7 +50,7 @@ enum {
> >> >> >> >> >>  CFA_BAYER = 3,  /**< GB/RG */
> >> >> >> >> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
> >> >> >> >> >>
> >> >> >> >> >> -CFA_TLGRAY= 0x8000,
> >> >> >> >> >> +CFA_TLGRAY= INT32_MIN,
> >> >> >> >> >>  CFA_TRGRAY= 0x4000,
> >> >> >> >> >>  CFA_BLGRAY= 0x2000,
> >> >> >> >> >>  CFA_BRGRAY= 0x1000
> >> >> >> >> >> 

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 2:39 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Oct 28, 2015 at 2:31 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> On Wed, Oct 28, 2015 at 11:38 AM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Wed, Oct 28, 2015 at 11:00 AM, Ganesh Ajjanagadde
>> >  wrote:
>> >>
>> >> On Wed, Oct 28, 2015 at 10:53 AM, Ronald S. Bultje 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde
>> >> >  wrote:
>> >> >>
>> >> >> On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje
>> >> >> 
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
>> >> >> >> >  wrote:
>> >> >> >> >>
>> >> >> >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje
>> >> >> >> >> 
>> >> >> >> >> wrote:
>> >> >> >> >> > Hi,
>> >> >> >> >> >
>> >> >> >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
>> >> >> >> >> > 
>> >> >> >> >> > wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> ISO C restricts enumerator values to the range of int. Thus
>> >> >> >> >> >> (for
>> >> >> >> >> >> instance)
>> >> >> >> >> >> 0x8000
>> >> >> >> >> >> unfortunately does not work, and throws a warning with
>> >> >> >> >> >> -Wpedantic
>> >> >> >> >> >> on
>> >> >> >> >> >> clang 3.7.
>> >> >> >> >> >>
>> >> >> >> >> >> This fixes it by using alternative expressions that result
>> >> >> >> >> >> in
>> >> >> >> >> >> identical
>> >> >> >> >> >> values but do not have this issue.
>> >> >> >> >> >>
>> >> >> >> >> >> Tested with FATE.
>> >> >> >> >> >>
>> >> >> >> >> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> >> >> >> >> ---
>> >> >> >> >> >>  libavcodec/dca_syncwords.h | 26 --
>> >> >> >> >> >>  libavformat/cinedec.c  |  2 +-
>> >> >> >> >> >>  libavformat/mov_chan.c |  2 +-
>> >> >> >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
>> >> >> >> >> >>
>> >> >> >> >> >> diff --git a/libavcodec/dca_syncwords.h
>> >> >> >> >> >> b/libavcodec/dca_syncwords.h
>> >> >> >> >> >> index 3466b6b..6981cb8 100644
>> >> >> >> >> >> --- a/libavcodec/dca_syncwords.h
>> >> >> >> >> >> +++ b/libavcodec/dca_syncwords.h
>> >> >> >> >> >> @@ -19,19 +19,17 @@
>> >> >> >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>> >> >> >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
>> >> >> >> >> >>
>> >> >> >> >> >> -enum DCASyncwords {
>> >> >> >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
>> >> >> >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
>> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
>> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
>> >> >> >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
>> >> >> >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
>> >> >> >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
>> >> >> >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
>> >> >> >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
>> >> >> >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
>> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
>> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
>> >> >> >> >> >> -};
>> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
>> >> >> >> >> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
>> >> >> >> >> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
>> >> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > This one is fine.
>> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> --- a/libavformat/cinedec.c
>> >> >> >> >> >> +++ b/libavformat/cinedec.c
>> >> >> >> >> >> @@ -50,7 +50,7 @@ enum {
>> >> >> >> >> >>  CFA_BAYER = 3,  /**< GB/RG */
>> >> >> >> >> >>  CFA_BAYERFLIP = 4,  /**< RG/GB */
>> >> >> >> >> >>
>> >> >> >> >> >> -CFA_TLGRAY= 

Re: [FFmpeg-devel] [PATCH] avformat: implement SChannel SSP TLS protocol

[Derek Buitenhuis]

Enjoy my half-assed / useless review.

> +#ifndef SECBUFFER_ALERT
> +#define SECBUFFER_ALERT17
> +#endif

Why?

> +SecPkgContext_StreamSizes Sizes;

Accidental capital?

> +if (c->enc_buf == NULL) {
> +c->enc_buf_offset = 0;
> +c->enc_buf_size = SCHANNEL_INITIAL_BUFFER_SIZE;
> +ret = av_reallocp(>enc_buf, c->enc_buf_size);
> +if (ret < 0)
> +goto fail;

I can never remember if _close() is guaranteed to be called. I'll assume yes.

> +while (1)
> +{
> +if (c->enc_buf_size - c->enc_buf_offset < SCHANNEL_FREE_BUFFER_SIZE) 
> {

Can enc_buf_offset ever end up bigger? e.. if data keeps being read, and you 
keep
getting SEC_E_INCOMPLETE_MESSAGE.

> +/* input buffers */
> +InitSecBuffer([0], SECBUFFER_TOKEN, 
> av_malloc(c->enc_buf_offset), c->enc_buf_offset);

Is this a unchecked malloc, or is it passed into inbuf[0].pvBuffer?

> +
> +sspi_ret = InitializeSecurityContext(>cred_handle, 
> >ctxt_handle, s->host, c->request_flags,
> + 0, 0, _desc, 0, NULL, 
> _desc, >context_flags,
> + >ctxt_timestamp);
> +av_freep([0].pvBuffer);

Double checking: is this safe?


> +/* SChannel Options */
> +memset(_cred, 0, sizeof(schannel_cred));

SCHANNEL_CRED schannel_cred = { 0 };

> +cleanup:
> +size = len < c->dec_buf_offset ? len : c->dec_buf_offset;
> +if (size) {
> +memcpy(buf, c->dec_buf, size);
> +memmove(c->dec_buf, c->dec_buf + size, c->dec_buf_offset - size);
> +c->dec_buf_offset -= size;
> +
> +return size;
> +}
> +
> +if (ret == 0 && !c->connection_closed)
> +ret = AVERROR(EAGAIN);
> +
> +return ret < 0 ? ret : 0;
> +
> +fail:
> +return ret;

No cleanup in case of failure?

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

Re: [FFmpeg-devel] [PATCH 3/3] WIP: lavf/utils: try to avoid decoding a frame to get the codec parameters

[wm4]

On Wed, 28 Oct 2015 13:30:59 -0400
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Sat, Oct 17, 2015 at 4:34 PM, Matthieu Bouron 
> wrote:
> 
> > From: Matthieu Bouron 
> >
> > Avoid decoding twice images such as jpeg and png, once in the
> > avformat_find_stream_info and once when the actual decode is made.
> >
> > The decoder must honor the skip_frame option in order to skip
> > decoding. For now the AVDISCARD_ALL flag is only set for the mjpeg and
> > png decoders.
> > ---
> >  libavformat/utils.c | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 689473e..67dfffc 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -2676,11 +2676,16 @@ static int has_codec_parameters(AVStream *st,
> > const char **errmsg_ptr)
> >  static int try_decode_frame(AVFormatContext *s, AVStream *st, AVPacket
> > *avpkt,
> >  AVDictionary **options)
> >  {
> > +int i;
> >  const AVCodec *codec;
> >  int got_picture = 1, ret = 0;
> >  AVFrame *frame = av_frame_alloc();
> >  AVSubtitle subtitle;
> >  AVPacket pkt = *avpkt;
> > +int skip_frame;
> > +static const enum AVCodecID no_decode_codecs[] = {
> > +AV_CODEC_ID_MJPEG, AV_CODEC_ID_PNG,
> > +};
> >
> >  if (!frame)
> >  return AVERROR(ENOMEM);
> > @@ -2719,6 +2724,14 @@ static int try_decode_frame(AVFormatContext *s,
> > AVStream *st, AVPacket *avpkt,
> >  goto fail;
> >  }
> >
> > +skip_frame = st->codec->skip_frame;
> > +for (i = 0; i < FF_ARRAY_ELEMS(no_decode_codecs); i++) {
> > +if (st->codec->codec_id == no_decode_codecs[i]) {
> > +st->codec->skip_frame = AVDISCARD_ALL;
> > +break;
> > +}
> > +}  
> 
> 
> I tend to find this kind of specific code in general interfaces fairly
> questionable. Why is this necessary?

The intention of this patch is to make these image codecs discard the
frame data (and not to decompress in the first frame), but still have
them set the parameters of the discarded frame.

It's a very ugly hack to make libavformat set the pixfmt field in the
AVStream codec contexts, without decoding image data. (Which would be
huge and take long.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swr: do not reject channel layouts that use channel 63

[wm4]

On Mon, 26 Oct 2015 20:31:00 +0100
Michael Niedermayer  wrote:

> On Sun, Oct 25, 2015 at 06:31:02PM +0100, wm4 wrote:
> > Channel layouts are essentially uint64_t, and every value is valid.
> > ---
> >  libswresample/options.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)  
> 
> this LGTM if no unsiged int64 support is added to avoptions

Pushed. Not very ideal, but I see no better way to do this right now
(plus libavresample also does it this way).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ronald S. Bultje]

Hi,

On Wed, Oct 28, 2015 at 2:46 PM, Ganesh Ajjanagadde 
wrote:

> On Wed, Oct 28, 2015 at 2:39 PM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Wed, Oct 28, 2015 at 2:31 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> On Wed, Oct 28, 2015 at 11:38 AM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Wed, Oct 28, 2015 at 11:00 AM, Ganesh Ajjanagadde
> >> >  wrote:
> >> >>
> >> >> On Wed, Oct 28, 2015 at 10:53 AM, Ronald S. Bultje <
> rsbul...@gmail.com>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde
> >> >> >  wrote:
> >> >> >>
> >> >> >> On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje
> >> >> >> 
> >> >> >> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde
> >> >> >> > 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje
> >> >> >> >> 
> >> >> >> >> wrote:
> >> >> >> >> > Hi,
> >> >> >> >> >
> >> >> >> >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
> >> >> >> >> >  wrote:
> >> >> >> >> >>
> >> >> >> >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje
> >> >> >> >> >> 
> >> >> >> >> >> wrote:
> >> >> >> >> >> > Hi,
> >> >> >> >> >> >
> >> >> >> >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
> >> >> >> >> >> > 
> >> >> >> >> >> > wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >> ISO C restricts enumerator values to the range of int.
> Thus
> >> >> >> >> >> >> (for
> >> >> >> >> >> >> instance)
> >> >> >> >> >> >> 0x8000
> >> >> >> >> >> >> unfortunately does not work, and throws a warning with
> >> >> >> >> >> >> -Wpedantic
> >> >> >> >> >> >> on
> >> >> >> >> >> >> clang 3.7.
> >> >> >> >> >> >>
> >> >> >> >> >> >> This fixes it by using alternative expressions that
> result
> >> >> >> >> >> >> in
> >> >> >> >> >> >> identical
> >> >> >> >> >> >> values but do not have this issue.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Tested with FATE.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Signed-off-by: Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> >> >> >> >> >> >> ---
> >> >> >> >> >> >>  libavcodec/dca_syncwords.h | 26
> --
> >> >> >> >> >> >>  libavformat/cinedec.c  |  2 +-
> >> >> >> >> >> >>  libavformat/mov_chan.c |  2 +-
> >> >> >> >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
> >> >> >> >> >> >>
> >> >> >> >> >> >> diff --git a/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> b/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> index 3466b6b..6981cb8 100644
> >> >> >> >> >> >> --- a/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> +++ b/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> @@ -19,19 +19,17 @@
> >> >> >> >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
> >> >> >> >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
> >> >> >> >> >> >>
> >> >> >> >> >> >> -enum DCASyncwords {
> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
> >> >> >> >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
> >> >> >> >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
> >> >> >> >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
> >> >> >> >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
> >> >> >> >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
> >> >> >> >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
> >> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
> >> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
> >> >> >> >> >> >> -};
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_X96  0x1D95F262U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XBR  0x655E315EU
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_LBR  0x0A801921U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XLL  0x41A29547U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
> >> >> >> >> >> >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > This one is fine.
> >> >> >> >> >> >
> >> >> >> 

Re: [FFmpeg-devel] [PATCH] vp9_parser: don't overwrite cached timestamps with nopts.

[wm4]

On Wed, 28 Oct 2015 12:21:05 -0400
"Ronald S. Bultje"  wrote:

> ---
>  libavcodec/vp9_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> index 0437097..6713850 100644
> --- a/libavcodec/vp9_parser.c
> +++ b/libavcodec/vp9_parser.c
> @@ -64,7 +64,7 @@ static int parse_frame(AVCodecParserContext *ctx, const 
> uint8_t *buf, int size)
>  if (ctx->pts == AV_NOPTS_VALUE)
>  ctx->pts = s->pts;
>  s->pts = AV_NOPTS_VALUE;
> -} else {
> +} else if (ctx->pts != AV_NOPTS_VALUE) {
>  s->pts = ctx->pts;
>  ctx->pts = AV_NOPTS_VALUE;
>  }

I find this a bit questionable. What is it needed for? Wouldn't it
repeat the previous timestamp if new packets have none?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9_parser: don't overwrite cached timestamps with nopts.

[Ronald S. Bultje]

Hi,

On Wed, Oct 28, 2015 at 3:44 PM, wm4  wrote:

> On Wed, 28 Oct 2015 12:21:05 -0400
> "Ronald S. Bultje"  wrote:
>
> > ---
> >  libavcodec/vp9_parser.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> > index 0437097..6713850 100644
> > --- a/libavcodec/vp9_parser.c
> > +++ b/libavcodec/vp9_parser.c
> > @@ -64,7 +64,7 @@ static int parse_frame(AVCodecParserContext *ctx,
> const uint8_t *buf, int size)
> >  if (ctx->pts == AV_NOPTS_VALUE)
> >  ctx->pts = s->pts;
> >  s->pts = AV_NOPTS_VALUE;
> > -} else {
> > +} else if (ctx->pts != AV_NOPTS_VALUE) {
> >  s->pts = ctx->pts;
> >  ctx->pts = AV_NOPTS_VALUE;
> >  }
>
> I find this a bit questionable. What is it needed for? Wouldn't it
> repeat the previous timestamp if new packets have none?


I don't think so. Let's first go through the problem that I'm seeing, maybe
you see alternate solutions. Then I'll explain (very end) why I don't think
this happens.

So, we're assuming here (this is generally true) that all input to the
parser has timestamps (coming from ivf/webm), and that some frames are
"superframes" which have one invisible (alt-ref) frame (only a reference,
not an actual frame that's ever displayed) packed with the following
visible frame. So each packet in ivf/webm leads to one visible output
frame, but in some cases this requires decoding of multiple (invisible)
references. For frame threading purposes, we split before we send it to the
decoder.

So what you get is:
- ivf/webm file has packet of size a with timestamp b, calls parser
- parser notices that packet is superframe with 2 frames in it
- we output the first (invisible) frame with no timestamp, and cache the
timestamp of the input packet
- utils.c code calls parser again with the same input data (we told it we
didn't consume any), but the (input) timestamp is now set to nopts
- we output the second (visible) frame with the cached timestamp on the
packet

This generally makes sense, the webm/ivf indeed assume that the timestamp
only is valid for the visible frame. Invisible frames have no timestamp
associated with them since they're never displayed.

So, the above code has the issue: what if there's 2 invisible frames packed
in a superframe (followed by the visible frame)? Right now, this happens:
- ivf/webm file has packet of size a with timestamp b, calls parser
- parser notices that packet is superframe with 3 frames in it
- we output the first (invisible) frame with no timestamp, and cache the
timestamp of the input packet
- utils.c code calls parser again with the same input data (we told it we
didn't consume any), but the (input) timestamp is now set to nopts
- we output the second (invisible) frame with no timestamp, and cache the
timestamp of the input packet (which is now set to nopts)
- utils.c code calls parser again with the same input data (we told it we
didn't consume any), but the (input) timestamp is now set to nopts
- we output the third (visible) frame with the cached timestamp on the
packet, which was nopts

The last 3 are wrong; we should only cache timestamps if there is any to be
cached, we should not override the cached timestamp with a new nopts value,
at least not in this particular case.

--
very end
--

Ok, so what about your point: can we output the same timestamp twice? I
don't think so, because as soon as we output the cached timestamp, we reset
the value of the cached timestamp to nopts, so if we were to reuse the
cached timestamp, it would be nopts and the output data would have no
timestamp.

(Hope that wasn't too detailed.)

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

Re: [FFmpeg-devel] [PATCH] avfilter/asrc_sine: fix options typos

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 07:10:24PM +0100, Nicolas George wrote:
> Le septidi 7 brumaire, an CCXXIV, Kyle Swanson a écrit :
> > Signed-off-by: Kyle Swanson 
> > ---
> >  libavfilter/asrc_sine.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Of course ok, thanks.

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH] vp9_parser: don't overwrite cached timestamps with nopts.

[Ronald S. Bultje]

Hi,

On Wed, Oct 28, 2015 at 5:51 PM, wm4  wrote:

> On Wed, 28 Oct 2015 16:05:49 -0400
> "Ronald S. Bultje"  wrote:
>
> > Hi,
> >
> > On Wed, Oct 28, 2015 at 3:44 PM, wm4  wrote:
> >
> > > On Wed, 28 Oct 2015 12:21:05 -0400
> > > "Ronald S. Bultje"  wrote:
> > >
> > > > ---
> > > >  libavcodec/vp9_parser.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> > > > index 0437097..6713850 100644
> > > > --- a/libavcodec/vp9_parser.c
> > > > +++ b/libavcodec/vp9_parser.c
> > > > @@ -64,7 +64,7 @@ static int parse_frame(AVCodecParserContext *ctx,
> > > const uint8_t *buf, int size)
> > > >  if (ctx->pts == AV_NOPTS_VALUE)
> > > >  ctx->pts = s->pts;
> > > >  s->pts = AV_NOPTS_VALUE;
> > > > -} else {
> > > > +} else if (ctx->pts != AV_NOPTS_VALUE) {
> > > >  s->pts = ctx->pts;
> > > >  ctx->pts = AV_NOPTS_VALUE;
> > > >  }
> > >
> > > I find this a bit questionable. What is it needed for? Wouldn't it
> > > repeat the previous timestamp if new packets have none?
> >
> >
> > I don't think so. Let's first go through the problem that I'm seeing,
> maybe
> > you see alternate solutions. Then I'll explain (very end) why I don't
> think
> > this happens.
> >
> > So, we're assuming here (this is generally true) that all input to the
> > parser has timestamps (coming from ivf/webm), and that some frames are
> > "superframes" which have one invisible (alt-ref) frame (only a reference,
> > not an actual frame that's ever displayed) packed with the following
> > visible frame. So each packet in ivf/webm leads to one visible output
> > frame, but in some cases this requires decoding of multiple (invisible)
> > references. For frame threading purposes, we split before we send it to
> the
> > decoder.
> >
> > So what you get is:
> > - ivf/webm file has packet of size a with timestamp b, calls parser
> > - parser notices that packet is superframe with 2 frames in it
> > - we output the first (invisible) frame with no timestamp, and cache the
> > timestamp of the input packet
> > - utils.c code calls parser again with the same input data (we told it we
> > didn't consume any), but the (input) timestamp is now set to nopts
> > - we output the second (visible) frame with the cached timestamp on the
> > packet
> >
> > This generally makes sense, the webm/ivf indeed assume that the timestamp
> > only is valid for the visible frame. Invisible frames have no timestamp
> > associated with them since they're never displayed.
> >
> > So, the above code has the issue: what if there's 2 invisible frames
> packed
> > in a superframe (followed by the visible frame)? Right now, this happens:
> > - ivf/webm file has packet of size a with timestamp b, calls parser
> > - parser notices that packet is superframe with 3 frames in it
> > - we output the first (invisible) frame with no timestamp, and cache the
> > timestamp of the input packet
> > - utils.c code calls parser again with the same input data (we told it we
> > didn't consume any), but the (input) timestamp is now set to nopts
> > - we output the second (invisible) frame with no timestamp, and cache the
> > timestamp of the input packet (which is now set to nopts)
> > - utils.c code calls parser again with the same input data (we told it we
> > didn't consume any), but the (input) timestamp is now set to nopts
> > - we output the third (visible) frame with the cached timestamp on the
> > packet, which was nopts
> >
> > The last 3 are wrong; we should only cache timestamps if there is any to
> be
> > cached, we should not override the cached timestamp with a new nopts
> value,
> > at least not in this particular case.
> >
> > --
> > very end
> > --
> >
> > Ok, so what about your point: can we output the same timestamp twice? I
> > don't think so, because as soon as we output the cached timestamp, we
> reset
> > the value of the cached timestamp to nopts, so if we were to reuse the
> > cached timestamp, it would be nopts and the output data would have no
> > timestamp.
> >
> > (Hope that wasn't too detailed.)
>
> Thanks for the explanations. I didn't know there could be more than 1
> super frame, and I see how the new logic works and doesn't duplicate
> timestamps.
>
> Patch looks good with me then.


TY, pushed.

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

Re: [FFmpeg-devel] [PATCH] avutil/opt: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 6:12 PM, Ganesh Ajjanagadde
 wrote:
> Some warnings do get triggered that will need to be fixed.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/opt.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index 753434d..5abe963 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -414,6 +414,7 @@ void av_opt_set_defaults2(void *s, int mask, int flags);
>   * the error code issued by av_opt_set() if a key/value pair
>   * cannot be set
>   */
> +av_warn_unused_result
>  int av_set_options_string(void *ctx, const char *opts,
>const char *key_val_sep, const char *pairs_sep);
>
> @@ -444,6 +445,7 @@ int av_set_options_string(void *ctx, const char *opts,
>   * Separators must use characters distinct from option names and from each
>   * other.
>   */
> +av_warn_unused_result
>  int av_opt_set_from_string(void *ctx, const char *opts,
> const char *const *shorthand,
> const char *key_val_sep, const char *pairs_sep);
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCH] avutil/opencl: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Fri, Oct 16, 2015 at 8:02 AM, Ganesh Ajjanagadde
 wrote:
> On Thu, Oct 15, 2015 at 11:17 PM, highgod0401  wrote:
>>
>> From: Ganesh Ajjanagadde
>> Date: 2015-10-16 08:08
>> To: ffmpeg-devel
>> CC: Ganesh Ajjanagadde
>> Subject: [FFmpeg-devel] [PATCH] avutil/opencl: add av_warn_unused_result
>> This will trigger a few warnings. My config does not compile the opencl
>> code, so this is untested.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/opencl.h | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/libavutil/opencl.h b/libavutil/opencl.h
>> index e423e55..6a5b0ab 100644
>> --- a/libavutil/opencl.h
>> +++ b/libavutil/opencl.h
>> @@ -81,6 +81,7 @@ typedef struct {
>>   *
>>   * @return  >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_get_device_list(AVOpenCLDeviceList **device_list);
>>
>>  /**
>> @@ -108,6 +109,7 @@ void av_opencl_free_device_list(AVOpenCLDeviceList
>> **device_list);
>>   * @return >=0 on success, a negative error code in case of failure
>>   * @see av_opencl_get_option()
>>   */
>> +av_warn_unused_result
>>  int av_opencl_set_option(const char *key, const char *val);
>>
>>  /**
>> @@ -119,6 +121,7 @@ int av_opencl_set_option(const char *key, const char
>> *val);
>>   * @return  >=0 on success, a negative error code in case of failure
>>   * @see av_opencl_set_option()
>>   */
>> +av_warn_unused_result
>>  int av_opencl_get_option(const char *key, uint8_t **out_val);
>>
>>  /**
>> @@ -161,6 +164,7 @@ const char *av_opencl_errstr(cl_int status);
>>   * @param kernel_codekernel code to be compiled in the OpenCL runtime
>> environment
>>   * @return  >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_register_kernel_code(const char *kernel_code);
>>
>>  /**
>> @@ -170,6 +174,7 @@ int av_opencl_register_kernel_code(const char
>> *kernel_code);
>>   *   application program, ignored if set to NULL
>>   * @return >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_init(AVOpenCLExternalEnv *ext_opencl_env);
>>
>>  /**
>> @@ -205,6 +210,7 @@ cl_command_queue av_opencl_get_command_queue(void);
>>   * @param host_ptr host pointer of the OpenCL buffer
>>   * @return >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_buffer_create(cl_mem *cl_buf, size_t cl_buf_size, int flags,
>> void *host_ptr);
>>
>>  /**
>> @@ -215,6 +221,7 @@ int av_opencl_buffer_create(cl_mem *cl_buf, size_t
>> cl_buf_size, int flags, void
>>   * @param buf_size  size in bytes of the source and destination
>> buffers
>>   * @return >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_buffer_write(cl_mem dst_cl_buf, uint8_t *src_buf, size_t
>> buf_size);
>>
>>  /**
>> @@ -225,6 +232,7 @@ int av_opencl_buffer_write(cl_mem dst_cl_buf, uint8_t
>> *src_buf, size_t buf_size)
>>   * @param buf_size  size in bytes of the source and destination
>> buffers
>>   * @return >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_buffer_read(uint8_t *dst_buf, cl_mem src_cl_buf, size_t
>> buf_size);
>>
>>  /**
>> @@ -240,6 +248,7 @@ int av_opencl_buffer_read(uint8_t *dst_buf, cl_mem
>> src_cl_buf, size_t buf_size);
>>   * @param src_plane_num  number of source image planes
>>   * @return >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_buffer_write_image(cl_mem dst_cl_buf, size_t cl_buffer_size,
>> int dst_cl_offset,
>>   uint8_t **src_data, int *plane_size, int
>> plane_num);
>>
>> @@ -253,6 +262,7 @@ int av_opencl_buffer_write_image(cl_mem dst_cl_buf,
>> size_t cl_buffer_size, int d
>>   * @param src_cl_buf_sizesize in bytes of OpenCL buffer
>>   * @return >=0 on success, a negative error code in case of failure
>>   */
>> +av_warn_unused_result
>>  int av_opencl_buffer_read_image(uint8_t **dst_data, int *plane_size, int
>> plane_num,
>>  cl_mem src_cl_buf, size_t cl_buffer_size);
>>
>> --
>> 2.6.1
>>
>> Hi
>>
>> Could I ask a question? Why should we add the av_warn_unused_result?
>
> It is not an absolute necessity, but highly recommended. Basically,
> functions which can fail and propagate error codes need their error
> codes propagated. See the original commit:
> 1d4af04adf99301e21d7364d72f5570f5219083a for its rationale. It already
> has caught quite a few bugs (some of them CIDs), with no introduction
> of false positives yet. As long as one judiciously applies it (and not
> just everywhere), it should be very helpful.
>
> Note that it not only helps FFmpeg, but also users of FFmpeg who use
> our headers: if they do not 

Re: [FFmpeg-devel] [PATCH 03/11] avdevice/sndio: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Fri, Oct 16, 2015 at 5:31 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Oct 16, 2015 at 11:46 AM, Michael Niedermayer
>  wrote:
>> On Thu, Oct 15, 2015 at 10:22:17PM -0400, Ganesh Ajjanagadde wrote:
>>> This does not trigger any warnings, but adds robustness.
>>> Untested, as my configure does not compile this file.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavdevice/sndio.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> iam not the maintainer of this but its probably ok
>
> Will wait, will need at the minimum a compile test (to ensure that the
> attributes stuff is present).

To anyone with ability to compile sndio stuff, ping - I am not sure
whether the libavutil/attributes header is needed or not, and can't
test on my end.

>
>>
>> [...]
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Many things microsoft did are stupid, but not doing something just because
>> microsoft did it is even more stupid. If everything ms did were stupid they
>> would be bankrupt already.
>>
>> ___
>> 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 02/11] avcodec/nellymoserenc: use log2 instead of log()/M_LN2

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/nellymoserenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
index d7368d0..d998dba 100644
--- a/libavcodec/nellymoserenc.c
+++ b/libavcodec/nellymoserenc.c
@@ -318,7 +318,7 @@ static void encode_block(NellyMoserEncodeContext *s, 
unsigned char *output, int
+ s->mdct_out[i + NELLY_BUF_LEN] * s->mdct_out[i + 
NELLY_BUF_LEN];
 }
 cand[band] =
-log(FFMAX(1.0, coeff_sum / (ff_nelly_band_sizes_table[band] << 
7))) * 1024.0 / M_LN2;
+log2(FFMAX(1.0, coeff_sum / (ff_nelly_band_sizes_table[band] << 
7))) * 1024.0;
 }
 
 if (s->avctx->trellis) {
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] vp9_parser: don't overwrite cached timestamps with nopts.

[James Almer]

On 10/28/2015 11:16 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Oct 28, 2015 at 5:51 PM, wm4  wrote:
> 
>> On Wed, 28 Oct 2015 16:05:49 -0400
>> "Ronald S. Bultje"  wrote:
>>
>>> Hi,
>>>
>>> On Wed, Oct 28, 2015 at 3:44 PM, wm4  wrote:
>>>
 On Wed, 28 Oct 2015 12:21:05 -0400
 "Ronald S. Bultje"  wrote:

> ---
>  libavcodec/vp9_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> index 0437097..6713850 100644
> --- a/libavcodec/vp9_parser.c
> +++ b/libavcodec/vp9_parser.c
> @@ -64,7 +64,7 @@ static int parse_frame(AVCodecParserContext *ctx,
 const uint8_t *buf, int size)
>  if (ctx->pts == AV_NOPTS_VALUE)
>  ctx->pts = s->pts;
>  s->pts = AV_NOPTS_VALUE;
> -} else {
> +} else if (ctx->pts != AV_NOPTS_VALUE) {
>  s->pts = ctx->pts;
>  ctx->pts = AV_NOPTS_VALUE;
>  }

 I find this a bit questionable. What is it needed for? Wouldn't it
 repeat the previous timestamp if new packets have none?
>>>
>>>
>>> I don't think so. Let's first go through the problem that I'm seeing,
>> maybe
>>> you see alternate solutions. Then I'll explain (very end) why I don't
>> think
>>> this happens.
>>>
>>> So, we're assuming here (this is generally true) that all input to the
>>> parser has timestamps (coming from ivf/webm), and that some frames are
>>> "superframes" which have one invisible (alt-ref) frame (only a reference,
>>> not an actual frame that's ever displayed) packed with the following
>>> visible frame. So each packet in ivf/webm leads to one visible output
>>> frame, but in some cases this requires decoding of multiple (invisible)
>>> references. For frame threading purposes, we split before we send it to
>> the
>>> decoder.
>>>
>>> So what you get is:
>>> - ivf/webm file has packet of size a with timestamp b, calls parser
>>> - parser notices that packet is superframe with 2 frames in it
>>> - we output the first (invisible) frame with no timestamp, and cache the
>>> timestamp of the input packet
>>> - utils.c code calls parser again with the same input data (we told it we
>>> didn't consume any), but the (input) timestamp is now set to nopts
>>> - we output the second (visible) frame with the cached timestamp on the
>>> packet
>>>
>>> This generally makes sense, the webm/ivf indeed assume that the timestamp
>>> only is valid for the visible frame. Invisible frames have no timestamp
>>> associated with them since they're never displayed.
>>>
>>> So, the above code has the issue: what if there's 2 invisible frames
>> packed
>>> in a superframe (followed by the visible frame)? Right now, this happens:
>>> - ivf/webm file has packet of size a with timestamp b, calls parser
>>> - parser notices that packet is superframe with 3 frames in it
>>> - we output the first (invisible) frame with no timestamp, and cache the
>>> timestamp of the input packet
>>> - utils.c code calls parser again with the same input data (we told it we
>>> didn't consume any), but the (input) timestamp is now set to nopts
>>> - we output the second (invisible) frame with no timestamp, and cache the
>>> timestamp of the input packet (which is now set to nopts)
>>> - utils.c code calls parser again with the same input data (we told it we
>>> didn't consume any), but the (input) timestamp is now set to nopts
>>> - we output the third (visible) frame with the cached timestamp on the
>>> packet, which was nopts
>>>
>>> The last 3 are wrong; we should only cache timestamps if there is any to
>> be
>>> cached, we should not override the cached timestamp with a new nopts
>> value,
>>> at least not in this particular case.
>>>
>>> --
>>> very end
>>> --
>>>
>>> Ok, so what about your point: can we output the same timestamp twice? I
>>> don't think so, because as soon as we output the cached timestamp, we
>> reset
>>> the value of the cached timestamp to nopts, so if we were to reuse the
>>> cached timestamp, it would be nopts and the output data would have no
>>> timestamp.
>>>
>>> (Hope that wasn't too detailed.)
>>
>> Thanks for the explanations. I didn't know there could be more than 1
>> super frame, and I see how the new logic works and doesn't duplicate
>> timestamps.
>>
>> Patch looks good with me then.
> 
> 
> TY, pushed.
> 
> Ronald

Did you forget to update the ref files for fate-vp9-10-show-existing-frame and
fate-vp9-16-intra-only? Because they are failing in a lot of fate clients.

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

Re: [FFmpeg-devel] [PATCH] avdevice/dshow_enummediatypes: check return of av_malloc

[Michael Niedermayer]

On Tue, Oct 27, 2015 at 08:09:03PM -0400, Ganesh Ajjanagadde wrote:
> Untested.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavdevice/dshow_enummediatypes.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavdevice/dshow_enummediatypes.c 
> b/libavdevice/dshow_enummediatypes.c
> index 5b69a5b..5a24870 100644
> --- a/libavdevice/dshow_enummediatypes.c
> +++ b/libavdevice/dshow_enummediatypes.c
> @@ -37,6 +37,8 @@ libAVEnumMediaTypes_Next(libAVEnumMediaTypes *this, 
> unsigned long n,
>  if (!this->pos && n == 1) {
>  if (!IsEqualGUID(>type.majortype, _NULL)) {
>  AM_MEDIA_TYPE *type = av_malloc(sizeof(AM_MEDIA_TYPE));
> +if (!type)
> +return AVERROR(ENOMEM);

I cannot test this either but the surrounding code returns
E_POINTER, E_OUTOFMEMORY, ...
not AVERROR*
so this does not look correct, or at least inconsistent

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

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


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

Re: [FFmpeg-devel] [PATCH] avfilter/tremolo: fix wavetable buffer size

[Kyle Swanson]

 This fixes an obvious bug for sub 1-hz modulation frequencies.
Wavetable buffer was too small for frequencies under 1 hz, and also
too big for frequencies above 1hz. One cycle is all we need.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] avutil/buffer: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 7:10 PM, Ganesh Ajjanagadde
 wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/buffer.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavutil/buffer.h b/libavutil/buffer.h
> index b4399fd..e0dbc8a 100644
> --- a/libavutil/buffer.h
> +++ b/libavutil/buffer.h
> @@ -26,6 +26,7 @@
>  #define AVUTIL_BUFFER_H
>
>  #include 
> +#include "attributes.h"
>
>  /**
>   * @defgroup lavu_buffer AVBuffer
> @@ -178,6 +179,7 @@ int av_buffer_get_ref_count(const AVBufferRef *buf);
>   *written in its place. On failure, buf is left untouched.
>   * @return 0 on success, a negative AVERROR on failure.
>   */
> +av_warn_unused_result
>  int av_buffer_make_writable(AVBufferRef **buf);
>
>  /**
> @@ -195,6 +197,7 @@ int av_buffer_make_writable(AVBufferRef **buf);
>   * reference to it (i.e. the one passed to this function). In all other cases
>   * a new buffer is allocated and the data is copied.
>   */
> +av_warn_unused_result
>  int av_buffer_realloc(AVBufferRef **buf, int size);
>
>  /**
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCH 1/2] swresample/swresample: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 9:31 PM, Ganesh Ajjanagadde
 wrote:
> This will trigger a few warnings (e.g in avfilter) that need to be
> fixed.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libswresample/swresample.h | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/libswresample/swresample.h b/libswresample/swresample.h
> index 10eaebc..d21084f 100644
> --- a/libswresample/swresample.h
> +++ b/libswresample/swresample.h
> @@ -220,6 +220,7 @@ struct SwrContext *swr_alloc(void);
>   * @param[in,out]   s Swr context to initialize
>   * @return AVERROR error code in case of failure.
>   */
> +av_warn_unused_result
>  int swr_init(struct SwrContext *s);
>
>  /**
> @@ -307,6 +308,7 @@ void swr_close(struct SwrContext *s);
>   *
>   * @return number of samples output per channel, negative value on error
>   */
> +av_warn_unused_result
>  int swr_convert(struct SwrContext *s, uint8_t **out, int out_count,
>  const uint8_t **in , int in_count);
>
> @@ -354,6 +356,7 @@ int64_t swr_next_pts(struct SwrContext *s, int64_t pts);
>   *@li compensation unsupported by resampler, or
>   *@li swr_init() fails when called.
>   */
> +av_warn_unused_result
>  int swr_set_compensation(struct SwrContext *s, int sample_delta, int 
> compensation_distance);
>
>  /**
> @@ -364,6 +367,7 @@ int swr_set_compensation(struct SwrContext *s, int 
> sample_delta, int compensatio
>   *indexes, -1 for a muted channel)
>   * @return >= 0 on success, or AVERROR error code in case of failure.
>   */
> +av_warn_unused_result
>  int swr_set_channel_mapping(struct SwrContext *s, const int *channel_map);
>
>  /**
> @@ -375,6 +379,7 @@ int swr_set_channel_mapping(struct SwrContext *s, const 
> int *channel_map);
>   * @param stride  offset between lines of the matrix
>   * @return  >= 0 on success, or AVERROR error code in case of failure.
>   */
> +av_warn_unused_result
>  int swr_set_matrix(struct SwrContext *s, const double *matrix, int stride);
>
>  /**
> @@ -395,6 +400,7 @@ int swr_set_matrix(struct SwrContext *s, const double 
> *matrix, int stride);
>   *
>   * @return >= 0 on success, or a negative AVERROR code on failure
>   */
> +av_warn_unused_result
>  int swr_drop_output(struct SwrContext *s, int count);
>
>  /**
> @@ -408,6 +414,7 @@ int swr_drop_output(struct SwrContext *s, int count);
>   *
>   * @return >= 0 on success, or a negative AVERROR code on failure
>   */
> +av_warn_unused_result
>  int swr_inject_silence(struct SwrContext *s, int count);
>
>  /**
> @@ -526,6 +533,7 @@ const char *swresample_license(void);
>   * @return0 on success, AVERROR on failure or nonmatching
>   *configuration.
>   */
> +av_warn_unused_result
>  int swr_convert_frame(SwrContext *swr,
>AVFrame *output, const AVFrame *input);
>
> @@ -543,6 +551,7 @@ int swr_convert_frame(SwrContext *swr,
>   * @param input   input AVFrame
>   * @return0 on success, AVERROR on failure.
>   */
> +av_warn_unused_result
>  int swr_config_frame(SwrContext *swr, const AVFrame *out, const AVFrame *in);
>
>  /**
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCHv2] avcodec/dvenc: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

On Sun, Oct 4, 2015 at 8:44 PM, Ganesh Ajjanagadde
 wrote:
> On Sun, Sep 20, 2015 at 9:09 AM, Ganesh Ajjanagadde
>  wrote:
>> s->frame is non-const, so this casts them explicitly.
>> This suppresses -Wdiscarded-qualifiers seen in e.g
>> http://fate.ffmpeg.org/log.cgi?time=20150919100330=compile=x86_64-archlinux-gcc-enableshared.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/dvenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
>> index 5de12cc..14b8758 100644
>> --- a/libavcodec/dvenc.c
>> +++ b/libavcodec/dvenc.c
>> @@ -721,7 +721,7 @@ static int dvvideo_encode_frame(AVCodecContext *c, 
>> AVPacket *pkt,
>>  return ret;
>>
>>  c->pix_fmt= s->sys->pix_fmt;
>> -s->frame  = frame;
>> +s->frame  = (AVFrame *)frame;
>>  #if FF_API_CODED_FRAME
>>  FF_DISABLE_DEPRECATION_WARNINGS
>>  c->coded_frame->key_frame = 1;
>> --
>> 2.5.2
>>
>
> ping. I do not know whether there is a better way of doing this that
> avoids the cast; hopefully someone with expertise on this can check.

Strange, can't even reproduce this "discarded qualifiers" on GCC,
although the fate log clearly shows a warning. Examining the code,
there should be no issue whatsoever. Consider the patch dropped.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 04/11] avcodec/zmbvenc: use log2 instead of log()/M_LN2

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/zmbvenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index df06e37..e832bed 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -277,7 +277,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
 int lvl = 9;
 
 for(i=1; i<256; i++)
-score_tab[i]= -i * log(i/(double)(ZMBV_BLOCK*ZMBV_BLOCK)) * 
(256/M_LN2);
+score_tab[i]= -i * log2(i/(double)(ZMBV_BLOCK*ZMBV_BLOCK)) * 256;
 
 c->avctx = avctx;
 
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 03/11] avcodec/snowenc: use log2 instead of log() / log(2...)

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.
The expression has also been accordingly simplified.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/snowenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index 7e8269c..fb0cd3f 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -1547,7 +1547,7 @@ static void calculate_visual_weight(SnowContext *s, Plane 
*p){
 }
 }
 
-b->qlog= (int)(log(352256.0/sqrt(error)) / log(pow(2.0, 
1.0/QROOT))+0.5);
+b->qlog= (int)(QROOT * log2(352256.0/sqrt(error)) + 0.5);
 }
 }
 }
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 10/11] avfilter/vf_ssim: use log10 instead of log()/log(10)

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_ssim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index ce1e3db..6b2a8d7 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -176,7 +176,7 @@ static float ssim_plane(SSIMDSPContext *dsp,
 
 static double ssim_db(double ssim, double weight)
 {
-return 10 * (log(weight) / log(10) - log(weight - ssim) / log(10));
+return 10 * (log10(weight) - log10(weight - ssim));
 }
 
 static AVFrame *do_ssim(AVFilterContext *ctx, AVFrame *main,
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 08/11] avfilter/avf_showvolume: use log10 instead of log()/M_LN10

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/avf_showvolume.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/avf_showvolume.c b/libavfilter/avf_showvolume.c
index 95b5388..395375a 100644
--- a/libavfilter/avf_showvolume.c
+++ b/libavfilter/avf_showvolume.c
@@ -197,7 +197,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 max = FFMAX(max, src[i]);
 
 max = av_clipf(max, 0, 1);
-values[VAR_VOLUME] = 20.0 * log(max) / M_LN10;
+values[VAR_VOLUME] = 20.0 * log10(max);
 values[VAR_CHANNEL] = c;
 color = av_expr_eval(s->c_expr, values, NULL);
 
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 09/11] avfilter/vf_psnr: use log10 instead of log()/log(10)

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_psnr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index 36bbab2..bce5c51 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -72,7 +72,7 @@ static inline unsigned pow2(unsigned base)
 
 static inline double get_psnr(double mse, uint64_t nb_frames, int max)
 {
-return 10.0 * log(pow2(max) / (mse / nb_frames)) / log(10.0);
+return 10.0 * log10(pow2(max) / (mse / nb_frames));
 }
 
 static uint64_t sse_line_8bit(const uint8_t *main_line,  const uint8_t 
*ref_line, int outw)
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] avutil/ripemd: make rol macro more robust by adding parentheses

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 11:52 AM, James Almer  wrote:
> On 10/27/2015 9:00 PM, Ganesh Ajjanagadde wrote:
>> This ensures that the macro remains correct in the sense of allowing
>> expressions for value and bits, by placing the value and bits expressions 
>> within
>> parentheses.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/ripemd.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/ripemd.c b/libavutil/ripemd.c
>> index d247fb4..6777c99 100644
>> --- a/libavutil/ripemd.c
>> +++ b/libavutil/ripemd.c
>> @@ -85,7 +85,7 @@ static const int WB[80] = {
>>  12, 15, 10,  4,  1,  5,  8,  7,  6,  2, 13, 14,  0,  3,  9, 11
>>  };
>>
>> -#define rol(value, bits) ((value << bits) | (value >> (32 - bits)))
>> +#define rol(value, bits) (((value) << (bits)) | ((value) >> (32 - (bits
>>
>>  #define ROUND128_0_TO_15(a,b,c,d,e,f,g,h)   \
>>  a = rol(a + ((  b ^ c  ^ d)  + block[WA[n]]), ROTA[n]); \
>>
>
> LGTM

pushed, thanks.

>
> ___
> 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] avutil/frame: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 7:47 PM, Ganesh Ajjanagadde
 wrote:
> This is going to trigger a lot of warnings all over the place that need
> fixing. Main culprits are in avfilter, when one tries to copy a frame
> without checking whether src and dest formats actually are compatible.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/frame.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 9c6061a..5dfac64 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -575,6 +575,7 @@ void av_frame_free(AVFrame **frame);
>   *
>   * @return 0 on success, a negative AVERROR on error
>   */
> +av_warn_unused_result
>  int av_frame_ref(AVFrame *dst, const AVFrame *src);
>
>  /**
> @@ -613,6 +614,7 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
>   *
>   * @return 0 on success, a negative AVERROR on error.
>   */
> +av_warn_unused_result
>  int av_frame_get_buffer(AVFrame *frame, int align);
>
>  /**
> @@ -640,6 +642,7 @@ int av_frame_is_writable(AVFrame *frame);
>   * @see av_frame_is_writable(), av_buffer_is_writable(),
>   * av_buffer_make_writable()
>   */
> +av_warn_unused_result
>  int av_frame_make_writable(AVFrame *frame);
>
>  /**
> @@ -653,6 +656,7 @@ int av_frame_make_writable(AVFrame *frame);
>   *
>   * @return >= 0 on success, a negative AVERROR on error.
>   */
> +av_warn_unused_result
>  int av_frame_copy(AVFrame *dst, const AVFrame *src);
>
>  /**
> @@ -663,6 +667,7 @@ int av_frame_copy(AVFrame *dst, const AVFrame *src);
>   * aspect ratio (for video), but not width/height or channel layout.
>   * Side data is also copied.
>   */
> +av_warn_unused_result
>  int av_frame_copy_props(AVFrame *dst, const AVFrame *src);
>
>  /**
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCH] avutil/opencl_internal: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 6:24 PM, Ganesh Ajjanagadde
 wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/opencl_internal.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/opencl_internal.h b/libavutil/opencl_internal.h
> index dacd930..a4f5885 100644
> --- a/libavutil/opencl_internal.h
> +++ b/libavutil/opencl_internal.h
> @@ -30,4 +30,5 @@ typedef struct {
>  void *ctx;
>  } FFOpenclParam;
>
> +av_warn_unused_result
>  int avpriv_opencl_set_parameter(FFOpenclParam *opencl_param, ...);
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCH] avutil/audio_fifo: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Fri, Oct 16, 2015 at 5:16 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Oct 16, 2015 at 11:44 AM, Michael Niedermayer
>  wrote:
>> On Thu, Oct 15, 2015 at 07:26:04PM -0400, Ganesh Ajjanagadde wrote:
>>> This one should not trigger any warnings, but will be useful for future
>>> robustness.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/audio_fifo.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavutil/audio_fifo.h b/libavutil/audio_fifo.h
>>> index d93be2a..24f91da 100644
>>> --- a/libavutil/audio_fifo.h
>>> +++ b/libavutil/audio_fifo.h
>>> @@ -73,6 +73,7 @@ AVAudioFifo *av_audio_fifo_alloc(enum AVSampleFormat 
>>> sample_fmt, int channels,
>>>   * @param nb_samples  new allocation size, in samples
>>>   * @return0 if OK, or negative AVERROR code on failure
>>>   */
>>> +av_warn_unused_result
>>>  int av_audio_fifo_realloc(AVAudioFifo *af, int nb_samples);
>>
>> probably ok
>> strictly speaking one could check the size after the call instead of
>> the returb value i think
>
> I guess so, but that is an unusual use as far as I can tell. Will
> leave it up to someone else before pushing. If no one replies in the
> next 48 h, I will push.

pushed with the above caveat mentioned in the commit message.

>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> It is what and why we do it that matters, not just one of them.
>>
>> ___
>> 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 01/11] ffmpeg: use log10 instead of log()/log(10)

[Ganesh Ajjanagadde]

This is more concise and conveys the intent better.
Furthermore, it is likely more precise as well due to lack of floating
point division.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index f91fb7b..148c21b 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1244,7 +1244,7 @@ static void do_video_out(AVFormatContext *s,
 
 static double psnr(double d)
 {
-return -10.0 * log(d) / log(10.0);
+return -10.0 * log10(d);
 }
 
 static void do_video_stats(OutputStream *ost, int frame_size)
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 07/11] avfilter/avf_showspectrum: use log10 instead of log()/...

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/avf_showspectrum.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 936db60..7d5c438 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -386,7 +386,7 @@ static int plot_spectrum_column(AVFilterLink *inlink, 
AVFrame *insamples)
 a = cbrt(a);
 break;
 case LOG:
-a = 1 - log(FFMAX(FFMIN(1, a), 1e-6)) / log(1e-6); // zero = 
-120dBFS
+a = 1 + log10(FFMAX(FFMIN(1, a), 1e-6)) / 6; // zero = -120dBFS
 break;
 default:
 av_assert0(0);
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 06/11] avfilter/af_volumedetect: use log10 instead of hardcoded constant

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/af_volumedetect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index 01f24ba..ad5fef3 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -78,7 +78,7 @@ static inline double logdb(uint64_t v)
 double d = v / (double)(0x8000 * 0x8000);
 if (!v)
 return MAX_DB;
-return log(d) * -4.3429448190325182765112891891660508229; /* -10/log(10) */
+return log10(d) * 10;
 }
 
 static void print_stats(AVFilterContext *ctx)
-- 
2.6.2

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

[FFmpeg-devel] Idea for a better filter that reduces noise

[P. van Gaans]

You all know the CSI episodes where they read a license plate by 
"enhancing" some super-grainy security footage. Nonsense, right? Well, 
maybe not.. If the car was parked. And it seems what I found doesn't 
exist yet. (but perhaps I overlooked it)


If you quickly want to know what I'm on about, take a look at these images:

http://members.ziggo.nl/sinaasappel/images/1_original.jpg (original)
http://members.ziggo.nl/sinaasappel/images/2_40framewind.jpg (40f WIND)
http://members.ziggo.nl/sinaasappel/images/3_wind_hqdn3d.jpg (comparison 
with hqdn3d and pp=tn)


All have limited jpeg compression, but I can deliver PNG files and an 
XCF to experiment for yourself if desired.


So what is WIND? It's what you see if you forget/fail to do motion 
detection. (like I did in the images) Also, Wind Is Not a Denoiser. ;-) 
It's a way to increase the exposure time of the camera used to shoot a 
movie after it's been shot. For the images, I took a 2-second somewhat 
grainy clip of a building with nearly no motion. I output the frames to 
PNG and load them as layers in The GIMP. I set the opacity for the 
bottom layer to 100. The layer above that 50. (100/2) Above that 33.3. 
(100/3) 25, 20, 16.7 and so on. Every image with noise is "wrong", some 
too dark and some too light. On average, they are spot-on. The 
advantage: improved quality and better compression.


To make this into a proper useable filter, it would need to do this:

1. Deshake/stabilize the image.
2. Divide image in blocks. (e.g. 8x8 pixels)
3. Figure out it the average color of an 8x8 block is changing during 
the next X frames. If not, it's probably not moving and you can average 
the values. If it is or is about to, it should be averaged over fewer 
frames or not at all. Any area that is about to move will gradually pick 
up noise so it doesn't look too unnatural.

4. Reshake the image.

Will I do this myself? Maybe, but don't hold your breath. I'm just 
sharing this in case somebody finds it interesting and to make sure 
nobody can patent it. (assuming it hasn't been done already)


Best regards,

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

Re: [FFmpeg-devel] [PATCH] avdevice/dshow_enummediatypes: check return of av_malloc

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 10:00 PM, Michael Niedermayer
 wrote:
> On Tue, Oct 27, 2015 at 08:09:03PM -0400, Ganesh Ajjanagadde wrote:
>> Untested.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavdevice/dshow_enummediatypes.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavdevice/dshow_enummediatypes.c 
>> b/libavdevice/dshow_enummediatypes.c
>> index 5b69a5b..5a24870 100644
>> --- a/libavdevice/dshow_enummediatypes.c
>> +++ b/libavdevice/dshow_enummediatypes.c
>> @@ -37,6 +37,8 @@ libAVEnumMediaTypes_Next(libAVEnumMediaTypes *this, 
>> unsigned long n,
>>  if (!this->pos && n == 1) {
>>  if (!IsEqualGUID(>type.majortype, _NULL)) {
>>  AM_MEDIA_TYPE *type = av_malloc(sizeof(AM_MEDIA_TYPE));
>> +if (!type)
>> +return AVERROR(ENOMEM);
>
> I cannot test this either but the surrounding code returns
> E_POINTER, E_OUTOFMEMORY, ...
> not AVERROR*
> so this does not look correct, or at least inconsistent

Looks like some Windows thing, I guess E_OUTOFMEMORY is the best
choice. This needs to wait for a review from a Windows using dev IMO.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Freedom in capitalist society always remains about the same as it was in
> ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
>
> ___
> 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] avutil/mathematics: make av_gcd more robust

[Ganesh Ajjanagadde]

This ensures that no undefined behavior is invoked, while retaining
identical return values in all cases and at no loss of performance
(identical asm on clang and gcc).
Essentially, this patch exchanges undefined behavior with implementation
defined behavior, a strict improvement.

Rationale:
1. The ideal solution is to have the return type a uint64_t. This
unfortunately requires an API change.
2. The only pathological behavior happens if both arguments are
INT64_MIN, to the best of my knowledge. In such a case, the
implementation defined behavior is invoked in the sense that UINT64_MAX
is interpreted as INT64_MIN, which any reasonable implementation will
do. In any case, any usage where both arguments are INT64_MIN is a
fuzzer anyway.
3. Alternatives of checking, etc require branching and lose performance
for no concrete gain - no client cares about av_gcd's actual value when
both args are INT64_MIN. Even if it did, on sane platforms (e.g all the
ones FFmpeg cares about), it produces a correct gcd, namely INT64_MIN.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/mathematics.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/mathematics.c b/libavutil/mathematics.c
index 16e4eba..fde460c 100644
--- a/libavutil/mathematics.c
+++ b/libavutil/mathematics.c
@@ -52,7 +52,7 @@ int64_t av_gcd(int64_t a, int64_t b) {
 v -= u;
 v >>= ff_ctzll(v);
 }
-return u << k;
+return (uint64_t)u << k;
 }
 
 int64_t av_rescale_rnd(int64_t a, int64_t b, int64_t c, enum AVRounding rnd)
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH 1/2] swscale/swscale_internal: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 9:46 PM, Ganesh Ajjanagadde
 wrote:
> This triggers a few warnings that need to be fixed.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libswscale/swscale_internal.h | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
> index 27a40af..6e4d031 100644
> --- a/libswscale/swscale_internal.h
> +++ b/libswscale/swscale_internal.h
> @@ -634,6 +634,7 @@ typedef struct SwsContext {
>  //FIXME check init (where 0)
>
>  SwsFunc ff_yuv2rgb_get_func_ptr(SwsContext *c);
> +av_warn_unused_result
>  int ff_yuv2rgb_c_init_tables(SwsContext *c, const int inv_table[4],
>   int fullRange, int brightness,
>   int contrast, int saturation);
> @@ -1017,6 +1018,7 @@ typedef struct VScalerContext
>  int ff_init_slice_from_src(SwsSlice * s, uint8_t *src[4], int stride[4], int 
> srcW, int lumY, int lumH, int chrY, int chrH, int relative);
>
>  // Initialize scaler filter descriptor chain
> +av_warn_unused_result
>  int ff_init_filters(SwsContext *c);
>
>  // Free all filter data
> @@ -1031,23 +1033,29 @@ int ff_free_filters(SwsContext *c);
>  int ff_rotate_slice(SwsSlice *s, int lum, int chr);
>
>  /// initializes gamma conversion descriptor
> +av_warn_unused_result
>  int ff_init_gamma_convert(SwsFilterDescriptor *desc, SwsSlice * src, 
> uint16_t *table);
>
>  /// initializes lum pixel format conversion descriptor
> +av_warn_unused_result
>  int ff_init_desc_fmt_convert(SwsFilterDescriptor *desc, SwsSlice * src, 
> SwsSlice *dst, uint32_t *pal);
>
>  /// initializes lum horizontal scaling descriptor
> +av_warn_unused_result
>  int ff_init_desc_hscale(SwsFilterDescriptor *desc, SwsSlice *src, SwsSlice 
> *dst, uint16_t *filter, int * filter_pos, int filter_size, int xInc);
>
>  /// initializes chr pixel format conversion descriptor
> +av_warn_unused_result
>  int ff_init_desc_cfmt_convert(SwsFilterDescriptor *desc, SwsSlice * src, 
> SwsSlice *dst, uint32_t *pal);
>
>  /// initializes chr horizontal scaling descriptor
> +av_warn_unused_result
>  int ff_init_desc_chscale(SwsFilterDescriptor *desc, SwsSlice *src, SwsSlice 
> *dst, uint16_t *filter, int * filter_pos, int filter_size, int xInc);
>
>  int ff_init_desc_no_chr(SwsFilterDescriptor *desc, SwsSlice * src, SwsSlice 
> *dst);
>
>  /// initializes vertical scaling descriptors
> +av_warn_unused_result
>  int ff_init_vscale(SwsContext *c, SwsFilterDescriptor *desc, SwsSlice *src, 
> SwsSlice *dst);
>
>  /// setup vertical scaler functions
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCH] avutil/parseutils: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 10:24 PM, Ganesh Ajjanagadde  wrote:
> On Thu, Oct 15, 2015 at 10:22 PM, Ganesh Ajjanagadde  wrote:
>> On Thu, Oct 15, 2015 at 10:16 PM, James Almer  wrote:
>>> On 10/15/2015 10:23 PM, Ganesh Ajjanagadde wrote:
 On Thu, Oct 15, 2015 at 8:06 PM, James Almer  wrote:
> On 10/15/2015 8:52 PM, Ganesh Ajjanagadde wrote:
>> This triggers a few warnings that will need to be fixed - not that bad,
>> the current code is mostly fine.
>>
>
> I think i asked you before, but in any case i'll do it again. Please,
> send patchsets contained in a single thread. You're making things
> hard to track and organize on people's inboxes.
> See https://kernel.org/pub/software/scm/git/docs/git-send-email.html
> --thread, --chain-reply-to and --in-reply-to options.

 Would greatly appreciate a command/command sequence: I am on master
 (which is ahead of origin/master) and contains only the avutil warning
 stuff (many commits). How do I get a proper chain of emails that you
 would like?

>
> Thanks.
>>>
>>> When you send several mails with a single git send-email command, it
>>> should by default send every email after the first as a reply to the
>>> first, effectively making a single "thread".
>>
>> Sorry, but gmail smtp/send-email does not let me do this - I have
>> tried multiple patches in a single git send-email, and it closes the
>> connection.
>
> The engineers at Google must have fixed something - I tried it just
> now in the manner you described for the avdevice patches.

ping

>
>>
>>>
>>> When you send one email at a time, you'll have to use --in-reply-to
>>> as part of the git send-email command, using the message ID of the email
>>> you want as parent as argument.
>>> ___
>>> 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] avutil/pixdesc: add av_warn_unused_result to av_pix_fmt_get_chroma_sub_sample

[Ganesh Ajjanagadde]

On Fri, Oct 16, 2015 at 5:17 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Oct 16, 2015 at 11:39 AM, Michael Niedermayer
>  wrote:
>> On Thu, Oct 15, 2015 at 07:20:30PM -0400, Ganesh Ajjanagadde wrote:
>>> This will trigger a bunch of warnings (rightfully so). This API has been
>>> abused, see the Doxygen comment above for what to do if the error code
>>> is not meant to be checked.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/pixdesc.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
>>> index a6056fe..975fbf2 100644
>>> --- a/libavutil/pixdesc.h
>>> +++ b/libavutil/pixdesc.h
>>> @@ -297,6 +297,7 @@ enum AVPixelFormat av_pix_fmt_desc_get_id(const 
>>> AVPixFmtDescriptor *desc);
>>>   *
>>>   * @return 0 on success, AVERROR(ENOSYS) on invalid or unknown pixel format
>>>   */
>>> +av_warn_unused_result
>>>  int av_pix_fmt_get_chroma_sub_sample(enum AVPixelFormat pix_fmt,
>>>   int *h_shift, int *v_shift);
>>
>> if the caller knows the pixel format is valid (and non hw accel) then
>> there is no need to check the return code
>> in many cases this is true, like a decoder that set the pix_fmt itself
>> it can be sure all possible values are valid
>
> See the Doxygen right above (this is why I pointed to it in the commit
> message) - you are right, but for such "guaranteed safety" usage there
> is a different API in avcodec. It seems to have been created precisely
> for this purpose.

ping; you don't find the above reasoning satisfying?

>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> No human being will ever know the Truth, for even if they happen to say it
>> by chance, they would not even known they had done so. -- Xenophanes
>>
>> ___
>> 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 05/11] avfilter/af_volume: use log10 instead of log()/M_LN10

[Ganesh Ajjanagadde]

This is likely more precise and conveys the intent better.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/af_volume.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
index 16e994c..3ba356a 100644
--- a/libavfilter/af_volume.c
+++ b/libavfilter/af_volume.c
@@ -279,7 +279,7 @@ static int set_volume(AVFilterContext *ctx)
 av_log(ctx, AV_LOG_VERBOSE, "volume_i:%d/255 ", vol->volume_i);
 }
 av_log(ctx, AV_LOG_VERBOSE, "volume:%f volume_dB:%f\n",
-   vol->volume, 20.0*log(vol->volume)/M_LN10);
+   vol->volume, 20.0*log10(vol->volume));
 
 volume_init(vol);
 return 0;
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features

[James Almer]

On 10/27/2015 9:56 PM, Michael Niedermayer wrote:
> On Mon, Oct 26, 2015 at 12:32:58AM +0700, Muhammad Faiz wrote:
>> On Sun, Oct 25, 2015 at 9:51 AM, Michael Niedermayer
>>  wrote:
>>> On Sun, Oct 25, 2015 at 08:43:07AM +0700, Muhammad Faiz wrote:
  doc/filters.texi  |  181 +++--
  libavfilter/avf_showcqt.c | 1546 
 +++---
  libavfilter/avf_showcqt.h |  104 +++
  libavfilter/version.h |2
  4 files changed, 1294 insertions(+), 539 deletions(-)
 3f83a0d334d780da3defa7d1fa3f09b3beb1db2d  
 0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch
 From 337a659f96ef5dcf87aad1d541e745b7c262cbb9 Mon Sep 17 00:00:00 2001
 From: Muhammad Faiz 
 Date: Sat, 24 Oct 2015 00:44:42 +0700
 Subject: [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features
>>>
>>> this fails to build on "arm-linux-gnueabi-gcc-4.5 (Ubuntu/Linaro 
>>> 4.5.3-12ubuntu2) 4.5.3"
>>> In file included from ffmpeg/libavfilter/avf_showcqt.c:41:0:
>>> ffmpeg/libavfilter/avf_showcqt.h:39:30: warning: declaration does not 
>>> declare anything
>>> ffmpeg/libavfilter/avf_showcqt.h:40:30: warning: declaration does not 
>>> declare anything
>>> ffmpeg/libavfilter/avf_showcqt.c: In function ‘rgb_from_cqt’:
>>> ffmpeg/libavfilter/avf_showcqt.c:668:13: error: ‘ColorFloat’ has no member 
>>> named ‘r’
>>> ffmpeg/libavfilter/avf_showcqt.c:669:13: error: ‘ColorFloat’ has no member 
>>> named ‘g’
>>> ffmpeg/libavfilter/avf_showcqt.c:670:13: error: ‘ColorFloat’ has no member 
>>> named ‘b’
>>> ffmpeg/libavfilter/avf_showcqt.c: In function ‘yuv_from_cqt’:
>>> ffmpeg/libavfilter/avf_showcqt.c:682:13: error: ‘ColorFloat’ has no member 
>>> named ‘y’
>>> ffmpeg/libavfilter/avf_showcqt.c:683:13: error: ‘ColorFloat’ has no member 
>>> named ‘u’
>>> ffmpeg/libavfilter/avf_showcqt.c:684:13: error: ‘ColorFloat’ has no member 
>>> named ‘v’
>>
>>
>> revision: do not use anonymous struct, it seems it is not supported on
>> some platforms
>>
>> thanks
> 
>>  doc/filters.texi  |  181 +++--
>>  libavfilter/avf_showcqt.c | 1546 
>> +++---
>>  libavfilter/avf_showcqt.h |  112 +++
>>  libavfilter/version.h |2 
>>  4 files changed, 1302 insertions(+), 539 deletions(-)
>> be583ed02fc82b34612c9c1782955795fb8b4259  
>> 0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch
>> From e6d6243e03439cffd2d58e30d9892c18e2ef0bc4 Mon Sep 17 00:00:00 2001
>> From: Muhammad Faiz 
>> Date: Mon, 26 Oct 2015 00:18:41 +0700
>> Subject: [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features
>>
>> add yuv444p, yuv422p, and yuv420p output format (lower cpu usage
>> on ffplay playback because it does not do format conversion)
>> custom size with size/s option (fullhd option is deprecated)
>> custom layout with bar_h, axis_h, and sono_h option
>> support rational frame rate (within fps/r/rate option)
>> relaxed frame rate restriction (support fractional sample step)
>> support all input sample rates
>> separate sonogram and bargraph volume (with volume/sono_v and
>> volume2/bar_v)
>> timeclamp option alias (timeclamp/tc)
>> fcount option
>> gamma option alias (gamma/sono_g and gamma2/bar_g)
>> support custom frequency range (basefreq and endfreq)
>> support drawing axis using external image file (axisfile option)
>> alias for disabling drawing to axis (text/axis)
>> possibility to optimize it using arch specific asm code
>> ---
>>  doc/filters.texi  |  181 --
>>  libavfilter/avf_showcqt.c | 1546 
>> +++--
>>  libavfilter/avf_showcqt.h |  112 
>>  libavfilter/version.h |2 +-
>>  4 files changed, 1302 insertions(+), 539 deletions(-)
>>  create mode 100644 libavfilter/avf_showcqt.h
> 
> applied
> 
> thanks

C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(316) : error 
C4013: 'fmax' undefined; assuming extern returning int
C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(317) : error 
C4013: 'fmin' undefined; assuming extern returning int
C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(668) : error 
C4013: 'fminf' undefined; assuming extern returning int

If these can't be replaced with FFMIN/FFMAX then maybe a fallback version should
be added to libavutil/libm.h
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/motion_est_template: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 10:00 AM, Michael Niedermayer
 wrote:
> On Tue, Oct 27, 2015 at 10:51:29PM -0400, Ganesh Ajjanagadde wrote:
>> This code is in a performance critical section. AV_QSORT is
>> substantially faster due to the inlining of the comparison callback.
>> Thus, the increase in performance is worth the increase in binary size.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>> Benchmarks not provided, since FATE does not seem to exercise this.
>> Left to the maintainer/any interested.
>> ---
>>  libavcodec/motion_est_template.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> LGTM
>
> (if someone wants to benchmark see the -dia_size parameter)
>
> thx

pushed, thanks.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 2
> "100% positive feedback" - "All either got their money back or didnt complain"
> "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/tremolo: fix wavetable buffer size

[Kyle Swanson]

Signed-off-by: Kyle Swanson 
---
 libavfilter/af_tremolo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/af_tremolo.c b/libavfilter/af_tremolo.c
index 50df2e4..572e9e3 100644
--- a/libavfilter/af_tremolo.c
+++ b/libavfilter/af_tremolo.c
@@ -72,7 +72,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 dst += channels;
 src += channels;
 s->index++;
-if (s->index >= inlink->sample_rate)
+if (s->index >= inlink->sample_rate / s->freq)
 s->index = 0;
 }
 
@@ -125,11 +125,11 @@ static int config_input(AVFilterLink *inlink)
 const double offset = 1. - s->depth / 2.;
 int i;
 
-s->table = av_malloc_array(inlink->sample_rate, sizeof(*s->table));
+s->table = av_malloc_array(inlink->sample_rate / s->freq, 
sizeof(*s->table));
 if (!s->table)
 return AVERROR(ENOMEM);
 
-for (i = 0; i < inlink->sample_rate; i++) {
+for (i = 0; i < inlink->sample_rate / s->freq; i++) {
 double env = s->freq * i / inlink->sample_rate;
 env = sin(2 * M_PI * fmod(env + 0.25, 1.0));
 s->table[i] = env * (1 - fabs(offset)) + offset;
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] avutil/mathematics: correct documentation for av_gcd

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 10:09 AM, Ganesh Ajjanagadde
 wrote:
> On Tue, Oct 27, 2015 at 8:18 PM, Ganesh Ajjanagadde
>  wrote:
>> av_gcd is now always defined regardless of input. This documents this
>> change in the "documented API". Two benefits (closely related):
>> 1. The function is robust, and there is no need to worry about INT64_MIN, 
>> etc.
>>
>> 2. Clients of av_gcd, like av_reduce, can now be made fully correct. 
>> Currently,
>> av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to
>> integer overflow in the FFABS. Furthermore, this undefined behavior is
>> completely undocumented, and could be a fuzzer's paradise. The FFABS was 
>> needed in the past as
>> av_gcd was undefined for negative inputs. In order to make av_reduce
>> robust, it is essential to guarantee that av_gcd works for all int64_t.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/mathematics.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h
>> index ac94488..6fc2577 100644
>> --- a/libavutil/mathematics.h
>> +++ b/libavutil/mathematics.h
>> @@ -77,9 +77,9 @@ enum AVRounding {
>>  };
>>
>>  /**
>> - * Return the greatest common divisor of a and b.
>> - * If both a and b are 0 or either or both are <0 then behavior is
>> - * undefined.
>> + * Compute the greatest common divisor of a and b.
>> + *
>> + * @return gcd of a and b up to sign; if a and b are both zero returns 0
>>   */
>>  int64_t av_const av_gcd(int64_t a, int64_t b);
>>
>> --
>> 2.6.2
>>
>
> Patch dropped for now, undefined behavior is still possible with
> av_gcd: take a and b to be both INT64_MIN. Need to examine this a
> little more closely to make it robust without losing performance.

Request to reconsider; patch making av_gcd more robust sent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/samplefmt: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 6:31 PM, Ganesh Ajjanagadde
 wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/samplefmt.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/samplefmt.h b/libavutil/samplefmt.h
> index 6a8a031..246147f 100644
> --- a/libavutil/samplefmt.h
> +++ b/libavutil/samplefmt.h
> @@ -222,6 +222,7 @@ int av_samples_fill_arrays(uint8_t **audio_data, int 
> *linesize,
>   * @see av_samples_fill_arrays()
>   * @see av_samples_alloc_array_and_samples()
>   */
> +av_warn_unused_result
>  int av_samples_alloc(uint8_t **audio_data, int *linesize, int nb_channels,
>   int nb_samples, enum AVSampleFormat sample_fmt, int 
> align);
>
> @@ -234,6 +235,7 @@ int av_samples_alloc(uint8_t **audio_data, int *linesize, 
> int nb_channels,
>   *
>   * @see av_samples_alloc()
>   */
> +av_warn_unused_result
>  int av_samples_alloc_array_and_samples(uint8_t ***audio_data, int *linesize, 
> int nb_channels,
> int nb_samples, enum AVSampleFormat 
> sample_fmt, int align);
>
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCH] avutil/wchar_filename: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Wed, Oct 21, 2015 at 11:46 PM, Ganesh Ajjanagadde
 wrote:
> On Thu, Oct 15, 2015 at 8:01 PM, Ganesh Ajjanagadde
>  wrote:
>> Current code is fine, this just adds robustness.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/wchar_filename.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
>> index c553c46..2ade321 100644
>> --- a/libavutil/wchar_filename.h
>> +++ b/libavutil/wchar_filename.h
>> @@ -23,6 +23,7 @@
>>  #include 
>>  #include "mem.h"
>>
>> +av_warn_unused_result
>>  static inline int utf8towchar(const char *filename_utf8, wchar_t 
>> **filename_w)
>>  {
>>  int num_chars;
>> --
>> 2.6.1
>>
>
> ping - anyone willing to review this (and the other
> av_warn_unused_result patches)?

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

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 07:02:42PM -0400, Ganesh Ajjanagadde wrote:
> On Wed, Oct 28, 2015 at 3:05 PM, Ronald S. Bultje  wrote:
> > Hi,
> >
> > On Wed, Oct 28, 2015 at 2:46 PM, Ganesh Ajjanagadde 
> > wrote:
> >>
> >> On Wed, Oct 28, 2015 at 2:39 PM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Wed, Oct 28, 2015 at 2:31 PM, Ganesh Ajjanagadde
> >> > 
> >> > wrote:
> >> >>
> >> >> On Wed, Oct 28, 2015 at 11:38 AM, Ronald S. Bultje 
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Wed, Oct 28, 2015 at 11:00 AM, Ganesh Ajjanagadde
> >> >> >  wrote:
> >> >> >>
> >> >> >> On Wed, Oct 28, 2015 at 10:53 AM, Ronald S. Bultje
> >> >> >> 
> >> >> >> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde
> >> >> >> >  wrote:
> >> >> >> >>
> >> >> >> >> On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje
> >> >> >> >> 
> >> >> >> >> wrote:
> >> >> >> >> > Hi,
> >> >> >> >> >
> >> >> >> >> > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde
> >> >> >> >> > 
> >> >> >> >> > wrote:
> >> >> >> >> >>
> >> >> >> >> >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje
> >> >> >> >> >> 
> >> >> >> >> >> wrote:
> >> >> >> >> >> > Hi,
> >> >> >> >> >> >
> >> >> >> >> >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
> >> >> >> >> >> >  wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje
> >> >> >> >> >> >> 
> >> >> >> >> >> >> wrote:
> >> >> >> >> >> >> > Hi,
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
> >> >> >> >> >> >> > 
> >> >> >> >> >> >> > wrote:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> ISO C restricts enumerator values to the range of int.
> >> >> >> >> >> >> >> Thus
> >> >> >> >> >> >> >> (for
> >> >> >> >> >> >> >> instance)
> >> >> >> >> >> >> >> 0x8000
> >> >> >> >> >> >> >> unfortunately does not work, and throws a warning with
> >> >> >> >> >> >> >> -Wpedantic
> >> >> >> >> >> >> >> on
> >> >> >> >> >> >> >> clang 3.7.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> This fixes it by using alternative expressions that
> >> >> >> >> >> >> >> result
> >> >> >> >> >> >> >> in
> >> >> >> >> >> >> >> identical
> >> >> >> >> >> >> >> values but do not have this issue.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Tested with FATE.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Signed-off-by: Ganesh Ajjanagadde
> >> >> >> >> >> >> >> 
> >> >> >> >> >> >> >> ---
> >> >> >> >> >> >> >>  libavcodec/dca_syncwords.h | 26
> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >>  libavformat/cinedec.c  |  2 +-
> >> >> >> >> >> >> >>  libavformat/mov_chan.c |  2 +-
> >> >> >> >> >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> diff --git a/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> >> b/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> >> index 3466b6b..6981cb8 100644
> >> >> >> >> >> >> >> --- a/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> >> +++ b/libavcodec/dca_syncwords.h
> >> >> >> >> >> >> >> @@ -19,19 +19,17 @@
> >> >> >> >> >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
> >> >> >> >> >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> -enum DCASyncwords {
> >> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
> >> >> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
> >> >> >> >> >> >> >> -};
> >> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_BE
> >> >> >> >> >> >> >> 0x7FFE8001U
> >> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_LE
> >> >> >> >> >> >> >> 0xFE7F0180U
> >> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE
> >> >> >> >> >> >> >> 0x1FFFE800U
> >> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE
> >> >> >> >> >> >> >> 0xFF1F00E8U
> >> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XCH
> >> >> >> >> >> >> >> 0x5A5A5A5AU
> >> >> >> >> >> >> >> +#define

[FFmpeg-devel] [PATCH 11/11] avutil/rational: use frexp rather than ad-hoc log to get floating point exponent

[Ganesh Ajjanagadde]

This simplifies and cleans up the code.
Furthermore, it is much faster due to absence of the slow log computation.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/rational.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/rational.c b/libavutil/rational.c
index 21d2bb7..81a9402 100644
--- a/libavutil/rational.c
+++ b/libavutil/rational.c
@@ -106,14 +106,14 @@ AVRational av_sub_q(AVRational b, AVRational c)
 AVRational av_d2q(double d, int max)
 {
 AVRational a;
-#define LOG2  0.69314718055994530941723212145817656807550013436025
 int exponent;
 int64_t den;
 if (isnan(d))
 return (AVRational) { 0,0 };
 if (fabs(d) > INT_MAX + 3LL)
 return (AVRational) { d < 0 ? -1 : 1, 0 };
-exponent = FFMAX( (int)(log(fabs(d) + 1e-20)/LOG2), 0);
+frexp(d, );
+exponent = FFMAX(exponent-1, 0);
 den = 1LL << (61 - exponent);
 // (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64
 av_reduce(, , floor(d * den + 0.5), den, max);
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[Dale Curtis]

On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje 
wrote:
>
> So this is likely because we init all tables instead of just these that we
> need, right? So how about having one ff_once per table? That should be
> trivial to implement.


Just so we're all on the same page, this is trivial, but will get a bit
messy unless I'm missing something. The ff_thread_once() API only takes a
void(void) function, so unless there's partial specialization hiding
somewhere we need prototypes for each partial initialization. I.e.
ff_init_ff_cos_static_table_init_4(), ff_init_ff_cos_static_table_init_5(),
ff_init_ff_cos_static_table_init_6(), etc for 4..16. We would also then
have an array of AVOnce items for entries 4..16 where each entry would
correspond to calling the paired initialization function.

Is this what everyone had in mind?

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

Re: [FFmpeg-devel] [PATCH] fix nvenc potential profile error when encoding yuv444p

[Timo Rothenpieler]

> ---
>  libavcodec/nvenc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 0e6ef43..083e494 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -912,6 +912,11 @@ static av_cold int nvenc_encode_init(AVCodecContext
> *avctx)
>  goto error;
>  }
>  }
> +// force setting profile as high444p if input is
> AV_PIX_FMT_YUV444P
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV444P) {
> +ctx->encode_config.profileGUID =
> NV_ENC_H264_PROFILE_HIGH_444_GUID;
> +avctx->profile = FF_PROFILE_H264_HIGH_444_PREDICTIVE;
> +}
> 
> 
> ctx->encode_config.encodeCodecConfig.h264Config.chromaFormatIDC =
> avctx->profile == FF_PROFILE_H264_HIGH_444_PREDICTIVE ? 3 : 1;
> 
> @@ -1452,7 +1457,7 @@ static const enum AVPixelFormat pix_fmts_nvenc[] = {
>  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
>  { "preset", "Set the encoding preset (one of slow = hq 2pass,
> medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default)",
> OFFSET(preset), AV_OPT_TYPE_STRING, { .str = "hq" }, 0, 0, VE },
> -{ "profile", "Set the encoding profile (high, main or baseline)",
> OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> +{ "profile", "Set the encoding profile (high, main, baseline or
> high444p)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
>  { "level", "Set the encoding level restriction (auto, 1.0, 1.0b,
> 1.1, 1.2, ..., 4.2, 5.0, 5.1)", OFFSET(level), AV_OPT_TYPE_STRING, { 0
> }, 0, 0, VE },
>  { "tier", "Set the encoding tier (main or high)", OFFSET(tier),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
>  { "cbr", "Use cbr encoding mode", OFFSET(cbr), AV_OPT_TYPE_BOOL, {
> .i64 = 0 }, 0, 1, VE },

LGTM, can't push it currently, will push this weekend if nobody has
already done so by then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avformat: add DC STR demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/dcstr.c  | 79 
 3 files changed, 81 insertions(+)
 create mode 100644 libavformat/dcstr.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index c3d9e18..27aefcb 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -127,6 +127,7 @@ OBJS-$(CONFIG_DATA_MUXER)+= rawdec.o
 OBJS-$(CONFIG_DASH_MUXER)+= dashenc.o isom.o
 OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
+OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
 OBJS-$(CONFIG_DFA_DEMUXER)   += dfa.o
 OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
 OBJS-$(CONFIG_DIRAC_MUXER)   += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index a67a226..fc42cb7 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -109,6 +109,7 @@ void av_register_all(void)
 REGISTER_MUXER   (DASH, dash);
 REGISTER_MUXDEMUX(DATA, data);
 REGISTER_MUXDEMUX(DAUD, daud);
+REGISTER_DEMUXER (DCSTR,dcstr);
 REGISTER_DEMUXER (DFA,  dfa);
 REGISTER_MUXDEMUX(DIRAC,dirac);
 REGISTER_MUXDEMUX(DNXHD,dnxhd);
diff --git a/libavformat/dcstr.c b/libavformat/dcstr.c
new file mode 100644
index 000..1baa723
--- /dev/null
+++ b/libavformat/dcstr.c
@@ -0,0 +1,79 @@
+/*
+ * DC STR demuxer
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * 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 "avformat.h"
+#include "internal.h"
+
+static int dcstr_probe(AVProbeData *p)
+{
+if (p->buf_size < 224 || memcmp(p->buf + 213, "Sega Stream", 11))
+return 0;
+
+return AVPROBE_SCORE_MAX;
+}
+
+static int dcstr_read_header(AVFormatContext *s)
+{
+unsigned codec, align;
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codec->channels= avio_rl32(s->pb);
+st->codec->sample_rate = avio_rl32(s->pb);
+codec  = avio_rl32(s->pb);
+align  = avio_rl32(s->pb);
+avio_skip(s->pb, 4);
+st->duration   = avio_rl32(s->pb);
+st->codec->channels   *= avio_rl32(s->pb);
+if (!align || align > INT_MAX / st->codec->channels)
+return AVERROR_INVALIDDATA;
+st->codec->block_align = align * st->codec->channels;
+
+switch (codec) {
+case  4: st->codec->codec_id = AV_CODEC_ID_ADPCM_AICA;   break;
+case 16: st->codec->codec_id = AV_CODEC_ID_PCM_S16LE_PLANAR; break;
+default: avpriv_request_sample(s, "codec %X", codec);
+}
+
+avio_skip(s->pb, 0x800 - avio_tell(s->pb));
+avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
+
+return 0;
+}
+
+static int dcstr_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+AVCodecContext *codec = s->streams[0]->codec;
+return av_get_packet(s->pb, pkt, codec->block_align);
+}
+
+AVInputFormat ff_dcstr_demuxer = {
+.name   = "dcstr",
+.long_name  = NULL_IF_CONFIG_SMALL("Sega DC STR"),
+.read_probe = dcstr_probe,
+.read_header= dcstr_read_header,
+.read_packet= dcstr_read_packet,
+.extensions = "str",
+};
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] fix nvenc potential profile error when encoding yuv444p

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 11:52:50AM -0700, Philip Langdale wrote:
> On Wed, 28 Oct 2015 14:53:42 +0800
> Agatha Hu  wrote:
> 
> > ---
> >   libavcodec/nvenc.c | 7 ++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> > index 0e6ef43..083e494 100644
> > --- a/libavcodec/nvenc.c
> > +++ b/libavcodec/nvenc.c
> > @@ -912,6 +912,11 @@ static av_cold int
> > nvenc_encode_init(AVCodecContext *avctx)
> >   goto error;
> >   }
> >   }
> > +// force setting profile as high444p if input is
> > AV_PIX_FMT_YUV444P
> > +if (avctx->pix_fmt == AV_PIX_FMT_YUV444P) {
> > +ctx->encode_config.profileGUID = 
> > NV_ENC_H264_PROFILE_HIGH_444_GUID;
> > +avctx->profile = FF_PROFILE_H264_HIGH_444_PREDICTIVE;
> > +}
> > 
> >  
> > ctx->encode_config.encodeCodecConfig.h264Config.chromaFormatIDC = 
> > avctx->profile == FF_PROFILE_H264_HIGH_444_PREDICTIVE ? 3 : 1;
> > 
> > @@ -1452,7 +1457,7 @@ static const enum AVPixelFormat
> > pix_fmts_nvenc[] = { #define VE AV_OPT_FLAG_VIDEO_PARAM |
> > AV_OPT_FLAG_ENCODING_PARAM static const AVOption options[] = {
> >   { "preset", "Set the encoding preset (one of slow = hq 2pass, 
> > medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default)", 
> > OFFSET(preset), AV_OPT_TYPE_STRING, { .str = "hq" }, 0, 0, VE },
> > -{ "profile", "Set the encoding profile (high, main or
> > baseline)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> > +{ "profile", "Set the encoding profile (high, main, baseline or 
> > high444p)", OFFSET(profile), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> >   { "level", "Set the encoding level restriction (auto, 1.0,
> > 1.0b, 1.1, 1.2, ..., 4.2, 5.0, 5.1)", OFFSET(level),
> > AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> >   { "tier", "Set the encoding tier (main or high)", OFFSET(tier), 
> > AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
> >   { "cbr", "Use cbr encoding mode", OFFSET(cbr),
> > AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> 
> Seems reasonable to me.

i cant apply that patch, its currupted by extra newlines

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

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


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

Re: [FFmpeg-devel] [PATCH] vp9_parser: don't overwrite cached timestamps with nopts.

[wm4]

On Wed, 28 Oct 2015 16:05:49 -0400
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Wed, Oct 28, 2015 at 3:44 PM, wm4  wrote:
> 
> > On Wed, 28 Oct 2015 12:21:05 -0400
> > "Ronald S. Bultje"  wrote:
> >  
> > > ---
> > >  libavcodec/vp9_parser.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> > > index 0437097..6713850 100644
> > > --- a/libavcodec/vp9_parser.c
> > > +++ b/libavcodec/vp9_parser.c
> > > @@ -64,7 +64,7 @@ static int parse_frame(AVCodecParserContext *ctx,  
> > const uint8_t *buf, int size)  
> > >  if (ctx->pts == AV_NOPTS_VALUE)
> > >  ctx->pts = s->pts;
> > >  s->pts = AV_NOPTS_VALUE;
> > > -} else {
> > > +} else if (ctx->pts != AV_NOPTS_VALUE) {
> > >  s->pts = ctx->pts;
> > >  ctx->pts = AV_NOPTS_VALUE;
> > >  }  
> >
> > I find this a bit questionable. What is it needed for? Wouldn't it
> > repeat the previous timestamp if new packets have none?  
> 
> 
> I don't think so. Let's first go through the problem that I'm seeing, maybe
> you see alternate solutions. Then I'll explain (very end) why I don't think
> this happens.
> 
> So, we're assuming here (this is generally true) that all input to the
> parser has timestamps (coming from ivf/webm), and that some frames are
> "superframes" which have one invisible (alt-ref) frame (only a reference,
> not an actual frame that's ever displayed) packed with the following
> visible frame. So each packet in ivf/webm leads to one visible output
> frame, but in some cases this requires decoding of multiple (invisible)
> references. For frame threading purposes, we split before we send it to the
> decoder.
> 
> So what you get is:
> - ivf/webm file has packet of size a with timestamp b, calls parser
> - parser notices that packet is superframe with 2 frames in it
> - we output the first (invisible) frame with no timestamp, and cache the
> timestamp of the input packet
> - utils.c code calls parser again with the same input data (we told it we
> didn't consume any), but the (input) timestamp is now set to nopts
> - we output the second (visible) frame with the cached timestamp on the
> packet
> 
> This generally makes sense, the webm/ivf indeed assume that the timestamp
> only is valid for the visible frame. Invisible frames have no timestamp
> associated with them since they're never displayed.
> 
> So, the above code has the issue: what if there's 2 invisible frames packed
> in a superframe (followed by the visible frame)? Right now, this happens:
> - ivf/webm file has packet of size a with timestamp b, calls parser
> - parser notices that packet is superframe with 3 frames in it
> - we output the first (invisible) frame with no timestamp, and cache the
> timestamp of the input packet
> - utils.c code calls parser again with the same input data (we told it we
> didn't consume any), but the (input) timestamp is now set to nopts
> - we output the second (invisible) frame with no timestamp, and cache the
> timestamp of the input packet (which is now set to nopts)
> - utils.c code calls parser again with the same input data (we told it we
> didn't consume any), but the (input) timestamp is now set to nopts
> - we output the third (visible) frame with the cached timestamp on the
> packet, which was nopts
> 
> The last 3 are wrong; we should only cache timestamps if there is any to be
> cached, we should not override the cached timestamp with a new nopts value,
> at least not in this particular case.
> 
> --
> very end
> --
> 
> Ok, so what about your point: can we output the same timestamp twice? I
> don't think so, because as soon as we output the cached timestamp, we reset
> the value of the cached timestamp to nopts, so if we were to reuse the
> cached timestamp, it would be nopts and the output data would have no
> timestamp.
> 
> (Hope that wasn't too detailed.)

Thanks for the explanations. I didn't know there could be more than 1
super frame, and I see how the new logic works and doesn't duplicate
timestamps.

Patch looks good with me then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Wed, Oct 28, 2015 at 3:05 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Oct 28, 2015 at 2:46 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> On Wed, Oct 28, 2015 at 2:39 PM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Wed, Oct 28, 2015 at 2:31 PM, Ganesh Ajjanagadde
>> > 
>> > wrote:
>> >>
>> >> On Wed, Oct 28, 2015 at 11:38 AM, Ronald S. Bultje 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Wed, Oct 28, 2015 at 11:00 AM, Ganesh Ajjanagadde
>> >> >  wrote:
>> >> >>
>> >> >> On Wed, Oct 28, 2015 at 10:53 AM, Ronald S. Bultje
>> >> >> 
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Wed, Oct 28, 2015 at 10:48 AM, Ganesh Ajjanagadde
>> >> >> >  wrote:
>> >> >> >>
>> >> >> >> On Wed, Oct 28, 2015 at 10:34 AM, Ronald S. Bultje
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > On Wed, Oct 28, 2015 at 8:20 AM, Ganesh Ajjanagadde
>> >> >> >> > 
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> On Wed, Oct 28, 2015 at 7:00 AM, Ronald S. Bultje
>> >> >> >> >> 
>> >> >> >> >> wrote:
>> >> >> >> >> > Hi,
>> >> >> >> >> >
>> >> >> >> >> > On Tue, Oct 27, 2015 at 10:58 PM, Ganesh Ajjanagadde
>> >> >> >> >> >  wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> On Tue, Oct 27, 2015 at 10:41 PM, Ronald S. Bultje
>> >> >> >> >> >> 
>> >> >> >> >> >> wrote:
>> >> >> >> >> >> > Hi,
>> >> >> >> >> >> >
>> >> >> >> >> >> > On Tue, Oct 27, 2015 at 8:53 PM, Ganesh Ajjanagadde
>> >> >> >> >> >> > 
>> >> >> >> >> >> > wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> ISO C restricts enumerator values to the range of int.
>> >> >> >> >> >> >> Thus
>> >> >> >> >> >> >> (for
>> >> >> >> >> >> >> instance)
>> >> >> >> >> >> >> 0x8000
>> >> >> >> >> >> >> unfortunately does not work, and throws a warning with
>> >> >> >> >> >> >> -Wpedantic
>> >> >> >> >> >> >> on
>> >> >> >> >> >> >> clang 3.7.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> This fixes it by using alternative expressions that
>> >> >> >> >> >> >> result
>> >> >> >> >> >> >> in
>> >> >> >> >> >> >> identical
>> >> >> >> >> >> >> values but do not have this issue.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Tested with FATE.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Signed-off-by: Ganesh Ajjanagadde
>> >> >> >> >> >> >> 
>> >> >> >> >> >> >> ---
>> >> >> >> >> >> >>  libavcodec/dca_syncwords.h | 26
>> >> >> >> >> >> >> --
>> >> >> >> >> >> >>  libavformat/cinedec.c  |  2 +-
>> >> >> >> >> >> >>  libavformat/mov_chan.c |  2 +-
>> >> >> >> >> >> >>  3 files changed, 14 insertions(+), 16 deletions(-)
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> diff --git a/libavcodec/dca_syncwords.h
>> >> >> >> >> >> >> b/libavcodec/dca_syncwords.h
>> >> >> >> >> >> >> index 3466b6b..6981cb8 100644
>> >> >> >> >> >> >> --- a/libavcodec/dca_syncwords.h
>> >> >> >> >> >> >> +++ b/libavcodec/dca_syncwords.h
>> >> >> >> >> >> >> @@ -19,19 +19,17 @@
>> >> >> >> >> >> >>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>> >> >> >> >> >> >>  #define AVCODEC_DCA_SYNCWORDS_H
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> -enum DCASyncwords {
>> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
>> >> >> >> >> >> >> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_X96= 0x1D95F262U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_XBR= 0x655E315EU,
>> >> >> >> >> >> >> -DCA_SYNCWORD_LBR= 0x0A801921U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_XLL= 0x41A29547U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
>> >> >> >> >> >> >> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
>> >> >> >> >> >> >> -};
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_BE
>> >> >> >> >> >> >> 0x7FFE8001U
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_LE
>> >> >> >> >> >> >> 0xFE7F0180U
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_BE
>> >> >> >> >> >> >> 0x1FFFE800U
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_CORE_14B_LE
>> >> >> >> >> >> >> 0xFF1F00E8U
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XCH
>> >> >> >> >> >> >> 0x5A5A5A5AU
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XXCH
>> >> >> >> >> >> >> 0x47004A03U
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_X96
>> >> >> >> >> >> >> 0x1D95F262U
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_XBR
>> >> >> >> >> >> >> 0x655E315EU
>> >> >> >> >> >> >> +#defineDCA_SYNCWORD_LBR
>> >> >> >> >> >> >> 0x0A801921U
>> >> 

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

[Marton Balint]

On Sun, 18 Oct 2015, Bodecs Bela wrote:

[...]

It can be anything if it does not change existing behaviour, a complex 
specifier can be split to basic specifiers without worrying about the 
syntax of the basic specifier and if there is a well defined rule for 
escaping special characters. Also if it is readable to the user, that 
is a plus.


The exact solution can be a bit about personal taste as well, but 
maybe something like


(specifier)(specifier)

I like this version. So, there would be the original case: specifier, 
and if you want to use more specifier, you should put each of them into 
parenthesis (round brackets): (specifier)(specifier)

I think it really won't break any current code


Yes, exactly.



+specifier+specifier

I think () is more readible and rarely used in specifiers.  If it is ok 
for you and others I would implement it.


Ok, it's fine by me.

Thanks,
Marton




can work and is readable. Knowing that you are dealing with a complex 
expression also means that the special characters separating the basic 
specifiers needs escaping, I guess av_get_token can be used to get the 
proper unescaped basic specifiers when parsing the complex one.


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


best regards,

bb

___
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] ffprobe: move abort() call to after the print statements

[wm4]

On Tue, 27 Oct 2015 20:21:11 -0400
Ganesh Ajjanagadde  wrote:

> This fixes warning C4702 "unreachable code" reported in MSVC:
> http://fate.ffmpeg.org/log.cgi?time=20151026165907=compile=x86_64-msvc12-windows-native,
> and also likely fixes the intended behavior.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffprobe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ffprobe.c b/ffprobe.c
> index 02e2c48..0374cd9 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -1890,9 +1890,9 @@ static void show_frame(WriterContext *w, AVFrame 
> *frame, AVStream *stream,
>  print_str("side_data_type", name ? name : "unknown");
>  print_int("side_data_size", sd->size);
>  if (sd->type == AV_FRAME_DATA_DISPLAYMATRIX && sd->size >= 9*4) {
> -abort();
>  writer_print_integers(w, "displaymatrix", sd->data, 9, " 
> %11d", 3, 4, 1);
>  print_int("rotation", av_display_rotation_get((int32_t 
> *)sd->data));
> +abort();
>  }
>  writer_print_section_footer(w);
>  }

Why the heck is there an abort()?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] all: fix enum definition for large values

[wm4]

On Tue, 27 Oct 2015 20:53:39 -0400
Ganesh Ajjanagadde  wrote:

> ISO C restricts enumerator values to the range of int. Thus (for instance) 
> 0x8000
> unfortunately does not work, and throws a warning with -Wpedantic on
> clang 3.7.
> 
> This fixes it by using alternative expressions that result in identical
> values but do not have this issue.
> 
> Tested with FATE.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/dca_syncwords.h | 26 --
>  libavformat/cinedec.c  |  2 +-
>  libavformat/mov_chan.c |  2 +-
>  3 files changed, 14 insertions(+), 16 deletions(-)
> 
> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
> index 3466b6b..6981cb8 100644
> --- a/libavcodec/dca_syncwords.h
> +++ b/libavcodec/dca_syncwords.h
> @@ -19,19 +19,17 @@
>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>  #define AVCODEC_DCA_SYNCWORDS_H
>  
> -enum DCASyncwords {
> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
> -DCA_SYNCWORD_X96= 0x1D95F262U,
> -DCA_SYNCWORD_XBR= 0x655E315EU,
> -DCA_SYNCWORD_LBR= 0x0A801921U,
> -DCA_SYNCWORD_XLL= 0x41A29547U,
> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
> -};
> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
> +#defineDCA_SYNCWORD_X96  0x1D95F262U
> +#defineDCA_SYNCWORD_XBR  0x655E315EU
> +#defineDCA_SYNCWORD_LBR  0x0A801921U
> +#defineDCA_SYNCWORD_XLL  0x41A29547U
> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
>  
>  #endif /* AVCODEC_DCA_SYNCWORDS_H */
> diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c
> index 632f46c..d030907 100644
> --- a/libavformat/cinedec.c
> +++ b/libavformat/cinedec.c
> @@ -50,7 +50,7 @@ enum {
>  CFA_BAYER = 3,  /**< GB/RG */
>  CFA_BAYERFLIP = 4,  /**< RG/GB */
>  
> -CFA_TLGRAY= 0x8000,
> +CFA_TLGRAY= INT32_MIN,
>  CFA_TRGRAY= 0x4000,
>  CFA_BLGRAY= 0x2000,
>  CFA_BRGRAY= 0x1000
> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
> index a2fa8d6..f6181e2 100644
> --- a/libavformat/mov_chan.c
> +++ b/libavformat/mov_chan.c
> @@ -45,7 +45,7 @@
>   *do not specify a particular ordering of those channels."
>   */
>  enum MovChannelLayoutTag {
> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
> +MOV_CH_LAYOUT_UNKNOWN   = -( 1 << 16),
>  MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
>  MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
>  MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,

Looks all kinds of backwards.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffprobe: move abort() call to after the print statements

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 09:55:56AM +0100, wm4 wrote:
> On Tue, 27 Oct 2015 20:21:11 -0400
> Ganesh Ajjanagadde  wrote:
> 
> > This fixes warning C4702 "unreachable code" reported in MSVC:
> > http://fate.ffmpeg.org/log.cgi?time=20151026165907=compile=x86_64-msvc12-windows-native,
> > and also likely fixes the intended behavior.
> > 
> > Signed-off-by: Ganesh Ajjanagadde 
> > ---
> >  ffprobe.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/ffprobe.c b/ffprobe.c
> > index 02e2c48..0374cd9 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -1890,9 +1890,9 @@ static void show_frame(WriterContext *w, AVFrame 
> > *frame, AVStream *stream,
> >  print_str("side_data_type", name ? name : "unknown");
> >  print_int("side_data_size", sd->size);
> >  if (sd->type == AV_FRAME_DATA_DISPLAYMATRIX && sd->size >= 
> > 9*4) {
> > -abort();
> >  writer_print_integers(w, "displaymatrix", sd->data, 9, " 
> > %11d", 3, 4, 1);
> >  print_int("rotation", av_display_rotation_get((int32_t 
> > *)sd->data));
> > +abort();
> >  }
> >  writer_print_section_footer(w);
> >  }
> 
> Why the heck is there an abort()?

It looks like mistake (used for testing/debuging), ill remove it

Thanks

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

[FFmpeg-devel] [PATCH 1/8] lavu/aes: test CBC functionality

[Rodger Combs]

---
 libavutil/aes.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/libavutil/aes.c b/libavutil/aes.c
index dde15be..9096f03 100644
--- a/libavutil/aes.c
+++ b/libavutil/aes.c
@@ -280,7 +280,7 @@ int main(int argc, char **argv)
 { 0x10, 0xa5, 0x88, 0x69, 0xd7, 0x4b, 0xe5, 0xa3,
   0x74, 0xcf, 0x86, 0x7c, 0xfb, 0x47, 0x38, 0x59 }
 };
-uint8_t pt[16], rpt[2][16]= {
+uint8_t pt[32], rpt[2][16]= {
 { 0x6a, 0x84, 0x86, 0x7c, 0xd7, 0x7e, 0x12, 0xad,
   0x07, 0xea, 0x1b, 0xe8, 0x95, 0xc5, 0x3f, 0xa3 },
 { 0 }
@@ -291,7 +291,8 @@ int main(int argc, char **argv)
 { 0x6d, 0x25, 0x1e, 0x69, 0x44, 0xb0, 0x51, 0xe0,
   0x4e, 0xaa, 0x6f, 0xb4, 0xdb, 0xf7, 0x84, 0x65 }
 };
-uint8_t temp[16];
+uint8_t temp[32];
+uint8_t iv[2][16];
 int err = 0;
 
 av_log_set_level(AV_LOG_DEBUG);
@@ -317,16 +318,24 @@ int main(int argc, char **argv)
 av_lfg_init(, 1);
 
 for (i = 0; i < 1; i++) {
-for (j = 0; j < 16; j++) {
+for (j = 0; j < 32; j++) {
 pt[j] = av_lfg_get();
 }
+for (j = 0; j < 16; j++) {
+iv[0][j] = iv[1][j] = av_lfg_get();
+}
 {
 START_TIMER;
-av_aes_crypt(, temp, pt, 1, NULL, 0);
+av_aes_crypt(, temp, pt, 2, iv[0], 0);
+if (!(i & (i - 1)))
+av_log(NULL, AV_LOG_ERROR, "%02X %02X %02X %02X\n",
+   temp[0], temp[5], temp[10], temp[15]);
+av_aes_crypt(, temp, temp, 2, iv[1], 1);
+av_aes_crypt(, temp, pt, 2, NULL, 0);
 if (!(i & (i - 1)))
 av_log(NULL, AV_LOG_ERROR, "%02X %02X %02X %02X\n",
temp[0], temp[5], temp[10], temp[15]);
-av_aes_crypt(, temp, temp, 1, NULL, 1);
+av_aes_crypt(, temp, temp, 2, NULL, 1);
 STOP_TIMER("aes");
 }
 for (j = 0; j < 16; j++) {
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 2/8] lavu/aes: add x86 AESNI optimizations

[Rodger Combs]

crypto_bench comparison for AES-128-ECB:

lavu_aesni AES-128-ECB  size: 1048576  runs:   1024  time:0.596 +- 0.081
lavu_c AES-128-ECB  size: 1048576  runs:   1024  time:   17.007 +- 2.131
crypto AES-128-ECB  size: 1048576  runs:   1024  time:0.612 +- 1.857
gcrypt AES-128-ECB  size: 1048576  runs:   1024  time:1.123 +- 0.224
tomcrypt   AES-128-ECB  size: 1048576  runs:   1024  time:9.038 +- 0.790

Improved-By: Henrik Gramner 
---
 libavutil/aes.c  |  2 +
 libavutil/aes_internal.h |  2 +
 libavutil/x86/Makefile   |  4 +-
 libavutil/x86/aes.asm| 95 
 libavutil/x86/aes_init.c | 37 +++
 5 files changed, 139 insertions(+), 1 deletion(-)
 create mode 100644 libavutil/x86/aes.asm
 create mode 100644 libavutil/x86/aes_init.c

diff --git a/libavutil/aes.c b/libavutil/aes.c
index 9096f03..958041b 100644
--- a/libavutil/aes.c
+++ b/libavutil/aes.c
@@ -200,6 +200,8 @@ int av_aes_init(AVAES *a, const uint8_t *key, int key_bits, 
int decrypt)
 uint8_t alog8[512];
 
 a->crypt = decrypt ? aes_decrypt : aes_encrypt;
+if (ARCH_X86)
+ff_init_aes_x86(a, decrypt);
 
 if 
(!enc_multbl[FF_ARRAY_ELEMS(enc_multbl)-1][FF_ARRAY_ELEMS(enc_multbl[0])-1]) {
 j = 1;
diff --git a/libavutil/aes_internal.h b/libavutil/aes_internal.h
index 4944258..dfa2039 100644
--- a/libavutil/aes_internal.h
+++ b/libavutil/aes_internal.h
@@ -40,4 +40,6 @@ typedef struct AVAES {
 void (*crypt)(struct AVAES *a, uint8_t *dst, const uint8_t *src, int 
count, uint8_t *iv, int rounds);
 } AVAES;
 
+void ff_init_aes_x86(AVAES *a, int decrypt);
+
 #endif /* AVUTIL_AES_INTERNAL_H */
diff --git a/libavutil/x86/Makefile b/libavutil/x86/Makefile
index eb70a62..4ac6219 100644
--- a/libavutil/x86/Makefile
+++ b/libavutil/x86/Makefile
@@ -1,4 +1,5 @@
-OBJS += x86/cpu.o   \
+OBJS += x86/aes_init.o  \
+x86/cpu.o   \
 x86/float_dsp_init.o\
 x86/lls_init.o  \
 
@@ -10,5 +11,6 @@ YASM-OBJS += x86/cpuid.o  
  \
  $(EMMS_OBJS__yes_)  \
  x86/float_dsp.o\
  x86/lls.o  \
+ x86/aes.o  \
 
 YASM-OBJS-$(CONFIG_PIXELUTILS) += x86/pixelutils.o  \
diff --git a/libavutil/x86/aes.asm b/libavutil/x86/aes.asm
new file mode 100644
index 000..2147f6b
--- /dev/null
+++ b/libavutil/x86/aes.asm
@@ -0,0 +1,95 @@
+;*
+;* Copyright (c) 2015 Rodger Combs 
+;*
+;* 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 "x86util.asm"
+
+SECTION .text
+
+;-
+; void ff_aes_decrypt(AVAES *a, uint8_t *dst, const uint8_t *src,
+; int count, uint8_t *iv, int rounds)
+;-
+%macro AES_CRYPT 1
+cglobal aes_%1rypt, 6,6,2
+test  r3, r3
+je .ret
+shl  r3d, 4
+add  r5d, r5d
+add   r0, 0x60
+add   r2, r3
+add   r1, r3
+neg   r3
+pxor  m1, m1
+test  r4, r4
+je .block
+movu  m1, [r4] ; iv
+.block:
+movu  m0, [r2+r3] ; state
+%ifidn %1, enc
+pxor  m0, m1
+%endif
+pxor  m0, [r0+8*r5-0x60]
+cmp  r5d, 24
+je .rounds12
+jl .rounds10
+aes%1 m0, [r0+0x70]
+aes%1 m0, [r0+0x60]
+.rounds12:
+aes%1 m0, [r0+0x50]
+aes%1 m0, [r0+0x40]
+.rounds10:
+aes%1 m0, [r0+0x30]
+aes%1 m0, [r0+0x20]
+aes%1 m0, [r0+0x10]
+aes%1 m0, [r0+0x00]
+aes%1 m0, [r0-0x10]
+aes%1 m0, 

[FFmpeg-devel] [PATCH 3/8] checkasm: add tests for AES

[Rodger Combs]

---
 tests/checkasm/Makefile   |  2 +-
 tests/checkasm/aes.c  | 64 +++
 tests/checkasm/checkasm.c |  1 +
 tests/checkasm/checkasm.h |  1 +
 4 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 tests/checkasm/aes.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index c29ceef..5529e98 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -13,7 +13,7 @@ CHECKASMOBJS-$(CONFIG_AVCODEC) += $(AVCODECOBJS-yes)
 
 -include $(SRC_PATH)/tests/checkasm/$(ARCH)/Makefile
 
-CHECKASMOBJS += $(CHECKASMOBJS-yes) checkasm.o
+CHECKASMOBJS += $(CHECKASMOBJS-yes) aes.o checkasm.o
 CHECKASMOBJS := $(sort $(CHECKASMOBJS:%=tests/checkasm/%))
 
 -include $(CHECKASMOBJS:.o=.d)
diff --git a/tests/checkasm/aes.c b/tests/checkasm/aes.c
new file mode 100644
index 000..c550211
--- /dev/null
+++ b/tests/checkasm/aes.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 2015 Rodger Combs 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 "checkasm.h"
+#include "libavutil/aes.h"
+#include "libavutil/aes_internal.h"
+#include "libavutil/internal.h"
+
+#define MAX_COUNT 16
+
+void checkasm_check_aes(void)
+{
+int i, j, d;
+AVAES b;
+uint8_t pt[MAX_COUNT * 16];
+uint8_t temp[2][MAX_COUNT * 16];
+uint8_t iv[2][16];
+
+for (d = 0; d <= 1; d++) {
+for (i = 128; i <= 256; i += 64) {
+av_aes_init(, (const 
uint8_t*)"PI=3.1415926535897932384626433..", i, d);
+if (check_func(b.crypt, "aes_%scrypt_%i", d ? "de" : "en", i)) {
+declare_func(void, AVAES *a, uint8_t *dst, const uint8_t *src,
+ int count, uint8_t *iv, int rounds);
+int count = (rnd() & (MAX_COUNT - 1)) + 1;
+for (j = 0; j < 16 * MAX_COUNT; j++)
+pt[j] = rnd();
+for (j = 0; j < 16; j++)
+iv[0][j] = iv[1][j] = rnd();
+call_ref(, temp[0], pt, count, iv[0], b.rounds);
+call_new(, temp[1], pt, count, iv[1], b.rounds);
+if (memcmp(temp[0], temp[1], sizeof(16 * count)))
+fail();
+if (memcmp(iv[0], iv[1], sizeof(iv[0])))
+fail();
+call_ref(, temp[0], pt, count, NULL, b.rounds);
+call_new(, temp[1], pt, count, NULL, b.rounds);
+if (memcmp(temp[0], temp[1], sizeof(16 * count)))
+fail();
+if (memcmp(iv[0], iv[1], sizeof(iv[0])))
+fail();
+bench_new(, temp[1], pt, MAX_COUNT, NULL, b.rounds);
+}
+}
+report("%scrypt", d ? "de" : "en");
+}
+}
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index e875120..f5b28dc 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -57,6 +57,7 @@ static const struct {
 const char *name;
 void (*func)(void);
 } tests[] = {
+{ "aes", checkasm_check_aes },
 #if CONFIG_AVCODEC
 #if CONFIG_ALAC_DECODER
 { "alacdsp", checkasm_check_alacdsp },
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 1775a25..3b39e16 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -29,6 +29,7 @@
 #include "libavutil/lfg.h"
 #include "libavutil/timer.h"
 
+void checkasm_check_aes(void);
 void checkasm_check_alacdsp(void);
 void checkasm_check_bswapdsp(void);
 void checkasm_check_flacdsp(void);
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 5/8] tools/crypto_bench: add AES-CBC modes

[Rodger Combs]

---
 tools/crypto_bench.c | 140 +--
 1 file changed, 137 insertions(+), 3 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index ad20f95..15bb5f1 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -52,6 +52,7 @@ static const char *enabled_algos;
 static unsigned specified_runs;
 
 static const uint8_t *hardcoded_key = "FFmpeg is the best program ever.";
+static const uint8_t hardcoded_iv[16] = {0};
 
 static void fatal_error(const char *tag)
 {
@@ -136,6 +137,39 @@ static void run_lavu_aes256(uint8_t *output, const uint8_t 
*input, unsigned size
 av_aes_crypt(aes, output, input, size >> 4, NULL, 0);
 }
 
+static void run_lavu_aes128cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
+{
+static struct AVAES *aes;
+static uint8_t *iv;
+if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+av_aes_init(aes, hardcoded_key, 128, 0);
+av_aes_crypt(aes, output, input, size >> 4, iv, 0);
+}
+
+static void run_lavu_aes192cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
+{
+static struct AVAES *aes;
+static uint8_t *iv;
+if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+av_aes_init(aes, hardcoded_key, 192, 0);
+av_aes_crypt(aes, output, input, size >> 4, iv, 0);
+}
+
+static void run_lavu_aes256cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
+{
+static struct AVAES *aes;
+static uint8_t *iv;
+if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+av_aes_init(aes, hardcoded_key, 256, 0);
+av_aes_crypt(aes, output, input, size >> 4, iv, 0);
+}
+
 static void run_lavu_blowfish(uint8_t *output,
   const uint8_t *input, unsigned size)
 {
@@ -258,6 +292,42 @@ static void run_crypto_aes256(uint8_t *output, const 
uint8_t *input, unsigned si
 AES_encrypt(input + i, output + i, );
 }
 
+static void run_crypto_aes128cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
+{
+AES_KEY aes;
+static uint8_t *iv;
+if ((!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+
+AES_set_encrypt_key(hardcoded_key, 128, );
+AES_cbc_encrypt(input, output, size, , iv, 1);
+}
+
+static void run_crypto_aes192cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
+{
+AES_KEY aes;
+static uint8_t *iv;
+if ((!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+
+AES_set_encrypt_key(hardcoded_key, 192, );
+AES_cbc_encrypt(input, output, size, , iv, 1);
+}
+
+static void run_crypto_aes256cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
+{
+AES_KEY aes;
+static uint8_t *iv;
+if ((!iv && !(iv = av_malloc(16
+fatal_error("out of memory");
+memcpy(iv, hardcoded_iv, 16);
+
+AES_set_encrypt_key(hardcoded_key, 256, );
+AES_cbc_encrypt(input, output, size, , iv, 1);
+}
+
 static void run_crypto_blowfish(uint8_t *output,
 const uint8_t *input, unsigned size)
 {
@@ -355,6 +425,39 @@ static void run_gcrypt_aes256(uint8_t *output, const 
uint8_t *input, unsigned si
 gcry_cipher_encrypt(aes, output, size, input, size);
 }
 
+static void run_gcrypt_aes128cbc(uint8_t *output,
+  const uint8_t *input, unsigned size)
+{
+static gcry_cipher_hd_t aes;
+if (!aes)
+gcry_cipher_open(, GCRY_CIPHER_AES128, GCRY_CIPHER_MODE_CBC, 0);
+gcry_cipher_setkey(aes, hardcoded_key, 16);
+gcry_cipher_setiv(aes, hardcoded_iv, 16);
+gcry_cipher_encrypt(aes, output, size, input, size);
+}
+
+static void run_gcrypt_aes192cbc(uint8_t *output,
+  const uint8_t *input, unsigned size)
+{
+static gcry_cipher_hd_t aes;
+if (!aes)
+gcry_cipher_open(, GCRY_CIPHER_AES192, GCRY_CIPHER_MODE_CBC, 0);
+gcry_cipher_setkey(aes, hardcoded_key, 24);
+gcry_cipher_setiv(aes, hardcoded_iv, 16);
+gcry_cipher_encrypt(aes, output, size, input, size);
+}
+
+static void run_gcrypt_aes256cbc(uint8_t *output,
+  const uint8_t *input, unsigned size)
+{
+static gcry_cipher_hd_t aes;
+if (!aes)
+gcry_cipher_open(, GCRY_CIPHER_AES256, GCRY_CIPHER_MODE_CBC, 0);
+gcry_cipher_setkey(aes, hardcoded_key, 32);
+gcry_cipher_setiv(aes, hardcoded_iv, 16);
+gcry_cipher_encrypt(aes, output, size, input, size);
+}
+
 static void run_gcrypt_blowfish(uint8_t *output,
 const uint8_t *input, unsigned size)
 {
@@ -459,6 +562,30 @@ static void run_tomcrypt_aes256(uint8_t *output, const 
uint8_t *input, unsigned
 

[FFmpeg-devel] [PATCH 6/8] tools/crypto_bench: switch to OpenSSL's faster AES API

[Rodger Combs]

---
 tools/crypto_bench.c | 85 +---
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index 15bb5f1..8a468ba 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -244,6 +244,7 @@ static void run_lavu_xtea(uint8_t *output,
 #include 
 #include 
 #include 
+#include 
 
 #define DEFINE_CRYPTO_WRAPPER(suffix, function)  \
 static void run_crypto_ ## suffix(uint8_t *output,   \
@@ -258,74 +259,82 @@ DEFINE_CRYPTO_WRAPPER(sha256,SHA256)
 DEFINE_CRYPTO_WRAPPER(sha512,SHA512)
 DEFINE_CRYPTO_WRAPPER(ripemd160, RIPEMD160)
 
-static void run_crypto_aes128(uint8_t *output,
-  const uint8_t *input, unsigned size)
+static void run_crypto_aes128(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 128, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_128_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes192(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 192, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_192_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes256(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 256, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_256_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes128cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 128, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_128_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes192cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 192, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_192_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes256cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 256, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_256_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_blowfish(uint8_t *output,
-- 
2.6.2

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