Re: [FFmpeg-devel] Is it possible to run just a single FATE test?
On 4/4/2019 5:52 PM, Carl Eugen Hoyos wrote: 2019-04-05 2:45 GMT+02:00, Allan Cady via ffmpeg-devel Try for example: $ make SAMPLES=fate-suite fate-xtea $ make SAMPLES=fate-suite fate-h264 $ make fate-acodec-flac $ make fate-vsynth1 and also $ make SAMPLES=fate-suite fate-list Excellent, that works. Thank you. ___ 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] Is it possible to run just a single FATE test?
2019-04-05 2:45 GMT+02:00, Allan Cady via ffmpeg-devel : > Is it possible to run just a single FATE test against local code while doing > development, rather than running the entire test suite, to speed up the > iteration cycle? Try for example: $ make SAMPLES=fate-suite fate-xtea $ make SAMPLES=fate-suite fate-h264 $ make fate-acodec-flac $ make fate-vsynth1 and also $ make SAMPLES=fate-suite fate-list Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is it possible to run just a single FATE test?
On 4/4/2019 9:45 PM, Allan Cady via ffmpeg-devel wrote: > Is it possible to run just a single FATE test against local code while doing > development, rather than running the entire test suite, to speed up the > iteration cycle? I expect it is, but I don't see how explained in the > documentation. Would appreciate a clue if this is possible. > Thanks. Just call make with the name of the test. For example, fate-imc. ___ 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] Is it possible to run just a single FATE test?
Is it possible to run just a single FATE test against local code while doing development, rather than running the entire test suite, to speed up the iteration cycle? I expect it is, but I don't see how explained in the documentation. Would appreciate a clue if this is possible. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/agm: Fix integer overflow with w/h
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an
unsigned type to negate this value to itself
Fixes:
13999/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5644405991538688
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/agm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/agm.c b/libavcodec/agm.c
index 2d209d..cbd45e8095 100644
--- a/libavcodec/agm.c
+++ b/libavcodec/agm.c
@@ -535,11 +535,13 @@ static int decode_frame(AVCodecContext *avctx, void *data,
s->flags = 0;
w = bytestream2_get_le32(gbyte);
+h = bytestream2_get_le32(gbyte);
+if (w == INT32_MIN || h == INT32_MIN)
+return AVERROR_INVALIDDATA;
if (w < 0) {
w = -w;
s->flags |= 2;
}
-h = bytestream2_get_le32(gbyte);
if (h < 0) {
h = -h;
s->flags |= 1;
--
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] tests: don't include TARGET_PATH in the sample path needlessly
On 4/3/2019 7:17 PM, Hendrik Leppkes wrote: > The transcode() helper function will already prepend the TARGET_PATH to > the sample path, if its a relative path. This avoids an issue on > Windows, where the relative path check could fail. > --- > tests/fate/ffmpeg.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > index af7282f9ab..71ab2f1f63 100644 > --- a/tests/fate/ffmpeg.mak > +++ b/tests/fate/ffmpeg.mak > @@ -95,7 +95,7 @@ fate-copy-trac2211-avi: CMD = transcode "h264 -r 14" > $(TARGET_SAMPLES)/h264/bbc2 > > FATE_STREAMCOPY-$(call ENCDEC, APNG, APNG) += fate-copy-apng > fate-copy-apng: fate-lavf-apng > -fate-copy-apng: CMD = transcode apng > "$(TARGET_PATH)/tests/data/lavf/lavf.apng" apng "-c:v copy" > +fate-copy-apng: CMD = transcode apng tests/data/lavf/lavf.apng apng "-c:v > copy" Should be ok, thanks. > > FATE_STREAMCOPY-$(call DEMMUX, OGG, OGG) += fate-limited_input_seek > fate-limited_input_seek-copyts > fate-limited_input_seek: $(TARGET_SAMPLES)/vorbis/moog_small.ogg > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils: Use av_packet_move_ref for packet ownership transfer
On Thu, Apr 04, 2019 at 10:55:03AM -0400, Andriy Gelman wrote: > From: Andriy Gelman > > This commit replaces packet assignment operator with av_packet_move_ref when > there > is a packet ownership transfer. > --- > > Aims to address a TODO in libavformat/utils.c about using av_packet_mov_ref > instead of assignment operator. > > libavformat/utils.c | 28 +++- > 1 file changed, 15 insertions(+), 13 deletions(-) this changes the behavior: ./ffprobe ~/tickets/4221/teletext-streams-misrecognized.ts https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4221/teletext-streams-misrecognized.ts before: Stream #0:0[0x65]: Video: mpeg2video (Main), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:1[0x68]: Unknown: none Stream #0:2[0x6a]: Audio: ac3, 48000 Hz, stereo, fltp, 448 kb/s Stream #0:3[0x67]: Audio: mp2, 48000 Hz, stereo, s16p, 192 kb/s Stream #0:4[0x66]: Audio: mp2, 48000 Hz, stereo, s16p, 256 kb/s Stream #0:5[0x69]: Subtitle: dvb_subtitle afterwards: Stream #0:0[0x65]: Video: mpeg2video (Main), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:1[0x68]: Unknown: none Stream #0:2[0x6a]: Audio: ac3, 48000 Hz, stereo, fltp, 448 kb/s Stream #0:3[0x67]: Audio: mp2, 48000 Hz, stereo, s16p, 192 kb/s Stream #0:4[0x66]: Audio: mp2, 48000 Hz, stereo, s16p, 256 kb/s Stream #0:5[0x69]: Unknown: none [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Updated the documentation about the encoding options for libaom-av1 encoder.
On 4/2/2019 9:49 PM, Sam John via ffmpeg-devel wrote:
> ---
> doc/encoders.texi | 46 ++
> 1 file changed, 46 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 94337d009c..a669ac3739 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1434,6 +1434,12 @@ value is 1, which will be slow and high quality.
> Enable use of alternate reference frames. Defaults to the internal
> default of the library.
>
> +@item arnr-max-frames
> +Set altref noise reduction max frame count.
> +
> +@item arnr-strength
> +Set altref noise reduction filter strength.
> +
> @item lag-in-frames
> Set the maximum number of frames which the encoder may keep in flight
> at any one time for lookahead purposes. Defaults to the internal
> @@ -1466,6 +1472,33 @@ buffer falls below this percentage, frames will be
> dropped until it
> has refilled above the threshold. Defaults to zero (no frames are
> dropped).
>
> +@item denoise-noise-level
> +Amount of noise to be removed for grain synthesis. Grain synthesis is
> disabled if
> +it is not set or set to 0.
> +
> +@item denoise-block-size
> +Block size used for denoising for grain synthesis. If not set, AV1 codec
> +uses the default value of 32.
> +
> +@item undershoot-pct
> +Set datarate undershoot (min) percentage of the target bitrate.
> +
> +@item overshoot-pct
> +Set datarate overshoot (max) percentage of the target bitrate.
> +
> +@item maxrate (@emph{maxsection-pct})
> +Set GOP max bitrate in bits/s. Note @command{libaom-av1}'s option
> maxsection-pct is
> +specified as a percentage of the target bitrate. If maxsection-pct is not
> set, the
> +libaomenc wrapper computes it as follows: @code{(maxrate * 100 / bitrate)}.
> +
> +@item minrate (@emph{minsection-pct})
> +Set GOP min bitrate in bits/s. Note @command{libaom-av1}'s option
> minsection-pct is
> +specified as a percentage of the target bitrate. If minsection-pct is not
> set, the
> +libaomenc wrapper computes it as follows: @code{(minrate * 100 / bitrate)}.
> +
> +@item frame-parallel @var{boolean}
> +Enable frame parallel decodability features. The default value is true.
> +
> @item tiles
> Set the number of tiles to encode the input video with, as columns x
> rows. Larger numbers allow greater parallelism in both encoding and
> @@ -1480,6 +1513,19 @@ Provided for compatibility with libvpx/VP9.
> @item row-mt (Requires libaom >= 1.0.0-759-g90a15f4f2)
> Enable row based multi-threading. Disabled by default.
>
> +@item enable-cdef @var{boolean}
> +Flag to enable or disable Constrianed Directional Enhancement Filter. The
> libaom-av1
> +encoder enables CDEF by default.
> +
> +@item enable-global-motion @var{boolean}
> +Flag to enable or disable the use of global motion for block prediction.
> +The default value is true.
> +
> +@item enable-intrabc @var{boolean}
> +Flag to enable or disable block copy mode for intra block prediction. This
> mode is
> +useful for screen content. The default value is true.
Maybe "The libaom-av1 encoder enables global-motion/intrabc by default"
like you did for cdef. For all three the default value is -1, meaning up
to the library.
> +
> +
> @end table
>
> @section libkvazaar
>
___
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] Updated the documentation about the encoding options for libaom-av1 encoder.
On 03-04-2019 06:19 AM, Sam John via ffmpeg-devel wrote:
---
doc/encoders.texi | 46 ++
1 file changed, 46 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 94337d009c..a669ac3739 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1434,6 +1434,12 @@ value is 1, which will be slow and high quality.
Enable use of alternate reference frames. Defaults to the internal
default of the library.
+@item arnr-max-frames
+Set altref noise reduction max frame count.
+
+@item arnr-strength
+Set altref noise reduction filter strength.
+
@item lag-in-frames
Set the maximum number of frames which the encoder may keep in flight
at any one time for lookahead purposes. Defaults to the internal
@@ -1466,6 +1472,33 @@ buffer falls below this percentage, frames will be
dropped until it
has refilled above the threshold. Defaults to zero (no frames are
dropped).
+@item denoise-noise-level
+Amount of noise to be removed for grain synthesis. Grain synthesis is disabled
if
+it is not set or set to 0.
+
+@item denoise-block-size
+Block size used for denoising for grain synthesis. If not set, AV1 codec
+uses the default value of 32.
+
+@item undershoot-pct
+Set datarate undershoot (min) percentage of the target bitrate.
+
+@item overshoot-pct
+Set datarate overshoot (max) percentage of the target bitrate.
+
+@item maxrate (@emph{maxsection-pct})
+Set GOP max bitrate in bits/s. Note @command{libaom-av1}'s option
maxsection-pct is
+specified as a percentage of the target bitrate. If maxsection-pct is not set,
the
+libaomenc wrapper computes it as follows: @code{(maxrate * 100 / bitrate)}.
+
+@item minrate (@emph{minsection-pct})
+Set GOP min bitrate in bits/s. Note @command{libaom-av1}'s option
minsection-pct is
+specified as a percentage of the target bitrate. If minsection-pct is not set,
the
+libaomenc wrapper computes it as follows: @code{(minrate * 100 / bitrate)}.
The actual option names should be used for @item. minrate/maxrate are
generic lavc options. The label in @emph describes the units expected.
+@item frame-parallel @var{boolean}
+Enable frame parallel decodability features. The default value is true.
+
@item tiles
Set the number of tiles to encode the input video with, as columns x
rows. Larger numbers allow greater parallelism in both encoding and
@@ -1480,6 +1513,19 @@ Provided for compatibility with libvpx/VP9.
@item row-mt (Requires libaom >= 1.0.0-759-g90a15f4f2)
Enable row based multi-threading. Disabled by default.
+@item enable-cdef @var{boolean}
+Flag to enable or disable Constrianed Directional Enhancement Filter. The
libaom-av1
+encoder enables CDEF by default.
s/Constrianed/Constrained
+@item enable-global-motion @var{boolean}
+Flag to enable or disable the use of global motion for block prediction.
+The default value is true.
+
+@item enable-intrabc @var{boolean}
+Flag to enable or disable block copy mode for intra block prediction. This
mode is
+useful for screen content. The default value is true.
Doc for aq-mode missing.
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".
[FFmpeg-devel] [PATCH] matroskaenc: fix leak on error
---
libavformat/matroskaenc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b9f99c4463..1a06103c5d 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -694,8 +694,10 @@ static int put_flac_codecpriv(AVFormatContext *s,
av_dict_set(, "WAVEFORMATEXTENSIBLE_CHANNEL_MASK", buf, 0);
len = ff_vorbiscomment_length(dict, vendor, NULL, 0);
-if (len >= ((1<<24) - 4))
+if (len >= ((1<<24) - 4)) {
+av_dict_free();
return AVERROR(EINVAL);
+}
data = av_malloc(len + 4);
if (!data) {
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT
On Thu, Apr 04, 2019 at 04:10:35PM +0800, Linjie Fu wrote: > Use the profile constraint flags to determine the exact va_profile for > HEVC_REXT. > > Directly cast PTLCommon to H265RawProfileTierLevel, and use > ff_h265_get_profile > to get the exact profile. > > Signed-off-by: Linjie Fu > --- > [v2]: use constraint flags to determine the exact profile, expose the > codec-specific stuff at the beginning. > [v3]: move the VA version check to fix the compile issue. > [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for > convenience? The members in PTLCommon should be strictly matched in > H265RawProfileTierLevel. > > libavcodec/vaapi_decode.c | 73 +++ > 1 file changed, 58 insertions(+), 15 deletions(-) breaks build with shared libs: libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [ffmpeg_g] Error 1 make: *** Waiting for unfinished jobs libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [ffplay_g] Error 1 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [ffprobe_g] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavf/matroskaenc: Fix memory leak after write trailer
Jun Zhao:
> From: Jun Zhao
>
> Fix memory leak after write trailer for #7827, only store a audio
> packet whose buffer has size greater than zero in cur_audio_pkt.
>
> Thanks to Andreas Rheinhardt for the suggestions.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/matroskaenc.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index b9f99c4..06f3aeb 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2534,7 +2534,8 @@ static int mkv_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> // buffer an audio packet to ensure the packet containing the video
> // keyframe's timecode is contained in the same cluster for WebM
> if (codec_type == AVMEDIA_TYPE_AUDIO) {
> -ret = av_packet_ref(>cur_audio_pkt, pkt);
> +if (pkt->size > 0)
> +ret = av_packet_ref(>cur_audio_pkt, pkt);
> } else
> ret = mkv_write_packet_internal(s, pkt, 0);
> return ret;
>
Seems that I took quite a lot of time to write my commit message. I
don't care which patch gets committed, but I presume you did run
valgrind to make sure that it actually fixes #7827?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/matroskaenc: Fix memleak
Audio packets with size zero, but with side-data currently lead to
memleaks, in the Matroska muxer, because they are not properly freed:
They are currently put into an AVPacket in the MatroskaMuxContext to
ensure that the necessary audio is always available for a new cluster,
but are only written and freed when their size is > 0.
As the only use we have for such packets consists in updating the
CodecPrivate it makes no sense to store these packets at all and this
is how this commit solves the memleak.
Fixes track ticket #7827.
Signed-off-by: Andreas Rheinhardt
---
Could some kind soul please run Valgrind to check that it really fixes
the memleak from #7827?
(I have thought about whether all zero-sized packets (not necessarily
audio packets only) should be discarded at this point, but if I am not
mistaken, then WebVTT subtitles can be side-data-only.)
libavformat/matroskaenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b9f99c4463..06f3aeb46d 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2534,7 +2534,8 @@ static int mkv_write_packet(AVFormatContext *s, AVPacket
*pkt)
// buffer an audio packet to ensure the packet containing the video
// keyframe's timecode is contained in the same cluster for WebM
if (codec_type == AVMEDIA_TYPE_AUDIO) {
-ret = av_packet_ref(>cur_audio_pkt, pkt);
+if (pkt->size > 0)
+ret = av_packet_ref(>cur_audio_pkt, pkt);
} else
ret = mkv_write_packet_internal(s, pkt, 0);
return ret;
--
2.19.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V2] lavf/matroskaenc: Fix memory leak after write trailer
From: Jun Zhao
Fix memory leak after write trailer for #7827, only store a audio
packet whose buffer has size greater than zero in cur_audio_pkt.
Thanks to Andreas Rheinhardt for the suggestions.
Signed-off-by: Jun Zhao
---
libavformat/matroskaenc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b9f99c4..06f3aeb 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2534,7 +2534,8 @@ static int mkv_write_packet(AVFormatContext *s, AVPacket
*pkt)
// buffer an audio packet to ensure the packet containing the video
// keyframe's timecode is contained in the same cluster for WebM
if (codec_type == AVMEDIA_TYPE_AUDIO) {
-ret = av_packet_ref(>cur_audio_pkt, pkt);
+if (pkt->size > 0)
+ret = av_packet_ref(>cur_audio_pkt, pkt);
} else
ret = mkv_write_packet_internal(s, pkt, 0);
return ret;
--
1.7.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] avformat/utils: Use av_packet_move_ref for packet ownership transfer
From: Andriy Gelman
This commit replaces packet assignment operator with av_packet_move_ref when
there
is a packet ownership transfer.
---
Aims to address a TODO in libavformat/utils.c about using av_packet_mov_ref
instead of assignment operator.
libavformat/utils.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 9b3f0d28e6..f757b02d49 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -460,10 +460,7 @@ int ff_packet_list_put(AVPacketList **packet_buffer,
return ret;
}
} else {
-// TODO: Adapt callers in this file so the line below can use
-// av_packet_move_ref() to effectively move the reference
-// to the list.
-pktl->pkt = *pkt;
+av_packet_move_ref(>pkt, pkt);
}
if (*packet_buffer)
@@ -832,19 +829,21 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
{
int ret, i, err;
AVStream *st;
+AVPacket *buffer_pkt; /*view packet contents only. does not take
ownership*/
for (;;) {
AVPacketList *pktl = s->internal->raw_packet_buffer;
if (pktl) {
-*pkt = pktl->pkt;
-st = s->streams[pkt->stream_index];
+buffer_pkt = >pkt;
+st = s->streams[buffer_pkt->stream_index];
if (s->internal->raw_packet_buffer_remaining_size <= 0)
if ((err = probe_codec(s, st, NULL)) < 0)
return err;
if (st->request_probe <= 0) {
s->internal->raw_packet_buffer = pktl->next;
s->internal->raw_packet_buffer_remaining_size += pkt->size;
+av_packet_move_ref(pkt, >pkt);
av_free(pktl);
return 0;
}
@@ -914,14 +913,17 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
if (!pktl && st->request_probe <= 0)
return ret;
+/*transfer pkt ownership to list*/
err = ff_packet_list_put(>internal->raw_packet_buffer,
>internal->raw_packet_buffer_end,
pkt, 0);
if (err)
return err;
-s->internal->raw_packet_buffer_remaining_size -= pkt->size;
-if ((err = probe_codec(s, st, pkt)) < 0)
+buffer_pkt = >internal->raw_packet_buffer_end->pkt;
+s->internal->raw_packet_buffer_remaining_size -= buffer_pkt->size;
+
+if ((err = probe_codec(s, st, buffer_pkt)) < 0)
return err;
}
}
@@ -1662,7 +1664,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (!st->need_parsing || !st->parser) {
/* no parsing needed: we just output the packet as is */
-*pkt = cur_pkt;
+av_packet_move_ref(pkt, _pkt);
compute_pkt_fields(s, st, NULL, pkt, AV_NOPTS_VALUE,
AV_NOPTS_VALUE);
if ((s->iformat->flags & AVFMT_GENERIC_INDEX) &&
(pkt->flags & AV_PKT_FLAG_KEY) && pkt->dts != AV_NOPTS_VALUE) {
@@ -3779,15 +3781,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
break;
}
-pkt =
-
if (!(ic->flags & AVFMT_FLAG_NOBUFFER)) {
ret = ff_packet_list_put(>internal->packet_buffer,
>internal->packet_buffer_end,
- pkt, 0);
+ , 0);
if (ret < 0)
goto find_stream_info_err;
-}
+pkt = >internal->packet_buffer_end->pkt;
+} else
+pkt =
st = ic->streams[pkt->stream_index];
if (!(st->disposition & AV_DISPOSITION_ATTACHED_PIC))
--
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 2/2] avformat/mxfenc: support XAVC long gop
Hi Baptiste,
Am Mi., 3. Apr. 2019 um 11:23 Uhr schrieb Baptiste Coudurier <
baptiste.coudur...@gmail.com>:
> ---
> libavformat/mxf.h| 1 +
> libavformat/mxfenc.c | 197 ---
> 2 files changed, 147 insertions(+), 51 deletions(-)
>
> diff --git a/libavformat/mxf.h b/libavformat/mxf.h
> index 4394450dea..f32124f772 100644
> --- a/libavformat/mxf.h
> +++ b/libavformat/mxf.h
> @@ -48,6 +48,7 @@ enum MXFMetadataSetType {
> EssenceGroup,
> TaggedValue,
> TapeDescriptor,
> +AVCSubDescriptor,
> };
>
> enum MXFFrameLayout {
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 8c6db94865..1f865a0ad1 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -49,7 +49,10 @@
> #include "libavcodec/bytestream.h"
> #include "libavcodec/dnxhddata.h"
> #include "libavcodec/dv_profile.h"
> -#include "libavcodec/h264.h"
> +#include "libavcodec/golomb.h"
> +#include "libavcodec/h264data.h"
> +#include "libavcodec/h264_ps.h"
> +#include "libavcodec/h2645_parse.h"
> #include "libavcodec/internal.h"
> #include "audiointerleave.h"
> #include "avformat.h"
> @@ -99,6 +102,7 @@ typedef struct MXFStreamContext {
> int max_gop; ///< maximum gop size, used by mpeg-2
> descriptor
> int b_picture_count; ///< maximum number of consecutive b
> pictures, used in mpeg-2 descriptor
> int low_delay; ///< low delay, used in mpeg-2 descriptor
> +int avc_intra;
> } MXFStreamContext;
>
> typedef struct MXFContainerEssenceEntry {
> @@ -167,6 +171,7 @@ static const struct {
> static void mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
> static void mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
> static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
> +static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
> static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
> static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream
> *st);
> static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
> @@ -310,7 +315,7 @@ static const MXFContainerEssenceEntry
> mxf_essence_container_uls[] = {
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x10,0x60,0x01
> },
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x00,0x00,0x00
> },
> - mxf_write_mpegvideo_desc },
> + mxf_write_h264_desc },
> // S436M ANC
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x0e,0x00,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00
> },
> @@ -498,6 +503,12 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
> { 0x8006,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
> /* MaxGOP */
> { 0x8007,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
> /* ProfileAndLevel */
> { 0x8008,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
> /* BPictureCount */
> +// Generic Descriptor
> +{ 0x8100,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
> /* SubDescriptors */
> +// AVC SubDescriptor
> +{ 0x8200,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
> /* AVC Decoding Delay */
> +{ 0x8201,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
> /* AVC Profile */
> +{ 0x8202,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
> /* AVC Level */
> // Wave Audio Essence Descriptor
> { 0x3D09,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x03,0x05,0x00,0x00,0x00}},
> /* Average Bytes Per Second */
> { 0x3D0A,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x02,0x01,0x00,0x00,0x00}},
> /* Block Align */
> @@ -1126,6 +1137,8 @@ static const UID mxf_aes3_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,
> static const UID mxf_cdci_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00
> };
> static const UID mxf_generic_sound_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00
> };
>
> +static const UID mxf_avc_subdescriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x6E,0x00
> };
> +
> static int get_trc(UID ul, enum AVColorTransferCharacteristic trc)
> {
> switch (trc){
> @@ -1317,6 +1330,13 @@ static int64_t
> mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID
> avio_w8(pb, sc->field_dominance);
> }
>
> +if (st->codecpar->codec_id == AV_CODEC_ID_H264 && !sc->avc_intra) {
> +// write avc sub descriptor
Re: [FFmpeg-devel] [PATCH] x11grab: fix vertical repositioning
On 4/1/19 11:17 AM, Octavio Alvarez wrote: > On 4/1/19 7:41 AM, Carl Eugen Hoyos wrote: >>> The patch is untested, but it looks fairly straightforward. >> >> How can this patch be tested? > > ffmpeg -y -r 30 -f x11grab -show_region 1 -draw_mouse 0 -s 350x614 > -follow_mouse 10 -i :0.0+0,0 -r 30 -preset ultrafast followcapture-test-.mkv I just tested the patch and it properly works. Octavio. ___ 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] lavf/matroskaenc: Fix memory leak after write trailer
On Thu, Apr 4, 2019 at 3:05 PM Andreas Rheinhardt via ffmpeg-devel wrote: > > And I think that this memleak in mkv_write_trailer() has a twin in > mkv_write_packet(): Audio frames are not written directly, but rather > put into storage in cur_audio_pkt via av_packet_ref(). But if the > preceding audio packet was a zero size packet (but possibly with > side-data), then the preceding packet's side data will leak at this > point. A better solution seems to be never to store a packet whose > buffer has size zero in cur_audio_pkt. The only use we have for such > packets is to use them for mkv_check_new_extra_data() and that has > already been done at this point. > That seems like a good idea. - Hendrik ___ 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] lavf/matroskaenc: Fix memory leak after write trailer
And I think that this memleak in mkv_write_trailer() has a twin in mkv_write_packet(): Audio frames are not written directly, but rather put into storage in cur_audio_pkt via av_packet_ref(). But if the preceding audio packet was a zero size packet (but possibly with side-data), then the preceding packet's side data will leak at this point. A better solution seems to be never to store a packet whose buffer has size zero in cur_audio_pkt. The only use we have for such packets is to use them for mkv_check_new_extra_data() and that has already been done at this point. - 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] ffmpeg: add -drop_deviant_frames option
On 04-04-2019 02:37 AM, Michael Niedermayer wrote: doc/ffmpeg.texi |5 + fftools/ffmpeg.c | 47 +-- fftools/ffmpeg.h |3 +++ fftools/ffmpeg_opt.c |5 + 4 files changed, 58 insertions(+), 2 deletions(-) 71a87fe4d8f2efa73a3d2d9845e7aabfb75edce5 0001-ffmpeg-add-drop_deviant_frames-option.patch From f39e3d44e1cb8108592d2241e2251d8e1506e031 Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Mon, 25 Mar 2019 22:01:07 +0530 Subject: [PATCH] ffmpeg: add -drop_deviant_frames option Decoded frames with changed parameters in inputs expected to be uniform may indicate malformed/corrupted packets. Demuxer with flag discardcorrupt set may not catch all such packets and neither may decoders with err_detect flags set. Upon parameter change, AVFilterLink of any filters receiving such frames has to be reconfigured, destroying existing filter context. In case of a change in audio sample rate, timestamps can go haywire, potentially leaving the output stream to be "truncated". Added option allows users to avoid sending such deviant frames onwards. Default behaviour remains unchanged. --- doc/ffmpeg.texi | 5 + fftools/ffmpeg.c | 47 ++-- fftools/ffmpeg.h | 3 +++ fftools/ffmpeg_opt.c | 5 + 4 files changed, 58 insertions(+), 2 deletions(-) Would it make sense to make this feature available to other applications ? The awnser here has an effect of the design because For example if this is implemented in libavcodec or libavfilter then other applications could use such a feature. While if its in ffmpeg then other applications could not. Could be a useful addition to libavcodec, since not all users may onward process using libavfilter. Looks like avcodec_receive_frame is the place to add this gate. 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 V1] lavf/matroskaenc: Fix memory leak after write trailer
Hendrik Leppkes:
> On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
>>
>> From: Jun Zhao
>>
>> Fix memory leak after write trailer for #7827
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavformat/matroskaenc.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index b9f99c4..22ba93a 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -2571,13 +2571,13 @@ static int mkv_write_trailer(AVFormatContext *s)
>> // check if we have an audio packet cached
>> if (mkv->cur_audio_pkt.size > 0) {
>> ret = mkv_write_packet_internal(s, >cur_audio_pkt, 0);
>> -av_packet_unref(>cur_audio_pkt);
>> if (ret < 0) {
>> av_log(s, AV_LOG_ERROR,
>> "Could not write cached audio packet ret:%d\n", ret);
>> return ret;
>> }
>> }
>> +av_packet_unref(>cur_audio_pkt);
>>
>
> Won't this leak instead when the error path above is triggered?
Yes, it will.
> Also, whats in the packet if it has a size of 0?
>
It contains side-data which is used to update the extradata (the md5
and number of samples etc. that is part of the flac STREAMINFO header).
- 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 V1] lavf/matroskaenc: Fix memory leak after write trailer
On Thu, Apr 4, 2019 at 5:43 PM Hendrik Leppkes wrote:
>
> On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
> >
> > From: Jun Zhao
> >
> > Fix memory leak after write trailer for #7827
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/matroskaenc.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > index b9f99c4..22ba93a 100644
> > --- a/libavformat/matroskaenc.c
> > +++ b/libavformat/matroskaenc.c
> > @@ -2571,13 +2571,13 @@ static int mkv_write_trailer(AVFormatContext *s)
> > // check if we have an audio packet cached
> > if (mkv->cur_audio_pkt.size > 0) {
> > ret = mkv_write_packet_internal(s, >cur_audio_pkt, 0);
> > -av_packet_unref(>cur_audio_pkt);
> > if (ret < 0) {
> > av_log(s, AV_LOG_ERROR,
> > "Could not write cached audio packet ret:%d\n", ret);
> > return ret;
> > }
> > }
> > +av_packet_unref(>cur_audio_pkt);
> >
>
> Won't this leak instead when the error path above is triggered?
> Also, whats in the packet if it has a size of 0?
>
I think is mkv_write_packet() with the codec_type ==
AVMEDIA_TYPE_AUDIO in
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L2537
___
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] lavf/matroskaenc: Fix memory leak after write trailer
On Thu, Apr 4, 2019 at 11:25 AM Jun Zhao wrote:
>
> From: Jun Zhao
>
> Fix memory leak after write trailer for #7827
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/matroskaenc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index b9f99c4..22ba93a 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -2571,13 +2571,13 @@ static int mkv_write_trailer(AVFormatContext *s)
> // check if we have an audio packet cached
> if (mkv->cur_audio_pkt.size > 0) {
> ret = mkv_write_packet_internal(s, >cur_audio_pkt, 0);
> -av_packet_unref(>cur_audio_pkt);
> if (ret < 0) {
> av_log(s, AV_LOG_ERROR,
> "Could not write cached audio packet ret:%d\n", ret);
> return ret;
> }
> }
> +av_packet_unref(>cur_audio_pkt);
>
Won't this leak instead when the error path above is triggered?
Also, whats in the packet if it has a size of 0?
- Hendrik
___
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] avcodec/agm: More completely check size before using it
On Wed, Apr 03, 2019 at 10:14:22AM +0200, Paul B Mahol wrote: > On 4/3/19, Michael Niedermayer wrote: > > Fixes: out of array access > > Fixes: > > 13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/agm.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/agm.c b/libavcodec/agm.c > > index b0e8b80f81..2d209d 100644 > > --- a/libavcodec/agm.c > > +++ b/libavcodec/agm.c > > @@ -562,7 +562,8 @@ static int decode_frame(AVCodecContext *avctx, void > > *data, > > > > for (int i = 0; i < 3; i++) > > s->size[i] = bytestream2_get_le32(gbyte); > > -if (32LL + s->size[0] + s->size[1] + s->size[2] > avpkt->size) > > +if (s->size[0] < 0 || s->size[1] < 0 || s->size[2] < 0 || > > +32LL + s->size[0] + s->size[1] + s->size[2] > avpkt->size) > > return AVERROR_INVALIDDATA; > > > > if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0) > > -- > > 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". > > OK will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] apedec: add ability to check CRC
On Wed, Mar 06, 2019 at 02:47:37PM +0100, Lynne wrote:
> 6 Mar 2019, 11:22 by d...@lynne.ee:
>
> > The CRC flag is only signalled once every few minutes but CRC is still
> > always present so the patch uses the file version instead.
> > CRC on 24-bit files wants non-padded samples so skip such files.
> > Some corrupt samples may have been output before the final check
> > depending on the -max_samples setting.
> >
> v2 attached
> apedec.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
> c0cc550d77927ee0349094a4976f73d0ef671ff6
> 0001-apedec-add-ability-to-check-CRC-v2.patch
> From 68c25bb026761eacda3c276148e2beb34e8929fd Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Wed, 6 Mar 2019 11:01:01 +
> Subject: [PATCH v2] apedec: add ability to check CRC
>
> The CRC flag is only signalled once every few minutes but CRC is still
> always present so the patch uses the file version instead.
> CRC on 24-bit files wants non-padded samples so skip such files.
> Some corrupt samples may have been output before the final check
> depending on the -max_samples setting.
> ---
> libavcodec/apedec.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> index 15eb416ba4..a20d884606 100644
> --- a/libavcodec/apedec.c
> +++ b/libavcodec/apedec.c
> @@ -24,6 +24,7 @@
>
> #include "libavutil/avassert.h"
> #include "libavutil/channel_layout.h"
> +#include "libavutil/crc.h"
> #include "libavutil/opt.h"
> #include "lossless_audiodsp.h"
> #include "avcodec.h"
> @@ -147,7 +148,8 @@ typedef struct APEContext {
> int fset;///< which filter set to use
> (calculated from compression level)
> int flags; ///< global decoder flags
>
> -uint32_t CRC;///< frame CRC
> +uint32_t CRC;///< signalled frame CRC
> +uint32_t CRC_state; ///< accumulated CRC
> int frameflags; ///< frame flags
> APEPredictor predictor; ///< predictor used for final
> reconstruction
>
> @@ -730,6 +732,7 @@ static int init_entropy_decoder(APEContext *ctx)
>
> /* Read the frame flags if they exist */
> ctx->frameflags = 0;
> +ctx->CRC_state = UINT32_MAX;
> if ((ctx->fileversion > 3820) && (ctx->CRC & 0x8000)) {
> ctx->CRC &= ~0x8000;
>
> @@ -1548,6 +1551,27 @@ static int ape_decode_frame(AVCodecContext *avctx,
> void *data,
>
> s->samples -= blockstodecode;
>
> +if ((avctx->err_recognition & AV_EF_CRCCHECK) &&
> +(s->fileversion >= 3900) && (s->bps < 24)) {
what about file versions other than this ? do they have no crc ?
what about othet bps ?
> +uint32_t crc = s->CRC_state;
> +const AVCRC *crc_tab = av_crc_get_table(AV_CRC_32_IEEE_LE);
> +for (i = 0; i < blockstodecode; i++) {
> +for (ch = 0; ch < s->channels; ch++) {
> +uint8_t *smp = frame->data[ch] + (i*(s->bps >> 3));
> +crc = av_crc(crc_tab, crc, smp, s->bps >> 3);
> +}
> +}
> +
> +if (!s->samples && ((~crc >> 1) ^ s->CRC)) {
> +av_log(avctx, AV_LOG_ERROR, "CRC mismatch! Previously decoded "
> + "frames may have been affected as well.\n");
What is the usecase for this ?
the implementation does only check CRC for a subset of files and it could
report them at a time different from where they occur
In practice for a user, that adds some unpredictability to this information
A file may contains CRC errors but no errors would be detected
A file may contain CRC errors but they would be shown too late
A file may contain CRC errors and they are shown at the correct time
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
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 for Reproducing Issue 7827
On Thu, Apr 4, 2019 at 3:12 PM Peter Belkner wrote: > > On 04.04.2019 08:49, myp...@gmail.com wrote: > > On Thu, Apr 4, 2019 at 2:33 PM Peter Belkner wrote: > > This patch does not improve or fix something instead it is meant for > easily reproducing issue 7827 (as requested, cf. > https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know > how to produce a patch by "git format-patch" instead it was made by "git > diff > muxing.patch". > > A lot of docs for this type question, this is a refer > https://www.x.org/wiki/Development/Documentation/SubmittingPatches/ > > You can used the command like: > > git format-patch HEAD~1 # create a patch for the last commit > > And I think "git diff > muxing.patch" will drop the commit message, > it's a part of the patch for review, Tks. > > The patch produced with your command is attached. This is *not* the patch I > want to provide. > > Just believe me: I'm able to search the internet myself and luckily finally > found > https://stackoverflow.com/questions/5159185/create-a-git-patch-from-the-changes-in-the-current-working-directory. > > BTW: I already spend hours to narrow this issue to libavformat. Just eat the > provided patch either from the issue itself (cf. > https://trac.ffmpeg.org/ticket/7827) or from this mailing list OR LET IT BE. > > Cheers. Please try the patch https://patchwork.ffmpeg.org/patch/12612/, Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V1] lavf/matroskaenc: Fix memory leak after write trailer
From: Jun Zhao
Fix memory leak after write trailer for #7827
Signed-off-by: Jun Zhao
---
libavformat/matroskaenc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b9f99c4..22ba93a 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2571,13 +2571,13 @@ static int mkv_write_trailer(AVFormatContext *s)
// check if we have an audio packet cached
if (mkv->cur_audio_pkt.size > 0) {
ret = mkv_write_packet_internal(s, >cur_audio_pkt, 0);
-av_packet_unref(>cur_audio_pkt);
if (ret < 0) {
av_log(s, AV_LOG_ERROR,
"Could not write cached audio packet ret:%d\n", ret);
return ret;
}
}
+av_packet_unref(>cur_audio_pkt);
if (mkv->dyn_bc) {
end_ebml_master_crc32(pb, >dyn_bc, mkv, mkv->cluster);
--
1.7.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] fftools/ffmpeg.c: allow forcing input framerate on streamcopy
On Wed, Jan 09, 2019 at 05:26:53PM -0500, Leo Izen wrote: > --- > fftools/ffmpeg.c | 19 ++- > 1 file changed, 14 insertions(+), 5 deletions(-) Does this behave as intended when there is also an audio stream ? also a fate test should be added thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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".
[FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT
Use the profile constraint flags to determine the exact va_profile for
HEVC_REXT.
Directly cast PTLCommon to H265RawProfileTierLevel, and use ff_h265_get_profile
to get the exact profile.
Signed-off-by: Linjie Fu
---
[v2]: use constraint flags to determine the exact profile, expose the
codec-specific stuff at the beginning.
[v3]: move the VA version check to fix the compile issue.
[RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for
convenience? The members in PTLCommon should be strictly matched in
H265RawProfileTierLevel.
libavcodec/vaapi_decode.c | 73 +++
1 file changed, 58 insertions(+), 15 deletions(-)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 69512e1d45..47db6c874a 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -24,6 +24,8 @@
#include "decode.h"
#include "internal.h"
#include "vaapi_decode.h"
+#include "hevcdec.h"
+#include "h265_profile_level.h"
int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
@@ -401,6 +403,33 @@ static const struct {
#undef MAP
};
+/*
+ * Find exact va_profile for HEVC Range Extension
+ */
+static VAProfile vaapi_decode_find_exact_profile(AVCodecContext *avctx)
+{
+const HEVCContext *h = avctx->priv_data;
+const HEVCSPS *sps = h->ps.sps;
+const PTL *ptl = &(sps->ptl);
+const PTLCommon *general_ptl = &(ptl->general_ptl);
+const H265ProfileDescriptor *profile;
+
+/* PTLCommon should match the member sequence in H265RawProfileTierLevel*/
+profile = ff_h265_get_profile((H265RawProfileTierLevel *)general_ptl);
+
+#if VA_CHECK_VERSION(1, 2, 0)
+if (!strcmp(profile->name, "Main 4:2:2 10"))
+return VAProfileHEVCMain422_10;
+else if (!strcmp(profile->name, "Main 4:4:4"))
+return VAProfileHEVCMain444;
+else if (!strcmp(profile->name, "Main 4:4:4 10"))
+return VAProfileHEVCMain444_10;
+#else
+av_log(avctx, AV_LOG_WARNING, "HEVC profile %s is "
+"not supported with this VA version.\n",
profile->name);
+#endif
+return VAProfileNone;
+}
/*
* Set *va_config and the frames_ref fields from the current codec parameters
* in avctx.
@@ -447,24 +476,38 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
matched_va_profile = VAProfileNone;
exact_match = 0;
-for (i = 0; i < FF_ARRAY_ELEMS(vaapi_profile_map); i++) {
-int profile_match = 0;
-if (avctx->codec_id != vaapi_profile_map[i].codec_id)
-continue;
-if (avctx->profile == vaapi_profile_map[i].codec_profile ||
-vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
-profile_match = 1;
-for (j = 0; j < profile_count; j++) {
-if (vaapi_profile_map[i].va_profile == profile_list[j]) {
-exact_match = profile_match;
+if (avctx->profile == FF_PROFILE_HEVC_REXT) {
+/* find the exact va_profile for HEVC_REXT */
+VAProfile va_profile = vaapi_decode_find_exact_profile(avctx);
+for (i = 0; i < profile_count; i++) {
+if (va_profile == profile_list[i]) {
+exact_match = 1;
+matched_va_profile = va_profile;
+matched_ff_profile = FF_PROFILE_HEVC_REXT;
break;
}
}
-if (j < profile_count) {
-matched_va_profile = vaapi_profile_map[i].va_profile;
-matched_ff_profile = vaapi_profile_map[i].codec_profile;
-if (exact_match)
-break;
+} else {
+/* find the exact va_profile according to codec_id and profile */
+for (i = 0; i < FF_ARRAY_ELEMS(vaapi_profile_map); i++) {
+int profile_match = 0;
+if (avctx->codec_id != vaapi_profile_map[i].codec_id)
+continue;
+if (avctx->profile == vaapi_profile_map[i].codec_profile ||
+vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
+profile_match = 1;
+for (j = 0; j < profile_count; j++) {
+if (vaapi_profile_map[i].va_profile == profile_list[j]) {
+exact_match = profile_match;
+break;
+}
+}
+if (j < profile_count) {
+matched_va_profile = vaapi_profile_map[i].va_profile;
+matched_ff_profile = vaapi_profile_map[i].codec_profile;
+if (exact_match)
+break;
+}
}
}
av_freep(_list);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Patch for Reproducing Issue 7827
On 04.04.2019 08:49, myp...@gmail.com wrote:
On Thu, Apr 4, 2019 at 2:33 PM Peter Belkner wrote:
This patch does not improve or fix something instead it is meant for
easily reproducing issue 7827 (as requested, cf.
https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
how to produce a patch by "git format-patch" instead it was made by "git
diff > muxing.patch".
A lot of docs for this type question, this is a refer
https://www.x.org/wiki/Development/Documentation/SubmittingPatches/
You can used the command like:
git format-patch HEAD~1 # create a patch for the last commit
And I think "git diff > muxing.patch" will drop the commit message,
it's a part of the patch for review, Tks.
___
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".
The patch produced with your command is attached. This is *not* the
patch I want to provide.
Just believe me: I'm able to search the internet myself and luckily
finally found
https://stackoverflow.com/questions/5159185/create-a-git-patch-from-the-changes-in-the-current-working-directory.
BTW: I already spend hours to narrow this issue to libavformat. Just eat
the provided patch either from the issue itself (cf.
https://trac.ffmpeg.org/ticket/7827) or from this mailing list OR LET IT BE.
Cheers.
From ee16d14b0a29317f6118a209c4d0737b97b7f58f Mon Sep 17 00:00:00 2001
From: James Almer
Date: Mon, 25 Mar 2019 00:27:23 -0300
Subject: [PATCH] avcodec/av1_metadata: add an option to remove Padding OBUs
Reviewed-by: Mark Thompson
Signed-off-by: James Almer
---
doc/bitstream_filters.texi| 3 +++
libavcodec/av1_metadata_bsf.c | 19 +++
libavcodec/version.h | 2 +-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 076b910e40..25bbf8372b 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -87,6 +87,9 @@ the timing info in the sequence header.
Set the number of ticks in each picture, to indicate that the stream
has a fixed framerate. Ignored if @option{tick_rate} is not also set.
+@item delete_padding
+Deletes Padding OBUs.
+
@end table
@section chomp
diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 2b74b697e4..fe208feaf5 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -46,6 +46,8 @@ typedef struct AV1MetadataContext {
AVRational tick_rate;
int num_ticks_per_picture;
+
+int delete_padding;
} AV1MetadataContext;
@@ -158,6 +160,19 @@ static int av1_metadata_filter(AVBSFContext *bsf, AVPacket
*out)
}
}
+if (ctx->delete_padding) {
+for (i = 0; i < frag->nb_units; i++) {
+if (frag->units[i].type == AV1_OBU_PADDING) {
+err = ff_cbs_delete_unit(ctx->cbc, frag, i);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to delete Padding
OBU.\n");
+goto fail;
+}
+--i;
+}
+}
+}
+
err = ff_cbs_write_packet(ctx->cbc, out, frag);
if (err < 0) {
av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
@@ -275,6 +290,10 @@ static const AVOption av1_metadata_options[] = {
OFFSET(num_ticks_per_picture), AV_OPT_TYPE_INT,
{ .i64 = -1 }, -1, INT_MAX, FLAGS },
+{ "delete_padding", "Delete all Padding OBUs",
+OFFSET(delete_padding), AV_OPT_TYPE_BOOL,
+{ .i64 = 0 }, 0, 1, FLAGS},
+
{ NULL }
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index d1cd356524..02cb5c3ec1 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 48
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
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 for Reproducing Issue 7827
On Thu, Apr 4, 2019 at 2:33 PM Peter Belkner wrote:
>
> This patch does not improve or fix something instead it is meant for
> easily reproducing issue 7827 (as requested, cf.
> https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
> how to produce a patch by "git format-patch" instead it was made by "git
> diff > muxing.patch".
>
A lot of docs for this type question, this is a refer
https://www.x.org/wiki/Development/Documentation/SubmittingPatches/
You can used the command like:
git format-patch HEAD~1 # create a patch for the last commit
And I think "git diff > muxing.patch" will drop the commit message,
it's a part of the patch for review, Tks.
diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 08da98e574..75766f497b 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -49,6 +49,8 @@
#define SCALE_FLAGS SWS_BICUBIC
+#define MUX_MATROSKA_FLAC
+
// a wrapper around a single output AVStream
typedef struct OutputStream {
AVStream *st;
@@ -600,7 +602,12 @@ int main(int argc, char **argv)
encode_video = 1;
}
if (fmt->audio_codec != AV_CODEC_ID_NONE) {
-add_stream(_st, oc, _codec, fmt->audio_codec);
+#if defined (MUX_MATROSKA_FLAC) // [
+ if (!strcmp("matroska",fmt->name))
+add_stream(_st, oc, _codec, AV_CODEC_ID_FLAC);
+ else
+#endif // ]
+ add_stream(_st, oc, _codec, fmt->audio_codec);
have_audio = 1;
encode_audio = 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 2/6] lavu/frame: Expand ROI documentation
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Wednesday, March 13, 2019 8:18 AM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH v2 2/6] lavu/frame: Expand ROI > documentation > > Clarify and add examples for the behaviour of the quantisation offset, > and define how multiple ranges should be handled. > --- > libavutil/frame.h | 46 ++ > 1 file changed, 34 insertions(+), 12 deletions(-) Maybe we can first refine and push the first two patches? ___ 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] lavf/flvdec: Fix AMF NUMBER type to metadata lost precision
On Thu, Apr 4, 2019 at 5:21 AM Michael Niedermayer
wrote:
>
> On Thu, Mar 28, 2019 at 09:23:29PM +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > Use %.12g replace %.f when save AMF NUMBER(double) type to
> > metadata. And update fate ref.
> >
> > before this fix, we get FLV metadata like:
> >
> > Metadata:
> > lasttimestamp : 113
> > lastkeyframetimestamp: 112
> >
> > after this fix:
> >
> > Metadata:
> > lasttimestamp : 113.005
> > lastkeyframetimestamp: 111.678
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/flvdec.c |2 +-
> > tests/ref/fate/flv-add_keyframe_index |2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > index 445d58d..12bfd4b 100644
> > --- a/libavformat/flvdec.c
> > +++ b/libavformat/flvdec.c
> > @@ -649,7 +649,7 @@ static int amf_parse_object(AVFormatContext *s,
> > AVStream *astream,
> > sizeof(str_val));
> > av_dict_set(>metadata, key, str_val, 0);
> > } else if (amf_type == AMF_DATA_TYPE_NUMBER) {
> > -snprintf(str_val, sizeof(str_val), "%.f", num_val);
> > +snprintf(str_val, sizeof(str_val), "%.12g", num_val);
> > av_dict_set(>metadata, key, str_val, 0);
> > } else if (amf_type == AMF_DATA_TYPE_STRING) {
> > av_dict_set(>metadata, key, str_val, 0);
> > diff --git a/tests/ref/fate/flv-add_keyframe_index
> > b/tests/ref/fate/flv-add_keyframe_index
> > index 1c4da65..ce3809e 100644
> > --- a/tests/ref/fate/flv-add_keyframe_index
> > +++ b/tests/ref/fate/flv-add_keyframe_index
> > @@ -7,6 +7,6 @@ canSeekToEnd=true
> > datasize=629776
> > videosize=629381
> > audiosize=0
> > -lasttimestamp=20
> > +lasttimestamp=19.8571428571
>
> does every platform we support produce the same number here ?
> if not then make fate would break
> its a lot of digits after the decimal point, floats are not exact ...
%g flag characters for snprintf is part of C 90 standand, so I think
it's ok if the platform with C 90 standand suppoted.
For log digits after the decimal point, how about change from %.12g
to %.6g? Any other suggestion?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlylI7AACgkQYR7HhwQLD6uA0gCgk2yOM8TwH8T6oLhoU+20CnRT
XbEAnAuIClxs4buySSU6USaIhAxeqNuV
=tDZ7
-END 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".
[FFmpeg-devel] Patch for Reproducing Issue 7827
This patch does not improve or fix something instead it is meant for
easily reproducing issue 7827 (as requested, cf.
https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
how to produce a patch by "git format-patch" instead it was made by "git
diff > muxing.patch".
diff --git a/doc/examples/muxing.c b/doc/examples/muxing.c
index 08da98e574..75766f497b 100644
--- a/doc/examples/muxing.c
+++ b/doc/examples/muxing.c
@@ -49,6 +49,8 @@
#define SCALE_FLAGS SWS_BICUBIC
+#define MUX_MATROSKA_FLAC
+
// a wrapper around a single output AVStream
typedef struct OutputStream {
AVStream *st;
@@ -600,7 +602,12 @@ int main(int argc, char **argv)
encode_video = 1;
}
if (fmt->audio_codec != AV_CODEC_ID_NONE) {
-add_stream(_st, oc, _codec, fmt->audio_codec);
+#if defined (MUX_MATROSKA_FLAC) // [
+ if (!strcmp("matroska",fmt->name))
+add_stream(_st, oc, _codec, AV_CODEC_ID_FLAC);
+ else
+#endif // ]
+ add_stream(_st, oc, _codec, fmt->audio_codec);
have_audio = 1;
encode_audio = 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".
