Re: [FFmpeg-devel] [PATCH] avcodec/tak: remove GetBitContext usage from avpriv_tak_parse_streaminfo()

[James Almer]

On 10/25/2017 4:37 AM, Paul B Mahol wrote:
> On 10/23/17, James Almer  wrote:
>> This prevents potential ABI issues with GetBitContext.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/tak.c | 17 +++--
>>  libavcodec/tak.h |  8 ++--
>>  libavformat/takdec.c |  7 +--
>>  3 files changed, 26 insertions(+), 6 deletions(-)
>>
> 
> lgtm

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

Re: [FFmpeg-devel] [PATCH] avcodec/exif: remove GetByteContext usage from avpriv_exif_decode_ifd()

[James Almer]

On 10/25/2017 4:32 AM, Paul B Mahol wrote:
> On 10/24/17, James Almer  wrote:
>> This prevents potential ABI issues with GetByteContext.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/exif.c | 16 +---
>>  libavcodec/exif.h |  6 --
>>  libavcodec/mjpegdec.c |  2 +-
>>  libavcodec/webp.c |  2 +-
>>  libavformat/avidec.c  |  4 ++--
>>  5 files changed, 21 insertions(+), 9 deletions(-)
>>
> 
> 
> lgtm

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

Re: [FFmpeg-devel] [PATCH] fate: fix mpeg2-ticket6677 faillures on some platforms

[Michael Niedermayer]

On Wed, Oct 25, 2017 at 01:45:22PM +0800, Zhong Li wrote:
> Signed-off-by: Zhong Li 
> ---
>  tests/fate/video.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4

[Michael Niedermayer]

On Wed, Oct 25, 2017 at 06:48:06PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Oct 25, 2017 at 5:57 PM, Carl Eugen Hoyos 
> wrote:
> 
> > 2017-10-25 16:52 GMT+02:00 Jean-Yves Avenard :
> > > hi
> > >
> > > On 26 August 2017 at 12:08, Carl Eugen Hoyos  wrote:
> > >> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
> > >>
> > >>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
> > >>
> > >> Why does this only apply to flac?
> > >>
> > >
> > > Sorry, I had missed your reply.
> > >
> > > The specification on how sampling rate is to be stored should it be
> > > greater than INT16_MAX is a FLAC in ISOBMFF requirement:
> > >
> > > https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=
> > 574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
> > >
> > > It definitely could be applied to other codecs, but I haven't seen
> > > such requirements clearly defined.
> > >
> > > ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
> > > in which case the sampling_rate is a 32 bits integer (ISO 14496-12
> > > 12.2.3.2)
> >
> > Not sure I understand:
> > In ticket #6609, I asked if this is a flac-only issue.
> > You answered: "The issue can be reproduced with any codec."
> >
> > So why does your patch only fix the issue for flac?
> > Or do I misunderstand?
> >
> 
> The extension for storing values greater than int16_max is only part of the
> isobmff-flac spec, it's not generalized for other audio codecs. Using it
> for other audio codecs may have unwanted results, which is why it's
> flac-specific.
> 

> Do you want a comment in the source code to make this easier to understand
> for future developers staring at this code?

the question wasnt intended for me, but yes 

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: fix missing first segment bug in fmp4 mode

[Steven Liu]

fix ticket id: #6776
fix code logic error, need not check first segment.

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 55ce800c5a..caced6a3dd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1080,15 +1080,16 @@ static int hls_window(AVFormatContext *s, int last)
 avio_printf(out, ",BYTERANGE=\"%"PRId64"@%"PRId64"\"", 
en->size, en->pos);
 }
 avio_printf(out, "\n");
-} else {
-if (hls->flags & HLS_ROUND_DURATIONS)
-avio_printf(out, "#EXTINF:%ld,\n",  lrint(en->duration));
-else
-avio_printf(out, "#EXTINF:%f,\n", en->duration);
-if (byterange_mode)
-avio_printf(out, "#EXT-X-BYTERANGE:%"PRId64"@%"PRId64"\n",
-en->size, en->pos);
 }
+
+if (hls->flags & HLS_ROUND_DURATIONS)
+avio_printf(out, "#EXTINF:%ld,\n",  lrint(en->duration));
+else
+avio_printf(out, "#EXTINF:%f,\n", en->duration);
+if (byterange_mode)
+avio_printf(out, "#EXT-X-BYTERANGE:%"PRId64"@%"PRId64"\n",
+en->size, en->pos);
+
 if (hls->flags & HLS_PROGRAM_DATE_TIME) {
 time_t tt, wrongsecs;
 int milli;
@@ -1113,11 +1114,10 @@ static int hls_window(AVFormatContext *s, int last)
 avio_printf(out, "#EXT-X-PROGRAM-DATE-TIME:%s.%03d%s\n", buf0, 
milli, buf1);
 prog_date_time += en->duration;
 }
-if (!((hls->segment_type == SEGMENT_TYPE_FMP4) && (en == 
hls->segments))) {
-if (hls->baseurl)
-avio_printf(out, "%s", hls->baseurl);
-avio_printf(out, "%s\n", en->filename);
-}
+
+if (hls->baseurl)
+avio_printf(out, "%s", hls->baseurl);
+avio_printf(out, "%s\n", en->filename);
 }
 
 if (last && (hls->flags & HLS_OMIT_ENDLIST)==0)
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix base_output_dirname is null when basename_size is 0 bug

[Steven Liu]

fix ticket id: #6777
when use argument hls_segment_filename, the basename_size will be 0

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 418f153c6f..55ce800c5a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1335,6 +1335,7 @@ static int hls_write_header(AVFormatContext *s)
 AVDictionary *options = NULL;
 int basename_size = 0;
 int vtt_basename_size = 0;
+int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
 
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 pattern = "%d.m4s";
@@ -1445,7 +1446,6 @@ static int hls_write_header(AVFormatContext *s)
 }
 
 if (av_strcasecmp(hls->fmp4_init_filename, "init.mp4")) {
-int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
 hls->base_output_dirname = av_malloc(fmp4_init_filename_len);
 if (!hls->base_output_dirname) {
 ret = AVERROR(ENOMEM);
@@ -1453,19 +1453,25 @@ static int hls_write_header(AVFormatContext *s)
 }
 av_strlcpy(hls->base_output_dirname, hls->fmp4_init_filename, 
fmp4_init_filename_len);
 } else {
-hls->base_output_dirname = av_malloc(basename_size);
+if (basename_size > 0) {
+hls->base_output_dirname = av_malloc(basename_size);
+} else {
+hls->base_output_dirname = 
av_malloc(strlen(hls->fmp4_init_filename));
+}
 if (!hls->base_output_dirname) {
 ret = AVERROR(ENOMEM);
 goto fail;
 }
 
-av_strlcpy(hls->base_output_dirname, s->filename, basename_size);
-p = strrchr(hls->base_output_dirname, '/');
+if (basename_size > 0) {
+av_strlcpy(hls->base_output_dirname, s->filename, basename_size);
+p = strrchr(hls->base_output_dirname, '/');
+}
 if (p) {
 *(p + 1) = '\0';
 av_strlcat(hls->base_output_dirname, hls->fmp4_init_filename, 
basename_size);
 } else {
-av_strlcpy(hls->base_output_dirname, hls->fmp4_init_filename, 
basename_size);
+av_strlcpy(hls->base_output_dirname, hls->fmp4_init_filename, 
fmp4_init_filename_len);
 }
 }
 
-- 
2.11.0 (Apple Git-81)



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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Thierry Foucu]

On Wed, Oct 25, 2017 at 4:36 PM, Michael Niedermayer  wrote:

> On Wed, Oct 25, 2017 at 04:21:28PM -0700, Thierry Foucu wrote:
> > On Wed, Oct 25, 2017 at 2:43 PM, Carl Eugen Hoyos 
> > wrote:
> >
> > > 2017-10-25 20:38 GMT+02:00 Thierry Foucu :
> > >
> > > > Without the patch, the decoder will return only 29 frames
> > >
> > > Isn't that the correct and expected output?
> > >
> >
> > Not sure what you mean by correct.
> > There are only 29 VOP encoded, and over 1900 N_VOP packets.
> > If you just demux the sample file, you will get 1947 packets
> >
> > I used the Xvid decoder from
> > http://svn.xvid.org/trunk/xvidcore/examples/xvid_decraw.c
> >
> > to decode the same file, and their decoder outputted 1947 frames.
> >
> >
> > >
> > > If you need cfr, you can request it.
> > >
> >
> > true, but this works as long as you have 2 frames and you can cfr between
> > them. But what if you have the last X second of the file with only N_VOP
> > frames
> > In this case, the decoder will not output frames and the transcoded file
> > will be shorter by X second
>
> the decoder could output a final frame during decoder flush to make
> sure the last NVOPs duration is not lost
>

Oh, that's sound interesting. Let me see if i understand the code enough to
do exactly this.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are too smart to engage in politics are punished by being
> governed by those who are dumber. -- Plato
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Michael Niedermayer]

On Wed, Oct 25, 2017 at 04:21:28PM -0700, Thierry Foucu wrote:
> On Wed, Oct 25, 2017 at 2:43 PM, Carl Eugen Hoyos 
> wrote:
> 
> > 2017-10-25 20:38 GMT+02:00 Thierry Foucu :
> >
> > > Without the patch, the decoder will return only 29 frames
> >
> > Isn't that the correct and expected output?
> >
> 
> Not sure what you mean by correct.
> There are only 29 VOP encoded, and over 1900 N_VOP packets.
> If you just demux the sample file, you will get 1947 packets
> 
> I used the Xvid decoder from
> http://svn.xvid.org/trunk/xvidcore/examples/xvid_decraw.c
> 
> to decode the same file, and their decoder outputted 1947 frames.
> 
> 
> >
> > If you need cfr, you can request it.
> >
> 
> true, but this works as long as you have 2 frames and you can cfr between
> them. But what if you have the last X second of the file with only N_VOP
> frames
> In this case, the decoder will not output frames and the transcoded file
> will be shorter by X second

the decoder could output a final frame during decoder flush to make
sure the last NVOPs duration is not lost

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

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


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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Thierry Foucu]

On Wed, Oct 25, 2017 at 2:43 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-25 20:38 GMT+02:00 Thierry Foucu :
>
> > Without the patch, the decoder will return only 29 frames
>
> Isn't that the correct and expected output?
>

Not sure what you mean by correct.
There are only 29 VOP encoded, and over 1900 N_VOP packets.
If you just demux the sample file, you will get 1947 packets

I used the Xvid decoder from
http://svn.xvid.org/trunk/xvidcore/examples/xvid_decraw.c

to decode the same file, and their decoder outputted 1947 frames.


>
> If you need cfr, you can request it.
>

true, but this works as long as you have 2 frames and you can cfr between
them. But what if you have the last X second of the file with only N_VOP
frames
In this case, the decoder will not output frames and the transcoded file
will be shorter by X second


> Once the frames are duplicated, you can't undo the file
> size multiplication.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/crc: always use precalculated CRC tables for known polynomials

[Muhammad Faiz]

On Tue, Oct 24, 2017 at 6:05 PM, Michael Niedermayer
 wrote:
> On Mon, Oct 23, 2017 at 10:36:21PM -0300, James Almer wrote:
>> On 10/23/2017 10:24 PM, Michael Niedermayer wrote:
>> > On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote:
>> >> On 24/10/17 00:52, Michael Niedermayer wrote:
>> >>> Hi
>> >>>
>> >>> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote:
>>  On 23/10/17 03:56, Michael Niedermayer wrote:
>> > the initialization should be thread safe as it never writes a different
>> > value in the same spot
>> 
>>  This is not true; please be very careful with assumptions like this.
>> 
>>  The C standard calls this a data race and it is undefined behaviour.
>> >>>
>> >>> Thats interresting, we definitly do not want undefined behavior
>> >>> can you quote the relevant parts of the C standard
>> >>> which make writing the same value, a data race ?
>> >>>
>> >>> I was not aware of this if its true.
>> >>> Also i dont immedeatly see this in the "latest" draft i am looking at
>> >>> atm
>> >>>
>> >>> What i see is this:
>> >>> 4 Two expression evaluations conflict if one of them modifies a memory 
>> >>> location and the
>> >>>   other one reads or modifies the same memory location.
>> >>> ...
>> >>> 25 The execution of a program contains a data race if it contains two 
>> >>> conflicting actions in
>> >>>different threads, at least one of which is not atomic, and neither 
>> >>> happens before the
>> >>>other. Any such data race results in undefined behavior.
>> >>>
>> >>> This seems carefully worded to not include writing the same value.
>> >>> As "modification" implies change which does not occur when writing the
>> >>> same value.
>> >>
>> >> All writes are modifications.
>> >>
>> >> See section 3.1 note 2:
>> >> """
>> >> 3 NOTE 2   "Modify"€™ includes the case where the new value being stored 
>> >> is the same as the previous value.
>> >> """
>> >
>> > That resolves the difference between our interpretation
>> >
>> > thanks
>>
>> Should i push this, or does someone want to give ff_thread_once() a try?
>
> If ff_thread_once() is used outside init code, it should be benchmarked
> as it may be a bad idea speed wise.
> During init speed doesnt matter so ff_thread_once() there would be fine
> but would require more changes to move it to init.

Using my patch:
Benchmark: make fate-lavf-png at pngenc.c:png_write_chunk
old:
 150640 decicycles in av_crc_get_table:first, 1 runs,  0 skips
   1740 decicycles in av_crc_get_table,   1 runs,  0 skips
   1390 decicycles in av_crc_get_table,   2 runs,  0 skips
945 decicycles in av_crc_get_table,   4 runs,  0 skips
720 decicycles in av_crc_get_table,   8 runs,  0 skips
592 decicycles in av_crc_get_table,  16 runs,  0 skips
536 decicycles in av_crc_get_table,  32 runs,  0 skips
510 decicycles in av_crc_get_table,  64 runs,  0 skips
497 decicycles in av_crc_get_table, 128 runs,  0 skips
494 decicycles in av_crc_get_table, 256 runs,  0 skips
479 decicycles in av_crc_get_table, 512 runs,  0 skips
454 decicycles in av_crc_get_table,1024 runs,  0 skips
434 decicycles in av_crc_get_table,2048 runs,  0 skips


new:
 235060 decicycles in av_crc_get_table:first, 1 runs,  0 skips
   2900 decicycles in av_crc_get_table,   1 runs,  0 skips
   2560 decicycles in av_crc_get_table,   2 runs,  0 skips
   1825 decicycles in av_crc_get_table,   4 runs,  0 skips
   1200 decicycles in av_crc_get_table,   8 runs,  0 skips
902 decicycles in av_crc_get_table,  16 runs,  0 skips
719 decicycles in av_crc_get_table,  32 runs,  0 skips
628 decicycles in av_crc_get_table,  64 runs,  0 skips
576 decicycles in av_crc_get_table, 128 runs,  0 skips
550 decicycles in av_crc_get_table, 256 runs,  0 skips
532 decicycles in av_crc_get_table, 512 runs,  0 skips
499 decicycles in av_crc_get_table,1024 runs,  0 skips
470 decicycles in av_crc_get_table,2048 runs,  0 skips

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

Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4

[Ronald S. Bultje]

Hi,

On Wed, Oct 25, 2017 at 5:57 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-25 16:52 GMT+02:00 Jean-Yves Avenard :
> > hi
> >
> > On 26 August 2017 at 12:08, Carl Eugen Hoyos  wrote:
> >> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
> >>
> >>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
> >>
> >> Why does this only apply to flac?
> >>
> >
> > Sorry, I had missed your reply.
> >
> > The specification on how sampling rate is to be stored should it be
> > greater than INT16_MAX is a FLAC in ISOBMFF requirement:
> >
> > https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=
> 574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
> >
> > It definitely could be applied to other codecs, but I haven't seen
> > such requirements clearly defined.
> >
> > ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
> > in which case the sampling_rate is a 32 bits integer (ISO 14496-12
> > 12.2.3.2)
>
> Not sure I understand:
> In ticket #6609, I asked if this is a flac-only issue.
> You answered: "The issue can be reproduced with any codec."
>
> So why does your patch only fix the issue for flac?
> Or do I misunderstand?
>

The extension for storing values greater than int16_max is only part of the
isobmff-flac spec, it's not generalized for other audio codecs. Using it
for other audio codecs may have unwanted results, which is why it's
flac-specific.

Do you want a comment in the source code to make this easier to understand
for future developers staring at this code?

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

[FFmpeg-devel] [PATCH 1/2] avcodec/jpeglsdec: Check ilv for being a supported value

[Michael Niedermayer]

Fixes: 1773/clusterfuzz-testcase-minimized-4832523987189760

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

diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index 64505321af..cb2f89a88c 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -443,6 +443,10 @@ int ff_jpegls_decode_picture(MJpegDecodeContext *s, int 
near,
 avpriv_report_missing_feature(s->avctx, "Sample interleaved images");
 ret = AVERROR_PATCHWELCOME;
 goto end;
+} else { /* unknown interleaving */
+avpriv_report_missing_feature(s->avctx, "Unknown interleaved images");
+ret = AVERROR_PATCHWELCOME;
+goto end;
 }
 
 if (s->xfrm && s->nb_components == 3) {
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line()

[Michael Niedermayer]

Fixes: 1773/clusterfuzz-testcase-minimized-4832523987189760

Fixes: Timeout

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

diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index cb2f89a88c..5308b744df 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -233,6 +233,9 @@ static inline void ls_decode_line(JLSState *state, 
MJpegDecodeContext *s,
 while (x < w) {
 int err, pred;
 
+if (get_bits_left(>gb) <= 0)
+return;
+
 /* compute gradients */
 Ra = x ? R(dst, x - stride) : R(last, x);
 Rb = R(last, x);
-- 
2.14.2

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] cbs_mpeg2: Fix type for marker_bit reading

[Carl Eugen Hoyos]

2017-10-25 10:06 GMT+02:00 Hendrik Leppkes :

> As if static analyzers always care what you can and cannot do. :p

It was actually asan or ubsan iirc.

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

Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4

[Carl Eugen Hoyos]

2017-10-25 16:52 GMT+02:00 Jean-Yves Avenard :
> hi
>
> On 26 August 2017 at 12:08, Carl Eugen Hoyos  wrote:
>> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
>>
>>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
>>
>> Why does this only apply to flac?
>>
>
> Sorry, I had missed your reply.
>
> The specification on how sampling rate is to be stored should it be
> greater than INT16_MAX is a FLAC in ISOBMFF requirement:
>
> https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
>
> It definitely could be applied to other codecs, but I haven't seen
> such requirements clearly defined.
>
> ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
> in which case the sampling_rate is a 32 bits integer (ISO 14496-12
> 12.2.3.2)

Not sure I understand:
In ticket #6609, I asked if this is a flac-only issue.
You answered: "The issue can be reproduced with any codec."

So why does your patch only fix the issue for flac?
Or do I misunderstand?

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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Carl Eugen Hoyos]

2017-10-25 20:38 GMT+02:00 Thierry Foucu :

> Without the patch, the decoder will return only 29 frames

Isn't that the correct and expected output?

If you need cfr, you can request it.
Once the frames are duplicated, you can't undo the file
size multiplication.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Derek Buitenhuis]

This time to the list properly... woops.

On 10/25/2017 7:38 PM, Thierry Foucu wrote:
> I tried using one of those files.
> Without the patch, the decoder will return only 29 frames
> With this patch, the decoder will return 1947 frames.
> The time of decoding the file were the same (with or without)

Makes sense (because of reference counting).

> I think where it may slow down, it's in case we transcode the file and we
> are not doing constant frame rate, then the encoder will have to encode
> 1947 frames instead of 24 frames.
> But for decoding it the same.

Yeah, that's what I thought might happen. However, thinking about it
a bit more, these files are old and rare enough that we probably shouldn't
care about such an edge case, and the decoder outputting duplicate frames
is probably easier for the API user.

So, no objection from me.

- Derek

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

Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Paul B Mahol]

On 10/25/17, Martin Vignali  wrote:
> 2017-10-25 22:08 GMT+02:00 Paul B Mahol :
>
>> On 10/25/17, Martin Vignali  wrote:
>> > 2017-10-25 21:53 GMT+02:00 Paul B Mahol :
>> >
>> >> On 10/25/17, Martin Vignali  wrote:
>> >> > 2017-10-25 9:43 GMT+02:00 Paul B Mahol :
>> >> >
>> >> >> On 10/21/17, Martin Vignali  wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > In attach patch to add AVX2 version for add_bytes
>> >> >> >
>> >> >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
>> >> >> > add AVX2 version
>> >> >> >
>> >> >> > pass fate-test for me (os 10.12, x86_64)
>> >> >> >
>> >> >> > checkasm result : (Kaby Lake) (run 10 times, and i took the
>> >> >> > fastest
>> >> >> > version)
>> >> >> > checkasm: all 2 tests passed
>> >> >> > add_bytes_c: 108.7
>> >> >> > add_bytes_sse2: 26.5
>> >> >> > add_bytes_avx2: 15.5
>> >> >> >
>> >> >> >
>> >> >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
>> >> >> > only cosmetic
>> >> >> > like the ref c function declaration in asm file is not consistent
>> >> >> > between
>> >> >> > each asm file
>> >> >> > i think a better separator for each function make the file easier
>> to
>> >> >> > read
>> >> >> >
>> >> >> > also add the c declaration for add bytes in comment
>> >> >> >
>> >> >> >
>> >> >> > Martin
>> >> >> >
>> >> >>
>> >> >> Are you sure 32bit alignment is actually enforced?
>> >> >>
>> >> >>
>> >> > Hello,
>> >> >
>> >> > I think, data used by add_bytes is always aligned
>> >> > because dst and src, are start of a line of an AvFrame
>> >>
>> >> Yes, but try width thats not multiple of 32.
>> >> ___
>> >>
>> >>
>> > Sorry, not sure i understand.
>> > following the doc, AVFrame->linesize, is multiple of max alignment
>> >
>> > and in the asm, loop will be repeat until, val < width
>> >
>> > Can you indicate me, the part, where you think, it's not ok ?
>>
>> I dunno. You should test it with widths not divisible by 32.
>>
>
> Tested with the fate sample : vsynth3-huffyuvbgra.avi (34x34)
> ./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc -
>
> generate same crc than
> ./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc -
> -cpuflags 0
>
>
>>
>> also try encoding cropped video.
>>
>
> Are you sure, encoding cropped video, have a link to the decoding dsp func ?
>
> these patch only take care about the decoding func
>
>
> And the encoding func of huffyuvenc (in huffyuv add add/diff_bytes16 AVX2
> discussion)
> and losslessencdsp (not made for now), have a test for alignment of dst and
> src
>
>
> Martin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


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

Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Martin Vignali]

2017-10-25 22:08 GMT+02:00 Paul B Mahol :

> On 10/25/17, Martin Vignali  wrote:
> > 2017-10-25 21:53 GMT+02:00 Paul B Mahol :
> >
> >> On 10/25/17, Martin Vignali  wrote:
> >> > 2017-10-25 9:43 GMT+02:00 Paul B Mahol :
> >> >
> >> >> On 10/21/17, Martin Vignali  wrote:
> >> >> > Hello,
> >> >> >
> >> >> > In attach patch to add AVX2 version for add_bytes
> >> >> >
> >> >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
> >> >> > add AVX2 version
> >> >> >
> >> >> > pass fate-test for me (os 10.12, x86_64)
> >> >> >
> >> >> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest
> >> >> > version)
> >> >> > checkasm: all 2 tests passed
> >> >> > add_bytes_c: 108.7
> >> >> > add_bytes_sse2: 26.5
> >> >> > add_bytes_avx2: 15.5
> >> >> >
> >> >> >
> >> >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
> >> >> > only cosmetic
> >> >> > like the ref c function declaration in asm file is not consistent
> >> >> > between
> >> >> > each asm file
> >> >> > i think a better separator for each function make the file easier
> to
> >> >> > read
> >> >> >
> >> >> > also add the c declaration for add bytes in comment
> >> >> >
> >> >> >
> >> >> > Martin
> >> >> >
> >> >>
> >> >> Are you sure 32bit alignment is actually enforced?
> >> >>
> >> >>
> >> > Hello,
> >> >
> >> > I think, data used by add_bytes is always aligned
> >> > because dst and src, are start of a line of an AvFrame
> >>
> >> Yes, but try width thats not multiple of 32.
> >> ___
> >>
> >>
> > Sorry, not sure i understand.
> > following the doc, AVFrame->linesize, is multiple of max alignment
> >
> > and in the asm, loop will be repeat until, val < width
> >
> > Can you indicate me, the part, where you think, it's not ok ?
>
> I dunno. You should test it with widths not divisible by 32.
>

Tested with the fate sample : vsynth3-huffyuvbgra.avi (34x34)
./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc -

generate same crc than
./ffmpeg -i ./tests/data/fate/vsynth3-huffyuvbgra.avi -f framecrc -
-cpuflags 0


>
> also try encoding cropped video.
>

Are you sure, encoding cropped video, have a link to the decoding dsp func ?

these patch only take care about the decoding func


And the encoding func of huffyuvenc (in huffyuv add add/diff_bytes16 AVX2
discussion)
and losslessencdsp (not made for now), have a test for alignment of dst and
src


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

Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Paul B Mahol]

On 10/25/17, Martin Vignali  wrote:
> 2017-10-25 21:53 GMT+02:00 Paul B Mahol :
>
>> On 10/25/17, Martin Vignali  wrote:
>> > 2017-10-25 9:43 GMT+02:00 Paul B Mahol :
>> >
>> >> On 10/21/17, Martin Vignali  wrote:
>> >> > Hello,
>> >> >
>> >> > In attach patch to add AVX2 version for add_bytes
>> >> >
>> >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
>> >> > add AVX2 version
>> >> >
>> >> > pass fate-test for me (os 10.12, x86_64)
>> >> >
>> >> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest
>> >> > version)
>> >> > checkasm: all 2 tests passed
>> >> > add_bytes_c: 108.7
>> >> > add_bytes_sse2: 26.5
>> >> > add_bytes_avx2: 15.5
>> >> >
>> >> >
>> >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
>> >> > only cosmetic
>> >> > like the ref c function declaration in asm file is not consistent
>> >> > between
>> >> > each asm file
>> >> > i think a better separator for each function make the file easier to
>> >> > read
>> >> >
>> >> > also add the c declaration for add bytes in comment
>> >> >
>> >> >
>> >> > Martin
>> >> >
>> >>
>> >> Are you sure 32bit alignment is actually enforced?
>> >>
>> >>
>> > Hello,
>> >
>> > I think, data used by add_bytes is always aligned
>> > because dst and src, are start of a line of an AvFrame
>>
>> Yes, but try width thats not multiple of 32.
>> ___
>>
>>
> Sorry, not sure i understand.
> following the doc, AVFrame->linesize, is multiple of max alignment
>
> and in the asm, loop will be repeat until, val < width
>
> Can you indicate me, the part, where you think, it's not ok ?

I dunno. You should test it with widths not divisible by 32.

also try encoding cropped video.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Martin Vignali]

2017-10-25 21:53 GMT+02:00 Paul B Mahol :

> On 10/25/17, Martin Vignali  wrote:
> > 2017-10-25 9:43 GMT+02:00 Paul B Mahol :
> >
> >> On 10/21/17, Martin Vignali  wrote:
> >> > Hello,
> >> >
> >> > In attach patch to add AVX2 version for add_bytes
> >> >
> >> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
> >> > add AVX2 version
> >> >
> >> > pass fate-test for me (os 10.12, x86_64)
> >> >
> >> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest
> >> > version)
> >> > checkasm: all 2 tests passed
> >> > add_bytes_c: 108.7
> >> > add_bytes_sse2: 26.5
> >> > add_bytes_avx2: 15.5
> >> >
> >> >
> >> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
> >> > only cosmetic
> >> > like the ref c function declaration in asm file is not consistent
> >> > between
> >> > each asm file
> >> > i think a better separator for each function make the file easier to
> >> > read
> >> >
> >> > also add the c declaration for add bytes in comment
> >> >
> >> >
> >> > Martin
> >> >
> >>
> >> Are you sure 32bit alignment is actually enforced?
> >>
> >>
> > Hello,
> >
> > I think, data used by add_bytes is always aligned
> > because dst and src, are start of a line of an AvFrame
>
> Yes, but try width thats not multiple of 32.
> ___
>
>
Sorry, not sure i understand.
following the doc, AVFrame->linesize, is multiple of max alignment

and in the asm, loop will be repeat until, val < width

Can you indicate me, the part, where you think, it's not ok ?

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

Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Paul B Mahol]

On 10/25/17, Martin Vignali  wrote:
> 2017-10-25 9:43 GMT+02:00 Paul B Mahol :
>
>> On 10/21/17, Martin Vignali  wrote:
>> > Hello,
>> >
>> > In attach patch to add AVX2 version for add_bytes
>> >
>> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
>> > add AVX2 version
>> >
>> > pass fate-test for me (os 10.12, x86_64)
>> >
>> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest
>> > version)
>> > checkasm: all 2 tests passed
>> > add_bytes_c: 108.7
>> > add_bytes_sse2: 26.5
>> > add_bytes_avx2: 15.5
>> >
>> >
>> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
>> > only cosmetic
>> > like the ref c function declaration in asm file is not consistent
>> > between
>> > each asm file
>> > i think a better separator for each function make the file easier to
>> > read
>> >
>> > also add the c declaration for add bytes in comment
>> >
>> >
>> > Martin
>> >
>>
>> Are you sure 32bit alignment is actually enforced?
>>
>>
> Hello,
>
> I think, data used by add_bytes is always aligned
> because dst and src, are start of a line of an AvFrame

Yes, but try width thats not multiple of 32.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/utvideodsp : add avx2 version

[Martin Vignali]

2017-10-22 14:05 GMT+02:00 Martin Vignali :

> Hello,
>
> In attach patch to add AVX2 version for the utvideodsp
>
> Checkasm result (Kaby Lake, os 10.12)
> restore_rgb_planes_c: 8371.0
> restore_rgb_planes_sse2: 6583.7
> restore_rgb_planes_avx2: 3596.5
>
> restore_rgb_planes10_c: 16735.7
> restore_rgb_planes10_sse2: 11478.5
> restore_rgb_planes10_avx2: 7193.7
>
>
> Pass fate test for me
>
>
> 0001-checkasm-add-utvideodsp-test :
> I'm not entirely sure of mine, for this checkasm,
>
> 0002-libavcodec-x86-utvideodsp-make-macro-for-func
> Code reorganization
>
> 0003-libavcodec-utvideodsp-add-avx2-version-for-the-dsp
> AVX2 version
>
> 0004-libavcodec-x86-utvideodsp.asm-cosmetic
> Cosmetic
>
> Martin
> Jokyo Images
>
>
Following comments of Paul B Mahol in another thread

Here too, data alignment "is made" with AVFrame->data / AVFrame->linesize

these func are call with this code :

c->utdsp.restore_rgb_planes(frame.f->data[2], frame.f->data[0],
frame.f->data[1],
frame.f->linesize[2],
frame.f->linesize[0], frame.f->linesize[1],
avctx->width, avctx->height);
and
c->utdsp.restore_rgb_planes10((uint16_t *)frame.f->data[2], (uint16_t
*)frame.f->data[0], (uint16_t *)frame.f->data[1],
  frame.f->linesize[2] / 2,
frame.f->linesize[0] / 2, frame.f->linesize[1] / 2,
  avctx->width, avctx->height);


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

Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Martin Vignali]

2017-10-25 9:43 GMT+02:00 Paul B Mahol :

> On 10/21/17, Martin Vignali  wrote:
> > Hello,
> >
> > In attach patch to add AVX2 version for add_bytes
> >
> > 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
> > add AVX2 version
> >
> > pass fate-test for me (os 10.12, x86_64)
> >
> > checkasm result : (Kaby Lake) (run 10 times, and i took the fastest
> > version)
> > checkasm: all 2 tests passed
> > add_bytes_c: 108.7
> > add_bytes_sse2: 26.5
> > add_bytes_avx2: 15.5
> >
> >
> > 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
> > only cosmetic
> > like the ref c function declaration in asm file is not consistent between
> > each asm file
> > i think a better separator for each function make the file easier to read
> >
> > also add the c declaration for add bytes in comment
> >
> >
> > Martin
> >
>
> Are you sure 32bit alignment is actually enforced?
>
>
Hello,

I think, data used by add_bytes is always aligned
because dst and src, are start of a line of an AvFrame


More details :

the add_bytes func is used only by magicyuv and huffyuvdec

*in MagicYuv decoder*

uint8_t *b = p->data[0] + j * s->slice_height * p->linesize[0];
uint8_t *g = p->data[1] + j * s->slice_height * p->linesize[1];
uint8_t *r = p->data[2] + j * s->slice_height * p->linesize[2];
...
for (i = 0; i < height; i++) {
s->llviddsp.add_bytes(b, g, width);
s->llviddsp.add_bytes(r, g, width);
b += p->linesize[0];
g += p->linesize[1];
r += p->linesize[2];


*In Huffyuv Decoder*
add_bytes is call directly
or with a call to static void add_bytes(HYuvContext *s, uint8_t *dst,
uint8_t *src, int w)

*First use : *
add_bytes(s, dst, dst - fake_stride, w);

==>
uint8_t *dst = p->data[plane] + p->linesize[plane]*y;
and fake_stride is a multiple of linesize of the frame



*Second use :*
s->llviddsp.add_bytes(ydst, ydst - fake_ystride, width);

==> same idea here ydst is the start of a line
fake_ystride is a multiple of linesize


*Third use : *
s->llviddsp.add_bytes(ydst, ydst - fake_ystride, width);
if (!(s->flags & AV_CODEC_FLAG_GRAY)) {
s->llviddsp.add_bytes(udst, udst - fake_ustride, width2);
s->llviddsp.add_bytes(vdst, vdst - fake_vstride, width2);

==> Same idea here


*Last use : *
s->llviddsp.add_bytes(p->data[0] + p->linesize[0] * y, p->data[0] +
p->linesize[0] * y + fake_ystride, 4 * width);


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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Thierry Foucu]

On Wed, Oct 25, 2017 at 4:59 AM, Michael Niedermayer  wrote:

> On Tue, Oct 24, 2017 at 06:42:54PM -0700, Thierry Foucu wrote:
> > Changed the return value when no VOD were encoded in Mpeg4 bistream.
> > And if we do have already a decoded frames and we are not in xvid_packed
> > mode, output the existing decoded frame instead of nothing.
> > ---
> >  libavcodec/h263dec.c   | 9 -
> >  libavcodec/mpeg4videodec.c | 2 +-
> >  libavcodec/mpegutils.h | 1 +
> >  3 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> > index c7cf4bc0c2..394a366f9c 100644
> > --- a/libavcodec/h263dec.c
> > +++ b/libavcodec/h263dec.c
> > @@ -506,8 +506,15 @@ retry:
> >  s->height= avctx->coded_height;
> >  }
> >  }
> > -if (ret == FRAME_SKIPPED)
> > +if (ret == FRAME_SKIPPED || ret == FRAME_NOT_CODED) {
> > +if (s->next_picture_ptr && ret == FRAME_NOT_CODED &&
> !s->divx_packed) {
> > +if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0)
> {
> > +return ret;
> > +}
> > +*got_frame = 1;
> > +}
> >  return get_consumed_bytes(s, buf_size);
> > +}
> >
> >  /* skip if the header was thrashed */
> >  if (ret < 0) {
> > diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> > index 82c4f8fc8c..3a9ed12971 100644
> > --- a/libavcodec/mpeg4videodec.c
> > +++ b/libavcodec/mpeg4videodec.c
> > @@ -2394,7 +2394,7 @@ static int decode_vop_header(Mpeg4DecContext
> *ctx, GetBitContext *gb)
> >  if (get_bits1(gb) != 1) {
> >  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> >  av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
> > -return FRAME_SKIPPED;
> > +return FRAME_NOT_CODED;
> >  }
> >  if (ctx->new_pred)
> >  decode_new_pred(ctx, gb);
>
> the return codes are documented currently:
>  * @return <0 if no VOP found (or a damaged one)
>  * FRAME_SKIPPED if a not coded VOP is found
>  * 0 if a VOP is found
>
> you added a case but did not update all use cases
>
>
I can update the text here. But i was waiting to get some idea if the patch
seems to be ok for all of you or not.
If the idea sounds ok, I will update it.


> which seems to
> lead to intermittent crashes (i cant say for sure as i failed to
> reproduce one in a debugger or with any debuging code added)
>
>
i tried some files here and could not get any crash so far. I used asan as
well to find out if something was wrong.


> Also returning frames for skiped frames when te match the previous
> would slow the code down as more frames would need to be processed.
> more so i think this is not the only codec that can skip frames
> so any downstream problems will likely not be worked around by forcing
> constant fps with frame duplication here
>
>
True, but the decoder does not return a frame, so the got_output is set to
false for those packets and in this case, we are not increasing the
ist->next_pts

So, in we do have a lot of n_vop frame at the end, we are not setting the
next_pts to them and when we are closing the filtergraph, we are setting
the EOF time to the last decoded frame. And so, we are not padding the
video to match the original timestamp/duration of the input.




>
> [...]
> --
> 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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Thierry Foucu]

Derek,

On Wed, Oct 25, 2017 at 9:43 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 10/25/2017 2:42 AM, Thierry Foucu wrote:
> > Changed the return value when no VOD were encoded in Mpeg4 bistream.
> > And if we do have already a decoded frames and we are not in xvid_packed
> > mode, output the existing decoded frame instead of nothing.
> > ---
> >  libavcodec/h263dec.c   | 9 -
> >  libavcodec/mpeg4videodec.c | 2 +-
> >  libavcodec/mpegutils.h | 1 +
> >  3 files changed, 10 insertions(+), 2 deletions(-)
>
> Would this considerably slow down pathological files with a lot of
> NVOPs purposely inserted? For example, it use to be A Thing to use
> NVOPs to hack in "variable framerate" Xvid-in-avi encodes, by for
> example, setting the fps to 120 for a file with 24 and 30 fps sections,
> and padding the rest with NVOPs.
>

I tried using one of those files.
Without the patch, the decoder will return only 29 frames
With this patch, the decoder will return 1947 frames.
The time of decoding the file were the same (with or without)

I think where it may slow down, it's in case we transcode the file and we
are not doing constant frame rate, then the encoder will have to encode
1947 frames instead of 24 frames.
But for decoding it the same.


>
> Do we care about such files? (Probably not...)
>
> I can provide some samples, probably, if needed.
>
> - 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

[FFmpeg-devel] [PATCH 1/2] lavf/tls_securetransport: return buffered data first from tls_read

[Aman Gupta]

From: Aman Gupta 

This fixes a deadlock while reading a chunked https response, if
multiple_requests=1 is also set. Without an EOF to signal the end of
the last chunk, tls_read gets stuck forever trying to read more data
than is available. This occurs with the http protocol reproducibly,
because http.c always reads 4kb at a time, and the last chunk of an
http response is often much smaller.

After this commit, tls_read always returns any buffered plaintext
first before attempting to read more encrypted data off the
underlying tcp socket.
---
 libavformat/tls_securetransport.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/tls_securetransport.c 
b/libavformat/tls_securetransport.c
index bc8a32069e..9ea588ae3a 100644
--- a/libavformat/tls_securetransport.c
+++ b/libavformat/tls_securetransport.c
@@ -352,8 +352,12 @@ static int map_ssl_error(OSStatus status, size_t processed)
 static int tls_read(URLContext *h, uint8_t *buf, int size)
 {
 TLSContext *c = h->priv_data;
-size_t processed = 0;
-int ret = SSLRead(c->ssl_context, buf, size, );
+size_t available = 0, processed = 0;
+int ret;
+SSLGetBufferedReadSize(c->ssl_context, );
+if (available)
+size = FFMIN(available, size);
+ret = SSLRead(c->ssl_context, buf, size, );
 ret = map_ssl_error(ret, processed);
 if (ret > 0)
 return ret;
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/2] lavf/tls_securetransport: build on iOS

[Aman Gupta]

From: Aman Gupta 

This works as expected on iOS, except for the ca_file feature which
is disabled because SecItemImport is not available.
---
 configure | 6 +-
 libavformat/tls_securetransport.c | 4 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index c86e5788fa..a867077d66 100755
--- a/configure
+++ b/configure
@@ -2039,6 +2039,7 @@ SYSTEM_FUNCS="
 posix_memalign
 pthread_cancel
 sched_getaffinity
+SecItemImport
 SetConsoleTextAttribute
 SetConsoleCtrlHandler
 setmode
@@ -6164,9 +6165,12 @@ fi
 
 enabled securetransport &&
 check_func SecIdentityCreate "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security" &&
-check_lib securetransport "Security/SecureTransport.h Security/Security.h" 
"SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security" ||
+check_lib securetransport "Security/SecureTransport.h Security/Security.h" 
"SSLCreateContext" "-Wl,-framework,CoreFoundation -Wl,-framework,Security" ||
 disable securetransport
 
+enabled securetransport &&
+check_func SecItemImport "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security"
+
 enabled schannel &&
 check_func_headers "windows.h security.h" InitializeSecurityContext 
-DSECURITY_WIN32 -lsecur32 &&
 check_cpp_condition winerror.h "defined(SEC_I_CONTEXT_EXPIRED)" &&
diff --git a/libavformat/tls_securetransport.c 
b/libavformat/tls_securetransport.c
index 9ea588ae3a..69672f7676 100644
--- a/libavformat/tls_securetransport.c
+++ b/libavformat/tls_securetransport.c
@@ -69,6 +69,9 @@ static int print_tls_error(URLContext *h, int ret)
 
 static int import_pem(URLContext *h, char *path, CFArrayRef *array)
 {
+#if !HAVE_SECITEMIMPORT
+return AVERROR_PATCHWELCOME;
+#else
 AVIOContext *s = NULL;
 CFDataRef data = NULL;
 int64_t ret = 0;
@@ -124,6 +127,7 @@ end:
 if (s)
 avio_close(s);
 return ret;
+#endif
 }
 
 static int load_ca(URLContext *h)
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI

[Marton Balint]

On Fri, 6 Oct 2017, Devin Heitmueller wrote:


From: Devin Heitmueller 

Hook in libklvanc and use it for output of EIA-708 captions over
SDI.  The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.

Libklvanc can be found at: https://github.com/stoth68000/libklvanc


Sorry for the delay, I had little time lately. In general I think it is OK 
to put VANC functionality into a library, but libklvanc does not seem like 
a very mature one, it has some pretty generic function names without 
namespacing, e.g. "generate_vanc_line". Or it is using simple printf for 
the dumper functions. You plan to work on these kind of issues to make 
it more like a "stable" generic library?




Signed-off-by: Devin Heitmueller 
---
configure |   3 ++
libavcodec/v210enc.c  |   8 +++
libavdevice/decklink_common.h |   1 +
libavdevice/decklink_enc.cpp  | 113 +++---
4 files changed, 119 insertions(+), 6 deletions(-)

diff --git a/configure b/configure
index 391c141e7a..18647896b1 100755
--- a/configure
+++ b/configure
@@ -238,6 +238,7 @@ External library support:
  --enable-libgsm  enable GSM de/encoding via libgsm [no]
  --enable-libiec61883 enable iec61883 via libiec61883 [no]
  --enable-libilbc enable iLBC de/encoding via libilbc [no]
+  --enable-libklvanc   enable Kernel Labs VANC processing [no]
  --enable-libkvazaar  enable HEVC encoding via libkvazaar [no]
  --enable-libmodplug  enable ModPlug via libmodplug [no]
  --enable-libmp3lame  enable MP3 encoding via libmp3lame [no]
@@ -1603,6 +1604,7 @@ EXTERNAL_LIBRARY_LIST="
libgsm
libiec61883
libilbc
+libklvanc
libkvazaar
libmodplug
libmp3lame
@@ -6027,6 +6029,7 @@ enabled libx264   && { use_pkg_config libx264 x264 
"stdint.h x264.h" x26
enabled libx265   && require_pkg_config libx265 x265 x265.h x265_api_get 
&&
 require_cpp_condition x265.h "X265_BUILD >= 68"
enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode -lxavs
+enabled libklvanc && require libklvanc libklvanc/vanc.h 
vanc_context_create -lklvanc
enabled libxvid   && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg   && require_pkg_config libzimg "zimg >= 2.3.0" zimg.h 
zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a6afbbfc41..44cc3c5c81 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -123,6 +123,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
int aligned_width = ((avctx->width + 47) / 48) * 48;
int stride = aligned_width * 8 / 3;
int line_padding = stride - ((avctx->width * 8 + 11) / 12) * 4;
+AVFrameSideData *side_data = NULL;


initializer seems unnecesarry.


int h, w, ret;
uint8_t *dst;

@@ -233,6 +234,13 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
}
}

+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
+if (side_data && side_data->size) {
+uint8_t* buf = av_packet_new_side_data(pkt, AV_PKT_DATA_A53_CC, 
side_data->size);
+if (buf)
+memcpy(buf, side_data->data, side_data->size);


else
return AVERROR(ENOMEM)?


+}
+
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = 1;
return 0;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..285a244000 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -78,6 +78,7 @@ struct decklink_ctx {
AVStream *audio_st;
AVStream *video_st;
AVStream *teletext_st;
+uint16_t cdp_sequence_num;

/* Options */
int list_devices;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 81df563b3b..3049e936a9 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -38,16 +38,20 @@ extern "C" {

#include "decklink_common.h"
#include "decklink_enc.h"
-
+#if CONFIG_LIBKLVANC
+#include "libklvanc/vanc.h"
+#include "libklvanc/vanc-lines.h"
+#include "libklvanc/pixels.h"
+#endif

/* DeckLink callback class declaration */
class decklink_frame : public IDeckLinkVideoFrame
{
public:
decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, AVCodecID 
codec_id, int height, int width) :
-_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id), 
_height(height), _width(width),  _refs(1) { }
+_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id), 
_ancillary(NULL), _height(height), _width(width),  _refs(1) { }
decklink_frame(struct decklink_ctx *ctx, AVPacket *avpacket, AVCodecID 
codec_id, int height, int width) :
-   

Re: [FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value

[Michael Niedermayer]

On Wed, Oct 25, 2017 at 07:55:52PM +0200, Michael Niedermayer wrote:
> On Tue, Oct 24, 2017 at 11:47:21AM +0200, Tobias Rapp wrote:
> > According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
> > should contain the absolute position to the maximum audio sample value,
> > but the current implementation writes the relative peak frame index
> > instead.
> > 
> > Fix the issue by writing the "unknown" value (-1) for now until the
> > feature is implemented correctly.
> > 
> > Previous version reviewed-by: Peter Bubestinger 
> > Signed-off-by: Tobias Rapp 
> > ---
> > v2:
> >  - added version micro bump
> >  - more code clean-up
> > 
> >  libavformat/version.h|  2 +-
> >  libavformat/wavenc.c | 11 +--
> >  tests/ref/lavf/wav_peak  |  2 +-
> >  tests/ref/lavf/wav_peak_only |  2 +-
> >  4 files changed, 4 insertions(+), 13 deletions(-)
> 
> will apply, thanks

rather LGTM, feel free to apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- 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 2/2] swscale: use dithering in DITHER_COPY only if not set -sws_dither none

[Michael Niedermayer]

On Tue, Oct 24, 2017 at 10:02:17AM +0200, Mateusz wrote:
> This patch uses dithering in DITHER_COPY macro only if
> it was not used option '-sws_dither none'.
> With option '-sws_dither none' it uses downshift.
> 
> For human eye dithering is OK, for video codecs not necessarily.
> If user don't want to use dithering, we should respect that.
> 
> Signed-off-by: Mateusz Brzostek 
> ---
>  libswscale/swscale_unscaled.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)

will apply

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc bi weighted hv mc msa functions

[Michael Niedermayer]

On Tue, Oct 24, 2017 at 11:21:39AM +, Manojkumar Bhosale wrote:
> LGTM

will apply

thanks

[...]
-- 
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] avcodec/mips: Improve avc chroma copy and avg vert mc msa functions

[Michael Niedermayer]

On Tue, Oct 24, 2017 at 11:21:32AM +, Manojkumar Bhosale wrote:
> LGTM

will apply

thanks

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

No great genius has ever existed without some touch of madness. -- 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] avcodec/mips: Improve avc put mc 11, 31, 13 and 33 msa functions

[Michael Niedermayer]

On Tue, Oct 24, 2017 at 11:21:21AM +, Manojkumar Bhosale wrote:
> LGTM

will apply

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value

[Michael Niedermayer]

On Tue, Oct 24, 2017 at 11:47:21AM +0200, Tobias Rapp wrote:
> According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
> should contain the absolute position to the maximum audio sample value,
> but the current implementation writes the relative peak frame index
> instead.
> 
> Fix the issue by writing the "unknown" value (-1) for now until the
> feature is implemented correctly.
> 
> Previous version reviewed-by: Peter Bubestinger 
> Signed-off-by: Tobias Rapp 
> ---
> v2:
>  - added version micro bump
>  - more code clean-up
> 
>  libavformat/version.h|  2 +-
>  libavformat/wavenc.c | 11 +--
>  tests/ref/lavf/wav_peak  |  2 +-
>  tests/ref/lavf/wav_peak_only |  2 +-
>  4 files changed, 4 insertions(+), 13 deletions(-)

will apply, thanks

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] Don't use _tzcnt instrinics with clang for windows w/o BMI.

[Michael Niedermayer]

On Thu, Oct 26, 2017 at 03:39:57AM +1100, Matt Oliver wrote:
> On 25 October 2017 at 07:15, Dale Curtis  wrote:
> 
> > Technically _tzcnt* intrinsics are only available when the BMI
> > instruction set is present. However the instruction encoding
> > degrades to "rep bsf" on older processors.
> >
> > Clang for Windows debatably restricts the _tzcnt* instrinics behind
> > the __BMI__ architecture define, so check for its presence or
> > exclude the usage of these intrinics when clang is present.
> >
> > See also:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183404.html
> > https://bugs.llvm.org/show_bug.cgi?id=30506
> > http://lists.llvm.org/pipermail/cfe-dev/2016-October/051034.html
> >
> > Signed-off-by: Dale Curtis  
> 
> LGTM

will apply

thanks

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

[Michael Niedermayer]

On Wed, Oct 25, 2017 at 09:51:39AM -0400, Bjorn Roche wrote:
> On Tue, Oct 24, 2017 at 8:56 PM, Michael Niedermayer  > wrote:
> 
> > On Tue, Oct 24, 2017 at 12:40:22PM -0400, Bjorn Roche wrote:
> > > Support for transparencies in animated gifs requires modifying both
> > > libavcodec/gif.c and libavformat/gif.c because both the graphics
> > > control extension (handled by libavformat/gif.c) and the raw frame data
> > > (handled by libavcodec/gif.c) must be changed. This is because
> > > transparencies in GIF can be used both to create a transparent image,
> > > and to provide optimization.
> > >
> > > How transparencies are interpreted in a given frame is controlled by
> > > the “disposal method”, which must be set appropriately in the graphics
> > > control extension.
> > >
> > >  The “in place” disposal method is used when transparency indicates
> > > optimization, and the “background” disposal method is used when
> > > transparency is intended to be preserved. In order to support both
> > > disposal methods, libavcodec/gif.c must signal to libavformat/gif.c
> > > which disposal method is required for every frame. This is done with a
> > > new side data type: AV_PKT_DATA_GIF_FRAME_DISPOSAL. This requires a
> > > change to avcodec.h
> > >
> > > Unfortunately, the addition of a new side data type causes some of the
> > > FATE tests to fail. This is not addressed here.
> > >
> > > This patch assumes paletteuse has already been patched to support
> > > transparency. (e.g. lavfi/paletteuse: fix to support transparency)
> > >
> > > Feedback I definitely need:
> > > - I’ve done a fair bit of testing, but I’m sure I missed some important
> > > cases.
> > > - I don’t know if/how to update the FATE tests.
> > > ---
> > >  libavcodec/avcodec.h |   6 ++
> > >  libavcodec/gif.c | 196 ++
> > +++--
> > >  libavformat/gif.c|  16 -
> > >  3 files changed, 212 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > index 52cc5b0ca0..82a5328ce1 100644
> > > --- a/libavcodec/avcodec.h
> > > +++ b/libavcodec/avcodec.h
> > > @@ -1599,6 +1599,12 @@ enum AVPacketSideDataType {
> > >   */
> > >  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> > >
> > > +/**
> > > + * The disposal method that should be used with the frame. If
> > missing,
> > > + * the frame will not be disposed. This contains exactly one byte.
> > > + */
> > > +AV_PKT_DATA_GIF_FRAME_DISPOSAL,
> > > +
> > >  /**
> > >   * ATSC A53 Part 4 Closed Captions. This metadata should be
> > associated with
> > >   * a video stream. A53 CC bitstream is stored as uint8_t in
> > AVPacketSideData.data.
> >
> > you cannot add values in the middle of a public enum, that would
> > change the ABI
> >
> 
> Ah, thanks -- I thought that was internal only. Is it safe to add to the
> end?

additions should be immedeatly before AV_PKT_DATA_NB
if this is insufficiently documented (seems so) then a patch improving
the documentation is welcome too

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Derek Buitenhuis]

On 10/25/2017 2:42 AM, Thierry Foucu wrote:
> Changed the return value when no VOD were encoded in Mpeg4 bistream.
> And if we do have already a decoded frames and we are not in xvid_packed
> mode, output the existing decoded frame instead of nothing.
> ---
>  libavcodec/h263dec.c   | 9 -
>  libavcodec/mpeg4videodec.c | 2 +-
>  libavcodec/mpegutils.h | 1 +
>  3 files changed, 10 insertions(+), 2 deletions(-)

Would this considerably slow down pathological files with a lot of
NVOPs purposely inserted? For example, it use to be A Thing to use
NVOPs to hack in "variable framerate" Xvid-in-avi encodes, by for
example, setting the fps to 120 for a file with 24 and 30 fps sections,
and padding the rest with NVOPs.

Do we care about such files? (Probably not...)

I can provide some samples, probably, if needed.

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

Re: [FFmpeg-devel] Don't use _tzcnt instrinics with clang for windows w/o BMI.

[Matt Oliver]

On 25 October 2017 at 07:15, Dale Curtis  wrote:

> Technically _tzcnt* intrinsics are only available when the BMI
> instruction set is present. However the instruction encoding
> degrades to "rep bsf" on older processors.
>
> Clang for Windows debatably restricts the _tzcnt* instrinics behind
> the __BMI__ architecture define, so check for its presence or
> exclude the usage of these intrinics when clang is present.
>
> See also:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183404.html
> https://bugs.llvm.org/show_bug.cgi?id=30506
> http://lists.llvm.org/pipermail/cfe-dev/2016-October/051034.html
>
> Signed-off-by: Dale Curtis 

[FFmpeg-devel] Invalid behaviour of av_parser_parse2 with some content

[Jean-Yves Avenard]

Hi.

According to the documentation of av_parser_parse2:
https://www.ffmpeg.org/doxygen/trunk/group__lavc__parsing.html#ga691ca0258e91f99297e7726f56d8c247


"poutbuf_size  set to size of parsed buffer or zero if not yet finished. "

So we can expect that both poutbuf_size and poutbuf will be set upon
av_parser_parse2 returning.

However, looking at the code of some parser, such as the vp8 decoder:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp8_parser.c;h=609f5077d1a1b2add1dd3e13f0508615428dafa0;hb=HEAD#l30

we can see that the vp8 parser will do return buf_size immediately
under some circumstances (such as the size being to small, the sync
code being invalid and so forth... but when doing so doesn't set the
two out parameters.

I believe this is a bug

Either the documentation needs fixing, or the two out parameters needs
to be set to poutbuf and poutbuf_size respectively as all data is to
be consumed.

An alternative would be to set them both to 0 if content is invalid
(or too small) and as such we don't want the parser to output
anything.

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

Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4

[Jean-Yves Avenard]

hi

On 26 August 2017 at 12:08, Carl Eugen Hoyos  wrote:
> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
>
>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
>
> Why does this only apply to flac?
>

Sorry, I had missed your reply.

The specification on how sampling rate is to be stored should it be
greater than INT16_MAX is a FLAC in ISOBMFF requirement:

https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165

It definitely could be applied to other codecs, but I haven't seen
such requirements clearly defined.

ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
in which case the sampling_rate is a 32 bits integer (ISO 14496-12
12.2.3.2)

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

Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4

[Ronald S. Bultje]

Hi,

On Fri, Aug 25, 2017 at 7:29 PM, Michael Niedermayer  wrote:

> On Fri, Aug 25, 2017 at 01:25:23PM +0200, Jean-Yves Avenard wrote:
> > From 9baa7166fa96ed6beac9146c7e3b4dcf425a67d0 Mon Sep 17 00:00:00 2001
> > From: Jean-Yves Avenard 
> > Date: Fri, 25 Aug 2017 13:11:28 +0200
> > Subject: [PATCH] Properly store sampling rate for FLAC in mp4
> >
> > Fixes ticket #6609
> >
> > Signed-off-by: Jean-Yves Avenard 
> > ---
> >  libavformat/movenc.c | 28 +---
> >  1 file changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index 10b959ad02..aa4a9c962a 100644
> > --- a/libavformat/movenc.c
> > +++ b/libavformat/movenc.c
> > @@ -1028,9 +1028,31 @@ static int mov_write_audio_tag(AVFormatContext
> > *s, AVIOContext *pb, MOVMuxContex
> >  avio_wb16(pb, 0); /* packet size (= 0) */
>
> This patch is corrupted by line wraps / newlines
>

An uncorrupted version was attached to #6609:

https://trac.ffmpeg.org/attachment/ticket/6609/0001-Properly-store-sampling-rate-for-FLAC-in-mp4.patch

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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

[Bjorn Roche]

On Tue, Oct 24, 2017 at 8:56 PM, Michael Niedermayer  wrote:

> On Tue, Oct 24, 2017 at 12:40:22PM -0400, Bjorn Roche wrote:
> > Support for transparencies in animated gifs requires modifying both
> > libavcodec/gif.c and libavformat/gif.c because both the graphics
> > control extension (handled by libavformat/gif.c) and the raw frame data
> > (handled by libavcodec/gif.c) must be changed. This is because
> > transparencies in GIF can be used both to create a transparent image,
> > and to provide optimization.
> >
> > How transparencies are interpreted in a given frame is controlled by
> > the “disposal method”, which must be set appropriately in the graphics
> > control extension.
> >
> >  The “in place” disposal method is used when transparency indicates
> > optimization, and the “background” disposal method is used when
> > transparency is intended to be preserved. In order to support both
> > disposal methods, libavcodec/gif.c must signal to libavformat/gif.c
> > which disposal method is required for every frame. This is done with a
> > new side data type: AV_PKT_DATA_GIF_FRAME_DISPOSAL. This requires a
> > change to avcodec.h
> >
> > Unfortunately, the addition of a new side data type causes some of the
> > FATE tests to fail. This is not addressed here.
> >
> > This patch assumes paletteuse has already been patched to support
> > transparency. (e.g. lavfi/paletteuse: fix to support transparency)
> >
> > Feedback I definitely need:
> > - I’ve done a fair bit of testing, but I’m sure I missed some important
> > cases.
> > - I don’t know if/how to update the FATE tests.
> > ---
> >  libavcodec/avcodec.h |   6 ++
> >  libavcodec/gif.c | 196 ++
> +++--
> >  libavformat/gif.c|  16 -
> >  3 files changed, 212 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 52cc5b0ca0..82a5328ce1 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1599,6 +1599,12 @@ enum AVPacketSideDataType {
> >   */
> >  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> >
> > +/**
> > + * The disposal method that should be used with the frame. If
> missing,
> > + * the frame will not be disposed. This contains exactly one byte.
> > + */
> > +AV_PKT_DATA_GIF_FRAME_DISPOSAL,
> > +
> >  /**
> >   * ATSC A53 Part 4 Closed Captions. This metadata should be
> associated with
> >   * a video stream. A53 CC bitstream is stored as uint8_t in
> AVPacketSideData.data.
>
> you cannot add values in the middle of a public enum, that would
> change the ABI
>

Ah, thanks -- I thought that was internal only. Is it safe to add to the
end?

bjorn


-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat: deprecate getters and setters for AVFormatContext and AVStream fields

[Paul B Mahol]

On 10/23/17, James Almer  wrote:
> The fields can be accessed directly, so these are not needed anymore.
>
> Signed-off-by: James Almer 
> ---
>  libavformat/avformat.h | 30 +-
>  libavformat/utils.c|  4 
>  libavformat/version.h  |  3 +++
>  3 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 7594277f06..b2db234041 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1213,11 +1213,22 @@ typedef struct AVStream {
>  AVStreamInternal *internal;
>  } AVStream;
>
> +#if FF_API_FORMAT_GET_SET
> +/**
> + * Accessors for some AVStream fields. These used to be provided for ABI
> + * compatibility, and do not need to be used anymore.
> + */
> +attribute_deprecated
>  AVRational av_stream_get_r_frame_rate(const AVStream *s);
> +attribute_deprecated
>  void   av_stream_set_r_frame_rate(AVStream *s, AVRational r);
> -struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> +attribute_deprecated
>  char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
> +attribute_deprecated
>  void  av_stream_set_recommended_encoder_configuration(AVStream *s, char
> *configuration);
> +#endif
> +
> +struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
>
>  /**
>   * Returns the pts of the last muxed packet + its duration
> @@ -1889,29 +1900,46 @@ typedef struct AVFormatContext {
>  int max_streams;
>  } AVFormatContext;
>
> +#if FF_API_FORMAT_GET_SET
>  /**
>   * Accessors for some AVFormatContext fields. These used to be provided for
> ABI
>   * compatibility, and do not need to be used anymore.
>   */
> +attribute_deprecated
>  int av_format_get_probe_score(const AVFormatContext *s);
> +attribute_deprecated
>  AVCodec * av_format_get_video_codec(const AVFormatContext *s);
> +attribute_deprecated
>  void  av_format_set_video_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
>  AVCodec * av_format_get_audio_codec(const AVFormatContext *s);
> +attribute_deprecated
>  void  av_format_set_audio_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
>  AVCodec * av_format_get_subtitle_codec(const AVFormatContext *s);
> +attribute_deprecated
>  void  av_format_set_subtitle_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
>  AVCodec * av_format_get_data_codec(const AVFormatContext *s);
> +attribute_deprecated
>  void  av_format_set_data_codec(AVFormatContext *s, AVCodec *c);
> +attribute_deprecated
>  int   av_format_get_metadata_header_padding(const AVFormatContext *s);
> +attribute_deprecated
>  void  av_format_set_metadata_header_padding(AVFormatContext *s, int c);
> +attribute_deprecated
>  void *av_format_get_opaque(const AVFormatContext *s);
> +attribute_deprecated
>  void  av_format_set_opaque(AVFormatContext *s, void *opaque);
> +attribute_deprecated
>  av_format_control_message av_format_get_control_message_cb(const
> AVFormatContext *s);
> +attribute_deprecated
>  void  av_format_set_control_message_cb(AVFormatContext *s,
> av_format_control_message callback);
>  #if FF_API_OLD_OPEN_CALLBACKS
>  attribute_deprecated AVOpenCallback av_format_get_open_cb(const
> AVFormatContext *s);
>  attribute_deprecated void av_format_set_open_cb(AVFormatContext *s,
> AVOpenCallback callback);
>  #endif
> +#endif
>
>  /**
>   * This function will cause global side data to be injected in the next
> packet
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 6dbc48d54d..8fd7b82c67 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -104,6 +104,7 @@ static int64_t wrap_timestamp(const AVStream *st,
> int64_t timestamp)
>  return timestamp;
>  }
>
> +#if FF_API_FORMAT_GET_SET
>  MAKE_ACCESSORS(AVStream, stream, AVRational, r_frame_rate)
>  MAKE_ACCESSORS(AVStream, stream, char *, recommended_encoder_configuration)
>  MAKE_ACCESSORS(AVFormatContext, format, AVCodec *, video_codec)
> @@ -118,6 +119,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  MAKE_ACCESSORS(AVFormatContext, format, AVOpenCallback, open_cb)
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
> +#endif
>
>  int64_t av_stream_get_end_pts(const AVStream *st)
>  {
> @@ -215,10 +217,12 @@ static const AVCodec
> *find_probe_decoder(AVFormatContext *s, const AVStream *st,
>  return codec;
>  }
>
> +#if FF_API_FORMAT_GET_SET
>  int av_format_get_probe_score(const AVFormatContext *s)
>  {
>  return s->probe_score;
>  }
> +#endif
>
>  /* an arbitrarily chosen "sane" max packet size -- 50M */
>  #define SANE_CHUNK_SIZE (5000)
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 0feb788c36..8765b59435 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -79,6 +79,9 @@
>  #ifndef FF_API_OLD_ROTATE_API
>  #define FF_API_OLD_ROTATE_API   (LIBAVFORMAT_VERSION_MAJOR < 59)
>  #endif
> +#ifndef FF_API_FORMAT_GET_SET
> +#define 

[FFmpeg-devel] [PATCH] configure: v4l2_m2m depends on pthreads

[Mark Thompson]

Fixes build with --disable-pthreads.
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index c86e578..76523c8 100755
--- a/configure
+++ b/configure
@@ -2780,7 +2780,7 @@ omx_rpi_select="omx"
 qsvdec_select="qsv"
 qsvenc_select="qsv"
 vaapi_encode_deps="vaapi"
-v4l2_m2m_deps_any="linux_videodev2_h"
+v4l2_m2m_deps="linux_videodev2_h pthreads"
 
 hwupload_cuda_filter_deps="cuda"
 scale_npp_filter_deps="cuda libnpp"
-- 
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Michael Niedermayer]

On Tue, Oct 24, 2017 at 06:42:54PM -0700, Thierry Foucu wrote:
> Changed the return value when no VOD were encoded in Mpeg4 bistream.
> And if we do have already a decoded frames and we are not in xvid_packed
> mode, output the existing decoded frame instead of nothing.
> ---
>  libavcodec/h263dec.c   | 9 -
>  libavcodec/mpeg4videodec.c | 2 +-
>  libavcodec/mpegutils.h | 1 +
>  3 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index c7cf4bc0c2..394a366f9c 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -506,8 +506,15 @@ retry:
>  s->height= avctx->coded_height;
>  }
>  }
> -if (ret == FRAME_SKIPPED)
> +if (ret == FRAME_SKIPPED || ret == FRAME_NOT_CODED) {
> +if (s->next_picture_ptr && ret == FRAME_NOT_CODED && 
> !s->divx_packed) {
> +if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0) {
> +return ret;
> +}
> +*got_frame = 1;
> +}
>  return get_consumed_bytes(s, buf_size);
> +}
>  
>  /* skip if the header was thrashed */
>  if (ret < 0) {
> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> index 82c4f8fc8c..3a9ed12971 100644
> --- a/libavcodec/mpeg4videodec.c
> +++ b/libavcodec/mpeg4videodec.c
> @@ -2394,7 +2394,7 @@ static int decode_vop_header(Mpeg4DecContext *ctx, 
> GetBitContext *gb)
>  if (get_bits1(gb) != 1) {
>  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
>  av_log(s->avctx, AV_LOG_ERROR, "vop not coded\n");
> -return FRAME_SKIPPED;
> +return FRAME_NOT_CODED;
>  }
>  if (ctx->new_pred)
>  decode_new_pred(ctx, gb);

the return codes are documented currently:
 * @return <0 if no VOP found (or a damaged one)
 * FRAME_SKIPPED if a not coded VOP is found
 * 0 if a VOP is found

you added a case but did not update all use cases

which seems to
lead to intermittent crashes (i cant say for sure as i failed to
reproduce one in a debugger or with any debuging code added)

Also returning frames for skiped frames when te match the previous
would slow the code down as more frames would need to be processed.
more so i think this is not the only codec that can skip frames
so any downstream problems will likely not be worked around by forcing
constant fps with frame duplication here


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

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


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] lavf/aviobuf: return EINVAL when reading from a write-only context.

[Nicolas George]

Le quartidi 4 brumaire, an CCXXVI, Hendrik Leppkes a écrit :
> I think you meant to change the other ret assignment?

You are entirely right. Locally swapped. Thanks for noticing.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/aviobuf: return EINVAL when reading from a write-only context.

[Hendrik Leppkes]

On Wed, Oct 25, 2017 at 10:22 AM, Nicolas George  wrote:
> Signed-off-by: Nicolas George 
> ---
>  libavformat/aviobuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> Not related to the issue, but seems more correct.
>
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index bb5bcf7a14..dfe8437b18 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -534,7 +534,7 @@ static int read_packet_wrapper(AVIOContext *s, uint8_t 
> *buf, int size)
>  #if FF_API_OLD_AVIO_EOF_0
>  if (!ret && !s->max_packet_size) {
>  av_log(s, AV_LOG_WARNING, "Invalid return value 0 for stream 
> protocol\n");
> -ret = AVERROR_EOF;
> +ret = AVERROR(EINVAL);
>  }
>  #else
>  av_assert2(ret || s->max_packet_size);
> --

I think you meant to change the other ret assignment?

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

Re: [FFmpeg-devel] NVENC - HEVC + WP

[Timo Rothenpieler]

Am 25.10.2017 um 06:06 schrieb Yogender Gupta:

One of the users had recently complained about encoding problems with HEVC 
encoding with WP (Weighted Prediction). This is a driver issue that has been 
identified, and shows up when using HEVC + WP + (PictureTimingSEI messages and 
or buffering period SEI messages).

Recently the PictureTiming SEI message was turned on by default in the NVENC 
code in ffmpeg and the issue shows up when doing HEVC encodes with WP turned on.

We have a driver fix that will come up in a later release, and users would be 
suggested to not enable weighted prediction with HEVC till a fixed driver 
version is available.

Regards,
Yogender


Thanks for the heads up!
WP is turned off by default, so I don't think we need to patch ffmpeg here.
If some user shows up with this issue, I'll let them know what's going on.



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

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

[Nicolas George]

Le tridi 3 brumaire, an CCXXVI, Nicolas George a écrit :
> As I said, I will try to find time to implement a correct workaround
> tomorrow.

Patch series posted.

https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218482.html
https://patchwork.ffmpeg.org/patch/5686/

Please confirm if it fixes the issue with your application.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 3/3] lavf/aviobuf: return EINVAL when reading from a write-only context.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavformat/aviobuf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Not related to the issue, but seems more correct.


diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index bb5bcf7a14..dfe8437b18 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -534,7 +534,7 @@ static int read_packet_wrapper(AVIOContext *s, uint8_t 
*buf, int size)
 #if FF_API_OLD_AVIO_EOF_0
 if (!ret && !s->max_packet_size) {
 av_log(s, AV_LOG_WARNING, "Invalid return value 0 for stream 
protocol\n");
-ret = AVERROR_EOF;
+ret = AVERROR(EINVAL);
 }
 #else
 av_assert2(ret || s->max_packet_size);
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 2/3] lavf/avio: temporarily accept 0 as EOF.

[Nicolas George]

Print a warning to let applicatios fix their use.
After a deprecation period, check with a low-level assert.
Also make the constraint explicit in the doxygen comment.

Signed-off-by: Nicolas George 
---
 libavformat/avio.h|  2 ++
 libavformat/aviobuf.c | 30 +-
 libavformat/version.h |  3 +++
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 19ecd96eb7..76ff7cd81e 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -452,6 +452,8 @@ void avio_free_directory_entry(AVIODirEntry **entry);
  * @param write_flag Set to 1 if the buffer should be writable, 0 otherwise.
  * @param opaque An opaque pointer to user-specific data.
  * @param read_packet  A function for refilling the buffer, may be NULL.
+ * For stream protocols, must never return 0 but rather
+ * a proper AVERROR code.
  * @param write_packet A function for writing the buffer contents, may be NULL.
  *The function may not change the input buffers content.
  * @param seek A function for seeking to specified byte position, may be NULL.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 3e9d774a13..bb5bcf7a14 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -524,6 +524,24 @@ void avio_write_marker(AVIOContext *s, int64_t time, enum 
AVIODataMarkerType typ
 s->last_time = time;
 }
 
+static int read_packet_wrapper(AVIOContext *s, uint8_t *buf, int size)
+{
+int ret;
+
+if (!s->read_packet)
+return AVERROR_EOF;
+ret = s->read_packet(s->opaque, buf, size);
+#if FF_API_OLD_AVIO_EOF_0
+if (!ret && !s->max_packet_size) {
+av_log(s, AV_LOG_WARNING, "Invalid return value 0 for stream 
protocol\n");
+ret = AVERROR_EOF;
+}
+#else
+av_assert2(ret || s->max_packet_size);
+#endif
+return ret;
+}
+
 /* Input stream */
 
 static void fill_buffer(AVIOContext *s)
@@ -562,10 +580,7 @@ static void fill_buffer(AVIOContext *s)
 len = s->orig_buffer_size;
 }
 
-if (s->read_packet)
-len = s->read_packet(s->opaque, dst, len);
-else
-len = AVERROR_EOF;
+len = read_packet_wrapper(s, dst, len);
 if (len == AVERROR_EOF) {
 /* do not modify buffer if EOF reached so that a seek back can
be done without rereading data */
@@ -638,10 +653,7 @@ int avio_read(AVIOContext *s, unsigned char *buf, int size)
 if (len == 0 || s->write_flag) {
 if((s->direct || size > s->buffer_size) && !s->update_checksum) {
 // bypass the buffer and read data directly into buf
-if(s->read_packet)
-len = s->read_packet(s->opaque, buf, size);
-else
-len = AVERROR_EOF;
+len = read_packet_wrapper(s, buf, size);
 if (len == AVERROR_EOF) {
 /* do not modify buffer if EOF reached so that a seek back 
can
 be done without rereading data */
@@ -708,7 +720,7 @@ int avio_read_partial(AVIOContext *s, unsigned char *buf, 
int size)
 return -1;
 
 if (s->read_packet && s->write_flag) {
-len = s->read_packet(s->opaque, buf, size);
+len = read_packet_wrapper(s, buf, size);
 if (len > 0)
 s->pos += len;
 return len;
diff --git a/libavformat/version.h b/libavformat/version.h
index 0feb788c36..358ab91ab2 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -79,6 +79,9 @@
 #ifndef FF_API_OLD_ROTATE_API
 #define FF_API_OLD_ROTATE_API   (LIBAVFORMAT_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_OLD_AVIO_EOF_0
+#define FF_API_OLD_AVIO_EOF_0   (LIBAVFORMAT_VERSION_MAJOR < 59)
+#endif
 
 
 #ifndef FF_API_R_FRAME_RATE
-- 
2.14.2

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

[FFmpeg-devel] [PATCH 1/3] examples/avio_reading: return AVERROR_EOF at EOF.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 doc/examples/avio_reading.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/examples/avio_reading.c b/doc/examples/avio_reading.c
index 02474e907a..7860fd5e2f 100644
--- a/doc/examples/avio_reading.c
+++ b/doc/examples/avio_reading.c
@@ -44,6 +44,8 @@ static int read_packet(void *opaque, uint8_t *buf, int 
buf_size)
 struct buffer_data *bd = (struct buffer_data *)opaque;
 buf_size = FFMIN(buf_size, bd->size);
 
+if (!buf_size)
+return AVERROR_EOF;
 printf("ptr:%p size:%zu\n", bd->ptr, bd->size);
 
 /* copy internal buffer data to buf */
-- 
2.14.2

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] cbs_mpeg2: Fix type for marker_bit reading

[Hendrik Leppkes]

On Wed, Oct 25, 2017 at 12:42 AM, Mark Thompson  wrote:
> On 24/10/17 23:34, Carl Eugen Hoyos wrote:
>> 2017-10-25 0:29 GMT+02:00 Mark Thompson :
>>> On 24/10/17 23:14, Carl Eugen Hoyos wrote:
 2017-10-25 0:09 GMT+02:00 Mark Thompson :
> ffmpeg | branch: master | Mark Thompson  | Tue Oct 24 
> 22:56:48 2017 +0100| [5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22] | 
> committer: Mark Thompson
>
> cbs_mpeg2: Fix type for marker_bit reading
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5b2c71bb94d7cab23ee81b5c29388f5fadbcaf22
> ---
>
>  libavcodec/cbs_mpeg2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index d137762227..0cac29733e 100644
> --- a/libavcodec/cbs_mpeg2.c
> +++ b/libavcodec/cbs_mpeg2.c
> @@ -54,7 +54,7 @@
>  xui(width, name, current->name)
>
>  #define marker_bit() do { \
> -av_unused int one = 1; \
> +av_unused uint32_t one; \
>  CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", , 1, 
> 1)); \

 The commit message doesn't match the change / is this defined behaviour?
>>>
>>> It's only written and never read, so the initialisation isn't doing 
>>> anything.
>>
>> I asked because I believe it was reported once that a static analyzer 
>> protested
>> on passing uninitialized stuff - that was never going to be used - as
>> a parameter.
>> (But that may have been an uninitialized variable that was never used,
>> not a pointer.)
>
> I don't think pointers in general can be complained about in C without 
> knowledge of the target function - consider that there are destination 
> pointers all over the standard library which need not be initialised, like 
> memcpy() or scanf().
>

As if static analyzers always care what you can and cannot do. :p

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

Re: [FFmpeg-devel] libavcodec/bswapdsp : add AVX2 for bswap_buf

[Paul B Mahol]

On 10/22/17, Martin Vignali  wrote:
> Hello,
>
> In attach patch in order to add an AVX2 version for bswap_buf
> (swap uint32 in a buffer)
>
> Checkasm result (Kaby Lake 10.12)
> bswap_buf_c: 122.8
> bswap_buf_sse2: 67.8
> bswap_buf_ssse3: 34.3
> bswap_buf_avx2: 21.0
>
>
> Pass checkasm and fate test for me
>
>
> Martin
> Jokyo Images
>

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

Re: [FFmpeg-devel] [PATCH] avcodec/tak: remove GetBitContext usage from avpriv_tak_parse_streaminfo()

[Paul B Mahol]

On 10/23/17, James Almer  wrote:
> This prevents potential ABI issues with GetBitContext.
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/tak.c | 17 +++--
>  libavcodec/tak.h |  8 ++--
>  libavformat/takdec.c |  7 +--
>  3 files changed, 26 insertions(+), 6 deletions(-)
>

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

Re: [FFmpeg-devel] libavcodec/lossless_videodsp : add add_bytes AVX2

[Paul B Mahol]

On 10/21/17, Martin Vignali  wrote:
> Hello,
>
> In attach patch to add AVX2 version for add_bytes
>
> 0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
> add AVX2 version
>
> pass fate-test for me (os 10.12, x86_64)
>
> checkasm result : (Kaby Lake) (run 10 times, and i took the fastest
> version)
> checkasm: all 2 tests passed
> add_bytes_c: 108.7
> add_bytes_sse2: 26.5
> add_bytes_avx2: 15.5
>
>
> 0002-libavcodec-lossless_video_dsp-cosmetic-add-better-se:
> only cosmetic
> like the ref c function declaration in asm file is not consistent between
> each asm file
> i think a better separator for each function make the file easier to read
>
> also add the c declaration for add bytes in comment
>
>
> Martin
>

Are you sure 32bit alignment is actually enforced?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/exif: remove GetByteContext usage from avpriv_exif_decode_ifd()

[Paul B Mahol]

On 10/24/17, James Almer  wrote:
> This prevents potential ABI issues with GetByteContext.
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/exif.c | 16 +---
>  libavcodec/exif.h |  6 --
>  libavcodec/mjpegdec.c |  2 +-
>  libavcodec/webp.c |  2 +-
>  libavformat/avidec.c  |  4 ++--
>  5 files changed, 21 insertions(+), 9 deletions(-)
>


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