Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
On 7/21/19 11:23 PM, Paul B Mahol wrote: > On 7/22/19, David Bryant wrote: >> Hi, >> >> As I promised late last year, here is a patch to add a WavPack DSD decoder. >> >> Thanks! >> >> -David Bryant >> >> > Please correct me if I'm wrong, but why this uses new codec id? > Apparently is also copies some logic from other files. Yes, I created a new codec ID for WavPack DSD. It would be possible to just piggyback on the existing WavPack codec by silently decimating the DSD to PCM, but that seemed weird and wrong to me. For one thing, the user would have no idea that the file was actually DSD and not high sample-rate PCM. Also, since regular WavPack has threading enabled but WavPack DSD can't (because of the dsd2pcm conversion) I would have to turn off threading for all WavPack (unless there's some way of making that conditional at runtime). It would also mean that regular WavPack would be dependent on the dsd2pcm component even if DSD was not required (not everyone needs DSD). And of course I was looking closely at the only other DSD codec in FFmpeg (DST) which has its own codec ID. Because regular WavPack PCM and DSD share the same block format and metadata structure, there is a little code that is shared between the two codecs (although they are no longer identical because of the threading difference). Is this a problem? I could combine the two codecs into one file and sprinkle in a few conditionals, but I don't think it would be as clean or clear (but might save a little duplicate code). That's my thinking, but obviously I am not as familiar with the FFmpeg philosophy as you guys. -David > ___ > 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 1/3] lavf/f_select: support scenecut with more pixel formats
On 23-07-2019 02:43 AM, Marton Balint wrote: On Sun, 21 Jul 2019, lance.lmw...@gmail.com wrote: From: Limin Wang This patch haven't make other pixel format usable yet to make sure the test result is same with rgb32 format. Reviewed-by: Marton Balint You should only add this if you got an explicit LGTM for a patch. Signed-off-by: Limin Wang --- libavfilter/f_select.c | 34 ++ 1 file changed, 30 insertions(+), 4 deletions(-) Ok, I applied the series with some minor fixes and rewordings of your commit messages, as they were a bit difficult to understand sometimes. "avformat/f_select: support scenecut with more pixel formats" This should have been avfilter/f_select. 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] Setup for extracting quantization parameters from encoded streams
Jul 23, 2019, 12:23 AM by juandl-at-google@ffmpeg.org: >> On Mon, Jul 22, 2019 at 12:17 PM Lynne wrote: >> You can't hack a decoder in any nice and performant way for it to output >> > data to an analyzer. > Hi, Lynne > I hear your concern about the decoder performance. > I believe that the way we would like to modify the decoder should not > affect its performance, since > AV_FRAME_QUANTIZATION_PARAMS will be disabled by default; the extraction is > done optionally with a flag. > I would be glad to verify that by running tests and measuring performance > with and without my changes. > If you have in mind any tests I should run, please let me know. > >> I've explained why this is a bad idea and why you should maintain >> > it internally. > FFmpeg already has a lot of analyzing tools, I disagree that this change > does not belong to ffmpeg. > Switches like these only make code slower, not faster. And they don't erase code either. I'll not accept this API without a decoder patch either. ___ 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/rl2: set dimensions
Jul 22, 2019, 11:24 PM by ceffm...@gmail.com: > Am Di., 23. Juli 2019 um 00:14 Uhr schrieb Lynne : > >> If the size somehow gets lost between lavf and lavc then the problem is >> there, and should be solved by not fudging the decoder. >> > > (Using libavformat is no condition for using libavcodec) > >> Moreover, if neither the codec, nor container can change the resolution, >> then how does that make anything different? >> >> Please, stop it with those patches. >> > > Please stop with these comments. > > No matter what others may tell you, they are not useful but very disturbing. > Please stay out of all my emails and harassing me over apparently not having enough commits. ___ 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/rl2: set dimensions
Jul 23, 2019, 12:00 AM by mich...@niedermayer.cc:
> On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
>
>> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
>>
>> > The dimensions are always 320x200 they are hardcoded in the demuxer.
>> > Hardcode them instead in the decoder.
>> >
>> > Fixes: Timeout (16sec -> 400ms)
>> > Fixes:
>> > 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
>> >
>> > Found-by: continuous fuzzing process
>> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > libavcodec/rl2.c | 5 +
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/libavcodec/rl2.c b/libavcodec/rl2.c
>> > index 6662979c52..2d336a61e5 100644
>> > --- a/libavcodec/rl2.c
>> > +++ b/libavcodec/rl2.c
>> > @@ -134,10 +134,15 @@ static av_cold int rl2_decode_init(AVCodecContext
>> > *avctx)
>> > Rl2Context *s = avctx->priv_data;
>> > int back_size;
>> > int i;
>> > +int ret;
>> >
>> > s->avctx = avctx;
>> > avctx->pix_fmt = AV_PIX_FMT_PAL8;
>> >
>> > +ret = ff_set_dimensions(avctx, 320, 200);
>> > +if (ret < 0)
>> > +return ret;
>> > +
>> > /** parse extra data */
>> > if (!avctx->extradata || avctx->extradata_size < EXTRADATA1_SIZE) {
>> > av_log(avctx, AV_LOG_ERROR, "invalid extradata size\n");
>> > --
>> > 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".
>> >
>>
>> If the size somehow gets lost between lavf and lavc then the problem is
>> there, and should be solved by not fudging the decoder.
>>
>
> libavcodec is used by many applications which do not use libavformat.
> for all i know and what is documented in the only reference spec i have.
> the resolution is a constant its always 320x200 for this codec. So its
> natural to have the decoder know about its own resolution.
>
Nonetheless, while I agree with having both decoder and demuxer hardcode the
resolution, I still think this is fudging.
>> Moreover, if neither the codec, nor container can change the resolution,
>> then how does that make anything different?
>>
>
>
>> Please, stop it with those patches. It takes energy and some worry to have
>> to open up the ML and scan it for bad patches from people who really should
>> know better every time.
>>
>
> Please stop with these attacks, this is just making people become
> mutually more aggressive and filled with hatred.
>
Of course I'm frustrated, I've been ignored.
These patches affect decoding of real world broken files in favor of fixing
specially crafted fuzzed files. Sure, protecting against ddos attacts is
important, but not important enough to make decoders give up early and return
nothing. Especially in cases where the timeout speedup is of the order of 2s to
400ms.
Yet in all of those timeout patches all you've cared about is shutting up the
tool. You've never once shown any figures if this could affect decoding,
because its a lot harder than just showing they fix something some tool calls a
timeout and forgetting about it. You haven't even commented on this when I
asked you on IRC.
You also sneak this type of patches in when there's an overflow later on during
decoding, which is completely incorrect in almost all cases, for the same
reason above.
If people really wanted to ddos anything using decoders they can easly do so by
sending over a gzip compressed specially crafted vobis file to allocate tons of
memory and spend CPU. Something every browser supports, rather than use old
codecs disabled by everyone.
___
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 1/3] lavf/f_select: support scenecut with more pixel formats
On Mon, Jul 22, 2019 at 11:13:46PM +0200, Marton Balint wrote: > > On Sun, 21 Jul 2019, lance.lmw...@gmail.com wrote: > > >From: Limin Wang > > > >This patch haven't make other pixel format usable yet to make sure the test > >result is same with rgb32 format. > > > >Reviewed-by: Marton Balint > > You should only add this if you got an explicit LGTM for a patch. OK, got it. thanks for the review, it's very helpful. > > >Signed-off-by: Limin Wang > >--- > >libavfilter/f_select.c | 34 ++ > >1 file changed, 30 insertions(+), 4 deletions(-) > > Ok, I applied the series with some minor fixes and rewordings of > your commit messages, as they were a bit difficult to understand > sometimes. OK, after the change, it looks better. > > 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] Setup for extracting quantization parameters from encoded streams
> On Mon, Jul 22, 2019 at 12:17 PM Lynne wrote: > You can't hack a decoder in any nice and performant way for it to output data to an analyzer. Hi, Lynne I hear your concern about the decoder performance. I believe that the way we would like to modify the decoder should not affect its performance, since AV_FRAME_QUANTIZATION_PARAMS will be disabled by default; the extraction is done optionally with a flag. I would be glad to verify that by running tests and measuring performance with and without my changes. If you have in mind any tests I should run, please let me know. > I've explained why this is a bad idea and why you should maintain it internally. FFmpeg already has a lot of analyzing tools, I disagree that this change does not belong to ffmpeg. ___ 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 4/4] avcodec/hqx: Check the input data against the image size
On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote: > On 7/21/19, Michael Niedermayer wrote: > > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: > >> On 7/21/19, Michael Niedermayer wrote: > >> > Fixes: Timeout (22 -> 7 sec) > >> > Fixes: > >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 > >> > > >> > Found-by: continuous fuzzing process > >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > >> > Signed-off-by: Michael Niedermayer > >> > --- > >> > libavcodec/hqx.c | 4 > >> > 1 file changed, 4 insertions(+) > >> > > >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c > >> > index bc24ba91d1..8639d77a41 100644 > >> > --- a/libavcodec/hqx.c > >> > +++ b/libavcodec/hqx.c > >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext *avctx, > >> > void > >> > *data, > >> > avctx->height = ctx->height; > >> > avctx->bits_per_raw_sample = 10; > >> > > >> > +if (avctx->coded_width / 16 * (avctx->coded_height / 16) * > >> > +(100 - avctx->discard_damaged_percentage) / 100 > 8LL * > >> > avpkt->size) > >> > +return AVERROR_INVALIDDATA; > >> > >> Why just this change and not something better? > > > > What would you prefer exactly ? > > Something that works with pure black video. Can you share the failing video file ? I thought theres a minimum size of 1 vlc code (2 bit seem the smallest) per 16x16 block. But quite possibly i might have missed something Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- 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 v6] Fix integer parameters size check in SDP fmtp line
On Mon, Jul 22, 2019 at 09:58:58AM +0200, Olivier MAIGNIAL wrote: > You are right, some values are expected to be <= 32. > However, it doesn't add a bug: Without my patch fail will occur at parsing > time; With my patch it will occur a bit later on check performed by > get_bits_long(). get_bits_long has an assert on the size, so if its out of range its a bug Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: 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 4/4] avcodec/mediacodec_wrapper: remove unused local variables in ff_AMediaCodec_getCodecNameByType()
On Mon, Jul 22, 2019 at 09:02:15AM +0200, Matthieu Bouron wrote:
> On Fri, Jul 19, 2019 at 09:40:52AM +0200, Matthieu Bouron wrote:
> > On Sun, Jul 14, 2019 at 08:17:03PM +0200, Matthieu Bouron wrote:
> > > On Thu, Jul 04, 2019 at 03:43:48PM +0200, Matthieu Bouron wrote:
> > > > ---
> > > > libavcodec/mediacodec_wrapper.c | 10 --
> > > > 1 file changed, 10 deletions(-)
> > > >
> > > > diff --git a/libavcodec/mediacodec_wrapper.c
> > > > b/libavcodec/mediacodec_wrapper.c
> > > > index 70e1e7cae1..5213cf640a 100644
> > > > --- a/libavcodec/mediacodec_wrapper.c
> > > > +++ b/libavcodec/mediacodec_wrapper.c
> > > > @@ -392,8 +392,6 @@ char *ff_AMediaCodecList_getCodecNameByType(const
> > > > char *mime, int profile, int e
> > > > struct JNIAMediaCodecListFields jfields = { 0 };
> > > > struct JNIAMediaFormatFields mediaformat_jfields = { 0 };
> > > >
> > > > -jobject format = NULL;
> > > > -jobject codec = NULL;
> > > > jobject codec_name = NULL;
> > > >
> > > > jobject info = NULL;
> > > > @@ -571,14 +569,6 @@ done_with_info:
> > > > }
> > > >
> > > > done:
> > > > -if (format) {
> > > > -(*env)->DeleteLocalRef(env, format);
> > > > -}
> > > > -
> > > > -if (codec) {
> > > > -(*env)->DeleteLocalRef(env, codec);
> > > > -}
> > > > -
> > > > if (codec_name) {
> > > > (*env)->DeleteLocalRef(env, codec_name);
> > > > }
> > > > --
> > > > 2.22.0
> > > >
> > >
> > > Ping for the patch set.
> >
> > If there is no objection, I will push the patchset in a few days.
> >
>
> Pushed to master. Is it still on time to also be pushed to the 4.2 release
> branch ?
i found no time today for working on the release so theres still time for
any backports of bug fixes, yes
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".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
>
> > The dimensions are always 320x200 they are hardcoded in the demuxer.
> > Hardcode them instead in the decoder.
> >
> > Fixes: Timeout (16sec -> 400ms)
> > Fixes:
> > 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/rl2.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavcodec/rl2.c b/libavcodec/rl2.c
> > index 6662979c52..2d336a61e5 100644
> > --- a/libavcodec/rl2.c
> > +++ b/libavcodec/rl2.c
> > @@ -134,10 +134,15 @@ static av_cold int rl2_decode_init(AVCodecContext
> > *avctx)
> > Rl2Context *s = avctx->priv_data;
> > int back_size;
> > int i;
> > +int ret;
> >
> > s->avctx = avctx;
> > avctx->pix_fmt = AV_PIX_FMT_PAL8;
> >
> > +ret = ff_set_dimensions(avctx, 320, 200);
> > +if (ret < 0)
> > +return ret;
> > +
> > /** parse extra data */
> > if (!avctx->extradata || avctx->extradata_size < EXTRADATA1_SIZE) {
> > av_log(avctx, AV_LOG_ERROR, "invalid extradata size\n");
> > --
> > 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".
> >
>
> If the size somehow gets lost between lavf and lavc then the problem is
> there, and should be solved by not fudging the decoder.
libavcodec is used by many applications which do not use libavformat.
for all i know and what is documented in the only reference spec i have.
the resolution is a constant its always 320x200 for this codec. So its
natural to have the decoder know about its own resolution.
> Moreover, if neither the codec, nor container can change the resolution, then
> how does that make anything different?
> Please, stop it with those patches. It takes energy and some worry to have to
> open up the ML and scan it for bad patches from people who really should know
> better every time.
Please stop with these attacks, this is just making people become
mutually more aggressive and filled with hatred.
Lets work together to find solutions, not work against each other.
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] avcodec/rl2: set dimensions
Am Di., 23. Juli 2019 um 00:14 Uhr schrieb Lynne : > If the size somehow gets lost between lavf and lavc then the problem is > there, and should be solved by not fudging the decoder. (Using libavformat is no condition for using libavcodec) > Moreover, if neither the codec, nor container can change the resolution, then > how does that make anything different? > Please, stop it with those patches. Please stop with these comments. No matter what others may tell you, they are not useful but very disturbing. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
> The dimensions are always 320x200 they are hardcoded in the demuxer.
> Hardcode them instead in the decoder.
>
> Fixes: Timeout (16sec -> 400ms)
> Fixes:
> 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/rl2.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/rl2.c b/libavcodec/rl2.c
> index 6662979c52..2d336a61e5 100644
> --- a/libavcodec/rl2.c
> +++ b/libavcodec/rl2.c
> @@ -134,10 +134,15 @@ static av_cold int rl2_decode_init(AVCodecContext
> *avctx)
> Rl2Context *s = avctx->priv_data;
> int back_size;
> int i;
> +int ret;
>
> s->avctx = avctx;
> avctx->pix_fmt = AV_PIX_FMT_PAL8;
>
> +ret = ff_set_dimensions(avctx, 320, 200);
> +if (ret < 0)
> +return ret;
> +
> /** parse extra data */
> if (!avctx->extradata || avctx->extradata_size < EXTRADATA1_SIZE) {
> av_log(avctx, AV_LOG_ERROR, "invalid extradata size\n");
> --
> 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".
>
If the size somehow gets lost between lavf and lavc then the problem is there,
and should be solved by not fudging the decoder.
Moreover, if neither the codec, nor container can change the resolution, then
how does that make anything different?
Please, stop it with those patches. It takes energy and some worry to have to
open up the ML and scan it for bad patches from people who really should know
better every time.
___
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/rl2: set dimensions
The dimensions are always 320x200 they are hardcoded in the demuxer.
Hardcode them instead in the decoder.
Fixes: Timeout (16sec -> 400ms)
Fixes:
15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/rl2.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/rl2.c b/libavcodec/rl2.c
index 6662979c52..2d336a61e5 100644
--- a/libavcodec/rl2.c
+++ b/libavcodec/rl2.c
@@ -134,10 +134,15 @@ static av_cold int rl2_decode_init(AVCodecContext *avctx)
Rl2Context *s = avctx->priv_data;
int back_size;
int i;
+int ret;
s->avctx = avctx;
avctx->pix_fmt = AV_PIX_FMT_PAL8;
+ret = ff_set_dimensions(avctx, 320, 200);
+if (ret < 0)
+return ret;
+
/** parse extra data */
if (!avctx->extradata || avctx->extradata_size < EXTRADATA1_SIZE) {
av_log(avctx, AV_LOG_ERROR, "invalid extradata size\n");
--
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".
Re: [FFmpeg-devel] [PATCH v3 1/3] lavf/f_select: support scenecut with more pixel formats
On Sun, 21 Jul 2019, lance.lmw...@gmail.com wrote: From: Limin Wang This patch haven't make other pixel format usable yet to make sure the test result is same with rgb32 format. Reviewed-by: Marton Balint You should only add this if you got an explicit LGTM for a patch. Signed-off-by: Limin Wang --- libavfilter/f_select.c | 34 ++ 1 file changed, 30 insertions(+), 4 deletions(-) Ok, I applied the series with some minor fixes and rewordings of your commit messages, as they were a bit difficult to understand sometimes. 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] avformat/mxfenc: fix index byte count in partition header
Hi Tomas,
> On Jul 22, 2019, at 2:45 AM, Tomas Härdin wrote:
>
> fre 2019-07-19 klockan 09:51 -0700 skrev Baptiste Coudurier:
>> Hi Tomas
>>
>>> On Jul 19, 2019, at 8:48 AM, Tomas Härdin
>>> wrote:
>>>
>>> tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
---
libavformat/mxfenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index b677f6af8e..2e54320cf0 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1944,8 +1944,7 @@ static int
mxf_write_partition(AVFormatContext
*s, int bodysid,
index_byte_count = 80;
if (index_byte_count) {
-// add encoded ber length
-index_byte_count += 16 +
klv_ber_length(index_byte_count);
+index_byte_count += 16 + 4; // add encoded ber4 length
index_byte_count += klv_fill_size(index_byte_count);
}
>>>
>>> Is there a reason why we don't pick a single BER length coding for
>>> the
>>> entire muxer?
>>
>> BER It saves space, BER4 is only used when required. No strong
>> opinion,
>> I think it’s unrelated to this fix though.
>
> Sorry about the late reply. But yeah, just thought it was a bit
> strange. BER4 does make computing sizes much easier where possible. The
> patch itself is obviously fine
No worries. Yeah I kinda agree.
Applied.
Thanks a lot!
—
Baptiste
___
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 3/3] lavc/libdavs2.c: use decoder data directly instead of memcpy
On Sat, 13 Jul 2019, hwren wrote:
At 2019-07-13 01:38:55, "Marton Balint" wrote:
On Fri, 12 Jul 2019, hwrenx wrote:
Can effectivly improved decoding speed when memcpy becomes a limitation
for proccessing high resolution source.
Tested under i7-8700k with `ffmpeg -i 7680x4320.avs2 -vsync 0 -f null -`
got performance 23fps => 42fps
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 54 +--
1 file changed, 31 insertions(+), 23 deletions(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 1b274a3..af0778f 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -60,13 +60,24 @@ static av_cold int davs2_init(AVCodecContext *avctx)
return 0;
}
+static void davs2_frame_unref(void *opaque, uint8_t *data) {
+DAVS2Context*cad = (DAVS2Context *)opaque;
+davs2_picture_t pic;
+
+pic.magic = (davs2_picture_t *)data;
+
+if (cad->decoder) {
+davs2_decoder_frame_unref(cad->decoder, );
+} else {
+av_log(NULL, AV_LOG_WARNING, "Decoder not found, frame unreference
failed.\n");
Whoa, this should not happen, and you have to be prepared that the user
might close the decoder before freeing the last frame.
I hope so, actually it's harmless if we failed to unref some frames outside
davs2 when decoder
was closed through davs2_decoder_close(). The decoder will free the memory
which contains
all recycle data itself.
And that is the problem, because the data should survive closing the
(avcodec) decoder.
Maybe you should use some refcounting and create references to the
decoder, others may have a better idea.
Regards,
Marton
Of course, anyway, it would be better if there are any ways to make sure we
correctly freed all
frames even decoder was not found or exited without a davs2_decoder_close().
But force to
free the memory immediately in the call back function can cause troubles to
decoder and I'm
not very clearly understand how to use reference to deal with this problem
inside a codec.
Maybe that means I could reference the buffer and waiting ffmpeg to free them
once they were
not handled by davs2?
I am not sure I understand your concern here.
Here is what I propose in more detail, I think it works for all cases:
In davs_init allocate a small struct which contains the decoder and a
reference counter for the decoder itself:
DAVS2Reference {
atomic_int refcount;
void *decoder;
}
set the refs to 1.
In davs2_dump_frames you should pass the allocated DAVS2Reference to
av_buffer_create instead of the DAVS2Context. After each successful
av_buffer_create you should increase refcount.
In davs2_frame_unref after freeing the frame you should decrease the
reference counter and if you reach 0 then you can destroy the davs2
decoder (and free DAVS2Reference struct as well)
You can do the same in davs2_end: decrease the refcount and if you reach 0
then you can close the davs2 decoder and free the DAVS2Reference struct.
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] avfilter/vf_ciescope: add DCI-P3
Hi, Patch attached. 0001-avfilter-vf_ciescope-add-DCI-P3.patch Description: Binary data ___ 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] Setup for extracting quantization parameters from encoded streams
Jul 22, 2019, 8:03 PM by juandl-at-google@ffmpeg.org: > On Fri, Jul 19, 2019 at 12:47 PM Moritz Barsnick wrote: > >> On Fri, Jul 19, 2019 at 10:00:52 +0200, Nicolas George wrote: >> > I do not judge whether this filter would be useful and should be >> > included, but if so, then I would appreciate that the output be done >> > using AVIO, so that it can go to any supported protocol. >> >> The metadata filter has a nice example of how to use avio, incl. >> mapping to stdout: >> >> >> https://github.com/FFmpeg/FFmpeg/blob/f102a4efcef33014d414f9bf4492a04feab20c82/libavfilter/f_metadata.c#L250 >> >> I suppose this can been used as a reference. >> >> 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". >> > > > Thanks, I will update the filter to use avio. > Pinging the thread. > I've explained why this is a bad idea and why you should maintain it internally. You can't hack a decoder in any nice and performant way for it to output data to an analyzer. ___ 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] Setup for extracting quantization parameters from encoded streams
On Fri, Jul 19, 2019 at 12:47 PM Moritz Barsnick wrote: > On Fri, Jul 19, 2019 at 10:00:52 +0200, Nicolas George wrote: > > I do not judge whether this filter would be useful and should be > > included, but if so, then I would appreciate that the output be done > > using AVIO, so that it can go to any supported protocol. > > The metadata filter has a nice example of how to use avio, incl. > mapping to stdout: > > > https://github.com/FFmpeg/FFmpeg/blob/f102a4efcef33014d414f9bf4492a04feab20c82/libavfilter/f_metadata.c#L250 > > I suppose this can been used as a reference. > > 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". Thanks, I will update the filter to use avio. Pinging the thread. ___ 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 IPC SHM
From: Carl Eugen Hoyos
Subject: Re: [FFmpeg-devel] Patch for IPC SHM
Date: Mon, 22 Jul 2019 19:23:35 +0200
>
>
>
>> Am 22.07.2019 um 18:10 schrieb :
>>
>> All,
>>
>> I have encountered an error in libavdevice/xcbgrab.c that prevents NetBSD
>> from
>> using X11grab. When xcbgrab_frame_shm calls allocate_shm, it creates a
>> private
>> shared memory region, attaches to that memory, sends the id to the server,
>> but
>> then removes the shared memory ID. On NetBSD with xorg, this causes the
>> subsequent call to xcb_shm_get_image to fail with BadShmSeg. The fix is to
>> keep
>> the ID valid until the memory is know to be shared, after the call to
>> xcb_shm_get_image_reply. The following patch fixes the issue on my system.
>> It
>> is untested on others.
>>
>> My guess is that Linux keeps the ID around until all attached processes
>> terminate.
>
> Please create your patch with “git format-patch”, we cannot read other
> patches.
>
> Thank you, 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".
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index b7e689343e..c2119946e1 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -75,6 +75,7 @@ typedef struct XCBGrabContext {
const char *framerate;
int has_shm;
+int shmid;
} XCBGrabContext;
#define FOLLOW_CENTER -1
@@ -221,6 +222,14 @@ static int check_shm(xcb_connection_t *conn)
return 0;
}
+static void rm_shmid(AVFormatContext *s) {
+XCBGrabContext *c = s->priv_data;
+if(c->shmid != -1) {
+ shmctl(c->shmid, IPC_RMID, 0);
+ c->shmid == -1;
+}
+}
+
static int allocate_shm(AVFormatContext *s)
{
XCBGrabContext *c = s->priv_data;
@@ -230,7 +239,8 @@ static int allocate_shm(AVFormatContext *s)
if (c->buffer)
return 0;
-id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0777);
+
+id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0666);
if (id == -1) {
char errbuf[1024];
int err = AVERROR(errno);
@@ -239,15 +249,20 @@ static int allocate_shm(AVFormatContext *s)
size, errbuf);
return err;
}
+
xcb_shm_attach(c->conn, c->segment, id, 0);
data = shmat(id, NULL, 0);
-shmctl(id, IPC_RMID, 0);
-if ((intptr_t)data == -1 || !data)
-return AVERROR(errno);
+
+if ((intptr_t)data == -1 || !data) {
+ shmctl(id, IPC_RMID, 0);
+ return AVERROR(errno);
+}
c->buffer = data;
+c->shmid = id;
return 0;
}
+
static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
{
XCBGrabContext *c = s->priv_data;
@@ -268,6 +283,8 @@ static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket
*pkt)
xcb_flush(c->conn);
+rm_shmid(s);
+
if (e) {
av_log(s, AV_LOG_ERROR,
"Cannot get the image data "
pgpga7WCIi0B4.pgp
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 IPC SHM
> Am 22.07.2019 um 18:10 schrieb : > > All, > > I have encountered an error in libavdevice/xcbgrab.c that prevents NetBSD from > using X11grab. When xcbgrab_frame_shm calls allocate_shm, it creates a > private > shared memory region, attaches to that memory, sends the id to the server, but > then removes the shared memory ID. On NetBSD with xorg, this causes the > subsequent call to xcb_shm_get_image to fail with BadShmSeg. The fix is to > keep > the ID valid until the memory is know to be shared, after the call to > xcb_shm_get_image_reply. The following patch fixes the issue on my system. > It > is untested on others. > > My guess is that Linux keeps the ID around until all attached processes > terminate. Please create your patch with “git format-patch”, we cannot read other patches. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix return code for trun box with no sample entries
On 22-07-2019 12:50 PM, Paul B Mahol wrote: On 7/21/19, Gyan wrote: On 21-07-2019 02:21 PM, Paul B Mahol wrote: On 7/20/19, Gyan wrote: Affected files can now be demuxed. Verified with John Stebbins. FATE passes. Gyan You removed negative check, so not ok. entries is unsigned (in the code as well as in the standard). So the value read from file will be >= 0. Even after adjustment for index size overflow, it cannot become negative. OK then Pushed as d51d71c1e3a6a225a5bc8f35963b50331e479b1a after moving check to after overflow check. Thanks, 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 for IPC SHM
All,
I have encountered an error in libavdevice/xcbgrab.c that prevents NetBSD from
using X11grab. When xcbgrab_frame_shm calls allocate_shm, it creates a private
shared memory region, attaches to that memory, sends the id to the server, but
then removes the shared memory ID. On NetBSD with xorg, this causes the
subsequent call to xcb_shm_get_image to fail with BadShmSeg. The fix is to keep
the ID valid until the memory is know to be shared, after the call to
xcb_shm_get_image_reply. The following patch fixes the issue on my system. It
is untested on others.
My guess is that Linux keeps the ID around until all attached processes
terminate.
For what it is worth, trac's registration system seems to be broken. If you are
interested, please let me know and I can provide details.
Aran
*** libavdevice/xcbgrab.c.orig Sun Jul 21 10:34:46 2019
--- libavdevice/xcbgrab.c Sun Jul 21 10:34:55 2019
***
*** 75,80
--- 75,81
const char *framerate;
int has_shm;
+ int shmid;
} XCBGrabContext;
#define FOLLOW_CENTER -1
***
*** 221,226
--- 222,235
return 0;
}
+ static void rm_shmid(AVFormatContext *s) {
+ XCBGrabContext *c = s->priv_data;
+ if(c->shmid != -1) {
+ shmctl(c->shmid, IPC_RMID, 0);
+ c->shmid == -1;
+ }
+ }
+
static int allocate_shm(AVFormatContext *s)
{
XCBGrabContext *c = s->priv_data;
***
*** 230,236
if (c->buffer)
return 0;
! id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0777);
if (id == -1) {
char errbuf[1024];
int err = AVERROR(errno);
--- 239,246
if (c->buffer)
return 0;
!
! id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0666);
if (id == -1) {
char errbuf[1024];
int err = AVERROR(errno);
***
*** 239,253
size, errbuf);
return err;
}
xcb_shm_attach(c->conn, c->segment, id, 0);
data = shmat(id, NULL, 0);
! shmctl(id, IPC_RMID, 0);
! if ((intptr_t)data == -1 || !data)
! return AVERROR(errno);
c->buffer = data;
return 0;
}
static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
{
XCBGrabContext *c = s->priv_data;
--- 249,268
size, errbuf);
return err;
}
+
xcb_shm_attach(c->conn, c->segment, id, 0);
data = shmat(id, NULL, 0);
!
! if ((intptr_t)data == -1 || !data) {
! shmctl(id, IPC_RMID, 0);
! return AVERROR(errno);
! }
c->buffer = data;
+ c->shmid = id;
return 0;
}
+
static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
{
XCBGrabContext *c = s->priv_data;
***
*** 268,273
--- 283,290
xcb_flush(c->conn);
+ rm_shmid(s);
+
if (e) {
av_log(s, AV_LOG_ERROR,
"Cannot get the image data "
pgpbx3Xm6MpQ3.pgp
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] libavformat/mpegtsenc: new interlaced mux mode
Hi Paul, Marton and Andriy, I have updated the patch following the comments. The first part that solves only the PCR bug with multiple programs is already published: https://patchwork.ffmpeg.org/patch/14036/ I hope it will soon be accepted. Regards. A.H. --- ___ 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] libavformat/mpegtsenc: fix incorrect PCR with multiple programs
Hi,
Based on the discussion of my previous patch
https://patchwork.ffmpeg.org/patch/13487/
Here I publish a first part of the patch that only addresses the PCR problem.
This supersedes too: https://patchwork.ffmpeg.org/patch/13745/
Regards.
A.H.
---From a9d51e71c546986c8ea3bd111d16fc81354ffa3d Mon Sep 17 00:00:00 2001
From: Andreas Hakon
Date: Mon, 22 Jul 2019 13:10:20 +0100
Subject: [PATCH] libavformat/mpegtsenc: fix incorrect PCR with multiple
programs
The MPEG-TS muxer has a serious bug related to the PCR pid selection.
This bug appears when more than one program is used. The root cause is because
the current code targets only one program when selecting the stream for the PCR.
This patch solves this problem. And you can check it with these commands:
- First, make sure you have "ffmpeg-old" (a binary without the patch),
"ffmpeg-new" (a binary with the patch), and the test file "Day_Flight.mpg" from
https://samples.ffmpeg.org/MPEG2/mpegts-klv/Day%20Flight.mpg
- Execute these commands:
$ ffmpeg-old -loglevel verbose -y -f mpegts -i Day_Flight.mpg \
-map i:0x1e1 -c:v:0 copy -map i:0x1e1 -c:v:1 copy \
-program st=0 -program st=1 -f mpegts out-error.ts
$ ffmpeg-new -loglevel verbose -y -f mpegts -i Day_Flight.mpg \
-map i:0x1e1 -c:v:0 copy -map i:0x1e1 -c:v:1 copy \
-program st=0 -program st=1 -f mpegts out-ok.ts
- As a result, you have two files "out-error.ts" and "out-ok.ts". Both files
with the same content (but not identical): two services, and each one with one
video stream. However, the first file has errors in the PCR timestamps.
- If you analyze the files, you can see that the file "out-error.ts" has PCR
marks in every packet of the pid 256 (a total of 561862 packets with PCR marks).
However, the pid 257 has 783 packets only with PCR marks. On the other hand,
the file "out-ok.ts" has correct PCR marks, and both pids (256 & 257) only have
783 packets with PCR timestamps.
- You can do additional checks with the tool "tsreport" from the tstools
package.
Try this to see the difference:
$ tsreport -b -v out-ok.ts | more
$ tsreport -b -v out-error.ts | more
Signed-off-by: Andreas Hakon
---
libavformat/mpegtsenc.c | 82 +--
1 file changed, 44 insertions(+), 38 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea22..4a978ed 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -953,46 +953,54 @@ static int mpegts_init(AVFormatContext *s)
av_freep();
-/* if no video stream, use the first stream as PCR */
-if (service->pcr_pid == 0x1fff && s->nb_streams > 0) {
-pcr_st = s->streams[0];
-ts_st= pcr_st->priv_data;
-service->pcr_pid = ts_st->pid;
-} else
-ts_st = pcr_st->priv_data;
-
-if (ts->mux_rate > 1) {
-service->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
- (TS_PACKET_SIZE * 8 * 1000);
-ts->sdt_packet_period = (int64_t)ts->mux_rate * SDT_RETRANS_TIME /
- (TS_PACKET_SIZE * 8 * 1000);
-ts->pat_packet_period = (int64_t)ts->mux_rate * PAT_RETRANS_TIME /
- (TS_PACKET_SIZE * 8 * 1000);
-
-if (ts->copyts < 1)
-ts->first_pcr = av_rescale(s->max_delay, PCR_TIME_BASE,
AV_TIME_BASE);
-} else {
-/* Arbitrary values, PAT/PMT will also be written on video key frames
*/
-ts->sdt_packet_period = 200;
-ts->pat_packet_period = 40;
-if (pcr_st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-int frame_size = av_get_audio_frame_duration2(pcr_st->codecpar, 0);
-if (!frame_size) {
-av_log(s, AV_LOG_WARNING, "frame size not set\n");
-service->pcr_packet_period =
-pcr_st->codecpar->sample_rate / (10 * 512);
+for (i = 0; i < ts->nb_services; i++) {
+service = ts->services[i];
+
+/* if no video stream, use the first stream as PCR */
+if (service->pcr_pid == 0x1fff && s->nb_streams > 0) {
+pcr_st = s->streams[0];
+ts_st= pcr_st->priv_data;
+service->pcr_pid = ts_st->pid;
+} else
+ts_st = pcr_st->priv_data;
+
+if (ts->mux_rate > 1) {
+service->pcr_packet_period = (int64_t)ts->mux_rate *
ts->pcr_period /
+(TS_PACKET_SIZE * 8 * 1000);
+ts->sdt_packet_period = (int64_t)ts->mux_rate *
SDT_RETRANS_TIME /
+(TS_PACKET_SIZE * 8 * 1000);
+ts->pat_packet_period = (int64_t)ts->mux_rate *
PAT_RETRANS_TIME /
+(TS_PACKET_SIZE * 8 * 1000);
+if (ts->copyts < 1)
+ts->first_pcr = av_rescale(s->max_delay, PCR_TIME_BASE,
AV_TIME_BASE);
+} else {
+
[FFmpeg-devel] [PATCH] Use gnutls_set_default_priority
This will use the default priority for gnutls.
When supported, the priority will be set to @SYSTEM which allows to
adapt the ciphers list at runtime according to the policy set.
See also:
https://fedoraproject.org/wiki/Packaging:CryptoPolicies
https://wiki.debian.org/CryptoPolicy
Signed-off-by: Nicolas Chauvet
---
libavformat/tls_gnutls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index f32bc2821b..b30e8ea007 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -181,7 +181,7 @@ static int tls_open(URLContext *h, const char *uri, int
flags, AVDictionary **op
gnutls_transport_set_pull_function(p->session, gnutls_url_pull);
gnutls_transport_set_push_function(p->session, gnutls_url_push);
gnutls_transport_set_ptr(p->session, c->tcp);
-gnutls_priority_set_direct(p->session, "NORMAL", NULL);
+gnutls_set_default_priority (p->session);
do {
ret = gnutls_handshake(p->session);
if (gnutls_error_is_fatal(ret)) {
--
2.17.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".
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix index byte count in partition header
fre 2019-07-19 klockan 09:51 -0700 skrev Baptiste Coudurier:
> Hi Tomas
>
> > On Jul 19, 2019, at 8:48 AM, Tomas Härdin
> > wrote:
> >
> > tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
> > > ---
> > > libavformat/mxfenc.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > index b677f6af8e..2e54320cf0 100644
> > > --- a/libavformat/mxfenc.c
> > > +++ b/libavformat/mxfenc.c
> > > @@ -1944,8 +1944,7 @@ static int
> > > mxf_write_partition(AVFormatContext
> > > *s, int bodysid,
> > > index_byte_count = 80;
> > >
> > > if (index_byte_count) {
> > > -// add encoded ber length
> > > -index_byte_count += 16 +
> > > klv_ber_length(index_byte_count);
> > > +index_byte_count += 16 + 4; // add encoded ber4 length
> > > index_byte_count += klv_fill_size(index_byte_count);
> > > }
> > >
> >
> > Is there a reason why we don't pick a single BER length coding for
> > the
> > entire muxer?
>
> BER It saves space, BER4 is only used when required. No strong
> opinion,
> I think it’s unrelated to this fix though.
Sorry about the late reply. But yeah, just thought it was a bit
strange. BER4 does make computing sizes much easier where possible. The
patch itself is obviously fine
/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, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Gyan
> Sent: Saturday, July 20, 2019 13:29
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index cd35eb49c8..99121b6981 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > +@item -autoscale
> > +Automatically scale the video according to the resolution of first frame.
> > +Enabled by default, use @option{-noautoscale} to disable it. When
> autoscale is
> > +disabled, all output frames might not be in the same resolution and may
> require
> > +some additional explicit processing according to your final
> rendering/output
> > +destination. Disabling autoscale may not work in all situations. Therefore,
> it
> > +is not recommended to disable it unless you really know what you are
> doing.
> > +Disable autoscale at your own risk.
>
> Since the auto scaling happens at the end of the graph, what may the
> "additional explicit processing" be?
Vpp processing may not be influenced, a warning in transcode is needed.
The expression seems to be improper, how about:
"When autoscale is disabled, all output frames of filter graph might not be in
the same
resolution and may be inadequate for encoder/muxer."
or other suggestions?
> > @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> > { "autorotate", HAS_ARG | OPT_BOOL | OPT_SPEC |
> > OPT_EXPERT | OPT_INPUT,
> >{ .off =
> OFFSET(autorotate) },
> > "automatically insert correct rotate filters" },
> > +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> > + OPT_EXPERT | OPT_INPUT,
> > { .off =
> OFFSET(autoscale) },
> > +"automatically insert a scale filter at the end of the filter
> > graph if a
> resolution"
> > +"change is detected. This ensures all frames are the same
> > resolution
> as the first frame"
> > +"when they leave the filter chain (this option is enabled by
> > default)."
> > +"If disabled, some encoders/muxers may not support this mode."},
> Which muxers can detect or check for prop changes within coded
> bitstreams? Which encoders are known to be able to handle
> changing resolution?
It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic
resolution in spec).
I don't intend to be so absolutely in doc, will it be better for you to modify
like:
"If disabled, encoders/muxers won't support this mode currently."
- linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] Fix integer parameters size check in SDP fmtp line
You are right, some values are expected to be <= 32.
However, it doesn't add a bug: Without my patch fail will occur at parsing
time; With my patch it will occur a bit later on check performed by
get_bits_long().
Maybe we can add a specific max value to each parameter to make logs more
accurate on what happens.
On Wed, Jul 17, 2019 at 10:28 PM Michael Niedermayer
wrote:
> On Fri, Jul 12, 2019 at 08:40:40AM +0200, Olivier Maignial wrote:
> > === PROBLEM ===
> >
> > I was trying to record h264 + aac streams from an RTSP server to mp4
> file. using this command line:
> > ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy
> -bsf:a aac_adtstoasc test.mp4
> >
> > FFmpeg then fail to record audio and output this logs:
> > [rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40)
> > [rtsp @ 0xcda1f0] Error parsing AU headers
> > ...
> > [rtsp @ 0xcda1f0] Could not find codec parameters for stream 1
> (Audio: aac, 48000 Hz, 1 channels): unspecified sample format
> >
> > In SDP provided by my RTSP server I had this fmtp line:
> > a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr;
> config=1188; sizeLength=13; indexLength=3; indexDeltaLength=3;
> >
> > In FFmpeg code, I found a check introduced by commit
> 24130234cd9dd733116d17b724ea4c8e12ce097a. It disallows values greater than
> 32 for fmtp line parameters.
> > However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual
> Streams) give examples of "profile-level-id" values for AAC, up to 55.
> > Furthermore, RFC-4566 (SDP: Session Description Protocol) do not give
> any limit of size on interger parameters given in fmtp line.
> >
> > === FIX ===
> >
> > Instead of prohibit values over 32, I propose to check the possible
> integer overflow.
> > The use of strtoll allow to check the string validity and the possible
> overflow.
> > Value is then checked against INT32_MIN and INT32_MAX. Using
> INT32_MIN/MAX ensure to have the same behavior on 32 or 64 bits platforms.
> >
> > This patch fix my problem and I now can record my RTSP AAC stream to mp4.
> > It has passed the full fate tests suite sucessfully.
> >
> > Signed-off-by: Olivier Maignial
> > ---
> >
> > Changes V6 --> V7:
> > - Use long long int and strtoll. LLONG_MAX is always greather than
> INT32_MIN while LONG_MAX can be equal to INT32_MAX. It allows to accept
> full INT32 range.
> > - Avoid to use errno
> >
> > libavformat/rtpdec_mpeg4.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
> > index 4f70599..f1cbedf 100644
> > --- a/libavformat/rtpdec_mpeg4.c
> > +++ b/libavformat/rtpdec_mpeg4.c
> > @@ -289,15 +289,18 @@ static int parse_fmtp(AVFormatContext *s,
> > for (i = 0; attr_names[i].str; ++i) {
> > if (!av_strcasecmp(attr, attr_names[i].str)) {
> > if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
> > -int val = atoi(value);
> > -if (val > 32) {
> > +char *end_ptr = NULL;
> > +long long int val = strtoll(value, _ptr, 10);
> > +if (end_ptr == value || end_ptr[0] != '\0' ||
> > +val < INT32_MIN || val > INT32_MAX) {
> > av_log(s, AV_LOG_ERROR,
> > - "The %s field size is invalid (%d)\n",
> > - attr, val);
> > + "The %s field value is not a valid
> number, or overflows int32: %s\n",
> > + attr, value);
> > return AVERROR_INVALIDDATA;
> > }
> > +
> > *(int *)((char *)data+
> > -attr_names[i].offset) = val;
> > +attr_names[i].offset) = (int) val;
>
> Looking at this a bit deeper, this reads several specific values
> for example sizelength which is then used to read with get_bits_long()
> that is limited to 32bit. Maybe iam missing some check but if not
> that is adding a bug.
> I did not check what the valid range of the other cases is but
> they may have similar problems
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
> ___
> 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] avformat/mov: fix return code for trun box with no sample entries
On 7/21/19, Gyan wrote: > > > On 21-07-2019 02:21 PM, Paul B Mahol wrote: >> On 7/20/19, Gyan wrote: >>> Affected files can now be demuxed. Verified with John Stebbins. FATE >>> passes. >>> >>> Gyan >>> >> You removed negative check, so not ok. > > entries is unsigned (in the code as well as in the standard). So the > value read from file will be >= 0. Even after adjustment for index size > overflow, it cannot become negative. OK then > > 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 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 v5 3/3] lavc/libdavs2.c: reduce memcpy
Can effectivly improved decoding speed when memcpy becomes a limitation
for proccessing high resolution source.
Tested under i7-8700k with `ffmpeg -i 7680x4320.avs2 -vsync 0 -f null -`
got performance 23fps => 42fps
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 52 ---
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 6d66209..32c07fe 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -73,13 +73,22 @@ static av_cold int davs2_init(AVCodecContext *avctx)
return 0;
}
+static void davs2_frame_unref(void *opaque, uint8_t *data) {
+DAVS2Context*cad = (DAVS2Context *)opaque;
+davs2_picture_t pic;
+
+pic.magic = (davs2_picture_t *)data;
+
+if (cad->decoder) {
+davs2_decoder_frame_unref(cad->decoder, );
+}
+}
+
static int davs2_dump_frames(AVCodecContext *avctx, davs2_picture_t *pic, int
*got_frame,
davs2_seq_info_t *headerset, int ret_type,
AVFrame *frame)
{
DAVS2Context *cad= avctx->priv_data;
-int bytes_per_sample = pic->bytes_per_sample;
-int plane = 0;
-int line = 0;
+int plane;
if (!headerset) {
*got_frame = 0;
@@ -117,29 +126,28 @@ static int davs2_dump_frames(AVCodecContext *avctx,
davs2_picture_t *pic, int *g
return AVERROR_EXTERNAL;
}
-for (plane = 0; plane < 3; ++plane) {
-int size_line = pic->widths[plane] * bytes_per_sample;
-frame->buf[plane] = av_buffer_alloc(size_line * pic->lines[plane]);
-
-if (!frame->buf[plane]){
-av_log(avctx, AV_LOG_ERROR, "Decoder error: allocation failure,
can't dump frames.\n");
-return AVERROR(ENOMEM);
-}
-
-frame->data[plane] = frame->buf[plane]->data;
-frame->linesize[plane] = size_line;
-
-for (line = 0; line < pic->lines[plane]; ++line)
-memcpy(frame->data[plane] + line * size_line,
- pic->planes[plane] + line * pic->strides[plane],
- pic->widths[plane] * bytes_per_sample);
-}
-
frame->width = cad->headerset.width;
frame->height= cad->headerset.height;
frame->pts = cad->out_frame.pts;
frame->format= avctx->pix_fmt;
+/* handle the actual picture in magic */
+frame->buf[0]= av_buffer_create((uint8_t *)pic->magic,
+sizeof(davs2_picture_t *),
+davs2_frame_unref,
+(void *)cad,
+AV_BUFFER_FLAG_READONLY);
+if (!frame->buf[0]) {
+av_log(avctx, AV_LOG_ERROR,
+"Decoder error: allocation failure, can't dump frames.\n");
+return AVERROR(ENOMEM);
+}
+
+for (plane = 0; plane < 3; ++plane) {
+frame->linesize[plane] = pic->strides[plane];
+frame->data[plane] = pic->planes[plane];
+}
+
*got_frame = 1;
return 0;
}
@@ -171,7 +179,6 @@ static int send_delayed_frame(AVCodecContext *avctx,
AVFrame *frame, int *got_fr
}
if (ret == DAVS2_GOT_FRAME) {
ret = davs2_dump_frames(avctx, >out_frame, got_frame,
>headerset, ret, frame);
-davs2_decoder_frame_unref(cad->decoder, >out_frame);
}
return ret;
}
@@ -220,7 +227,6 @@ static int davs2_decode_frame(AVCodecContext *avctx, void
*data,
if (ret != DAVS2_DEFAULT) {
ret = davs2_dump_frames(avctx, >out_frame, got_frame,
>headerset, ret, frame);
-davs2_decoder_frame_unref(cad->decoder, >out_frame);
}
return ret == 0 ? buf_size : ret;
--
2.7.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 v5 1/3] lavc/avs2_parser.c: fix missing start code
Signed-off-by: hwrenx
---
libavcodec/avs2_parser.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/avs2_parser.c b/libavcodec/avs2_parser.c
index 1c9b342..dc2fa16 100644
--- a/libavcodec/avs2_parser.c
+++ b/libavcodec/avs2_parser.c
@@ -23,8 +23,10 @@
#define SLICE_MAX_START_CODE0x01af
+#define ISSQH(x) ((x) == 0xB0 )
+#define ISEND(x) ((x) == 0xB1 )
#define ISPIC(x) ((x) == 0xB3 || (x) == 0xB6)
-#define ISUNIT(x) ((x) == 0xB0 || (x) == 0xB1 || (x) == 0xB2 || ISPIC(x))
+#define ISUNIT(x) ( ISSQH(x) || ISEND(x) || (x) == 0xB2 || ISPIC(x) || (x) ==
0xB5 || (x) == 0xB7 )
static int avs2_find_frame_end(ParseContext *pc, const uint8_t *buf, int
buf_size)
{
--
2.7.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 v5 0/3] optimize frame dumping and fix missing start codes
Version 5: 1. Using ifs for log level instead of expressions. Version 4: 1. Change info level setting. 2. Remove `Decoder not found` condition. The previous version 2 patches were deprecated for using pointer to itself can be unsafe when release frames. This patch set is mainly about avoiding using memcpy when fetching frame data, and fixed missing start codes which may cause error packetization sometime. Default info level of libdavs2 was changed because we found debug info is useless in most of the time. hwrenx (3): lavc/avs2_parser.c: fix missing start code lavc/libdavs2.c: fix decoder info level setting lavc/libdavs2.c: reduce memcpy libavcodec/avs2_parser.c | 4 ++- libavcodec/libdavs2.c| 69 +++- 2 files changed, 48 insertions(+), 25 deletions(-) The performance comparison is like following: [Platform] Intel® Core™ i7-8700k CPU @ 3.70GHz × 6 / 16GiB [Command] ffmpeg -i test.avs2 -vsync 0 -f null - [Stream] 7680x4320 yuv420p Random Access [Original version] frame= 2669 fps= 23 q=-0.0 Lsize=N/A time=00:00:53.44 bitrate=N/A speed=0.465x [Optimized version] frame= 2669 fps= 42 q=-0.0 Lsize=N/A time=00:00:53.44 bitrate=N/A speed=0.836x -- 2.7.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 v5 2/3] lavc/libdavs2.c: fix decoder info level setting
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 218f3ec..6d66209 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -37,14 +37,29 @@ typedef struct DAVS2Context {
}DAVS2Context;
+static int davs2_log_get_level(int log_level)
+{
+if (log_level <= AV_LOG_ERROR)
+return DAVS2_LOG_ERROR;
+
+if (log_level <= AV_LOG_WARNING)
+return DAVS2_LOG_WARNING;
+
+if (log_level <= AV_LOG_INFO)
+return DAVS2_LOG_INFO;
+
+return DAVS2_LOG_DEBUG;
+}
+
static av_cold int davs2_init(AVCodecContext *avctx)
{
DAVS2Context *cad = avctx->priv_data;
int cpu_flags = av_get_cpu_flags();
+int log_level = av_log_get_level();
/* init the decoder */
cad->param.threads = avctx->thread_count;
-cad->param.info_level = 0;
+cad->param.info_level = davs2_log_get_level(log_level);
cad->param.disable_avx = !(cpu_flags & AV_CPU_FLAG_AVX &&
cpu_flags & AV_CPU_FLAG_AVX2);
cad->decoder= davs2_decoder_open(>param);
--
2.7.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 4/4] avcodec/mediacodec_wrapper: remove unused local variables in ff_AMediaCodec_getCodecNameByType()
On Fri, Jul 19, 2019 at 09:40:52AM +0200, Matthieu Bouron wrote:
> On Sun, Jul 14, 2019 at 08:17:03PM +0200, Matthieu Bouron wrote:
> > On Thu, Jul 04, 2019 at 03:43:48PM +0200, Matthieu Bouron wrote:
> > > ---
> > > libavcodec/mediacodec_wrapper.c | 10 --
> > > 1 file changed, 10 deletions(-)
> > >
> > > diff --git a/libavcodec/mediacodec_wrapper.c
> > > b/libavcodec/mediacodec_wrapper.c
> > > index 70e1e7cae1..5213cf640a 100644
> > > --- a/libavcodec/mediacodec_wrapper.c
> > > +++ b/libavcodec/mediacodec_wrapper.c
> > > @@ -392,8 +392,6 @@ char *ff_AMediaCodecList_getCodecNameByType(const
> > > char *mime, int profile, int e
> > > struct JNIAMediaCodecListFields jfields = { 0 };
> > > struct JNIAMediaFormatFields mediaformat_jfields = { 0 };
> > >
> > > -jobject format = NULL;
> > > -jobject codec = NULL;
> > > jobject codec_name = NULL;
> > >
> > > jobject info = NULL;
> > > @@ -571,14 +569,6 @@ done_with_info:
> > > }
> > >
> > > done:
> > > -if (format) {
> > > -(*env)->DeleteLocalRef(env, format);
> > > -}
> > > -
> > > -if (codec) {
> > > -(*env)->DeleteLocalRef(env, codec);
> > > -}
> > > -
> > > if (codec_name) {
> > > (*env)->DeleteLocalRef(env, codec_name);
> > > }
> > > --
> > > 2.22.0
> > >
> >
> > Ping for the patch set.
>
> If there is no objection, I will push the patchset in a few days.
>
Pushed to master. Is it still on time to also be pushed to the 4.2 release
branch ?
Thanks.
--
Matthieu B.
___
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] avcodec: add a WavPack DSD decoder
On 7/22/19, David Bryant wrote: > Hi, > > As I promised late last year, here is a patch to add a WavPack DSD decoder. > > Thanks! > > -David Bryant > > Please correct me if I'm wrong, but why this uses new codec id? Apparently is also copies some logic from other files. ___ 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 4/4] avcodec/hqx: Check the input data against the image size
On 7/21/19, Michael Niedermayer wrote: > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: >> On 7/21/19, Michael Niedermayer wrote: >> > Fixes: Timeout (22 -> 7 sec) >> > Fixes: >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 >> > >> > Found-by: continuous fuzzing process >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > Signed-off-by: Michael Niedermayer >> > --- >> > libavcodec/hqx.c | 4 >> > 1 file changed, 4 insertions(+) >> > >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c >> > index bc24ba91d1..8639d77a41 100644 >> > --- a/libavcodec/hqx.c >> > +++ b/libavcodec/hqx.c >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext *avctx, >> > void >> > *data, >> > avctx->height = ctx->height; >> > avctx->bits_per_raw_sample = 10; >> > >> > +if (avctx->coded_width / 16 * (avctx->coded_height / 16) * >> > +(100 - avctx->discard_damaged_percentage) / 100 > 8LL * >> > avpkt->size) >> > +return AVERROR_INVALIDDATA; >> >> Why just this change and not something better? > > What would you prefer exactly ? Something that works with pure black video. > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Modern terrorism, a quick summary: Need oil, start war with country that > has oil, kill hundread thousand in war. Let country fall into chaos, > be surprised about raise of fundamantalists. Drop more bombs, kill more > people, be surprised about them taking revenge and drop even more bombs > and strip your own citizens of their rights and freedoms. to be continued > ___ 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".
