[FFmpeg-devel] fate/exr : add test for ticket 6994 (long name flag)
Hello, Patch in attach add test for ticket 6994 (flag long name) Sample can be found here : https://we.tl/WBnt10VSA1 and need to be put inside ./fate-suite/exr Can be test with : make fate-exr SAMPLES=fate-suite/ Need to be apply after one of the patch in discussion : "lavc/exr: Ignore long names flag" Martin 0009-fate-exr-add-test-for-long-name-flag.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp3: Check eob_run
On 2/9/18, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: 5919/clusterfuzz-testcase-minimized-5859311382167552
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp3.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> index cf9c57f5fa..120c20f349 100644
> --- a/libavcodec/vp3.c
> +++ b/libavcodec/vp3.c
> @@ -978,6 +978,9 @@ static int unpack_vlcs(Vp3DecodeContext *s,
> GetBitContext *gb,
> if (eob_run_get_bits[token])
> eob_run += get_bits(gb, eob_run_get_bits[token]);
>
> +if (!eob_run)
> +return AVERROR_INVALIDDATA;
> +
> // record only the number of blocks ended in this plane,
> // any spill will be recorded in the next plane.
> if (eob_run > num_coeffs - coeff_i) {
> --
> 2.16.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
probably ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] Add muxer/demuxer for raw codec2 and .c2 files
Ping? I'd maintain this of course. Plus I'd like to add some tests, but I need to know if this looks OK to everyone first /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]configure: Improve the wording of the license failure
Hi!
It was reported on the user mailing list that "libvmaf is version3 and
--enable-version3 is not specified." is unclear, attached patch tries
to slightly improve the sentence.
Please comment, Carl Eugen
From c0170122c42f9837dc188296e6d66ad37258febe Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 9 Feb 2018 11:04:03 +0100
Subject: [PATCH] configure: Improve the wording of the license failure
message.
---
configure |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 2711382..3883057 100755
--- a/configure
+++ b/configure
@@ -3767,11 +3767,11 @@ EOF
fi
die_license_disabled() {
-enabled $1 || { enabled $v && die "$v is $1 and --enable-$1 is not specified."; }
+enabled $1 || { enabled $v && die "$v requires $1 for license reasons but --enable-$1 is not specified."; }
}
die_license_disabled_gpl() {
-enabled $1 || { enabled $v && die "$v is incompatible with the gpl and --enable-$1 is not specified."; }
+enabled $1 || { enabled $v && die "$v is incompatible with the gpl but --enable-$1 is not specified."; }
}
map "die_license_disabled gpl" $EXTERNAL_LIBRARY_GPL_LIST $EXTERNAL_LIBRARY_GPLV3_LIST
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
2018-02-09 7:38 GMT+01:00 Jerome Martinez : > On 09/02/2018 02:19, Carl Eugen Hoyos wrote: >> >> 2018-02-08 11:28 GMT+01:00 Jerome Martinez : >>> >>> Currently RGB and RGBA 12-bit are supported by DPX decoder only if >>> component >>> values are padded (packing "Filled to 32-bit words, method A"). >>> This patch adds decoding of RGB >>> and RGBA 12-bit with no padding (packing "Packed into 32-bit words"). >> >> I suggest we wait with this patch until we verified if RGBA dpx decoding >> is broken (I suspect so, I believe you have a sample to verify). > > > Sorry, I see a line was missing in my first post, the one with the link to > the RGBA test file. > Test file for RGBA 12-bit packed: > https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGBA_12_Packed_BE Is this a sample from a four-channel film scanner (with infrared channel)? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/format: temporarily use old next api
Should fix https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225066.html
Signed-off-by: Muhammad Faiz
---
The actual problem is that av*next() and av*iterate() have different
semantics:
- av*next() iterate all formats+devices
- av*iterate() iterate formats only.
Is this the intended behaviour?
libavformat/format.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavformat/format.c b/libavformat/format.c
index b8c5a90a92..75951938cf 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -52,7 +52,9 @@ AVOutputFormat *av_guess_format(const char *short_name, const
char *filename,
const char *mime_type)
{
AVOutputFormat *fmt = NULL, *fmt_found;
+#if !FF_API_NEXT
void *i = 0;
+#endif
int score_max, score;
/* specific test for image sequences */
@@ -66,7 +68,13 @@ AVOutputFormat *av_guess_format(const char *short_name,
const char *filename,
/* Find the proper file type. */
fmt_found = NULL;
score_max = 0;
-while ((fmt = av_muxer_iterate(&i))) {
+#if FF_API_NEXT
+FF_DISABLE_DEPRECATION_WARNINGS
+while ((fmt = av_oformat_next(fmt)))
+#else
+while ((fmt = av_muxer_iterate(&i)))
+#endif
+ {
score = 0;
if (fmt->name && short_name && av_match_name(short_name, fmt->name))
score += 100;
@@ -81,6 +89,9 @@ AVOutputFormat *av_guess_format(const char *short_name, const
char *filename,
fmt_found = fmt;
}
}
+#if FF_API_NEXT
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
return fmt_found;
}
--
2.13.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] Add muxer/demuxer for raw codec2 and .c2 files
2018-01-15 22:36 GMT+01:00 Tomas Härdin : >> +if (p->buf[4] > EXPECTED_CODEC2_MINOR_VERSION) score -= >> AVPROBE_SCORE_MAX/5; >> +if (p->buf[5] > AVPRIV_CODEC2_MODE_MAX)score -= >> AVPROBE_SCORE_MAX/5; >> +if (p->buf[6] != 0) score -= >> AVPROBE_SCORE_MAX/5; >> +return score; >> >> Imo, this is too complicated: >> If the first 32bit are correct, return MAX/2, for 24bit, return less This should have been AVPROBE_SCORE_EXTENSION + 1, sorry about my mistake. Please threaten to push this and push after a few days. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
2018-02-09 11:15 GMT+01:00 Carl Eugen Hoyos : > 2018-02-09 7:38 GMT+01:00 Jerome Martinez : >> Sorry, I see a line was missing in my first post, the one with the link to >> the RGBA test file. >> Test file for RGBA 12-bit packed: >> https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGBA_12_Packed_BE > > Is this a sample from a four-channel film scanner (with infrared channel)? No, it is not, please mention ticket #5639 in the commit message. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
On 09/02/2018 11:15, Carl Eugen Hoyos wrote: Sorry, I see a line was missing in my first post, the one with the link to the RGBA test file. Test file for RGBA 12-bit packed: https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGBA_12_Packed_BE Is this a sample from a four-channel film scanner (with infrared channel)? I think the question is out of topic for this patch proposal, as this question is global for all flavors of DPX (also the ones already supported by FFmpeg, i.e. FFmpeg already supports RGBA 12-bit filled with Method A, here I just add the support for packed content, without adding anything else about alpha support in FFmpeg, this patch changes nothing about alpha support in FFmpeg and/or DPX) and the need for validating such patch is about sample files for RGBA 12-bit packed (RGBA 12-bit filled with method A being already available) and not for the content itself. If it is blocking for the patch inclusion, I could remove the line permitting RGBA Packed decoding. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures
2018-02-09 3:51 GMT+01:00 Nekopanda : >> From: Carl Eugen Hoyos >>> Yes, I have files that show artifacts without this change. Recently, >>> Japanese satellite television started to use field pictures widely, >>> and many of that show artifacts. We need this change to remove >>> the artifacts. >> >> Could you provide a sample with visible artefacts? > > Sorry, all of them are copyrighted materials and difficult to share. Please find a few seconds of commercials that show the issue and share them. Many thousand samples were provided here, very few were not copyrighted. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
2018-02-09 11:34 GMT+01:00 Jerome Martinez :
> On 09/02/2018 11:15, Carl Eugen Hoyos wrote:
>>
>>
>>> Sorry, I see a line was missing in my first post, the one with the link
>>> to
>>> the RGBA test file.
>>> Test file for RGBA 12-bit packed:
>>>
>>> https://github.com/MediaArea/RAWcooked-RegressionTestingFiles/tree/master/Formats/DPX/Flavors/RGBA_12_Packed_BE
>>
>> Is this a sample from a four-channel film scanner (with infrared channel)?
>
>
> I think the question is out of topic for this patch proposal, as this
> question is global for all flavors of DPX (also the ones already supported
> by FFmpeg, i.e. FFmpeg already supports RGBA 12-bit filled with Method A,
> here I just add the support for packed content, without adding anything else
> about alpha support in FFmpeg, this patch changes nothing about alpha
> support in FFmpeg and/or DPX) and the need for validating such patch is
> about sample files for RGBA 12-bit packed (RGBA 12-bit filled with method A
> being already available) and not for the content itself.
Sorry, I thought you had access to such a sample and we would
just have to test it, no?
One more minor issue:
> +}
> +else {
This is getting very common now (do you know why?), please fix it.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: sort codec_descriptors
On Fri, Feb 9, 2018 at 9:11 AM, Michael Niedermayer wrote: > On Sat, Feb 03, 2018 at 01:35:34AM +0700, Muhammad Faiz wrote: >> Use bsearch on avcodec_descriptor_get(). >> >> Signed-off-by: Muhammad Faiz >> --- >> libavcodec/codec_desc.c | 1103 >> --- >> 1 file changed, 563 insertions(+), 540 deletions(-) > > probably ok Pushed. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer wrote: > On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote: >> Josh de Kock (2018-02-06): >> > ffmpeg | branch: master | Josh de Kock | Fri Dec 22 >> > 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | >> > committer: Josh de Kock >> > >> > lavc: add new API for iterating codecs and codec parsers >> > >> > Based on an unfinished patch by atomnuker. > > This commit also breaks > > ./configure --enable-libsoxr && make -j12 fate-checkasm > make -j12 fate-checkasm > ... > LD tests/checkasm/checkasm > libswresample/libswresample.a(soxr_resample.o): In function `get_out_samples': > ffmpeg/libswresample/soxr_resample.c:118: undefined reference to `soxr_delay' > libswresample/libswresample.a(soxr_resample.o): In function `get_delay': > ffmpeg/libswresample/soxr_resample.c:100: undefined reference to `soxr_delay' > libswresample/libswresample.a(soxr_resample.o): In function `flush': > ffmpeg/libswresample/soxr_resample.c:70: undefined reference to `soxr_delay' > ffmpeg/libswresample/soxr_resample.c:72: undefined reference to `soxr_process' > ffmpeg/libswresample/soxr_resample.c:77: undefined reference to `soxr_process' > ffmpeg/libswresample/soxr_resample.c:78: undefined reference to `soxr_delay' > libswresample/libswresample.a(soxr_resample.o): In function `process': > ffmpeg/libswresample/soxr_resample.c:88: undefined reference to > `soxr_set_num_channels' > ffmpeg/libswresample/soxr_resample.c:88: undefined reference to > `soxr_set_error' > ffmpeg/libswresample/soxr_resample.c:90: undefined reference to `soxr_process' > libswresample/libswresample.a(soxr_resample.o): In function `destroy': > ffmpeg/libswresample/soxr_resample.c:65: undefined reference to `soxr_delete' > libswresample/libswresample.a(soxr_resample.o): In function `create': > ffmpeg/libswresample/soxr_resample.c:46: undefined reference to `soxr_io_spec' > ffmpeg/libswresample/soxr_resample.c:48: undefined reference to > `soxr_quality_spec' > ffmpeg/libswresample/soxr_resample.c:56: undefined reference to `soxr_delete' > ffmpeg/libswresample/soxr_resample.c:57: undefined reference to `soxr_create' > collect2: error: ld returned 1 exit status > make: *** [tests/checkasm/checkasm] Error 1 Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1 Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
On 09/02/2018 11:32, Carl Eugen Hoyos wrote:
[...] please mention ticket #5639 in the commit message.
I should definitely have indicated this source instead of my copy, my
mistake.
Commit message extended with it.
FYI I am running tests on several DPX flavors (to FFV1 and back to DPX,
checking that framemd5 is same in order to be sure the lossless
compression is really lossless), including the ones in this ticket, I'll
post a message in this ticket when I finish and all files are well
supported in FFmpeg.
On 09/02/2018 11:39, Carl Eugen Hoyos wrote:
Sorry, I thought you had access to such a sample and we would
just have to test it, no?
I use to stay on a technical side, if the DPX header says alpha I map to
alpha (no way to differentiate from an illegitimate content, technically
speaking), whatever are the hacks used by users (my goal is to store
content with FFV1 in order to save disk space then convert back to DPX
when needed, so such hack are the user problem and are not visible by
FFmpeg). Sometimes I have contact with the source provider, sometimes
not. I think some of the files I get are hacked with infrared instead of
alpha, if you are interested in a sample file with infrared-hacked
content for sure I'll ask if it is the case for some files I have. But
not blocking for the patch IMO (especially because the files I am
thinking to are not 12-bit)
One more minor issue:
+}
+else {
This is getting very common now (do you know why?),
Different projects, different C style standards, so sometimes some
mistakes when people work on several projects.
(here, it was due to automatic edition from a code editor having a
different standard by default, and I missed it when I reviewed the style)
please fix it.
Fixed, updated patch attached.
From 986379350bc788701e39e2d6f9fce55b61b5fbb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Thu, 8 Feb 2018 09:22:08 +0100
Subject: [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
Limited to widths multiple of 8 (RGB) and 2 (RGBA) due to lack of test files
for such corner case
This partially fixes ticket #5639
---
libavcodec/dpx.c | 69 +---
1 file changed, 66 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 1aa2cbd1c8..7535de6c23 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -65,6 +65,38 @@ static uint16_t read10in32(const uint8_t **ptr, uint32_t *
lbuf,
return *lbuf & 0x3FF;
}
+static uint16_t read12in32(const uint8_t **ptr, uint32_t * lbuf,
+ int * n_datum, int is_big)
+{
+if (*n_datum)
+(*n_datum)--;
+else {
+*lbuf = read32(ptr, is_big);
+*n_datum = 7;
+}
+
+switch (*n_datum){
+case 7: return *lbuf & 0xFFF;
+case 6: return (*lbuf >> 12) & 0xFFF;
+case 5: {
+uint32_t c = *lbuf >> 24;
+*lbuf = read32(ptr, is_big);
+c |= *lbuf << 8;
+return c & 0xFFF;
+}
+case 4: return (*lbuf >> 4) & 0xFFF;
+case 3: return (*lbuf >> 16) & 0xFFF;
+case 2: {
+uint32_t c = *lbuf >> 28;
+*lbuf = read32(ptr, is_big);
+c |= *lbuf << 4;
+return c & 0xFFF;
+}
+case 1: return (*lbuf >> 8) & 0xFFF;
+default: return *lbuf >> 20;
+}
+}
+
static int decode_frame(AVCodecContext *avctx,
void *data,
int *got_frame,
@@ -201,10 +233,29 @@ static int decode_frame(AVCodecContext *avctx,
break;
case 12:
if (!packing) {
-av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
-return -1;
+int tested = 0;
+if (endian && descriptor == 50 && (avctx->width%8) == 0) // Little
endian and widths not a multiple of 8 need tests
+tested = 1;
+if (endian && descriptor == 51 && (avctx->width%2) == 0) // Little
endian and widths not a multiple of 2 need tests
+tested = 1;
+if (!tested) {
+av_log(avctx, AV_LOG_ERROR, "Packing to 16bit required\n");
+return -1;
+}
+}
+stride = avctx->width * elements;
+if (packing)
+stride *= 2;
+else {
+stride *= 3; // 12 bits are 1.5 byte so multiplied by 3 then
divided by 2
+if (stride % 8) {
+// Align to 32-bit boundaries (not tested)
+stride /= 8;
+stride++;
+stride *= 8;
+}
+stride /= 2;
}
-stride = 2 * avctx->width * elements;
break;
case 16:
stride = 2 * avctx->width * elements;
@@ -349,6 +400,7 @@ static int decode_frame(AVCodecContext *avctx,
(uint16_t*)ptr[2],
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
Muhammad Faiz (2018-02-08): > I actually prefer _next() without introducing new API. Yeah, it is > slower because it must initialize next pointer I am not sure what you mean here. The problem with initing the next pointer was never speed. The problem with the next pointer is that it requires a run-time write in the codec structure, that requires it to be in the data section instead of the rodata section. The static init of this pointer, as you proposed, fixes that specific issue. But that is still a linked list. Linked lists are very good when you need to insert and remove in the list frequently, but for something that is built once and then static, it has very limited usefulness. If the drawback of memory management for solution C (returning the whole list at once) is considered too bad, then I think solution B is preferable: more versatile, easier to understand. And by the way, until we decide between solutions A, B, C or anything else proposed, starting coding would be useless. Just as starting to pack your bags before deciding whether you go to the sea or mountain. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
Hi both, I'm just wondering if the past duration errors in my earlier email mean anything,or should they be ignored? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding
On 09/02/2018 12:20, Kieran O Leary wrote: Hi both, I'm just wondering if the past duration errors in my earlier email mean anything,or should they be ignored? They are independent from the patch, e.g.: https://stackoverflow.com/questions/30782771/what-does-past-duration-x-xxx-too-large-mean ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
On 2/9/2018 7:56 AM, Muhammad Faiz wrote: > On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer > wrote: >> On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote: >>> Josh de Kock (2018-02-06): ffmpeg | branch: master | Josh de Kock | Fri Dec 22 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | committer: Josh de Kock lavc: add new API for iterating codecs and codec parsers Based on an unfinished patch by atomnuker. >> >> This commit also breaks >> >> ./configure --enable-libsoxr && make -j12 fate-checkasm >> make -j12 fate-checkasm >> ... >> LD tests/checkasm/checkasm >> libswresample/libswresample.a(soxr_resample.o): In function >> `get_out_samples': >> ffmpeg/libswresample/soxr_resample.c:118: undefined reference to `soxr_delay' >> libswresample/libswresample.a(soxr_resample.o): In function `get_delay': >> ffmpeg/libswresample/soxr_resample.c:100: undefined reference to `soxr_delay' >> libswresample/libswresample.a(soxr_resample.o): In function `flush': >> ffmpeg/libswresample/soxr_resample.c:70: undefined reference to `soxr_delay' >> ffmpeg/libswresample/soxr_resample.c:72: undefined reference to >> `soxr_process' >> ffmpeg/libswresample/soxr_resample.c:77: undefined reference to >> `soxr_process' >> ffmpeg/libswresample/soxr_resample.c:78: undefined reference to `soxr_delay' >> libswresample/libswresample.a(soxr_resample.o): In function `process': >> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to >> `soxr_set_num_channels' >> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to >> `soxr_set_error' >> ffmpeg/libswresample/soxr_resample.c:90: undefined reference to >> `soxr_process' >> libswresample/libswresample.a(soxr_resample.o): In function `destroy': >> ffmpeg/libswresample/soxr_resample.c:65: undefined reference to `soxr_delete' >> libswresample/libswresample.a(soxr_resample.o): In function `create': >> ffmpeg/libswresample/soxr_resample.c:46: undefined reference to >> `soxr_io_spec' >> ffmpeg/libswresample/soxr_resample.c:48: undefined reference to >> `soxr_quality_spec' >> ffmpeg/libswresample/soxr_resample.c:56: undefined reference to `soxr_delete' >> ffmpeg/libswresample/soxr_resample.c:57: undefined reference to `soxr_create' >> collect2: error: ld returned 1 exit status >> make: *** [tests/checkasm/checkasm] Error 1 > > Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1 > > Thank's. This is not a proper solution. swr is pulled by avcodec only if Opus decoder is enabled. There's no reason to hardcode it for checkasm otherwise. The problem here is that the Makefile should pull all the dependencies of its hardcoded dependencies. This is what FFLIBS and FFEXTRALIBS do in common.mak to link the actual libraries. That said, was this really a regression generated by this commit? It looks unrelated. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/format: temporarily use old next api
On 2/9/2018 7:16 AM, Muhammad Faiz wrote:
> Should fix https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225066.html
>
> Signed-off-by: Muhammad Faiz
> ---
> The actual problem is that av*next() and av*iterate() have different
> semantics:
> - av*next() iterate all formats+devices
> - av*iterate() iterate formats only.
> Is this the intended behaviour?
>
> libavformat/format.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/format.c b/libavformat/format.c
> index b8c5a90a92..75951938cf 100644
> --- a/libavformat/format.c
> +++ b/libavformat/format.c
> @@ -52,7 +52,9 @@ AVOutputFormat *av_guess_format(const char *short_name,
> const char *filename,
> const char *mime_type)
> {
> AVOutputFormat *fmt = NULL, *fmt_found;
> +#if !FF_API_NEXT
> void *i = 0;
> +#endif
> int score_max, score;
>
> /* specific test for image sequences */
> @@ -66,7 +68,13 @@ AVOutputFormat *av_guess_format(const char *short_name,
> const char *filename,
> /* Find the proper file type. */
> fmt_found = NULL;
> score_max = 0;
> -while ((fmt = av_muxer_iterate(&i))) {
> +#if FF_API_NEXT
> +FF_DISABLE_DEPRECATION_WARNINGS
> +while ((fmt = av_oformat_next(fmt)))
> +#else
> +while ((fmt = av_muxer_iterate(&i)))
> +#endif
> + {
> score = 0;
> if (fmt->name && short_name && av_match_name(short_name, fmt->name))
> score += 100;
> @@ -81,6 +89,9 @@ AVOutputFormat *av_guess_format(const char *short_name,
> const char *filename,
> fmt_found = fmt;
> }
> }
> +#if FF_API_NEXT
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
> return fmt_found;
> }
Is your intention to schedule this change to happen once the deprecation
period ends two years from now, or were you just disabling it for a bit
until the new API is fixed/finalized?
If the latter, then please don't add the wrappers. Just replace the
_iterate() calls.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures
> From: Carl Eugen Hoyos > > 2018-02-09 3:51 GMT+01:00 Nekopanda > : >>> From: Carl Eugen Hoyos > Yes, I have files that show artifacts without this change. > Recently, Japanese satellite television started to use field pictures > widely, and many of that show artifacts. We need this change to remove the artifacts. >>> >>> Could you provide a sample with visible artefacts? >> >> Sorry, all of them are copyrighted materials and difficult to share. > > Please find a few seconds of commercials that show the issue > and share them. > > Many thousand samples were provided here, very few were > not copyrighted. OK. Here is. http://nekopandanet.sakura.ne.jp/tmp/v/field-pic-bug.mpg Decoded frame with artifacts http://nekopandanet.sakura.ne.jp/tmp/v/pic-09.png ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp3: Check eob_run
On Fri, Feb 09, 2018 at 04:41:44AM +0100, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: 5919/clusterfuzz-testcase-minimized-5859311382167552
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp3.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> index cf9c57f5fa..120c20f349 100644
> --- a/libavcodec/vp3.c
> +++ b/libavcodec/vp3.c
> @@ -978,6 +978,9 @@ static int unpack_vlcs(Vp3DecodeContext *s, GetBitContext
> *gb,
> if (eob_run_get_bits[token])
> eob_run += get_bits(gb, eob_run_get_bits[token]);
>
> +if (!eob_run)
> +return AVERROR_INVALIDDATA;
> +
> // record only the number of blocks ended in this plane,
> // any spill will be recorded in the next plane.
> if (eob_run > num_coeffs - coeff_i) {
this is incorrect for theora, (its correct for vp3) i will post a better patch
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/vp3: Check eob_run
Fixes: out of array access
Fixes: 5919/clusterfuzz-testcase-minimized-5859311382167552
Fixes: special case for theora (untested due to lack of sample)
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp3.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index cf9c57f5fa..33be345c14 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -978,6 +978,9 @@ static int unpack_vlcs(Vp3DecodeContext *s, GetBitContext
*gb,
if (eob_run_get_bits[token])
eob_run += get_bits(gb, eob_run_get_bits[token]);
+if (!eob_run)
+eob_run = INT_MAX;
+
// record only the number of blocks ended in this plane,
// any spill will be recorded in the next plane.
if (eob_run > num_coeffs - coeff_i) {
--
2.16.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol
On Fri, 9 Feb 2018 03:08:26 +0100 Michael Niedermayer wrote: > On Tue, Jan 30, 2018 at 04:11:03PM -0500, Nablet Developer wrote: > > protocol requires libsrt (https://github.com/Haivision/srt) to be > > installed > > > > Signed-off-by: Nablet Developer > > --- > > MAINTAINERS | 1 + > > configure | 9 + > > doc/protocols.texi | 116 + > > libavformat/Makefile| 1 + > > libavformat/opensrt.c | 621 > > > > libavformat/protocols.c | 1 + > > 6 files changed, 749 insertions(+) > > create mode 100644 libavformat/opensrt.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index ba7a728..0317f24 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -498,6 +498,7 @@ Protocols: > >http.cRonald S. Bultje > >libssh.c Lukasz Marek > >mms*.cRonald S. Bultje > > + opensrt.c Nablet Developer > >udp.c Luca Abeni > >icecast.c Marvin Scholz > > Is "Nablet Developer" identifying a single person ? > if not this is not ok as the MAINTAINERS files gives one also the right to > have git write access and that would not work with a unspecified group I'd assume this is under the copyright of that nablet company. I'd advise against just giving some drive-by contributor git push access (who is probably multiple persons under a single account too). I have no idea why you'd even consider that. Also, the irony of the situation is that the whole diff context in this patch consists of outdated entries. Ronald basically doesn't care about HTTP or MMS anymore, Lukasz didn't post here for 2 years, Luca didn't post here for at least 5 years, and refused my mpv relicensing request because he has utterly negative memories of ffmpeg & co, and Marvin didn't post here for about 4 years. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] Add muxer/demuxer for raw codec2 and .c2 files
On 2018-02-09 11:29, Carl Eugen Hoyos wrote: 2018-01-15 22:36 GMT+01:00 Tomas Härdin : +if (p->buf[4] > EXPECTED_CODEC2_MINOR_VERSION) score -= AVPROBE_SCORE_MAX/5; +if (p->buf[5] > AVPRIV_CODEC2_MODE_MAX)score -= AVPROBE_SCORE_MAX/5; +if (p->buf[6] != 0) score -= AVPROBE_SCORE_MAX/5; +return score; Imo, this is too complicated: If the first 32bit are correct, return MAX/2, for 24bit, return less This should have been AVPROBE_SCORE_EXTENSION + 1, sorry about my mistake. Alright. A documentation update may be in order unless already done Please threaten to push this and push after a few days. Don't have ssh access, but I believe Michael has offered to add me several times. I'll email him a GPG signed copy of a public SSH key when I get home /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol
On Fri, Feb 09, 2018 at 02:28:41PM +0100, wm4 wrote: > On Fri, 9 Feb 2018 03:08:26 +0100 > Michael Niedermayer wrote: > > > On Tue, Jan 30, 2018 at 04:11:03PM -0500, Nablet Developer wrote: > > > protocol requires libsrt (https://github.com/Haivision/srt) to be > > > installed > > > > > > Signed-off-by: Nablet Developer > > > --- > > > MAINTAINERS | 1 + > > > configure | 9 + > > > doc/protocols.texi | 116 + > > > libavformat/Makefile| 1 + > > > libavformat/opensrt.c | 621 > > > > > > libavformat/protocols.c | 1 + > > > 6 files changed, 749 insertions(+) > > > create mode 100644 libavformat/opensrt.c > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index ba7a728..0317f24 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -498,6 +498,7 @@ Protocols: > > >http.cRonald S. Bultje > > >libssh.c Lukasz Marek > > >mms*.cRonald S. Bultje > > > + opensrt.c Nablet Developer > > >udp.c Luca Abeni > > >icecast.c Marvin Scholz > > > > Is "Nablet Developer" identifying a single person ? > > if not this is not ok as the MAINTAINERS files gives one also the right to > > have git write access and that would not work with a unspecified group > > I'd assume this is under the copyright of that nablet company. I'd > advise against just giving some drive-by contributor git push > access (who is probably multiple persons under a single account too). I > have no idea why you'd even consider that. If you or any other developer is against someone receiving git write access you only need to object to the patch adding him to the MAINTAINERS file. Thats one of the reasons why there is a MAINTAINERs file. It would be ideal IMO if for each part of teh codebase at least one person with write access cares/"Maintains" it. Is there someone who already has write access who wants to take care of opensrt.c ? (it seemed there is little interrest from teh lack of replies in the thread so far) Also i belive there already is a developer from nablet who is in the MAINTAINERs file and has write access. thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
On Fri, Feb 9, 2018 at 6:53 PM, James Almer wrote: > On 2/9/2018 7:56 AM, Muhammad Faiz wrote: >> On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer >> wrote: >>> On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote: Josh de Kock (2018-02-06): > ffmpeg | branch: master | Josh de Kock | Fri Dec 22 > 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | > committer: Josh de Kock > > lavc: add new API for iterating codecs and codec parsers > > Based on an unfinished patch by atomnuker. >>> >>> This commit also breaks >>> >>> ./configure --enable-libsoxr && make -j12 fate-checkasm >>> make -j12 fate-checkasm >>> ... >>> LD tests/checkasm/checkasm >>> libswresample/libswresample.a(soxr_resample.o): In function >>> `get_out_samples': >>> ffmpeg/libswresample/soxr_resample.c:118: undefined reference to >>> `soxr_delay' >>> libswresample/libswresample.a(soxr_resample.o): In function `get_delay': >>> ffmpeg/libswresample/soxr_resample.c:100: undefined reference to >>> `soxr_delay' >>> libswresample/libswresample.a(soxr_resample.o): In function `flush': >>> ffmpeg/libswresample/soxr_resample.c:70: undefined reference to `soxr_delay' >>> ffmpeg/libswresample/soxr_resample.c:72: undefined reference to >>> `soxr_process' >>> ffmpeg/libswresample/soxr_resample.c:77: undefined reference to >>> `soxr_process' >>> ffmpeg/libswresample/soxr_resample.c:78: undefined reference to `soxr_delay' >>> libswresample/libswresample.a(soxr_resample.o): In function `process': >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to >>> `soxr_set_num_channels' >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to >>> `soxr_set_error' >>> ffmpeg/libswresample/soxr_resample.c:90: undefined reference to >>> `soxr_process' >>> libswresample/libswresample.a(soxr_resample.o): In function `destroy': >>> ffmpeg/libswresample/soxr_resample.c:65: undefined reference to >>> `soxr_delete' >>> libswresample/libswresample.a(soxr_resample.o): In function `create': >>> ffmpeg/libswresample/soxr_resample.c:46: undefined reference to >>> `soxr_io_spec' >>> ffmpeg/libswresample/soxr_resample.c:48: undefined reference to >>> `soxr_quality_spec' >>> ffmpeg/libswresample/soxr_resample.c:56: undefined reference to >>> `soxr_delete' >>> ffmpeg/libswresample/soxr_resample.c:57: undefined reference to >>> `soxr_create' >>> collect2: error: ld returned 1 exit status >>> make: *** [tests/checkasm/checkasm] Error 1 >> >> Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1 >> >> Thank's. > > This is not a proper solution. swr is pulled by avcodec only if Opus > decoder is enabled. There's no reason to hardcode it for checkasm otherwise. > The problem here is that the Makefile should pull all the dependencies > of its hardcoded dependencies. This is what FFLIBS and FFEXTRALIBS do in > common.mak to link the actual libraries. Probably, this is not a proper solution, but it is trivial enough. (I'm sorry that I pushed it without posting). So, please fix it with the proper solution. Probably, by adding swresample-extralibs to avcodec-extralibs when avcodec has dependency to swresample. I don't know how to do it. > > That said, was this really a regression generated by this commit? It > looks unrelated. Actually, it was a bug even before this commit. Just, previously it was hidden because linker was smart enough to discard unneeded dependency. But now when the list is changed to array, the linker is unable to do it. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
On 2/9/2018 12:21 PM, Muhammad Faiz wrote: > On Fri, Feb 9, 2018 at 6:53 PM, James Almer wrote: >> On 2/9/2018 7:56 AM, Muhammad Faiz wrote: >>> On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer >>> wrote: On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote: > Josh de Kock (2018-02-06): >> ffmpeg | branch: master | Josh de Kock | Fri Dec 22 >> 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | >> committer: Josh de Kock >> >> lavc: add new API for iterating codecs and codec parsers >> >> Based on an unfinished patch by atomnuker. This commit also breaks ./configure --enable-libsoxr && make -j12 fate-checkasm make -j12 fate-checkasm ... LD tests/checkasm/checkasm libswresample/libswresample.a(soxr_resample.o): In function `get_out_samples': ffmpeg/libswresample/soxr_resample.c:118: undefined reference to `soxr_delay' libswresample/libswresample.a(soxr_resample.o): In function `get_delay': ffmpeg/libswresample/soxr_resample.c:100: undefined reference to `soxr_delay' libswresample/libswresample.a(soxr_resample.o): In function `flush': ffmpeg/libswresample/soxr_resample.c:70: undefined reference to `soxr_delay' ffmpeg/libswresample/soxr_resample.c:72: undefined reference to `soxr_process' ffmpeg/libswresample/soxr_resample.c:77: undefined reference to `soxr_process' ffmpeg/libswresample/soxr_resample.c:78: undefined reference to `soxr_delay' libswresample/libswresample.a(soxr_resample.o): In function `process': ffmpeg/libswresample/soxr_resample.c:88: undefined reference to `soxr_set_num_channels' ffmpeg/libswresample/soxr_resample.c:88: undefined reference to `soxr_set_error' ffmpeg/libswresample/soxr_resample.c:90: undefined reference to `soxr_process' libswresample/libswresample.a(soxr_resample.o): In function `destroy': ffmpeg/libswresample/soxr_resample.c:65: undefined reference to `soxr_delete' libswresample/libswresample.a(soxr_resample.o): In function `create': ffmpeg/libswresample/soxr_resample.c:46: undefined reference to `soxr_io_spec' ffmpeg/libswresample/soxr_resample.c:48: undefined reference to `soxr_quality_spec' ffmpeg/libswresample/soxr_resample.c:56: undefined reference to `soxr_delete' ffmpeg/libswresample/soxr_resample.c:57: undefined reference to `soxr_create' collect2: error: ld returned 1 exit status make: *** [tests/checkasm/checkasm] Error 1 >>> >>> Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1 >>> >>> Thank's. >> >> This is not a proper solution. swr is pulled by avcodec only if Opus >> decoder is enabled. There's no reason to hardcode it for checkasm otherwise. >> The problem here is that the Makefile should pull all the dependencies >> of its hardcoded dependencies. This is what FFLIBS and FFEXTRALIBS do in >> common.mak to link the actual libraries. > > Probably, this is not a proper solution, but it is trivial enough. > (I'm sorry that I pushed it without posting). It's a trivial change that does the job of fixing the regression, so it's fine. > So, please fix it with the proper solution. Probably, by adding > swresample-extralibs to avcodec-extralibs when avcodec has dependency > to swresample. I don't know how to do it. I guess the best way is with Makefile magic, like i mentioned FFLIBS and FFXEXTRALIBS do for each library. I'll take a look at it later. > >> >> That said, was this really a regression generated by this commit? It >> looks unrelated. > > Actually, it was a bug even before this commit. Just, previously it > was hidden because linker was smart enough to discard unneeded > dependency. But now when the list is changed to array, the linker is > unable to do it. > > Thank's. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/format: temporarily use old next api
On Fri, Feb 9, 2018 at 7:04 PM, James Almer wrote:
> On 2/9/2018 7:16 AM, Muhammad Faiz wrote:
>> Should fix
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225066.html
>>
>> Signed-off-by: Muhammad Faiz
>> ---
>> The actual problem is that av*next() and av*iterate() have different
>> semantics:
>> - av*next() iterate all formats+devices
>> - av*iterate() iterate formats only.
>> Is this the intended behaviour?
>>
>> libavformat/format.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/format.c b/libavformat/format.c
>> index b8c5a90a92..75951938cf 100644
>> --- a/libavformat/format.c
>> +++ b/libavformat/format.c
>> @@ -52,7 +52,9 @@ AVOutputFormat *av_guess_format(const char *short_name,
>> const char *filename,
>> const char *mime_type)
>> {
>> AVOutputFormat *fmt = NULL, *fmt_found;
>> +#if !FF_API_NEXT
>> void *i = 0;
>> +#endif
>> int score_max, score;
>>
>> /* specific test for image sequences */
>> @@ -66,7 +68,13 @@ AVOutputFormat *av_guess_format(const char *short_name,
>> const char *filename,
>> /* Find the proper file type. */
>> fmt_found = NULL;
>> score_max = 0;
>> -while ((fmt = av_muxer_iterate(&i))) {
>> +#if FF_API_NEXT
>> +FF_DISABLE_DEPRECATION_WARNINGS
>> +while ((fmt = av_oformat_next(fmt)))
>> +#else
>> +while ((fmt = av_muxer_iterate(&i)))
>> +#endif
>> + {
>> score = 0;
>> if (fmt->name && short_name && av_match_name(short_name, fmt->name))
>> score += 100;
>> @@ -81,6 +89,9 @@ AVOutputFormat *av_guess_format(const char *short_name,
>> const char *filename,
>> fmt_found = fmt;
>> }
>> }
>> +#if FF_API_NEXT
>> +FF_ENABLE_DEPRECATION_WARNINGS
>> +#endif
>> return fmt_found;
>> }
>
> Is your intention to schedule this change to happen once the deprecation
> period ends two years from now, or were you just disabling it for a bit
> until the new API is fixed/finalized?
> If the latter, then please don't add the wrappers. Just replace the
> _iterate() calls.
My intention is the first. With assumption that people agree with
current new API, and
the different semantic between av_iformat/oformat_next (which iterate
formats+devices)
and av_muxer/demuxer_iterate (which iterate formats only) is intended behaviour.
Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
On Fri, Feb 9, 2018 at 6:12 PM, Nicolas George wrote: > Muhammad Faiz (2018-02-08): >> I actually prefer _next() without introducing new API. Yeah, it is >> slower because it must initialize next pointer > > I am not sure what you mean here. The problem with initing the next > pointer was never speed. > > The problem with the next pointer is that it requires a run-time write > in the codec structure, that requires it to be in the data section > instead of the rodata section. This is what I mean "speed" (Don't forget we also need to call ff_thread_once on every _next() call). > > The static init of this pointer, as you proposed, fixes that specific > issue. > > But that is still a linked list. Linked lists are very good when you > need to insert and remove in the list frequently, but for something that > is built once and then static, it has very limited usefulness. I dislike that we introduce new API just because it is "slightly" better than old API. Also, migrating to new API isn't trivial enough (see cmdutils.c problem). > > If the drawback of memory management for solution C (returning the whole > list at once) is considered too bad, then I think solution B is > preferable: more versatile, easier to understand. If we really need to introduce new API, I also choose B. (Unless we have a plan to make the array become linked list again in the future). Actually, I don't care so much about this. I will follow what people agree. > > And by the way, until we decide between solutions A, B, C or anything > else proposed, starting coding would be useless. Just as starting to > pack your bags before deciding whether you go to the sea or mountain. Except for fixing regression. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: Improve the wording of the license failure
On Fri, Feb 9, 2018, at 1:06 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> It was reported on the user mailing list that "libvmaf is version3 and
> --enable-version3 is not specified." is unclear, attached patch tries
> to slightly improve the sentence.
>
> Please comment, Carl Eugen
[...]
A few alternatives to consider:
> die_license_disabled() {
>-enabled $1 || { enabled $v && die "$v is $1 and --enable-$1 is not
>specified."; }
>+enabled $1 || { enabled $v && die "$v requires $1 for license reasons but
>--enable-$1 is not specified."; }
"$v requires --enable-$1."
> die_license_disabled_gpl() {
>-enabled $1 || { enabled $v && die "$v is incompatible with the gpl and
>--enable-$1 is not specified."; }
>+enabled $1 || { enabled $v && die "$v is incompatible with the gpl but
>--enable-$1 is not specified."; }
"$v is incompatible with the GPL. --enable-$1 is required."
or
"$v is incompatible with --enable-gpl. --enable-$1 is required."
or
"$v is incompatible with the GPL. Add --enable-$1 or remove --enable-gpl."
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fix ctts_index calculation
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 5adba52e08..f0bd3e3623 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3148,7 +3148,7 @@ static int find_prev_closest_index(AVStream *st,
> *ctts_index = 0;
> *ctts_sample = 0;
> for (index_ctts_count = 0; index_ctts_count < *index;
> index_ctts_count++) {
> -if (*ctts_index < ctts_count) {
+if (*ctts_index < ctts_count - 1) {
>
If you do this, then we are skipping, looking at ctts_samples in the last
ctts entry where (*ctts_index == ctts_count -1), which is not desired.
(*ctts_sample)++;
> if (ctts_data[*ctts_index].count == *ctts_sample) {
> (*ctts_index)++;
>
Here *ctts_index == ctts_count only iff the *ctts_index is the last CTTS
entry, and we still didn't reach *index. That means that it's file with
CTTS truncated i.e. no corresponding CTTS entries for some STTS entries.
This issue can be fixed by checking for *ctts_index < ctts_count, in the
line after this loop.
while (*index
>= 0 && (*ctts_index
)
>= 0) {
we already check for (*ctts_index) >=0 so we can check for the upper bound
too.
On Sat, Feb 3, 2018 at 12:36 PM, Michael Niedermayer wrote:
> On Fri, Feb 02, 2018 at 05:55:38PM -0800, Xiaohan Wang (王消寒) wrote:
> >
>
> > mov.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 87157b4053de0e044e78db72ef13e8058075c235 0001-Fix-ctts_index-calculatio
> n.patch
> > From bb376fd2de5da5f9ecdef41621a579252b899d7d Mon Sep 17 00:00:00 2001
> > From: Xiaohan Wang
> > Date: Fri, 2 Feb 2018 17:33:56 -0800
> > Subject: [PATCH] Fix ctts_index calculation
> >
> > An index should never be equal to the count. Hence we must make sure
> > *ctts_index < ctts_count.
> > ---
> > libavformat/mov.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> should be reviewed by sasi idealy, he wrote this
>
> thx
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Democracy is the form of government in which you can choose your dictator
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse ID3 tags between ADTS frames.
I just wanted to send a final ping about this patch. While most streams will not encounter the case that it addresses, those that do will have a pretty bad experience. The demuxer's read_packet function currently only reads 7 bytes (ADTS_HEADER_SIZE) of input. If the first 12 bits aren't the sync word, it immediately gives up and returns AVERROR_INVALIDDATA. This means that if it encounters an ID3 tag, it won't re-sync unless the tag length just happens to be a multiple of 7 bytes. I'm assuming that the demuxer should be enhanced to search input for the next sync word. (That might be some of the additional work that James mentioned, and is something I'd be interested in working on.) In the mean time, I think this patch addresses a likely case of lost synchronization, while also providing some utility to API users. I know that people are probably busy, so I don't want to be annoying or overly persistent. However, if anyone has a little time to review this and provide feedback or accept the changes, I'd appreciate it. Thanks, -Richard On Wed, Feb 7, 2018 at 9:40 AM, Richard Shaffer wrote: > I did send the sample file and a unit test for this. If there are no > issues or other comments, would you guys be willing to merge it? > > -Richard > > On Fri, Feb 2, 2018 at 11:15 AM, Richard Shaffer wrote: >> On Fri, Feb 2, 2018 at 5:52 AM, James Almer wrote: >>> On 2/1/2018 11:37 PM, rshaf...@tunein.com wrote: From: Richard Shaffer While rare, ID3 tags may be inserted between ADTS frames. This change enables parsing them and setting the appropriate metadata updated event flag. --- I have encountered a streaming provider that I must support which does this. There are indications that it isn't totally off the wall, and that it does happen in the wild: * https://www.w3.org/TR/mse-byte-stream-format-mpeg-audio/ (See specifically sections 3 and 4.) * https://github.com/video-dev/hls.js/issues/508 That being said, the providers that do this are in the minority. It seems most streaming providers will do one of the following: 1. If using .aac segments inside of HLS, use the #EXTINF for text metadata and use an ID3 tag at the head of the segment for things like timing metadata. 2. If streaming raw AAC over HTTP, use Icy metadata. Aside from comments on the code, I'd be interested in any opinion about whether this is something that should or should not be supported in libavformat. Thanks, -Richard >>> >>> Can you provide a sample and add a fate test for this? To avoid >>> regressions in the future. This demuxer still needs some work. >>> >>> Use the new probetags() function you added in your other id3v2 test if >>> the tags between samples in the file are the only ones, or if they >>> differ in some way from the ones at the beginning of the file, so >>> ffprobe will report them instead. >>> Alternatively, see fate-adts-demux in tests/fate/demux.mak >> >> Oh, somebody did merge that test. How cool. >> >> I don't think we can test this with ffprobe, though. It will just read >> tags at the head of the file and not in the middle. >> >> I have at least one sample that's ok for me to share. I'll work on a >> separate patch to add a fate test. >> >> -Richard >> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec
On Mon, Feb 05, 2018 at 12:27:20AM +0100, Michael Niedermayer wrote: > On Sun, Feb 04, 2018 at 04:07:26PM +0100, Aurelien Jacobs wrote: > > On Sat, Jan 20, 2018 at 11:20:22PM +, Rostislav Pehlivanov wrote: > > > On 20 January 2018 at 17:26, Aurelien Jacobs wrote: > > > > > > > On Sun, Jan 14, 2018 at 10:54:34PM +0100, Carl Eugen Hoyos wrote: > > > > > 2018-01-14 14:06 GMT+01:00 Aurelien Jacobs : > > > > > > > > > > > Well, here is an updated patch which uses codec tags for the decoder > > > > and > > > > > > profile for the encoder. > > > > > > > > > > Sorry but I object to this patch: > > > > > We should not invent codec_tags. > > > > > > > > OK, I understand, and I agree. > > > > > > > > But now we are in an interlocking situation. > > > > We have 2 solutions to handle aptX vs. aptX HD but those 2 solutions > > > > have > > > > been rejected by 2 different person. > > > > > > > > Do anybody have a 3rd solution, that everyone would accept ? > > > > > > > > And if not, how do we resolve this ? > > > > Is there any policy nowadays to handle this kind of interlocking ? > > > > > > > > > > Fine, I see no choice but to use multiple codec IDs for aptxhd since the > > > format really provides you with nothing bitstream wise to determine what > > > it > > > is. Even game codecs have a bit or two for version. > > > > OK. Good. > > > Now, will someone push the original patchset ? > > I think you should be able to push it yourself if there are no review > comments remaining > you are listed in MAINTAINERS for some parts and i see a "ajacobs" for ffmpeg > so you should have git write access OK. Well I digged out my ssh key from old laptop, an I pushed it myself. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse ID3 tags between ADTS frames.
On Fri, 9 Feb 2018 12:54:29 -0800 Richard Shaffer wrote: > I just wanted to send a final ping about this patch. While most > streams will not encounter the case that it addresses, those that do > will have a pretty bad experience. The demuxer's read_packet function > currently only reads 7 bytes (ADTS_HEADER_SIZE) of input. If the first > 12 bits aren't the sync word, it immediately gives up and returns > AVERROR_INVALIDDATA. This means that if it encounters an ID3 tag, it > won't re-sync unless the tag length just happens to be a multiple of 7 > bytes. > > I'm assuming that the demuxer should be enhanced to search input for > the next sync word. (That might be some of the additional work that > James mentioned, and is something I'd be interested in working on.) In > the mean time, I think this patch addresses a likely case of lost > synchronization, while also providing some utility to API users. > > I know that people are probably busy, so I don't want to be annoying > or overly persistent. However, if anyone has a little time to review > this and provide feedback or accept the changes, I'd appreciate it. I think I forgot about this patch. I can apply it on Monday or so, unless someone else has comments. James Almer wanted a test - what's the status on this and does anyone demand that this is pushed only with such a test added? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/utvideodec: Add several out of array read related checks
Fixes: OV_decode_plane.avi
Found-by: GwanYeong Kim
Signed-off-by: Michael Niedermayer
---
libavcodec/utvideodec.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index 1bcd14e74c..f0be2b231b 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -268,8 +268,12 @@ static int decode_plane(UtvideoContext *c, int plane_no,
send = (height * (slice + 1) / c->slices) & cmask;
dest = dst + sstart * stride;
+if (3 * ((dst + send * stride - dest + 7)/8) >
get_bits_left(&cbit))
+return AVERROR_INVALIDDATA;
+
for (p = dest; p < dst + send * stride; p += 8) {
-int bits = get_bits_le(&cbit, 3);
+int bits;
+bits = get_bits_le(&cbit, 3);
if (bits == 0) {
*(uint64_t *) p = 0;
@@ -277,6 +281,9 @@ static int decode_plane(UtvideoContext *c, int plane_no,
uint32_t sub = 0x80 >> (8 - (bits + 1)), add;
int k;
+if ((bits + 1) * 8 > get_bits_left(&pbit))
+return AVERROR_INVALIDDATA;
+
for (k = 0; k < 8; k++) {
p[k] = get_bits_le(&pbit, bits + 1);
@@ -639,9 +646,9 @@ static int decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
for (j = 0; j < c->slices; j++) {
c->packed_stream[i][j] = packed_stream;
c->packed_stream_size[i][j] = bytestream2_get_le32(&pb);
-left -= c->packed_stream_size[i][j];
-if (left < 0)
+if (c->packed_stream_size[i][j] > left)
return AVERROR_INVALIDDATA;
+left -= c->packed_stream_size[i][j];
packed_stream += c->packed_stream_size[i][j];
}
}
@@ -652,9 +659,9 @@ static int decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
for (j = 0; j < c->slices; j++) {
c->control_stream[i][j] = control_stream;
c->control_stream_size[i][j] = bytestream2_get_le32(&pb);
-left -= c->control_stream_size[i][j];
-if (left < 0)
+if (c->control_stream_size[i][j] > left)
return AVERROR_INVALIDDATA;
+left -= c->control_stream_size[i][j];
control_stream += c->control_stream_size[i][j];
}
}
--
2.16.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/mpeg4videodec: Ignore multiple VOL headers
Fixes: Ticket7005
Signed-off-by: Michael Niedermayer
---
libavcodec/mpeg4videodec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 756753e2fc..19210d97fe 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2707,8 +2707,8 @@ int ff_mpeg4_decode_picture_header(Mpeg4DecContext *ctx,
GetBitContext *gb)
if (startcode >= 0x120 && startcode <= 0x12F) {
if (vol) {
-av_log(s->avctx, AV_LOG_ERROR, "Multiple VOL headers");
-return AVERROR_INVALIDDATA;
+av_log(s->avctx, AV_LOG_WARNING, "Ignoring multiple VOL
headers\n");
+continue;
}
vol++;
if ((ret = decode_vol_header(ctx, gb)) < 0)
--
2.16.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: add myself for aptx.c
--- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index ba7a7284eb..b691bd56ec 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -139,6 +139,7 @@ Codecs: aacenc*, aaccoder.c Rostislav Pehlivanov alacenc.c Jaikrishnan Menon alsdec.c Thilo Borgmann, Umair Khan + aptx.cAurelien Jacobs ass* Aurelien Jacobs asv* Michael Niedermayer atrac3plus* Maxim Poliakovski -- 2.16.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse ID3 tags between ADTS frames.
On Fri, Feb 9, 2018 at 1:21 PM, wm4 wrote: > On Fri, 9 Feb 2018 12:54:29 -0800 > Richard Shaffer wrote: > >> I just wanted to send a final ping about this patch. While most >> streams will not encounter the case that it addresses, those that do >> will have a pretty bad experience. The demuxer's read_packet function >> currently only reads 7 bytes (ADTS_HEADER_SIZE) of input. If the first >> 12 bits aren't the sync word, it immediately gives up and returns >> AVERROR_INVALIDDATA. This means that if it encounters an ID3 tag, it >> won't re-sync unless the tag length just happens to be a multiple of 7 >> bytes. >> >> I'm assuming that the demuxer should be enhanced to search input for >> the next sync word. (That might be some of the additional work that >> James mentioned, and is something I'd be interested in working on.) In >> the mean time, I think this patch addresses a likely case of lost >> synchronization, while also providing some utility to API users. >> >> I know that people are probably busy, so I don't want to be annoying >> or overly persistent. However, if anyone has a little time to review >> this and provide feedback or accept the changes, I'd appreciate it. > > I think I forgot about this patch. I can apply it on Monday or so, > unless someone else has comments. James Almer wanted a test - what's > the status on this and does anyone demand that this is pushed only with > such a test added? I was also able to provide a patch and sample file to add a fate test. Patch: https://patchwork.ffmpeg.org/patch/7504/ Sample: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224906.html I think I sent that out late on a Saturday, so it probably got overlooked in the shuffle. -Richard > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fix ctts_index calculation
I uploaded a new patch. Is this what you meant?
I am confused with the code though. In the case *ctts_index == ctts_count,
this while loop will do nothing. Is this what we want? Also, the "wrong"
|ctts_index| will be available outside of this function. How do we make
sure it won't cause trouble later?
On Fri, Feb 9, 2018 at 12:26 PM, Sasi Inguva wrote:
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 5adba52e08..f0bd3e3623 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -3148,7 +3148,7 @@ static int find_prev_closest_index(AVStream *st,
> > *ctts_index = 0;
> > *ctts_sample = 0;
> > for (index_ctts_count = 0; index_ctts_count < *index;
> > index_ctts_count++) {
> > -if (*ctts_index < ctts_count) {
>
> +if (*ctts_index < ctts_count - 1) {
> >
> If you do this, then we are skipping, looking at ctts_samples in the last
> ctts entry where (*ctts_index == ctts_count -1), which is not desired.
>
> (*ctts_sample)++;
> > if (ctts_data[*ctts_index].count == *ctts_sample) {
> > (*ctts_index)++;
> >
>
> Here *ctts_index == ctts_count only iff the *ctts_index is the last CTTS
> entry, and we still didn't reach *index. That means that it's file with
> CTTS truncated i.e. no corresponding CTTS entries for some STTS entries.
> This issue can be fixed by checking for *ctts_index < ctts_count, in the
> line after this loop.
> while (*index
> party/ffmpeg/next/libavformat/mov.c?l=3123&ct=xref_jump_to_
> def&gsn=index&rcl=184932376>
> >= 0 && (*ctts_index
> party/ffmpeg/next/libavformat/mov.c?l=3124&ct=xref_jump_to_
> def&gsn=ctts_index&rcl=184932376>)
> >= 0) {
> we already check for (*ctts_index) >=0 so we can check for the upper bound
> too.
>
> On Sat, Feb 3, 2018 at 12:36 PM, Michael Niedermayer
> > wrote:
>
> > On Fri, Feb 02, 2018 at 05:55:38PM -0800, Xiaohan Wang (王消寒) wrote:
> > >
> >
> > > mov.c |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > 87157b4053de0e044e78db72ef13e8058075c235
> 0001-Fix-ctts_index-calculatio
> > n.patch
> > > From bb376fd2de5da5f9ecdef41621a579252b899d7d Mon Sep 17 00:00:00 2001
> > > From: Xiaohan Wang
> > > Date: Fri, 2 Feb 2018 17:33:56 -0800
> > > Subject: [PATCH] Fix ctts_index calculation
> > >
> > > An index should never be equal to the count. Hence we must make sure
> > > *ctts_index < ctts_count.
> > > ---
> > > libavformat/mov.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > should be reviewed by sasi idealy, he wrote this
> >
> > thx
> >
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Democracy is the form of government in which you can choose your dictator
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From cedc04aec7703ce63a7e2b78ee394fcb0999b016 Mon Sep 17 00:00:00 2001
From: Xiaohan Wang
Date: Fri, 2 Feb 2018 17:33:56 -0800
Subject: [PATCH] Fix ctts_index calculation
An index should never be equal to the count. Hence we must make sure
*ctts_index < ctts_count.
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5adba52e08..c7f70f141e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3157,7 +3157,7 @@ static int find_prev_closest_index(AVStream *st,
}
}
-while (*index >= 0 && (*ctts_index) >= 0) {
+while (*index >= 0 && (*ctts_index) >= 0 && (*ctts_index) < ctts_count) {
// Find a "key frame" with PTS <= timestamp_pts (So that we can decode B-frames correctly).
// No need to add dts_shift to the timestamp here becase timestamp_pts has already been
// compensated by dts_shift above.
--
2.16.0.rc1.238.g530d649a79-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself for aptx.c
On 9 February 2018 at 21:27, Aurelien Jacobs wrote: > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ba7a7284eb..b691bd56ec 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -139,6 +139,7 @@ Codecs: >aacenc*, aaccoder.c Rostislav Pehlivanov >alacenc.c Jaikrishnan Menon >alsdec.c Thilo Borgmann, Umair Khan > + aptx.cAurelien Jacobs >ass* Aurelien Jacobs >asv* Michael Niedermayer >atrac3plus* Maxim Poliakovski > -- > 2.16.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > LGTM, though try to make sure you sent patches to the ML as well, wouldn't want to accidentally add another codec ID while you're at it ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fix ctts_index calculation
On Fri, Feb 9, 2018 at 1:34 PM, Xiaohan Wang (王消寒)
wrote:
> I uploaded a new patch. Is this what you meant?
>
> I am confused with the code though. In the case *ctts_index == ctts_count,
>
The problem is when *ctts_index == (ctts_count -1) .
if ( (ctts_count- 1) < ctts_count) {
while ( ctts_sample < ctts_data[ctts_count - 1].count ) {
increment(ctts_sample )
}
}
But if you check for (ctts_count - 1) < (ctts_count -1) , the above
iterations won't take place.
> this while loop will do nothing. Is this what we want? Also, the "wrong"
> |ctts_index| will be available outside of this function. How do we make
> sure it won't cause trouble later?
>
> On Fri, Feb 9, 2018 at 12:26 PM, Sasi Inguva org
> > wrote:
>
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index 5adba52e08..f0bd3e3623 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -3148,7 +3148,7 @@ static int find_prev_closest_index(AVStream *st,
> > > *ctts_index = 0;
> > > *ctts_sample = 0;
> > > for (index_ctts_count = 0; index_ctts_count < *index;
> > > index_ctts_count++) {
> > > -if (*ctts_index < ctts_count) {
> >
> > +if (*ctts_index < ctts_count - 1) {
> > >
> > If you do this, then we are skipping, looking at ctts_samples in the last
> > ctts entry where (*ctts_index == ctts_count -1), which is not desired.
> >
> > (*ctts_sample)++;
> > > if (ctts_data[*ctts_index].count == *ctts_sample) {
> > > (*ctts_index)++;
> > >
> >
> > Here *ctts_index == ctts_count only iff the *ctts_index is the last
> CTTS
> > entry, and we still didn't reach *index. That means that it's file with
> > CTTS truncated i.e. no corresponding CTTS entries for some STTS entries.
> > This issue can be fixed by checking for *ctts_index < ctts_count, in
> the
> > line after this loop.
> > while (*index
> > > party/ffmpeg/next/libavformat/mov.c?l=3123&ct=xref_jump_to_
> > def&gsn=index&rcl=184932376>
> > >= 0 && (*ctts_index
> > > party/ffmpeg/next/libavformat/mov.c?l=3124&ct=xref_jump_to_
> > def&gsn=ctts_index&rcl=184932376>)
> > >= 0) {
> > we already check for (*ctts_index) >=0 so we can check for the upper
> bound
> > too.
> >
> > On Sat, Feb 3, 2018 at 12:36 PM, Michael Niedermayer
> > > > wrote:
> >
> > > On Fri, Feb 02, 2018 at 05:55:38PM -0800, Xiaohan Wang (王消寒) wrote:
> > > >
> > >
> > > > mov.c |2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 87157b4053de0e044e78db72ef13e8058075c235
> > 0001-Fix-ctts_index-calculatio
> > > n.patch
> > > > From bb376fd2de5da5f9ecdef41621a579252b899d7d Mon Sep 17 00:00:00
> 2001
> > > > From: Xiaohan Wang
> > > > Date: Fri, 2 Feb 2018 17:33:56 -0800
> > > > Subject: [PATCH] Fix ctts_index calculation
> > > >
> > > > An index should never be equal to the count. Hence we must make sure
> > > > *ctts_index < ctts_count.
> > > > ---
> > > > libavformat/mov.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > should be reviewed by sasi idealy, he wrote this
> > >
> > > thx
> > >
> > >
> > > [...]
> > >
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >
> > > Democracy is the form of government in which you can choose your
> dictator
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples: Don't call deprecated functions which don't do anything
On 09/02/18 01:54, James Almer wrote:
> On 2/8/2018 10:41 PM, Jun Zhao wrote:
>> On 2018/2/8 3:44, Mark Thompson wrote:
>>> ---
>>> doc/examples/avio_dir_cmd.c | 2 --
>>> doc/examples/avio_reading.c | 3 ---
>>> doc/examples/decode_audio.c | 3 ---
>>> doc/examples/decode_video.c | 2 --
>>> doc/examples/demuxing_decoding.c | 3 ---
>>> doc/examples/encode_audio.c | 3 ---
>>> doc/examples/encode_video.c | 2 --
>>> doc/examples/extract_mvs.c | 2 --
>>> doc/examples/filtering_audio.c | 1 -
>>> doc/examples/filtering_video.c | 1 -
>>> doc/examples/http_multiclient.c | 1 -
>>> doc/examples/hw_decode.c | 2 --
>>> doc/examples/metadata.c | 1 -
>>> doc/examples/muxing.c| 3 ---
>>> doc/examples/qsvdec.c| 2 --
>>> doc/examples/remuxing.c | 2 --
>>> doc/examples/transcode_aac.c | 2 --
>>> doc/examples/transcoding.c | 1 -
>>> doc/examples/vaapi_encode.c | 2 --
>>> doc/examples/vaapi_transcode.c | 2 --
>>> 20 files changed, 40 deletions(-)
>>>
>>> diff --git a/doc/examples/avio_dir_cmd.c b/doc/examples/avio_dir_cmd.c
>>> index 50c435cf8f..0722bd9ab1 100644
>>> --- a/doc/examples/avio_dir_cmd.c
>>> +++ b/doc/examples/avio_dir_cmd.c
>>> @@ -143,8 +143,6 @@ int main(int argc, char *argv[])
>>> return 1;
>>> }
>>>
>>> -/* register codecs and formats and other lavf/lavc components*/
>>> -av_register_all();
>>> avformat_network_init();
>>>
>>> op = argv[1];
>>> diff --git a/doc/examples/avio_reading.c b/doc/examples/avio_reading.c
>>> index 7860fd5e2f..cbfeb174b8 100644
>>> --- a/doc/examples/avio_reading.c
>>> +++ b/doc/examples/avio_reading.c
>>> @@ -74,9 +74,6 @@ int main(int argc, char *argv[])
>>> }
>>> input_filename = argv[1];
>>>
>>> -/* register codecs and formats and other lavf/lavc components*/
>>> -av_register_all();
>>> -
>>> /* slurp file content into buffer */
>>> ret = av_file_map(input_filename, &buffer, &buffer_size, 0, NULL);
>>> if (ret < 0)
>>> diff --git a/doc/examples/decode_audio.c b/doc/examples/decode_audio.c
>>> index fb9a9af2f6..19dcafd2c8 100644
>>> --- a/doc/examples/decode_audio.c
>>> +++ b/doc/examples/decode_audio.c
>>> @@ -94,9 +94,6 @@ int main(int argc, char **argv)
>>> filename= argv[1];
>>> outfilename = argv[2];
>>>
>>> -/* register all the codecs */
>>> -avcodec_register_all();
>>> -
>>> pkt = av_packet_alloc();
>>>
>>> /* find the MPEG audio decoder */
>>> diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
>>> index 4377fd49e0..5a9d43f689 100644
>>> --- a/doc/examples/decode_video.c
>>> +++ b/doc/examples/decode_video.c
>>> @@ -101,8 +101,6 @@ int main(int argc, char **argv)
>>> filename= argv[1];
>>> outfilename = argv[2];
>>>
>>> -avcodec_register_all();
>>> -
>>> pkt = av_packet_alloc();
>>> if (!pkt)
>>> exit(1);
>>> diff --git a/doc/examples/demuxing_decoding.c
>>> b/doc/examples/demuxing_decoding.c
>>> index b1a216abb4..69a31a8935 100644
>>> --- a/doc/examples/demuxing_decoding.c
>>> +++ b/doc/examples/demuxing_decoding.c
>>> @@ -252,9 +252,6 @@ int main (int argc, char **argv)
>>> video_dst_filename = argv[2];
>>> audio_dst_filename = argv[3];
>>>
>>> -/* register all formats and codecs */
>>> -av_register_all();
>>> -
>>> /* open input file, and allocate format context */
>>> if (avformat_open_input(&fmt_ctx, src_filename, NULL, NULL) < 0) {
>>> fprintf(stderr, "Could not open source file %s\n", src_filename);
>>> diff --git a/doc/examples/encode_audio.c b/doc/examples/encode_audio.c
>>> index d1ef105d9d..ab3586be7f 100644
>>> --- a/doc/examples/encode_audio.c
>>> +++ b/doc/examples/encode_audio.c
>>> @@ -138,9 +138,6 @@ int main(int argc, char **argv)
>>> }
>>> filename = argv[1];
>>>
>>> -/* register all the codecs */
>>> -avcodec_register_all();
>>> -
>>> /* find the MP2 encoder */
>>> codec = avcodec_find_encoder(AV_CODEC_ID_MP2);
>>> if (!codec) {
>>> diff --git a/doc/examples/encode_video.c b/doc/examples/encode_video.c
>>> index 8cd13219bb..6731b2ad19 100644
>>> --- a/doc/examples/encode_video.c
>>> +++ b/doc/examples/encode_video.c
>>> @@ -84,8 +84,6 @@ int main(int argc, char **argv)
>>> filename = argv[1];
>>> codec_name = argv[2];
>>>
>>> -avcodec_register_all();
>>> -
>>> /* find the mpeg1video encoder */
>>> codec = avcodec_find_encoder_by_name(codec_name);
>>> if (!codec) {
>>> diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
>>> index 7ae934ead3..de31ccd2b9 100644
>>> --- a/doc/examples/extract_mvs.c
>>> +++ b/doc/examples/extract_mvs.c
>>> @@ -129,8 +129,6 @@ int main(int argc, char **argv)
>>> }
>>> src_filename = argv[1];
>>>
>>> -av_register_all();
>>> -
>>> if (avformat_open_input(&fmt_ctx, src_filename, NULL, NULL) < 0) {
>>>
Re: [FFmpeg-devel] Fix ctts_index calculation
The new patch looks good to me.
On Fri, Feb 9, 2018 at 1:34 PM, Xiaohan Wang (王消寒)
wrote:
> I uploaded a new patch. Is this what you meant?
>
> I am confused with the code though. In the case *ctts_index == ctts_count,
> this while loop will do nothing. Is this what we want? Also, the "wrong"
> |ctts_index| will be available outside of this function. How do we make
> sure it won't cause trouble later?
>
> On Fri, Feb 9, 2018 at 12:26 PM, Sasi Inguva org
> > wrote:
>
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index 5adba52e08..f0bd3e3623 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -3148,7 +3148,7 @@ static int find_prev_closest_index(AVStream *st,
> > > *ctts_index = 0;
> > > *ctts_sample = 0;
> > > for (index_ctts_count = 0; index_ctts_count < *index;
> > > index_ctts_count++) {
> > > -if (*ctts_index < ctts_count) {
> >
> > +if (*ctts_index < ctts_count - 1) {
> > >
> > If you do this, then we are skipping, looking at ctts_samples in the last
> > ctts entry where (*ctts_index == ctts_count -1), which is not desired.
> >
> > (*ctts_sample)++;
> > > if (ctts_data[*ctts_index].count == *ctts_sample) {
> > > (*ctts_index)++;
> > >
> >
> > Here *ctts_index == ctts_count only iff the *ctts_index is the last
> CTTS
> > entry, and we still didn't reach *index. That means that it's file with
> > CTTS truncated i.e. no corresponding CTTS entries for some STTS entries.
> > This issue can be fixed by checking for *ctts_index < ctts_count, in
> the
> > line after this loop.
> > while (*index
> > > party/ffmpeg/next/libavformat/mov.c?l=3123&ct=xref_jump_to_
> > def&gsn=index&rcl=184932376>
> > >= 0 && (*ctts_index
> > > party/ffmpeg/next/libavformat/mov.c?l=3124&ct=xref_jump_to_
> > def&gsn=ctts_index&rcl=184932376>)
> > >= 0) {
> > we already check for (*ctts_index) >=0 so we can check for the upper
> bound
> > too.
> >
> > On Sat, Feb 3, 2018 at 12:36 PM, Michael Niedermayer
> > > > wrote:
> >
> > > On Fri, Feb 02, 2018 at 05:55:38PM -0800, Xiaohan Wang (王消寒) wrote:
> > > >
> > >
> > > > mov.c |2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 87157b4053de0e044e78db72ef13e8058075c235
> > 0001-Fix-ctts_index-calculatio
> > > n.patch
> > > > From bb376fd2de5da5f9ecdef41621a579252b899d7d Mon Sep 17 00:00:00
> 2001
> > > > From: Xiaohan Wang
> > > > Date: Fri, 2 Feb 2018 17:33:56 -0800
> > > > Subject: [PATCH] Fix ctts_index calculation
> > > >
> > > > An index should never be equal to the count. Hence we must make sure
> > > > *ctts_index < ctts_count.
> > > > ---
> > > > libavformat/mov.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > should be reviewed by sasi idealy, he wrote this
> > >
> > > thx
> > >
> > >
> > > [...]
> > >
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >
> > > Democracy is the form of government in which you can choose your
> dictator
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg2dec: fix decoding field pictures
On Fri, Feb 09, 2018 at 02:03:24AM +0900, Nekopanda wrote: > - Fix field selection for skipped macroblocks > > For B field pictures, the spec says, > > > The prediction shall be made from the field of the same parity as the field > > being predicted. > > I did it. > > - Fix motion vector rounding for chroma components > > In 16x8 motion compensation, for lower 16x8 region, the input to > mpeg_motion() for motion_y was "motion_y + 16", which causes wrong rounding. > For 4:2:0, chroma scaling for y is dividing by two and rounding toward zero. > When motion_y < 0 and motion_y + 16 > 0, the rounding direction of "motion_y" > and "motion_y + 16" is different and rounding "motion_y + 16" would be > incorrect. > > We should input "motion_y" as is to round correctly. I add "is_16x8" flag to > do that. please split this patch in 2. I think these are 2 independant bugfixes. also please update the fate checksums so make fate does not break after either patch thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/format: temporarily use old next api
On Sat, Feb 10, 2018 at 1:08 AM, Muhammad Faiz wrote:
> On Fri, Feb 9, 2018 at 7:04 PM, James Almer wrote:
>> On 2/9/2018 7:16 AM, Muhammad Faiz wrote:
>>> Should fix
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225066.html
>>>
>>> Signed-off-by: Muhammad Faiz
>>> ---
>>> The actual problem is that av*next() and av*iterate() have different
>>> semantics:
>>> - av*next() iterate all formats+devices
>>> - av*iterate() iterate formats only.
>>> Is this the intended behaviour?
>>>
>>> libavformat/format.c | 13 -
>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/format.c b/libavformat/format.c
>>> index b8c5a90a92..75951938cf 100644
>>> --- a/libavformat/format.c
>>> +++ b/libavformat/format.c
>>> @@ -52,7 +52,9 @@ AVOutputFormat *av_guess_format(const char *short_name,
>>> const char *filename,
>>> const char *mime_type)
>>> {
>>> AVOutputFormat *fmt = NULL, *fmt_found;
>>> +#if !FF_API_NEXT
>>> void *i = 0;
>>> +#endif
>>> int score_max, score;
>>>
>>> /* specific test for image sequences */
>>> @@ -66,7 +68,13 @@ AVOutputFormat *av_guess_format(const char *short_name,
>>> const char *filename,
>>> /* Find the proper file type. */
>>> fmt_found = NULL;
>>> score_max = 0;
>>> -while ((fmt = av_muxer_iterate(&i))) {
>>> +#if FF_API_NEXT
>>> +FF_DISABLE_DEPRECATION_WARNINGS
>>> +while ((fmt = av_oformat_next(fmt)))
>>> +#else
>>> +while ((fmt = av_muxer_iterate(&i)))
>>> +#endif
>>> + {
>>> score = 0;
>>> if (fmt->name && short_name && av_match_name(short_name,
>>> fmt->name))
>>> score += 100;
>>> @@ -81,6 +89,9 @@ AVOutputFormat *av_guess_format(const char *short_name,
>>> const char *filename,
>>> fmt_found = fmt;
>>> }
>>> }
>>> +#if FF_API_NEXT
>>> +FF_ENABLE_DEPRECATION_WARNINGS
>>> +#endif
>>> return fmt_found;
>>> }
>>
>> Is your intention to schedule this change to happen once the deprecation
>> period ends two years from now, or were you just disabling it for a bit
>> until the new API is fixed/finalized?
>> If the latter, then please don't add the wrappers. Just replace the
>> _iterate() calls.
>
> My intention is the first. With assumption that people agree with
> current new API, and
> the different semantic between av_iformat/oformat_next (which iterate
> formats+devices)
> and av_muxer/demuxer_iterate (which iterate formats only) is intended
> behaviour.
>
> Thank's.
Pushed.
Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
On Fri, Feb 09, 2018 at 10:21:04PM +0700, Muhammad Faiz wrote: > On Fri, Feb 9, 2018 at 6:53 PM, James Almer wrote: > > On 2/9/2018 7:56 AM, Muhammad Faiz wrote: > >> On Thu, Feb 8, 2018 at 7:04 AM, Michael Niedermayer > >> wrote: > >>> On Wed, Feb 07, 2018 at 01:52:33PM +0100, Nicolas George wrote: > Josh de Kock (2018-02-06): > > ffmpeg | branch: master | Josh de Kock | Fri Dec 22 > > 22:17:00 2017 +| [7e8eba2d8755962d9dca5eade57bf8f591a73c0c] | > > committer: Josh de Kock > > > > lavc: add new API for iterating codecs and codec parsers > > > > Based on an unfinished patch by atomnuker. > >>> > >>> This commit also breaks > >>> > >>> ./configure --enable-libsoxr && make -j12 fate-checkasm > >>> make -j12 fate-checkasm > >>> ... > >>> LD tests/checkasm/checkasm > >>> libswresample/libswresample.a(soxr_resample.o): In function > >>> `get_out_samples': > >>> ffmpeg/libswresample/soxr_resample.c:118: undefined reference to > >>> `soxr_delay' > >>> libswresample/libswresample.a(soxr_resample.o): In function `get_delay': > >>> ffmpeg/libswresample/soxr_resample.c:100: undefined reference to > >>> `soxr_delay' > >>> libswresample/libswresample.a(soxr_resample.o): In function `flush': > >>> ffmpeg/libswresample/soxr_resample.c:70: undefined reference to > >>> `soxr_delay' > >>> ffmpeg/libswresample/soxr_resample.c:72: undefined reference to > >>> `soxr_process' > >>> ffmpeg/libswresample/soxr_resample.c:77: undefined reference to > >>> `soxr_process' > >>> ffmpeg/libswresample/soxr_resample.c:78: undefined reference to > >>> `soxr_delay' > >>> libswresample/libswresample.a(soxr_resample.o): In function `process': > >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to > >>> `soxr_set_num_channels' > >>> ffmpeg/libswresample/soxr_resample.c:88: undefined reference to > >>> `soxr_set_error' > >>> ffmpeg/libswresample/soxr_resample.c:90: undefined reference to > >>> `soxr_process' > >>> libswresample/libswresample.a(soxr_resample.o): In function `destroy': > >>> ffmpeg/libswresample/soxr_resample.c:65: undefined reference to > >>> `soxr_delete' > >>> libswresample/libswresample.a(soxr_resample.o): In function `create': > >>> ffmpeg/libswresample/soxr_resample.c:46: undefined reference to > >>> `soxr_io_spec' > >>> ffmpeg/libswresample/soxr_resample.c:48: undefined reference to > >>> `soxr_quality_spec' > >>> ffmpeg/libswresample/soxr_resample.c:56: undefined reference to > >>> `soxr_delete' > >>> ffmpeg/libswresample/soxr_resample.c:57: undefined reference to > >>> `soxr_create' > >>> collect2: error: ld returned 1 exit status > >>> make: *** [tests/checkasm/checkasm] Error 1 > >> > >> Fixed in 81d6501be77b273053a66eeced94d78e2021f1d1 > >> > >> Thank's. > > > > This is not a proper solution. swr is pulled by avcodec only if Opus > > decoder is enabled. There's no reason to hardcode it for checkasm otherwise. > > The problem here is that the Makefile should pull all the dependencies > > of its hardcoded dependencies. This is what FFLIBS and FFEXTRALIBS do in > > common.mak to link the actual libraries. > > Probably, this is not a proper solution, but it is trivial enough. > (I'm sorry that I pushed it without posting). > So, please fix it with the proper solution. Probably, by adding > swresample-extralibs to avcodec-extralibs when avcodec has dependency > to swresample. I don't know how to do it. > > > > > That said, was this really a regression generated by this commit? It > > looks unrelated. > > Actually, it was a bug even before this commit. Just, previously it > was hidden because linker was smart enough to discard unneeded > dependency. But now when the list is changed to array, the linker is > unable to do it. iam not sure i understand correctly. But does this mean that tools/target_dec_"codec"_fuzzer will now include everything and not just the "codec" ? If so this will possibly prevent FFmpeg from being tested in googles ossfuzz framework. As their diskspace was already rather tight. i do see on my disk that the more recently build fuzzers have gottem MUCH larger: -rwxr-x--- 1 michael michael 17588987 Feb 3 18:53 tools/target_dec_scpr_fuzzer* -rwxr-x--- 1 michael michael 17476326 Feb 4 02:16 tools/target_dec_paf_video_fuzzer* -rwxr-x--- 1 michael michael 143210465 Feb 9 13:53 tools/target_dec_h264_fuzzer* -rwxr-x--- 1 michael michael 143210465 Feb 9 13:56 tools/target_dec_vp3_fuzzer* [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add aac id3v2 demux test
On Sat, 3 Feb 2018 23:25:56 -0800 Richard Shaffer wrote: > Attaching sample file for the test. > > -Richard > > On Sat, Feb 3, 2018 at 11:24 PM, wrote: > > From: Richard Shaffer > > > > A basic test for demuxing raw AAC (ADTS) with ID3v2 tags. > > --- > > This is related to the patch 'libavformat/aac: Parse ID3 tags between ADTS > > frames', and will fail without it. The test file contains an ID3 tag at the > > beginning as well as a second tag between frames. While the test doesn't > > check > > that the tags' data have been parsed correctly, without the aforementioned > > patch, the demuxing will fail on the second tag and return an invalid data > > error. > > > > The sample will be attached in a separate email. > > > > Thanks, > > > > -Richard > > > > tests/fate/demux.mak| 3 +- > > tests/ref/fate/adts-id3v2-demux | 240 > > > > 2 files changed, 242 insertions(+), 1 deletion(-) > > create mode 100644 tests/ref/fate/adts-id3v2-demux > > > > diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak > > index 9427ac30c8..306904b9de 100644 > > --- a/tests/fate/demux.mak > > +++ b/tests/fate/demux.mak > > @@ -1,9 +1,10 @@ > > FATE_SAMPLES_DEMUX-$(call DEMDEC, AVI, FRAPS) += fate-avio-direct > > fate-avio-direct: CMD = framecrc -avioflags direct -i > > $(TARGET_SAMPLES)/fraps/fraps-v5-bouncing-balls-partial.avi -avioflags > > direct > > > > -FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux > > fate-adts-id3v1-demux > > +FATE_SAMPLES_DEMUX-$(call DEMDEC, AAC, AAC) += fate-adts-demux > > fate-adts-id3v1-demux fate-adts-id3v2-demux > > fate-adts-demux: CMD = crc -i $(TARGET_SAMPLES)/aac/ct_faac-adts.aac -c:a > > copy > > fate-adts-id3v1-demux: CMD = framecrc -f aac -i > > $(TARGET_SAMPLES)/aac/id3v1.aac -c:a copy > > +fate-adts-id3v2-demux: CMD = framecrc -f aac -i > > $(TARGET_SAMPLES)/aac/id3v2.aac -c:a copy > > > > FATE_SAMPLES_DEMUX-$(CONFIG_AEA_DEMUXER) += fate-aea-demux > > fate-aea-demux: CMD = crc -i $(TARGET_SAMPLES)/aea/chirp.aea -c:a copy > > diff --git a/tests/ref/fate/adts-id3v2-demux > > b/tests/ref/fate/adts-id3v2-demux > > new file mode 100644 > > index 00..db00e3b81e > > --- /dev/null > > +++ b/tests/ref/fate/adts-id3v2-demux > > @@ -0,0 +1,240 @@ > > +#tb 0: 1/28224000 > > +#media_type 0: audio > > +#codec_id 0: aac > > +#sample_rate 0: 48000 > > +#channel_layout 0: 4 > > +#channel_layout_name 0: mono > > +0, 0, 0, 602112, 126, 0x639a3a5b > > +0, 602112, 602112, 602112, 135, 0x5b1f3ced > > +0,1204224,1204224, 602112, 123, 0xfcb73863 > > +0,1806336,1806336, 602112, 126, 0x639a3a5b > > +0,2408448,2408448, 602112, 135, 0x5b1f3ced > > +0,3010560,3010560, 602112, 123, 0xfcb73863 > > +0,3612672,3612672, 602112, 144, 0xa0434540 > > +0,4214784,4214784, 602112, 119, 0x45053cc1 > > +0,4816896,4816896, 602112, 111, 0x23043aaf > > +0,5419008,5419008, 602112, 126, 0x693a3a67 > > +0,6021120,6021120, 602112, 149, 0x31304a34 > > +0,6623232,6623232, 602112, 111, 0x21603aab > > +0,7225344,7225344, 602112, 132, 0xe42d43b3 > > +0,7827456,7827456, 602112, 135, 0x5b1f3ced > > +0,8429568,8429568, 602112, 123, 0xfe8b3867 > > +0,9031680,9031680, 602112, 144, 0xa26b4544 > > +0,9633792,9633792, 602112, 129, 0xf7de3bc7 > > +0, 10235904, 10235904, 602112, 111, 0x1fbc3aa7 > > +0, 10838016, 10838016, 602112, 126, 0x657a3a5f > > +0, 11440128, 11440128, 602112, 140, 0xdb6542ec > > +0, 12042240, 12042240, 602112, 123, 0xfcb73863 > > +0, 12644352, 12644352, 602112, 138, 0xad7e44b6 > > +0, 13246464, 13246464, 602112, 119, 0x46c93cc5 > > +0, 13848576, 13848576, 602112, 123, 0xfe8b3867 > > +0, 14450688, 14450688, 602112, 144, 0xa26b4544 > > +0, 15052800, 15052800, 602112, 129, 0xf7de3bc7 > > +0, 15654912, 15654912, 602112, 111, 0x1fbc3aa7 > > +0, 16257024, 16257024, 602112, 126, 0x657a3a5f > > +0, 16859136, 16859136, 602112, 140, 0xdb6542ec > > +0, 17461248, 17461248, 602112, 123, 0xfcb73863 > > +0, 18063360, 18063360, 602112, 138, 0xad7e44b6 > > +0, 18665472, 18665472, 602112, 119, 0x46c93cc5 > > +0, 19267584, 19267584, 602112, 123, 0xfe8b3867 > > +0, 19869696, 19869696, 602112, 144, 0xa26b4544 > > +0, 20471808, 20471808, 602112, 129, 0xf7de3bc7 > > +0, 21073920, 21073920, 602112, 111, 0x1fbc3aa7 > > +0, 21676032, 21676032, 602112, 126, 0x657a3a5f > > +0, 22278144, 22278144, 602112, 140, 0xdb6542ec > > +0, 22880256, 22880256, 602112, 123, 0xfcb73863 > > +0, 23482368, 23482368, 602112, 138, 0xad7e44b6 > > +0, 24084480, 2
[FFmpeg-devel] [PATCH]lavf/rtpdec: Constify several pointers
Hi!
Attached patch fixes two warnings.
libavformat/rtpdec.c: In function ‘ff_rtp_handler_find_by_name’:
libavformat/rtpdec.c:155:20: warning: return discards ‘const’
qualifier from pointer target type [-Wdiscarded-qualifiers]
return handler;
^~~
libavformat/rtpdec.c: In function ‘ff_rtp_handler_find_by_id’:
libavformat/rtpdec.c:168:20: warning: return discards ‘const’
qualifier from pointer target type [-Wdiscarded-qualifiers]
return handler;
^~~
Please comment, Carl Eugen
From b0383afe16c62fcb0fbc7ea49168edd2f26ac0aa Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 10 Feb 2018 02:54:42 +0100
Subject: [PATCH] lavf/rtpdec: Constify several pointers.
Fixes two warnings:
libavformat/rtpdec.c:155:20: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
libavformat/rtpdec.c:168:20: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
---
libavformat/rdt.c|2 +-
libavformat/rdt.h|2 +-
libavformat/rtpdec.c |6 +++---
libavformat/rtpdec.h |6 +++---
libavformat/rtsp.c |8
libavformat/rtsp.h |2 +-
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavformat/rdt.c b/libavformat/rdt.c
index 31a32ff..60c36f0 100644
--- a/libavformat/rdt.c
+++ b/libavformat/rdt.c
@@ -53,7 +53,7 @@ struct RDTDemuxContext {
RDTDemuxContext *
ff_rdt_parse_open(AVFormatContext *ic, int first_stream_of_set_idx,
- void *priv_data, RTPDynamicProtocolHandler *handler)
+ void *priv_data, const RTPDynamicProtocolHandler *handler)
{
RDTDemuxContext *s = av_mallocz(sizeof(RDTDemuxContext));
if (!s)
diff --git a/libavformat/rdt.h b/libavformat/rdt.h
index 2480565..67fb308 100644
--- a/libavformat/rdt.h
+++ b/libavformat/rdt.h
@@ -41,7 +41,7 @@ typedef struct RDTDemuxContext RDTDemuxContext;
RDTDemuxContext *ff_rdt_parse_open(AVFormatContext *ic,
int first_stream_of_set_idx,
void *priv_data,
- RTPDynamicProtocolHandler *handler);
+ const RTPDynamicProtocolHandler *handler);
void ff_rdt_parse_close(RDTDemuxContext *s);
/**
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index 6499e27..e75a34c 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -143,7 +143,7 @@ const RTPDynamicProtocolHandler *ff_rtp_handler_iterate(void **opaque)
return r;
}
-RTPDynamicProtocolHandler *ff_rtp_handler_find_by_name(const char *name,
+const RTPDynamicProtocolHandler *ff_rtp_handler_find_by_name(const char *name,
enum AVMediaType codec_type)
{
void *i = 0;
@@ -157,7 +157,7 @@ RTPDynamicProtocolHandler *ff_rtp_handler_find_by_name(const char *name,
return NULL;
}
-RTPDynamicProtocolHandler *ff_rtp_handler_find_by_id(int id,
+const RTPDynamicProtocolHandler *ff_rtp_handler_find_by_id(int id,
enum AVMediaType codec_type)
{
void *i = 0;
@@ -572,7 +572,7 @@ RTPDemuxContext *ff_rtp_parse_open(AVFormatContext *s1, AVStream *st,
}
void ff_rtp_parse_set_dynamic_protocol(RTPDemuxContext *s, PayloadContext *ctx,
- RTPDynamicProtocolHandler *handler)
+ const RTPDynamicProtocolHandler *handler)
{
s->dynamic_protocol_context = ctx;
s->handler = handler;
diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h
index fe726a6..5a47d6f 100644
--- a/libavformat/rtpdec.h
+++ b/libavformat/rtpdec.h
@@ -43,7 +43,7 @@ typedef struct RTPDemuxContext RTPDemuxContext;
RTPDemuxContext *ff_rtp_parse_open(AVFormatContext *s1, AVStream *st,
int payload_type, int queue_size);
void ff_rtp_parse_set_dynamic_protocol(RTPDemuxContext *s, PayloadContext *ctx,
- RTPDynamicProtocolHandler *handler);
+ const RTPDynamicProtocolHandler *handler);
void ff_rtp_parse_set_crypto(RTPDemuxContext *s, const char *suite,
const char *params);
int ff_rtp_parse_packet(RTPDemuxContext *s, AVPacket *pkt,
@@ -208,7 +208,7 @@ const RTPDynamicProtocolHandler *ff_rtp_handler_iterate(void **opaque);
* @param name name of the requested rtp dynamic protocol handler
* @return A rtp dynamic protocol handler if one was found, NULL otherwise.
*/
-RTPDynamicProtocolHandler *ff_rtp_handler_find_by_name(const char *name,
+const RTPDynamicProtocolHandler *ff_rtp_handler_find_by_name(const char *name,
enum AVMediaType codec_type);
/**
* Find a registered rtp dynamic protocol handler with a matching codec ID.
@@ -216,7 +216,7 @@ RTPDynamicProtocolHandler *ff_
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself for aptx.c
On Fri, Feb 09, 2018 at 10:27:39PM +0100, Aurelien Jacobs wrote: > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ba7a7284eb..b691bd56ec 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -139,6 +139,7 @@ Codecs: >aacenc*, aaccoder.c Rostislav Pehlivanov >alacenc.c Jaikrishnan Menon >alsdec.c Thilo Borgmann, Umair Khan > + aptx.cAurelien Jacobs >ass* Aurelien Jacobs >asv* Michael Niedermayer >atrac3plus* Maxim Poliakovski > -- LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fix ctts_index calculation
On Fri, Feb 09, 2018 at 02:51:25PM -0800, Sasi Inguva wrote: > The new patch looks good to me. 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 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
