Re: [FFmpeg-devel] [PATCH 1/2] libavformat/avio: Add avio_get_dyn_buf function

[Soft Works]

> Michael wrote
> Is the author name intended to be
> Author: softworkz 

Yes please, if you don't mind, same as my previous commit: 
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=70c1647a3501fa6182c04c9ce66f477def64a611

PS: On behalf of the Emby project, I'd like to thank you for your kind 
assistance!
(https://emby.media/)

Thank you very much,

softworkz
(https://github.com/softworkz)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] libavformat/avio: Add avio_get_dyn_buf function

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 09:14:59PM +, Soft Works wrote:
> [PATCH] libavformat/avio: Add avio_get_dyn_buf function
> 
> Revision #2: Bumb version and add APIchanges entry
> 
> This commit adds the avio_get_dyn_buf function which allows accessing
> the
> content of a DynBuffer without destroying it.
> 
> This is required in matroskaenc for preliminary writing (correct) mkv
> headers.
> 
> Context for this change is fixing regression bug #5977.
> ---
>  doc/APIchanges|  3 +++
>  libavformat/avio.h| 12 
>  libavformat/aviobuf.c | 17 +
>  libavformat/version.h |  2 +-
>  4 files changed, 33 insertions(+), 1 deletion(-)

Is the author name intended to be
Author: softworkz 
?

[...]

-- 
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


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/3] mpeg12dec: validate color space

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 09:43:24PM +0100, Andreas Cadhalpun wrote:
> On 23.12.2016 00:57, Andreas Cadhalpun wrote:
> > Signed-off-by: Andreas Cadhalpun 
> > ---
> >  libavcodec/mpeg12dec.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > index 63979079c8..d3dc67ad6a 100644
> > --- a/libavcodec/mpeg12dec.c
> > +++ b/libavcodec/mpeg12dec.c
> > @@ -1470,6 +1470,10 @@ static void 
> > mpeg_decode_sequence_display_extension(Mpeg1Context *s1)
> >  s->avctx->color_primaries = get_bits(>gb, 8);
> >  s->avctx->color_trc   = get_bits(>gb, 8);
> >  s->avctx->colorspace  = get_bits(>gb, 8);
> > +if (!av_color_space_name(s->avctx->colorspace)) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid color space %d, 
> > setting to unspecified\n", s->avctx->colorspace);
> > +s->avctx->colorspace = AVCOL_SPC_UNSPECIFIED;
> > +}
> >  }
> >  w = get_bits(>gb, 14);
> >  skip_bits(>gb, 1); // marker
> > 
> 
> Ping for the series.

i have no real objection to it.
iam used to see these being exported unchanged though so it feels a
bit odd


[...]
-- 
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 9/9] xvag: prevent overflow during block alignment calculation

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 08:49:49PM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/xvag.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/xvag.c b/libavformat/xvag.c
> index 5ef4fb0900..1f28df7b89 100644
> --- a/libavformat/xvag.c
> +++ b/libavformat/xvag.c
> @@ -74,6 +74,7 @@ static int xvag_read_header(AVFormatContext *s)
>  switch (codec) {
>  case 0x1c:
>  st->codecpar->codec_id= AV_CODEC_ID_ADPCM_PSX;
> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels > INT_MAX / 16)

this check could also be added to
"if (st->codecpar->channels <= 0)" above

[...]
-- 
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 4/9] genh: prevent overflow during block alignment calculation

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 08:48:02PM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/genh.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/genh.c b/libavformat/genh.c
> index b683e026d1..6ce2588ed3 100644
> --- a/libavformat/genh.c
> +++ b/libavformat/genh.c
> @@ -74,6 +74,7 @@ static int genh_read_header(AVFormatContext *s)
>  case  0: st->codecpar->codec_id = AV_CODEC_ID_ADPCM_PSX;break;
>  case  1:
>  case 11: st->codecpar->bits_per_coded_sample = 4;
> + FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels > INT_MAX / 36)
>   st->codecpar->block_align = 36 * st->codecpar->channels;
>   st->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_WAV;break;
>  case  2: st->codecpar->codec_id = AV_CODEC_ID_ADPCM_DTK;break;

i see a channels * 1024 in genh_read_packet()
is the added check sufficient ?

also i think we should ask for a sample for a file that has a
channel count beyond normal bounds


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

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


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/9] electronicarts: prevent overflow during block alignment calculation

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 08:47:39PM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/electronicarts.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> index 30eb723bd5..03422e5b2c 100644
> --- a/libavformat/electronicarts.c
> +++ b/libavformat/electronicarts.c
> @@ -556,6 +556,7 @@ static int ea_read_header(AVFormatContext *s)
>  st->codecpar->codec_tag = 0;   /* no tag */
>  st->codecpar->channels  = ea->num_channels;
>  st->codecpar->sample_rate   = ea->sample_rate;
> +FF_RETURN_ON_OVERFLOW(s, ea->bytes > INT_MAX / 8 / 2)

I think we should ask for a sample when the number of bytes per
sample is larger than 2 or 4 or whatever max we think occurs.

the patch is probably fine

[...]

-- 
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/9] 4xm: prevent overflow during block alignment calculation

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 09:27:29PM +0100, Andreas Cadhalpun wrote:
> On 06.01.2017 20:58, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Fri, Jan 6, 2017 at 2:47 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> > 
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavformat/4xm.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
> >> index 2758b69d29..45949c4e97 100644
> >> --- a/libavformat/4xm.c
> >> +++ b/libavformat/4xm.c
> >> @@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
> >>  st->codecpar->bit_rate  = (int64_t)st->codecpar->channels
> >> *
> >>st->codecpar->sample_rate *
> >>st->codecpar->bits_per_coded_
> >> sample;
> >> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
> >> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
> >>  st->codecpar->block_align   = st->codecpar->channels *
> >>st->codecpar->bits_per_coded_
> >> sample;
> >>
> >> --
> >> 2.11.0
> > 
> > 
> > To an innocent reader (who doesn't know/care about SIGFPE), this might look
> > like channels = 0 is an actual valid decoder condition that is explicitly
> > handled here.
> 
> Actually this function errors out earlier if channels is zero, so I've removed
> this pointless additional check. Updated patch is attached.
> 
> Best regards,
> Andreas
> 
> 

>  4xm.c |1 +
>  1 file changed, 1 insertion(+)
> 4b27cb10f25865014fac1666956f7040d65113f9  
> 0002-4xm-prevent-overflow-during-block-alignment-calculat.patch
> From 861b62eec30feaa56b10eec7ba4029daf48a3c28 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Thu, 15 Dec 2016 02:14:31 +0100
> Subject: [PATCH 2/9] 4xm: prevent overflow during block alignment calculation
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/4xm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
> index 2758b69d29..58729fed0d 100644
> --- a/libavformat/4xm.c
> +++ b/libavformat/4xm.c
> @@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
>  st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
>st->codecpar->sample_rate *
>
> st->codecpar->bits_per_coded_sample;
> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->bits_per_coded_sample > INT_MAX / 
> st->codecpar->channels)
>  st->codecpar->block_align   = st->codecpar->channels *
>
> st->codecpar->bits_per_coded_sample;

i think we should check channels for > 8 or something and ask for a
sample and check bits_per_coded_sample against what maximal sensible
value of bits a sample and ask for a sample if above

the patch should be ok

thx

[...]

-- 
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

Re: [FFmpeg-devel] [PATCH 1/9] avutil: add FF_RETURN_ON_OVERFLOW

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 09:11:10PM -0300, James Almer wrote:
> On 1/6/2017 4:46 PM, Andreas Cadhalpun wrote:
> > Suggested-by: Rodger Combs 
> > Signed-off-by: Andreas Cadhalpun 
> > ---
> > 
> > Changed the name as suggested by wm4 and the return value as suggested
> > by Muhammad Faiz.
> > There are also two new overflow checks at the end of the series.
> 
> This is a good chance to introduce the gcc overflow check builtins.
> See https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html, they
> use hardware instructions when possible, like x86's Jump on Overflow.
> 
> The idea would be to use __builtin_mul_overflow_p(). For example (untested):
> 
> #if AV_GCC_VERSION_AT_LEAST(5,1)
> #define av_builtin_mul_overflow_p(a, b) __builtin_mul_overflow_p(a, b, (int) 
> 0)
> #else
> #define av_builtin_mul_overflow_p(a, b) ((a) > INT_MAX / (b)))
> #endif
> 
> It can also be used all across the codebase, not just for these checks.
> 

> > 
> > ---
> >  libavutil/common.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavutil/common.h b/libavutil/common.h
> > index 8142b31fdb..6d795a353a 100644
> > --- a/libavutil/common.h
> > +++ b/libavutil/common.h
> > @@ -99,6 +99,8 @@
> >  #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
> >  #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
> >  
> > +#define FF_RETURN_ON_OVERFLOW(ctx, x) if (x) {av_log(ctx, AV_LOG_ERROR, 
> > "Overflow check failed: " #x"\n"); return AVERROR(ERANGE);}
> 
> Printing an error unconditionally seems like log bloat. We do all kinds of
> sanity checks on demuxers and simply return INVALIDDATA without printing
> anything if they fail.
> Maybe we should do the same here and let the demuxer choose to print an
> error or not.

error messages help debuging and thus maintaining code.



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

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


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

Re: [FFmpeg-devel] [PATCH] h264_ps: validate chroma sample location

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 11:33:13PM +0100, Andreas Cadhalpun wrote:
> On 06.01.2017 22:47, Kieran Kunhya wrote:
> > On Fri, 6 Jan 2017 at 20:44 Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> > 
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavcodec/h264_ps.c | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> >> index 8218e3a010..089bfc650a 100644
> >> --- a/libavcodec/h264_ps.c
> >> +++ b/libavcodec/h264_ps.c
> >> @@ -181,6 +181,10 @@ static inline int decode_vui_parameters(GetBitContext
> >> *gb, AVCodecContext *avctx
> >>  if (get_bits1(gb)) {
> >>  /* chroma_sample_location_type_top_field */
> >>  avctx->chroma_sample_location = get_ue_golomb(gb) + 1;
> >> +if (!av_chroma_location_name(avctx->chroma_sample_location)) {
> >> +av_log(avctx, AV_LOG_WARNING, "Invalid chroma sample location
> >> %d, setting to unspecified\n", avctx->chroma_sample_location);
> >> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> >> +}
> >>
> >>
> > Is there a way to long only once, this seems like it could spam the user
> > full of these warnings.
> 
> One could add a field like shown_chroma_loc_warning to SPS, but I think
> that would be a bit too much overhead for this.
> Alternatively, one could drop the log message entirely. (Wrong color
> primaries etc. aren't logged either...)

I think making it a "normally not displayed" log level would be a
better choice than removing it entirely

also a generic solution is possible, like a

av_log_once(context, >my_message_state, ...)
such function would also allow simplifying a bit of code

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

Avoid a single point of failure, be that a person or equipment.


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/9] avutil: add FF_RETURN_ON_OVERFLOW

[James Almer]

On 1/6/2017 4:46 PM, Andreas Cadhalpun wrote:
> Suggested-by: Rodger Combs 
> Signed-off-by: Andreas Cadhalpun 
> ---
> 
> Changed the name as suggested by wm4 and the return value as suggested
> by Muhammad Faiz.
> There are also two new overflow checks at the end of the series.

This is a good chance to introduce the gcc overflow check builtins.
See https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html, they
use hardware instructions when possible, like x86's Jump on Overflow.

The idea would be to use __builtin_mul_overflow_p(). For example (untested):

#if AV_GCC_VERSION_AT_LEAST(5,1)
#define av_builtin_mul_overflow_p(a, b) __builtin_mul_overflow_p(a, b, (int) 0)
#else
#define av_builtin_mul_overflow_p(a, b) ((a) > INT_MAX / (b)))
#endif

It can also be used all across the codebase, not just for these checks.

> 
> ---
>  libavutil/common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavutil/common.h b/libavutil/common.h
> index 8142b31fdb..6d795a353a 100644
> --- a/libavutil/common.h
> +++ b/libavutil/common.h
> @@ -99,6 +99,8 @@
>  #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
>  #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
>  
> +#define FF_RETURN_ON_OVERFLOW(ctx, x) if (x) {av_log(ctx, AV_LOG_ERROR, 
> "Overflow check failed: " #x"\n"); return AVERROR(ERANGE);}

Printing an error unconditionally seems like log bloat. We do all kinds of
sanity checks on demuxers and simply return INVALIDDATA without printing
anything if they fail.
Maybe we should do the same here and let the demuxer choose to print an
error or not.

> +
>  /* misc math functions */
>  
>  #ifdef HAVE_AV_CONFIG_H
> 

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskaenc: Regression fix for invalid MKV headers

[Soft Works]

Revision #4: Don't create CRC32 for preliminary headers

The following three commits created a regression by writing initially
invalid mkv headers:

650e17d88b63b5aca6e0a43483e89e64b0f7d2dd avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf822711720ff0f8d14db71ae47cdf97e652 avformat/matroskaenc: write a
CRC32 element on Info
ee888cfbe777cd2916a3548c750e433ab8f8e6a5 avformat/matroskaenc: postpone
writing the Tracks master

Symptoms:

- You can no longer playback a file that is still processed by ffmpeg,
e.g. VLC fails playback
- You can no longer stream a file to a client while if is still being
processed
- Various diagnosing tools show header errors or incomplete headers
(e.g. ffprobe, mediainfo, mkvalidator)

Note: The symptoms do not apply to completed files or ffmpeg runs that
were interrupted with 'q'

Cause:

The mentioned commits made changes in a way that some header elements
are only partially written in
mkv_write_header, leaving the header in an invalid state. Only in
mkv_write_trailer, these elements
are finished correctly, but that does only occur at the end of the
process.

Regression:

Before these commits were applied, mkv headers have always been valid,
even before completion of ffmpeg.
This has worked reliably over many versions of ffmpeg, to it was an
obvious regression.

Bugtracker:

This issue has been recorded as #5977 which is resolved by this patch

Patch:

The patch adds a new function 'end_ebml_master_crc32_preliminary' that
preliminarily finishes the ebl
element without destroying the buffer. The buffer can be used to update
the ebml element later during
mkv_write_trailer. But most important: mkv_write_header finishes with a
valid mkv header again.
---
 libavformat/matroskaenc.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 827d755..dd8ff8e 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -367,6 +367,22 @@ static void end_ebml_master_crc32(AVIOContext *pb, 
AVIOContext **dyn_cp, Matrosk
 *dyn_cp = NULL;
 }
 
+/**
+* Complete ebml master whithout destroying the buffer, allowing for later 
updates
+*/
+static void end_ebml_master_crc32_preliminary(AVIOContext *pb, AVIOContext 
**dyn_cp, MatroskaMuxContext *mkv,
+ebml_master master)
+{
+if (pb->seekable) {
+
+uint8_t *buf;
+int size = avio_get_dyn_buf(*dyn_cp, );
+
+avio_write(pb, buf, size);
+end_ebml_master(pb, master);
+}
+}
+
 static void put_xiph_size(AVIOContext *pb, int size)
 {
 ffio_fill(pb, 255, size / 255);
@@ -1309,7 +1325,7 @@ static int mkv_write_tracks(AVFormatContext *s)
 }
 
 if (pb->seekable && !mkv->is_live)
-put_ebml_void(pb, avio_tell(mkv->tracks_bc));
+end_ebml_master_crc32_preliminary(pb, >tracks_bc, mkv, 
mkv->tracks_master);
 else
 end_ebml_master_crc32(pb, >tracks_bc, mkv, mkv->tracks_master);
 
@@ -1554,7 +1570,7 @@ static int mkv_write_tags(AVFormatContext *s)
 
 if (mkv->tags.pos) {
 if (s->pb->seekable && !mkv->is_live)
-put_ebml_void(s->pb, avio_tell(mkv->tags_bc));
+end_ebml_master_crc32_preliminary(s->pb, >tags_bc, mkv, 
mkv->tags);
 else
 end_ebml_master_crc32(s->pb, >tags_bc, mkv, mkv->tags);
 }
@@ -1811,7 +1827,7 @@ static int mkv_write_header(AVFormatContext *s)
 }
 }
 if (s->pb->seekable && !mkv->is_live)
-put_ebml_void(s->pb, avio_tell(pb));
+end_ebml_master_crc32_preliminary(s->pb, >info_bc, mkv, 
mkv->info);
 else
 end_ebml_master_crc32(s->pb, >info_bc, mkv, mkv->info);
 pb = s->pb;
-- 
2.10.2.windows.1



0004-avformat-matroskaenc-Regression-fix-for-invalid-MKV-.patch
Description: 0004-avformat-matroskaenc-Regression-fix-for-invalid-MKV-.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Steven Liu]

2017-01-07 0:47 GMT+08:00 Bodecs Bela :

>
>
> 2017.01.06. 17:33 keltezéssel, Steven Liu írta:
>
>> 2017-01-07 0:22 GMT+08:00 Bodecs Bela :
>>
>>
>>> 2017.01.06. 16:50 keltezéssel, Steven Liu írta:
>>>
>>> 2017-01-06 22:07 GMT+08:00 Bodecs Bela :

 Dear All,

> in avformat/hlsenc the start_number option starts the playlist sequence
> number
> (#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
> single_file is set, it also specifies starting sequence numbers of
> segment and subtitle filenames. Sometimes it is usefull to have unique
> starting numbers at each run, but currently it is only achiveable by
> setting this parameter manually.
> This patch enables to set start_number parameter automatically for
> practically unique numbers. If start_number is set to -1, then
> the start number will be the seconds since epoch (1970-01-01 00:00:00).
> If set to -2, then the start number will be based on the current
> date/time value as mmddHHMMSS. e.g. 20161231235659.
>
>
> thank you,
>
> Bela Bodecs
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
> Two question:
>
 1. char b[21];   Why this is 21 ?

 you are right, 15 is enough.
>>>
>>> 2. +{"start_number",  "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
 INT64_MAX,
 E},
 Why is this -2 and the help message maybe need more infomation, for
 example
 -2 mean -1 mean  0 mean, and default value.

 yes, I have altered now but I have written verbosly into the doc
>>> (muxers.texi), here:
>>>
>>> +If set to -1, then the start number will be the seconds since epoch
>>> (1970-01-01 00:00:00).
>>> +If set to -2, then the start number will be based on the current
>>> date/time as mmddHHMMSS. e.g. 20161231235759.
>>> +Default value is 0.
>>>
>>> ___
>>>
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

 I have enclosed a fixed version. A have changed some code, where greater
>>> than 32 bit long sequence numbers were not handled correctly.
>>> (av_get_frame_filename2)
>>>
>>> thank you.
>>> Bela Bodecs
>>>
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>>> +{"start_number",  "set first number in the sequence, 0 is default,
>> -1:
>> second since epoch, -2: current datetime as MMDDhhmmss, actual value
>> otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
>>  -2,
>> INT64_MAX, E},
>>
>> I have check this option, i think add flag to control the start_number
>> maybe better,
>> for example:
>> hls_flags
>> hls_playlist_type
>>
>> maybe add a start_number_flags is better, What about you think?
>>
>
> Using hls_flags is not enough to specify different values for them.
>

NO, i am not mean use hls_flags, i mean you can creat a new flags,

start_number_flags
 generic
 epoch
 datetime


I thought that there should be 3 options beside this start_number option.
> hls_start_number_playlist, hls_start_number_segment and
> hls_start_number_vtt
> Using start_number and any of the new 3 ones would be mutualy exlusive.
>
> This way anybody could use the old option (start_number) and it won't
> break the current behaviour.
> But those who want to have finer control, they may use the new options.
>
> of course -start_number x  has the same effect as using
> -hls_start_number_playlist x -hls_start_number_segment x
> -hls_start_number_vtt x
>
>
>
> ___
>> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/9] nistspheredec: prevent overflow during block alignment calculation

[Ronald S. Bultje]

Hi,

On Fri, Jan 6, 2017 at 5:30 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> On 06.01.2017 22:30, Ronald S. Bultje wrote:
> > On Fri, Jan 6, 2017 at 2:48 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavformat/nistspheredec.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c
> >> index 782d1dfbfb..9023ed7fc7 100644
> >> --- a/libavformat/nistspheredec.c
> >> +++ b/libavformat/nistspheredec.c
> >> @@ -80,6 +80,7 @@ static int nist_read_header(AVFormatContext *s)
> >>
> >>  avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
> >>
> >> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
> >> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
> >
> >
> > Same comment as the other one, the channels == 0 isn't a valid case that
> we
> > want to special case, probably check that it's not zero separately.
>
> Here I disagree: This is only the demuxer, that doesn't need to know
> the number of channels, which can be set later by the decoder.
> (For example the shorten decoder does this.)


Hm ... I don't like how we're adding special-case code for hypothetical
cases that can only come from entirely broken muxers or fuzzers. I'll leave
it to others to break the tie.

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

Re: [FFmpeg-devel] [PATCH] h264_ps: validate chroma sample location

[Andreas Cadhalpun]

On 06.01.2017 22:47, Kieran Kunhya wrote:
> On Fri, 6 Jan 2017 at 20:44 Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/h264_ps.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
>> index 8218e3a010..089bfc650a 100644
>> --- a/libavcodec/h264_ps.c
>> +++ b/libavcodec/h264_ps.c
>> @@ -181,6 +181,10 @@ static inline int decode_vui_parameters(GetBitContext
>> *gb, AVCodecContext *avctx
>>  if (get_bits1(gb)) {
>>  /* chroma_sample_location_type_top_field */
>>  avctx->chroma_sample_location = get_ue_golomb(gb) + 1;
>> +if (!av_chroma_location_name(avctx->chroma_sample_location)) {
>> +av_log(avctx, AV_LOG_WARNING, "Invalid chroma sample location
>> %d, setting to unspecified\n", avctx->chroma_sample_location);
>> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
>> +}
>>
>>
> Is there a way to long only once, this seems like it could spam the user
> full of these warnings.

One could add a field like shown_chroma_loc_warning to SPS, but I think
that would be a bit too much overhead for this.
Alternatively, one could drop the log message entirely. (Wrong color
primaries etc. aren't logged either...)

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 6/9] nistspheredec: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

On 06.01.2017 22:30, Ronald S. Bultje wrote:
> On Fri, Jan 6, 2017 at 2:48 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/nistspheredec.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c
>> index 782d1dfbfb..9023ed7fc7 100644
>> --- a/libavformat/nistspheredec.c
>> +++ b/libavformat/nistspheredec.c
>> @@ -80,6 +80,7 @@ static int nist_read_header(AVFormatContext *s)
>>
>>  avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
>>
>> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
>> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
> 
> 
> Same comment as the other one, the channels == 0 isn't a valid case that we
> want to special case, probably check that it's not zero separately.

Here I disagree: This is only the demuxer, that doesn't need to know
the number of channels, which can be set later by the decoder.
(For example the shorten decoder does this.)

Thus I think this check here is really needed.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/9] ircamdec: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

On 06.01.2017 22:31, Ronald S. Bultje wrote:
> On Fri, Jan 6, 2017 at 2:48 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/ircamdec.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/ircamdec.c b/libavformat/ircamdec.c
>> index 59f3a49411..f3cf4d0dc9 100644
>> --- a/libavformat/ircamdec.c
>> +++ b/libavformat/ircamdec.c
>> @@ -96,6 +96,7 @@ static int ircam_read_header(AVFormatContext *s)
>>  }
>>
>>  st->codecpar->bits_per_coded_sample = av_get_bits_per_sample(st->
>> codecpar->codec_id);
>> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
>> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
>>  st->codecpar->block_align = st->codecpar->bits_per_coded_sample *
>> st->codecpar->channels / 8;
>>  avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
>>  avio_skip(s->pb, 1008);
> 
> 
> I see this code a few lines up:
> 
> if (!channels || !sample_rate)
> return AVERROR_INVALIDDATA;
> 
> So channels == 0 seems impossible to me.

Right, I dropped the check for that.

Best regards,
Andreas

>From b91a25e4b8a79d8d39a9c0593d0715190474a4ec Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Thu, 15 Dec 2016 02:14:45 +0100
Subject: [PATCH 5/9] ircamdec: prevent overflow during block alignment
 calculation

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/ircamdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/ircamdec.c b/libavformat/ircamdec.c
index 59f3a49411..5d2d0ab9b9 100644
--- a/libavformat/ircamdec.c
+++ b/libavformat/ircamdec.c
@@ -96,6 +96,7 @@ static int ircam_read_header(AVFormatContext *s)
 }
 
 st->codecpar->bits_per_coded_sample = av_get_bits_per_sample(st->codecpar->codec_id);
+FF_RETURN_ON_OVERFLOW(s, st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
 st->codecpar->block_align = st->codecpar->bits_per_coded_sample * st->codecpar->channels / 8;
 avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
 avio_skip(s->pb, 1008);
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] h264_ps: validate chroma sample location

[Kieran Kunhya]

On Fri, 6 Jan 2017 at 20:44 Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/h264_ps.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 8218e3a010..089bfc650a 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -181,6 +181,10 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
>  if (get_bits1(gb)) {
>  /* chroma_sample_location_type_top_field */
>  avctx->chroma_sample_location = get_ue_golomb(gb) + 1;
> +if (!av_chroma_location_name(avctx->chroma_sample_location)) {
> +av_log(avctx, AV_LOG_WARNING, "Invalid chroma sample location
> %d, setting to unspecified\n", avctx->chroma_sample_location);
> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> +}
>
>
Is there a way to long only once, this seems like it could spam the user
full of these warnings.

Kieran
-- 

Sent from my mobile device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/9] ircamdec: prevent overflow during block alignment calculation

[Ronald S. Bultje]

Hi,

On Fri, Jan 6, 2017 at 2:48 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/ircamdec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/ircamdec.c b/libavformat/ircamdec.c
> index 59f3a49411..f3cf4d0dc9 100644
> --- a/libavformat/ircamdec.c
> +++ b/libavformat/ircamdec.c
> @@ -96,6 +96,7 @@ static int ircam_read_header(AVFormatContext *s)
>  }
>
>  st->codecpar->bits_per_coded_sample = av_get_bits_per_sample(st->
> codecpar->codec_id);
> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
>  st->codecpar->block_align = st->codecpar->bits_per_coded_sample *
> st->codecpar->channels / 8;
>  avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
>  avio_skip(s->pb, 1008);


I see this code a few lines up:

if (!channels || !sample_rate)
return AVERROR_INVALIDDATA;

So channels == 0 seems impossible to me.

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

Re: [FFmpeg-devel] [PATCH 6/9] nistspheredec: prevent overflow during block alignment calculation

[Ronald S. Bultje]

Hi,

On Fri, Jan 6, 2017 at 2:48 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/nistspheredec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c
> index 782d1dfbfb..9023ed7fc7 100644
> --- a/libavformat/nistspheredec.c
> +++ b/libavformat/nistspheredec.c
> @@ -80,6 +80,7 @@ static int nist_read_header(AVFormatContext *s)
>
>  avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
>
> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)


Same comment as the other one, the channels == 0 isn't a valid case that we
want to special case, probably check that it's not zero separately.

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

Re: [FFmpeg-devel] [PATCH 1/2] libavformat/avio: Add avio_get_dyn_buf function

[Soft Works]

[PATCH] libavformat/avio: Add avio_get_dyn_buf function

Revision #2: Bumb version and add APIchanges entry

This commit adds the avio_get_dyn_buf function which allows accessing
the
content of a DynBuffer without destroying it.

This is required in matroskaenc for preliminary writing (correct) mkv
headers.

Context for this change is fixing regression bug #5977.
---
 doc/APIchanges|  3 +++
 libavformat/avio.h| 12 
 libavformat/aviobuf.c | 17 +
 libavformat/version.h |  2 +-
 4 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index fbeae7a..3279563 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2017-01-06 - xxx - lavf 57.62.100- avio.h
+  Add avio_get_dyn_buf()
+
 2016-12-10 - xxx - lavu xx.xx.100- imgutils.h
   Add av_image_check_size2()
 
diff --git a/libavformat/avio.h b/libavformat/avio.h
index b1ce1d1..f2b9a6f 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -704,6 +704,18 @@ int avio_closep(AVIOContext **s);
 int avio_open_dyn_buf(AVIOContext **s);
 
 /**
+ * Return the written size and a pointer to the buffer. 
+ * The AVIOContext stream is left intact.
+ * The buffer must NOT be freed. 
+ * No padding is added to the buffer.
+ *
+ * @param s IO context
+ * @param pbuffer pointer to a byte buffer
+ * @return the length of the byte buffer
+ */
+int avio_get_dyn_buf(AVIOContext *s, uint8_t **pbuffer);
+
+/**
  * Return the written size and a pointer to the buffer. The buffer
  * must be freed with av_free().
  * Padding of AV_INPUT_BUFFER_PADDING_SIZE is added to the buffer.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 134d627..bf7e5f8 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1277,6 +1277,23 @@ int ffio_open_dyn_packet_buf(AVIOContext **s, int 
max_packet_size)
 return url_open_dyn_buf_internal(s, max_packet_size);
 }
 
+int avio_get_dyn_buf(AVIOContext *s, uint8_t **pbuffer)
+{
+DynBuffer *d;
+
+if (!s) {
+*pbuffer = NULL;
+return 0;
+}
+
+avio_flush(s);
+
+d = s->opaque;
+*pbuffer = d->buffer;
+
+return d->size;
+}
+
 int avio_close_dyn_buf(AVIOContext *s, uint8_t **pbuffer)
 {
 DynBuffer *d;
diff --git a/libavformat/version.h b/libavformat/version.h
index 65e6a4c..21cc8a9 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  57
-#define LIBAVFORMAT_VERSION_MINOR  61
+#define LIBAVFORMAT_VERSION_MINOR  62
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.10.2.windows.1



0002-libavformat-avio-Add-avio_get_dyn_buf-function.patch
Description: 0002-libavformat-avio-Add-avio_get_dyn_buf-function.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] h264_ps: validate chroma sample location

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/h264_ps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 8218e3a010..089bfc650a 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -181,6 +181,10 @@ static inline int decode_vui_parameters(GetBitContext *gb, 
AVCodecContext *avctx
 if (get_bits1(gb)) {
 /* chroma_sample_location_type_top_field */
 avctx->chroma_sample_location = get_ue_golomb(gb) + 1;
+if (!av_chroma_location_name(avctx->chroma_sample_location)) {
+av_log(avctx, AV_LOG_WARNING, "Invalid chroma sample location %d, 
setting to unspecified\n", avctx->chroma_sample_location);
+avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
+}
 get_ue_golomb(gb);  /* chroma_sample_location_type_bottom_field */
 }
 
-- 
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] mpeg12dec: validate color space

[Andreas Cadhalpun]

On 23.12.2016 00:57, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/mpeg12dec.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index 63979079c8..d3dc67ad6a 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -1470,6 +1470,10 @@ static void 
> mpeg_decode_sequence_display_extension(Mpeg1Context *s1)
>  s->avctx->color_primaries = get_bits(>gb, 8);
>  s->avctx->color_trc   = get_bits(>gb, 8);
>  s->avctx->colorspace  = get_bits(>gb, 8);
> +if (!av_color_space_name(s->avctx->colorspace)) {
> +av_log(s->avctx, AV_LOG_WARNING, "Invalid color space %d, 
> setting to unspecified\n", s->avctx->colorspace);
> +s->avctx->colorspace = AVCOL_SPC_UNSPECIFIED;
> +}
>  }
>  w = get_bits(>gb, 14);
>  skip_bits(>gb, 1); // marker
> 

Ping for the series.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskaenc: Regression fix for invalid MKV headers

[Soft Works]

> James Almer wrote
> 
> 
> start_ebml_master_crc32() only reserves the space needed for the CRC32 
> element,
> which is then written by end_ebml_master_crc32(). The preliminary header will
> have a couple six bytes long Void elements that every parser will promptly
> ignore.
> 
> CRC32 elements on this preliminarily state are pointless. Extra cycles wasted
> calculating something that will be overwritten and recalculated at the end of
> the process.

Thank you very much for the clarification. I made the change and checked the 
resulting
headers. I'll submit it once fate is done.

Now I hope someone will review the avio change.

Thanks again,

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

Re: [FFmpeg-devel] [PATCH 2/9] 4xm: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

On 06.01.2017 20:58, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Jan 6, 2017 at 2:47 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/4xm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
>> index 2758b69d29..45949c4e97 100644
>> --- a/libavformat/4xm.c
>> +++ b/libavformat/4xm.c
>> @@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
>>  st->codecpar->bit_rate  = (int64_t)st->codecpar->channels
>> *
>>st->codecpar->sample_rate *
>>st->codecpar->bits_per_coded_
>> sample;
>> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
>> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
>>  st->codecpar->block_align   = st->codecpar->channels *
>>st->codecpar->bits_per_coded_
>> sample;
>>
>> --
>> 2.11.0
> 
> 
> To an innocent reader (who doesn't know/care about SIGFPE), this might look
> like channels = 0 is an actual valid decoder condition that is explicitly
> handled here.

Actually this function errors out earlier if channels is zero, so I've removed
this pointless additional check. Updated patch is attached.

Best regards,
Andreas


>From 861b62eec30feaa56b10eec7ba4029daf48a3c28 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Thu, 15 Dec 2016 02:14:31 +0100
Subject: [PATCH 2/9] 4xm: prevent overflow during block alignment calculation

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/4xm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/4xm.c b/libavformat/4xm.c
index 2758b69d29..58729fed0d 100644
--- a/libavformat/4xm.c
+++ b/libavformat/4xm.c
@@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
 st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
   st->codecpar->sample_rate *
   st->codecpar->bits_per_coded_sample;
+FF_RETURN_ON_OVERFLOW(s, st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
 st->codecpar->block_align   = st->codecpar->channels *
   st->codecpar->bits_per_coded_sample;
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 2/9] 4xm: prevent overflow during block alignment calculation

[Ronald S. Bultje]

Hi,

On Fri, Jan 6, 2017 at 2:47 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/4xm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/4xm.c b/libavformat/4xm.c
> index 2758b69d29..45949c4e97 100644
> --- a/libavformat/4xm.c
> +++ b/libavformat/4xm.c
> @@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
>  st->codecpar->bit_rate  = (int64_t)st->codecpar->channels
> *
>st->codecpar->sample_rate *
>st->codecpar->bits_per_coded_
> sample;
> +FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels &&
> st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
>  st->codecpar->block_align   = st->codecpar->channels *
>st->codecpar->bits_per_coded_
> sample;
>
> --
> 2.11.0


To an innocent reader (who doesn't know/care about SIGFPE), this might look
like channels = 0 is an actual valid decoder condition that is explicitly
handled here.

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

[FFmpeg-devel] [PATCH 2/9] 4xm: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/4xm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/4xm.c b/libavformat/4xm.c
index 2758b69d29..45949c4e97 100644
--- a/libavformat/4xm.c
+++ b/libavformat/4xm.c
@@ -187,6 +187,7 @@ static int parse_strk(AVFormatContext *s,
 st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
   st->codecpar->sample_rate *
   st->codecpar->bits_per_coded_sample;
+FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels && 
st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
 st->codecpar->block_align   = st->codecpar->channels *
   st->codecpar->bits_per_coded_sample;
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 8/9] epafdec: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

---
 libavformat/epafdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/epafdec.c b/libavformat/epafdec.c
index 29190fff72..b28f035cdf 100644
--- a/libavformat/epafdec.c
+++ b/libavformat/epafdec.c
@@ -83,6 +83,7 @@ static int epaf_read_header(AVFormatContext *s)
 }
 
 st->codecpar->bits_per_coded_sample = 
av_get_bits_per_sample(st->codecpar->codec_id);
+FF_RETURN_ON_OVERFLOW(s, st->codecpar->bits_per_coded_sample > INT_MAX / 
st->codecpar->channels)
 st->codecpar->block_align = st->codecpar->bits_per_coded_sample * 
st->codecpar->channels / 8;
 
 avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 9/9] xvag: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/xvag.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/xvag.c b/libavformat/xvag.c
index 5ef4fb0900..1f28df7b89 100644
--- a/libavformat/xvag.c
+++ b/libavformat/xvag.c
@@ -74,6 +74,7 @@ static int xvag_read_header(AVFormatContext *s)
 switch (codec) {
 case 0x1c:
 st->codecpar->codec_id= AV_CODEC_ID_ADPCM_PSX;
+FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels > INT_MAX / 16)
 st->codecpar->block_align = 16 * st->codecpar->channels;
 break;
 default:
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 6/9] nistspheredec: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/nistspheredec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c
index 782d1dfbfb..9023ed7fc7 100644
--- a/libavformat/nistspheredec.c
+++ b/libavformat/nistspheredec.c
@@ -80,6 +80,7 @@ static int nist_read_header(AVFormatContext *s)
 
 avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
 
+FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels && 
st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
 st->codecpar->block_align = st->codecpar->bits_per_coded_sample * 
st->codecpar->channels / 8;
 
 if (avio_tell(s->pb) > header_size)
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 7/9] pvfdec: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/pvfdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/pvfdec.c b/libavformat/pvfdec.c
index b9f6d4f2c2..94ef20c249 100644
--- a/libavformat/pvfdec.c
+++ b/libavformat/pvfdec.c
@@ -56,6 +56,7 @@ static int pvf_read_header(AVFormatContext *s)
 st->codecpar->sample_rate = sample_rate;
 st->codecpar->codec_id= ff_get_pcm_codec_id(bps, 0, 1, 0x);
 st->codecpar->bits_per_coded_sample = bps;
+FF_RETURN_ON_OVERFLOW(s, bps > INT_MAX / st->codecpar->channels)
 st->codecpar->block_align = bps * st->codecpar->channels / 8;
 
 avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 5/9] ircamdec: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/ircamdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/ircamdec.c b/libavformat/ircamdec.c
index 59f3a49411..f3cf4d0dc9 100644
--- a/libavformat/ircamdec.c
+++ b/libavformat/ircamdec.c
@@ -96,6 +96,7 @@ static int ircam_read_header(AVFormatContext *s)
 }
 
 st->codecpar->bits_per_coded_sample = 
av_get_bits_per_sample(st->codecpar->codec_id);
+FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels && 
st->codecpar->bits_per_coded_sample > INT_MAX / st->codecpar->channels)
 st->codecpar->block_align = st->codecpar->bits_per_coded_sample * 
st->codecpar->channels / 8;
 avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
 avio_skip(s->pb, 1008);
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 4/9] genh: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/genh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/genh.c b/libavformat/genh.c
index b683e026d1..6ce2588ed3 100644
--- a/libavformat/genh.c
+++ b/libavformat/genh.c
@@ -74,6 +74,7 @@ static int genh_read_header(AVFormatContext *s)
 case  0: st->codecpar->codec_id = AV_CODEC_ID_ADPCM_PSX;break;
 case  1:
 case 11: st->codecpar->bits_per_coded_sample = 4;
+ FF_RETURN_ON_OVERFLOW(s, st->codecpar->channels > INT_MAX / 36)
  st->codecpar->block_align = 36 * st->codecpar->channels;
  st->codecpar->codec_id = AV_CODEC_ID_ADPCM_IMA_WAV;break;
 case  2: st->codecpar->codec_id = AV_CODEC_ID_ADPCM_DTK;break;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 3/9] electronicarts: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/electronicarts.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 30eb723bd5..03422e5b2c 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -556,6 +556,7 @@ static int ea_read_header(AVFormatContext *s)
 st->codecpar->codec_tag = 0;   /* no tag */
 st->codecpar->channels  = ea->num_channels;
 st->codecpar->sample_rate   = ea->sample_rate;
+FF_RETURN_ON_OVERFLOW(s, ea->bytes > INT_MAX / 8 / 2)
 st->codecpar->bits_per_coded_sample = ea->bytes * 8;
 st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
   st->codecpar->sample_rate *
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/9] avutil: add FF_RETURN_ON_OVERFLOW

[Andreas Cadhalpun]

Suggested-by: Rodger Combs 
Signed-off-by: Andreas Cadhalpun 
---

Changed the name as suggested by wm4 and the return value as suggested
by Muhammad Faiz.
There are also two new overflow checks at the end of the series.

---
 libavutil/common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavutil/common.h b/libavutil/common.h
index 8142b31fdb..6d795a353a 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -99,6 +99,8 @@
 #define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
 #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
 
+#define FF_RETURN_ON_OVERFLOW(ctx, x) if (x) {av_log(ctx, AV_LOG_ERROR, 
"Overflow check failed: " #x"\n"); return AVERROR(ERANGE);}
+
 /* misc math functions */
 
 #ifdef HAVE_AV_CONFIG_H
-- 
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] opt: check image size when setting it

[Andreas Cadhalpun]

On 11.12.2016 21:45, Andreas Cadhalpun wrote:
> On 11.12.2016 21:03, Hendrik Leppkes wrote:
>> On Sun, Dec 11, 2016 at 7:48 PM, Andreas Cadhalpun
>>  wrote:
>>> On 11.12.2016 10:04, Hendrik Leppkes wrote:
 I still see the problem that this option code does not know which
 pix_fmt the numbers relate to and as such would keep the old limit in
 place despite there being no technical reasons for it.
>>>
>>> And I still think that av_image_check_size should be changed to
>>> accept the largest value valid for any pixel format (once every place
>>> needing stricter limits is switched to the pixel format sensitive
>>> check).
>>> Do you disagree with this or what is your point?
>>
>> I could probably live with a simple w*h overflow check (more or less),
>> which av_image_check_size then probably would end up being if I
>> understand you right?
> 
> I don't think so. For example, av_image_check_size2 accepts resolutions
> like 10x8 for AV_PIX_FMT_MONOWHITE and thus av_image_check_size
> should also accept this, even though the number of pixels is larger
> than INT_MAX. However, that's not the current state of affairs, so
> until the work is done to actually use the pixel format specific limits,
> the option code should check for the old limit.
> 
>> Thats much higher then the current limit in most cases and while we
>> should try to move this to size_t/ptrdiff_t eventually to lift the
>> limit even higher on 64-bit platforms, its OK for now.
> 
> Note that av_image_check_size is documented to check that
> "all bytes of the image can be addressed with a signed int",
> so increasing the limit higher requires using a different function.

I assume I've convinced you, so I'll apply this patch soon, unless
I hear back from you.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 1/3] omadec: fix overflows during bit rate calculation

[Andreas Cadhalpun]

On 15.12.2016 01:53, Andreas Cadhalpun wrote:
> On 14.12.2016 11:16, Moritz Barsnick wrote:
>> On Wed, Dec 14, 2016 at 01:02:41 +0100, Andreas Cadhalpun wrote:
>>> On 13.12.2016 08:11, Paul B Mahol wrote:
> -st->codecpar->bit_rate= samplerate * framesize * 8 / 2048;
> +st->codecpar->bit_rate= samplerate * framesize / 256;
>>>
>>> Why multiply with 8 when dividing by a multiple of 8 directly afterwards?
>>> That's just a waste of computational resources.
>>
>> I can only explain the term with "readability" (e.g. "number of bytes
>> times 8 is number of bits, divided by 2048 is the rate"). If you
>> bracket the (8 / 2048), it would avoid the overflow, and the compiler
>> should evaluate the term to that constant 256 anyway, right? (Just if
>> anyone cares about the presumed readability.)
> 
> Well, (8 / 2048) = 0, but one can do "/ (2048 / 8)".
> Attached is a version doing it that way. Do you think that's better?

I've pushed this variant now.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature

[Gerion Entrup]

On Donnerstag, 5. Januar 2017 02:26:23 CET Michael Niedermayer wrote:
> On Wed, Jan 04, 2017 at 05:05:41PM +0100, Gerion Entrup wrote:
> > On Dienstag, 3. Januar 2017 16:58:32 CET Moritz Barsnick wrote:
> > > > > The English opposite of "fine" is "coarse", not "course". :)
> > > > Oops.
> > > 
> > > You still have a few "courses". (The actual variables, not the types. I
> > > don't care *too* much, but might be better for consistency.)
> > You're right. Fixed version attached.
> > 
> > 
> > > From my side - mostly style and docs - it looks fine. Technically, I
> > > can't judge too much. You went through a long review cycle already, so
> > > I assume it's fine for those previous reviewers. They have the last
> > > call anyway.
> > 
> > What about FATE? I'm willing to write a test, but don't know the best way. 
> > There are official conditions, whether the signature is standard compliant. 
> > I've 
> > written a python script to proof that (see previous emails). Nevertheless 
> > the 
> > checks take relatively long and need 3GB inputvideo, so I assume this is 
> > not 
> > usable for FATE.
> 
> yes, a 3gb reference is not ok for fate
> 
> 
> > 
> > One way would be, to take a short input video, take the calculated 
> > signature 
> > and use this as reference, but the standard allow some bitflips and my code
> > has some of them in comparison to the reference signatures.
> 
> then the fate test could/should compare and pass if its within what
> we expect of our code. (which may be stricter than the reference
> allowance)
> there are already tests that do similar for comparing PCM/RAW
Ok, will try to create a test the next days.

 
> > +#define OFFSET(x) offsetof(SignatureContext, x)
> 
> > +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM
> 
> should contin also  AV_OPT_FLAG_FILTERING_PARAM
Done.


> > +static int export(AVFilterContext *ctx, StreamContext *sc, int input)
> > +{
> > +SignatureContext* sic = ctx->priv;
> > +char filename[1024];
> > +
> > +if (sic->nb_inputs > 1) {
> 
> > +/* error already handled */
> > +av_get_frame_filename(filename, sizeof(filename), sic->filename, 
> > input);
> 
> its more robust to use a av_assert*() on the return code if its assumed
> to be never failing than just a comment as a comment cannot be
> automatcially checked for validity currently.
I chose av_assert0 because the check is done only nb_inputs times.

The attached patch also fixes the file writing for every frame the one input is
longer than the other.

Gerion>From 09aa2cf7c89bae45cadd15754e70404dbdc31303 Mon Sep 17 00:00:00 2001
From: Gerion Entrup 
Date: Mon, 2 Jan 2017 02:08:57 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature

This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
---
 Changelog  |   1 +
 configure  |   1 +
 doc/filters.texi   |  89 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/signature.h| 569 ++
 libavfilter/signature_lookup.c | 573 ++
 libavfilter/version.h  |   2 +-
 libavfilter/vf_signature.c | 767 +
 9 files changed, 2003 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/signature.h
 create mode 100644 libavfilter/signature_lookup.c
 create mode 100644 libavfilter/vf_signature.c

diff --git a/Changelog b/Changelog
index aff9ab0..687131c 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
 - 16.8 floating point pcm decoder
 - 24.0 floating point pcm decoder
 - Apple Pixlet decoder
+- MPEG-7 Video Signature filter
 
 version 3.2:
 - libopenmpt demuxer
diff --git a/configure b/configure
index f035f35..3e68a44 100755
--- a/configure
+++ b/configure
@@ -3126,6 +3126,7 @@ showspectrum_filter_deps="avcodec"
 showspectrum_filter_select="fft"
 showspectrumpic_filter_deps="avcodec"
 showspectrumpic_filter_select="fft"
+signature_filter_deps="gpl avcodec avformat"
 smartblur_filter_deps="gpl swscale"
 sofalizer_filter_deps="netcdf avcodec"
 sofalizer_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index 42cdd2e..1722d65 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12543,6 +12543,95 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
 @end example
 @end itemize
 
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter can handle more than one
+input. In this case the matching between the inputs can be calculated additionally.
+The filter always passes through the first input. The signature of each stream can
+be written into a file.
+
+It accepts the following options:
+
+@table @option
+@item detectmode
+Enable or disable the matching process.
+
+Available values are:
+
+@table @samp
+@item off
+Disable the 

Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskaenc: Regression fix for invalid MKV headers

[James Almer]

On 1/6/2017 2:41 PM, Soft Works wrote:
>> From: ffmpeg-devel  on behalf of James 
>> Almer 
>> Sent: Friday, January 6, 2017 6:02 AM
>>
>> IMO, no point calculating and writing a CRC element for this temporary state.
>> You can rename and simplify this function into something like
>>
>> static void end_ebml_master_preliminary(AVIOContext *pb, AVIOContext 
>> **dyn_cp,
>> ebml_master master)
>> {
>> uint8_t *buf;
>> int size = avio_get_dyn_buf(*dyn_cp, );
>>
>> avio_write(pb, buf, size);
>> end_ebml_master(pb, master);
>> }
> 
> James,
> 
> thanks for looking into this!
> 
> I wasn't sure if clients would be OK when some headers have CRC and some have 
> not 
> (in the preliminary state). Also I'm not sure if clients are OK with the CRC 
> bytes being 
> zero. 
> But if you're sure that all this is fine, I'll make this change...
> 
> softworkz

start_ebml_master_crc32() only reserves the space needed for the CRC32 element,
which is then written by end_ebml_master_crc32(). The preliminary header will
have a couple six bytes long Void elements that every parser will promptly
ignore.

CRC32 elements on this preliminarily state are pointless. Extra cycles wasted
calculating something that will be overwritten and recalculated at the end of
the process.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/exr: Fix blank output when data window != display window

[Kevin Wheatley]

No, just this kind.

Behind the images when data = display window, the most common case
OpenEXR file we have, is with a reduced data window that resides
completely inside the display window, though this particular bug would
impact any files where the value of ymax+1 is not equal to the height.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskaenc: Regression fix for invalid MKV headers

[Soft Works]

> From: ffmpeg-devel  on behalf of James Almer 
> 
> Sent: Friday, January 6, 2017 6:02 AM
> 
> IMO, no point calculating and writing a CRC element for this temporary state.
> You can rename and simplify this function into something like
> 
> static void end_ebml_master_preliminary(AVIOContext *pb, AVIOContext **dyn_cp,
> ebml_master master)
> {
> uint8_t *buf;
> int size = avio_get_dyn_buf(*dyn_cp, );
> 
> avio_write(pb, buf, size);
> end_ebml_master(pb, master);
> }

James,

thanks for looking into this!

I wasn't sure if clients would be OK when some headers have CRC and some have 
not 
(in the preliminary state). Also I'm not sure if clients are OK with the CRC 
bytes being 
zero. 
But if you're sure that all this is fine, I'll make this change...

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

Re: [FFmpeg-devel] [PATCH] libavcodec/exr: Fix blank output when data window != display window

[Paul B Mahol]

On 1/6/17, Kevin Wheatley  wrote:
> The following is a sample EXR that needs the patch to correctly
> process in FFmpeg.
>
> Kevin
>

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

Re: [FFmpeg-devel] [PATCH] libavcodec/exr: Fix blank output when data window != display window

[Martin Vignali]

Hello,

Did you try,all the official display/data window sample ?

I will try to take a look this week end.
Thanks for the sample

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

Re: [FFmpeg-devel] [PATCH] libavcodec/exr: Fix blank output when data window != display window

[Kevin Wheatley]

The following is a sample EXR that needs the patch to correctly
process in FFmpeg.

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.06. 17:33 keltezéssel, Steven Liu írta:

2017-01-07 0:22 GMT+08:00 Bodecs Bela :



2017.01.06. 16:50 keltezéssel, Steven Liu írta:


2017-01-06 22:07 GMT+08:00 Bodecs Bela :

Dear All,

in avformat/hlsenc the start_number option starts the playlist sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs


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


Two question:

1. char b[21];   Why this is 21 ?


you are right, 15 is enough.


2. +{"start_number",  "set first number in the sequence",
   OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean  0 mean, and default value.


yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:

+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.

___

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


I have enclosed a fixed version. A have changed some code, where greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)

thank you.
Bela Bodecs


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



+{"start_number",  "set first number in the sequence, 0 is default, -1:
second since epoch, -2: current datetime as MMDDhhmmss, actual value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
INT64_MAX, E},

I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type

maybe add a start_number_flags is better, What about you think?


Using hls_flags is not enough to specify different values for them.
I thought that there should be 3 options beside this start_number option.
hls_start_number_playlist, hls_start_number_segment and hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy exlusive.

This way anybody could use the old option (start_number) and it won't 
break the current behaviour.

But those who want to have finer control, they may use the new options.

of course -start_number x  has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x 
-hls_start_number_vtt x




___
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] avformat/hlsenc: start_number new options

[Steven Liu]

2017-01-07 0:22 GMT+08:00 Bodecs Bela :

>
>
> 2017.01.06. 16:50 keltezéssel, Steven Liu írta:
>
>> 2017-01-06 22:07 GMT+08:00 Bodecs Bela :
>>
>> Dear All,
>>>
>>> in avformat/hlsenc the start_number option starts the playlist sequence
>>> number
>>> (#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
>>> single_file is set, it also specifies starting sequence numbers of
>>> segment and subtitle filenames. Sometimes it is usefull to have unique
>>> starting numbers at each run, but currently it is only achiveable by
>>> setting this parameter manually.
>>> This patch enables to set start_number parameter automatically for
>>> practically unique numbers. If start_number is set to -1, then
>>> the start number will be the seconds since epoch (1970-01-01 00:00:00).
>>> If set to -2, then the start number will be based on the current
>>> date/time value as mmddHHMMSS. e.g. 20161231235659.
>>>
>>>
>>> thank you,
>>>
>>> Bela Bodecs
>>>
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>>> Two question:
>> 1. char b[21];   Why this is 21 ?
>>
> you are right, 15 is enough.
>
>> 2. +{"start_number",  "set first number in the sequence",
>>   OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
>> INT64_MAX,
>> E},
>> Why is this -2 and the help message maybe need more infomation, for
>> example
>> -2 mean -1 mean  0 mean, and default value.
>>
> yes, I have altered now but I have written verbosly into the doc
> (muxers.texi), here:
>
> +If set to -1, then the start number will be the seconds since epoch
> (1970-01-01 00:00:00).
> +If set to -2, then the start number will be based on the current
> date/time as mmddHHMMSS. e.g. 20161231235759.
> +Default value is 0.
>
> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> I have enclosed a fixed version. A have changed some code, where greater
> than 32 bit long sequence numbers were not handled correctly.
> (av_get_frame_filename2)
>
> thank you.
> Bela Bodecs
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
+{"start_number",  "set first number in the sequence, 0 is default, -1:
second since epoch, -2: current datetime as MMDDhhmmss, actual value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
INT64_MAX, E},

I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type

maybe add a start_number_flags is better, What about you think?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.06. 16:50 keltezéssel, Steven Liu írta:

2017-01-06 22:07 GMT+08:00 Bodecs Bela :


Dear All,

in avformat/hlsenc the start_number option starts the playlist sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs


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



Two question:
1. char b[21];   Why this is 21 ?

you are right, 15 is enough.

2. +{"start_number",  "set first number in the sequence",
  OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2, INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for example
-2 mean -1 mean  0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc 
(muxers.texi), here:


+If set to -1, then the start number will be the seconds since epoch 
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current 
date/time as mmddHHMMSS. e.g. 20161231235759.

+Default value is 0.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where greater 
than 32 bit long sequence numbers were not handled correctly. 
(av_get_frame_filename2)


thank you.
Bela Bodecs

>From 4560890d877af6d3e2f10a499c0cfd847ded8f37 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Fri, 6 Jan 2017 14:52:08 +0100
Subject: [PATCH] avformat/hlsenc: start_number new options

start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
Hls speficication allow 64 bit integers as sequence numbers. This patch
changes some code where only 32 bit integer values were handled.

Signed-off-by: Bela Bodecs 
---
 doc/muxers.texi  |  8 ++--
 libavformat/hlsenc.c | 42 +++---
 2 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 351cd8c..746f231 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -417,8 +417,12 @@ files, and limits the maximum number of segment files written to disk
 to @var{wrap}.
 
 @item start_number @var{number}
-Start the playlist sequence number from @var{number}. Default value is
-0.
+Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) from the specified @var{number}.
+Unless @code{hls_flags single_file} is set, it also specifies starting sequence numbers of segment and subtitle filenames.
+If set to -1, then the start number will be the seconds since epoch (1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0. If @code{hls_flags append_list} is set and read playlist sequence number is greater than specified
+@var{number}, then that value will be used as start_number value.
 
 @item hls_allow_cache @var{allowcache}
 Explicitly set whether the client MAY (1) or MUST NOT (0) cache media segments.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index eeb450a..1679607 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -39,6 +39,9 @@
 #include "internal.h"
 #include "os_support.h"
 
+#define HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH -1
+#define HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME -2
+
 #define KEYSIZE 16
 #define LINE_BUFFER_SIZE 1024
 
@@ -586,7 +589,11 @@ static int parse_playlist(AVFormatContext *s, const char *url)
 while (!avio_feof(in)) {
 read_chomp_line(in, line, sizeof(line));
 if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", )) {
-hls->sequence = atoi(ptr);
+int64_t 

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Steven Liu]

2017-01-06 22:07 GMT+08:00 Bodecs Bela :

> Dear All,
>
> in avformat/hlsenc the start_number option starts the playlist sequence
> number
> (#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
> single_file is set, it also specifies starting sequence numbers of
> segment and subtitle filenames. Sometimes it is usefull to have unique
> starting numbers at each run, but currently it is only achiveable by
> setting this parameter manually.
> This patch enables to set start_number parameter automatically for
> practically unique numbers. If start_number is set to -1, then
> the start number will be the seconds since epoch (1970-01-01 00:00:00).
> If set to -2, then the start number will be based on the current
> date/time value as mmddHHMMSS. e.g. 20161231235659.
>
>
> thank you,
>
> Bela Bodecs
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Two question:
1. char b[21];   Why this is 21 ?
2. +{"start_number",  "set first number in the sequence",
 OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2, INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for example
-2 mean -1 mean  0 mean, and default value.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: disable B frame in baseline profile

[Moritz Barsnick]

Since Michael mentioned it:

On Fri, Dec 16, 2016 at 10:21:25 +0800, Jun Zhao wrote:

> +if (avctx->max_b_frames != 0) {
> +avctx->max_b_frames = 0;
> +av_log(avctx, AV_LOG_WARNING, "H.264 constrained baseline "
> +   "profile don't support encode B frame.\n");
> +}

"H.264 constrained baseline profile doesn't support encoding with B
frames, disabling them.\n".

> +if (avctx->max_b_frames != 0) {
> +avctx->max_b_frames = 0;
> +av_log(avctx, AV_LOG_WARNING, "H.264 baseline "
> +   "profile don't support encode B frame.\n");
> +}

"H.264 baseline profile doesn't support encoding with B frames,
disabling them.\n".

(I like stating the consequent action, otherwise the uneducated user
may believe ffmpeg continues to do something which isn't valid.)

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

Re: [FFmpeg-devel] [PATCH] avcodec/atrac3: use AVCodec.init_static_data() to initialize static data

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 02:54:42PM +0100, Paul B Mahol wrote:
> On 1/6/17, James Almer  wrote:
> > On 1/6/2017 6:26 AM, Paul B Mahol wrote:
> >> On 1/6/17, James Almer  wrote:
> >>> Signed-off-by: James Almer 
> >>> ---
> >>>  libavcodec/atrac3.c | 8 ++--
> >>>  1 file changed, 2 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
> >>> index 256990b..208762d 100644
> >>> --- a/libavcodec/atrac3.c
> >>> +++ b/libavcodec/atrac3.c
> >>> @@ -771,7 +771,7 @@ static int atrac3_decode_frame(AVCodecContext *avctx,
> >>> void *data,
> >>>  return avctx->block_align;
> >>>  }
> >>>
> >>> -static av_cold void atrac3_init_static_data(void)
> >>> +static av_cold void atrac3_decode_init_static_data(AVCodec *codec)
> >>>  {
> >>>  int i;
> >>>
> >>> @@ -791,7 +791,6 @@ static av_cold void atrac3_init_static_data(void)
> >>>
> >>>  static av_cold int atrac3_decode_init(AVCodecContext *avctx)
> >>>  {
> >>> -static int static_init_done;
> >>>  int i, ret;
> >>>  int version, delay, samples_per_frame, frame_factor;
> >>>  const uint8_t *edata_ptr = avctx->extradata;
> >>> @@ -802,10 +801,6 @@ static av_cold int atrac3_decode_init(AVCodecContext
> >>> *avctx)
> >>>  return AVERROR(EINVAL);
> >>>  }
> >>>
> >>> -if (!static_init_done)
> >>> -atrac3_init_static_data();
> >>> -static_init_done = 1;
> >>> -
> >>>  /* Take care of the codec-specific extradata. */
> >>>  if (avctx->extradata_size == 14) {
> >>>  /* Parse the extradata, WAV format */
> >>> @@ -932,6 +927,7 @@ AVCodec ff_atrac3_decoder = {
> >>>  .id   = AV_CODEC_ID_ATRAC3,
> >>>  .priv_data_size   = sizeof(ATRAC3Context),
> >>>  .init = atrac3_decode_init,
> >>> +.init_static_data = atrac3_decode_init_static_data,
> >>>  .close= atrac3_decode_close,
> >>>  .decode   = atrac3_decode_frame,
> >>>  .capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
> >>> --
> >>> 2.10.2
> >>
> >> The issue is that init_static_data is called even when codec is never
> >> gonna be used.
> >> And it is called for both encoder and decoder.
> >>
> >> Do we really want such startup speed and memory overhead?
> >
> > Supposedly hardcoded tables builds were added to counter that, at least
> > partially.
> >
> > In any case it's not important for me, so this can be dropped if it has
> > no real advantages. I remember more than one email from people loathing
> > global state, so I assumed it would be proper to do it this way.
> 
> I have no real opinion on this, but maybe others do have?
> 

> We could add smarter init_static_data...

+1


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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

[FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

Dear All,

in avformat/hlsenc the start_number option starts the playlist sequence 
number

(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs

>From 3901ca87d9918e9002681b55a6984d3d0d0eaea5 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Fri, 6 Jan 2017 14:52:08 +0100
Subject: [PATCH] avformat/hlsenc: start_number new options

start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.

Signed-off-by: Bela Bodecs 
---
 doc/muxers.texi  |  7 +--
 libavformat/hlsenc.c | 22 --
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 351cd8c..ae877c9 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -417,8 +417,11 @@ files, and limits the maximum number of segment files written to disk
 to @var{wrap}.
 
 @item start_number @var{number}
-Start the playlist sequence number from @var{number}. Default value is
-0.
+Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) from the specified @var{number}.
+Unless @code{hls_flags single_file} is set, it also specifies starting sequence numbers of segment and subtitle filenames.
+Default value is 0.
+If set to -1, then the start number will be the seconds since epoch (1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current date/time as mmddHHMMSS. e.g. 20161231235659.
 
 @item hls_allow_cache @var{allowcache}
 Explicitly set whether the client MAY (1) or MUST NOT (0) cache media segments.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index eeb450a..de37be5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -39,6 +39,9 @@
 #include "internal.h"
 #include "os_support.h"
 
+#define HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH -1
+#define HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME -2
+
 #define KEYSIZE 16
 #define LINE_BUFFER_SIZE 1024
 
@@ -586,7 +589,7 @@ static int parse_playlist(AVFormatContext *s, const char *url)
 while (!avio_feof(in)) {
 read_chomp_line(in, line, sizeof(line));
 if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", )) {
-hls->sequence = atoi(ptr);
+hls->sequence = strtoll(ptr, NULL, 10);
 } else if (av_strstart(line, "#EXT-X-DISCONTINUITY", )) {
 is_segment = 1;
 hls->discontinuity = 1;
@@ -971,6 +974,21 @@ static int hls_write_header(AVFormatContext *s)
 int basename_size;
 int vtt_basename_size;
 
+if (hls->start_sequence == HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH || hls->start_sequence == HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME) {
+time_t t = time(NULL); // we will need it in either case
+if (hls->start_sequence == HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH)
+hls->start_sequence = (int64_t)t;
+else if (hls->start_sequence == HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME) {
+char b[21];
+struct tm *p, tmbuf;
+if (!(p = localtime_r(, )))
+return AVERROR(ENOMEM);
+if (!strftime(b, sizeof(b), "%Y%m%d%H%M%S", p))
+return AVERROR(ENOMEM);
+hls->start_sequence = strtoll(b, NULL, 10);
+}
+}
+
 hls->sequence   = hls->start_sequence;
 hls->recording_time = (hls->init_time ? hls->init_time : hls->time) * AV_TIME_BASE;
 hls->start_pts  = AV_NOPTS_VALUE;
@@ -1318,7 +1336,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
 #define OFFSET(x) offsetof(HLSContext, x)
 #define E AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
-{"start_number",  "set first number in the sequence",OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, 0, INT64_MAX, E},
+{"start_number",  "set first number in the 

Re: [FFmpeg-devel] [PATCH] avcodec/atrac3: use AVCodec.init_static_data() to initialize static data

[Nicolas George]

Le septidi 17 nivôse, an CCXXV, Paul B Mahol a écrit :
> I have no real opinion on this, but maybe others do have?
> 
> We could add smarter init_static_data...

Changing the framework to call init_static_data only the first time the
codec is ever opened seems like the obvious thing to do. It requires an
atomic flag per codec, I think we can devise a way.

By the way, the sine table generator in asrc_sine is significantly
faster than the float version from the libc, and bit-exact with itself
to boot, maybe you can make use of it.

Regards,

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

Re: [FFmpeg-devel] patch: the fastest video decoder ever? :)

[Paul B Mahol]

On 1/6/17, u-9...@aetey.se  wrote:
> Hello,
>
> On slow hardware a 16-bit framebuffer depth makes a remarkable difference
> in performance and still provides a good look.
>
> When videos are to be played on slow terminals there is a single
> best speed performer, cinepak (tell me if you know a better codec in this
> respect, the only comparable one I know of is VQA-15, but there is no
> reasonable encoder for it, nor a safe decoder).
>
> Unfortunately cinepak as present in ffmpeg yields rgb24 which has to be
> repacked depending on the framebuffer format.
>
> The attached patch makes cinepak to provide rgb565 in native endianness.
> This cuts in half (!) the mplayer CPU consumption on i686 with Xorg
> in the corresponding mode/depth, compared to decoding to rgb24.
>
> The optimization is possible because cinepak is a VC codec and pixel
> format packing at codebook fill is much more efficient than at a later
> stage. (Thanks Michael for the suggestion, long ago).
>
> Of course the picture quality is slightly affected if this decoder version
> is used with larger framebuffer depths. A run-time switch would be to
> prefer, if this optimization against all odds would be welcome upstream :)
>
> I am posting this as a proof of concept, lacking run-time format
> switching. As said, this patch yields half CPU consumption or double
> speed at decoding for rgb565 terminals.
>
> Regards,
> Rune
>

You could easily add option to decoder for picking output format...

See how it is done for encoders.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/atrac3: use AVCodec.init_static_data() to initialize static data

[Paul B Mahol]

On 1/6/17, James Almer  wrote:
> On 1/6/2017 6:26 AM, Paul B Mahol wrote:
>> On 1/6/17, James Almer  wrote:
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavcodec/atrac3.c | 8 ++--
>>>  1 file changed, 2 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
>>> index 256990b..208762d 100644
>>> --- a/libavcodec/atrac3.c
>>> +++ b/libavcodec/atrac3.c
>>> @@ -771,7 +771,7 @@ static int atrac3_decode_frame(AVCodecContext *avctx,
>>> void *data,
>>>  return avctx->block_align;
>>>  }
>>>
>>> -static av_cold void atrac3_init_static_data(void)
>>> +static av_cold void atrac3_decode_init_static_data(AVCodec *codec)
>>>  {
>>>  int i;
>>>
>>> @@ -791,7 +791,6 @@ static av_cold void atrac3_init_static_data(void)
>>>
>>>  static av_cold int atrac3_decode_init(AVCodecContext *avctx)
>>>  {
>>> -static int static_init_done;
>>>  int i, ret;
>>>  int version, delay, samples_per_frame, frame_factor;
>>>  const uint8_t *edata_ptr = avctx->extradata;
>>> @@ -802,10 +801,6 @@ static av_cold int atrac3_decode_init(AVCodecContext
>>> *avctx)
>>>  return AVERROR(EINVAL);
>>>  }
>>>
>>> -if (!static_init_done)
>>> -atrac3_init_static_data();
>>> -static_init_done = 1;
>>> -
>>>  /* Take care of the codec-specific extradata. */
>>>  if (avctx->extradata_size == 14) {
>>>  /* Parse the extradata, WAV format */
>>> @@ -932,6 +927,7 @@ AVCodec ff_atrac3_decoder = {
>>>  .id   = AV_CODEC_ID_ATRAC3,
>>>  .priv_data_size   = sizeof(ATRAC3Context),
>>>  .init = atrac3_decode_init,
>>> +.init_static_data = atrac3_decode_init_static_data,
>>>  .close= atrac3_decode_close,
>>>  .decode   = atrac3_decode_frame,
>>>  .capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
>>> --
>>> 2.10.2
>>
>> The issue is that init_static_data is called even when codec is never
>> gonna be used.
>> And it is called for both encoder and decoder.
>>
>> Do we really want such startup speed and memory overhead?
>
> Supposedly hardcoded tables builds were added to counter that, at least
> partially.
>
> In any case it's not important for me, so this can be dropped if it has
> no real advantages. I remember more than one email from people loathing
> global state, so I assumed it would be proper to do it this way.

I have no real opinion on this, but maybe others do have?

We could add smarter init_static_data...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] patch: the fastest video decoder ever? :)

[u-9iep]

Hello,

On slow hardware a 16-bit framebuffer depth makes a remarkable difference
in performance and still provides a good look.

When videos are to be played on slow terminals there is a single
best speed performer, cinepak (tell me if you know a better codec in this
respect, the only comparable one I know of is VQA-15, but there is no
reasonable encoder for it, nor a safe decoder).

Unfortunately cinepak as present in ffmpeg yields rgb24 which has to be
repacked depending on the framebuffer format.

The attached patch makes cinepak to provide rgb565 in native endianness.
This cuts in half (!) the mplayer CPU consumption on i686 with Xorg
in the corresponding mode/depth, compared to decoding to rgb24.

The optimization is possible because cinepak is a VC codec and pixel
format packing at codebook fill is much more efficient than at a later
stage. (Thanks Michael for the suggestion, long ago).

Of course the picture quality is slightly affected if this decoder version
is used with larger framebuffer depths. A run-time switch would be to
prefer, if this optimization against all odds would be welcome upstream :)

I am posting this as a proof of concept, lacking run-time format
switching. As said, this patch yields half CPU consumption or double
speed at decoding for rgb565 terminals.

Regards,
Rune
--- libavcodec/cinepak.c.rgb24  2017-01-05 14:43:53.379965430 +0100
+++ libavcodec/cinepak.c2017-01-05 21:54:04.333090225 +0100
@@ -30,7 +30,9 @@
  *   http://wiki.multimedia.cx/index.php?title=Sega_FILM
  *
  * Cinepak colorspace support (c) 2013 Rl, Aetey Global Technologies AB
+ * Cinepak rgb565 format (c) 2017 Rl, Aetey Global Technologies AB
  * @author Cinepak colorspace, Rl, Aetey Global Technologies AB
+ * @author Cinepak rgb565, Rl, Aetey Global Technologies AB
  */
 
 #include 
@@ -42,8 +44,12 @@
 #include "avcodec.h"
 #include "internal.h"
 
+/* feel free to replace with a better mapping implementation
+ * (keeping in mind slow, not very "intelligent" hardware)
+ */
+#define PACK_RGB_RGB565(r,g,b) r)>>3)<<11)|(((g)>>2)<<5)|(b>>3))
 
-typedef uint8_t cvid_codebook[12];
+typedef uint16_t cvid_codebook[4]; /* in the native endian rgb565 format */
 
 #define MAX_STRIPS  32
 
@@ -73,13 +79,13 @@
 uint32_t pal[256];
 } CinepakContext;
 
-static void cinepak_decode_codebook (cvid_codebook *codebook,
+static void cinepak_decode_codebook (cvid_codebook *codebook, int 
palette_video,
  int chunk_id, int size, const uint8_t 
*data)
 {
 const uint8_t *eod = (data + size);
 uint32_t flag, mask;
 int  i, n;
-uint8_t *p;
+uint16_t *p;
 
 /* check if this chunk contains 4- or 6-element vectors */
 n= (chunk_id & 0x04) ? 4 : 6;
@@ -98,33 +104,36 @@
 }
 
 if (!(chunk_id & 0x01) || (flag & mask)) {
-int k, kk;
+int k;
 
 if ((data + n) > eod)
 break;
 
-for (k = 0; k < 4; ++k) {
-int r = *data++;
-for (kk = 0; kk < 3; ++kk)
-*p++ = r;
-}
-if (n == 6) {
-int r, g, b, u, v;
+if (n == 4)
+/* 8-bit palette indexes or otherwise grayscale values,
+ * they need different handling */
+if (palette_video)
+for (k = 0; k < 4; ++k)
+*p++ = *data++;
+else
+for (k = 0; k < 4; ++k) {
+int r = *data++;
+*p++ = PACK_RGB_RGB565(r,r,r);
+}
+else {
+int y[4], u, v;
+for (k = 0; k < 4; ++k)
+/* 8-bit luminance values */
+y[k] = *data++;
 u = *(int8_t *)data++;
 v = *(int8_t *)data++;
-p -= 12;
-for(k=0; k<4; ++k) {
-r = *p++ + v*2;
-g = *p++ - (u/2) - v;
-b = *p   + u*2;
-p -= 2;
-*p++ = av_clip_uint8(r);
-*p++ = av_clip_uint8(g);
-*p++ = av_clip_uint8(b);
-}
+for(k=0; k<4; ++k)
+*p++ = PACK_RGB_RGB565(av_clip_uint8(y[k] + v*2),
+   av_clip_uint8(y[k] - (u/2) - v),
+   av_clip_uint8(y[k] + u*2));
 }
 } else {
-p += 12;
+p += 4;
 }
 }
 }
@@ -134,8 +143,8 @@
 {
 const uint8_t   *eod = (data + size);
 uint32_t flag, mask;
-uint8_t *cb0, *cb1, *cb2, *cb3;
-int x, y;
+uint16_t*cb0, *cb1, *cb2, *cb3;
+int  x, y;
 char*ip0, *ip1, *ip2, *ip3;
 
 flag = 0;
@@ -145,7 +154,7 @@
 
 /* take care of y dimension not being multiple of 4, such streams exist */
 ip0 = ip1 = ip2 = 

Re: [FFmpeg-devel] [PATCH] avcodec/atrac3: use AVCodec.init_static_data() to initialize static data

[James Almer]

On 1/6/2017 6:26 AM, Paul B Mahol wrote:
> On 1/6/17, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/atrac3.c | 8 ++--
>>  1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
>> index 256990b..208762d 100644
>> --- a/libavcodec/atrac3.c
>> +++ b/libavcodec/atrac3.c
>> @@ -771,7 +771,7 @@ static int atrac3_decode_frame(AVCodecContext *avctx,
>> void *data,
>>  return avctx->block_align;
>>  }
>>
>> -static av_cold void atrac3_init_static_data(void)
>> +static av_cold void atrac3_decode_init_static_data(AVCodec *codec)
>>  {
>>  int i;
>>
>> @@ -791,7 +791,6 @@ static av_cold void atrac3_init_static_data(void)
>>
>>  static av_cold int atrac3_decode_init(AVCodecContext *avctx)
>>  {
>> -static int static_init_done;
>>  int i, ret;
>>  int version, delay, samples_per_frame, frame_factor;
>>  const uint8_t *edata_ptr = avctx->extradata;
>> @@ -802,10 +801,6 @@ static av_cold int atrac3_decode_init(AVCodecContext
>> *avctx)
>>  return AVERROR(EINVAL);
>>  }
>>
>> -if (!static_init_done)
>> -atrac3_init_static_data();
>> -static_init_done = 1;
>> -
>>  /* Take care of the codec-specific extradata. */
>>  if (avctx->extradata_size == 14) {
>>  /* Parse the extradata, WAV format */
>> @@ -932,6 +927,7 @@ AVCodec ff_atrac3_decoder = {
>>  .id   = AV_CODEC_ID_ATRAC3,
>>  .priv_data_size   = sizeof(ATRAC3Context),
>>  .init = atrac3_decode_init,
>> +.init_static_data = atrac3_decode_init_static_data,
>>  .close= atrac3_decode_close,
>>  .decode   = atrac3_decode_frame,
>>  .capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
>> --
>> 2.10.2
> 
> The issue is that init_static_data is called even when codec is never
> gonna be used.
> And it is called for both encoder and decoder.
> 
> Do we really want such startup speed and memory overhead?

Supposedly hardcoded tables builds were added to counter that, at least
partially.

In any case it's not important for me, so this can be dropped if it has
no real advantages. I remember more than one email from people loathing
global state, so I assumed it would be proper to do it this way.

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: disable B frame in baseline profile

[Michael Niedermayer]

On Fri, Dec 16, 2016 at 10:21:25AM +0800, Jun Zhao wrote:
>  vaapi_encode_h264.c |   10 ++
>  1 file changed, 10 insertions(+)
> 79dbe8e5eaf06d39210c325486b96eef1f4d575d  
> 0001-lavc-vaapi_encode_h264-disable-B-frame-in-baseline-p.patch
> From a4b410e02ac4864c7d82b15474a65ed42a84da6a Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 16 Dec 2016 09:49:57 +0800
> Subject: [PATCH] lavc/vaapi_encode_h264: disable B frame in baseline profile.
> 
> disable B frames when usd baseline/constrined baseline profile,
> it's base on H.264 spec Annex A.2.1.
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Yi A Wang 
> ---
>  libavcodec/vaapi_encode_h264.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 69cc483..075f800 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -1190,9 +1190,19 @@ static av_cold int 
> vaapi_encode_h264_init(AVCodecContext *avctx)
>  switch (avctx->profile) {
>  case FF_PROFILE_H264_CONSTRAINED_BASELINE:
>  ctx->va_profile = VAProfileH264ConstrainedBaseline;
> +if (avctx->max_b_frames != 0) {
> +avctx->max_b_frames = 0;
> +av_log(avctx, AV_LOG_WARNING, "H.264 constrained baseline "
> +   "profile don't support encode B frame.\n");
> +}
>  break;
>  case FF_PROFILE_H264_BASELINE:
>  ctx->va_profile = VAProfileH264Baseline;
> +if (avctx->max_b_frames != 0) {
> +avctx->max_b_frames = 0;
> +av_log(avctx, AV_LOG_WARNING, "H.264 baseline "
> +   "profile don't support encode B frame.\n");

the english grammer sounds wrong


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

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


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

Re: [FFmpeg-devel] [PATCH] configure: disable the new optimizer in Visual Studio 2015 Update 3

[Michael Niedermayer]

On Fri, Jan 06, 2017 at 12:11:57AM +0100, Kacper Michajlow wrote:
> 2016-07-04 3:53 GMT+02:00 Kacper Michajlow :
> > 2016-07-03 23:39 GMT+02:00 Hendrik Leppkes :
> >> On Tue, Jun 28, 2016 at 12:01 PM, Hendrik Leppkes  
> >> wrote:
> >>> On Tue, Jun 28, 2016 at 11:48 AM, Hendrik Leppkes  
> >>> wrote:
>  Visual Studio 2015 Update 3 introduced a new SSA optimizer, however
>  it unfortunately causes miscompilations. Until it is fixed, the new
>  optimizations are disabled and should be re-checked on subsequent
>  compiler releases.
> 
>  Fixes recent FATE failure of fate-lavf-pam on VS2015.
> >>>
> >>> On that note, i'm not exactly sure which code actually miscompiles.
> >>> I though its pamenc, but the generated files are identical, then I
> >>> though its the crc computing code (crcenc/adler32), but those seem
> >>> fine as well and would likely screw up in more then one case if they
> >>> would miscompile.
> >>>
> >>> So that leaves pnmdec, I suppose, but I didn't make much headway to
> >>> poke around in that. If anyone has any handy hints how to find the
> >>> code in question that might be helpful.
> >>> Maybe the code is actually not-quite-right and might enjoy some 
> >>> straigtening.
> >>>
> >>
> >> Applied the patch to disable the new optimizations in MSVC as I did
> >> not spot anything obviously "bad" in pamdec - which does not mean
> >> there isn't anything there, of course.
> >>
> >
> > This is pretty bad miscompilation in new SSA optimizer. It assumes
> > that variable declared in loop doesn't change the value even if there
> > is assignment. I minimized testcese and reported the bug
> > https://connect.microsoft.com/VisualStudio/feedback/details/2890170
> >
> > - Kacper
> 
> Sorry for bumping such old thread, but I just got information that the
> bug has been fixed in MSVC.
> 
> It is fixed in hotfix for VS2015 - KB3207317
> https://support.microsoft.com/en-us/kb/3207317 and of course in
> upcoming VS2017.
> 
> I've confirmed that this hotfix fixes fate-lavf-pam test. The
> following change will enable SSA Optimizer on newer compiler versions.
> 
> ---
>  configure | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 398e843..cf82b3b 100755
> --- a/configure
> +++ b/configure
> @@ -6317,9 +6317,9 @@ EOF
>  check_func strtoll || add_cflags -Dstrtoll=_strtoi64
>  check_func strtoull || add_cflags -Dstrtoull=_strtoui64
>  # the new SSA optimzer in VS2015 U3 is mis-optimizing some parts
> of the code
> -# this flag should be re-checked on newer compiler releases and put 
> under a

patch is currupted by stray newline

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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/2] libavformat/avio: Add avio_get_dyn_buf function

[Michael Niedermayer]

On Thu, Jan 05, 2017 at 06:06:27PM +, Soft Works wrote:
> This commit adds the avio_get_dyn_buf function which allows accessing the
> content of a DynBuffer without destroying it.
> 
> This is required in matroskaenc for preliminary writing (correct) mkv headers.
> 
> Context for this change is fixing regression bug #5977.
> ---
>  libavformat/avio.h| 12 
>  libavformat/aviobuf.c | 17 +
>  2 files changed, 29 insertions(+)
> 
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index b1ce1d1..f2b9a6f 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -704,6 +704,18 @@ int avio_closep(AVIOContext **s);
>  int avio_open_dyn_buf(AVIOContext **s);
>  
>  /**
> + * Return the written size and a pointer to the buffer. 
> + * The AVIOContext stream is left intact.
> + * The buffer must NOT be freed. 
> + * No padding is added to the buffer.
> + *
> + * @param s IO context
> + * @param pbuffer pointer to a byte buffer
> + * @return the length of the byte buffer
> + */
> +int avio_get_dyn_buf(AVIOContext *s, uint8_t **pbuffer);

adding a public function (av*)
needs minor version bump (libavformat/version.h) and
doc/APIchanges entry

thx

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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] avcodec/atrac3: use AVCodec.init_static_data() to initialize static data

[Paul B Mahol]

On 1/6/17, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/atrac3.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
> index 256990b..208762d 100644
> --- a/libavcodec/atrac3.c
> +++ b/libavcodec/atrac3.c
> @@ -771,7 +771,7 @@ static int atrac3_decode_frame(AVCodecContext *avctx,
> void *data,
>  return avctx->block_align;
>  }
>
> -static av_cold void atrac3_init_static_data(void)
> +static av_cold void atrac3_decode_init_static_data(AVCodec *codec)
>  {
>  int i;
>
> @@ -791,7 +791,6 @@ static av_cold void atrac3_init_static_data(void)
>
>  static av_cold int atrac3_decode_init(AVCodecContext *avctx)
>  {
> -static int static_init_done;
>  int i, ret;
>  int version, delay, samples_per_frame, frame_factor;
>  const uint8_t *edata_ptr = avctx->extradata;
> @@ -802,10 +801,6 @@ static av_cold int atrac3_decode_init(AVCodecContext
> *avctx)
>  return AVERROR(EINVAL);
>  }
>
> -if (!static_init_done)
> -atrac3_init_static_data();
> -static_init_done = 1;
> -
>  /* Take care of the codec-specific extradata. */
>  if (avctx->extradata_size == 14) {
>  /* Parse the extradata, WAV format */
> @@ -932,6 +927,7 @@ AVCodec ff_atrac3_decoder = {
>  .id   = AV_CODEC_ID_ATRAC3,
>  .priv_data_size   = sizeof(ATRAC3Context),
>  .init = atrac3_decode_init,
> +.init_static_data = atrac3_decode_init_static_data,
>  .close= atrac3_decode_close,
>  .decode   = atrac3_decode_frame,
>  .capabilities = AV_CODEC_CAP_SUBFRAMES | AV_CODEC_CAP_DR1,
> --
> 2.10.2

The issue is that init_static_data is called even when codec is never
gonna be used.
And it is called for both encoder and decoder.

Do we really want such startup speed and memory overhead?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: disable B frame in baseline profile

[Jun Zhao]

ping ?

On 2016/12/16 10:21, Jun Zhao wrote:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel