Re: [FFmpeg-devel] [PATCH 1/1] avformat/matroska: fully parse stsd atom in v_quicktime tracks
Hello,
I am no expert on mov (and so this should definitely be looked at from
someone who is), but I have some points:
Stanislav Ionascu:
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 1ea9b807e6..2a397c909a 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -2473,25 +2473,58 @@ static int
matroska_parse_tracks(AVFormatContext *s)
> } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
> (track->codec_priv.size >= 21) &&
> (track->codec_priv.data)) {
> +MOVStreamContext *msc;
> +MOVContext *mc = NULL;
> +void *priv_data;
> +int nb_streams;
You could initialize nb_streams and priv_data here. And the
initialization of mc is unnecessary.
> int ret = get_qt_codec(track, , _id);
> if (ret < 0)
> return ret;
> -if (codec_id == AV_CODEC_ID_NONE &&
AV_RL32(track->codec_priv.data+4) == AV_RL32("SMI ")) {
> -fourcc = MKTAG('S','V','Q','3');
> -codec_id = ff_codec_get_id(ff_codec_movvideo_tags,
fourcc);
> +mc = av_mallocz(sizeof(*mc));
> +if (!mc)
> +return AVERROR(ENOMEM);
> +priv_data = st->priv_data;
> +nb_streams = s->nb_streams;
> +mc->fc = s;
> +st->priv_data = msc = av_mallocz(sizeof(MOVStreamContext));
> +if (!msc) {
> +av_free(mc);
> +st->priv_data = priv_data;
> +return AVERROR(ENOMEM);
> }
> +ffio_init_context(, track->codec_priv.data,
> + track->codec_priv.size,
> + 0, NULL, NULL, NULL, NULL);
> +
> +/* ff_mov_read_stsd_entries updates stream s->nb_streams-1,
> + * so set it temporarily to indicate which stream to
update. */
> +s->nb_streams = st->index + 1;
> +ff_mov_read_stsd_entries(mc, , 1);
Is it intentional that you don't check the return value here?
> +
> +/* copy palette from MOVStreamContext */
> +track->has_palette = msc->has_palette;
> +if (track->has_palette) {
> +/* leave bit_depth = -1, to reuse
bits_per_coded_sample */
> +memcpy(track->palette, msc->palette, AVPALETTE_COUNT);
In case the track has a palette, your patch would only copy 256 bytes
of it, but a palette consists of 256 uint32_t. (This link
https://drive.google.com/drive/folders/0B3_pEBoLs0faWElmM2FnLTZYNlk
from the commit message that added the palette stuff seems to still
work if you need samples for this.)
> +}
> +
> +av_free(msc);
> +av_free(mc);
> +st->priv_data = priv_data;
> +s->nb_streams = nb_streams;
> +fourcc = st->codecpar->codec_tag;
> +codec_id = st->codecpar->codec_id;
> +
> +av_log(matroska->ctx, AV_LOG_TRACE,
> + "mov FourCC found %s.\n", av_fourcc2str(fourcc));
> +
> if (codec_id == AV_CODEC_ID_NONE)
> av_log(matroska->ctx, AV_LOG_ERROR,
> - "mov FourCC not found %s.\n",
av_fourcc2str(fourcc));
If the codec_id turns out to be AV_CODEC_ID_NONE, two strings will be
output (at least on loglevel trace): "mov FourCC found %s.\n" and then
"mov FourCC not found %s.\n". The first of these is superfluous in
this case.
> -if (track->codec_priv.size >= 86) {
> -bit_depth = AV_RB16(track->codec_priv.data + 82);
> -ffio_init_context(, track->codec_priv.data,
> - track->codec_priv.size,
> - 0, NULL, NULL, NULL, NULL);
> -if (ff_get_qtpalette(codec_id, , track->palette)) {
If I am not extremely mistaken, then there is no need to include
qtpalette.h any more after removing this function call.
> -bit_depth &= 0x1F;
> -track->has_palette = 1;
> -}
> +"mov FourCC not found %s.\n",
av_fourcc2str(fourcc));
> +
> +// dvh1 in mkv is likely HEVC
> +if (fourcc == MKTAG('d','v','h','1')) {
> +codec_id = AV_CODEC_ID_HEVC;
Your changes for dvh1 should probably be moved to a separate commit.
> }
> } else if (codec_id == AV_CODEC_ID_PCM_S16BE) {
> switch (track->audio.bitdepth) {
- 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 1/8] avcodec/cinepak: Require 1 bit per 4x4 block as minimum input
lör 2019-08-17 klockan 17:33 +0200 skrev Michael Niedermayer:
> On Sat, Aug 17, 2019 at 12:26:27AM +0200, Tomas Härdin wrote:
> > fre 2019-08-16 klockan 14:57 +0200 skrev Tomas Härdin:
> > > fre 2019-08-16 klockan 00:50 +0200 skrev Michael Niedermayer:
> > > > On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> > > > > ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > > > > > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > > > > > Fixes: Timeout (12sec -> 32ms)
> > > > > > > Fixes: 16078/clusterfuzz-testcase-minimized-
> > > > > > > ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296
> > > > > > > [...]
> > > > > > > +if (s->size < (s->avctx->width * s->avctx->height) / (4*4*8))
> > > > > > > +return AVERROR_INVALIDDATA;
> > > > > >
> > > > > > This is wrong if num_strips == 0, and if the MB area is != 0 mod 8.
> > > > > > You
> > > > > > could merge it with the check above into something like:
> > > > > >
> > > > > > if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12 +
> > > > > > (num_strips ? ((s->avctx->width * s->avctx->height) / 16 + 7)/8
> > > > > > :
> > > > > > 0)) {
> > > > > > return AVERROR_INVALIDDATA;
> > > > > > }
> > > > > >
> > > > > > The check further down could also check each strip's size, not just
> > > > > > the
> > > > > > first one.
> > > > >
> > > > > Actually, thinking a bit more about this, I suspect it might be legal
> > > > > to have strips that don't cover the entire frame. It would certainly
> > > > > be
> > > > > good to support that, for optimizing skip frames. Not sure what old
> > > > > decoders make of that however. A skip could potentially be encoded in
> > > > > 22 + (width/4 + 7)/8 bytes while still being compatible.
> > > >
> > > > i was asking myself the same questions before writing the patch, and
> > > > in the "spec" there is
> > > > "Each frame is segmented into 4x4 pixel blocks, and each block is coded
> > > > using either 1 or 4 vectors."
> > > > "Each" meaning no holes to me. If thats actually true for all real files
> > > > that i do not know.
> > >
> > > We should keep in mind the spec is fine with there being zero strips.
> > > It's only if one wants to support certain decoders that there will/must
> > > be one or more strips.
> >
> > I've been playing around with the Windows 3.1 cinepak decoder, and it
> > seems one indeed has to code every MB even if they don't change. I
> > suspect the reason is because that decoder uses double buffering and
> > they wanted to avoid doing more memcpy()s than absolutely necessary. If
> > one tries to play tricks like coding strips that are only 4x4 pixels to
> > indicate a frame without changes then parts of the video will be
> > replaced by garbage. So demanding number_of_bits >= number_of_mbs is
> > certainly in line with that decoder.
> >
> > I feel I should point out that being conservative here is at odds with
> > the general "best effort" approach taken in this project. These toy
> > codecs are useful as illustrative examples of this contradiction. I'm
> > sure there are many more examples of files that can cause ffmpeg to do
> > a lot more work than expected, for almost every codec. I know afl-fuzz
> > is likely to find out that it can make the ZMBV decoder do a lot of
> > work for a small input file, because I've seen it do that with gzip.
> >
> > The user base for cinepak is of course miniscule, so I doubt anyone's
> > going to complain that their broken CVID files don't work any more. I
> > certainly don't care since cinepakenc only puts out valid files.
> > But
> > again, for other formats we're just going to have to tell users to put
> > ffmpeg inside a sandbox and stick a CPU limit on it. Even ffprobe is
> > vulnerable to DoS-y things.
>
> yes
>
> the question ATM is just what to do here about this codec ?
> apply the patch ?
> change it ?
Well for a start, the file is 65535 x 209 pixels, 3166 frames. I
wouldn't call decoding that @ 263 fps particularly slow
Second, it's not the decoder which is slow. If I comment out the
"*got_frame = 1;" then the test also runs fast. I'm not sure what
happens elsewhere with the decoded buffer, but I suspect there's a
bunch of useless malloc()/memset()ing going on. Maybe the decoder is
using ff_reget_buffer() or av_frame_ref() incorrectly, I'm not sure.
As I said on IRC, this class of problems will exist for every codec.
Cinepak is easy to decode, even at these resolutions. Just imagine what
will happens when someone feeds in a 65535x209 av1 stream..
/Tomas
___
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] avformat/hlsenc: merge mpegts and fmp4 workflow to one workflow
> 在 2019年8月9日，下午5:30，Liu Steven 写道：
>
>
>
>> 在 2019年8月5日，上午10:29，Steven Liu 写道：
>>
>> just remove the 'i' of the v3 mail subject.
>> write mpegts or fmp4 context into buffer, and flush the buffer into
>> output file when split fragment. merge two format split workflow into
>> one workflow
>>
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/hlsenc.c | 251 +--
>> 1 file changed, 124 insertions(+), 127 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 51310fb528..f6f9c8161d 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -815,7 +815,7 @@ static int hls_mux_init(AVFormatContext *s,
>> VariantStream *vs)
>>vs->start_pos = 0;
>>vs->new_start = 1;
>>
>> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>> +if (hls->segment_type == SEGMENT_TYPE_FMP4 && hls->max_seg_size > 0) {
>>if (hls->http_persistent > 0) {
>>//TODO: Support fragment fmp4 for http persistent in HLS muxer.
>>av_log(s, AV_LOG_WARNING, "http persistent mode is currently
>> unsupported for fragment mp4 in the HLS muxer.\n");
>> @@ -824,34 +824,38 @@ static int hls_mux_init(AVFormatContext *s,
>> VariantStream *vs)
>>av_log(s, AV_LOG_WARNING, "Multi-file byterange mode is currently
>> unsupported in the HLS muxer.\n");
>>return AVERROR_PATCHWELCOME;
>>}
>> +}
>>
>> -vs->packets_written = 0;
>> -vs->init_range_length = 0;
>> -set_http_options(s, , hls);
>> -if ((ret = avio_open_dyn_buf(>pb)) < 0)
>> -return ret;
>> +vs->packets_written = 0;
>> +vs->init_range_length = 0;
>> +set_http_options(s, , hls);
>> +if ((ret = avio_open_dyn_buf(>pb)) < 0)
>> +return ret;
>>
>> +if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>>if (byterange_mode) {
>>ret = hlsenc_io_open(s, >out, vs->basename, );
>>} else {
>>ret = hlsenc_io_open(s, >out, vs->base_output_dirname,
>> );
>>}
>> -av_dict_free();
>> +}
>> +av_dict_free();
>> +if (ret < 0) {
>> +av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
>> vs->fmp4_init_filename);
>> +return ret;
>> +}
>> +
>> +if (hls->format_options_str) {
>> +ret = av_dict_parse_string(>format_options,
>> hls->format_options_str, "=", ":", 0);
>>if (ret < 0) {
>> -av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
>> vs->fmp4_init_filename);
>> +av_log(s, AV_LOG_ERROR, "Could not parse format options list
>> '%s'\n",
>> + hls->format_options_str);
>>return ret;
>>}
>> +}
>>
>> -if (hls->format_options_str) {
>> -ret = av_dict_parse_string(>format_options,
>> hls->format_options_str, "=", ":", 0);
>> -if (ret < 0) {
>> -av_log(s, AV_LOG_ERROR, "Could not parse format options
>> list '%s'\n",
>> - hls->format_options_str);
>> -return ret;
>> -}
>> -}
>> -
>> -av_dict_copy(, hls->format_options, 0);
>> +av_dict_copy(, hls->format_options, 0);
>> +if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>>av_dict_set(, "fflags", "-autobsf", 0);
>>av_dict_set(, "movflags", "+frag_custom+dash+delay_moov",
>> AV_DICT_APPEND);
>>ret = avformat_init_output(oc, );
>> @@ -862,9 +866,9 @@ static int hls_mux_init(AVFormatContext *s,
>> VariantStream *vs)
>>av_dict_free();
>>return AVERROR(EINVAL);
>>}
>> -avio_flush(oc->pb);
>> -av_dict_free();
>>}
>> +avio_flush(oc->pb);
>> +av_dict_free();
>>return 0;
>> }
>>
>> @@ -1435,7 +1439,6 @@ static int hls_window(AVFormatContext *s, int last,
>> VariantStream *vs)
>> {
>>HLSContext *hls = s->priv_data;
>>HLSSegment *en;
>> -AVFormatContext *oc = vs->avf;
>>int target_duration = 0;
>>int ret = 0;
>>char temp_filename[MAX_URL_SIZE];
>> @@ -1471,7 +1474,7 @@ static int hls_window(AVFormatContext *s, int last,
>> VariantStream *vs)
>>
>>set_http_options(s, , hls);
>>snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" :
>> "%s", vs->m3u8_name);
>> -if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
>> SEGMENT_TYPE_FMP4) ? >m3u8_out : >pb, temp_filename, )) <
>> 0) {
>> +if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
>> SEGMENT_TYPE_FMP4) ? >m3u8_out : >out, temp_filename, )) <
>> 0) {
>>if (hls->ignore_io_errors)
>>ret = 0;
>>goto fail;
>> @@ -1483,33 +1486,33 @@ static int hls_window(AVFormatContext *s, int last,
>> VariantStream *vs)
>>}
>>
>>vs->discontinuity_set = 0;
>> -ff_hls_write_playlist_header((byterange_mode || hls->segment_type ==
>> SEGMENT_TYPE_FMP4) ? hls->m3u8_out : oc->pb, hls->version,
Re: [FFmpeg-devel] [PATCH v2 1/2] lavf/dump: use error log level for invalid size
> 在 2019年8月11日，下午4:41，Steven Liu 写道：
>
>
>
>> 在 2019年8月10日，23:53，lance.lmw...@gmail.com 写道：
>>
>> From: Limin Wang
>>
>> Signed-off-by: Limin Wang
>> ---
>> libavformat/dump.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavformat/dump.c b/libavformat/dump.c
>> index 1c44656..68ce9a8 100644
>> --- a/libavformat/dump.c
>> +++ b/libavformat/dump.c
>> @@ -210,7 +210,7 @@ static void dump_paramchange(void *ctx, AVPacketSideData
>> *sd)
>>
>>return;
>> fail:
>> -av_log(ctx, AV_LOG_INFO, "unknown param");
>> +av_log(ctx, AV_LOG_ERROR, "unknown param");
>> }
>>
>> /* replaygain side data*/
>> @@ -239,7 +239,7 @@ static void dump_replaygain(void *ctx, AVPacketSideData
>> *sd)
>>AVReplayGain *rg;
>>
>>if (sd->size < sizeof(*rg)) {
>> -av_log(ctx, AV_LOG_INFO, "invalid data");
>> +av_log(ctx, AV_LOG_ERROR, "invalid data");
>>return;
>>}
>>rg = (AVReplayGain*)sd->data;
>> @@ -255,7 +255,7 @@ static void dump_stereo3d(void *ctx, AVPacketSideData
>> *sd)
>>AVStereo3D *stereo;
>>
>>if (sd->size < sizeof(*stereo)) {
>> -av_log(ctx, AV_LOG_INFO, "invalid data");
>> +av_log(ctx, AV_LOG_ERROR, "invalid data");
>>return;
>>}
>>
>> @@ -272,7 +272,7 @@ static void dump_audioservicetype(void *ctx,
>> AVPacketSideData *sd)
>>enum AVAudioServiceType *ast = (enum AVAudioServiceType *)sd->data;
>>
>>if (sd->size < sizeof(*ast)) {
>> -av_log(ctx, AV_LOG_INFO, "invalid data");
>> +av_log(ctx, AV_LOG_ERROR, "invalid data");
>>return;
>>}
>>
>> @@ -315,7 +315,7 @@ static void dump_cpb(void *ctx, AVPacketSideData *sd)
>>AVCPBProperties *cpb = (AVCPBProperties *)sd->data;
>>
>>if (sd->size < sizeof(*cpb)) {
>> -av_log(ctx, AV_LOG_INFO, "invalid data");
>> +av_log(ctx, AV_LOG_ERROR, "invalid data");
>>return;
>>}
>>
>> @@ -357,7 +357,7 @@ static void dump_spherical(void *ctx, AVCodecParameters
>> *par, AVPacketSideData *
>>double yaw, pitch, roll;
>>
>>if (sd->size < sizeof(*spherical)) {
>> -av_log(ctx, AV_LOG_INFO, "invalid data");
>> +av_log(ctx, AV_LOG_ERROR, "invalid data");
>>return;
>>}
>>
>> --
>> 2.6.4
>>
>> ___
>> 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
Pushed
Thanks
Steven
___
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 1/6] avcodec/ralf: fix undefined shift
Fixes: left shift of negative value -2
Fixes:
16145/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RALF_fuzzer-5146671058518016
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ralf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ralf.c b/libavcodec/ralf.c
index 619fd7126a..d2d803b0d4 100644
--- a/libavcodec/ralf.c
+++ b/libavcodec/ralf.c
@@ -300,8 +300,8 @@ static int decode_channel(RALFContext *ctx, GetBitContext
*gb, int ch,
t = get_vlc2(gb, code_vlc->table, code_vlc->bits, 2);
code1 = t / range2;
code2 = t % range2;
-dst[i] = extend_code(gb, code1, range, 0) << add_bits;
-dst[i + 1] = extend_code(gb, code2, range, 0) << add_bits;
+dst[i] = extend_code(gb, code1, range, 0) * (1 << add_bits);
+dst[i + 1] = extend_code(gb, code2, range, 0) * (1 << add_bits);
if (add_bits) {
dst[i] |= get_bits(gb, add_bits);
dst[i + 1] |= get_bits(gb, add_bits);
--
2.22.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".
[FFmpeg-devel] [PATCH 5/6] avcodec/apedec: Fix integer overflow in filter_fast_3320()
Fixes: signed integer overflow: -1094994793 * 2 cannot be represented in type 'int' Fixes: 16139/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5663911036059648 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/apedec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c index 70939abeb4..5d82ff53ff 100644 --- a/libavcodec/apedec.c +++ b/libavcodec/apedec.c @@ -828,7 +828,7 @@ static av_always_inline int filter_fast_3320(APEPredictor *p, return decoded; } -predictionA = p->buf[delayA] * 2 - p->buf[delayA - 1]; +predictionA = p->buf[delayA] * 2U - p->buf[delayA - 1]; p->lastA[filter] = decoded + ((int32_t)(predictionA * p->coeffsA[filter][0]) >> 9); if ((decoded ^ predictionA) > 0) -- 2.22.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".
[FFmpeg-devel] [PATCH 2/6] avcodec/ralf: fix undefined shift in extend_code()
Fixes: left shift of negative value -3 Fixes: 16147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RALF_fuzzer-5658392722407424 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/ralf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/ralf.c b/libavcodec/ralf.c index d2d803b0d4..75c9371b95 100644 --- a/libavcodec/ralf.c +++ b/libavcodec/ralf.c @@ -220,7 +220,7 @@ static inline int extend_code(GetBitContext *gb, int val, int range, int bits) val -= range; } if (bits) -val = (val << bits) | get_bits(gb, bits); +val = ((unsigned)val << bits) | get_bits(gb, bits); return val; } -- 2.22.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".
[FFmpeg-devel] [PATCH 6/6] vcodec/apedec: Fix integer overflow in filter_3800()
Fixes: signed integer overflow: 2021654528 + 2032575680 cannot be represented
in type 'int'
Fixes:
16270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5732438816325632
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/apedec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 5d82ff53ff..490b11b94e 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -842,7 +842,7 @@ static av_always_inline int filter_fast_3320(APEPredictor
*p,
}
static av_always_inline int filter_3800(APEPredictor *p,
-const int decoded, const int filter,
+const unsigned decoded, const int
filter,
const int delayA, const int delayB,
const int start, const int shift)
{
--
2.22.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".
[FFmpeg-devel] [PATCH 4/6] avcodec/pngdec: Check amount decoded
Fixes: Timeout (70sec -> 243ms)
Fixes:
16097/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APNG_fuzzer-5664690889293824
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pngdec.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 4ca4f7bdc1..6e6856ab3e 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -320,6 +320,15 @@ static void deloco_ ## NAME(TYPE *dst, int size, int
alpha) \
YUV2RGB(rgb8, uint8_t)
YUV2RGB(rgb16, uint16_t)
+static int percent_missing(PNGDecContext *s)
+{
+if (s->interlace_type) {
+return 100 - 100 * s->pass / (NB_PASSES - 1);
+} else {
+return 100 - 100 * s->y / s->cur_h;
+}
+}
+
/* process exactly one decompressed row */
static void png_handle_row(PNGDecContext *s)
{
@@ -1354,6 +1363,9 @@ exit_loop:
return 0;
}
+if (percent_missing(s) > avctx->discard_damaged_percentage)
+return AVERROR_INVALIDDATA;
+
if (s->bits_per_pixel <= 4)
handle_small_bpp(s, p);
--
2.22.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".
[FFmpeg-devel] [PATCH 3/6] avcodec/pngdec: Optimize has_trns code
30M cycles -> 5M cycles
Testcase: fate-rgbapng-4816
Testcase:
16097/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APNG_fuzzer-5664690889293824
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
---
libavcodec/pngdec.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index cad5796545..4ca4f7bdc1 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -24,6 +24,7 @@
#include "libavutil/avassert.h"
#include "libavutil/bprint.h"
#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
#include "libavutil/stereo3d.h"
#include "libavutil/mastering_display_metadata.h"
@@ -1363,19 +1364,38 @@ exit_loop:
unsigned x, y;
av_assert0(s->bit_depth > 1);
-
for (y = 0; y < s->height; ++y) {
uint8_t *row = >image_buf[s->image_linesize * y];
-/* since we're updating in-place, we have to go from right to left
*/
-for (x = s->width; x > 0; --x) {
-uint8_t *pixel = [s->bpp * (x - 1)];
-memmove(pixel, [raw_bpp * (x - 1)], raw_bpp);
+if (s->bpp == 2 && byte_depth == 1) {
+uint8_t *pixel = [2 * s->width - 1];
+uint8_t *rowp = [1 * s->width - 1];
+int tcolor = s->transparent_color_be[0];
+for (x = s->width; x > 0; --x) {
+*pixel-- = *rowp == tcolor ? 0 : 0xff;
+*pixel-- = *rowp--;
+}
+} else if (s->bpp == 4 && byte_depth == 1) {
+uint8_t *pixel = [4 * s->width - 1];
+uint8_t *rowp = [3 * s->width - 1];
+int tcolor = AV_RL24(s->transparent_color_be);
+for (x = s->width; x > 0; --x) {
+*pixel-- = AV_RL24(rowp-2) == tcolor ? 0 : 0xff;
+*pixel-- = *rowp--;
+*pixel-- = *rowp--;
+*pixel-- = *rowp--;
+}
+} else {
+/* since we're updating in-place, we have to go from right to
left */
+for (x = s->width; x > 0; --x) {
+uint8_t *pixel = [s->bpp * (x - 1)];
+memmove(pixel, [raw_bpp * (x - 1)], raw_bpp);
-if (!memcmp(pixel, s->transparent_color_be, raw_bpp)) {
-memset([raw_bpp], 0, byte_depth);
-} else {
-memset([raw_bpp], 0xff, byte_depth);
+if (!memcmp(pixel, s->transparent_color_be, raw_bpp)) {
+memset([raw_bpp], 0, byte_depth);
+} else {
+memset([raw_bpp], 0xff, byte_depth);
+}
}
}
}
--
2.22.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 v2] avfilter/showinfo: support Content Light Level information
On 8/17/2019 8:09 PM, Limin Wang wrote:
> On Sat, Aug 17, 2019 at 02:49:29PM -0300, James Almer wrote:
>> On 8/17/2019 2:44 PM, James Almer wrote:
>>> On 8/10/2019 11:58 AM, lance.lmw...@gmail.com wrote:
From: Limin Wang
show real information instead of the unknown side data type message for
HDR10 stream
Signed-off-by: Limin Wang
---
libavfilter/vf_showinfo.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 9fa322e..94d17bf 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -160,6 +160,20 @@ static void dump_mastering_display(AVFilterContext
*ctx, AVFrameSideData *sd)
av_q2d(mastering_display->min_luminance),
av_q2d(mastering_display->max_luminance));
}
+static void dump_content_light_metadata(AVFilterContext *ctx,
AVFrameSideData *sd)
+{
+AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
+
+if (sd->size < sizeof(*metadata)) {
>>>
>>> sizeof(AVContentLightMetadata) is not part of the ABI, so just remove
>>> this check.
>>
>> Oh, your first version was like that, and this one is the result of
>> someone suggesting to add the check.
>>
>> Pushed the correct version then.
>
> thanks, when we should check the size as some other metadata have the
> size check?
When the doxy for the relevant struct or the side data type states its
size is part of the ABI.
Some are (AVReplayGain, display matrix, etc), and some aren't
(AVDynamicHDRPlus, AVContentLightMetadata, AVMasteringDisplayMetadata,
AVSphericalMapping, etc).
>
>>
>>>
+av_log(ctx, AV_LOG_ERROR, "invalid data");
+return;
+}
+
+av_log(ctx, AV_LOG_INFO, "Content Light Level information: "
+ "MaxCLL=%d, MaxFALL=%d",
+ metadata->MaxCLL, metadata->MaxFALL);
+}
+
static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
{
const char *color_range_str =
av_color_range_name(frame->color_range);
@@ -301,6 +315,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
dump_mastering_display(ctx, sd);
break;
+case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL:
+dump_content_light_metadata(ctx, sd);
+break;
default:
av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
bytes)",
sd->type, sd->size);
>>>
>>
>> ___
>> 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 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 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] avfilter/showinfo: support Content Light Level information
On Sat, Aug 17, 2019 at 02:49:29PM -0300, James Almer wrote:
> On 8/17/2019 2:44 PM, James Almer wrote:
> > On 8/10/2019 11:58 AM, lance.lmw...@gmail.com wrote:
> >> From: Limin Wang
> >>
> >> show real information instead of the unknown side data type message for
> >> HDR10 stream
> >>
> >> Signed-off-by: Limin Wang
> >> ---
> >> libavfilter/vf_showinfo.c | 17 +
> >> 1 file changed, 17 insertions(+)
> >>
> >> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> >> index 9fa322e..94d17bf 100644
> >> --- a/libavfilter/vf_showinfo.c
> >> +++ b/libavfilter/vf_showinfo.c
> >> @@ -160,6 +160,20 @@ static void dump_mastering_display(AVFilterContext
> >> *ctx, AVFrameSideData *sd)
> >> av_q2d(mastering_display->min_luminance),
> >> av_q2d(mastering_display->max_luminance));
> >> }
> >>
> >> +static void dump_content_light_metadata(AVFilterContext *ctx,
> >> AVFrameSideData *sd)
> >> +{
> >> +AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
> >> +
> >> +if (sd->size < sizeof(*metadata)) {
> >
> > sizeof(AVContentLightMetadata) is not part of the ABI, so just remove
> > this check.
>
> Oh, your first version was like that, and this one is the result of
> someone suggesting to add the check.
>
> Pushed the correct version then.
thanks, when we should check the size as some other metadata have the
size check?
>
> >
> >> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> >> +return;
> >> +}
> >> +
> >> +av_log(ctx, AV_LOG_INFO, "Content Light Level information: "
> >> + "MaxCLL=%d, MaxFALL=%d",
> >> + metadata->MaxCLL, metadata->MaxFALL);
> >> +}
> >> +
> >> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> >> {
> >> const char *color_range_str =
> >> av_color_range_name(frame->color_range);
> >> @@ -301,6 +315,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> >> *frame)
> >> case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
> >> dump_mastering_display(ctx, sd);
> >> break;
> >> +case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL:
> >> +dump_content_light_metadata(ctx, sd);
> >> +break;
> >> default:
> >> av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> >> bytes)",
> >> sd->type, sd->size);
> >>
> >
>
> ___
> 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 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 v1] fftools/ffmpeg_opt: avoid to display the hwaccels name twice
On Sat, Aug 17, 2019 at 06:35:55PM +0200, Marton Balint wrote:
>
>
> On Sat, 17 Aug 2019, Limin Wang wrote:
>
> >On Sat, Aug 17, 2019 at 05:21:33PM +0200, Marton Balint wrote:
> >>
> >>
> >>On Sat, 17 Aug 2019, Limin Wang wrote:
> >>
> >>>
> >>>
> >>>ping, please help to merge the code if it's OK.
> >>>
> >>>On Thu, Aug 15, 2019 at 09:23:45AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> videotoolbox and qsv have been defined by hw_type_names[] in hwcontext.c
>
> Fixes ticket #7464
>
> Signed-off-by: Limin Wang
> ---
> fftools/ffmpeg_opt.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index f5ca18a..8baa898 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -66,12 +66,6 @@
> }
>
> const HWAccel hwaccels[] = {
> -#if CONFIG_VIDEOTOOLBOX
> -{ "videotoolbox", videotoolbox_init, HWACCEL_VIDEOTOOLBOX,
> AV_PIX_FMT_VIDEOTOOLBOX },
> -#endif
> -#if CONFIG_LIBMFX
> -{ "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
> -#endif
> >>
> >>And what about the init functions which are called? Or other cases
> >>in the code which iterates over hwaccels? Have you tried if
> >>accelerated processing works after your patch?
> >
> >Yes, I have tested OK with both videotoolbox decode and encode,
> >ffmpeg_opt.c:842 will invoke
> >av_hwdevice_find_type_by_name(hwaccel); to get them. For cuvid
> >isn't defined in the hwcontext.c, so keep it
> >anyway.
>
> The loop in ffmpeg.c:2845 won't find the hwaccel if you remove them
> from this list.
I understand ffmpeg.c 2824 config will true if it's expected, so it'll not come
to ffmpeg_opt.c:842.
>
> 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".
___
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] [CALL] New FFmpeg developers meeting
On Sat, Aug 17, 2019 at 4:18 PM James Almer wrote: > Start by drafting a list of subjects to discuss, and proposing a date > (at least two weeks from now) or asking for suggestions. Then wait to > see how many developers agree with it and confirm they will be there. Indeed, having some form of goal(s) would be useful. Are there particular things/topics you want to work on where having everyone in a room would be helpful? Is this just an opportunity for like-minded developers to socialize over beer? Also, would be good to have a rough idea as to what part of the world you want to meet in. I assume you're thinking "somewhere in Europe" given your locale. Regarding when to meet, I would suggest considering what other conferences are going on, and whether it would conflict with what you're planning. Alternatively, consider having it right before/after one of those conferences in the same region, and you might find people who are more likely to attend because they are already in the area (e.g. perhaps with airfare already paid for by their employer because of the other event). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ 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/1] Support new SRT streamid specification
Am 14.08.19 um 14:31 schrieb Aaron Boxer:
> @@ -101,6 +105,7 @@ static const AVOption libsrt_options[] = {
> { "maxbw", "Maximum bandwidth (bytes per second) that the
> connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{
> .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
> { "pbkeylen", "Crypto key len in bytes {16,24,32} Default: 16
> (128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT, {
> .i64 = -1 }, -1, 32,.flags = D|E },
> { "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable
> crypto", OFFSET(passphrase), AV_OPT_TYPE_STRING, { .str =
> NULL }, .flags = D|E },
> +{ "user_passphrase_list", "Comma separated list users and passphrases,
> of form usrr1=pass1,usr2=pass2,...", OFFSET(user_passphrase_list),
> AV_OPT_TYPE_STRING, { .str = NULL }, .flags = D|E },
There is a typo at usrr1.
How can a password containing comma or equal sign be specified?
Matthias
___
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] [CALL] New FFmpeg developers meeting
On 8/17/2019 6:48 AM, Paul B Mahol wrote: > Hi, > > When and how to organize this? Start by drafting a list of subjects to discuss, and proposing a date (at least two weeks from now) or asking for suggestions. Then wait to see how many developers agree with it and confirm they will be there. ___ 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 3/3] avcodec: remove some dead assignments
Signed-off-by: Marton Balint
---
libavcodec/bsf.c| 1 -
libavcodec/decode.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 5081307603..71915dea85 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -306,7 +306,6 @@ static int bsf_list_filter(AVBSFContext *bsf, AVPacket *out)
ret = av_bsf_receive_packet(lst->bsfs[lst->idx-1], out);
if (ret == AVERROR(EAGAIN)) {
/* no more packets from idx-1, try with previous */
-ret = 0;
lst->idx--;
continue;
} else if (ret == AVERROR_EOF) {
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6c31166ec2..cf9676e2ac 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -300,7 +300,6 @@ static int bsfs_poll(AVCodecContext *avctx, AVPacket *pkt)
ret = av_bsf_receive_packet(s->bsfs[idx], pkt);
if (ret == AVERROR(EAGAIN)) {
/* no packets available, try the next filter up the chain */
-ret = 0;
idx--;
continue;
} else if (ret < 0 && ret != AVERROR_EOF) {
--
2.16.4
___
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 2/3] avutil/imgutils: remove dead assignment
Signed-off-by: Marton Balint
---
libavutil/imgutils.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index c733cb5cf5..7f9c1b632c 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -519,7 +519,6 @@ static void memset_bytes(uint8_t *dst, size_t dst_size,
uint8_t *clear,
if (clear_size == 1) {
memset(dst, clear[0], dst_size);
-dst_size = 0;
} else {
if (clear_size > dst_size)
clear_size = dst_size;
--
2.16.4
___
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 1/3] avformat/mxfdec: do not ignore bad size errors
The return value was unintentionally lost after
00a2652df3bf25a27d174cc67ed508b5317cb115.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index bb72fb9841..397f820b3f 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -3508,8 +3508,8 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket
*pkt)
} else {
if ((size = next_ofs - pos) <= 0) {
av_log(s, AV_LOG_ERROR, "bad size: %"PRId64"\n", size);
-ret = AVERROR_INVALIDDATA;
-goto skip;
+mxf->current_klv_data = (KLVPacket){{0}};
+return AVERROR_INVALIDDATA;
}
// We must not overread, because the next edit unit might
be in another KLV
if (size > max_data_size)
--
2.16.4
___
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] EOF and IO error checking
Hi,
As you might now avio_feof() returns true both in case of actual EOF and
in case of IO errors.
Some demuxers (matroska) have special handling for this exact reason,
e.g.:
if (avio_feof(pb)) {
if (pb->error) {
return pb->error;
} else {
return AVERROR_EOF;
}
}
Most of the demuxers do not, so there is a real chance that IO errrors
are mistaken for EOF.
What should we do about this?
a) Fix every demuxer to return IO error if there is one.
b) Add special code to ff_read_packet which checks if there is an error in
the IO context and return that if there is?
c) Add code to ffmpeg.c which checks the IO context error code after every
av_read_frame call?
Some other idea? Which one is preferred from these?
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 v2 2/2] lavf/dump: add the valid check for consistent
On 8/10/2019 12:53 PM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/dump.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 68ce9a8..4b18032 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -328,6 +328,11 @@ static void dump_cpb(void *ctx, AVPacketSideData *sd)
>
> static void dump_mastering_display_metadata(void *ctx, AVPacketSideData* sd)
> {
> AVMasteringDisplayMetadata* metadata =
> (AVMasteringDisplayMetadata*)sd->data;
> +
> +if (sd->size < sizeof(*metadata)) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> +return;
> +}
> av_log(ctx, AV_LOG_INFO, "Mastering Display Metadata, "
> "has_primaries:%d has_luminance:%d "
> "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, %5.4f) "
> @@ -346,6 +351,11 @@ static void dump_mastering_display_metadata(void *ctx,
> AVPacketSideData* sd) {
> static void dump_content_light_metadata(void *ctx, AVPacketSideData* sd)
> {
> AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
> +
> +if (sd->size < sizeof(*metadata)) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> +return;
> +}
> av_log(ctx, AV_LOG_INFO, "Content Light Level Metadata, "
> "MaxCLL=%d, MaxFALL=%d",
> metadata->MaxCLL, metadata->MaxFALL);
No, the size of both structs is not part of the ABI.
___
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] avfilter/showinfo: support Content Light Level information
On 8/17/2019 2:44 PM, James Almer wrote:
> On 8/10/2019 11:58 AM, lance.lmw...@gmail.com wrote:
>> From: Limin Wang
>>
>> show real information instead of the unknown side data type message for
>> HDR10 stream
>>
>> Signed-off-by: Limin Wang
>> ---
>> libavfilter/vf_showinfo.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
>> index 9fa322e..94d17bf 100644
>> --- a/libavfilter/vf_showinfo.c
>> +++ b/libavfilter/vf_showinfo.c
>> @@ -160,6 +160,20 @@ static void dump_mastering_display(AVFilterContext
>> *ctx, AVFrameSideData *sd)
>> av_q2d(mastering_display->min_luminance),
>> av_q2d(mastering_display->max_luminance));
>> }
>>
>> +static void dump_content_light_metadata(AVFilterContext *ctx,
>> AVFrameSideData *sd)
>> +{
>> +AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
>> +
>> +if (sd->size < sizeof(*metadata)) {
>
> sizeof(AVContentLightMetadata) is not part of the ABI, so just remove
> this check.
Oh, your first version was like that, and this one is the result of
someone suggesting to add the check.
Pushed the correct version then.
>
>> +av_log(ctx, AV_LOG_ERROR, "invalid data");
>> +return;
>> +}
>> +
>> +av_log(ctx, AV_LOG_INFO, "Content Light Level information: "
>> + "MaxCLL=%d, MaxFALL=%d",
>> + metadata->MaxCLL, metadata->MaxFALL);
>> +}
>> +
>> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
>> {
>> const char *color_range_str =
>> av_color_range_name(frame->color_range);
>> @@ -301,6 +315,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>> *frame)
>> case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
>> dump_mastering_display(ctx, sd);
>> break;
>> +case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL:
>> +dump_content_light_metadata(ctx, sd);
>> +break;
>> default:
>> av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
>> bytes)",
>> sd->type, sd->size);
>>
>
___
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] avfilter/showinfo: support Content Light Level information
On 8/10/2019 11:58 AM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> show real information instead of the unknown side data type message for HDR10
> stream
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_showinfo.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index 9fa322e..94d17bf 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -160,6 +160,20 @@ static void dump_mastering_display(AVFilterContext *ctx,
> AVFrameSideData *sd)
> av_q2d(mastering_display->min_luminance),
> av_q2d(mastering_display->max_luminance));
> }
>
> +static void dump_content_light_metadata(AVFilterContext *ctx,
> AVFrameSideData *sd)
> +{
> +AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
> +
> +if (sd->size < sizeof(*metadata)) {
sizeof(AVContentLightMetadata) is not part of the ABI, so just remove
this check.
> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> +return;
> +}
> +
> +av_log(ctx, AV_LOG_INFO, "Content Light Level information: "
> + "MaxCLL=%d, MaxFALL=%d",
> + metadata->MaxCLL, metadata->MaxFALL);
> +}
> +
> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> {
> const char *color_range_str =
> av_color_range_name(frame->color_range);
> @@ -301,6 +315,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
> dump_mastering_display(ctx, sd);
> break;
> +case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL:
> +dump_content_light_metadata(ctx, sd);
> +break;
> default:
> av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> bytes)",
> sd->type, sd->size);
>
___
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] [PATCHv2 1/3] avformat/avio: add avio_print_string_array and avio_print
On Wed, 14 Aug 2019, Paul B Mahol wrote:
LGTM
Thanks for all the comments, patchset finally applied.
Regards,
Marton
On Mon, Aug 12, 2019 at 10:32 AM Marton Balint wrote:
These functions can be used to print a variable number of strings
consecutively
to the IO context. Unlike av_bprintf, no temporary buffer is necessary.
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavformat/avio.h| 17 +
libavformat/aviobuf.c | 6 ++
libavformat/version.h | 2 +-
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6603a8229e..ba35b847d9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-08-xx - xx - lavf 58.31.100 - avio.h
+ Add avio_print_string_array and avio_print.
+
2019-07-27 - xx - lavu 56.33.100 - tx.h
Add AV_TX_DOUBLE_FFT and AV_TX_DOUBLE_MDCT
diff --git a/libavformat/avio.h b/libavformat/avio.h
index dcb8dcdf93..910e4f1b48 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -574,6 +574,23 @@ int avio_feof(AVIOContext *s);
/** @warning Writes up to 4 KiB per call */
int avio_printf(AVIOContext *s, const char *fmt, ...) av_printf_format(2,
3);
+/**
+ * Write a NULL terminated array of strings to the context.
+ * Usually you don't need to use this function directly but its macro
wrapper,
+ * avio_print.
+ */
+void avio_print_string_array(AVIOContext *s, const char *strings[]);
+
+/**
+ * Write strings (const char *) to the context.
+ * This is a convenience macro around avio_print_string_array and it
+ * automatically creates the string array from the variable argument list.
+ * For simple string concatenations this function is more performant than
using
+ * avio_printf since it does not need a temporary buffer.
+ */
+#define avio_print(s, ...) \
+avio_print_string_array(s, (const char*[]){__VA_ARGS__, NULL})
+
/**
* Force flushing of buffered data.
*
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 2d011027c9..be4c97f827 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1225,6 +1225,12 @@ int avio_printf(AVIOContext *s, const char *fmt,
...)
return ret;
}
+void avio_print_string_array(AVIOContext *s, const char *strings[])
+{
+for(; *strings; strings++)
+avio_write(s, (const unsigned char *)*strings, strlen(*strings));
+}
+
int avio_pause(AVIOContext *s, int pause)
{
if (!s->read_pause)
diff --git a/libavformat/version.h b/libavformat/version.h
index 45efaff9b9..feceaedc08 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with
Chromium)
// Also please add any ticket numbers that you believe might be affected
here
#define LIBAVFORMAT_VERSION_MAJOR 58
-#define LIBAVFORMAT_VERSION_MINOR 30
+#define LIBAVFORMAT_VERSION_MINOR 31
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR,
\
--
2.16.4
___
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 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 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 v1] fftools/ffmpeg_opt: avoid to display the hwaccels name twice
On Sat, 17 Aug 2019, Limin Wang wrote:
On Sat, Aug 17, 2019 at 05:21:33PM +0200, Marton Balint wrote:
On Sat, 17 Aug 2019, Limin Wang wrote:
>
>
>ping, please help to merge the code if it's OK.
>
>On Thu, Aug 15, 2019 at 09:23:45AM +0800, lance.lmw...@gmail.com wrote:
>>From: Limin Wang
>>
>>videotoolbox and qsv have been defined by hw_type_names[] in hwcontext.c
>>
>>Fixes ticket #7464
>>
>>Signed-off-by: Limin Wang
>>---
>> fftools/ffmpeg_opt.c | 6 --
>> 1 file changed, 6 deletions(-)
>>
>>diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
>>index f5ca18a..8baa898 100644
>>--- a/fftools/ffmpeg_opt.c
>>+++ b/fftools/ffmpeg_opt.c
>>@@ -66,12 +66,6 @@
>> }
>>
>> const HWAccel hwaccels[] = {
>>-#if CONFIG_VIDEOTOOLBOX
>>-{ "videotoolbox", videotoolbox_init, HWACCEL_VIDEOTOOLBOX,
AV_PIX_FMT_VIDEOTOOLBOX },
>>-#endif
>>-#if CONFIG_LIBMFX
>>-{ "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
>>-#endif
And what about the init functions which are called? Or other cases
in the code which iterates over hwaccels? Have you tried if
accelerated processing works after your patch?
Yes, I have tested OK with both videotoolbox decode and encode,
ffmpeg_opt.c:842 will invoke av_hwdevice_find_type_by_name(hwaccel);
to get them. For cuvid isn't defined in the hwcontext.c, so keep it
anyway.
The loop in ffmpeg.c:2845 won't find the hwaccel if you remove them from
this list.
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 v3] avfilter/f_select: yuv will use Y plane only for scenecut detect
On Sat, 17 Aug 2019, Limin Wang wrote: ping, please help to merge the code if it's OK. On Tue, Aug 13, 2019 at 09:39:47AM +0800, lance.lmw...@gmail.com wrote: From: Limin Wang Signed-off-by: Limin Wang --- libavfilter/f_select.c | 6 +- tests/ref/fate/filter-metadata-scenedetect | 16 2 files changed, 13 insertions(+), 9 deletions(-) Thanks, pushed with some additional description for the patch. 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] avdevice/decklink: adjust for timecode lag
On 17-08-2019 09:21 PM, Marton Balint wrote: On Sat, 17 Aug 2019, Gyan wrote: On 17-08-2019 08:42 PM, Marton Balint wrote: On Wed, 14 Aug 2019, Marton Balint wrote: On Wed, 14 Aug 2019, Gyan wrote: On 09-08-2019 04:59 PM, Ilinca Tudose wrote: Hi Marton, The issue with the out of sync TC was reproducible on all tapes and decks that we tested. I don't have the exact number now, but a few dozens, less than 100. They all had between 7 and 17 frames out of sync. We were not able to obtain anything more in sync than 7 frames. The TC sync was tested by setting up the deck to "burn" the TC with the image while capturing the content with TC through ffmpeg. We then play the file in a player that supports timecodes and compare the burned-in TC with the one captured in the metadata. We used Decklink quad 2 and several Sony decks: J30, J3, JH3. We tested on multiple decks from each model and confirmed the issue was present + that Gyan's patch seemed to fix it. We have used several types of Betacam tapes and HDCAM tapes. I can not comment on whether this is the best solution, but can confirm it works. Let me know if you need more info. Thanks, ilinca Ping. Sorry, I need a bit more time to investigate. OK, I did a couple of tests myself for HD and SD pal signals, and it seems to me if signal autodetection is used, so no format_code is specified then timecode is readily available in the first frame. I was using BlackMagic SDK 11.1 for testing by the way. Can you confirm the same behaviour with your setup? So, were you able to reproduce the issue _with_ format_code specified? I was able to reproduce the part where after starting the capture the decklink device records empty frames (with flag bmdFrameHasNoInputSource set) for a couple of frames. I was not able to reproduce the part where the timecode was earlier or later available then the first frame of the useful video signal. Ok, thanks. I'll get back when I have more info. Gyan ___ 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] avdevice/decklink: adjust for timecode lag
On Sat, 17 Aug 2019, Gyan wrote: On 17-08-2019 08:42 PM, Marton Balint wrote: On Wed, 14 Aug 2019, Marton Balint wrote: On Wed, 14 Aug 2019, Gyan wrote: On 09-08-2019 04:59 PM, Ilinca Tudose wrote: Hi Marton, The issue with the out of sync TC was reproducible on all tapes and decks that we tested. I don't have the exact number now, but a few dozens, less than 100. They all had between 7 and 17 frames out of sync. We were not able to obtain anything more in sync than 7 frames. The TC sync was tested by setting up the deck to "burn" the TC with the image while capturing the content with TC through ffmpeg. We then play the file in a player that supports timecodes and compare the burned-in TC with the one captured in the metadata. We used Decklink quad 2 and several Sony decks: J30, J3, JH3. We tested on multiple decks from each model and confirmed the issue was present + that Gyan's patch seemed to fix it. We have used several types of Betacam tapes and HDCAM tapes. I can not comment on whether this is the best solution, but can confirm it works. Let me know if you need more info. Thanks, ilinca Ping. Sorry, I need a bit more time to investigate. OK, I did a couple of tests myself for HD and SD pal signals, and it seems to me if signal autodetection is used, so no format_code is specified then timecode is readily available in the first frame. I was using BlackMagic SDK 11.1 for testing by the way. Can you confirm the same behaviour with your setup? So, were you able to reproduce the issue _with_ format_code specified? I was able to reproduce the part where after starting the capture the decklink device records empty frames (with flag bmdFrameHasNoInputSource set) for a couple of frames. I was not able to reproduce the part where the timecode was earlier or later available then the first frame of the useful video signal. 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 v1] fftools/ffmpeg_opt: avoid to display the hwaccels name twice
On Sat, Aug 17, 2019 at 05:21:33PM +0200, Marton Balint wrote:
>
>
> On Sat, 17 Aug 2019, Limin Wang wrote:
>
> >
> >
> >ping, please help to merge the code if it's OK.
> >
> >On Thu, Aug 15, 2019 at 09:23:45AM +0800, lance.lmw...@gmail.com wrote:
> >>From: Limin Wang
> >>
> >>videotoolbox and qsv have been defined by hw_type_names[] in hwcontext.c
> >>
> >>Fixes ticket #7464
> >>
> >>Signed-off-by: Limin Wang
> >>---
> >> fftools/ffmpeg_opt.c | 6 --
> >> 1 file changed, 6 deletions(-)
> >>
> >>diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> >>index f5ca18a..8baa898 100644
> >>--- a/fftools/ffmpeg_opt.c
> >>+++ b/fftools/ffmpeg_opt.c
> >>@@ -66,12 +66,6 @@
> >> }
> >>
> >> const HWAccel hwaccels[] = {
> >>-#if CONFIG_VIDEOTOOLBOX
> >>-{ "videotoolbox", videotoolbox_init, HWACCEL_VIDEOTOOLBOX,
> >>AV_PIX_FMT_VIDEOTOOLBOX },
> >>-#endif
> >>-#if CONFIG_LIBMFX
> >>-{ "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
> >>-#endif
>
> And what about the init functions which are called? Or other cases
> in the code which iterates over hwaccels? Have you tried if
> accelerated processing works after your patch?
Yes, I have tested OK with both videotoolbox decode and encode,
ffmpeg_opt.c:842 will invoke av_hwdevice_find_type_by_name(hwaccel);
to get them. For cuvid isn't defined in the hwcontext.c, so keep it
anyway.
>
> 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".
___
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 6/6] doc/filters.texi: add overlay yuv420p10 format
On Sat, Aug 17, 2019 at 05:27:23PM +0200, Marton Balint wrote: > > On Sat, 17 Aug 2019, Limin Wang wrote: > > >On Thu, Jun 06, 2019 at 03:09:59PM +0800, lance.lmw...@gmail.com wrote: > >ping it also, I can update to master if it's necessary. > > > >>From: Limin Wang > >> > >>Signed-off-by: Limin Wang > >>--- > >> doc/filters.texi | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >>diff --git a/doc/filters.texi b/doc/filters.texi > >>index 5db8e0302f..b0e951c9f9 100644 > >>--- a/doc/filters.texi > >>+++ b/doc/filters.texi > >>@@ -13159,6 +13159,9 @@ It accepts the following values: > >> @item yuv420 > >> force YUV420 output > >> > >>+@item yuv420p10 > >>+force YUV420p10 output > >>+ > > Does the overlay filter supports yuv420p10 output? Yes, they're serial patches, patch#1-#5 are support it. > > 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". ___ 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/8] avcodec/cinepak: Require 1 bit per 4x4 block as minimum input
On Sat, Aug 17, 2019 at 12:26:27AM +0200, Tomas Härdin wrote:
> fre 2019-08-16 klockan 14:57 +0200 skrev Tomas Härdin:
> > fre 2019-08-16 klockan 00:50 +0200 skrev Michael Niedermayer:
> > > On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> > > > ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > > > > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > > > > Fixes: Timeout (12sec -> 32ms)
> > > > > > Fixes: 16078/clusterfuzz-testcase-minimized-
> > > > > > ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296
> > > > > > [...]
> > > > > > +if (s->size < (s->avctx->width * s->avctx->height) / (4*4*8))
> > > > > > +return AVERROR_INVALIDDATA;
> > > > >
> > > > > This is wrong if num_strips == 0, and if the MB area is != 0 mod 8.
> > > > > You
> > > > > could merge it with the check above into something like:
> > > > >
> > > > > if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12 +
> > > > > (num_strips ? ((s->avctx->width * s->avctx->height) / 16 + 7)/8 :
> > > > > 0)) {
> > > > > return AVERROR_INVALIDDATA;
> > > > > }
> > > > >
> > > > > The check further down could also check each strip's size, not just
> > > > > the
> > > > > first one.
> > > >
> > > > Actually, thinking a bit more about this, I suspect it might be legal
> > > > to have strips that don't cover the entire frame. It would certainly be
> > > > good to support that, for optimizing skip frames. Not sure what old
> > > > decoders make of that however. A skip could potentially be encoded in
> > > > 22 + (width/4 + 7)/8 bytes while still being compatible.
> > >
> > > i was asking myself the same questions before writing the patch, and
> > > in the "spec" there is
> > > "Each frame is segmented into 4x4 pixel blocks, and each block is coded
> > > using either 1 or 4 vectors."
> > > "Each" meaning no holes to me. If thats actually true for all real files
> > > that i do not know.
> >
> > We should keep in mind the spec is fine with there being zero strips.
> > It's only if one wants to support certain decoders that there will/must
> > be one or more strips.
>
> I've been playing around with the Windows 3.1 cinepak decoder, and it
> seems one indeed has to code every MB even if they don't change. I
> suspect the reason is because that decoder uses double buffering and
> they wanted to avoid doing more memcpy()s than absolutely necessary. If
> one tries to play tricks like coding strips that are only 4x4 pixels to
> indicate a frame without changes then parts of the video will be
> replaced by garbage. So demanding number_of_bits >= number_of_mbs is
> certainly in line with that decoder.
>
> I feel I should point out that being conservative here is at odds with
> the general "best effort" approach taken in this project. These toy
> codecs are useful as illustrative examples of this contradiction. I'm
> sure there are many more examples of files that can cause ffmpeg to do
> a lot more work than expected, for almost every codec. I know afl-fuzz
> is likely to find out that it can make the ZMBV decoder do a lot of
> work for a small input file, because I've seen it do that with gzip.
>
> The user base for cinepak is of course miniscule, so I doubt anyone's
> going to complain that their broken CVID files don't work any more. I
> certainly don't care since cinepakenc only puts out valid files.
> But
> again, for other formats we're just going to have to tell users to put
> ffmpeg inside a sandbox and stick a CPU limit on it. Even ffprobe is
> vulnerable to DoS-y things.
yes
the question ATM is just what to do here about this codec ?
apply the patch ?
change it ?
check the first slice as in:
@@ -359,7 +359,16 @@ static int cinepak_predecode_check (CinepakContext *s)
if (num_strips) {
const uint8_t *data = s->data + 10 + s->sega_film_skip_bytes;
int strip_size = AV_RB24 (data + 1);
-if (strip_size < 12 || strip_size > encoded_buf_size)
+
+if (!(s->strips[0].y1 = AV_RB16 ([4])))
+s->strips[0].y2 = (s->strips[0].y1 = 0) + AV_RB16 ([8]);
+else
+s->strips[0].y2 = AV_RB16 ([8]);
+
+if (strip_size < 12 || strip_size > encoded_buf_size ||
+s->strips[0].y2 <= s->strips[0].y1 ||
+((s->avctx->width * (int64_t)(s->strips[0].y2 - s->strips[0].y1))
/ 16 + 7)/8 > s->size
+)
return AVERROR_INVALIDDATA;
}
just raise the "threshold" in tools/target_dec_fuzzer.c for cinepak?
something else ?
This is not really a technical question, its a question what is preferred.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- 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
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: adjust for timecode lag
On 17-08-2019 08:42 PM, Marton Balint wrote: On Wed, 14 Aug 2019, Marton Balint wrote: On Wed, 14 Aug 2019, Gyan wrote: On 09-08-2019 04:59 PM, Ilinca Tudose wrote: Hi Marton, The issue with the out of sync TC was reproducible on all tapes and decks that we tested. I don't have the exact number now, but a few dozens, less than 100. They all had between 7 and 17 frames out of sync. We were not able to obtain anything more in sync than 7 frames. The TC sync was tested by setting up the deck to "burn" the TC with the image while capturing the content with TC through ffmpeg. We then play the file in a player that supports timecodes and compare the burned-in TC with the one captured in the metadata. We used Decklink quad 2 and several Sony decks: J30, J3, JH3. We tested on multiple decks from each model and confirmed the issue was present + that Gyan's patch seemed to fix it. We have used several types of Betacam tapes and HDCAM tapes. I can not comment on whether this is the best solution, but can confirm it works. Let me know if you need more info. Thanks, ilinca Ping. Sorry, I need a bit more time to investigate. OK, I did a couple of tests myself for HD and SD pal signals, and it seems to me if signal autodetection is used, so no format_code is specified then timecode is readily available in the first frame. I was using BlackMagic SDK 11.1 for testing by the way. Can you confirm the same behaviour with your setup? So, were you able to reproduce the issue _with_ format_code specified? Gyan ___ 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 6/6] doc/filters.texi: add overlay yuv420p10 format
On Sat, 17 Aug 2019, Limin Wang wrote: On Thu, Jun 06, 2019 at 03:09:59PM +0800, lance.lmw...@gmail.com wrote: ping it also, I can update to master if it's necessary. From: Limin Wang Signed-off-by: Limin Wang --- doc/filters.texi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/filters.texi b/doc/filters.texi index 5db8e0302f..b0e951c9f9 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -13159,6 +13159,9 @@ It accepts the following values: @item yuv420 force YUV420 output +@item yuv420p10 +force YUV420p10 output + Does the overlay filter supports yuv420p10 output? 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 v1] fftools/ffmpeg_opt: avoid to display the hwaccels name twice
On Sat, 17 Aug 2019, Limin Wang wrote:
ping, please help to merge the code if it's OK.
On Thu, Aug 15, 2019 at 09:23:45AM +0800, lance.lmw...@gmail.com wrote:
From: Limin Wang
videotoolbox and qsv have been defined by hw_type_names[] in hwcontext.c
Fixes ticket #7464
Signed-off-by: Limin Wang
---
fftools/ffmpeg_opt.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index f5ca18a..8baa898 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -66,12 +66,6 @@
}
const HWAccel hwaccels[] = {
-#if CONFIG_VIDEOTOOLBOX
-{ "videotoolbox", videotoolbox_init, HWACCEL_VIDEOTOOLBOX,
AV_PIX_FMT_VIDEOTOOLBOX },
-#endif
-#if CONFIG_LIBMFX
-{ "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
-#endif
And what about the init functions which are called? Or other cases in the
code which iterates over hwaccels? Have you tried if accelerated
processing works after your patch?
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 1/8] avcodec/cinepak: Require 1 bit per 4x4 block as minimum input
On Fri, Aug 16, 2019 at 02:57:42PM +0200, Tomas Härdin wrote:
> fre 2019-08-16 klockan 00:50 +0200 skrev Michael Niedermayer:
> > On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> > > ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > > > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > > > Fixes: Timeout (12sec -> 32ms)
> > > > > Fixes: 16078/clusterfuzz-testcase-minimized-
> > > > > ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296
> > > > > [...]
> > > > > +if (s->size < (s->avctx->width * s->avctx->height) / (4*4*8))
> > > > > +return AVERROR_INVALIDDATA;
> > > >
> > > > This is wrong if num_strips == 0, and if the MB area is != 0 mod 8. You
> > > > could merge it with the check above into something like:
> > > >
> > > > if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12 +
> > > > (num_strips ? ((s->avctx->width * s->avctx->height) / 16 + 7)/8 :
> > > > 0)) {
> > > > return AVERROR_INVALIDDATA;
> > > > }
> > > >
> > > > The check further down could also check each strip's size, not just the
> > > > first one.
> > >
> > > Actually, thinking a bit more about this, I suspect it might be legal
> > > to have strips that don't cover the entire frame. It would certainly be
> > > good to support that, for optimizing skip frames. Not sure what old
> > > decoders make of that however. A skip could potentially be encoded in
> > > 22 + (width/4 + 7)/8 bytes while still being compatible.
> >
> > i was asking myself the same questions before writing the patch, and
> > in the "spec" there is
> > "Each frame is segmented into 4x4 pixel blocks, and each block is coded
> > using either 1 or 4 vectors."
> > "Each" meaning no holes to me. If thats actually true for all real files
> > that i do not know.
>
> We should keep in mind the spec is fine with there being zero strips.
> It's only if one wants to support certain decoders that there will/must
> be one or more strips.
>
> I don't have any way of testing the MacOS decoder, but the old Win3.1
> decoder is easy enough to get running. Then I can also check whether
> strips narrower than avctx->width are OK.
>
> > > I'd replace s->avctx->height in the expression with the height of the
> > > first strip, to not constrain things too much.
> >
> > ill post a patch doing that
>
> I feel like a better fix would be to make the decoder not choke on the
> kind of files that trigger this. With this style of check it's still
> possible to insert a second strip that triggers the slowness, with a
> trivially sized strip before it.
>
> Would you mind sending me the sample?
will send it privatly
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
signature.asc
Description: 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] avdevice/decklink: adjust for timecode lag
On Wed, 14 Aug 2019, Marton Balint wrote: On Wed, 14 Aug 2019, Gyan wrote: On 09-08-2019 04:59 PM, Ilinca Tudose wrote: Hi Marton, The issue with the out of sync TC was reproducible on all tapes and decks that we tested. I don't have the exact number now, but a few dozens, less than 100. They all had between 7 and 17 frames out of sync. We were not able to obtain anything more in sync than 7 frames. The TC sync was tested by setting up the deck to "burn" the TC with the image while capturing the content with TC through ffmpeg. We then play the file in a player that supports timecodes and compare the burned-in TC with the one captured in the metadata. We used Decklink quad 2 and several Sony decks: J30, J3, JH3. We tested on multiple decks from each model and confirmed the issue was present + that Gyan's patch seemed to fix it. We have used several types of Betacam tapes and HDCAM tapes. I can not comment on whether this is the best solution, but can confirm it works. Let me know if you need more info. Thanks, ilinca Ping. Sorry, I need a bit more time to investigate. OK, I did a couple of tests myself for HD and SD pal signals, and it seems to me if signal autodetection is used, so no format_code is specified then timecode is readily available in the first frame. I was using BlackMagic SDK 11.1 for testing by the way. Can you confirm the same behaviour with your setup? Because that would make the patch uneeded I believe. 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 v2] avfilter/showinfo: support Content Light Level information
ping, please help to merge the code.
On Sat, Aug 10, 2019 at 10:58:30PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> show real information instead of the unknown side data type message for HDR10
> stream
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_showinfo.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index 9fa322e..94d17bf 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -160,6 +160,20 @@ static void dump_mastering_display(AVFilterContext *ctx,
> AVFrameSideData *sd)
> av_q2d(mastering_display->min_luminance),
> av_q2d(mastering_display->max_luminance));
> }
>
> +static void dump_content_light_metadata(AVFilterContext *ctx,
> AVFrameSideData *sd)
> +{
> +AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
> +
> +if (sd->size < sizeof(*metadata)) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> +return;
> +}
> +
> +av_log(ctx, AV_LOG_INFO, "Content Light Level information: "
> + "MaxCLL=%d, MaxFALL=%d",
> + metadata->MaxCLL, metadata->MaxFALL);
> +}
> +
> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> {
> const char *color_range_str =
> av_color_range_name(frame->color_range);
> @@ -301,6 +315,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
> dump_mastering_display(ctx, sd);
> break;
> +case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL:
> +dump_content_light_metadata(ctx, sd);
> +break;
> default:
> av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> bytes)",
> sd->type, sd->size);
> --
> 2.6.4
>
___
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 6/6] doc/filters.texi: add overlay yuv420p10 format
On Thu, Jun 06, 2019 at 03:09:59PM +0800, lance.lmw...@gmail.com wrote: ping it also, I can update to master if it's necessary. > From: Limin Wang > > Signed-off-by: Limin Wang > --- > doc/filters.texi | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/filters.texi b/doc/filters.texi > index 5db8e0302f..b0e951c9f9 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -13159,6 +13159,9 @@ It accepts the following values: > @item yuv420 > force YUV420 output > > +@item yuv420p10 > +force YUV420p10 output > + > @item yuv422 > force YUV422 output > > -- > 2.21.0 > ___ 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 2/2] lavf/dump: add the valid check for consistent
ping, please help to merge the code if it's OK.
On Sat, Aug 10, 2019 at 11:53:25PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/dump.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 68ce9a8..4b18032 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -328,6 +328,11 @@ static void dump_cpb(void *ctx, AVPacketSideData *sd)
>
> static void dump_mastering_display_metadata(void *ctx, AVPacketSideData* sd)
> {
> AVMasteringDisplayMetadata* metadata =
> (AVMasteringDisplayMetadata*)sd->data;
> +
> +if (sd->size < sizeof(*metadata)) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> +return;
> +}
> av_log(ctx, AV_LOG_INFO, "Mastering Display Metadata, "
> "has_primaries:%d has_luminance:%d "
> "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, %5.4f) "
> @@ -346,6 +351,11 @@ static void dump_mastering_display_metadata(void *ctx,
> AVPacketSideData* sd) {
> static void dump_content_light_metadata(void *ctx, AVPacketSideData* sd)
> {
> AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
> +
> +if (sd->size < sizeof(*metadata)) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> +return;
> +}
> av_log(ctx, AV_LOG_INFO, "Content Light Level Metadata, "
> "MaxCLL=%d, MaxFALL=%d",
> metadata->MaxCLL, metadata->MaxFALL);
> --
> 2.6.4
>
___
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] avfilter/showinfo: support Content Light Level information
ping, please help to merge the code if it's OK.
On Sat, Aug 10, 2019 at 10:58:30PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> show real information instead of the unknown side data type message for HDR10
> stream
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_showinfo.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index 9fa322e..94d17bf 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -160,6 +160,20 @@ static void dump_mastering_display(AVFilterContext *ctx,
> AVFrameSideData *sd)
> av_q2d(mastering_display->min_luminance),
> av_q2d(mastering_display->max_luminance));
> }
>
> +static void dump_content_light_metadata(AVFilterContext *ctx,
> AVFrameSideData *sd)
> +{
> +AVContentLightMetadata* metadata = (AVContentLightMetadata*)sd->data;
> +
> +if (sd->size < sizeof(*metadata)) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data");
> +return;
> +}
> +
> +av_log(ctx, AV_LOG_INFO, "Content Light Level information: "
> + "MaxCLL=%d, MaxFALL=%d",
> + metadata->MaxCLL, metadata->MaxFALL);
> +}
> +
> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> {
> const char *color_range_str =
> av_color_range_name(frame->color_range);
> @@ -301,6 +315,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
> dump_mastering_display(ctx, sd);
> break;
> +case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL:
> +dump_content_light_metadata(ctx, sd);
> +break;
> default:
> av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> bytes)",
> sd->type, sd->size);
> --
> 2.6.4
>
___
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 1/3] avfilter/vsrc_mptestsrc: add options to set the maximum number of frames
ping, please help to merge the code if it's OK.
On Mon, Aug 12, 2019 at 11:39:51PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/filters.texi | 3 +++
> libavfilter/vsrc_mptestsrc.c | 29 +
> 2 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index e081cdc..902e5bf 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -20246,6 +20246,9 @@ Set the number or the name of the test to perform.
> Supported tests are:
> @item ring2
> @item all
>
> +@item max_frames, m
> +Set the maximum number of frames generated for each test, default value is
> 30.
> +
> @end table
>
> Default value is "all", which will cycle through the list of all tests.
> diff --git a/libavfilter/vsrc_mptestsrc.c b/libavfilter/vsrc_mptestsrc.c
> index c5fdea7..4a2db18 100644
> --- a/libavfilter/vsrc_mptestsrc.c
> +++ b/libavfilter/vsrc_mptestsrc.c
> @@ -54,6 +54,7 @@ typedef struct MPTestContext {
> const AVClass *class;
> AVRational frame_rate;
> int64_t pts, max_pts, duration;
> +int64_t max_frames;
> int hsub, vsub;
> int test; ///< test_type
> } MPTestContext;
> @@ -79,6 +80,10 @@ static const AVOption mptestsrc_options[]= {
> { "ring1", "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_RING1},
> INT_MIN, INT_MAX, FLAGS, "test" },
> { "ring2", "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_RING2},
> INT_MIN, INT_MAX, FLAGS, "test" },
> { "all", "", 0, AV_OPT_TYPE_CONST, {.i64=TEST_ALL},
> INT_MIN, INT_MAX, FLAGS, "test" },
> +{ "max_frames", "Set the maximum number of frames generated for each
> test", OFFSET(max_frames),
> +AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
> +{ "m", "Set the maximum number of frames generated for each
> test", OFFSET(max_frames),
> +AV_OPT_TYPE_INT, {.i64 = 30}, 1, INT64_MAX, FLAGS },
> { NULL }
> };
>
> @@ -322,20 +327,20 @@ static int request_frame(AVFilterLink *outlink)
> memset(picref->data[2] + i*picref->linesize[2], 128, cw);
> }
>
> -if (tt == TEST_ALL && frame%30) /* draw a black frame at the beginning
> of each test */
> -tt = (frame/30)%(TEST_NB-1);
> +if (tt == TEST_ALL && frame%test->max_frames) /* draw a black frame at
> the beginning of each test */
> +tt = (frame/test->max_frames)%(TEST_NB-1);
>
> switch (tt) {
> -case TEST_DC_LUMA: dc_test(picref->data[0], picref->linesize[0],
> 256, 256, frame%30); break;
> -case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1],
> 256, 256, frame%30); break;
> -case TEST_FREQ_LUMA: freq_test(picref->data[0], picref->linesize[0],
> frame%30); break;
> -case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1],
> frame%30); break;
> -case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0],
> frame%30); break;
> -case TEST_AMP_CHROMA: amp_test(picref->data[1], picref->linesize[1],
> frame%30); break;
> -case TEST_CBP: cbp_test(picref->data , picref->linesize ,
> frame%30); break;
> -case TEST_MV:mv_test(picref->data[0], picref->linesize[0],
> frame%30); break;
> -case TEST_RING1: ring1_test(picref->data[0], picref->linesize[0],
> frame%30); break;
> -case TEST_RING2: ring2_test(picref->data[0], picref->linesize[0],
> frame%30); break;
> +case TEST_DC_LUMA: dc_test(picref->data[0], picref->linesize[0],
> 256, 256, frame%test->max_frames); break;
> +case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1],
> 256, 256, frame%test->max_frames); break;
> +case TEST_FREQ_LUMA: freq_test(picref->data[0], picref->linesize[0],
> frame%test->max_frames); break;
> +case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1],
> frame%test->max_frames); break;
> +case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0],
> frame%test->max_frames); break;
> +case TEST_AMP_CHROMA: amp_test(picref->data[1], picref->linesize[1],
> frame%test->max_frames); break;
> +case TEST_CBP: cbp_test(picref->data , picref->linesize ,
> frame%test->max_frames); break;
> +case TEST_MV:mv_test(picref->data[0], picref->linesize[0],
> frame%test->max_frames); break;
> +case TEST_RING1: ring1_test(picref->data[0], picref->linesize[0],
> frame%test->max_frames); break;
> +case TEST_RING2: ring2_test(picref->data[0], picref->linesize[0],
> frame%test->max_frames); break;
> }
>
> return ff_filter_frame(outlink, picref);
> --
> 2.6.4
>
___
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
Re: [FFmpeg-devel] [PATCH v3] avfilter/f_select: yuv will use Y plane only for scenecut detect
ping, please help to merge the code if it's OK.
On Tue, Aug 13, 2019 at 09:39:47AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/f_select.c | 6 +-
> tests/ref/fate/filter-metadata-scenedetect | 16
> 2 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
> index 5c7372c976..755e10a399 100644
> --- a/libavfilter/f_select.c
> +++ b/libavfilter/f_select.c
> @@ -209,9 +209,13 @@ static int config_input(AVFilterLink *inlink)
> {
> SelectContext *select = inlink->dst->priv;
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
> +int is_yuv = !(desc->flags & AV_PIX_FMT_FLAG_RGB) &&
> + (desc->flags & AV_PIX_FMT_FLAG_PLANAR) &&
> + desc->nb_components >= 3;
>
> select->bitdepth = desc->comp[0].depth;
> -select->nb_planes = av_pix_fmt_count_planes(inlink->format);
> +select->nb_planes = is_yuv ? 1 : av_pix_fmt_count_planes(inlink->format);
> +
> for (int plane = 0; plane < select->nb_planes; plane++) {
> ptrdiff_t line_size = av_image_get_linesize(inlink->format,
> inlink->w, plane);
> int vsub = desc->log2_chroma_h;
> diff --git a/tests/ref/fate/filter-metadata-scenedetect
> b/tests/ref/fate/filter-metadata-scenedetect
> index 7ce2d6794e..36c033bc0e 100644
> --- a/tests/ref/fate/filter-metadata-scenedetect
> +++ b/tests/ref/fate/filter-metadata-scenedetect
> @@ -1,11 +1,11 @@
> pkt_pts=1620|tag:lavfi.scene_score=1.00
> -pkt_pts=4140|tag:lavfi.scene_score=0.668643
> -pkt_pts=5800|tag:lavfi.scene_score=0.996721
> -pkt_pts=6720|tag:lavfi.scene_score=0.357390
> -pkt_pts=8160|tag:lavfi.scene_score=0.886268
> -pkt_pts=9760|tag:lavfi.scene_score=0.926219
> -pkt_pts=14080|tag:lavfi.scene_score=0.650033
> +pkt_pts=4140|tag:lavfi.scene_score=0.923403
> +pkt_pts=5800|tag:lavfi.scene_score=1.00
> +pkt_pts=6720|tag:lavfi.scene_score=0.475643
> +pkt_pts=8160|tag:lavfi.scene_score=1.00
> +pkt_pts=9760|tag:lavfi.scene_score=1.00
> +pkt_pts=14080|tag:lavfi.scene_score=0.874623
> pkt_pts=15700|tag:lavfi.scene_score=1.00
> -pkt_pts=18500|tag:lavfi.scene_score=0.316402
> -pkt_pts=20040|tag:lavfi.scene_score=0.269509
> +pkt_pts=18500|tag:lavfi.scene_score=0.422509
> +pkt_pts=20040|tag:lavfi.scene_score=0.352360
> pkt_pts=21760|tag:lavfi.scene_score=1.00
> --
> 2.21.0
>
___
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 v1] fftools/ffmpeg_opt: avoid to display the hwaccels name twice
ping, please help to merge the code if it's OK.
On Thu, Aug 15, 2019 at 09:23:45AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> videotoolbox and qsv have been defined by hw_type_names[] in hwcontext.c
>
> Fixes ticket #7464
>
> Signed-off-by: Limin Wang
> ---
> fftools/ffmpeg_opt.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index f5ca18a..8baa898 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -66,12 +66,6 @@
> }
>
> const HWAccel hwaccels[] = {
> -#if CONFIG_VIDEOTOOLBOX
> -{ "videotoolbox", videotoolbox_init, HWACCEL_VIDEOTOOLBOX,
> AV_PIX_FMT_VIDEOTOOLBOX },
> -#endif
> -#if CONFIG_LIBMFX
> -{ "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
> -#endif
> #if CONFIG_CUVID
> { "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA },
> #endif
> --
> 2.6.4
>
___
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] Dolby TrueHD support in ISO BMFF
On 8/17/2019 6:43 AM, Paul B Mahol wrote: > On Fri, Aug 16, 2019 at 11:18 PM James Almer wrote: > >> >> https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdbitstreamswithintheisobasemediafileformat.pdf >> >> There's no software i could find that supports this, so mine is the first >> implementation out there. It's therefore tested with itself :p >> > > We should wait for actual implementation from others. I disagree. We can if you want make the muxer implementation require the -strict experimental mode, but the demuxer one has no reason to be delayed just because no one else wrote theirs. Someone has to be the first after all. > > >> >> James Almer (3): >> avcodec/mlp_parse: move TrueHD channel layout and sample rate related >> code to the header >> avformat/mov: add demuxing support for Dolby TrueHD streams >> avformat/movenc: add muxing support for Dolby TrueHD streams >> >> libavcodec/mlp_parse.c | 50 -- >> libavcodec/mlp_parse.h | 49 + >> libavformat/isom.c | 1 + >> libavformat/mov.c | 34 +++ >> libavformat/movenc.c | 61 +- >> 5 files changed, 144 insertions(+), 51 deletions(-) >> >> -- >> 2.22.0 >> >> ___ >> 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 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 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] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Ok, thanks Moritz.
> On 17 Aug 2019, at 14:10, Moritz Barsnick wrote:
>
>> On Fri, Aug 16, 2019 at 10:35:43 -0700, Ross Nicholson wrote:
>> Need anything else Moritz?
>
> No. I only made one remark ("can't understand your issue"), hoping to
> push things forward with new facts for others to take into
> consideration. I can't and won't judge whether your fix is reasonable
> or required. You'll need to wait for others to look into it.
>
> Moritz
> ___
> 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 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: AVEncodeInfo data structures
Juan De León (12019-08-16):
> AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> AV_FRAME_DATA_ENCODE_INFO.
> The structure stores quantization index for each plane, DC/AC deltas
> for luma and chroma planes, and an array of AVEncodeInfoBlock type
> denoting position, size, and delta quantizer for each block in the
> frame.
> Can be extended to support extraction of other block information.
>
> Signed-off-by: Juan De León
> ---
> libavutil/Makefile | 2 +
> libavutil/encode_info.c | 68 +
> libavutil/encode_info.h | 110
> libavutil/frame.c | 1 +
> libavutil/frame.h | 7 +++
> 5 files changed, 188 insertions(+)
> create mode 100644 libavutil/encode_info.c
> create mode 100644 libavutil/encode_info.h
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 57e6e3d7e8..37cfb099e9 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -24,6 +24,7 @@ HEADERS = adler32.h
> \
>dict.h\
>display.h \
>downmix_info.h\
> + encode_info.h \
>encryption_info.h \
>error.h \
>eval.h\
> @@ -111,6 +112,7 @@ OBJS = adler32.o
> \
> dict.o \
> display.o\
> downmix_info.o \
> + encode_info.o\
> encryption_info.o\
> error.o \
> eval.o \
> diff --git a/libavutil/encode_info.c b/libavutil/encode_info.c
> new file mode 100644
> index 00..ec352a403b
> --- /dev/null
> +++ b/libavutil/encode_info.c
> @@ -0,0 +1,68 @@
> +/*
> + * 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/encode_info.h"
> +#include "libavutil/mem.h"
> +
> +// To prevent overflow, assumes max number = 1px blocks for 8k video.
> +#define AV_ENCODE_INFO_MAX_BLOCKS 33177600
> +
> +static int init_encode_info_data(AVEncodeInfoFrame *info, unsigned int
> nb_blocks) {
> +info->nb_blocks = nb_blocks;
> +info->block_size = sizeof(AVEncodeInfoBlock);
> +info->blocks_offset = offsetof(AVEncodeInfoFrame, blocks);
> +
> +for(int i = 0; i < AV_NUM_DATA_POINTERS; i++)
> +info->plane_q[i] = -1;
> +
> +return 0;
> +}
> +
> +AVEncodeInfoFrame *av_encode_info_alloc(unsigned int nb_blocks)
> +{
> +if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
> +return NULL;
> +
> +//AVEncodeInfoFrame already allocates size for one element of
> AVEncodeInfoBlock
> +size_t size = sizeof(AVEncodeInfoFrame) +
> sizeof(AVEncodeInfoBlock)*FFMAX((int)(nb_blocks - 1), 0);
(Commenting from my phone because urgent.)
This line do not make sense to me. Can you explain the reason for the
cast and how you avoid overflows?
> +AVEncodeInfoFrame *ptr = av_mallocz(size);
> +if (!ptr)
> +return NULL;
> +
> +init_encode_info_data(ptr, nb_blocks);
> +
> +return ptr;
> +}
> +
> +AVEncodeInfoFrame *av_encode_info_create_side_data(AVFrame *frame, unsigned
> int nb_blocks)
> +{
> +if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
> +return NULL;
> +
> +size_t size = sizeof(AVEncodeInfoFrame) +
> sizeof(AVEncodeInfoBlock)*FFMAX((int)(nb_blocks - 1), 0);
> +AVFrameSideData *sd = av_frame_new_side_data(frame,
> + AV_FRAME_DATA_ENCODE_INFO,
> + size);
> +if (!sd)
> +
Re: [FFmpeg-devel] [PATCH 7/7] avcodec/truemotion2: Fix multiple integer overflows in
On Thu, Aug 15, 2019 at 23:49:15 +0200, Michael Niedermayer wrote: > Subject: [FFmpeg-devel] [PATCH 7/7] avcodec/truemotion2: Fix multiple integer > overflows in ... in what? Spurious " in"? Moritz ___ 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] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
On Fri, Aug 16, 2019 at 10:35:43 -0700, Ross Nicholson wrote:
> Need anything else Moritz?
No. I only made one remark ("can't understand your issue"), hoping to
push things forward with new facts for others to take into
consideration. I can't and won't judge whether your fix is reasonable
or required. You'll need to wait for others to look into it.
Moritz
___
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] [CALL] New FFmpeg developers meeting
On 17-08-2019 03:18 PM, Paul B Mahol wrote: Hi, When and how to organize this? What's the agenda? Gyan ___ 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] avutil/pixfmt: Add EBU Tech. 3213-E AVColorPrimaries value
I would like to mention that this set of patches is revised following
previous comments. Since I did not set the version number correctly, it
might have slipped past some people's radars. If there are any further
changes needed, please let me know.
RZ
On 2019-08-11 9:54 a.m., rzu...@tebako.net wrote:
From: Raphaël Zumer
This is an alias for JEDEC P22.
The name associated with the value is also changed
from "jedec-p22" to "ebu3213" to match ITU-T H.273.
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 3 +++
libavutil/pixdesc.c | 2 +-
libavutil/pixfmt.h | 3 ++-
libavutil/version.h | 2 +-
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6603a8229e..f71b0c4a75 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-08-08 - xx - lavu 56.34.100 - pixfmt.h
+ Add EBU Tech. 3213-E AVColorPrimaries value
+
2019-07-27 - xx - lavu 56.33.100 - tx.h
Add AV_TX_DOUBLE_FFT and AV_TX_DOUBLE_MDCT
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index b97b0665b0..05dd4a1e20 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2369,7 +2369,7 @@ static const char * const
color_primaries_names[AVCOL_PRI_NB] = {
[AVCOL_PRI_SMPTE428] = "smpte428",
[AVCOL_PRI_SMPTE431] = "smpte431",
[AVCOL_PRI_SMPTE432] = "smpte432",
-[AVCOL_PRI_JEDEC_P22] = "jedec-p22",
+[AVCOL_PRI_EBU3213] = "ebu3213",
};
static const char * const color_transfer_names[] = {
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 8b54c9415b..d78e863d4b 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -456,7 +456,8 @@ enum AVColorPrimaries {
AVCOL_PRI_SMPTEST428_1 = AVCOL_PRI_SMPTE428,
AVCOL_PRI_SMPTE431= 11, ///< SMPTE ST 431-2 (2011) / DCI P3
AVCOL_PRI_SMPTE432= 12, ///< SMPTE ST 432-1 (2010) / P3 D65 / Display
P3
-AVCOL_PRI_JEDEC_P22 = 22, ///< JEDEC P22 phosphors
+AVCOL_PRI_EBU3213 = 22, ///< EBU Tech. 3213-E / JEDEC P22 phosphors
+AVCOL_PRI_JEDEC_P22 = AVCOL_PRI_EBU3213,
AVCOL_PRI_NB///< Not part of ABI
};
diff --git a/libavutil/version.h b/libavutil/version.h
index ecc6a7c9e2..658a508284 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 33
+#define LIBAVUTIL_VERSION_MINOR 34
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
___
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/1] avformat/matroska: fully parse stsd atom in v_quicktime tracks
Hi!
On Sat, Aug 17, 2019 at 12:53 AM Michael Niedermayer
wrote:
>
> On Thu, Aug 15, 2019 at 07:59:28AM +0200, Stanislav Ionascu wrote:
> > Hi,
> >
> > On Wed, Aug 14, 2019 at 11:50 PM Michael Niedermayer
> > wrote:
> > >
> > > On Wed, Aug 14, 2019 at 08:44:11PM +0200, Stanislav Ionascu wrote:
> > > > On Tue, Aug 13, 2019 at 10:22 PM Andreas Rheinhardt
> > > > wrote:
> > > > >
> > > > > Stanislav Ionascu:
> > > > > > Per matroska spec, v_quicktime contains the complete stsd atom,
> > > > > > after
> > > > > > the mandatory size + fourcc. By properly parsing the hvcc sub-atoms
> > > > > > of
> > > > > > the track, it becomes possible to demux/decode mp4/mov tracks
> > > > > > stored as is
> > > > > > in matroska containers.
> > > > > >
> > > > > > Also dvh1 in stsd in matroska is more likely hevc codec than dv.
> > > > > >
> > > > > > Signed-off-by: Stanislav Ionascu
> > > > > > ---
> > > > > > libavformat/matroskadec.c | 51
> > > > > > +++
> > > > > > 1 file changed, 36 insertions(+), 15 deletions(-)
> > > > > >
> > > > > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > > > > > index 4e20f15792..88bc89c545 100644
> > > > > > --- a/libavformat/matroskadec.c
> > > > > > +++ b/libavformat/matroskadec.c
> > > > > > @@ -2473,25 +2473,46 @@ static int
> > > > > > matroska_parse_tracks(AVFormatContext *s)
> > > > > > } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
> > > > > > (track->codec_priv.size >= 21) &&
> > > > > > (track->codec_priv.data)) {
> > > > > > +MOVStreamContext *msc;
> > > > > > +MOVContext *mc = NULL;
> > > > > > +AVIOContext *stsd_ctx = NULL;
> > > > > > +void *priv_data;
> > > > > > +int nb_streams;
> > > > > > int ret = get_qt_codec(track, , _id);
> > > > > > if (ret < 0)
> > > > > > return ret;
> > > > > > -if (codec_id == AV_CODEC_ID_NONE &&
> > > > > > AV_RL32(track->codec_priv.data+4) == AV_RL32("SMI ")) {
> > > > > > -fourcc = MKTAG('S','V','Q','3');
> > > > > > -codec_id = ff_codec_get_id(ff_codec_movvideo_tags,
> > > > > > fourcc);
> > > > > > +av_log(matroska->ctx, AV_LOG_TRACE,
> > > > > > + "FourCC found %s.\n", av_fourcc2str(fourcc));
> > > > > > +priv_data = st->priv_data;
> > > > > > +nb_streams = s->nb_streams;
> > > > > > +mc = av_mallocz(sizeof(*mc));
> > > > > > +if (!mc)
> > > > > > +return AVERROR(ENOMEM);
> > > > > > +stsd_ctx = avio_alloc_context(track->codec_priv.data,
> > > > > > +track->codec_priv.size,
> > > > > > +0, NULL, NULL, NULL, NULL);
> > > > > > +if (!stsd_ctx)
> > > > > > +return AVERROR(ENOMEM);
> > > > > I haven't looked at this patch deeply yet, but it seems to me that you
> > > > > should rather use ffio_init_context like it is done in the code that
> > > > > you intend to delete. That saves allocating and freeing stsd_ctx. You
> > > > > can even reuse the AVIOContext b that already exists on the stack.
> > > >
> > > > Done.
> > > >
> > > > > > +mc->fc = s;
> > > > > > +st->priv_data = msc =
> > > > > > av_mallocz(sizeof(MOVStreamContext));
> > > > > > +if (!msc) {
> > > > > > +av_free(mc);
> > > > > > +st->priv_data = priv_data;
> > > > > > +return AVERROR(ENOMEM);
> > > > > > }
> > > > > > -if (codec_id == AV_CODEC_ID_NONE)
> > > > > > -av_log(matroska->ctx, AV_LOG_ERROR,
> > > > > > - "mov FourCC not found %s.\n",
> > > > > > av_fourcc2str(fourcc));
> > > > > > -if (track->codec_priv.size >= 86) {
> > > > > > -bit_depth = AV_RB16(track->codec_priv.data + 82);
> > > > > > -ffio_init_context(, track->codec_priv.data,
> > > > > > - track->codec_priv.size,
> > > > > > - 0, NULL, NULL, NULL, NULL);
> > > > > > -if (ff_get_qtpalette(codec_id, ,
> > > > > > track->palette)) {
> > > > > > -bit_depth &= 0x1F;
> > > > > > -track->has_palette = 1;
> > > > > Why are you removing this code? What about tracks that ought to have a
> > > > > palette?
> > > >
> > > > The palette parsing is done in the stsd parser, but it still has to be
> > > > copied back into the track,
> > > > which is done in the later patch.
> > > >
> > > > > > -}
> > > > > > +/* ff_mov_read_stsd_entries updates stream
> > > > > > s->nb_streams-1,
> > > > > > + * so set it temporarily to indicate which stream to
> > > > > > update. */
> > > > > > +
[FFmpeg-devel] [CALL] New FFmpeg developers meeting
Hi, When and how to organize this? ___ 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] Dolby TrueHD support in ISO BMFF
On Fri, Aug 16, 2019 at 11:18 PM James Almer wrote: > > https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdbitstreamswithintheisobasemediafileformat.pdf > > There's no software i could find that supports this, so mine is the first > implementation out there. It's therefore tested with itself :p > We should wait for actual implementation from others. > > James Almer (3): > avcodec/mlp_parse: move TrueHD channel layout and sample rate related > code to the header > avformat/mov: add demuxing support for Dolby TrueHD streams > avformat/movenc: add muxing support for Dolby TrueHD streams > > libavcodec/mlp_parse.c | 50 -- > libavcodec/mlp_parse.h | 49 + > libavformat/isom.c | 1 + > libavformat/mov.c | 34 +++ > libavformat/movenc.c | 61 +- > 5 files changed, 144 insertions(+), 51 deletions(-) > > -- > 2.22.0 > > ___ > 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 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".
