[FFmpeg-devel] [PATCH, RFC] lavc/options_table: Add basic candidate h264 profiles

[Linjie Fu]

Allows specifying avctx->profile with string type profile for
h264 encoders.

Private field/option "profile" may be abled to be removed for basic
h264 profiles, directly for encoders like libopenh264/h264_vaapi,
or with an map to hardware profile like h264_qsv.

Signed-off-by: Linjie Fu 
---
One concern is some encoders have options for specific profiles,
like "high444p" for nvenc_h264 and "constrained_high" for h264_amf,
hence they may not be able to remove the private option easily.

Please help to comment.

 libavcodec/options_table.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 54366747ca..8d41f2755c 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -282,6 +282,10 @@ static const AVOption avcodec_options[] = {
 {"mpeg4_asp",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_PROFILE_MPEG4_ADVANCED_SIMPLE }, INT_MIN, INT_MAX, V|E, "profile"},
 {"main10",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_HEVC_MAIN_10 }, 
INT_MIN, INT_MAX, V|E, "profile"},
 {"msbc",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_PROFILE_SBC_MSBC }, INT_MIN, 
INT_MAX, A|E, "profile"},
+{"h264_constrained_baseline", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_PROFILE_H264_CONSTRAINED_BASELINE }, INT_MIN, INT_MAX, V|E, "profile"},
+{"h264_baseline", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_PROFILE_H264_BASELINE }, INT_MIN, INT_MAX, V|E, "profile"},
+{"h264_main", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_PROFILE_H264_MAIN }, INT_MIN, INT_MAX, V|E, "profile"},
+{"h264_high", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_PROFILE_H264_HIGH }, INT_MIN, INT_MAX, V|E, "profile"},
 {"level", NULL, OFFSET(level), AV_OPT_TYPE_INT, {.i64 = FF_LEVEL_UNKNOWN }, 
INT_MIN, INT_MAX, V|A|E, "level"},
 {"unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_LEVEL_UNKNOWN }, INT_MIN, 
INT_MAX, V|A|E, "level"},
 {"lowres", "decode at 1= 1/2, 2=1/4, 3=1/8 resolutions", OFFSET(lowres), 
AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, V|A|D},
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Improve checks for invalid stream mappings

[Steven Liu]

> 2020年5月6日 下午12:17，Andreas Rheinhardt  写道：
> 
> The mapping of streams to the various variant streams to be created by
> the HLS muxer is roughly as follows: Space and tab separate variant
> stream group maps while the entries in each variant stream group map are
> separated by ','.
> 
> The parsing process of each variant stream group proceeded as follows:
> At first the number of occurences of "a:", "v:" and "s:" in each variant
> stream group is calculated so that one can can allocate an array of
> streams with this number of entries. Then each entry is checked and the
> check for stream numbers was deficient: It did check that there is a
> number beginning after the ":", but it did not check that the number
> extends until the next "," (or until the end).
> 
> This means that an invalid variant stream group like v:0_v:1 will not be
> rejected; the problem is that the variant stream in this example is
> supposed to have two streams associated with it (because it contains two
> "v:"), yet only one stream is actually associated with it (because there
> is no ',' to start a second stream specifier). This discrepancy led to
> segfaults (null pointer dereferencing) in the rest of the code (when the
> nonexistent second stream associated to the variant stream was inspected).
> 
> Furthermore, this commit also removes an instance of using atoi() whose
> behaviour on a range error is undefined.
> 
> Fixes ticket #8652.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> libavformat/hlsenc.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index b269d015d8..5695c6cc95 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1880,7 +1880,7 @@ fail:
> 
> static int get_nth_codec_stream_index(AVFormatContext *s,
>   enum AVMediaType codec_type,
> -  int stream_id)
> +  int64_t stream_id)
> {
> unsigned int stream_index, cnt;
> if (stream_id < 0 || stream_id > s->nb_streams - 1)
> @@ -1963,6 +1963,8 @@ static int 
> parse_variant_stream_mapstring(AVFormatContext *s)
> 
> nb_streams = 0;
> while (keyval = av_strtok(varstr, ",", )) {
> +int64_t num;
> +char *end;
> varstr = NULL;
> if (av_strstart(keyval, "language:", )) {
> av_free(vs->language);
> @@ -2011,10 +2013,12 @@ static int 
> parse_variant_stream_mapstring(AVFormatContext *s)
> return AVERROR(EINVAL);
> }
> 
> -stream_index = -1;
> -if (av_isdigit(*val))
> -stream_index = get_nth_codec_stream_index (s, codec_type,
> -   atoi(val));
> +num = strtoll(val, , 0);
> +if (!av_isdigit(*val) || *end != '\0') {
> +av_log(s, AV_LOG_ERROR, "Invalid stream number: '%s'\n", 
> val);
> +return AVERROR(EINVAL);
> +}
> +stream_index = get_nth_codec_stream_index(s, codec_type, num);
> 
> if (stream_index >= 0 && nb_streams < vs->nb_streams) {
> for (i = 0; nb_streams > 0 && i < nb_streams; i++) {
> -- 
> 2.20.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

LGTM


Thanks

Steven Liu

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/17] avformat/hlsenc: Remove redundant setting of output format

[Andreas Rheinhardt]

Andreas Rheinhardt:
> avformat_alloc_output_context2() already sets the oformat member, so
> that there is no reason to overwrite it again with the value it already
> has.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/hlsenc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index f6dd894343..e58da7328f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -776,7 +776,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
> *vs)
>  if (!oc->url)
>  return AVERROR(ENOMEM);
>  
> -oc->oformat  = vs->oformat;
>  oc->interrupt_callback   = s->interrupt_callback;
>  oc->max_delay= s->max_delay;
>  oc->opaque   = s->opaque;
> @@ -790,7 +789,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream 
> *vs)
>  if (ret < 0)
>  return ret;
>  vtt_oc  = vs->vtt_avf;
> -vtt_oc->oformat = vs->vtt_oformat;
>  av_dict_copy(_oc->metadata, s->metadata, 0);
>  }
>  
> 
Will apply this tomorrow unless there are objections.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/hlsenc: Improve checks for invalid stream mappings

[Andreas Rheinhardt]

The mapping of streams to the various variant streams to be created by
the HLS muxer is roughly as follows: Space and tab separate variant
stream group maps while the entries in each variant stream group map are
separated by ','.

The parsing process of each variant stream group proceeded as follows:
At first the number of occurences of "a:", "v:" and "s:" in each variant
stream group is calculated so that one can can allocate an array of
streams with this number of entries. Then each entry is checked and the
check for stream numbers was deficient: It did check that there is a
number beginning after the ":", but it did not check that the number
extends until the next "," (or until the end).

This means that an invalid variant stream group like v:0_v:1 will not be
rejected; the problem is that the variant stream in this example is
supposed to have two streams associated with it (because it contains two
"v:"), yet only one stream is actually associated with it (because there
is no ',' to start a second stream specifier). This discrepancy led to
segfaults (null pointer dereferencing) in the rest of the code (when the
nonexistent second stream associated to the variant stream was inspected).

Furthermore, this commit also removes an instance of using atoi() whose
behaviour on a range error is undefined.

Fixes ticket #8652.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/hlsenc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index b269d015d8..5695c6cc95 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1880,7 +1880,7 @@ fail:
 
 static int get_nth_codec_stream_index(AVFormatContext *s,
   enum AVMediaType codec_type,
-  int stream_id)
+  int64_t stream_id)
 {
 unsigned int stream_index, cnt;
 if (stream_id < 0 || stream_id > s->nb_streams - 1)
@@ -1963,6 +1963,8 @@ static int parse_variant_stream_mapstring(AVFormatContext 
*s)
 
 nb_streams = 0;
 while (keyval = av_strtok(varstr, ",", )) {
+int64_t num;
+char *end;
 varstr = NULL;
 if (av_strstart(keyval, "language:", )) {
 av_free(vs->language);
@@ -2011,10 +2013,12 @@ static int 
parse_variant_stream_mapstring(AVFormatContext *s)
 return AVERROR(EINVAL);
 }
 
-stream_index = -1;
-if (av_isdigit(*val))
-stream_index = get_nth_codec_stream_index (s, codec_type,
-   atoi(val));
+num = strtoll(val, , 0);
+if (!av_isdigit(*val) || *end != '\0') {
+av_log(s, AV_LOG_ERROR, "Invalid stream number: '%s'\n", val);
+return AVERROR(EINVAL);
+}
+stream_index = get_nth_codec_stream_index(s, codec_type, num);
 
 if (stream_index >= 0 && nb_streams < vs->nb_streams) {
 for (i = 0; nb_streams > 0 && i < nb_streams; i++) {
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/bsf: add an Opus metadata bitstream filter

[Lynne]

May 5, 2020, 11:29 by d...@lynne.ee:

> May 5, 2020, 09:59 by andreas.rheinha...@gmail.com:
>
>> Lynne:
>>
>>> The only adjustable field is the gain. Some ripping/transcoding programs 
>>> have started to use it for replaygain adjustments.
>>>
>>> Patch attached.
>>>
>>> >
>>> +typedef struct OpusBSFContext {
>>> +const AVClass *class;
>>> +int64_t gain;
>>> +} OpusBSFContext;
>>>
>> [...]
>>
>>>
>>> +static const AVOption opus_metadata_options[] = {
>>> +{ "gain", "Gain, actual amplification is pow(10, gain/(20.0*256))", 
>>> OFFSET(gain),
>>> +  AV_OPT_TYPE_INT, { .i64 = 0 }, -(INT16_MAX + 1), INT16_MAX, .flags = 
>>> FLAGS },
>>> +
>>> +{ NULL },
>>> +};
>>>
>>
>> You are using an AV_OPT_TYPE_INT parameter, yet the actual type of the
>> destination is int64_t. This won't work on big endian systems. Make gain
>> an int.
>>
>
> Thanks, made it an int, patch attached.
>
>
>
>> PS: Do we actually support two's complement architectures were
>> -(INT16_MAX + 1) != INT16_MIN? (A two's complement architecture in which
>> the representation where the sign bit is set and all other bits is unset
>> is trap representation is legal according to the C standard. Does
>> someone know whether it would also be legal according to POSIX?)
>>
>
> I think we already rely on that pretty heavily in our code.
>

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [GSoC] [WIP] [RFC] FLIF Encoder & Decoder Project

[Jai Luthra]

Hi Kartik,

On Mon, Mar 30, 2020, at 4:50 AM, Kartik K. Khullar wrote:
> This is my WIP patch for GSoC and I worked on transformations involved 
> in encoding/decoding FLIF images. I have created a module under 
> libavcodec and as guided by my mentors I have tried to use pixel data 
> from AVFrame structs.
> Module covers all the chunks of code for YCoCg Transformation that will 
> be used in final encoder/decoder. Necessary structs and methods have 
> been made as suggested by my mentors. The module compiles/builds 
> successfully.
> Also I have attached a small code 'transformtest.c' which I wrote for 
> testing the implementation of pixel transformation.
> The variable AVFrame::data[] is of type uint8_t* and I was initially 
> unaware of this so I stored the YCoCg values in 'data'. So the negative 
> values which were the output of transformation of RGB -> YCoCg were not 
> stored properly and thats where the output is wrong.

I tested your code, and it is good for an initial attempt (ofc the negative 
values are overflowing the uint8_t range, which is wrong). 

Your understanding of the problem is correct, when we transform an RGB value 
that could lie in (0-255, 0-255, 0-255) it can result in a YCoCg value that 
could be anywhere between (0-255, -255-255, -255-255) and thus not fit within 
AVFrame.data which is uint8_t *

> Just wanted to ask, if I should be using some other structs for storing 
> the YCoCg values and not AVFrame, because AVFrame seems to be the 
> standard struct in FFmpeg where the raw media resides.

The YCoCg doesn't need to go in AVFrame as your testcase (RGB->YCoCg) is the 
encoding phase, which reads RGB values from **AVFrame** and ultimately should 
output binary encoded data (after entropy coding) into **AVPacket**. Sorry if 
this was not clear before.

It is OK if you use a bigger buffer with 16-bits per color value for the 
intermediate transform stages. The only invariant is that original frame will 
have 8-bit RGB values, and final encoder output will be binary data. What the 
encoder uses in the interim to represent pixel values doesn't matter to FFmpeg 
api.

But theoretically you will never use all the 16x16x16 bits with YCoCg, as the 
Co range is conditional on Y, and Cg range conditional on Y & Co. It is 
*crucial* for your project that you thoroughly understand the "new ranges" 
section in the spec [1]

Unlike YCbCr (and other common transforms) which goes from 0-255 to 0-255 (or 
even shorter), YCoCg works differently. If we know that Y value is very low or 
very high, it means color components are roughly equal and thus Co and Cg will 
definitely be in a small range. This is what the animation [2] in the spec is 
about. The Y/Luminance varies from 0-255 and the working range of CoCg is shown 
as the size of the square.

I.e. the transform may take a Co value to -255-255 but that will not happen for 
every value of Y. It will only happen when `origmax4-1 <= Y <= 3*origmax4 - 1`. 
Similar rules apply for Cg.

So your next steps should be:
1. Use uint16_t to store interim pixel values for all transformations (doesn't 
need to be part of AVFrame, is internal structure to decoder)
2. Figure out how to implement the crange functions/api as this will be crucial 
for the MANIAC encoder phase (it needs to know the conditional ranges to 
effectively do entropy coding of the pixel values)

> Attaching some testcases of RGB and its corresponding YCoCg values for 
> testing purposes.
> 
> Thanks
> Kartik K. Khullar

Cheers,
Jai

[1]: https://flif.info/spec.html#_new_ranges
[2]: https://www.youtube.com/watch?v=-v-xoKZBnhI
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet

[lance . lmwang]

On Tue, Apr 21, 2020 at 11:35:24PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> The patch will make audio and subtitle packets be marked as AV_PKT_FLAG_KEY.
> 
> For audio, it'll caused the audio sample to be sync sample.
> To verify ref/fate/movenc results:
> 1. Get the movenc test data
> [lmwang@vpn ffmpeg]$ libavformat/tests/movenc -w && mkdir -p audio_old && mv 
> *.mp4 audio_old_
> 
> After applied the patch:
> [lmwang@vpn ffmpeg]$ make fate-movenc SAMPLES=../fate-suite
> [lmwang@vpn ffmpeg]$ libavformat/tests/movenc -w && mkdir -p audio_key && mv 
> *.mp4 audio_key
> 
> 2. Get l-smash and build boxdumper
> https://github.com/l-smash/l-smash.git
> 
> 3. dump the box of crc change mp4 and diff -u
> [lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box 
> audio_key/non-empty-moov-no-elst.mp4  > audio_key/non-empty-moov-no-elst.log
> [lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box 
> audio_old/non-empty-moov-no-elst.mp4  > audio_old/non-empty-moov-no-elst.log
> [lmwang@vpn ffmpeg]$ diff -u audio_key/non-empty-moov-no-elst.log 
> audio_old/non-empty-moov-no-elst.log
> -default_sample_flags = 0x0200
> -independent
> -sync sample
> +default_sample_flags = 0x0101
> +dependent
> +non-sync sample
> 
> 4. have checked the change of crc are caused by default_sample_flags
> non-empty-moov.mp4, non-empty-moov-elst.mp4,
> non-empty-moov-no-elst.mp4, empty-moov.mp4, delay-moov-content.mp4,
> empty-moov-second-frag.mp4, empty-moov-second-frag-discont.mp4,
> delay-moov-second-frag-discont.mp4, delay-moov-elst-second-frag.mp4
> etc
> 
> 5 For subtitle, it'll effect for tests/ref/fate/binsub-movtextenc and
> tests/ref/fate/sub2video, that's expecting result for the subtitle is
> marked as keyframe. Below is the checking result of binsub-movtextenc:
> 
> [lmwang@vpn ffmpeg]$ ./ffmpeg -i 
> ../fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f 
> mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov 
> audio_key/binsub-movtextenc.mp4
> [lmwang@vpn ffmpeg]$ ./ffmpeg -i 
> ../fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f 
> mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov 
> audio_old/binsub-movtextenc.mp4
> [lmwang@vpn ffmpeg]$../l-smash/cli/boxdumper audio_key/binsub-movtextenc.mp4  
> > audio_key/binsub-movtextenc.log
> [lmwang@vpn ffmpeg]$../l-smash/cli/boxdumper audio_old/binsub-movtextenc.mp4  
> > audio_old/binsub-movtextenc.log
> [lmwang@vpn ffmpeg]$ diff -u audio_key/binsub-movtextenc.log 
> audio_old/binsub-movtextenc.log
>  // the key difference is the flag for sync sample
> -flags = 0x000701
> +flags = 0x000301
>  data-offset-present
>  sample-duration-present
>  sample-size-present
> -sample-flags-present
>  sample_count = 6
> -data_offset = 188
> +data_offset = 164
>  sample[0]
>  sample_duration = 157
>  sample_size = 21
> -sample_flags = 0x0200
> -independent
> -sync sample
> -degradation_priority = 0
>  sample[1]
>  sample_duration = 51
>  sample_size = 2
> -sample_flags = 0x0101
> -dependent
> -non-sync sample
> -degradation_priority = 0
>  sample[2]
>  sample_duration = 169
>  sample_size = 9
> -sample_flags = 0x0200
> -independent
> -sync sample
> -degradation_priority = 0
> 


will apply the patchset if no further comments tomorrow.


> Signed-off-by: Limin Wang 
> ---
>  libavformat/internal.h   |  2 +
>  libavformat/mux.c|  7 +++-
>  tests/ref/fate/binsub-movtextenc |  2 +-
>  tests/ref/fate/movenc| 50 +++
>  tests/ref/fate/sub2video | 86 
> 
>  5 files changed, 77 insertions(+), 70 deletions(-)
> 
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 716e42c..c4fac5c 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -189,6 +189,8 @@ struct AVStreamInternal {
>   */
>  int need_context_update;
>  
> +int is_intra_only;
> +
>  FFFrac *priv_pts;
>  };
>  
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index a6253f5..ea6524f 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -357,6 +357,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (desc && desc->props & 

Re: [FFmpeg-devel] [PATCH v1 1/6] fftools/ffmpeg: use local variable with same contents directly

[lance . lmwang]

On Sun, Apr 26, 2020 at 05:49:17PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  fftools/ffmpeg.c | 31 ++-
>  1 file changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index d896b14..d2b0e71 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -501,32 +501,37 @@ static void ffmpeg_cleanup(int ret)
>  FilterGraph *fg = filtergraphs[i];
>  avfilter_graph_free(>graph);
>  for (j = 0; j < fg->nb_inputs; j++) {
> -while (av_fifo_size(fg->inputs[j]->frame_queue)) {
> +InputFilter *ifilter = fg->inputs[j];
> +struct InputStream *ist = ifilter->ist;
> +
> +while (av_fifo_size(ifilter->frame_queue)) {
>  AVFrame *frame;
> -av_fifo_generic_read(fg->inputs[j]->frame_queue, ,
> +av_fifo_generic_read(ifilter->frame_queue, ,
>   sizeof(frame), NULL);
>  av_frame_free();
>  }
> -av_fifo_freep(>inputs[j]->frame_queue);
> -if (fg->inputs[j]->ist->sub2video.sub_queue) {
> -while 
> (av_fifo_size(fg->inputs[j]->ist->sub2video.sub_queue)) {
> +av_fifo_freep(>frame_queue);
> +if (ist->sub2video.sub_queue) {
> +while (av_fifo_size(ist->sub2video.sub_queue)) {
>  AVSubtitle sub;
> -
> av_fifo_generic_read(fg->inputs[j]->ist->sub2video.sub_queue,
> +av_fifo_generic_read(ist->sub2video.sub_queue,
>   , sizeof(sub), NULL);
>  avsubtitle_free();
>  }
> -av_fifo_freep(>inputs[j]->ist->sub2video.sub_queue);
> +av_fifo_freep(>sub2video.sub_queue);
>  }
> -av_buffer_unref(>inputs[j]->hw_frames_ctx);
> -av_freep(>inputs[j]->name);
> +av_buffer_unref(>hw_frames_ctx);
> +av_freep(>name);
>  av_freep(>inputs[j]);
>  }
>  av_freep(>inputs);
>  for (j = 0; j < fg->nb_outputs; j++) {
> -av_freep(>outputs[j]->name);
> -av_freep(>outputs[j]->formats);
> -av_freep(>outputs[j]->channel_layouts);
> -av_freep(>outputs[j]->sample_rates);
> +OutputFilter *ofilter = fg->outputs[j];
> +
> +av_freep(>name);
> +av_freep(>formats);
> +av_freep(>channel_layouts);
> +av_freep(>sample_rates);
>  av_freep(>outputs[j]);
>  }
>  av_freep(>outputs);
> -- 
> 1.8.3.1
> 

will apply patchset #1,#5,#6 tomorrow if no comments.

-- 
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/bsf: add an Opus metadata bitstream filter

[Lynne]

May 5, 2020, 23:15 by geo...@nsup.org:

> Lynne (12020-05-05):
>
>> Pushed.
>>
>
> I find rather rude that you did not even acknowledge the suggestion in
> this mail:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262151.html
>

I did acknowledge it but I didn't comment on it because I disliked the idea of 
modifying the values
that get written in the bitstream or using floats in a bsf, and I wanted to 
comment on the other
post more, so I replied to that one instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/bsf: add an Opus metadata bitstream filter

[Nicolas George]

Lynne (12020-05-05):
> Pushed.

I find rather rude that you did not even acknowledge the suggestion in
this mail:

https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262151.html

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [EXT] [PATCH 1/2] avcodec/v4l2_context: Drop empty packet while draining

[Andriy Gelman]

On Thu, 30. Apr 01:39, Ming Qian wrote:
> > From: Andriy Gelman 
> > 
> > v4l2_m2m devices may send an empty packet/frame while draining to indicate
> > that all capture buffers have been flushed.
> > 
> > Currently, the empty packet/frame is not handled correctly:
> > When encoding, the empty packet is forwarded to the muxer, usually creating
> > warnings.
> > When decoding, a reference to the memory is created anyway.. Since in the
> > past this memory contained a decoded frame, it results in an extra frame 
> > being
> > decoded.
> > 
> > This commit discards the empty packet/frame.
> > 
> > References:
> > linux/Documentation/media/uapi/v4l/dev-decoder.rst:
> > 
> > "The last buffer may be empty (with :c:type:`v4l2_buffer` bytesused = 0)
> >  and in that case it must be ignored by the client, as it does not
> >  contain a decoded frame."
> > 
> > linux/Documentation/media/uapi/media/v4l/vidioc-encoder-cmd.rst:
> > 
> > "...This buffer may be empty, indicated by the
> >  driver setting the ``bytesused`` field to 0."
> > 
> > Signed-off-by: Andriy Gelman 
> > ---
> >  libavcodec/v4l2_context.c | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c index
> > 6c2db5c849..f0ecc18ebd 100644
> > --- a/libavcodec/v4l2_context.c
> > +++ b/libavcodec/v4l2_context.c
> > @@ -393,6 +393,15 @@ dequeue:
> >  return NULL;
> >  }
> > 
> > +if (ctx_to_m2mctx(ctx)->draining
> > && !V4L2_TYPE_IS_OUTPUT(ctx->type)) {
> > +int bytesused = V4L2_TYPE_IS_MULTIPLANAR(buf.type) ?
> > +buf.m.planes[0].bytesused : buf.bytesused;
> > +if (bytesused == 0) {
> > +ctx->done = 1;
> > +return NULL;
> > +}
> > +}
> > +
> >  avbuf = >buffers[buf.index];
> >  avbuf->status = V4L2BUF_AVAILABLE;
> >  avbuf->buf = buf;
> > --
> > 2.25.1
> > 

> 
> Lgtm
> 

Thanks. 
Will apply both patches on Friday if no one objects.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[James Almer]

On 5/5/2020 9:42 AM, Andreas Rheinhardt wrote:
> As time passed, the API-violating behaviour of aac_adtstoasc was fixed
> and d6d605eb05c3ca32f591016c345eb2ad9e81c554 stopped delaying writing
> the header. The very same patchset containing said commit also contained
> a patch to deprecate AVFMT_FLAG_AUTO_BSF [1]. It was not applied due to
> concerns what happens when the bsf is not available.

This is solved by having the muxers select the required bsfs in
configure. The IVF muxer already does it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference frame computation based on level

[Josh Brewster]

> > From: ffmpeg-devel ffmpeg-devel-boun...@ffmpeg.org On Behalf Of
> > Josh de Kock
> > Sent: Tuesday, April 28, 2020 23:47
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference
> > frame computation based on level
> > On 26/04/2020 12:46, Josh Brewster wrote:
> >
> > > Hi, is there anything else I need to do to have this merged?
> >
> > From a precursory look at what x264 and we're doing here your patch is
> > correct. It doesn't break from a quick test, and looks OK to me. Would
> > rather someone else has a look at it too but I will again in a couple
> > days if no one does.
>
> Should be ok IMHO, thx.
>
> -   Linjie

Thanks for the feedback, I'll wait for it to be merged then.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Who is the FFmpeg documentation for? [was: Re: [PATCH v2] doc/filters.texi: complete rewrite of fps filter doc, v2.]

[Nicolas George]

Jim DeLaHunt (12020-05-02):
> Nicolas, I strongly disagree with the term "lazy beginners". This points to
> a much larger question: who is the FFmpeg documentation for?

Subscribe to ffmpeg-user, do support there, and then tell me if there
are no lazy users.

> This does not make them "lazy". What a condescending thing to say!

What makes them lazy is not perusing the documentation when they need
it. What makes them lazy is being angry if they do not find exactly what
they need in the documentation.

Most users are not like that fortunately. But some are. We should not
indulge them.

> There is value to stating the meaning explicitly.

I have not objected in stating the meaning explicitly. I have objected
to having the meaning repeated.

> Which ordinary user, coming to FFmpeg to accomplish a task rather than to
> learn all about FFmpeg's source code, will read
> https://ffmpeg.org/ffmpeg-all.html from top to bottom until they come across
> the #Video-rate section?

Could you please burn straw men elsewhere? This is not what I have
suggested at all.

>  Note that the existing *fps* filter doc does not
> link to #Video-rate.

Well, fix that!

> The doc lacks a Glossary, it lacks a Concepts
> Guide, it lacks a Tutorial, it lacks systematic cross references from terms
> used to definitions.

Then add them.

> So what you are saying is, the documentation is not for "lazy" beginners, it
> is only for beginners who are willing to pay the time to read the doc top to
> bottom, or to get a PhD in MPEG. And that excludes many, many FFmpeg users.

Please burn your straw men elsewhere.

> I will agree with you on the value of links from parameters to sections
> explaining the details of the types and values of that parameter. Note that
> my patch to the *fps* doc includes such a link.

The link is good.

> Note also that not every
> potential target of such a link includes an anchor: video filter /settb/
> does not, for example.

Then add the anchor.

> I think those links are helpful, but not sufficient.

They are.

> It is not a waste of time for the user who comes to FFmpeg wanting to get a
> task completed. But who is the FFmpeg documentation for? Is it for those
> users? Or is it just for the FFmpeg core developers? When you say
> "everybody", who do you include?

The documentation is for users who look for information. As such, it
should be terse and to the point. Extra chatter distract from the actual
info.

The only thing worse than a documentation that repeats a dozen times the
same thing is a documentation that repeats a dozen times the same thing
with subtle inconsistencies.

Make "frame rate" a link to the definition and syntax of "frame rate" in
the scope of FFmpeg's documentation, and do not duplicate a word of it.
Normal users will follow the link, because they need the syntax anyway.
Lazy users can go use a GUI.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Marton Balint]

On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:



On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:

Previously only 1:1 bitstream filters were supported, the end of the
stream was
not signalled to the bitstream filters and time base changes were
ignored.

This change also allows muxers to set up bitstream filters regardless
of the
autobsf flag during write_header instead of during check_bitstream
and those
bitstream filters will always be executed.


Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
when the user explicitly didn't want this.



The user should not be allowed to create broken files, and the only way
to achieve that is to force the BSF. I don't see a use case for
disabling BSF either for MXFenc of GXFenc. (in fact, from the top of my
head I can't see a use case for disabling automatically inserted BSF-s
in other muxers).


When automatic bitstream filtering was introduced in
1f9139b07b8a896b62c1f28f3d04acac33978c0d, writing the header of every
muxer that potentially might include a bsf automatically (as indicated
by the existence of the check_bitstream()-function) was delayed until
the first packet would be written. This meant that there was a high
probability of having a packet for the relevant stream when using the
interleaved codepath.
In particular, this meant that the Matroska muxer now received proper
extradata for AAC when writing the header even before it received any
packet with side data containing potential extradata at all. The reason
was that the aac_adtstoasc bsf has simply overwritten the output
extradata when dealing with the first packet (that was the old bsf API
without init functions; when the new bsf API was merged, the merge
commit (not the original commit) propagated the API violating behaviour).
1f6d7eb47070afc4394348721cd149f940ad2386 added the autobsf flag because
of this delay: After all, the delay existed as soon as the
AVOutputFormat had a check_bitstream function, even when no stream had a
codec for which the check_bitstream function would add a bsf at all.

As time passed, the API-violating behaviour of aac_adtstoasc was fixed
and d6d605eb05c3ca32f591016c345eb2ad9e81c554 stopped delaying writing
the header. The very same patchset containing said commit also contained
a patch to deprecate AVFMT_FLAG_AUTO_BSF [1]. It was not applied due to
concerns what happens when the bsf is not available.

(For the record, ff_stream_add_bitstream_filter() will error out if a
bsf is not available and the packet discarded. If the caller sends
another packet for this stream and a bsf that should be added isn't
available the packet will be rejected as well and so on.)

The fact that one is forced to include certain automatically inserted
bitstream filters even when one knows that one will only use them in
scenarios where they merely passthrough the packets is certainly a
downside of eliminating this flag. But now that I have reread the
history I am nevertheless in favour of deprecation.


Wow, thanks for checking this. But if we are moving in the direction of 
deprecation, then I'd rather not add the extra check to 
ff_stream_add_bitstream_filter because it will be removed later anyway.


Also when I tried to add that, there was a fate failure caused by the 
segment muxer setting the -autobsf flag but calling the muxer's 
check_bitstream function directly. Or should I add create a patch which 
simply removes the -autobsf additional options from segment.c?


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 0/2] initial input/output support for AV_PIX_FMT_GBRAPF32

[Michael Niedermayer]

On Sun, May 03, 2020 at 04:10:02PM -0700, mindm...@gmail.com wrote:
> From: Mark Reid 
> 
> changes since v1
> - added missing fillPlane32 function
> - tests should pass now for qemu-mips
> - removed exr patch for now
> 
> Mark Reid (2):
>   libswscale: add input support AV_PIX_FMT_GBRAPF32
>   libswscale: add output support for AV_PIX_FMT_GBRAPF32

will apply

thx

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

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v13] avformat: add demuxer for Pro Pinball Series' Soundbanks

[Michael Niedermayer]

On Mon, May 04, 2020 at 02:25:56PM +, Zane van Iperen wrote:
> Adds support for the soundbank files used by the Pro Pinball series of games.
> 
> v13:
>   - Increment current_track after reading a packet.
> 
> v12: [9]
>   - Read packets in a round-robin fashion to
> avoid "Too many packets buffered" errors.
> 
> v11: [8]
>   - Change probe function to be all-or-nothing
> 
> v10: [7]
>   - Change while() to for().
> 
> v9: [6]
>   - Rebase after codec_id.h changes
>   - style fixes
>   - Fix an uninitialised variable read
> 
> v8: [5]
>   - change "goto done" to a return + "goto fail"
>   - Handle truncated files
>   - Fix potential byte counter desync
> 
> v7: [4]
>   - Fix empty lines
>   - Use av_malloc_array() instead of av_reallocp_array()
>   - Replace multiple av_freep()'s with a goto
>   - Minor comment cleanups
>   - Ask for a sample if unexpected header values are found
> 
> v6: [3]
>   - fix tools/probetest failure
> 
> v5:
>   - add probe function
>   - add flag #define's
> 
> v4: [2]
>   - fix adpcm index table type
> 
> v3: [1]
>   - fix potential memory leak if read_header() fails
>   - fix a buffer overread
>   - attempt seek before updating state
>   - remove unneeded check
>   - naming fixes
> 
> v2:
>   - Add sanity checks in header fields
>   - Formatting and comment fixes
>   - Change the struct names to match the files
> 
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/258672.html
> [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/258918.html
> [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259278.html
> [4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259864.html
> [5]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259863.html
> [6]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260706.html
> [7]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260854.html
> [8]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261497.html
> [9]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262030.html

will apply without this development history
we normally dont include such things in git log and its quite long

but ill leave one link to the mailing list thread so anyone interrested
can find it

thx

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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] libswscale: add output support for AV_PIX_FMT_GBRAPF32

[Mark Reid]

On Sun, May 3, 2020 at 10:17 AM Michael Niedermayer 
wrote:

> On Sun, May 03, 2020 at 02:01:21AM -0700, Mark Reid wrote:
> > On Thu., Apr. 30, 2020, 11:46 a.m. Mark Reid, 
> wrote:
> >
> > >
> > >
> > > On Thu, Apr 30, 2020 at 7:59 AM Michael Niedermayer
> 
> > > wrote:
> > >
> > >> On Wed, Apr 29, 2020 at 02:49:35PM -0700, Mark Reid wrote:
> > >> > On Wed, Apr 29, 2020 at 2:22 PM Michael Niedermayer
> > >> 
> > >> > wrote:
> > >> >
> > >> > > On Wed, Apr 29, 2020 at 11:19:56PM +0200, Michael Niedermayer
> wrote:
> > >> > > > On Tue, Apr 28, 2020 at 08:02:34PM -0700, mindm...@gmail.com
> wrote:
> > >> > > > > From: Mark Reid 
> > >> > > > >
> > >> > > > > ---
> > >> > > > >  libswscale/output.c  | 82
> > >> 
> > >> > > > >  libswscale/slice.c   | 28 
> > >> > > > >  libswscale/swscale_unscaled.c| 33 ++
> > >> > > > >  libswscale/utils.c   |  8 +--
> > >> > > > >  tests/ref/fate/filter-pixdesc-gbrapf32be |  1 +
> > >> > > > >  tests/ref/fate/filter-pixdesc-gbrapf32le |  1 +
> > >> > > > >  tests/ref/fate/filter-pixdesc-gbrpf32be  |  1 +
> > >> > > > >  tests/ref/fate/filter-pixdesc-gbrpf32le  |  1 +
> > >> > > > >  tests/ref/fate/filter-pixfmts-copy   |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-crop   |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-field  |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-fieldorder |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-hflip  |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-il |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-null   |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-scale  |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-transpose  |  4 ++
> > >> > > > >  tests/ref/fate/filter-pixfmts-vflip  |  4 ++
> > >> > > > >  18 files changed, 180 insertions(+), 15 deletions(-)
> > >> > > > >  create mode 100644 tests/ref/fate/filter-pixdesc-gbrapf32be
> > >> > > > >  create mode 100644 tests/ref/fate/filter-pixdesc-gbrapf32le
> > >> > > > >  create mode 100644 tests/ref/fate/filter-pixdesc-gbrpf32be
> > >> > > > >  create mode 100644 tests/ref/fate/filter-pixdesc-gbrpf32le
> > >> > > >
> > >> > > > Fails on qemu MIPS
> > >> > > >
> > >> > > > --- src/tests/ref/fate/filter-pixfmts-scale 2020-04-29
> > >> > > 22:18:07.326122866 +0200
> > >> > > > +++ tests/data/fate/filter-pixfmts-scale2020-04-29
> > >> > > 23:06:16.167950113 +0200
> > >> > > > @@ -25,8 +25,8 @@
> > >> > > >  gbrap12le   bb1ba1c157717db3dd612a76d38a018e
> > >> > > >  gbrap16be   c72b935a6e57a8e1c37bff08c2db55b1
> > >> > > >  gbrap16le   13eb0e62b1ac9c1c86c81521eaefab5f
> > >> > > > -gbrapf32be  e6abe67df7fdd5f5dc5db7d852e50954
> > >> > > > -gbrapf32le  4d3043b206f7053f7d8d5672f430d680
> > >> > > > +gbrapf32be  982d646dc5b2dc718c65fa2a439828f5
> > >> > > > +gbrapf32le  f1ffa56441e29aab5e1fd982337bb8ac
> > >> > > >  gbrpdc3387f925f972c61aae7eb23cdc19f0
> > >> > > >  gbrp10be0277d4c3a8498d75e2783fb81379e481
> > >> > > >  gbrp10lef3d70f8ab845c3c9b8f7452e4a6e285a
> > >> > > > Test filter-pixfmts-scale failed. Look at
> > >> > > tests/data/fate/filter-pixfmts-scale.err for details.
> > >> > > > src/tests/Makefile:254: recipe for target
> > >> 'fate-filter-pixfmts-scale'
> > >> > > failed
> > >> > > > make: *** [fate-filter-pixfmts-scale] Error 1
> > >> > > > TESTh264-conformance-frext-pph422i5_panasonic_a
> > >> > > > TESTh264-conformance-frext-pph422i6_panasonic_a
> > >> > > > TESTh264-conformance-frext-pph422i7_panasonic_a
> > >> > > > TESTh264-conformance-hcbp2_hhi_a
> > >> > > > TESTh264-conformance-hcmp1_hhi_a
> > >> > > >
> > >> > > > I also think for float, tests based on comparission instead of
> > >> checksums
> > >> > > > would allow more use of floats in the computations which would
> > >> > > > differ rounding wise between platforms
> > >> > >
> > >> > > and the 2 sws patches would otherwise be ok if they didnt break
> any
> > >> tests
> > >> > >
> > >> > >
> > >> > I was worried about the test with float, and tried to limiting the
> > >> number
> > >> > of float operations, but guess it's not enough.
> > >>
> > >> > I haven't looked yet, but is there anywhere you could point me to
> doing
> > >> > a comparison based test?
> > >>
> > >> anything float based needs a comparission or luck ...
> > >> audio tests using "oneoff/stddev" in fate for example
> > >> checkasm also checks some float code with comparissions
> > >>
> > >> not sure how to best integrate this here ...
> > >>
> > >> thx
> > >>
> > >
> > > Thanks! I'll check those out. I came up with some other ideas to try
> too
> > > that I think might work. Its a tricky problem for sure!
> > >
> >
> > lt appears the mips test where only failing on the alpha channel formats.
> > it seems to because of a planefill 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/wavpack: Check rate_x and sample rate for overflow

[Michael Niedermayer]

On Sun, May 03, 2020 at 04:13:47PM -0700, David Bryant wrote:
> On 5/2/20 2:08 PM, Michael Niedermayer wrote:
> > Fixes: shift exponent 32 is too large for 32-bit type 'int'
> > Fixes: 
> > 21647/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5686168323883008
> >
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/wavpack.c | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> > index 58ab561a15..ead57063c8 100644
> > --- a/libavcodec/wavpack.c
> > +++ b/libavcodec/wavpack.c
> > @@ -1359,7 +1359,10 @@ static int wavpack_decode_block(AVCodecContext 
> > *avctx, int block_no,
> >  bytestream2_skip(, ssize);
> >  continue;
> >  }
> > -rate_x = 1 << bytestream2_get_byte();
> > +rate_x = bytestream2_get_byte();
> > +if (rate_x > 30)
> > +return AVERROR_INVALIDDATA;
> > +rate_x = 1 << rate_x;
> >  dsd_mode = bytestream2_get_byte();
> >  if (dsd_mode && dsd_mode != 1 && dsd_mode != 3) {
> >  av_log(avctx, AV_LOG_ERROR, "Invalid DSD encoding mode: 
> > %d\n",
> > @@ -1498,9 +1501,13 @@ static int wavpack_decode_block(AVCodecContext 
> > *avctx, int block_no,
> >  av_log(avctx, AV_LOG_ERROR, "Custom sample rate 
> > missing.\n");
> >  return AVERROR_INVALIDDATA;
> >  }
> > -new_samplerate = sample_rate * rate_x;
> > +new_samplerate = sample_rate;
> >  } else
> > -new_samplerate = wv_rates[sr] * rate_x;
> > +new_samplerate = wv_rates[sr];
> > +
> > +if (new_samplerate * (uint64_t)rate_x > INT_MAX)
> > +return AVERROR_INVALIDDATA;
> > +new_samplerate *= rate_x;
> >  
> >  if (multiblock) {
> >  if (chan)
> 
> Looks correct to me. Thanks.

will apply

thx

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

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


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v4] lavc/vp9: fix reference frame dimensions check for SINGLE_REFERENCE mode

[Ronald S. Bultje]

Hi,

On Wed, Apr 29, 2020 at 8:08 AM Fu, Linjie  wrote:

> > From: ffmpeg-devel  On Behalf Of Fu,
> > Linjie
> > Sent: Friday, March 20, 2020 09:49
> > To: Ronald S. Bultje ; FFmpeg development
> > discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH, v4] lavc/vp9: fix reference frame
> > dimensions check for SINGLE_REFERENCE mode
> >
> > > From: Ronald S. Bultje 
> > > Sent: Thursday, March 19, 2020 20:10
> > > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > > Cc: Fu, Linjie 
> > > Subject: Re: [FFmpeg-devel] [PATCH, v4] lavc/vp9: fix reference frame
> > dimensions check for SINGLE_REFERENCE mode
> > >
> > > Hi,
> > >
> > > On Tue, Mar 17, 2020 at 10:59 AM Linjie Fu
> > mailto:linjie...@intel.com>> wrote:
> > > With the description in frame size with refs semantics (SPEC 7.2.5),
> > > it is a requirement of bitstream conformance that for at least one
> > > reference frame has the valid dimensions.
> > >
> > > Modify the check to make sure the decoder works well in
> > SINGLE_REFERENCE
> > > mode that not all reference frames have valid dimensions.
> > >
> > > Check and error out if invalid reference frame is used in inter_recon.
> > >
> > > One of the failure case is a 480x272 inter frame (SINGLE_REFERENCE
> mode)
> > > with following reference pool:
> > >
> > > 0.  960x544LASTvalid
> > > 1. 1920x1088 GOLDEN  invalid, but not used in single reference mode
> > > 2. 1920x1088 ALTREF  invalid, but not used in single reference mode
> > > 3~7  ... Unused
> > >
> > > Identical logic in libvpx:
> > >
> >  > ecodeframe.c#L736>
> > >
> > > Signed-off-by: Linjie Fu  linjie...@intel.com>>
> > > ---
> > > [v3]: replace assert with check/return, tested in both multi
> frame/slice
> > mode
> > > [v4]: clear error_info to make decoding still work for other frames in
> this
> > stream
> > >
> > > libavcodec/vp9.c  | 20 ++--
> > > libavcodec/vp9dec.h   |  5 +
> > > libavcodec/vp9recon.c | 10 ++
> > > 3 files changed, 33 insertions(+), 2 deletions(-)
> > >
> > > LGTM, thanks for the revisions. (We have been discussing this on IRC.)
> >
> > Thanks for the review and valuable suggestions.
> >
> Ping for merge, thx.


Applied.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Reporting bugs

[Carl Eugen Hoyos]

Am Di., 5. Mai 2020 um 14:07 Uhr schrieb Nico Coesel :

> I want to report a bug in the jpeg encoding but I can't
> seem to register to trac.

Alternatives are to report the issue on the user mailing
list or on irc.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference frame computation based on level

[Fu, Linjie]

> From: ffmpeg-devel  On Behalf Of
> Josh Brewster
> Sent: Tuesday, May 5, 2020 23:52
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference
> frame computation based on level
> 
> > > From: ffmpeg-devel ffmpeg-devel-boun...@ffmpeg.org On Behalf Of
> > > Josh de Kock
> > > Sent: Tuesday, April 28, 2020 23:47
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference
> > > frame computation based on level
> > > On 26/04/2020 12:46, Josh Brewster wrote:
> > >
> > > > Hi, is there anything else I need to do to have this merged?
> > >
> > > From a precursory look at what x264 and we're doing here your patch is
> > > correct. It doesn't break from a quick test, and looks OK to me. Would
> > > rather someone else has a look at it too but I will again in a couple
> > > days if no one does.
> >
> > Should be ok IMHO, thx.
> >
> > -   Linjie
> 
> Thanks for the feedback, I'll wait for it to be merged then.
> 

FYI, already merged several days ago with the help of Josh in:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/79f001675a2bae16e243f30a3e7de9da6aeb3c2d

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] closed caption decoder: accept and decode a new codec type of 'raw 608 byte pairs'

[Roger Pack]

Bump...

On Wed, Apr 29, 2020 at 11:23 PM Roger Pack  wrote:
>
> > > c9153590e5f167e41910d867639eb887164e28d2  
> > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001
> > > From: rogerdpack 
> > > Date: Tue, 28 Apr 2020 05:15:15 +
> > > Subject: [PATCH 1/3] closed caption decoder: accept and decode a new codec
> > >  type of 'raw 608 byte pairs'
> >
> > breaks fate
> >
> > TESTsub-cc-realtime
> > --- ./tests/ref/fate/sub-cc-realtime2020-04-28 15:43:10.506887112 +0200
> > +++ tests/data/fate/sub-cc-realtime 2020-04-28 19:31:37.164407976 +0200
>
> OK I believe to have fixed that, see the latest attached.  Plus a few
> more aesthetic cleanups to boot.
>
> Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V2 1/2] avformat movenc extend video_track_timescale flag range to allow use of video stream timescale for track

[vectronic]

Extend range of video_track_timescale flag value to -1 to indicate video stream 
timescale should be used for track timebase. Add debug message if 
video_track_timescale is not specified and the video stream timescale is 
clamped to greater than 1.

Signed-off-by: vectronic 
---
 libavformat/movenc.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 32e8109268..bcc0ab4377 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -92,7 +92,7 @@ static const AVOption options[] = {
 { "min_frag_duration", "Minimum fragment duration", 
offsetof(MOVMuxContext, min_fragment_duration), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
 { "frag_size", "Maximum fragment size", offsetof(MOVMuxContext, 
max_fragment_size), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM},
 { "ism_lookahead", "Number of lookahead entries for ISM files", 
offsetof(MOVMuxContext, ism_lookahead), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
-{ "video_track_timescale", "set timescale of all video tracks", 
offsetof(MOVMuxContext, video_track_timescale), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
+{ "video_track_timescale", "set timescale of all video tracks, -1 to use 
existing stream timescale", offsetof(MOVMuxContext, video_track_timescale), 
AV_OPT_TYPE_INT, {.i64 = 0}, -1, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
 { "brand","Override major brand", offsetof(MOVMuxContext, 
major_brand),   AV_OPT_TYPE_STRING, {.str = NULL}, .flags = 
AV_OPT_FLAG_ENCODING_PARAM },
 { "use_editlist", "use edit list", offsetof(MOVMuxContext, use_editlist), 
AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, AV_OPT_FLAG_ENCODING_PARAM},
 { "fragment_index", "Fragment number of the next fragment", 
offsetof(MOVMuxContext, fragments), AV_OPT_TYPE_INT, {.i64 = 1}, 1, INT_MAX, 
AV_OPT_FLAG_ENCODING_PARAM},
@@ -6454,14 +6454,19 @@ static int mov_init(AVFormatContext *s)
 }
 track->height = track->tag >> 24 == 'n' ? 486 : 576;
 }
-if (mov->video_track_timescale) {
+if (mov->video_track_timescale > 0) {
 track->timescale = mov->video_track_timescale;
 if (mov->mode == MODE_ISM && mov->video_track_timescale != 
1000)
 av_log(s, AV_LOG_WARNING, "Warning: some tools, like 
mp4split, assume a timescale of 1000 for ISMV.\n");
 } else {
 track->timescale = st->time_base.den;
+if (mov->video_track_timescale != -1) {
 while(track->timescale < 1)
 track->timescale *= 2;
+if (track->timescale != st->time_base.den)
+av_log(s, AV_LOG_DEBUG, "Stream timescale was low (%d), 
the track timescale has been forced to %d.\n"
+"Specify -video_track_timescale -1 
to prevent this.\n", st->time_base.den, track->timescale);
+}
 }
 if (st->codecpar->width > 65535 || st->codecpar->height > 65535) {
 av_log(s, AV_LOG_ERROR, "Resolution %dx%d too large for 
mov/mp4\n", st->codecpar->width, st->codecpar->height);
-- 
2.24.2 (Apple Git-127)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V2 2/2] avformat movenc extend video_track_timescale flag range to allow use of video stream timescale for track

[vectronic]

indent

Signed-off-by: vectronic 
---
 libavformat/movenc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index bcc0ab4377..989ba5b857 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6461,11 +6461,11 @@ static int mov_init(AVFormatContext *s)
 } else {
 track->timescale = st->time_base.den;
 if (mov->video_track_timescale != -1) {
-while(track->timescale < 1)
-track->timescale *= 2;
-if (track->timescale != st->time_base.den)
-av_log(s, AV_LOG_DEBUG, "Stream timescale was low (%d), 
the track timescale has been forced to %d.\n"
-"Specify -video_track_timescale -1 
to prevent this.\n", st->time_base.den, track->timescale);
+while(track->timescale < 1)
+track->timescale *= 2;
+if (track->timescale != st->time_base.den)
+av_log(s, AV_LOG_DEBUG, "Stream timescale was low 
(%d), the track timescale has been forced to %d.\n"
+"Specify 
-video_track_timescale -1 to prevent this.\n", st->time_base.den, 
track->timescale);
 }
 }
 if (st->codecpar->width > 65535 || st->codecpar->height > 65535) {
-- 
2.24.2 (Apple Git-127)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V2 0/2] avformat movenc extend video_track_timescale flag to allow use of video stream timescale for track

[vectronic]

Revised patch based on feedback. Instead of introducing a new flag, this extend 
the range of video_track_timescale down to -1
which indicates to use the video stream timescale for video the track.

Still providing a debug message in default case if video timescale specified 
has been clamped to above 1.

The example scenario is where the input mov file has a video track timebase of 
e.g. 600.

Currently, if the following is run, the output file has a modified video track 
timebase of 19200:

ffmpeg -i in.mov -c:v copy out.mov

With this patch, if you run:

ffmpeg -loglevel debug -i in.mov -c:v copy out.mov

you will see in the output:

Stream timescale was low (600), the track timescale has been forced to 
19200.

And if you run the following, you will get an output file with the same video 
track timebase as the input e.g. 600:

ffmpeg -i in.mov -c:v copy -video_track_timescale -1 out.mov

The previous would be the same behaviour as the following, but it does not rely 
on the user knowing and specifying the input timebase:

ffmpeg -i in.mov -c:v copy -video_track_timescale 600 out.mov



vectronic (2):
  avformat movenc extend video_track_timescale flag range to allow use
of video stream timescale for track
  avformat movenc extend video_track_timescale flag range to allow use
of video stream timescale for track

 libavformat/movenc.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

-- 
2.24.2 (Apple Git-127)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/profiles: remove duplicate FF_PROFILE_RESERVED entry

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/profiles.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index eaf0d68..e59a3a5 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -99,7 +99,6 @@ const AVProfile ff_mpeg2_video_profiles[] = {
 { FF_PROFILE_MPEG2_MAIN, "Main"   },
 { FF_PROFILE_MPEG2_SIMPLE,   "Simple" },
 { FF_PROFILE_RESERVED,   "Reserved"   },
-{ FF_PROFILE_RESERVED,   "Reserved"   },
 { FF_PROFILE_UNKNOWN  },
 };
 
-- 
1.8.3.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/bsf: add an Opus metadata bitstream filter

[Lynne]

May 5, 2020, 09:59 by andreas.rheinha...@gmail.com:

> Lynne:
>
>> The only adjustable field is the gain. Some ripping/transcoding programs 
>> have started to use it for replaygain adjustments.
>>
>> Patch attached.
>>
>> >
>> +typedef struct OpusBSFContext {
>> +const AVClass *class;
>> +int64_t gain;
>> +} OpusBSFContext;
>>
> [...]
>
>>
>> +static const AVOption opus_metadata_options[] = {
>> +{ "gain", "Gain, actual amplification is pow(10, gain/(20.0*256))", 
>> OFFSET(gain),
>> +  AV_OPT_TYPE_INT, { .i64 = 0 }, -(INT16_MAX + 1), INT16_MAX, .flags = 
>> FLAGS },
>> +
>> +{ NULL },
>> +};
>>
>
> You are using an AV_OPT_TYPE_INT parameter, yet the actual type of the
> destination is int64_t. This won't work on big endian systems. Make gain
> an int.
>

Thanks, made it an int, patch attached.



> PS: Do we actually support two's complement architectures were
> -(INT16_MAX + 1) != INT16_MIN? (A two's complement architecture in which
> the representation where the sign bit is set and all other bits is unset
> is trap representation is legal according to the C standard. Does
> someone know whether it would also be legal according to POSIX?)
>

I think we already rely on that pretty heavily in our code.

>From 91ee53a5a46dc15cbbc4d463d6057ffa483b0625 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Sun, 3 May 2020 21:17:33 +0100
Subject: [PATCH] lavc/bsf: add an Opus metadata bitstream filter

The only adjustable field is the gain. Some ripping/transcoding programs
have started to use it.
---
 libavcodec/Makefile|  1 +
 libavcodec/bitstream_filters.c |  1 +
 libavcodec/opus_metadata_bsf.c | 72 ++
 3 files changed, 74 insertions(+)
 create mode 100644 libavcodec/opus_metadata_bsf.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 28076c2c83..cf72f55aff 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1116,6 +1116,7 @@ OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += mp3_header_decompress_bsf.o \
 OBJS-$(CONFIG_MPEG2_METADATA_BSF) += mpeg2_metadata_bsf.o
 OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
 OBJS-$(CONFIG_NULL_BSF)   += null_bsf.o
+OBJS-$(CONFIG_OPUS_METADATA_BSF)  += opus_metadata_bsf.o
 OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
 OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 6b5ffe4d70..f1b24baa53 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -49,6 +49,7 @@ extern const AVBitStreamFilter ff_mpeg4_unpack_bframes_bsf;
 extern const AVBitStreamFilter ff_mov2textsub_bsf;
 extern const AVBitStreamFilter ff_noise_bsf;
 extern const AVBitStreamFilter ff_null_bsf;
+extern const AVBitStreamFilter ff_opus_metadata_bsf;
 extern const AVBitStreamFilter ff_prores_metadata_bsf;
 extern const AVBitStreamFilter ff_remove_extradata_bsf;
 extern const AVBitStreamFilter ff_text2movsub_bsf;
diff --git a/libavcodec/opus_metadata_bsf.c b/libavcodec/opus_metadata_bsf.c
new file mode 100644
index 00..867ad830d3
--- /dev/null
+++ b/libavcodec/opus_metadata_bsf.c
@@ -0,0 +1,72 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "bsf.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+
+typedef struct OpusBSFContext {
+const AVClass *class;
+int gain;
+} OpusBSFContext;
+
+static int opus_metadata_filter(AVBSFContext *bsfc, AVPacket *pkt)
+{
+return ff_bsf_get_packet_ref(bsfc, pkt);
+}
+
+static int opus_metadata_init(AVBSFContext *bsfc)
+{
+OpusBSFContext *s = bsfc->priv_data;
+
+if (bsfc->par_out->extradata_size < 19)
+return AVERROR_INVALIDDATA;
+
+AV_WL16(bsfc->par_out->extradata + 16, s->gain);
+
+return 0;
+}
+
+#define OFFSET(x) offsetof(OpusBSFContext, x)
+#define FLAGS (AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_BSF_PARAM)
+static const AVOption opus_metadata_options[] = {
+{ "gain", "Gain, actual amplification is pow(10, gain/(20.0*256))", OFFSET(gain),
+  AV_OPT_TYPE_INT, { .i64 = 0 }, -(INT16_MAX + 1), INT16_MAX, .flags = FLAGS },
+
+{ NULL },
+};
+
+static const AVClass 

[FFmpeg-devel] [PATCH 11/12] avformat/nutenc: Don't segfault when chapters are added during muxing

[Andreas Rheinhardt]

When writing the header, the NUT muxer allocates an array with as many
entries as there are chapters containing information about the used
timebase. This information is used when writing the headers and also
when resending the headers (as the NUT muxer does from time to time).

When the NUT muxer writes or resends the headers, it simply presumes
that there are enough entries in its array for each chapter in the
AVFormatContext. Yet users are allowed to add chapters during the muxing
process, so this presumption is wrong and may lead to segfaults.

So explicitly store the number of entries of the chapter array and refer
to this number whenever headers are written.

Signed-off-by: Andreas Rheinhardt 
---
This patch presumes that the user may not change or remove the chapters
available during writing the header (if there were chapters available
when writing the header at all). I hope this is ok.

 libavformat/nut.h| 1 +
 libavformat/nutenc.c | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/nut.h b/libavformat/nut.h
index a4409ee23d..52225fed93 100644
--- a/libavformat/nut.h
+++ b/libavformat/nut.h
@@ -115,6 +115,7 @@ typedef struct NUTContext {
 int flags;
 int version; // version currently in use
 int minor_version;
+unsigned nb_chapters;
 } NUTContext;
 
 extern const AVCodecTag ff_nut_subtitle_tags[];
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 5071278835..2d35c44b79 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -675,7 +675,7 @@ static int write_headers(AVFormatContext *avctx, 
AVIOContext *bc)
 goto fail;
 }
 
-for (i = 0; i < nut->avf->nb_chapters; i++) {
+for (i = 0; i < nut->nb_chapters; i++) {
 write_chapter(nut, dyn_bc, i, prelude, _size);
 ret = put_packet(nut, bc, dyn_bc, prelude, prelude_size, 
INFO_STARTCODE);
 if (ret < 0)
@@ -719,6 +719,7 @@ static int nut_write_header(AVFormatContext *s)
 nut->chapter = av_calloc(s->nb_chapters, sizeof(*nut->chapter));
 if (!nut->chapter)
 return AVERROR(ENOMEM);
+nut->nb_chapters = s->nb_chapters;
 }
 
 for (i = 0; i < s->nb_streams; i++) {
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 01/10] libavformat/nutenc: Remove redundant function parameter

[Michael Niedermayer]

On Mon, May 04, 2020 at 08:22:41PM +0200, Andreas Rheinhardt wrote:
> calculate_checksum in put_packet() is always 1.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/nutenc.c | 25 +++--
>  1 file changed, 11 insertions(+), 14 deletions(-)

probably ok

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 02/10] avformat/nutenc: Reuse dynamic buffers when possible

[Michael Niedermayer]

On Mon, May 04, 2020 at 08:22:42PM +0200, Andreas Rheinhardt wrote:
> NUT uses variable-length integers in order to for length fields.
> Therefore the NUT muxer often writes data into a dynamic buffer in order
> to get the length of it, then writes the length field using the fewest
> amount of bytes needed. To do this, a new dynamic buffer was opened,
> used and freed for each element which involves lots of allocations. This
> commit changes this: The dynamic buffers are now resetted and reused.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/nutenc.c | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)

probably ok

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 03/10] avformat/nutenc: Add goto fail in nut_write_headers()

[Michael Niedermayer]

On Mon, May 04, 2020 at 08:22:43PM +0200, Andreas Rheinhardt wrote:
> It allows to combine several ffio_free_dyn_buf().

LGTM

thx

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 04/10] avformat/aviobuf, nutenc: Move ff_puv_v, ff_get_v_length to nutenc.c

[Michael Niedermayer]

On Mon, May 04, 2020 at 08:22:44PM +0200, Andreas Rheinhardt wrote:
> and make it static again.
> 
> These functions have been moved from nutenc to aviobuf and internal.h
> in f8280ff4c00eeaa245085fa9691035203abd168c in order to use them in a
> forthcoming patch in utils.c. Said patch never happened, so this commit
> moves them back and makes them static, effectively reverting said
> commit as well as f8280ff4c00eeaa245085fa9691035203abd168c (which added
> the ff-prefix to these functions).
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/aviobuf.c  |  20 -
>  libavformat/internal.h |  10 ---
>  libavformat/nutenc.c   | 172 -
>  3 files changed, 99 insertions(+), 103 deletions(-)

probably ok

thx

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 09/10] avformat/nutenc: Write size into right dynamic buffer

[Michael Niedermayer]

On Tue, May 05, 2020 at 03:31:27PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, May 04, 2020 at 08:22:49PM +0200, Andreas Rheinhardt wrote:
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >>  libavformat/nutenc.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> >> index 5735055d19..6df7dfe210 100644
> >> --- a/libavformat/nutenc.c
> >> +++ b/libavformat/nutenc.c
> >> @@ -902,7 +902,7 @@ static int write_sm_data(AVFormatContext *s, 
> >> AVIOContext *bc, AVPacket *pkt, int
> >>  put_str(dyn_bc, "ChannelLayout");
> >>  put_s(dyn_bc, -2);
> >>  put_str(dyn_bc, "u64");
> >> -put_v(bc, 8);
> >> +put_v(dyn_bc, 8);
> >>  avio_write(dyn_bc, data, 8); data+=8;
> >>  sm_data_count++;
> >>  }
> > 
> > muxer/encoder fixes should bump LIBAVFORMAT_VERSION_MICRO so the
> > issue can be dectected unambigously on the demuxer side
> > 
> > thx
> > 
> > [...]
> 
> Added locally. Is the patch then ready to merge (it can be applied
> independently of the rest) or not?

probably ok

thx

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 07/10] avformat/nutenc: Check allocations implicit in dynamic buffers

[Michael Niedermayer]

On Mon, May 04, 2020 at 08:22:47PM +0200, Andreas Rheinhardt wrote:
> For nut_write_trailer() this includes actually returning such errors.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/nutenc.c | 33 -
>  1 file changed, 24 insertions(+), 9 deletions(-)

should be ok

thx

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 09/10] avformat/nutenc: Write size into right dynamic buffer

[Andreas Rheinhardt]

Michael Niedermayer:
> On Mon, May 04, 2020 at 08:22:49PM +0200, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/nutenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
>> index 5735055d19..6df7dfe210 100644
>> --- a/libavformat/nutenc.c
>> +++ b/libavformat/nutenc.c
>> @@ -902,7 +902,7 @@ static int write_sm_data(AVFormatContext *s, AVIOContext 
>> *bc, AVPacket *pkt, int
>>  put_str(dyn_bc, "ChannelLayout");
>>  put_s(dyn_bc, -2);
>>  put_str(dyn_bc, "u64");
>> -put_v(bc, 8);
>> +put_v(dyn_bc, 8);
>>  avio_write(dyn_bc, data, 8); data+=8;
>>  sm_data_count++;
>>  }
> 
> muxer/encoder fixes should bump LIBAVFORMAT_VERSION_MICRO so the
> issue can be dectected unambigously on the demuxer side
> 
> thx
> 
> [...]

Added locally. Is the patch then ready to merge (it can be applied
independently of the rest) or not?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 09/10] avformat/nutenc: Write size into right dynamic buffer

[Michael Niedermayer]

On Mon, May 04, 2020 at 08:22:49PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/nutenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> index 5735055d19..6df7dfe210 100644
> --- a/libavformat/nutenc.c
> +++ b/libavformat/nutenc.c
> @@ -902,7 +902,7 @@ static int write_sm_data(AVFormatContext *s, AVIOContext 
> *bc, AVPacket *pkt, int
>  put_str(dyn_bc, "ChannelLayout");
>  put_s(dyn_bc, -2);
>  put_str(dyn_bc, "u64");
> -put_v(bc, 8);
> +put_v(dyn_bc, 8);
>  avio_write(dyn_bc, data, 8); data+=8;
>  sm_data_count++;
>  }

muxer/encoder fixes should bump LIBAVFORMAT_VERSION_MICRO so the
issue can be dectected unambigously on the demuxer side

thx

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

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add myself to libopenh264enc

[Fu, Linjie]

> From: Fu, Linjie 
> Sent: Thursday, April 30, 2020 09:13
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH] MAINTAINERS: Add myself to libopenh264enc
> 
> Reviewed-by: Martin Storsjö 
> Signed-off-by: Linjie Fu 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 06956f8..96654f1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -194,6 +194,7 @@ Codecs:
>libdavs2.cHuiwen Ren
>libgsm.c  Michel Bardiaux
>libkvazaar.c  Arttu Ylä-Outinen
> +  libopenh264enc.c  Martin Storsjo, Linjie Fu
>libopenjpeg.c Jaikrishnan Menon
>libopenjpegenc.c  Michael Bradshaw
>libtheoraenc.cDavid Conrad
> --
> 2.7.4
Ping, pls help to comment.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/bsf: add an Opus metadata bitstream filter

[Lynne]

May 3, 2020, 21:21 by d...@lynne.ee:

> The only adjustable field is the gain. Some ripping/transcoding programs 
> have started to use it for replaygain adjustments.
>
> Patch attached.
>

Planning to push this tonight if there are no objections.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Andreas Rheinhardt]

Marton Balint:
> 
> 
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
> 
>> Marton Balint:
>>> Previously only 1:1 bitstream filters were supported, the end of the
>>> stream was
>>> not signalled to the bitstream filters and time base changes were
>>> ignored.
>>>
>>> This change also allows muxers to set up bitstream filters regardless
>>> of the
>>> autobsf flag during write_header instead of during check_bitstream
>>> and those
>>> bitstream filters will always be executed.
>>
>> Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
>> when the user explicitly didn't want this.
>>
> 
> The user should not be allowed to create broken files, and the only way
> to achieve that is to force the BSF. I don't see a use case for
> disabling BSF either for MXFenc of GXFenc. (in fact, from the top of my
> head I can't see a use case for disabling automatically inserted BSF-s
> in other muxers).
> 
When automatic bitstream filtering was introduced in
1f9139b07b8a896b62c1f28f3d04acac33978c0d, writing the header of every
muxer that potentially might include a bsf automatically (as indicated
by the existence of the check_bitstream()-function) was delayed until
the first packet would be written. This meant that there was a high
probability of having a packet for the relevant stream when using the
interleaved codepath.
In particular, this meant that the Matroska muxer now received proper
extradata for AAC when writing the header even before it received any
packet with side data containing potential extradata at all. The reason
was that the aac_adtstoasc bsf has simply overwritten the output
extradata when dealing with the first packet (that was the old bsf API
without init functions; when the new bsf API was merged, the merge
commit (not the original commit) propagated the API violating behaviour).
1f6d7eb47070afc4394348721cd149f940ad2386 added the autobsf flag because
of this delay: After all, the delay existed as soon as the
AVOutputFormat had a check_bitstream function, even when no stream had a
codec for which the check_bitstream function would add a bsf at all.

As time passed, the API-violating behaviour of aac_adtstoasc was fixed
and d6d605eb05c3ca32f591016c345eb2ad9e81c554 stopped delaying writing
the header. The very same patchset containing said commit also contained
a patch to deprecate AVFMT_FLAG_AUTO_BSF [1]. It was not applied due to
concerns what happens when the bsf is not available.

(For the record, ff_stream_add_bitstream_filter() will error out if a
bsf is not available and the packet discarded. If the caller sends
another packet for this stream and a bsf that should be added isn't
available the packet will be rejected as well and so on.)

The fact that one is forced to include certain automatically inserted
bitstream filters even when one knows that one will only use them in
scenarios where they merely passthrough the packets is certainly a
downside of eliminating this flag. But now that I have reread the
history I am nevertheless in favour of deprecation.

- Andreas

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220993.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavutil: add clean aperture (CLAP) side data.

[Kieran O Leary]

Hi,

I broke the threading with my last reply, i apologise. Here goes another
attempt:

On Tue, Apr 28, 2020 at 6:23 PM Neil Birkbeck 
wrote:

> On Tue, Apr 28, 2020 at 3:18 AM Nicolas George  wrote:
>
> > Andreas Rheinhardt (12020-04-28):
> > > That's expected. The patch provided only provides the structure in
> which
> > > the values are intended to be exported; it does not add any demuxing or
> > > muxing capabilities for mov or mkv (as you can see from the fact that
> > > none of these (de)muxers have been changed in the patch).
> >
> > Which is something I intended to comment on: adding code without users
> > is rarely a good idea. I suggest we do not commit until at least one
> > demuxer use it, preferably at least two. Otherwise, we may realize that
> > “oh crap, it doesn't work” because of a tiny unforeseen detail.
>
>
> Thanks for the feedback. I also have patches for the demux (MOV/MKV) and
> mux (MOV/MKV).
>
> As there is still the alternative of using the fields in the
> AVCodecParameters/AVCodecContext, my intention was to keep the first patch
> small to resolve discussion on that point.
>
> I've included the patches, if you'd like to try test it, Kieren. I see on
> your test file that there may be some slight rounding error making output
> crop 704 not 703 (MKV file ends up with pixel_crop_{left,right} = 8).
>
> /ffprobe ../testdata/clap.mov 2>&1 | grep -A1 "Side"
> Side data:
>   Clean aperture:[width 41472/59 height:576/1 h_offset:0/1
> v_offset:0/1]
> ./ffmpeg -i ../testdata/clap.mov  -vcodec copy -acodec copy /tmp/clap.mkv
> ./ffprobe /tmp/clap.mkv 2>&1 | grep -A1 "Side"
> Side data:
>   Clean aperture:[width 704/1 height:576/1 h_offset:0/1 v_offset:0/1]
>

I have to look deeper into the MKV side of things and most likely raise it
with the cellar mailing list so that better minds than mine can weigh in. I
do see that the rounding up to 704 could be an issue alright.
As for MOV, your patch appears to generate the same output clap values as
the input, so that's really great! command line and mediainfo trace below:
$ ./ffmpeg -i /mnt/c/Users/blaaa/Downloads/clap.mov -c:v v210 newv210.mov
&& mediainfo --Details=1 newv210.mov |grep -i clap -n10
ffmpeg version N-97506-g2fae000994 Copyright (c) 2000-2020 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration:
  libavutil  56. 43.100 / 56. 43.100
  libavcodec 58. 82.100 / 58. 82.100
  libavformat58. 42.101 / 58. 42.101
  libavdevice58.  9.103 / 58.  9.103
  libavfilter 7. 79.100 /  7. 79.100
  libswscale  5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/mnt/c/Users/blaaa/Downloads/clap.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
creation_time   : 2018-09-13T08:48:41.00Z
  Duration: 00:00:01.00, start: 0.00, bitrate: 80686 kb/s
Stream #0:0(eng): Video: v210 (v210 / 0x30313276),
yuv422p10le(smpte170m/bt470bg/bt709, top coded first (swapped)), 720x576,
79626 kb/s, SAR 59:54 DAR 295:216, 9 fps, 25 tbr, 25k tbn, 25k tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  encoder : Uncompressed 10-Bit YUV
  timecode: 00:00:00:00
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz,
stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: Time Code Media Handler
  reel_name   : 001
  timecode: 00:00:00:00
File 'newv210.mov' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:1 -> #0:1 (pcm_s24le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'newv210.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
encoder : Lavf58.42.101
Stream #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(top
coded first (swapped)), 720x576 [SAR 59:54 DAR 295:216], q=2-31, 221184
kb/s, 0.04 fps, 12800 tbn, 25 tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 v210
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz,
stereo, fltp (24 bit), 128 kb/s (default)
Metadata:
  

[FFmpeg-devel] Reporting bugs

[Nico Coesel]

Hello all,
I want to report a bug in the jpeg encoding but I can't seem to register 
to trac.


Is there a special trick to it?

Regards,
N. Coesel

--
o---o
|   N C T  Developments |
|Innovative embedded solutions  |
o---o

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavutil: add clean aperture (CLAP) side data.

[Kieran O Leary]

Hi Neil,

I have to look deeper into the MKV side of things and most likely raise it
with the cellar mailing list so that better minds than mine can weigh in. I
do see that the rounding up to 704 could be an issue alright.
As for MOV, your patch appears to generate the same output clap values as
the input, so that's really great! command line and mediainfo trace below:
$ ./ffmpeg -i /mnt/c/Users/blaaa/Downloads/clap.mov -c:v v210 newv210.mov
&& mediainfo --Details=1 newv210.mov |grep -i clap -n10
ffmpeg version N-97506-g2fae000994 Copyright (c) 2000-2020 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration:
  libavutil  56. 43.100 / 56. 43.100
  libavcodec 58. 82.100 / 58. 82.100
  libavformat58. 42.101 / 58. 42.101
  libavdevice58.  9.103 / 58.  9.103
  libavfilter 7. 79.100 /  7. 79.100
  libswscale  5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/mnt/c/Users/blaaa/Downloads/clap.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
creation_time   : 2018-09-13T08:48:41.00Z
  Duration: 00:00:01.00, start: 0.00, bitrate: 80686 kb/s
Stream #0:0(eng): Video: v210 (v210 / 0x30313276),
yuv422p10le(smpte170m/bt470bg/bt709, top coded first (swapped)), 720x576,
79626 kb/s, SAR 59:54 DAR 295:216, 9 fps, 25 tbr, 25k tbn, 25k tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  encoder : Uncompressed 10-Bit YUV
  timecode: 00:00:00:00
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz,
stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: Time Code Media Handler
  reel_name   : 001
  timecode: 00:00:00:00
File 'newv210.mov' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:1 -> #0:1 (pcm_s24le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'newv210.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
encoder : Lavf58.42.101
Stream #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(top
coded first (swapped)), 720x576 [SAR 59:54 DAR 295:216], q=2-31, 221184
kb/s, 0.04 fps, 12800 tbn, 25 tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 v210
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz,
stereo, fltp (24 bit), 128 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 aac
frame=   25 fps=0.0 q=-0.0 Lsize=   27009kB time=00:00:00.96
bitrate=230455.2kbits/s dup=16 drop=0 speed=19.8x
video:27000kB audio:6kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.008794%
[aac @ 0x7fffe91cc680] Qavg: 171.537
226-1A5FBA4 detail: 9 (0x09)
227-1A5FBA5Pixel Aspect Ratio (16 bytes)
228-1A5FBA5 Header (8 bytes)
229-1A5FBA5  Size:  16 (0x0010)
230-1A5FBA9  Name:  pasp
231-1A5FBAD hSpacing:   59 (0x003B)
232-1A5FBB1 vSpacing:   54 (0x0036)
233-1A5FBB5Clean Aperture (40 bytes)
234-1A5FBB5 Header (8 bytes)
235-1A5FBB5  Size:  40 (0x0028)
236:1A5FBB9  Name:  clap
237-1A5FBBD apertureWidth_N:41472 (0xA200)
238-1A5FBC1 apertureWidth_D:59 (0x003B)
239-1A5FBC5 apertureHeight_N:   576 (0x0240)
240-1A5FBC9 apertureHeight_D:   1 (0x0001)
241-1A5FBCD horizOff_N: 0 (0x)
242-1A5FBD1 horizOff_D: 1 (0x0001)
243-1A5FBD5 vertOff_N:  0 (0x)
244-1A5FBD9 vertOff_D:  1 (0x0001)
245-1A5FBDD  Time to Sample (24 bytes)
246-1A5FBDD   Header (8 bytes)


and here's similar info for mkv:

 ./ffmpeg -i 

Re: [FFmpeg-devel] [PATCH] lavc/bsf: add an Opus metadata bitstream filter

[Nicolas George]

Andreas Rheinhardt (12020-05-05):
> > +static const AVOption opus_metadata_options[] = {
> > +{ "gain", "Gain, actual amplification is pow(10, gain/(20.0*256))", 
> > OFFSET(gain),
> > +  AV_OPT_TYPE_INT, { .i64 = 0 }, -(INT16_MAX + 1), INT16_MAX, .flags = 
> > FLAGS },
> > +
> > +{ NULL },
> > +};
> 
> You are using an AV_OPT_TYPE_INT parameter, yet the actual type of the
> destination is int64_t. This won't work on big endian systems. Make gain
> an int.

Or make it a float and multiply it by 256 or 5120 before giving it to
libopus, possibly.

Regards,

-- 
  Nicolas George


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/bsf: add an Opus metadata bitstream filter

[Andreas Rheinhardt]

Lynne:
> The only adjustable field is the gain. Some ripping/transcoding programs 
> have started to use it for replaygain adjustments.
> 
> Patch attached.
> 
> >
> +typedef struct OpusBSFContext {
> +const AVClass *class;
> +int64_t gain;
> +} OpusBSFContext;
[...]
> 
> +static const AVOption opus_metadata_options[] = {
> +{ "gain", "Gain, actual amplification is pow(10, gain/(20.0*256))", 
> OFFSET(gain),
> +  AV_OPT_TYPE_INT, { .i64 = 0 }, -(INT16_MAX + 1), INT16_MAX, .flags = 
> FLAGS },
> +
> +{ NULL },
> +};

You are using an AV_OPT_TYPE_INT parameter, yet the actual type of the
destination is int64_t. This won't work on big endian systems. Make gain
an int.

- Andreas

PS: Do we actually support two's complement architectures were
-(INT16_MAX + 1) != INT16_MIN? (A two's complement architecture in which
the representation where the sign bit is set and all other bits is unset
is trap representation is legal according to the C standard. Does
someone know whether it would also be legal according to POSIX?)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] Patch set to delay output live stream

[Andreas Rheinhardt]

Marton Balint:
> 
> 
> On Tue, 5 May 2020, Tao Zhang wrote:
> 
>> Marton Balint  于2020年5月5日周二 上午3:48写道：
>>>
>>>
>>>
>>> On Sat, 2 May 2020, Tao Zhang wrote:
>>>
>>> > Marton Balint  于2020年5月2日周六 下午7:05写道：
>>>
>>> [...]
>>>
>>> >> I see. But you could add an option to the fifo muxer to only write
>>> header
>>> >> when the first packet arrives. This way you will be able to use a
>>> >> bitstream filter to buffer packets and the fifo muxer will only write
>>> >> header when the first packet passes through the bitstream filter.
>>> Does
>>> >> this seem OK?
>>> > It seems OK. If nobody object it, I'm glad to add
>>> > write_header_on_first_packet option on fifo muxer and create a new
>>> > bitstream filter which buffers fixed duration packets.
>>>
>>> Great. I suggest a shorter name for the option of the fifo muxer,
>>> delay_write_header I think is enough, you can explain the details in the
>>> docs.
>> Great suggestion. I'll follow it.
>>>
>>> Also it should be pretty straightforward to add this feature to fifo.c,
>>> from a quick look at the code one approach is to add a NOOP message
>>> type,
>>> and if the option is set, then use that message type for the first
>>> message, if it is not set, use the WRITE_HEADER message type, as it is
>>> used now.
>>>
>>> Also we should find a good name for the bitstream filter, maybe
>>> "buffer",
>>> or "fifo", or if you want to better refer to the use case, then
>>> "timeshift" can also work.
>> Maybe "caching" or "cache"?
>>>
>>> Another thing you should think about is what should happen at the end of
>>> the stream, when flushing the bitstream filter:
>>> - drop pending packets
>>> - flush pending packets as fast as possible
>>> - flush pendning packets realtime
>>> Maybe it should be selectable between the 3 options? I can imagine use
>>> cases for all three possibilities.
>> Although I have not imagined the first and second use cases, I'm glad
>> to implement all three.
> 
> I have given the bitstream filter approach some additional thought and
> since each stream will have a different bitstream filter I think you
> will have problems when flushing them in ffmpeg.c because it will flush
> them sequentially, the packet interleaving will be something like
> - all remaining packets from the first stream
> - all remaining packets from the second stream

Maybe the custom interleavement functions should be split into one that
does the "add packet to packet list" part and another one for "return
packet from packet list"? This would allow to drain all the bsfs and to
add all packets to the interleavement queue, before starting to output them.
(This proposal would increase sizeof(AVOutputFormat) and would therefore
cause problems when one uses a new libavformat together with an old
libavdevice (despite no libavdevice muxer using custom interleavement
functions). This could be solved by using a hack: We put the add packet
function in place of the old interleave_packet() function and only ever
check for the existence of the get_packet() function if the add_packet()
function pointer is not NULL.)

- Andreas

PS: Nothing said above is intended to block your other patchset in any
way. I just wanted to mention it because the current interleave_packet()
functions are already naturally split into two independent parts.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] Patch set to delay output live stream

[Marton Balint]

On Tue, 5 May 2020, Tao Zhang wrote:


Marton Balint  于2020年5月5日周二 上午3:48写道：




On Sat, 2 May 2020, Tao Zhang wrote:

> Marton Balint  于2020年5月2日周六 下午7:05写道：

[...]

>> I see. But you could add an option to the fifo muxer to only write header
>> when the first packet arrives. This way you will be able to use a
>> bitstream filter to buffer packets and the fifo muxer will only write
>> header when the first packet passes through the bitstream filter. Does
>> this seem OK?
> It seems OK. If nobody object it, I'm glad to add
> write_header_on_first_packet option on fifo muxer and create a new
> bitstream filter which buffers fixed duration packets.

Great. I suggest a shorter name for the option of the fifo muxer,
delay_write_header I think is enough, you can explain the details in the
docs.

Great suggestion. I'll follow it.


Also it should be pretty straightforward to add this feature to fifo.c,
from a quick look at the code one approach is to add a NOOP message type,
and if the option is set, then use that message type for the first
message, if it is not set, use the WRITE_HEADER message type, as it is
used now.

Also we should find a good name for the bitstream filter, maybe "buffer",
or "fifo", or if you want to better refer to the use case, then
"timeshift" can also work.

Maybe "caching" or "cache"?


Another thing you should think about is what should happen at the end of
the stream, when flushing the bitstream filter:
- drop pending packets
- flush pending packets as fast as possible
- flush pendning packets realtime
Maybe it should be selectable between the 3 options? I can imagine use
cases for all three possibilities.

Although I have not imagined the first and second use cases, I'm glad
to implement all three.


I have given the bitstream filter approach some additional thought and 
since each stream will have a different bitstream filter I think you will 
have problems when flushing them in ffmpeg.c because it will flush them 
sequentially, the packet interleaving will be something like

- all remaining packets from the first stream
- all remaining packets from the second stream
... etc.

Which will cause issues at muxing the last part of the stream if the 
buffer duration is larger than a few seconds.


Sorry, it looks like hacking the whole thing into fifo.c works the best 
after all. The only problem is that I don't see a clean way of doing that 
if you only want to enforce realtiem output there when flushing the 
buffered packets...


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Andreas Rheinhardt]

Marton Balint:
> 
> 
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
> 
>> Marton Balint:
>>>
>>>
>>> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>>>
 Marton Balint:
>
>
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>
>> Marton Balint:
>>> Previously only 1:1 bitstream filters were supported, the end of the
>>> stream was
>>> not signalled to the bitstream filters and time base changes were
>>> ignored.
>>>
>>> This change also allows muxers to set up bitstream filters
>>> regardless
>>> of the
>>> autobsf flag during write_header instead of during check_bitstream
>>> and those
>>> bitstream filters will always be executed.
>>
>> Ignoring the autobsf flag is not ok IMO. The muxer should not add
>> a bsf
>> when the user explicitly didn't want this.
>>
>
> The user should not be allowed to create broken files, and the only
> way
> to achieve that is to force the BSF.

 No, one could also check in the muxer that the packets are ok (these
 checks could be disabled if the bsf is enabled, of course) and error
 out
 if it is not.
>>>
>>> And that would duplicate some functionaltiy for negigable performance
>>> gain of not always doing a BSF.
>>>

> I don't see a use case for
> disabling BSF either for MXFenc of GXFenc. (in fact, from the top
> of my
> head I can't see a use case for disabling automatically inserted BSF-s
> in other muxers).
>
 A user who already knows that his packets are ok can do so to avoid the
 (admittedly small) overhead of these bsfs. (And even if you think that
 the option should be removed/should be made non-public (for internal
 testing only), then this does not change that this option exists and
 removing it would require the usual deprecation period (and consensus
 from other devs, of course; I personally don't have formed an opinion
 about this yet).)
>>>
>>> With my patch the autobsf option is still honored for all existing
>>> bitstream filters which are inserted mid-stream (in check_bitstream).
>>> Only the ones which are inserted at write_header(), so in mxfenc and
>>> gxfenc are forced.
>>>
 One use-case is if a user runs the pcm_rechunk bsf filter manually and
 then sends the output to both a framecrc as well as the mxf muxers in
 order to be able to test more thoroughly whether any write errors
 happened. Or where you want to write the same audio to multiple mxf
 muxers, all with the same audio settings.
>>>
>>> And for them the additional BSF which is auto inserted will only pass on
>>> their packets, it will only *check* for correct packets, exactly what
>>> you suggested. I cannot accept the performance gain as argument.
>>>

> So if you feel strongly about this and we still want to avoid creating
> corrupt files then the BSFs should be processed in mxf_interleave and
> gxf_interleave separately from the auto inserted bitstream filters. Do
> you think that is better? I don't think so.
>
 That would just be a worse form of automatically inserted bsf (and it
 would not work for av_write_frame()).
>>>
>>> Please suggest something reasonable to follow up on this.
>>>
>> How about: You error out in write_header if there is an audio track and
>> the user does not want automatically inserted bitstream filters?
> 
> Then maybe better to do it ff_stream_add_bitstream_filter?
> 
Yeah, that sounds like the right place for this.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Marton Balint]

On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:



On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:



On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:

Previously only 1:1 bitstream filters were supported, the end of the
stream was
not signalled to the bitstream filters and time base changes were
ignored.

This change also allows muxers to set up bitstream filters regardless
of the
autobsf flag during write_header instead of during check_bitstream
and those
bitstream filters will always be executed.


Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
when the user explicitly didn't want this.



The user should not be allowed to create broken files, and the only way
to achieve that is to force the BSF.


No, one could also check in the muxer that the packets are ok (these
checks could be disabled if the bsf is enabled, of course) and error out
if it is not.


And that would duplicate some functionaltiy for negigable performance
gain of not always doing a BSF.




I don't see a use case for
disabling BSF either for MXFenc of GXFenc. (in fact, from the top of my
head I can't see a use case for disabling automatically inserted BSF-s
in other muxers).


A user who already knows that his packets are ok can do so to avoid the
(admittedly small) overhead of these bsfs. (And even if you think that
the option should be removed/should be made non-public (for internal
testing only), then this does not change that this option exists and
removing it would require the usual deprecation period (and consensus
from other devs, of course; I personally don't have formed an opinion
about this yet).)


With my patch the autobsf option is still honored for all existing
bitstream filters which are inserted mid-stream (in check_bitstream).
Only the ones which are inserted at write_header(), so in mxfenc and
gxfenc are forced.


One use-case is if a user runs the pcm_rechunk bsf filter manually and
then sends the output to both a framecrc as well as the mxf muxers in
order to be able to test more thoroughly whether any write errors
happened. Or where you want to write the same audio to multiple mxf
muxers, all with the same audio settings.


And for them the additional BSF which is auto inserted will only pass on
their packets, it will only *check* for correct packets, exactly what
you suggested. I cannot accept the performance gain as argument.




So if you feel strongly about this and we still want to avoid creating
corrupt files then the BSFs should be processed in mxf_interleave and
gxf_interleave separately from the auto inserted bitstream filters. Do
you think that is better? I don't think so.


That would just be a worse form of automatically inserted bsf (and it
would not work for av_write_frame()).


Please suggest something reasonable to follow up on this.


How about: You error out in write_header if there is an audio track and
the user does not want automatically inserted bitstream filters?


Then maybe better to do it ff_stream_add_bitstream_filter?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Andreas Rheinhardt]

Marton Balint:
> 
> 
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
> 
>> Marton Balint:
>>>
>>>
>>> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>>>
 Marton Balint:
> Previously only 1:1 bitstream filters were supported, the end of the
> stream was
> not signalled to the bitstream filters and time base changes were
> ignored.
>
> This change also allows muxers to set up bitstream filters regardless
> of the
> autobsf flag during write_header instead of during check_bitstream
> and those
> bitstream filters will always be executed.

 Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
 when the user explicitly didn't want this.

>>>
>>> The user should not be allowed to create broken files, and the only way
>>> to achieve that is to force the BSF.
>>
>> No, one could also check in the muxer that the packets are ok (these
>> checks could be disabled if the bsf is enabled, of course) and error out
>> if it is not.
> 
> And that would duplicate some functionaltiy for negigable performance
> gain of not always doing a BSF.
> 
>>
>>> I don't see a use case for
>>> disabling BSF either for MXFenc of GXFenc. (in fact, from the top of my
>>> head I can't see a use case for disabling automatically inserted BSF-s
>>> in other muxers).
>>>
>> A user who already knows that his packets are ok can do so to avoid the
>> (admittedly small) overhead of these bsfs. (And even if you think that
>> the option should be removed/should be made non-public (for internal
>> testing only), then this does not change that this option exists and
>> removing it would require the usual deprecation period (and consensus
>> from other devs, of course; I personally don't have formed an opinion
>> about this yet).)
> 
> With my patch the autobsf option is still honored for all existing
> bitstream filters which are inserted mid-stream (in check_bitstream).
> Only the ones which are inserted at write_header(), so in mxfenc and
> gxfenc are forced.
> 
>> One use-case is if a user runs the pcm_rechunk bsf filter manually and
>> then sends the output to both a framecrc as well as the mxf muxers in
>> order to be able to test more thoroughly whether any write errors
>> happened. Or where you want to write the same audio to multiple mxf
>> muxers, all with the same audio settings.
> 
> And for them the additional BSF which is auto inserted will only pass on
> their packets, it will only *check* for correct packets, exactly what
> you suggested. I cannot accept the performance gain as argument.
> 
>>
>>> So if you feel strongly about this and we still want to avoid creating
>>> corrupt files then the BSFs should be processed in mxf_interleave and
>>> gxf_interleave separately from the auto inserted bitstream filters. Do
>>> you think that is better? I don't think so.
>>>
>> That would just be a worse form of automatically inserted bsf (and it
>> would not work for av_write_frame()).
> 
> Please suggest something reasonable to follow up on this.
> 
How about: You error out in write_header if there is an audio track and
the user does not want automatically inserted bitstream filters?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Marton Balint]

On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:



On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:

Previously only 1:1 bitstream filters were supported, the end of the
stream was
not signalled to the bitstream filters and time base changes were
ignored.

This change also allows muxers to set up bitstream filters regardless
of the
autobsf flag during write_header instead of during check_bitstream
and those
bitstream filters will always be executed.


Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
when the user explicitly didn't want this.



The user should not be allowed to create broken files, and the only way
to achieve that is to force the BSF.


No, one could also check in the muxer that the packets are ok (these
checks could be disabled if the bsf is enabled, of course) and error out
if it is not.


And that would duplicate some functionaltiy for negigable performance 
gain of not always doing a BSF.





I don't see a use case for
disabling BSF either for MXFenc of GXFenc. (in fact, from the top of my
head I can't see a use case for disabling automatically inserted BSF-s
in other muxers).


A user who already knows that his packets are ok can do so to avoid the
(admittedly small) overhead of these bsfs. (And even if you think that
the option should be removed/should be made non-public (for internal
testing only), then this does not change that this option exists and
removing it would require the usual deprecation period (and consensus
from other devs, of course; I personally don't have formed an opinion
about this yet).)


With my patch the autobsf option is still honored for all existing 
bitstream filters which are inserted mid-stream (in check_bitstream). Only 
the ones which are inserted at write_header(), so in mxfenc and gxfenc are 
forced.



One use-case is if a user runs the pcm_rechunk bsf filter manually and
then sends the output to both a framecrc as well as the mxf muxers in
order to be able to test more thoroughly whether any write errors
happened. Or where you want to write the same audio to multiple mxf
muxers, all with the same audio settings.


And for them the additional BSF which is auto inserted will only pass on 
their packets, it will only *check* for correct packets, exactly what you 
suggested. I cannot accept the performance gain as argument.





So if you feel strongly about this and we still want to avoid creating
corrupt files then the BSFs should be processed in mxf_interleave and
gxf_interleave separately from the auto inserted bitstream filters. Do
you think that is better? I don't think so.


That would just be a worse form of automatically inserted bsf (and it
would not work for av_write_frame()).


Please suggest something reasonable to follow up on this.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Andreas Rheinhardt]

Marton Balint:
> 
> 
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
> 
>> Marton Balint:
>>> Previously only 1:1 bitstream filters were supported, the end of the
>>> stream was
>>> not signalled to the bitstream filters and time base changes were
>>> ignored.
>>>
>>> This change also allows muxers to set up bitstream filters regardless
>>> of the
>>> autobsf flag during write_header instead of during check_bitstream
>>> and those
>>> bitstream filters will always be executed.
>>
>> Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
>> when the user explicitly didn't want this.
>>
> 
> The user should not be allowed to create broken files, and the only way
> to achieve that is to force the BSF.

No, one could also check in the muxer that the packets are ok (these
checks could be disabled if the bsf is enabled, of course) and error out
if it is not.

> I don't see a use case for
> disabling BSF either for MXFenc of GXFenc. (in fact, from the top of my
> head I can't see a use case for disabling automatically inserted BSF-s
> in other muxers).
> 
A user who already knows that his packets are ok can do so to avoid the
(admittedly small) overhead of these bsfs. (And even if you think that
the option should be removed/should be made non-public (for internal
testing only), then this does not change that this option exists and
removing it would require the usual deprecation period (and consensus
from other devs, of course; I personally don't have formed an opinion
about this yet).)
One use-case is if a user runs the pcm_rechunk bsf filter manually and
then sends the output to both a framecrc as well as the mxf muxers in
order to be able to test more thoroughly whether any write errors
happened. Or where you want to write the same audio to multiple mxf
muxers, all with the same audio settings.

> So if you feel strongly about this and we still want to avoid creating
> corrupt files then the BSFs should be processed in mxf_interleave and
> gxf_interleave separately from the auto inserted bitstream filters. Do
> you think that is better? I don't think so.
> 
That would just be a worse form of automatically inserted bsf (and it
would not work for av_write_frame()).

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 5/8] avcodec/pcm_rechunk_bsf: add bitstream filter to rechunk pcm audio

[Marton Balint]

On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:

Signed-off-by: Marton Balint 
---
 Changelog  |   1 +
 doc/bitstream_filters.texi |  30 ++
 libavcodec/Makefile|   1 +
 libavcodec/bitstream_filters.c |   1 +
 libavcodec/pcm_rechunk_bsf.c   | 220 +
 libavcodec/version.h   |   2 +-
 6 files changed, 254 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/pcm_rechunk_bsf.c



[...]


+++ b/doc/bitstream_filters.texi
@@ -548,6 +548,36 @@ ffmpeg -i INPUT -c copy -bsf noise[=1] output.mkv
 @section null
 This bitstream filter passes the packets through unchanged.

+@section pcm_rechunk
+
+Repacketize PCM audio to a fixed number of samples per packet or a fixed packet
+rate per second. This is similar to the @ref{asetnsamples,,asetnsamples audio
+filter,ffmpeg-filters} but works on audio packets instead of audio frames.
+
+@table @option
+@item nb_out_samples, n
+Set the number of samples per each output audio packet. The number is intended
+as the number of samples @emph{per each channel}. Default value is 1024.
+
+@item pad, p
+If set to 1, the filter will pad the last audio packet with silence, so that it
+will contain the same number of samples (or roughly the same number of samples,
+see @option{frame_rate}) as the previous ones. Default value is 1.
+
+@item frame_rate, r
+This option makes the filter output a fixed numer of packets per second instead


numer


Fixed locally.

[...]


+} else if (s->in_pkt->size > data_size) {
+ret = av_packet_ref(pkt, s->in_pkt);
+if (ret < 0)
+return ret;
+pkt->size = data_size;


I just wonder: Have you tried av_shrink_packet() and found out that it
simply zeroes the data after the end of the packet without any regard to
whether it is writable or not or did you simply just do it the way you
do it here?


I always did it this way.

[...]


--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"

 #define LIBAVCODEC_VERSION_MAJOR  58
-#define LIBAVCODEC_VERSION_MINOR  82
+#define LIBAVCODEC_VERSION_MINOR  83
 #define LIBAVCODEC_VERSION_MICRO 100

 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \


LGTM apart from that.


Thanks,

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Marton Balint]

On Tue, 5 May 2020, Andreas Rheinhardt wrote:


Marton Balint:

Previously only 1:1 bitstream filters were supported, the end of the stream was
not signalled to the bitstream filters and time base changes were ignored.

This change also allows muxers to set up bitstream filters regardless of the
autobsf flag during write_header instead of during check_bitstream and those
bitstream filters will always be executed.


Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
when the user explicitly didn't want this.



The user should not be allowed to create broken files, and the only way to 
achieve that is to force the BSF. I don't see a use case for disabling BSF 
either for MXFenc of GXFenc. (in fact, from the top of my head I can't 
see a use case for disabling automatically inserted BSF-s in other 
muxers).


So if you feel strongly about this and we still want to avoid creating 
corrupt files then the BSFs should be processed in mxf_interleave and 
gxf_interleave separately from the auto inserted bitstream filters. Do you 
think that is better? I don't think so.


Regards,
Marton


- Andreas



Signed-off-by: Marton Balint 
---
 libavformat/mux.c | 87 +++
 1 file changed, 56 insertions(+), 31 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 33aed9da90..d3a98499ce 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1077,8 +1077,8 @@ static int interleave_packet(AVFormatContext *s, AVPacket 
*out, AVPacket *in, in
 return ff_interleave_packet_per_dts(s, out, in, flush);
 }

-static int do_packet_auto_bsf(AVFormatContext *s, AVPacket *pkt) {
-AVStream *st = s->streams[pkt->stream_index];
+static int check_bitstream(AVFormatContext *s, AVStream *st, AVPacket *pkt)
+{
 int ret;

 if (!(s->flags & AVFMT_FLAG_AUTO_BSF))
@@ -1093,30 +1093,6 @@ static int do_packet_auto_bsf(AVFormatContext *s, 
AVPacket *pkt) {
 }
 }

-if (st->internal->bsfc) {
-AVBSFContext *ctx = st->internal->bsfc;
-// TODO: when any bitstream filter requires flushing at EOF, we'll 
need to
-// flush each stream's BSF chain on write_trailer.
-if ((ret = av_bsf_send_packet(ctx, pkt)) < 0) {
-av_log(ctx, AV_LOG_ERROR,
-"Failed to send packet to filter %s for stream %d\n",
-ctx->filter->name, pkt->stream_index);
-return ret;
-}
-// TODO: when any automatically-added bitstream filter is generating 
multiple
-// output packets for a single input one, we'll need to call this in a 
loop
-// and write each output packet.
-if ((ret = av_bsf_receive_packet(ctx, pkt)) < 0) {
-if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
-return 0;
-av_log(ctx, AV_LOG_ERROR,
-"Failed to receive packet from filter %s for stream %d\n",
-ctx->filter->name, pkt->stream_index);
-if (s->error_recognition & AV_EF_EXPLODE)
-return ret;
-return 0;
-}
-}
 return 1;
 }

@@ -1161,17 +1137,53 @@ static int write_packet_common(AVFormatContext *s, 
AVStream *st, AVPacket *pkt,
 }
 }

+static int write_packets_from_bsfs(AVFormatContext *s, AVStream *st, AVPacket 
*pkt, int interleaved)
+{
+AVBSFContext *bsfc = st->internal->bsfc;
+int ret;
+
+if ((ret = av_bsf_send_packet(bsfc, pkt)) < 0) {
+av_log(s, AV_LOG_ERROR,
+"Failed to send packet to filter %s for stream %d\n",
+bsfc->filter->name, st->index);
+return ret;
+}
+
+do {
+ret = av_bsf_receive_packet(bsfc, pkt);
+if (ret < 0) {
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+return 0;
+av_log(s, AV_LOG_ERROR, "Error applying bitstream filters to an output 
"
+   "packet for stream #%d: %s\n", st->index, av_err2str(ret));
+if (!(s->error_recognition & AV_EF_EXPLODE) && ret != 
AVERROR(ENOMEM))
+continue;
+return ret;
+}
+av_packet_rescale_ts(pkt, bsfc->time_base_out, st->time_base);
+ret = write_packet_common(s, st, pkt, interleaved);
+if (ret >= 0 && !interleaved) // a successful write_packet_common 
already unrefed pkt for interleaved
+av_packet_unref(pkt);
+} while (ret >= 0);
+
+return ret;
+}
+
 static int write_packets_common(AVFormatContext *s, AVStream *st, AVPacket 
*pkt, int interleaved)
 {
 int ret = prepare_input_packet(s, pkt);
 if (ret < 0)
 return ret;

-ret = do_packet_auto_bsf(s, pkt);
-if (ret <= 0)
+ret = check_bitstream(s, st, pkt);
+if (ret < 0)
 return ret;

-return write_packet_common(s, st, pkt, interleaved);
+if (st->internal->bsfc) {
+return write_packets_from_bsfs(s, st, pkt, interleaved);
+} else {
+   

Re: [FFmpeg-devel] [PATCH 1/6] avformat/matroskaenc: Move adding SeekEntry into end_ebml_master_crc32()

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Up until now, SeekEntries were already added before
> start_ebml_master_crc32() was even called and before we were actually
> sure that we really write the element the SeekHead references; after
> all, we might also error out later; and given that the allocations
> implicit in dynamic buffers should be checked, end_ebml_master_crc32()
> will eventually have to return errors itself, so that it is the right
> place to add SeekHead entries.
> 
> The earlier behaviour is of course a remnant of the time in which
> start_ebml_master_crc32() really did output something, so that the
> position before start_ebml_master_crc32() needed to be recorded.
> Erroring out later is also not as dangerous as it seems because in
> this case no SeekHead will be written (if it happened when writing
> the header, the whole muxing process would abort; if it happened
> when writing the trailer (when writing chapters not available initially),
> writing the trailer would be aborted and no SeekHead containing the
> bogus chapter entry would be written).
> 
> This commit does not change the way the SeekEntries are added for those
> elements that are output preliminarily; this is so because the SeekHead
> is written before those elements are finally output and doing it
> otherwise would increase the amount of seeks.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/matroskaenc.c | 64 ---
>  1 file changed, 33 insertions(+), 31 deletions(-)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index a1b613290c..b50fd8dd9b 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -349,6 +349,17 @@ static void end_ebml_master(AVIOContext *pb, ebml_master 
> master)
>  avio_seek(pb, pos, SEEK_SET);
>  }
>  
> +static void mkv_add_seekhead_entry(MatroskaMuxContext *mkv, uint32_t 
> elementid,
> +   uint64_t filepos)
> +{
> +mkv_seekhead *seekhead = >seekhead;
> +
> +av_assert1(seekhead->num_entries < MAX_SEEKHEAD_ENTRIES);
> +
> +seekhead->entries[seekhead->num_entries].elementid= elementid;
> +seekhead->entries[seekhead->num_entries++].segmentpos = filepos - 
> mkv->segment_offset;
> +}
> +
>  static int start_ebml_master_crc32(AVIOContext **dyn_cp, MatroskaMuxContext 
> *mkv)
>  {
>  int ret;
> @@ -364,11 +375,15 @@ static int start_ebml_master_crc32(AVIOContext 
> **dyn_cp, MatroskaMuxContext *mkv
>  
>  static void end_ebml_master_crc32(AVIOContext *pb, AVIOContext **dyn_cp,
>MatroskaMuxContext *mkv, uint32_t id,
> -  int length_size, int keep_buffer)
> +  int length_size, int keep_buffer,
> +  int add_seekentry)
>  {
>  uint8_t *buf, crc[4];
>  int size, skip = 0;
>  
> +if (add_seekentry)
> +mkv_add_seekhead_entry(mkv, id, avio_tell(pb));
> +
>  put_ebml_id(pb, id);
>  size = avio_get_dyn_buf(*dyn_cp, );
>  put_ebml_length(pb, size, length_size);
> @@ -441,17 +456,6 @@ static void mkv_start_seekhead(MatroskaMuxContext *mkv, 
> AVIOContext *pb)
>  put_ebml_void(pb, mkv->seekhead.reserved_size);
>  }
>  
> -static void mkv_add_seekhead_entry(MatroskaMuxContext *mkv, uint32_t 
> elementid,
> -   uint64_t filepos)
> -{
> -mkv_seekhead *seekhead = >seekhead;
> -
> -av_assert1(seekhead->num_entries < MAX_SEEKHEAD_ENTRIES);
> -
> -seekhead->entries[seekhead->num_entries].elementid= elementid;
> -seekhead->entries[seekhead->num_entries++].segmentpos = filepos - 
> mkv->segment_offset;
> -}
> -
>  /**
>   * Write the SeekHead to the file at the location reserved for it
>   * and seek to destpos afterwards. When error_on_seek_failure
> @@ -489,7 +493,7 @@ static int mkv_write_seekhead(AVIOContext *pb, 
> MatroskaMuxContext *mkv,
>  put_ebml_uint(dyn_cp, MATROSKA_ID_SEEKPOSITION, entry->segmentpos);
>  end_ebml_master(dyn_cp, seekentry);
>  }
> -end_ebml_master_crc32(pb, _cp, mkv, MATROSKA_ID_SEEKHEAD, 0, 0);
> +end_ebml_master_crc32(pb, _cp, mkv, MATROSKA_ID_SEEKHEAD, 0, 0, 0);
>  
>  remaining = seekhead->filepos + seekhead->reserved_size - avio_tell(pb);
>  put_ebml_void(pb, remaining);
> @@ -1421,7 +1425,8 @@ static int mkv_write_tracks(AVFormatContext *s)
>  end_ebml_master_crc32_preliminary(pb, mkv->tracks_bc,
>MATROSKA_ID_TRACKS, 
> >tracks_pos);
>  else
> -end_ebml_master_crc32(pb, >tracks_bc, mkv, MATROSKA_ID_TRACKS, 
> 0, 0);
> +end_ebml_master_crc32(pb, >tracks_bc, mkv,
> +  MATROSKA_ID_TRACKS, 0, 0, 0);
>  
>  return 0;
>  }
> @@ -1443,8 +1448,6 @@ static int mkv_write_chapters(AVFormatContext *s)
>  break;
>  }
>  
> -mkv_add_seekhead_entry(mkv, MATROSKA_ID_CHAPTERS, avio_tell(pb));
> -
> 

Re: [FFmpeg-devel] [PATCH v4 4/8] avformat/mux: add proper support for full N:M bitstream filtering

[Andreas Rheinhardt]

Marton Balint:
> Previously only 1:1 bitstream filters were supported, the end of the stream 
> was
> not signalled to the bitstream filters and time base changes were ignored.
> 
> This change also allows muxers to set up bitstream filters regardless of the
> autobsf flag during write_header instead of during check_bitstream and those
> bitstream filters will always be executed.

Ignoring the autobsf flag is not ok IMO. The muxer should not add a bsf
when the user explicitly didn't want this.

- Andreas

> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mux.c | 87 
> +++
>  1 file changed, 56 insertions(+), 31 deletions(-)
> 
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 33aed9da90..d3a98499ce 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -1077,8 +1077,8 @@ static int interleave_packet(AVFormatContext *s, 
> AVPacket *out, AVPacket *in, in
>  return ff_interleave_packet_per_dts(s, out, in, flush);
>  }
>  
> -static int do_packet_auto_bsf(AVFormatContext *s, AVPacket *pkt) {
> -AVStream *st = s->streams[pkt->stream_index];
> +static int check_bitstream(AVFormatContext *s, AVStream *st, AVPacket *pkt)
> +{
>  int ret;
>  
>  if (!(s->flags & AVFMT_FLAG_AUTO_BSF))
> @@ -1093,30 +1093,6 @@ static int do_packet_auto_bsf(AVFormatContext *s, 
> AVPacket *pkt) {
>  }
>  }
>  
> -if (st->internal->bsfc) {
> -AVBSFContext *ctx = st->internal->bsfc;
> -// TODO: when any bitstream filter requires flushing at EOF, we'll 
> need to
> -// flush each stream's BSF chain on write_trailer.
> -if ((ret = av_bsf_send_packet(ctx, pkt)) < 0) {
> -av_log(ctx, AV_LOG_ERROR,
> -"Failed to send packet to filter %s for stream %d\n",
> -ctx->filter->name, pkt->stream_index);
> -return ret;
> -}
> -// TODO: when any automatically-added bitstream filter is generating 
> multiple
> -// output packets for a single input one, we'll need to call this in 
> a loop
> -// and write each output packet.
> -if ((ret = av_bsf_receive_packet(ctx, pkt)) < 0) {
> -if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
> -return 0;
> -av_log(ctx, AV_LOG_ERROR,
> -"Failed to receive packet from filter %s for stream 
> %d\n",
> -ctx->filter->name, pkt->stream_index);
> -if (s->error_recognition & AV_EF_EXPLODE)
> -return ret;
> -return 0;
> -}
> -}
>  return 1;
>  }
>  
> @@ -1161,17 +1137,53 @@ static int write_packet_common(AVFormatContext *s, 
> AVStream *st, AVPacket *pkt,
>  }
>  }
>  
> +static int write_packets_from_bsfs(AVFormatContext *s, AVStream *st, 
> AVPacket *pkt, int interleaved)
> +{
> +AVBSFContext *bsfc = st->internal->bsfc;
> +int ret;
> +
> +if ((ret = av_bsf_send_packet(bsfc, pkt)) < 0) {
> +av_log(s, AV_LOG_ERROR,
> +"Failed to send packet to filter %s for stream %d\n",
> +bsfc->filter->name, st->index);
> +return ret;
> +}
> +
> +do {
> +ret = av_bsf_receive_packet(bsfc, pkt);
> +if (ret < 0) {
> +if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
> +return 0;
> +av_log(s, AV_LOG_ERROR, "Error applying bitstream filters to an 
> output "
> +   "packet for stream #%d: %s\n", st->index, 
> av_err2str(ret));
> +if (!(s->error_recognition & AV_EF_EXPLODE) && ret != 
> AVERROR(ENOMEM))
> +continue;
> +return ret;
> +}
> +av_packet_rescale_ts(pkt, bsfc->time_base_out, st->time_base);
> +ret = write_packet_common(s, st, pkt, interleaved);
> +if (ret >= 0 && !interleaved) // a successful write_packet_common 
> already unrefed pkt for interleaved
> +av_packet_unref(pkt);
> +} while (ret >= 0);
> +
> +return ret;
> +}
> +
>  static int write_packets_common(AVFormatContext *s, AVStream *st, AVPacket 
> *pkt, int interleaved)
>  {
>  int ret = prepare_input_packet(s, pkt);
>  if (ret < 0)
>  return ret;
>  
> -ret = do_packet_auto_bsf(s, pkt);
> -if (ret <= 0)
> +ret = check_bitstream(s, st, pkt);
> +if (ret < 0)
>  return ret;
>  
> -return write_packet_common(s, st, pkt, interleaved);
> +if (st->internal->bsfc) {
> +return write_packets_from_bsfs(s, st, pkt, interleaved);
> +} else {
> +return write_packet_common(s, st, pkt, interleaved);
> +}
>  }
>  
>  int av_write_frame(AVFormatContext *s, AVPacket *in)
> @@ -1238,9 +1250,22 @@ int av_interleaved_write_frame(AVFormatContext *s, 
> AVPacket *pkt)
>  
>  int av_write_trailer(AVFormatContext *s)
>  {
> -int ret, i;
> +int i, ret1, ret = 0;
> +AVPacket pkt = {0};
> +av_init_packet();

Re: [FFmpeg-devel] [PATCH v4 8/8] avformat: remove retimeinterleave

[Andreas Rheinhardt]

Marton Balint:
> It is not used by anything anymore.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/retimeinterleave.c | 51 
> --
>  libavformat/retimeinterleave.h | 51 
> --
>  2 files changed, 102 deletions(-)
>  delete mode 100644 libavformat/retimeinterleave.c
>  delete mode 100644 libavformat/retimeinterleave.h
> 
> diff --git a/libavformat/retimeinterleave.c b/libavformat/retimeinterleave.c
> deleted file mode 100644
> index 9f874e3626..00
> --- a/libavformat/retimeinterleave.c
> +++ /dev/null
> @@ -1,51 +0,0 @@
> -/*
> - * Retime Interleaving functions
> - *
> - * Copyright (c) 2009 Baptiste Coudurier  dot com>
> - *
> - * This file is part of FFmpeg.
> - *
> - * FFmpeg is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public
> - * License as published by the Free Software Foundation; either
> - * version 2.1 of the License, or (at your option) any later version.
> - *
> - * FFmpeg is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with FFmpeg; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> - */
> -
> -#include "libavutil/mathematics.h"
> -#include "avformat.h"
> -#include "retimeinterleave.h"
> -#include "internal.h"
> -
> -void ff_retime_interleave_init(RetimeInterleaveContext *aic, AVRational 
> time_base)
> -{
> -aic->time_base = time_base;
> -}
> -
> -int ff_retime_interleave(AVFormatContext *s, AVPacket *out, AVPacket *pkt, 
> int flush,
> -int (*get_packet)(AVFormatContext *, AVPacket *, 
> AVPacket *, int),
> -int (*compare_ts)(AVFormatContext *, const AVPacket 
> *, const AVPacket *))
> -{
> -int ret;
> -
> -if (pkt) {
> -AVStream *st = s->streams[pkt->stream_index];
> -RetimeInterleaveContext *aic = st->priv_data;
> -pkt->duration = av_rescale_q(pkt->duration, st->time_base, 
> aic->time_base);
> -// rewrite pts and dts to be decoded time line position
> -pkt->pts = pkt->dts = aic->dts;
> -aic->dts += pkt->duration;
> -if ((ret = ff_interleave_add_packet(s, pkt, compare_ts)) < 0)
> -return ret;
> -}
> -
> -return get_packet(s, out, NULL, flush);
> -}
> diff --git a/libavformat/retimeinterleave.h b/libavformat/retimeinterleave.h
> deleted file mode 100644
> index de0a7442b0..00
> --- a/libavformat/retimeinterleave.h
> +++ /dev/null
> @@ -1,51 +0,0 @@
> -/*
> - * audio interleaving prototypes and declarations
> - *
> - * Copyright (c) 2009 Baptiste Coudurier  dot com>
> - *
> - * This file is part of FFmpeg.
> - *
> - * FFmpeg is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public
> - * License as published by the Free Software Foundation; either
> - * version 2.1 of the License, or (at your option) any later version.
> - *
> - * FFmpeg is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with FFmpeg; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> - */
> -
> -#ifndef AVFORMAT_RETIMEINTERLEAVE_H
> -#define AVFORMAT_RETIMEINTERLEAVE_H
> -
> -#include "avformat.h"
> -
> -typedef struct RetimeInterleaveContext {
> -uint64_t dts; ///< current dts
> -AVRational time_base; ///< time base of output packets
> -} RetimeInterleaveContext;
> -
> -/**
> - * Init the retime interleave context
> - */
> -void ff_retime_interleave_init(RetimeInterleaveContext *aic, AVRational 
> time_base);
> -
> -/**
> - * Retime packets per RetimeInterleaveContext->time_base and interleave them
> - * correctly.
> - * The first element of AVStream->priv_data must be RetimeInterleaveContext
> - * when using this function.
> - *
> - * @param get_packet function will output a packet when streams are 
> correctly interleaved.
> - * @param compare_ts function will compare AVPackets and decide interleaving 
> order.
> - */
> -int ff_retime_interleave(AVFormatContext *s, AVPacket *out, AVPacket *pkt, 
> int flush,
> -int (*get_packet)(AVFormatContext *, AVPacket *, 
> AVPacket *, int),
> -int (*compare_ts)(AVFormatContext *, const AVPacket 
> *, const AVPacket *));
> -
> -#endif /* 

Re: [FFmpeg-devel] [EXT] [PATCH v5] avcodec/v4l2_m2m_enc: Support changing qmin/qmax

[Andriy Gelman]

On Thu, 30. Apr 12:00, Andriy Gelman wrote:
> On Wed, 29. Apr 02:45, Ming Qian wrote:
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Andriy
> > > Gelman
> > > Sent: Wednesday, April 29, 2020 1:07 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Andriy Gelman 
> > > Subject: [EXT] [FFmpeg-devel] [PATCH v5] avcodec/v4l2_m2m_enc: Support
> > > changing qmin/qmax
> > > 
> > > Caution: EXT Email
> > > 
> > > From: Andriy Gelman 
> > > 
> > > Hard coded parameters for qmin and qmax are currently used to initialize
> > > v4l2_m2m device. This commit uses values from avctx->{qmin,qmax} if they
> > > are set.
> > > 
> > > Signed-off-by: Andriy Gelman 
> > > ---
> > > 
> > >  Changes in v5:
> > > - Check that qmin does not exceed qmax (thanks for feedback from Ming
> > > Qian)
> > > 
> > >  libavcodec/v4l2_m2m_enc.c | 23 +++
> > >  1 file changed, 19 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c index
> > > 8454e2326c..b22cfc61fb 100644
> > > --- a/libavcodec/v4l2_m2m_enc.c
> > > +++ b/libavcodec/v4l2_m2m_enc.c
> > > @@ -31,6 +31,7 @@
> > >  #include "v4l2_context.h"
> > >  #include "v4l2_m2m.h"
> > >  #include "v4l2_fmt.h"
> > > +#include "internal.h"
> > > 
> > >  #define MPEG_CID(x) V4L2_CID_MPEG_VIDEO_##x  #define MPEG_VIDEO(x)
> > > V4L2_MPEG_VIDEO_##x @@ -252,11 +253,18 @@ static int
> > > v4l2_prepare_encoder(V4L2m2mContext *s)
> > >  return 0;
> > >  }
> > > 
> > > -if (qmin != avctx->qmin || qmax != avctx->qmax)
> > > -av_log(avctx, AV_LOG_WARNING, "Encoder adjusted: qmin (%d),
> > > qmax (%d)\n", qmin, qmax);
> > > +if (avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin > 
> > > avctx->qmax)
> > > {
> > > +av_log(avctx, AV_LOG_WARNING, "Invalid qmin:%d qmax:%d. qmin
> > > should not "
> > > +  "exceed qmax\n", avctx->qmin,
> > > avctx->qmax);
> > > +} else {
> > > +qmin = avctx->qmin >= 0 ? avctx->qmin : qmin;
> > > +qmax = avctx->qmax >= 0 ? avctx->qmax : qmax;
> > > +}
> > > 
> > > -v4l2_set_ext_ctrl(s, qmin_cid, qmin, "minimum video quantizer 
> > > scale", 0);
> > > -v4l2_set_ext_ctrl(s, qmax_cid, qmax, "maximum video quantizer scale",
> > > 0);
> > > +v4l2_set_ext_ctrl(s, qmin_cid, qmin, "minimum video quantizer scale",
> > > +  avctx->qmin >= 0);
> > > +v4l2_set_ext_ctrl(s, qmax_cid, qmax, "maximum video quantizer scale",
> > > +  avctx->qmax >= 0);
> > > 
> > >  return 0;
> > >  }
> > > @@ -369,6 +377,12 @@ static const AVOption options[] = {
> > >  { NULL },
> > >  };
> > > 
> > > +static const AVCodecDefault v4l2_m2m_defaults[] = {
> > > +{ "qmin", "-1" },
> > > +{ "qmax", "-1" },
> > > +{ NULL },
> > > +};
> > > +
> > >  #define M2MENC_CLASS(NAME) \
> > >  static const AVClass v4l2_m2m_ ## NAME ## _enc_class = { \
> > >  .class_name = #NAME "_v4l2m2m_encoder", \ @@ -390,6 +404,7
> > > @@ static const AVOption options[] = {
> > >  .send_frame = v4l2_send_frame, \
> > >  .receive_packet = v4l2_receive_packet, \
> > >  .close  = v4l2_encode_close, \
> > > +.defaults   = v4l2_m2m_defaults, \
> > >  .capabilities   = AV_CODEC_CAP_HARDWARE |
> > > AV_CODEC_CAP_DELAY, \
> > >  .wrapper_name   = "v4l2m2m", \
> > >  };
> > > --
> > > 2.25.1
> > > 
> 
> > 
> > Lgtm
> > 
> 
> Thanks, I also locally put internal.h header in the correct alphabetical 
> order.
> 
> Will apply Sunday if no one objects. 

Applied. 

Thanks,
-- 
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 5/8] avcodec/pcm_rechunk_bsf: add bitstream filter to rechunk pcm audio

[Andreas Rheinhardt]

Marton Balint:
> Signed-off-by: Marton Balint 
> ---
>  Changelog  |   1 +
>  doc/bitstream_filters.texi |  30 ++
>  libavcodec/Makefile|   1 +
>  libavcodec/bitstream_filters.c |   1 +
>  libavcodec/pcm_rechunk_bsf.c   | 220 
> +
>  libavcodec/version.h   |   2 +-
>  6 files changed, 254 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/pcm_rechunk_bsf.c
> 
> diff --git a/Changelog b/Changelog
> index 83b8a4a46e..883e0bff99 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -63,6 +63,7 @@ version :
>  - maskedthreshold filter
>  - Support for muxing pcm and pgs in m2ts
>  - Cunning Developments ADPCM decoder
> +- pcm_rechunk bitstream filter
>  
>  
>  version 4.2:
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 8fe5b3ad75..287d320cc0 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -548,6 +548,36 @@ ffmpeg -i INPUT -c copy -bsf noise[=1] output.mkv
>  @section null
>  This bitstream filter passes the packets through unchanged.
>  
> +@section pcm_rechunk
> +
> +Repacketize PCM audio to a fixed number of samples per packet or a fixed 
> packet
> +rate per second. This is similar to the @ref{asetnsamples,,asetnsamples audio
> +filter,ffmpeg-filters} but works on audio packets instead of audio frames.
> +
> +@table @option
> +@item nb_out_samples, n
> +Set the number of samples per each output audio packet. The number is 
> intended
> +as the number of samples @emph{per each channel}. Default value is 1024.
> +
> +@item pad, p
> +If set to 1, the filter will pad the last audio packet with silence, so that 
> it
> +will contain the same number of samples (or roughly the same number of 
> samples,
> +see @option{frame_rate}) as the previous ones. Default value is 1.
> +
> +@item frame_rate, r
> +This option makes the filter output a fixed numer of packets per second 
> instead

numer

> +of a fixed number of samples per packet. If the audio sample rate is not
> +divisible by the frame rate then the number of samples will not be constant 
> but
> +will vary slightly so that each packet will start as close to the frame
> +boundary as possible. Using this option has precedence over 
> @option{nb_out_samples}.
> +@end table
> +
> +You can generate the well known 1602-1601-1602-1601-1602 pattern of 48kHz 
> audio
> +for NTSC frame rate using the @option{frame_rate} option.
> +@example
> +ffmpeg -f lavfi -i sine=r=48000:d=1 -c pcm_s16le -bsf 
> pcm_rechunk=r=3/1001 -f framecrc -
> +@end example
> +
>  @section prores_metadata
>  
>  Modify color property metadata embedded in prores stream.
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 28076c2c83..f5dcbb44ee 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1116,6 +1116,7 @@ OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += 
> mp3_header_decompress_bsf.o \
>  OBJS-$(CONFIG_MPEG2_METADATA_BSF) += mpeg2_metadata_bsf.o
>  OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
>  OBJS-$(CONFIG_NULL_BSF)   += null_bsf.o
> +OBJS-$(CONFIG_PCM_RECHUNK_BSF)+= pcm_rechunk_bsf.o
>  OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
>  OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
>  OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
> index 6b5ffe4d70..9e701191f8 100644
> --- a/libavcodec/bitstream_filters.c
> +++ b/libavcodec/bitstream_filters.c
> @@ -49,6 +49,7 @@ extern const AVBitStreamFilter ff_mpeg4_unpack_bframes_bsf;
>  extern const AVBitStreamFilter ff_mov2textsub_bsf;
>  extern const AVBitStreamFilter ff_noise_bsf;
>  extern const AVBitStreamFilter ff_null_bsf;
> +extern const AVBitStreamFilter ff_pcm_rechunk_bsf;
>  extern const AVBitStreamFilter ff_prores_metadata_bsf;
>  extern const AVBitStreamFilter ff_remove_extradata_bsf;
>  extern const AVBitStreamFilter ff_text2movsub_bsf;
> diff --git a/libavcodec/pcm_rechunk_bsf.c b/libavcodec/pcm_rechunk_bsf.c
> new file mode 100644
> index 00..b528ed0c71
> --- /dev/null
> +++ b/libavcodec/pcm_rechunk_bsf.c
> @@ -0,0 +1,220 @@
> +/*
> + * Copyright (c) 2020 Marton Balint
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write 

[FFmpeg-devel] [PATCH] avcodec/v4l2_m2m_dec: Use av_packet_move_ref()

[Andriy Gelman]

From: Andriy Gelman 

Signed-off-by: Andriy Gelman 
---
 libavcodec/v4l2_m2m_dec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 3e17e0fcac..f1ad1aa2a2 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -142,8 +142,7 @@ static int v4l2_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 int ret;
 
 if (s->buf_pkt.size) {
-avpkt = s->buf_pkt;
-memset(>buf_pkt, 0, sizeof(AVPacket));
+av_packet_move_ref(, >buf_pkt);
 } else {
 ret = ff_decode_get_packet(avctx, );
 if (ret < 0 && ret != AVERROR_EOF)
-- 
2.25.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".