[FFmpeg-devel] Interested in GSOC 2020
Hi, I am a 3rd Year Computer Science Student Currently Studying at Medi-Caps University, Indore. I want to make a contribution to FFmpeg Project in GSOC 2020. For Gsoc 2020 I interested in Fuzzing FATE tests in libavformat, libavutil and libswscale. I have one minor documentation bug fixed. And I also worked with git in the past. Can I ask my query here or I can only ask in IRC. Regards Sourabh Sharma ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] GSOC Project 2020
Hello, I am Ibrahim Anis CSE final year undergraduate student pursuing B.Tech from Govt. College Ujjain.I am looking forward to participating GSOC 2020 and contribute to ffmpeg community. I am interested in working on the project 'Improvig color constancy video filter'.I have knowledge of c programming language and I have worked on machine learning.I think this suites me to work on this project. I am a newbie here,so I don't know how should I start.I will really appreciate it if you could guide me. Regards, Ibrahim anis ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.
On Fri, Feb 21, 2020 at 5:17 PM Mohammad Izadi wrote: > Why does the struct belong to lavu? This struct is super similar to structs > in libavcodec/hevc_sei.h. We just move it to a new file to share it between > hevc and vp9 encoder/decoder. > > -- > 1. Please kindly stop top posting: http://www.idallen.com/topposting.html 2. It belongs to lavu because it's where the frame code generically code is. I'm not familiar with this API too much, but from what i gather users may need to have a way of accessing this data without pulling in all the dependencies of lavc or lavf. Vittorio On Fri, Feb 21, 2020 at 2:03 PM Hendrik Leppkes wrote: > > > On Fri, Feb 21, 2020 at 7:08 PM Mohammad Izadi > > wrote: > > > > > > If you believe lavc is at the top of the hierarchy, I can simply move > the > > > file to lavc. Then both lavc and lavf can use it and hierarchy is > > > respected. Can I do that? Doesn't break API? Any objection (with > > solution)? > > > Let's make right decisions to speed up the process please :). > > > -- > > > > > > The struct itself belongs in lavu with everything else of AVFrame. The > > parsing of the mpeg-specific SEI data belongs in avcodec. You can't > > just blindly move everything. > > > > - Hendrik > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.
Why does the struct belong to lavu? This struct is super similar to structs in libavcodec/hevc_sei.h. We just move it to a new file to share it between hevc and vp9 encoder/decoder. -- Best, Mohammad On Fri, Feb 21, 2020 at 2:03 PM Hendrik Leppkes wrote: > On Fri, Feb 21, 2020 at 7:08 PM Mohammad Izadi > wrote: > > > > If you believe lavc is at the top of the hierarchy, I can simply move the > > file to lavc. Then both lavc and lavf can use it and hierarchy is > > respected. Can I do that? Doesn't break API? Any objection (with > solution)? > > Let's make right decisions to speed up the process please :). > > -- > > > The struct itself belongs in lavu with everything else of AVFrame. The > parsing of the mpeg-specific SEI data belongs in avcodec. You can't > just blindly move everything. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2020
On Fri, Feb 21, 2020 at 04:41:35PM -0300, Pedro Arthur wrote: > Hi, > > Em qui., 6 de fev. de 2020 às 19:59, Michael Niedermayer > escreveu: > > > > Hi all > > > > please help fill the 2020 GSoC Ideas page > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020 > > It seems the 2020 results page [1] contains results from 2019. > > [1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results you mean the sample project ? feel free to edit it to look nicer otherwise ill wait for thilo, who added this to reply Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.
On Fri, Feb 21, 2020 at 7:08 PM Mohammad Izadi wrote: > > If you believe lavc is at the top of the hierarchy, I can simply move the > file to lavc. Then both lavc and lavf can use it and hierarchy is > respected. Can I do that? Doesn't break API? Any objection (with solution)? > Let's make right decisions to speed up the process please :). > -- The struct itself belongs in lavu with everything else of AVFrame. The parsing of the mpeg-specific SEI data belongs in avcodec. You can't just blindly move everything. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/ac3_parser: recognize LE bitstream variant
Signed-off-by: Paul B Mahol
---
libavcodec/ac3_parser.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 1e203ae6ac..ba171653ef 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -201,6 +201,12 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext
*hdr_info,
AC3HeaderInfo hdr;
GetBitContext gbc;
+if (tmp.u8[1] == 0x77 && tmp.u8[2] == 0x0b) {
+FFSWAP(uint8_t, tmp.u8[1], tmp.u8[2]);
+FFSWAP(uint8_t, tmp.u8[3], tmp.u8[4]);
+FFSWAP(uint8_t, tmp.u8[5], tmp.u8[6]);
+}
+
init_get_bits(, tmp.u8+8-AC3_HEADER_SIZE, 54);
err = ff_ac3_parse_header(, );
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.
On Fri, Feb 21, 2020 at 12:54 PM Dale Curtis
wrote:
> On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> I doubt that this patch still applies as-is because of
>> e2307f4ff197646a7feee0edbcdd2d3262932676.
>>
>>
> Ah, good point. Rebased and attached.
>
Whoops, attached the wrong file.
- dale
From f9f2b953a1e71e439a88581894715568987cba5c Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 21 Feb 2020 12:53:30 -0800
Subject: [PATCH] Don't trigger errors for multiple id3 tags.
Such errors may make sense for specific formats, but general parsing
logic shouldn't be treating these as errors regardless of the error
recognition mode.
Fixes loading of the following wave when using -err_detect explode:
https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav
Signed-off-by: Dale Curtis
---
libavformat/utils.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 123d67800b..cb15f6a4b3 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -635,15 +635,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
s->metadata = s->internal->id3v2_meta;
s->internal->id3v2_meta = NULL;
} else if (s->internal->id3v2_meta) {
-int level = AV_LOG_WARNING;
-if (s->error_recognition & AV_EF_COMPLIANT)
-level = AV_LOG_ERROR;
-av_log(s, level, "Discarding ID3 tags because more suitable tags were found.\n");
+av_log(s, AV_LOG_WARNING, "Discarding ID3 tags because more suitable tags were found.\n");
av_dict_free(>internal->id3v2_meta);
-if (s->error_recognition & AV_EF_EXPLODE) {
-ret = AVERROR_INVALIDDATA;
-goto close;
-}
}
if (id3v2_extra_meta) {
--
2.25.0.265.gbab2e86ba0-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.
On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> I doubt that this patch still applies as-is because of
> e2307f4ff197646a7feee0edbcdd2d3262932676.
>
>
Ah, good point. Rebased and attached.
- dale
From 57f732774528eecb837467919ec9a284e95470dc Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 21 Feb 2020 12:53:30 -0800
Subject: [PATCH] Don't trigger errors for multiple id3 tags.
Such errors may make sense for specific formats, but general parsing
logic shouldn't be treating these as errors regardless of the error
recognition mode.
Fixes loading of the following wave when using -err_detect explode:
https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav
Signed-off-by: Dale Curtis
---
libavformat/utils.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 123d67800b..72cbfa1690 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -635,15 +635,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
s->metadata = s->internal->id3v2_meta;
s->internal->id3v2_meta = NULL;
} else if (s->internal->id3v2_meta) {
-int level = AV_LOG_WARNING;
-if (s->error_recognition & AV_EF_COMPLIANT)
-level = AV_LOG_ERROR;
av_log(s, level, "Discarding ID3 tags because more suitable tags were found.\n");
av_dict_free(>internal->id3v2_meta);
-if (s->error_recognition & AV_EF_EXPLODE) {
-ret = AVERROR_INVALIDDATA;
-goto close;
-}
}
if (id3v2_extra_meta) {
--
2.25.0.265.gbab2e86ba0-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Followup: FOSDEM meeting
Hi all, Firstly, I want to thank j-b for his organisation of the meeting at FOSDEM, I think the meeting itself was productive and the outcome was good. Unfortunately, there is one issue: So far no one has shared a copy of the notes or a picture of the blackboard after the meeting. I was silly to assuming that someone else had recorded it and not taking a photo was my mistake. Did anyone keep a note of the results of the meeting at FOSDEM (or can at least recall them, my memory is not so good)? If not, this makes it difficult to begin the process of enacting the various votes which were discussed. I will make sure to take notes in any future meetings. I think that this is the best way to ensure that it properly gets done by holding myself, rather than others, accountable. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/startcode: Use AV_RN due to UBSan warning about unaligned access
On Wed, Jan 22, 2020 at 04:25:40PM +0100, Andreas Rheinhardt wrote: > On Wed, Jan 22, 2020 at 4:23 PM Carl Eugen Hoyos wrote: > > > Am Mi., 22. Jan. 2020 um 16:21 Uhr schrieb Andreas Rheinhardt > > : > > > > > > On Wed, Jan 22, 2020 at 4:06 PM Carl Eugen Hoyos > > wrote: > > > > > > > Am Mi., 22. Jan. 2020 um 15:57 Uhr schrieb Andreas Rheinhardt > > > > : > > > > > > > > > > when directly accessing a buffer via a pointer to uint8_t cast to a > > > > > pointer to uint64_t/uint32_t. This happened only if > > HAVE_FAST_UNALIGNED > > > > > was set, so it was ok, but UBSan nevertheless complained about > > unaligned > > > > > accesses. So simply use AV_RNxx to read the buffer; this also > > improves > > > > > readability. > > > > > > > > Is there a speed impact? > > > > > > > The assembly produced by both Clang as well as GCC was completely > > > unchanged (for non-UBSan builds). > > > > (on x86?) > > > > Yes: x86-64. are any other architectures affected or is it the same for all major ones? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cdtoons: Fix off by 4 check on diff_size
On Thu, Feb 20, 2020 at 11:29:51PM +0100, Paul B Mahol wrote: > On 2/20/20, Michael Niedermayer wrote: > > On Thu, Feb 20, 2020 at 08:11:34PM +0100, Paul B Mahol wrote: > >> Are you sure this is correct? > >> Does asan reports exactly overread by 4? > > > > the next line passes diff_size - 8 as a unsigned data size > > if diff_size is smaller than 8, diff_size - 8 is very big and > > the overread checks which use that will misbehave > > > > OK then. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cdtoons: Correct several end of data checks in cdtoons_render_sprite()
On Thu, Feb 20, 2020 at 11:32:08PM +0100, Paul B Mahol wrote: > LGTM will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/pcm: Fix invalid shift in AV_CODEC_ID_PCM_LXF
On Fri, Feb 21, 2020 at 12:42:07PM +0100, Paul B Mahol wrote: > probably ok will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2020
Hi, Em qui., 6 de fev. de 2020 às 19:59, Michael Niedermayer escreveu: > > Hi all > > please help fill the 2020 GSoC Ideas page > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020 It seems the 2020 results page [1] contains results from 2019. [1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results > > (This page is key to being acccepted to GSoC) > > Thank you > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When the tyrant has disposed of foreign enemies by conquest or treaty, and > there is nothing more to fear from them, then he is always stirring up > some war or other, in order that the people may require a leader. -- Plato > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.
Dale Curtis: > +John Rummell just noticed this patch never landed > upstream. Can this be landed? > > - dale > > On Thu, Feb 28, 2019 at 1:58 PM Dale Curtis wrote: > >> Such errors may make sense for specific formats, but general parsing >> logic shouldn't be treating these as errors regardless of the error >> recognition mode. >> >> Fixes loading of the following wave when using -err_detect explode: >> >> https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav >> >> Signed-off-by: Dale Curtis >> I doubt that this patch still applies as-is because of e2307f4ff197646a7feee0edbcdd2d3262932676. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.
+John Rummell just noticed this patch never landed upstream. Can this be landed? - dale On Thu, Feb 28, 2019 at 1:58 PM Dale Curtis wrote: > Such errors may make sense for specific formats, but general parsing > logic shouldn't be treating these as errors regardless of the error > recognition mode. > > Fixes loading of the following wave when using -err_detect explode: > > https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav > > Signed-off-by: Dale Curtis > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.
If you believe lavc is at the top of the hierarchy, I can simply move the file to lavc. Then both lavc and lavf can use it and hierarchy is respected. Can I do that? Doesn't break API? Any objection (with solution)? Let's make right decisions to speed up the process please :). -- Best, Mohammad On Fri, Feb 21, 2020 at 2:53 AM Hendrik Leppkes wrote: > On Fri, Feb 21, 2020 at 5:59 AM Vittorio Giovara > wrote: > > > > On Thu, Feb 20, 2020 at 6:38 PM James Almer wrote: > > > > > On 2/20/2020 5:02 PM, Vittorio Giovara wrote: > > > > On Mon, Feb 10, 2020 at 3:14 PM Mohammad Izadi > > > wrote: > > > > > > > >> From: Mohammad Izadi > > > >> > > > >> Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet > side > > > >> data in the follow-up CLs. > > > >> --- > > > >> libavutil/hdr_dynamic_metadata.c | 165 > +++ > > > >> libavutil/hdr_dynamic_metadata.h | 13 ++- > > > >> libavutil/version.h | 2 +- > > > >> 3 files changed, 178 insertions(+), 2 deletions(-) > > > >> > > > >> diff --git a/libavutil/hdr_dynamic_metadata.c > > > >> b/libavutil/hdr_dynamic_metadata.c > > > >> index 0fa1ee82de..f24bcb40f5 100644 > > > >> --- a/libavutil/hdr_dynamic_metadata.c > > > >> +++ b/libavutil/hdr_dynamic_metadata.c > > > >> @@ -19,8 +19,17 @@ > > > >> */ > > > >> > > > >> #include "hdr_dynamic_metadata.h" > > > >> +#include "libavcodec/get_bits.h" > > > >> > > > > > > > > wait is it ok to use libavcodec headers in libavutil? while it's > fine at > > > > compilation time since it is an inlined header, I don't think it's a > good > > > > idea to freely use such functions in this way: what I would do is > rather > > > > implement the parsing in libavcodec, store the fields in a structure > > > > defined in libavutil and then use this new structure in here > > > > > > This seems excessive only to use a bitstream reader to read a bunch of > > > fields in a buffer. > > > > > > get_bits.h is included in lavf, so i don't see why it couldn't be used > > > in lavu. > > > > > > bacuase lavf is a library which depends on lavc, not vice versa, > hierarchy > > is respected > > > > As you said it's inlined. > > > > > > > I still consider it a poor design choice: either make bitstream reader > > public in a separate library (not easy, i am aware) or do the bitstream > > reading where the bistream actually is, IMO > > > > I agree that the parsing should just move to avcodec. We parse every > other SEI straight in the codec it comes from, why does this one have > parsing in avutil? It seems weird. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/sonic: Fix several integer overflows
NAK
This code should be purged from the tree.
On 2/21/20, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2129689466 + 2129689466 cannot be
> represented in type 'int'
> Fixes:
> 20715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5155263109922816
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/sonic.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
> index c975774b04..b82c44344c 100644
> --- a/libavcodec/sonic.c
> +++ b/libavcodec/sonic.c
> @@ -140,7 +140,8 @@ static inline av_flatten int get_symbol(RangeCoder *c,
> uint8_t *state, int is_si
> if(get_rac(c, state+0))
> return 0;
> else{
> -int i, e, a;
> +int i, e;
> +unsigned a;
> e= 0;
> while(get_rac(c, state+1 + FFMIN(e,9))){ //1..10
> e++;
> @@ -474,7 +475,7 @@ static int predictor_calc_error(int *k, int *state, int
> order, int error)
> for (i = order-2; i >= 0; i--, k_ptr--, state_ptr--)
> {
> int k_value = *k_ptr, state_value = *state_ptr;
> -x -= shift_down(k_value * state_value, LATTICE_SHIFT);
> +x -= shift_down(k_value * (unsigned)state_value, LATTICE_SHIFT);
> state_ptr[1] = state_value + shift_down(k_value * (unsigned)x,
> LATTICE_SHIFT);
> }
> #else
> @@ -1044,7 +1045,7 @@ static int sonic_decode_frame(AVCodecContext *avctx,
> x += s->channels;
> }
>
> -s->int_samples[x] = predictor_calc_error(s->predictor_k,
> s->predictor_state[ch], s->num_taps, s->coded_samples[ch][i] * quant);
> +s->int_samples[x] = predictor_calc_error(s->predictor_k,
> s->predictor_state[ch], s->num_taps, s->coded_samples[ch][i] *
> (unsigned)quant);
> x += s->channels;
> }
>
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded side data
> De : ffmpeg-devel De la part de Michael
> Niedermayer
> Envoyé : vendredi 21 février 2020 12:54
> À : FFmpeg development discussions and patches
> Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded
> side data
>
> On Thu, Feb 20, 2020 at 11:22:33AM +, Gaullier Nicolas wrote:
> > > De : ffmpeg-devel De la part de Michael
> > > Niedermayer
> > > Envoyé : vendredi 7 février 2020 23:39
> > > À : FFmpeg development discussions and patches
> > > Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB
> > > coded side data
> > >
> > > On Wed, Jan 15, 2020 at 12:42:13AM +0100, Nicolas Gaullier wrote:
> > > > This fixes mpeg2video stream copies to mpeg muxer like this:
> > > > ffmpeg -i xdcamhd.mxf -c:v copy output.mpg
> > > > ---
> > > > libavcodec/mpeg12dec.c | 7 +++
> > > > tests/ref/fate/mxf-probe-d10 | 3 +++
> > > > tests/ref/fate/ts-demux | 2 +-
> > > > 3 files changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index
> > > > 17f9495a1d..48ac14fafa 100644
> > > > --- a/libavcodec/mpeg12dec.c
> > > > +++ b/libavcodec/mpeg12dec.c
> > > > @@ -1398,6 +1398,7 @@ static void
> > > > mpeg_decode_sequence_extension(Mpeg1Context *s1)
> > > > MpegEncContext *s = >mpeg_enc_ctx;
> > > > int horiz_size_ext, vert_size_ext;
> > > > int bit_rate_ext;
> > > > +AVCPBProperties *cpb_props;
> > > >
> > > > skip_bits(>gb, 1); /* profile and level esc*/
> > > > s->avctx->profile = get_bits(>gb, 3);
> > > > @@ -1429,6 +1430,12 @@ static void
> > > > mpeg_decode_sequence_extension(Mpeg1Context *s1)
> > > > ff_dlog(s->avctx, "sequence extension\n");
> > > > s->codec_id = s->avctx->codec_id = AV_CODEC_ID_MPEG2VIDEO;
> > > >
> > > > +if (cpb_props = ff_add_cpb_side_data(s->avctx)) {
> > > > +cpb_props->buffer_size = FFMAX(cpb_props->buffer_size,
> > > > s->avctx->rc_buffer_size);
> > > > +if (s->bit_rate != 0x3*400)
> > > > +cpb_props->max_bitrate = FFMAX(cpb_props->max_bitrate,
> > > > s->bit_rate);
> > > > +}
> > >
> > > why does this not export exactly the numbers as read from the header?
> > >
> > > thx
> > The header values are expressed in units of 400bit/s, and the native value
> > 0x3 is reserved, in case of MPEG-1 (but the code is
> shared), for vbr signalling.
> > This is not very nice to read, but this is how it is implemented in current
> > code.
>
> you misunderstand, why do you take the maximum of several things instead of
> exporting the value from the header ?
>
> Thanks
Sorry for my misunderstanding. I thought the cpb properties had to reflect the
entire stream at the end and thus cumulate the size/max values.
I agree it is best to have an exact match with native header values.
Thank you for your feedback.
I will send a new version with the 2x FFMAX removed.
Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/7] avformat/segafilmenc: Remove redundant checks
lgtm
On 1/14/20, Andreas Rheinhardt wrote:
> If an audio stream is present, the Sega FILM muxer checks for its
> compability with the container during init, so that the very same check
> needn't be repeated during writing the trailer.
>
> Essentially the same is true for the presence of a video stream: It has
> already been checked during init. Furthermore, after the check for the
> presence of a video stream succeeded, a pointer is set to point to the
> video stream. Yet said pointer (which was NULL before) will be
> derefenced anyway regardless of the result of the check. Coverity thus
> complained about this in CID 1434155 and removing this pointless check
> will also fix this issue.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/segafilmenc.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
> index 5ac60ea5c3..4f881f4f2f 100644
> --- a/libavformat/segafilmenc.c
> +++ b/libavformat/segafilmenc.c
> @@ -292,15 +292,9 @@ static int film_write_header(AVFormatContext
> *format_context)
>
> if (film->audio_index > -1)
> audio = format_context->streams[film->audio_index];
> -if (film->video_index > -1)
> -video = format_context->streams[film->video_index];
>
> if (audio != NULL) {
> audio_codec = get_audio_codec_id(audio->codecpar->codec_id);
> -if (audio_codec < 0) {
> -av_log(format_context, AV_LOG_ERROR, "Incompatible audio stream
> format.\n");
> -return AVERROR(EINVAL);
> -}
> }
>
> /* First, write the FILM header; this is very simple */
> @@ -317,6 +311,8 @@ static int film_write_header(AVFormatContext
> *format_context)
> ffio_wfourcc(pb, "FDSC");
> avio_wb32(pb, 0x20); /* Size of FDSC chunk */
>
> +video = format_context->streams[film->video_index];
> +
> /* The only two supported codecs; raw video is rare */
> switch (video->codecpar->codec_id) {
> case AV_CODEC_ID_CINEPAK:
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/7] avformat/segafilmenc: Remove redundant checks
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> If an audio stream is present, the Sega FILM muxer checks for its
>> compability with the container during init, so that the very same check
>> needn't be repeated during writing the trailer.
>>
>> Essentially the same is true for the presence of a video stream: It has
>> already been checked during init. Furthermore, after the check for the
>> presence of a video stream succeeded, a pointer is set to point to the
>> video stream. Yet said pointer (which was NULL before) will be
>> derefenced anyway regardless of the result of the check. Coverity thus
>> complained about this in CID 1434155 and removing this pointless check
>> will also fix this issue.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/segafilmenc.c | 8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
>> index 5ac60ea5c3..4f881f4f2f 100644
>> --- a/libavformat/segafilmenc.c
>> +++ b/libavformat/segafilmenc.c
>> @@ -292,15 +292,9 @@ static int film_write_header(AVFormatContext
>> *format_context)
>>
>> if (film->audio_index > -1)
>> audio = format_context->streams[film->audio_index];
>> -if (film->video_index > -1)
>> -video = format_context->streams[film->video_index];
>>
>> if (audio != NULL) {
>> audio_codec = get_audio_codec_id(audio->codecpar->codec_id);
>> -if (audio_codec < 0) {
>> -av_log(format_context, AV_LOG_ERROR, "Incompatible audio stream
>> format.\n");
>> -return AVERROR(EINVAL);
>> -}
>> }
>>
>> /* First, write the FILM header; this is very simple */
>> @@ -317,6 +311,8 @@ static int film_write_header(AVFormatContext
>> *format_context)
>> ffio_wfourcc(pb, "FDSC");
>> avio_wb32(pb, 0x20); /* Size of FDSC chunk */
>>
>> +video = format_context->streams[film->video_index];
>> +
>> /* The only two supported codecs; raw video is rare */
>> switch (video->codecpar->codec_id) {
>> case AV_CODEC_ID_CINEPAK:
>>
>
> Ping.
>
> - Andreas
>
Another ping.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded side data
On Thu, Feb 20, 2020 at 11:22:33AM +, Gaullier Nicolas wrote:
> > De : ffmpeg-devel De la part de Michael
> > Niedermayer
> > Envoyé : vendredi 7 février 2020 23:39
> > À : FFmpeg development discussions and patches
> > Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded
> > side data
> >
> > On Wed, Jan 15, 2020 at 12:42:13AM +0100, Nicolas Gaullier wrote:
> > > This fixes mpeg2video stream copies to mpeg muxer like this:
> > > ffmpeg -i xdcamhd.mxf -c:v copy output.mpg
> > > ---
> > > libavcodec/mpeg12dec.c | 7 +++
> > > tests/ref/fate/mxf-probe-d10 | 3 +++
> > > tests/ref/fate/ts-demux | 2 +-
> > > 3 files changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index
> > > 17f9495a1d..48ac14fafa 100644
> > > --- a/libavcodec/mpeg12dec.c
> > > +++ b/libavcodec/mpeg12dec.c
> > > @@ -1398,6 +1398,7 @@ static void
> > > mpeg_decode_sequence_extension(Mpeg1Context *s1)
> > > MpegEncContext *s = >mpeg_enc_ctx;
> > > int horiz_size_ext, vert_size_ext;
> > > int bit_rate_ext;
> > > +AVCPBProperties *cpb_props;
> > >
> > > skip_bits(>gb, 1); /* profile and level esc*/
> > > s->avctx->profile = get_bits(>gb, 3);
> > > @@ -1429,6 +1430,12 @@ static void
> > > mpeg_decode_sequence_extension(Mpeg1Context *s1)
> > > ff_dlog(s->avctx, "sequence extension\n");
> > > s->codec_id = s->avctx->codec_id = AV_CODEC_ID_MPEG2VIDEO;
> > >
> > > +if (cpb_props = ff_add_cpb_side_data(s->avctx)) {
> > > +cpb_props->buffer_size = FFMAX(cpb_props->buffer_size,
> > > s->avctx->rc_buffer_size);
> > > +if (s->bit_rate != 0x3*400)
> > > +cpb_props->max_bitrate = FFMAX(cpb_props->max_bitrate,
> > > s->bit_rate);
> > > +}
> >
> > why does this not export exactly the numbers as read from the header?
> >
> > thx
> The header values are expressed in units of 400bit/s, and the native value
> 0x3 is reserved, in case of MPEG-1 (but the code is shared), for vbr
> signalling.
> This is not very nice to read, but this is how it is implemented in current
> code.
you misunderstand, why do you take the maximum of several things instead of
exporting the value from the header ?
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"I am not trying to be anyone's saviour, I'm trying to think about the
future and not be sad" - Elon Musk
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/pcm: Fix invalid shift in AV_CODEC_ID_PCM_LXF
probably ok On 2/21/20, Michael Niedermayer wrote: > Fixes: left shift of 233 by 24 places cannot be represented in type 'int' > Fixes: > 20736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PCM_LXF_fuzzer-4829212685107200 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/pcm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/pcm.c b/libavcodec/pcm.c > index 6346510de0..96a68f7fe8 100644 > --- a/libavcodec/pcm.c > +++ b/libavcodec/pcm.c > @@ -513,7 +513,7 @@ static int pcm_decode_frame(AVCodecContext *avctx, void > *data, > ((src[2] & 0x0F) << 8) | > src[1]; > // extract high 20 bits and expand to 32 bits > -*dst_int32_t++ = (src[4] << 24) | > +*dst_int32_t++ = ((uint32_t)src[4]<<24) | >(src[3] << 16) | > ((src[2] & 0xF0) << 8) | >(src[4] << 4) | > -- > 2.17.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/pcm: Fix invalid shift in AV_CODEC_ID_PCM_LXF
Fixes: left shift of 233 by 24 places cannot be represented in type 'int' Fixes: 20736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PCM_LXF_fuzzer-4829212685107200 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/pcm.c b/libavcodec/pcm.c index 6346510de0..96a68f7fe8 100644 --- a/libavcodec/pcm.c +++ b/libavcodec/pcm.c @@ -513,7 +513,7 @@ static int pcm_decode_frame(AVCodecContext *avctx, void *data, ((src[2] & 0x0F) << 8) | src[1]; // extract high 20 bits and expand to 32 bits -*dst_int32_t++ = (src[4] << 24) | +*dst_int32_t++ = ((uint32_t)src[4]<<24) | (src[3] << 16) | ((src[2] & 0xF0) << 8) | (src[4] << 4) | -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/sonic: Fix several integer overflows
Fixes: signed integer overflow: 2129689466 + 2129689466 cannot be represented
in type 'int'
Fixes:
20715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5155263109922816
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/sonic.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c
index c975774b04..b82c44344c 100644
--- a/libavcodec/sonic.c
+++ b/libavcodec/sonic.c
@@ -140,7 +140,8 @@ static inline av_flatten int get_symbol(RangeCoder *c,
uint8_t *state, int is_si
if(get_rac(c, state+0))
return 0;
else{
-int i, e, a;
+int i, e;
+unsigned a;
e= 0;
while(get_rac(c, state+1 + FFMIN(e,9))){ //1..10
e++;
@@ -474,7 +475,7 @@ static int predictor_calc_error(int *k, int *state, int
order, int error)
for (i = order-2; i >= 0; i--, k_ptr--, state_ptr--)
{
int k_value = *k_ptr, state_value = *state_ptr;
-x -= shift_down(k_value * state_value, LATTICE_SHIFT);
+x -= shift_down(k_value * (unsigned)state_value, LATTICE_SHIFT);
state_ptr[1] = state_value + shift_down(k_value * (unsigned)x,
LATTICE_SHIFT);
}
#else
@@ -1044,7 +1045,7 @@ static int sonic_decode_frame(AVCodecContext *avctx,
x += s->channels;
}
-s->int_samples[x] = predictor_calc_error(s->predictor_k,
s->predictor_state[ch], s->num_taps, s->coded_samples[ch][i] * quant);
+s->int_samples[x] = predictor_calc_error(s->predictor_k,
s->predictor_state[ch], s->num_taps, s->coded_samples[ch][i] * (unsigned)quant);
x += s->channels;
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.
On Fri, Feb 21, 2020 at 5:59 AM Vittorio Giovara wrote: > > On Thu, Feb 20, 2020 at 6:38 PM James Almer wrote: > > > On 2/20/2020 5:02 PM, Vittorio Giovara wrote: > > > On Mon, Feb 10, 2020 at 3:14 PM Mohammad Izadi > > wrote: > > > > > >> From: Mohammad Izadi > > >> > > >> Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side > > >> data in the follow-up CLs. > > >> --- > > >> libavutil/hdr_dynamic_metadata.c | 165 +++ > > >> libavutil/hdr_dynamic_metadata.h | 13 ++- > > >> libavutil/version.h | 2 +- > > >> 3 files changed, 178 insertions(+), 2 deletions(-) > > >> > > >> diff --git a/libavutil/hdr_dynamic_metadata.c > > >> b/libavutil/hdr_dynamic_metadata.c > > >> index 0fa1ee82de..f24bcb40f5 100644 > > >> --- a/libavutil/hdr_dynamic_metadata.c > > >> +++ b/libavutil/hdr_dynamic_metadata.c > > >> @@ -19,8 +19,17 @@ > > >> */ > > >> > > >> #include "hdr_dynamic_metadata.h" > > >> +#include "libavcodec/get_bits.h" > > >> > > > > > > wait is it ok to use libavcodec headers in libavutil? while it's fine at > > > compilation time since it is an inlined header, I don't think it's a good > > > idea to freely use such functions in this way: what I would do is rather > > > implement the parsing in libavcodec, store the fields in a structure > > > defined in libavutil and then use this new structure in here > > > > This seems excessive only to use a bitstream reader to read a bunch of > > fields in a buffer. > > > > get_bits.h is included in lavf, so i don't see why it couldn't be used > > in lavu. > > > bacuase lavf is a library which depends on lavc, not vice versa, hierarchy > is respected > > As you said it's inlined. > > > > I still consider it a poor design choice: either make bitstream reader > public in a separate library (not easy, i am aware) or do the bitstream > reading where the bistream actually is, IMO > I agree that the parsing should just move to avcodec. We parse every other SEI straight in the codec it comes from, why does this one have parsing in avutil? It seems weird. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.
Vittorio Giovara (12020-02-20): > bacuase lavf is a library which depends on lavc, not vice versa, hierarchy > is respected > > I still consider it a poor design choice The poor design choice is to keep the libraries separated. We can see all the trouble it causes us, between this discussion and all the avpriv_ symbols. I have yet to see any actual benefit. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
