Re: [FFmpeg-devel] [RFC] libpostproc splitout
Hi, On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer wrote: > On Fri, Nov 08, 2024 at 11:44:03AM +0100, Tomas Härdin wrote: > > tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer: > > > Hi all > > > > > > Should libpostproc be split out into a seperate source repository ? > > > > > > Several people did over the years want libpostproc removed, and such > > > a task was part of the submitted and approved STF 2024 projects. > > > But when i recently started posting related work, tomas questioned > > > if spliting libpostproc into a seperate source repository actually is > a good idea. > > > > > > No invoice was submitted yet, so we could likely still change > > > this to something else, if thats what people prefer. > > > > > > To clarify this a bit (as its a bit convoluted) > > > Option A. > > > 1. split libpostproc out so it builds and links fine (already > done) (send to SPI/STF/Invoice in future) > > > 2. develop test system for libpostproc (2024 future) (send to > SPI/STF/Invoice in future) > > > 3. actually remove libpostproc from master repository (2025 > future) (send to SPI/STF/Invoice in future) > > > Option B. > > > 0. double check with STF/SPI that such change is ok > > > 1. split libpostproc out so it builds and links fine (already > done) (send to SPI/STF/ never send invoice) > > > 2. develop test system for libpostproc (2024 future) (send to > SPI/STF, never send invoice) (this will get used with the libpostproc > inside FFmpeg) > > > 3. renegotiate actual libpostproc task to something else the > community wants > > > 4. whoever does the new task sends invoices and gets the whole > money for all 3 parts > > > > > > This looks a bit convoluted as iam trying to minimize the annoyance > for STF so > > > we dont have issues in the future. (Iam especially avoiding moving any > STF payments > > > accross teh year end which is a issue IIUC for STF) > > > > > > each of the 3 milestones is 5040 Euro > > > > > > Please comment what you prefer, the > > > A. split libpostproc out or > > > B. leave libpostproc in ffmpeg and fund some other maintaince work > with the 15k Euro > > > > 15k sounds like money better spent on something else, for example > > improving the build system. Circular dependencies are kind of ugly, but > > they're not showstoppers given good build systems > > my wish would be that the 15k could be spend on a plugin interface > for libavfilter. > > Something that on startup would scan ~/.ffmpeg/plugins/ or something like > that > and load all compatible ones. > Wes from Meta gave a talk about this at VDD2024. Ronald ___ 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] [RFC] libpostproc splitout
On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald S. Bultje wrote: > Hi, > > On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer > wrote: > > > On Fri, Nov 08, 2024 at 11:44:03AM +0100, Tomas Härdin wrote: > > > tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer: > > > > Hi all > > > > > > > > Should libpostproc be split out into a seperate source repository ? > > > > > > > > Several people did over the years want libpostproc removed, and such > > > > a task was part of the submitted and approved STF 2024 projects. > > > > But when i recently started posting related work, tomas questioned > > > > if spliting libpostproc into a seperate source repository actually is > > a good idea. > > > > > > > > No invoice was submitted yet, so we could likely still change > > > > this to something else, if thats what people prefer. > > > > > > > > To clarify this a bit (as its a bit convoluted) > > > > Option A. > > > > 1. split libpostproc out so it builds and links fine (already > > done) (send to SPI/STF/Invoice in future) > > > > 2. develop test system for libpostproc (2024 future) (send to > > SPI/STF/Invoice in future) > > > > 3. actually remove libpostproc from master repository (2025 > > future) (send to SPI/STF/Invoice in future) > > > > Option B. > > > > 0. double check with STF/SPI that such change is ok > > > > 1. split libpostproc out so it builds and links fine (already > > done) (send to SPI/STF/ never send invoice) > > > > 2. develop test system for libpostproc (2024 future) (send to > > SPI/STF, never send invoice) (this will get used with the libpostproc > > inside FFmpeg) > > > > 3. renegotiate actual libpostproc task to something else the > > community wants > > > > 4. whoever does the new task sends invoices and gets the whole > > money for all 3 parts > > > > > > > > This looks a bit convoluted as iam trying to minimize the annoyance > > for STF so > > > > we dont have issues in the future. (Iam especially avoiding moving any > > STF payments > > > > accross teh year end which is a issue IIUC for STF) > > > > > > > > each of the 3 milestones is 5040 Euro > > > > > > > > Please comment what you prefer, the > > > > A. split libpostproc out or > > > > B. leave libpostproc in ffmpeg and fund some other maintaince work > > with the 15k Euro > > > > > > 15k sounds like money better spent on something else, for example > > > improving the build system. Circular dependencies are kind of ugly, but > > > they're not showstoppers given good build systems > > > > my wish would be that the 15k could be spend on a plugin interface > > for libavfilter. > > > > Something that on startup would scan ~/.ffmpeg/plugins/ or something like > > that > > and load all compatible ones. > > > > Wes from Meta gave a talk about this at VDD2024. is there a recording ? do you have a link ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Give a rich man 100$ and he will turn it into 1000$. Give a poor man 1000$ and he will spend it. 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] [RFC] libpostproc splitout
Hi, On Fri, Nov 8, 2024 at 11:45 AM Michael Niedermayer wrote: > On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald S. Bultje wrote: > > On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer < > mich...@niedermayer.cc> > > > my wish would be that the 15k could be spend on a plugin interface > > > for libavfilter. > [..] > > Wes from Meta gave a talk about this at VDD2024. > > is there a recording ? > Dr. Hamacher did make a recording (with a 3d cam, no less). You could ask him if he can share the relevant section? See his website: https://lab3d.kw.ac.kr/ > do you have a link ? > Wes posted a PDF on the VDD2024 Signal group. Ronald ___ 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] fate/pixfmt: disable dithering in the scale filter
On 11/8/2024 5:15 AM, Martin Storsjö wrote: On Thu, 7 Nov 2024, James Almer wrote: Should fix fate failures across different systems. Signed-off-by: James Almer --- This only hides the bug in the dither path for unscaled planar yuv 8bit to hbd and vice-versa. Someone more familiar with the code should check what exactly is going on. LGTM, thanks! Good job in hunting this one down - it seems odd as the exact output value seems stable on each machine (and valgrind doesn't find any nondeterminism), but the output is different on most machines. The only tests that fail are those using the DITHER_COPY method in planarCopyWrapper() when dither is used, and the only difference compared to the no dither path is accessing the "dithers" static const array defined in the same file. Maybe compilers are doing something weird when aligning it, or accessing it? OpenPGP_signature.asc Description: OpenPGP digital 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] Fix incorrect enum type used for a local variable
Thank you very much ___ 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] avfilter/asrc_sine: increase phase precision
Le torstaina 7. marraskuuta 2024, 21.02.14 EET Nicolas George a écrit : > Rémi Denis-Courmont (12024-11-07): > > It is very hard to believe that someone such as you would be unable to > > trivially obtain any such sources with about as much efforts that it would > > have taken to write that mail. > > > > At this point even slow-moving Debian "anticipate[d] that the kernel, d-i > > and images teams will cease to support i386 in the near future", and that > > was almost a year ago: > > https://lists.debian.org/debian-devel-announce/2023/12/msg3.html > > It is very hard to believe that someone such as you does not realize > that desktop and server distributions are not the only kind there is. Debian also addresses embedded. Some people even make businesses of it. Not that it matters here. At this point, native 32-bit is for microcontrollers, mostly Arm or RISC-V, and with no or very poor support for floating point support. Nobody in their right mind would run FFmpeg 7.1+ floating point filters on that kind of hardware. While we should not break hypothetical support for no particular reasons, *optimising* for that scenario in 2024 would be nothing short of idiotic. If there was a clear use case, I trust that you would have positively identified it, instead of always making negations. And even if there was a clear use case, you cannot demand benchmarks on fringe hardware. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] Fix incorrect enum type used for a local variable
In order to reproduce the problem you need to compile with warnings as errors and "enum-conversion" warning enabled. This is the what clang complains about: ../../third_party/ffmpeg/libavcodec/decode.c:1469:60: error: implicit conversion from enumeration type 'const enum AVPacketSideDataType' to different enumeration type 'enum AVFrameSideDataType' [-Werror,-Wenum-conversion] 1469 | const enum AVFrameSideDataType type_pkt = map[i].packet; | ~~~^~ ../../third_party/ffmpeg/libavcodec/decode.c:1474:58: error: implicit conversion from enumeration type 'const enum AVFrameSideDataType' to different enumeration type 'enum AVPacketSideDataType' [-Werror,-Wenum-conversion] 1474 | sd_pkt = packet_side_data_get(sd_src, nb_sd_src, type_pkt); | ^~~~ On Fri, Nov 8, 2024 at 10:11 AM Marth64 wrote: > Eugene Zemtsov: > > LGTM. Is there a way to reproduce any bug that this fixes? > > Will test for side effects and wait for a few days in case anyone has > comments or concerns. > > Thank you > -- Thanks, Eugene Zemtsov. ___ 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] Develop FFmpeg through your browser?
Am 07.11.24 um 19:55 schrieb Ronald S. Bultje: Hi, You raise good questions that certainly deserve further exploration, in fact I'd be deeply supportive of such discussions. However... On Sat, Nov 2, 2024 at 7:56 PM Michael Niedermayer wrote: That said, I find the discussions about such key decissions being done each year on "videolan developer days", inappropriate and hostile. Why? (I know, you explain further:) Such a conference is great for people to sozialize, meet, discuss technical things drink their favorit drinks together and eat their favorit foods together. but key project decissions should be discussed where everyone has equal access. (and not just the option of traveling around the world) Not only does this matter for fairness and finding the best solutions, there is also the danger of political parties forming from the clustering of people discussing mainly within their silos. For me, interactive face-to-face discussions around these subjects, even amongst only subsets of the full devgroup, are far superior compared to endless email discussions. I see it as bazaar vs cathedral, where what you're asking for is cathedral-style. IIUC I disagree. A face-to-face session with a moderator is almost cathedral and cut off (i.e. moderated) at any point. Also includes hardly any time to think about the topic if not done before and includes quite a bit of social- and/or group-effects. Whereas a discussion on the ML avoids these drawbacks IMO - you have time to think, you can branch off details, caring people group around the details in question, you can avoid parts of the discussion you don't care about. I agree this is not how decisions ought to be made, but early-stage discussions like this should be fine. ML driven discussions include the whole chain of argumentation about every aspect for everyone to follow up on - whereas bringing a face-to-face discussion to the ML and then iterate on it looses that whole part of the discussion. -Thilo ___ 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] [RFC] libpostproc splitout
On Fri, Nov 08, 2024 at 11:44:03AM +0100, Tomas Härdin wrote: > tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer: > > Hi all > > > > Should libpostproc be split out into a seperate source repository ? > > > > Several people did over the years want libpostproc removed, and such > > a task was part of the submitted and approved STF 2024 projects. > > But when i recently started posting related work, tomas questioned > > if spliting libpostproc into a seperate source repository actually is a > > good idea. > > > > No invoice was submitted yet, so we could likely still change > > this to something else, if thats what people prefer. > > > > To clarify this a bit (as its a bit convoluted) > > Option A. > > 1. split libpostproc out so it builds and links fine (already done) > > (send to SPI/STF/Invoice in future) > > 2. develop test system for libpostproc (2024 future) (send to > > SPI/STF/Invoice in future) > > 3. actually remove libpostproc from master repository (2025 future) > > (send to SPI/STF/Invoice in future) > > Option B. > > 0. double check with STF/SPI that such change is ok > > 1. split libpostproc out so it builds and links fine (already done) > > (send to SPI/STF/ never send invoice) > > 2. develop test system for libpostproc (2024 future) (send to SPI/STF, > > never send invoice) (this will get used with the libpostproc inside FFmpeg) > > 3. renegotiate actual libpostproc task to something else the community > > wants > > 4. whoever does the new task sends invoices and gets the whole money > > for all 3 parts > > > > This looks a bit convoluted as iam trying to minimize the annoyance for STF > > so > > we dont have issues in the future. (Iam especially avoiding moving any STF > > payments > > accross teh year end which is a issue IIUC for STF) > > > > each of the 3 milestones is 5040 Euro > > > > Please comment what you prefer, the > > A. split libpostproc out or > > B. leave libpostproc in ffmpeg and fund some other maintaince work with the > > 15k Euro > > 15k sounds like money better spent on something else, for example > improving the build system. Circular dependencies are kind of ugly, but > they're not showstoppers given good build systems my wish would be that the 15k could be spend on a plugin interface for libavfilter. Something that on startup would scan ~/.ffmpeg/plugins/ or something like that and load all compatible ones. A restriction to a simple 1 input link, 1 output link with possibility of future extension would already cover likely 90% of use cases. anton, would you be interrested to implement something like that for 15k ? or maybe nicolas ? or maybe someone has a suggestion who else could be interrested in implementing that ? Thx [...] -- 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 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] fate/jpeg2000dec: add missing ISO/IEC 15444-4 conformance tests
From: Pierre-Anthony Lemieux --- tests/fate/jpeg2000.mak | 122 ++- tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_02_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_02_b12 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_03_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_03_b14 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_04_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_04_b12 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_05_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_05_b12 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_07_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_07_b15 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_07_b16 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_08_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_08_b15 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_08_b16 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_09_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_10_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_11_b10 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_12_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_14_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_15_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_15_b14 | 6 ++ tests/ref/fate/jpeg2000dec-ds0_ht_16_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_01_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_01_b12 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_02_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_02_b12 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_03_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_03_b12 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_04_b9 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_05_b11 | 6 ++ tests/ref/fate/jpeg2000dec-ds1_ht_06_b11 | 6 ++ tests/ref/fate/jpeg2000dec-hifi_ht1_02 | 6 ++ tests/ref/fate/jpeg2000dec-hifi_p1_02| 6 ++ tests/ref/fate/jpeg2000dec-p1_01 | 6 ++ tests/ref/fate/jpeg2000dec-p1_02 | 6 ++ tests/ref/fate/jpeg2000dec-p1_03 | 6 ++ tests/ref/fate/jpeg2000dec-p1_04 | 6 ++ tests/ref/fate/jpeg2000dec-p1_05 | 6 ++ tests/ref/fate/jpeg2000dec-p1_06 | 6 ++ 41 files changed, 361 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_02_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_02_b12 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_03_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_03_b14 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_04_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_04_b12 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_05_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_05_b12 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b15 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b16 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b15 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b16 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_09_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_10_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_11_b10 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_12_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_14_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_15_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_15_b14 create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_16_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_01_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_01_b12 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_02_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_02_b12 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_03_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_03_b12 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_04_b9 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_05_b11 create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_06_b11 create mode 100644 tests/ref/fate/jpeg2000dec-hifi_ht1_02 create mode 100644 tests/ref/fate/jpeg2000dec-hifi_p1_02 create mode 100644 tests/ref/fate/jpeg2000dec-p1_01 create mode 100644 tests/ref/fate/jpeg2000dec-p1_02 create mode 100644 tests/ref/fate/jpeg2000dec-p1_03 create mode 100644 tests/ref/fate/jpeg2000dec-p1_04 create mode 100644 tests/ref/fate/jpeg2000dec-p1_05 create mode 100644 tests/ref/fate/jpeg2000dec-p1_06 diff --git a/tests/fate/jpeg2000.mak b/tests/fate/jpeg2000.mak index a99b0c4e0c..5c6105dc20 100644 --- a/tests/fate/jpeg2000.mak +++ b/tests/fate/jpeg2000.mak @@ -60,8 +60,128 @@ fate-jpeg2000dec-p0_15: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/jpe FATE_JPEG2000DEC += fate-jpeg2000dec-p0_16 fate-jpeg2000dec-p0_16: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/jpeg2000/itu-iso/codestreams_p
Re: [FFmpeg-devel] Add support for LJ92 compressed MLV files, attempt 02
On Sat, 9 Nov 2024 at 00:37, Michael Niedermayer wrote: > > On Mon, Nov 04, 2024 at 06:14:07AM +, South East wrote: > > Hi all - what do I need to do to progress this? > > iam a bit overloaded with work ATM, but bayer or interlacing combined with > jpeg gives me memories of segfaults. So maybe you can run this through some > fuzzer > with some samples that trigger the code pathes > to check it a bit Thanks. I have experience with AFL so this is practical for me. The likely output is a collection of samples that will improve code coverage, focussing on MLV and DNG files. Does ffmpeg use AFL for testing already? I would expect to make local code modifications to ffmpeg in order to improve speed of fuzzing (see e.g. __AFL_LOOP). Would you want those changes? It should be obvious they do something because of improved code coverage, perhaps that is enough. I would expect testing with ffplay (with an ASAN enabled build) would be an acceptable scope (there is no encoder for MLV). Is that assumption correct? I would guess we are only interested in new problems when the patches are applied, i.e., if I discover old flaws, that shouldn't have any bearing on whether my patches are accepted. Beyond that, what would you consider evidence of adequate testing? ___ 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] Develop FFmpeg through your browser?
On Fri, Nov 8, 2024 at 5:02 PM Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > For me, interactive face-to-face discussions around these subjects, even > > amongst only subsets of the full devgroup, are far superior compared to > > endless email discussions. I see it as bazaar vs cathedral, where what > > you're asking for is cathedral-style. > > IIUC I disagree. A face-to-face session with a moderator is almost > cathedral and cut off (i.e. moderated) at any point. Also includes hardly > any time to think about the topic if not done before and includes quite a > bit of social- and/or group-effects. > Whereas a discussion on the ML avoids these drawbacks IMO - you have time > to think, you can branch off details, caring people group around the > details in question, you can avoid parts of the discussion you don't care > about. > Hey Thilo, do you know what happened to the discussion about the ffmpeg booth(s)? > > I agree this is not how decisions ought to be made, but early-stage > > discussions like this should be fine. > > ML driven discussions include the whole chain of argumentation about every > aspect for everyone to follow up on - whereas bringing a face-to-face > discussion to the ML and then iterate on it looses that whole part of the > discussion. > This is false: ML driven discussions often lead to nowhere, especially in ffmpeg, with a lot of nothingburger and wall of texts that stifle any prospect of change or resolution.Face to face meetings on the other hand allow to gather a sense of consensus, and prepare some action points which then can be further elaborated offline. At most the discussion is strengthened, not loosened, since it shows transparency and shows that there is a community interest behind those words. -- 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] fate/jpeg2000dec: add missing ISO/IEC 15444-4 conformance tests
Hi Pierre, LGTM. I have also confirmed that this patch passes all the test cases defined in ISO/IEC 15444-4 conformance testing. That means the PAE and MSE values with the reconstructed images are under allowable tolerance. Best, Osamu > On Nov 9, 2024, at 6:09, p...@sandflow.com wrote: > > From: Pierre-Anthony Lemieux > > --- > tests/fate/jpeg2000.mak | 122 ++- > tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_02_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_02_b12 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_03_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_03_b14 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_04_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_04_b12 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_05_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_05_b12 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_07_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_07_b15 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_07_b16 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_08_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_08_b15 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_08_b16 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_09_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_10_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_11_b10 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_12_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_14_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_15_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_15_b14 | 6 ++ > tests/ref/fate/jpeg2000dec-ds0_ht_16_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_01_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_01_b12 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_02_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_02_b12 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_03_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_03_b12 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_04_b9 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_05_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-ds1_ht_06_b11 | 6 ++ > tests/ref/fate/jpeg2000dec-hifi_ht1_02 | 6 ++ > tests/ref/fate/jpeg2000dec-hifi_p1_02| 6 ++ > tests/ref/fate/jpeg2000dec-p1_01 | 6 ++ > tests/ref/fate/jpeg2000dec-p1_02 | 6 ++ > tests/ref/fate/jpeg2000dec-p1_03 | 6 ++ > tests/ref/fate/jpeg2000dec-p1_04 | 6 ++ > tests/ref/fate/jpeg2000dec-p1_05 | 6 ++ > tests/ref/fate/jpeg2000dec-p1_06 | 6 ++ > 41 files changed, 361 insertions(+), 1 deletion(-) > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_02_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_02_b12 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_03_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_03_b14 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_04_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_04_b12 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_05_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_05_b12 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b15 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b16 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b15 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b16 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_09_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_10_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_11_b10 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_12_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_14_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_15_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_15_b14 > create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_16_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_01_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_01_b12 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_02_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_02_b12 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_03_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_03_b12 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_04_b9 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_05_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_06_b11 > create mode 100644 tests/ref/fate/jpeg2000dec-hifi_ht1_02 > create mode 100644 tests/ref/fate/jpeg2000dec-hifi_p1_02 > create mode 100644 tests/ref/fate/jpeg2000dec-p1_01 > create mode 100644 tests/ref/fate/jpeg2000dec-p1_02 > create mode 100644 tests/ref/fate/jpeg2000dec-p1_03 > create mode 100644 tests/ref/fate/jpeg2000dec-p1_04 > create mode 100644 tests/ref/fate/jpeg2000dec-p1_05 > create mode 100644 tests/ref/fate/jpeg2000dec-p1_06 > > diff --git a/tests/fate/j
[FFmpeg-devel] [PATCH] lavfi/zscale: Fix unaligned data ptr issues in realign_frame
I ran into segfaults in zimg when I attempted to use zscale
to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
with this filter chain:
buffer=width=512:height=538:pix_fmt=yuv444p16le:time_base=1/1:sar=1/1,zscale=min=2020_ncl:rin=limited:pin=2020:tin=arib-std-b67:cin=left:t=linear,format=gbrpf32le,tonemap=gamma:desat=0,zscale=tin=linear:npl=100:p=709:m=709:r=limited:t=709,format=pix_fmts=yuv444p16le,buffersink
I found several issues:
- realign_frame called av_pix_fmt_count_planes with incorrect parameter.
- av_frame_get_buffer did not align data pointers to specified alignment.
- s->tmp[job_nr] pointer was also unaligned.
https://github.com/sekrit-twc/zimg/issues/212
---
libavfilter/vf_zscale.c | 17 -
libavutil/frame.c | 8 +++-
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 4ba059064b..a74a3da8d9 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -112,6 +112,7 @@ typedef struct ZScaleContext {
int force_original_aspect_ratio;
void *tmp[MAX_THREADS]; //separate for each thread;
+void *tmp_aligned[MAX_THREADS];
int nb_threads;
int jobs_ret[MAX_THREADS];
double in_slice_start[MAX_THREADS];
@@ -594,6 +595,7 @@ static int graphs_build(AVFrame *in, AVFrame *out, const
AVPixFmtDescriptor *des
{
ZScaleContext *s = ctx->priv;
int ret;
+int misaligned_tmp;
size_t size;
zimg_image_format src_format;
zimg_image_format dst_format;
@@ -628,11 +630,15 @@ static int graphs_build(AVFrame *in, AVFrame *out, const
AVPixFmtDescriptor *des
if (ret)
return print_zimg_error(ctx);
-if (s->tmp[job_nr])
+if (s->tmp[job_nr]) {
av_freep(&s->tmp[job_nr]);
-s->tmp[job_nr] = av_calloc(size, 1);
+s->tmp_aligned[job_nr] = NULL;
+}
+s->tmp[job_nr] = av_calloc(size + ZIMG_ALIGNMENT - 1, 1);
if (!s->tmp[job_nr])
return AVERROR(ENOMEM);
+misaligned_tmp = ((uintptr_t)(s->tmp[job_nr])) % ZIMG_ALIGNMENT;
+s->tmp_aligned[job_nr] = s->tmp[job_nr] + (misaligned_tmp ?
(ZIMG_ALIGNMENT - misaligned_tmp) : 0);
if (desc->flags & AV_PIX_FMT_FLAG_ALPHA && out_desc->flags &
AV_PIX_FMT_FLAG_ALPHA) {
alpha_src_format = s->alpha_src_format;
@@ -663,7 +669,7 @@ static int realign_frame(const AVPixFmtDescriptor *desc,
AVFrame **frame, int ne
int ret = 0, plane, planes;
/* Realign any unaligned input frame. */
-planes = av_pix_fmt_count_planes(desc->nb_components);
+planes = av_pix_fmt_count_planes((*frame)->format);
for (plane = 0; plane < planes; plane++) {
int p = desc->comp[plane].plane;
if ((uintptr_t)(*frame)->data[p] % ZIMG_ALIGNMENT ||
(*frame)->linesize[p] % ZIMG_ALIGNMENT) {
@@ -750,7 +756,7 @@ static int filter_slice(AVFilterContext *ctx, void *data,
int job_nr, int n_jobs
}
if (!s->graph[job_nr])
return AVERROR(EINVAL);
-ret = zimg_filter_graph_process(s->graph[job_nr], &src_buf, &dst_buf,
s->tmp[job_nr], 0, 0, 0, 0);
+ret = zimg_filter_graph_process(s->graph[job_nr], &src_buf, &dst_buf,
s->tmp_aligned[job_nr], 0, 0, 0, 0);
if (ret)
return print_zimg_error(ctx);
@@ -765,7 +771,7 @@ static int filter_slice(AVFilterContext *ctx, void *data,
int job_nr, int n_jobs
if (!s->alpha_graph[job_nr])
return AVERROR(EINVAL);
-ret = zimg_filter_graph_process(s->alpha_graph[job_nr], &src_buf,
&dst_buf, s->tmp[job_nr], 0, 0, 0, 0);
+ret = zimg_filter_graph_process(s->alpha_graph[job_nr], &src_buf,
&dst_buf, s->tmp_aligned[job_nr], 0, 0, 0, 0);
if (ret)
return print_zimg_error(ctx);
}
@@ -944,6 +950,7 @@ static av_cold void uninit(AVFilterContext *ctx)
for (int i = 0; i < s->nb_threads; i++) {
av_freep(&s->tmp[i]);
+s->tmp_aligned[i] = NULL;
if (s->graph[i]) {
zimg_filter_graph_free(s->graph[i]);
s->graph[i] = NULL;
diff --git a/libavutil/frame.c b/libavutil/frame.c
index f0a0dba018..c99d1fd9d9 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -175,8 +175,10 @@ static int get_video_buffer(AVFrame *frame, int align)
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
int ret, padded_height, total_size;
int plane_padding = FFMAX(16 + 16/*STRIDE_ALIGN*/, align);
+int misaligned;
ptrdiff_t linesizes[4];
size_t sizes[4];
+uint8_t *aligned_ptr;
if (!desc)
return AVERROR(EINVAL);
@@ -216,14 +218,18 @@ static int get_video_buffer(AVFrame *frame, int align)
total_size += sizes[i];
}
+total_size += align - 1;
frame->buf[0] = av_buffer_alloc(total_size);
if (!frame->buf[0]) {
ret = AVERROR(ENOMEM);
goto fail;
}
+misaligned = ((uintptr_t)(frame->buf[0]->data)) % align;
+aligned_ptr = frame->buf[0]->data + (misaligned ? (align - misaligned) :
[FFmpeg-devel] [PATCH 7/7] ffv1enc: add a Vulkan encoder
This commit implements a standard, compliant, version 3 and version 4 FFv1 encoder, entirely in Vulkan. The encoder is written in standard GLSL and requires a Vulkan 1.3 supporting GPU with the BDA extension. The encoder can use any amount of slices, but nominally, should use 32x32 slices (1024 in total) to maximize parallelism. All features are supported, as well as all pixel formats. This includes: - Rice - Range coding with a custom quantization table - PCM encoding --- configure |1 + libavcodec/Makefile|1 + libavcodec/allcodecs.c |1 + libavcodec/ffv1enc.c |2 +- libavcodec/ffv1enc_vulkan.c| 1321 libavcodec/rangecoder.h| 23 +- libavcodec/vulkan/Makefile |7 + libavcodec/vulkan/common.comp | 173 libavcodec/vulkan/ffv1_common.comp | 78 ++ libavcodec/vulkan/ffv1_enc.comp| 65 ++ libavcodec/vulkan/ffv1_enc_ac.comp | 84 ++ libavcodec/vulkan/ffv1_enc_common.comp | 76 ++ libavcodec/vulkan/ffv1_enc_rct.comp| 51 + libavcodec/vulkan/ffv1_enc_rgb.comp| 78 ++ libavcodec/vulkan/ffv1_enc_setup.comp | 177 libavcodec/vulkan/ffv1_enc_vlc.comp| 114 ++ libavcodec/vulkan/ffv1_vlc.comp| 122 +++ libavcodec/vulkan/rangecoder.comp | 189 18 files changed, 2556 insertions(+), 7 deletions(-) create mode 100644 libavcodec/ffv1enc_vulkan.c create mode 100644 libavcodec/vulkan/common.comp create mode 100644 libavcodec/vulkan/ffv1_common.comp create mode 100644 libavcodec/vulkan/ffv1_enc.comp create mode 100644 libavcodec/vulkan/ffv1_enc_ac.comp create mode 100644 libavcodec/vulkan/ffv1_enc_common.comp create mode 100644 libavcodec/vulkan/ffv1_enc_rct.comp create mode 100644 libavcodec/vulkan/ffv1_enc_rgb.comp create mode 100644 libavcodec/vulkan/ffv1_enc_setup.comp create mode 100644 libavcodec/vulkan/ffv1_enc_vlc.comp create mode 100644 libavcodec/vulkan/ffv1_vlc.comp create mode 100644 libavcodec/vulkan/rangecoder.comp diff --git a/configure b/configure index 90bb535ea1..6696e9df38 100755 --- a/configure +++ b/configure @@ -2951,6 +2951,7 @@ exr_decoder_deps="zlib" exr_encoder_deps="zlib" ffv1_decoder_select="rangecoder" ffv1_encoder_select="rangecoder" +ffv1_vulkan_encoder_select="vulkan spirv_compiler" ffvhuff_decoder_select="huffyuv_decoder" ffvhuff_encoder_select="huffyuv_encoder" fic_decoder_select="golomb" diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 676ff542af..a6e0e0b55e 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -370,6 +370,7 @@ OBJS-$(CONFIG_EXR_ENCODER) += exrenc.o float2half.o OBJS-$(CONFIG_FASTAUDIO_DECODER) += fastaudio.o OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o +OBJS-$(CONFIG_FFV1_VULKAN_ENCODER) += ffv1enc.o ffv1.o ffv1enc_vulkan.o OBJS-$(CONFIG_FFWAVESYNTH_DECODER) += ffwavesynth.o OBJS-$(CONFIG_FIC_DECODER) += fic.o OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o fits.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index d8a5866435..0b559dfc58 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -116,6 +116,7 @@ extern const FFCodec ff_escape130_decoder; extern const FFCodec ff_exr_encoder; extern const FFCodec ff_exr_decoder; extern const FFCodec ff_ffv1_encoder; +extern const FFCodec ff_ffv1_vulkan_encoder; extern const FFCodec ff_ffv1_decoder; extern const FFCodec ff_ffvhuff_encoder; extern const FFCodec ff_ffvhuff_decoder; diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c index 36db135f49..9c4d344318 100644 --- a/libavcodec/ffv1enc.c +++ b/libavcodec/ffv1enc.c @@ -853,7 +853,7 @@ av_cold int ff_ffv1_encode_setup_plane_info(AVCodecContext *avctx, } av_assert0(s->bits_per_raw_sample >= 8); -return av_pix_fmt_get_chroma_sub_sample (avctx->pix_fmt, &s->chroma_h_shift, &s->chroma_v_shift); +return av_pix_fmt_get_chroma_sub_sample (pix_fmt, &s->chroma_h_shift, &s->chroma_v_shift); } static int encode_init_internal(AVCodecContext *avctx) diff --git a/libavcodec/ffv1enc_vulkan.c b/libavcodec/ffv1enc_vulkan.c new file mode 100644 index 00..2fbb1c3ddb --- /dev/null +++ b/libavcodec/ffv1enc_vulkan.c @@ -0,0 +1,1321 @@ +/* + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a c
[FFmpeg-devel] [PATCH 3/7] ffv1enc: split off encoder initialization into a separate function
---
libavcodec/ffv1enc.c | 352 +++
libavcodec/ffv1enc.h | 30
2 files changed, 216 insertions(+), 166 deletions(-)
create mode 100644 libavcodec/ffv1enc.h
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 7a6c718b41..10103f129b 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -39,6 +39,7 @@
#include "put_golomb.h"
#include "rangecoder.h"
#include "ffv1.h"
+#include "ffv1enc.h"
static const int8_t quant5_10bit[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1,
@@ -513,17 +514,11 @@ static int sort_stt(FFV1Context *s, uint8_t stt[256])
return print;
}
-static av_cold int encode_init(AVCodecContext *avctx)
+av_cold int ff_ffv1_encode_init(AVCodecContext *avctx)
{
FFV1Context *s = avctx->priv_data;
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
int i, j, k, m, ret;
-if ((ret = ff_ffv1_common_init(avctx)) < 0)
-return ret;
-
-s->version = 0;
-
if ((avctx->flags & (AV_CODEC_FLAG_PASS1 | AV_CODEC_FLAG_PASS2)) ||
avctx->slices > 1)
s->version = FFMAX(s->version, 2);
@@ -569,6 +564,182 @@ static av_cold int encode_init(AVCodecContext *avctx)
return AVERROR_INVALIDDATA;
}
+if (s->ac == AC_RANGE_CUSTOM_TAB) {
+for (i = 1; i < 256; i++)
+s->state_transition[i] = ver2_state[i];
+} else {
+RangeCoder c;
+ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8);
+for (i = 1; i < 256; i++)
+s->state_transition[i] = c.one_state[i];
+}
+
+for (i = 0; i < 256; i++) {
+s->quant_table_count = 2;
+if ((s->qtable == -1 && s->bits_per_raw_sample <= 8) || s->qtable ==
1) {
+s->quant_tables[0][0][i]= quant11[i];
+s->quant_tables[0][1][i]=11*quant11[i];
+s->quant_tables[0][2][i]= 11*11*quant11[i];
+s->quant_tables[1][0][i]= quant11[i];
+s->quant_tables[1][1][i]=11*quant11[i];
+s->quant_tables[1][2][i]= 11*11*quant5 [i];
+s->quant_tables[1][3][i]= 5*11*11*quant5 [i];
+s->quant_tables[1][4][i]= 5*5*11*11*quant5 [i];
+s->context_count[0] = (11 * 11 * 11+ 1) / 2;
+s->context_count[1] = (11 * 11 * 5 * 5 * 5 + 1) / 2;
+} else {
+s->quant_tables[0][0][i]= quant9_10bit[i];
+s->quant_tables[0][1][i]= 9*quant9_10bit[i];
+s->quant_tables[0][2][i]= 9*9*quant9_10bit[i];
+s->quant_tables[1][0][i]= quant9_10bit[i];
+s->quant_tables[1][1][i]= 9*quant9_10bit[i];
+s->quant_tables[1][2][i]= 9*9*quant5_10bit[i];
+s->quant_tables[1][3][i]= 5*9*9*quant5_10bit[i];
+s->quant_tables[1][4][i]= 5*5*9*9*quant5_10bit[i];
+s->context_count[0] = (9 * 9 * 9 + 1) / 2;
+s->context_count[1] = (9 * 9 * 5 * 5 * 5 + 1) / 2;
+}
+}
+
+if ((ret = ff_ffv1_allocate_initial_states(s)) < 0)
+return ret;
+
+if (!s->transparency)
+s->plane_count = 2;
+if (!s->chroma_planes && s->version > 3)
+s->plane_count--;
+
+s->picture_number = 0;
+
+if (avctx->flags & (AV_CODEC_FLAG_PASS1 | AV_CODEC_FLAG_PASS2)) {
+for (i = 0; i < s->quant_table_count; i++) {
+s->rc_stat2[i] = av_mallocz(s->context_count[i] *
+sizeof(*s->rc_stat2[i]));
+if (!s->rc_stat2[i])
+return AVERROR(ENOMEM);
+}
+}
+if (avctx->stats_in) {
+char *p = avctx->stats_in;
+uint8_t (*best_state)[256] = av_malloc_array(256, 256);
+int gob_count = 0;
+char *next;
+if (!best_state)
+return AVERROR(ENOMEM);
+
+av_assert0(s->version >= 2);
+
+for (;;) {
+for (j = 0; j < 256; j++)
+for (i = 0; i < 2; i++) {
+s->rc_stat[j][i] = strtol(p, &next, 0);
+if (next == p) {
+av_log(avctx, AV_LOG_ERROR,
+ "2Pass file invalid at %d %d [%s]\n", j, i, p);
+av_freep(&best_state);
+return AVERROR_INVALIDDATA;
+}
+p = next;
+}
+for (i = 0; i < s->quant_table_count; i++)
+for (j = 0; j < s->context_count[i]; j++) {
+for (k = 0; k < 32; k++)
+for (m = 0; m < 2; m++) {
+s->rc_stat2[i][j][k][m] = strtol(p, &next, 0);
+if (next == p) {
+av_log(avctx, AV_LOG_ERROR,
+ "2Pass file invalid at %d %d %d %d
[%s]\n",
+ i, j, k, m
[FFmpeg-devel] [PATCH 4/7] ffv1enc: move plane info init into a separate function
---
libavcodec/ffv1enc.c | 40
libavcodec/ffv1enc.h | 2 ++
2 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 10103f129b..023b32e10c 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -731,22 +731,14 @@ av_cold int ff_ffv1_encode_init(AVCodecContext *avctx)
return 0;
}
-static int encode_init_internal(AVCodecContext *avctx)
+av_cold int ff_ffv1_encode_setup_plane_info(AVCodecContext *avctx,
+enum AVPixelFormat pix_fmt)
{
-int ret;
FFV1Context *s = avctx->priv_data;
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
-
-if ((ret = ff_ffv1_common_init(avctx)) < 0)
-return ret;
-
-if (s->ac == 1) // Compatbility with common command line usage
-s->ac = AC_RANGE_CUSTOM_TAB;
-else if (s->ac == AC_RANGE_DEFAULT_TAB_FORCE)
-s->ac = AC_RANGE_DEFAULT_TAB;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
s->plane_count = 3;
-switch(avctx->pix_fmt) {
+switch(pix_fmt) {
case AV_PIX_FMT_GRAY9:
case AV_PIX_FMT_YUV444P9:
case AV_PIX_FMT_YUV422P9:
@@ -879,6 +871,26 @@ static int encode_init_internal(AVCodecContext *avctx)
}
av_assert0(s->bits_per_raw_sample >= 8);
+return av_pix_fmt_get_chroma_sub_sample (avctx->pix_fmt,
&s->chroma_h_shift, &s->chroma_v_shift);
+}
+
+static int encode_init_internal(AVCodecContext *avctx)
+{
+int ret;
+FFV1Context *s = avctx->priv_data;
+
+if ((ret = ff_ffv1_common_init(avctx)) < 0)
+return ret;
+
+if (s->ac == 1) // Compatbility with common command line usage
+s->ac = AC_RANGE_CUSTOM_TAB;
+else if (s->ac == AC_RANGE_DEFAULT_TAB_FORCE)
+s->ac = AC_RANGE_DEFAULT_TAB;
+
+ret = ff_ffv1_encode_setup_plane_info(avctx, avctx->pix_fmt);
+if (ret < 0)
+return ret;
+
if (s->bits_per_raw_sample > 8) {
if (s->ac == AC_GOLOMB_RICE) {
av_log(avctx, AV_LOG_INFO,
@@ -887,10 +899,6 @@ static int encode_init_internal(AVCodecContext *avctx)
}
}
-ret = av_pix_fmt_get_chroma_sub_sample (avctx->pix_fmt,
&s->chroma_h_shift, &s->chroma_v_shift);
-if (ret)
-return ret;
-
{
int plane_count = 1 + 2*s->chroma_planes + s->transparency;
int max_h_slices = AV_CEIL_RSHIFT(avctx->width , s->chroma_h_shift);
diff --git a/libavcodec/ffv1enc.h b/libavcodec/ffv1enc.h
index c062af0bf5..f7b2e6cdbf 100644
--- a/libavcodec/ffv1enc.h
+++ b/libavcodec/ffv1enc.h
@@ -26,5 +26,7 @@
#include "avcodec.h"
av_cold int ff_ffv1_encode_init(AVCodecContext *avctx);
+av_cold int ff_ffv1_encode_setup_plane_info(AVCodecContext *avctx,
+enum AVPixelFormat pix_fmt);
#endif /* AVCODEC_FFV1ENC_H */
--
2.45.2.753.g447d99e1c3b
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/7] ffv1: use standard syntax for indexing state
It isn't immediately obvious what indexing this array does.
Use standard syntax instead.
---
libavcodec/ffv1.h | 2 +-
libavcodec/ffv1dec_template.c | 2 +-
libavcodec/ffv1enc_template.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index 2af457be27..ed71e238e0 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -63,7 +63,7 @@ typedef struct VlcState {
typedef struct PlaneContext {
int quant_table_index;
int context_count;
-uint8_t (*state)[CONTEXT_SIZE];
+uint8_t *state;
VlcState *vlc_state;
} PlaneContext;
diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
index 2da6bd935d..3c95741b32 100644
--- a/libavcodec/ffv1dec_template.c
+++ b/libavcodec/ffv1dec_template.c
@@ -71,7 +71,7 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
av_assert2(context < p->context_count);
if (ac != AC_GOLOMB_RICE) {
-diff = get_symbol_inline(c, p->state[context], 1);
+diff = get_symbol_inline(c, &p->state[32*context], 1);
} else {
if (context == 0 && run_mode == 0)
run_mode = 1;
diff --git a/libavcodec/ffv1enc_template.c b/libavcodec/ffv1enc_template.c
index bc14926ab9..e17e40a327 100644
--- a/libavcodec/ffv1enc_template.c
+++ b/libavcodec/ffv1enc_template.c
@@ -75,10 +75,10 @@ RENAME(encode_line)(FFV1Context *f, FFV1SliceContext *sc,
if (ac != AC_GOLOMB_RICE) {
if (pass1) {
-put_symbol_inline(c, p->state[context], diff, 1, sc->rc_stat,
+put_symbol_inline(c, &p->state[32*context], diff, 1,
sc->rc_stat,
sc->rc_stat2[p->quant_table_index][context]);
} else {
-put_symbol_inline(c, p->state[context], diff, 1, NULL, NULL);
+put_symbol_inline(c, &p->state[32*context], diff, 1, NULL,
NULL);
}
} else {
if (context == 0)
--
2.45.2.753.g447d99e1c3b
___
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/7] hwcontext_vulkan: explicitly wait when uploading
---
libavutil/hwcontext_vulkan.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 0b52ad5112..0c9047f4c6 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -4200,13 +4200,12 @@ static int vulkan_transfer_frame(AVHWFramesContext
*hwfc,
}
err = ff_vk_exec_submit(&p->vkctx, exec);
-if (err < 0) {
+if (err < 0)
ff_vk_exec_discard_deps(&p->vkctx, exec);
-} else if (!upload) {
-ff_vk_exec_wait(&p->vkctx, exec);
-if (!host_mapped)
-err = copy_buffer_data(hwfc, bufs[0], swf, region, planes, 0);
-}
+
+ff_vk_exec_wait(&p->vkctx, exec);
+if (!upload && !host_mapped)
+err = copy_buffer_data(hwfc, bufs[0], swf, region, planes, 0);
end:
for (int i = 0; i < nb_bufs; i++)
--
2.45.2.753.g447d99e1c3b
___
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/7] .gitignore: add exclusions for shader .c files
--- .gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index e810d11107..9cfc78b414 100644 --- a/.gitignore +++ b/.gitignore @@ -41,3 +41,5 @@ /src /mapfile /tools/python/__pycache__/ +/libavcodec/vulkan/*.c +/libavfilter/vulkan/*.c -- 2.45.2.753.g447d99e1c3b ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/7] ffv1enc: move slice allocation out of generic encode init
---
libavcodec/ffv1enc.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 023b32e10c..36db135f49 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -710,24 +710,6 @@ av_cold int ff_ffv1_encode_init(AVCodecContext *avctx)
return ret;
}
-if ((ret = ff_ffv1_init_slice_contexts(s)) < 0)
-return ret;
-s->slice_count = s->max_slice_count;
-
-for (int j = 0; j < s->slice_count; j++) {
-for (int i = 0; i < s->plane_count; i++) {
-PlaneContext *const p = &s->slices[j].plane[i];
-
-p->quant_table_index = s->context_model;
-p->context_count = s->context_count[p->quant_table_index];
-}
-
-ff_build_rac_states(&s->slices[j].c, 0.05 * (1LL << 32), 256 - 8);
-}
-
-if ((ret = ff_ffv1_init_slices_state(s)) < 0)
-return ret;
-
return 0;
}
@@ -937,6 +919,24 @@ slices_ok:
if (ret < 0)
return ret;
+if ((ret = ff_ffv1_init_slice_contexts(s)) < 0)
+return ret;
+s->slice_count = s->max_slice_count;
+
+for (int j = 0; j < s->slice_count; j++) {
+for (int i = 0; i < s->plane_count; i++) {
+PlaneContext *const p = &s->slices[j].plane[i];
+
+p->quant_table_index = s->context_model;
+p->context_count = s->context_count[p->quant_table_index];
+}
+
+ff_build_rac_states(&s->slices[j].c, 0.05 * (1LL << 32), 256 - 8);
+}
+
+if ((ret = ff_ffv1_init_slices_state(s)) < 0)
+return ret;
+
#define STATS_OUT_SIZE 1024 * 1024 * 6
if (avctx->flags & AV_CODEC_FLAG_PASS1) {
avctx->stats_out = av_mallocz(STATS_OUT_SIZE);
--
2.45.2.753.g447d99e1c3b
___
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] lavfi/zscale: Fix unaligned data ptr issues in realign_frame
On 11/8/2024 10:51 PM, Pavel Koshevoy wrote:
I ran into segfaults in zimg when I attempted to use zscale
to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
with this filter chain:
buffer=width=512:height=538:pix_fmt=yuv444p16le:time_base=1/1:sar=1/1,zscale=min=2020_ncl:rin=limited:pin=2020:tin=arib-std-b67:cin=left:t=linear,format=gbrpf32le,tonemap=gamma:desat=0,zscale=tin=linear:npl=100:p=709:m=709:r=limited:t=709,format=pix_fmts=yuv444p16le,buffersink
I found several issues:
- realign_frame called av_pix_fmt_count_planes with incorrect parameter.
- av_frame_get_buffer did not align data pointers to specified alignment.
Because it's not supposed to. The align parameter doxy states "buffer
size alignment", which is the result of aligning the stride/linesizes,
not the data pointers.
You may want to use ff_default_get_video_buffer2(), which will add align
amount of bytes to the allocated buffers (On top of aligning the
linesizes to it), and then align the pointers with FFALIGN().
- s->tmp[job_nr] pointer was also unaligned.
Please split this into one patch per issue fixed, to simplify future
bisecting.
https://github.com/sekrit-twc/zimg/issues/212
---
libavfilter/vf_zscale.c | 17 -
libavutil/frame.c | 8 +++-
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 4ba059064b..a74a3da8d9 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -112,6 +112,7 @@ typedef struct ZScaleContext {
int force_original_aspect_ratio;
void *tmp[MAX_THREADS]; //separate for each thread;
+void *tmp_aligned[MAX_THREADS];
int nb_threads;
int jobs_ret[MAX_THREADS];
double in_slice_start[MAX_THREADS];
@@ -594,6 +595,7 @@ static int graphs_build(AVFrame *in, AVFrame *out, const
AVPixFmtDescriptor *des
{
ZScaleContext *s = ctx->priv;
int ret;
+int misaligned_tmp;
size_t size;
zimg_image_format src_format;
zimg_image_format dst_format;
@@ -628,11 +630,15 @@ static int graphs_build(AVFrame *in, AVFrame *out, const
AVPixFmtDescriptor *des
if (ret)
return print_zimg_error(ctx);
-if (s->tmp[job_nr])
+if (s->tmp[job_nr]) {
av_freep(&s->tmp[job_nr]);
-s->tmp[job_nr] = av_calloc(size, 1);
+s->tmp_aligned[job_nr] = NULL;
+}
+s->tmp[job_nr] = av_calloc(size + ZIMG_ALIGNMENT - 1, 1);
if (!s->tmp[job_nr])
return AVERROR(ENOMEM);
+misaligned_tmp = ((uintptr_t)(s->tmp[job_nr])) % ZIMG_ALIGNMENT;
Use FFALIGN() instead.
OpenPGP_signature.asc
Description: OpenPGP digital 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] Develop FFmpeg through your browser?
Nicolas George 于2024年11月8日周五 00:24写道： > > Michael Niedermayer (12024-11-03): > > We can install gitlab on our infrastructure, if the community decides that > > it > > wants gitlab. We can also install anything else the community wants. > > If we want a more-than-monthly emergency security update and the dozens > of minutes of associated downtime, then by all means let us install > GitLab on own infrastructure. > > (And just to be clear, that was not me volunteering to manage it. I am > already fed up with the two I have inherited.) > > More generally, these “forges” that try to do everything unavoidably are > passable or mediocre at each thing they do. The benefit of having > everything integrated together is completely cancelled by not using the > best tool for each task. > > The main benefit is for people who are already familiar with these tools > and will not need to learn another process. > > That leads me to my third point: It seems to me the demands that we move > to such a tool mostly come from people who would have contributed > anyway. People who want their code in, shifting the burden of > maintenance to the project, but do not want to invest time into learning > different tools, even when they are superior. I agreed Nicolas's comment. And i think maybe we should try AB Test some month, use both ML & gitlab, the developers can review PR base gitlab who like review on gitlab, keep current status if developer like review base ML. We could move to gitlab if developer have many counts growth. We should keep current status if developer have a few growth. Everything can be showed by growth data, the growth data can say move to gitlab is right or wrong. And i agreed with Thilo, everything in community should be recorded and save storage. I like current FFmpeg community status, FFmpeg community looks have solid historical foundation, looks not light as a feather. And i usually use github communicate with other opensource project. If developers have interested in FFmpeg, they can learn how to contribute code, document and other thing to ffmpeg, At least that's how I feel. Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/zscale: Fix unaligned data ptr issues in realign_frame
On Fri, Nov 8, 2024 at 7:29 PM James Almer wrote:
> On 11/8/2024 10:51 PM, Pavel Koshevoy wrote:
> > I ran into segfaults in zimg when I attempted to use zscale
> > to convert a 512x538@yuv444p16le(tv) image from HLG to Bt.709
> > with this filter chain:
> >
> >
> buffer=width=512:height=538:pix_fmt=yuv444p16le:time_base=1/1:sar=1/1,zscale=min=2020_ncl:rin=limited:pin=2020:tin=arib-std-b67:cin=left:t=linear,format=gbrpf32le,tonemap=gamma:desat=0,zscale=tin=linear:npl=100:p=709:m=709:r=limited:t=709,format=pix_fmts=yuv444p16le,buffersink
> >
> > I found several issues:
> > - realign_frame called av_pix_fmt_count_planes with incorrect parameter.
> > - av_frame_get_buffer did not align data pointers to specified alignment.
>
> Because it's not supposed to. The align parameter doxy states "buffer
> size alignment", which is the result of aligning the stride/linesizes,
> not the data pointers.
>
> You may want to use ff_default_get_video_buffer2(), which will add align
> amount of bytes to the allocated buffers (On top of aligning the
> linesizes to it), and then align the pointers with FFALIGN().
>
I am not the maintainer of vf_zscale, and I am not intimately familiar with
private ffmpeg APIs such as ff_default_get_video_buffer2, and at first
glance that function
doesn't appear to be a drop-in replacement for av_frame_get_buffer.
ff_default_get_video_buffer2 requires AVFilterLink parameter?! --
realign_frame doesn't
have that, it has an AVFrame which it needs to re-align to make it
compatible with libzimg API.
... and why isn't av_frame_get_buffer populating AVFrame.data pointers
aligned
as specified by the align parameter? It costs at most (align - 1) more
padding bytes
to make it align the pointers, so I don't understand why it doesn't do that.
>
> > - s->tmp[job_nr] pointer was also unaligned.
>
> Please split this into one patch per issue fixed, to simplify future
> bisecting.
>
> >
> > https://github.com/sekrit-twc/zimg/issues/212
> > ---
> > libavfilter/vf_zscale.c | 17 -
> > libavutil/frame.c | 8 +++-
> > 2 files changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
> > index 4ba059064b..a74a3da8d9 100644
> > --- a/libavfilter/vf_zscale.c
> > +++ b/libavfilter/vf_zscale.c
> > @@ -112,6 +112,7 @@ typedef struct ZScaleContext {
> > int force_original_aspect_ratio;
> >
> > void *tmp[MAX_THREADS]; //separate for each thread;
> > +void *tmp_aligned[MAX_THREADS];
> > int nb_threads;
> > int jobs_ret[MAX_THREADS];
> > double in_slice_start[MAX_THREADS];
> > @@ -594,6 +595,7 @@ static int graphs_build(AVFrame *in, AVFrame *out,
> const AVPixFmtDescriptor *des
> > {
> > ZScaleContext *s = ctx->priv;
> > int ret;
> > +int misaligned_tmp;
> > size_t size;
> > zimg_image_format src_format;
> > zimg_image_format dst_format;
> > @@ -628,11 +630,15 @@ static int graphs_build(AVFrame *in, AVFrame *out,
> const AVPixFmtDescriptor *des
> > if (ret)
> > return print_zimg_error(ctx);
> >
> > -if (s->tmp[job_nr])
> > +if (s->tmp[job_nr]) {
> > av_freep(&s->tmp[job_nr]);
> > -s->tmp[job_nr] = av_calloc(size, 1);
> > +s->tmp_aligned[job_nr] = NULL;
> > +}
> > +s->tmp[job_nr] = av_calloc(size + ZIMG_ALIGNMENT - 1, 1);
> > if (!s->tmp[job_nr])
> > return AVERROR(ENOMEM);
> > +misaligned_tmp = ((uintptr_t)(s->tmp[job_nr])) % ZIMG_ALIGNMENT;
>
> Use FFALIGN() instead.
>
> ___
> 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 2/2] lavc/vvc_mc: R-V V dmvr
ping 于2024年10月12日周六 17:28写道： > From: sunyuechi > > k230 banana_f3 > dmvr_8_12x20_c: 619.3 ( 1.00x)624.1 ( 1.00x) > dmvr_8_12x20_rvv_i32: 128.6 ( 4.82x)103.4 ( 6.04x) > dmvr_8_20x12_c: 610.0 ( 1.00x)665.6 ( 1.00x) > dmvr_8_20x12_rvv_i32: 137.6 ( 4.44x)92.9 ( 7.17x) > dmvr_8_20x20_c: 1008.0 ( 1.00x)1082.7 ( 1.00x) > dmvr_8_20x20_rvv_i32: 221.1 ( 4.56x)155.4 ( 6.97x) > dmvr_h_8_12x20_c:2008.0 ( 1.00x)2009.7 ( 1.00x) > dmvr_h_8_12x20_rvv_i32: 239.6 ( 8.38x)186.7 (10.77x) > dmvr_h_8_20x12_c:1989.5 ( 1.00x)2009.4 ( 1.00x) > dmvr_h_8_20x12_rvv_i32: 230.3 ( 8.64x)155.4 (12.93x) > dmvr_h_8_20x20_c:3304.1 ( 1.00x)3342.9 ( 1.00x) > dmvr_h_8_20x20_rvv_i32: 378.3 ( 8.73x)248.9 (13.43x) > dmvr_hv_8_12x20_c: 3609.8 ( 1.00x)3603.4 ( 1.00x) > dmvr_hv_8_12x20_rvv_i32: 369.1 ( 9.78x)322.1 (11.19x) > dmvr_hv_8_20x12_c: 3628.3 ( 1.00x)3624.2 ( 1.00x) > dmvr_hv_8_20x12_rvv_i32: 322.8 (11.24x)238.7 (15.19x) > dmvr_hv_8_20x20_c: 5933.8 ( 1.00x)5936.6 ( 1.00x) > dmvr_hv_8_20x20_rvv_i32: 526.5 (11.27x)374.1 (15.87x) > dmvr_v_8_12x20_c:2156.3 ( 1.00x)2155.4 ( 1.00x) > dmvr_v_8_12x20_rvv_i32: 239.6 ( 9.00x)176.2 (12.24x) > dmvr_v_8_20x12_c:2137.6 ( 1.00x)2165.9 ( 1.00x) > dmvr_v_8_20x12_rvv_i32: 230.3 ( 9.28x)155.2 (13.96x) > dmvr_v_8_20x20_c:4183.8 ( 1.00x)3592.9 ( 1.00x) > dmvr_v_8_20x20_rvv_i32: 369.3 (11.33x)249.2 (14.42x) > --- > libavcodec/riscv/vvc/vvc_mc_rvv.S | 122 + > libavcodec/riscv/vvc/vvcdsp_init.c | 22 ++ > 2 files changed, 144 insertions(+) > > diff --git a/libavcodec/riscv/vvc/vvc_mc_rvv.S > b/libavcodec/riscv/vvc/vvc_mc_rvv.S > index 18532616d9..1dcbaf7d5b 100644 > --- a/libavcodec/riscv/vvc/vvc_mc_rvv.S > +++ b/libavcodec/riscv/vvc/vvc_mc_rvv.S > @@ -285,3 +285,125 @@ endfunc > func_w_avg 128 > func_w_avg 256 > #endif > + > +func dmvr zve32x, zbb, zba > +lpad0 > +lit0, 4 > +1: > +add t1, a1, a2 > +addi t4, a0, 128*2 > +vle8.vv0, (a1) > +vle8.vv4, (t1) > +addi a3, a3, -2 > +vwmulu.vx v16, v0, t0 > +vwmulu.vx v20, v4, t0 > +vse16.v v16, (a0) > +vse16.v v20, (t4) > +sh1adda1, a2, a1 > +add a0, a0, 128*2*2 > +bnez a3, 1b > +ret > +endfunc > + > +.macro dmvr_h_v mn, type, w, vlen > +func dmvr_\type\vlen\w, zve32x, zbb, zba > +lla t4, ff_vvc_inter_luma_dmvr_filters > +sh1addt4, \mn, t4 > +lbu t5, (t4) > +lbu t6, 1(t4) > +1: > +vsetvlstatic8 \w, \vlen > +.ifc \type,h > +addi t0, a1, 1 > +addi t1, a1, 2 > +.else > +add t0, a1, a2 > +add t1, t0, a2 > +.endif > +vle8.vv0, (a1) > +vle8.vv4, (t0) > +vle8.vv8, (t1) > +addi a3, a3, -2 > +addi t2, a0, 128*2 > +vwmulu.vx v12, v0, t5 > +vwmulu.vx v24, v4, t5 > +vwmaccu.vxv12, t6, v4 > +vwmaccu.vxv24, t6, v8 > +vsetvlstatic16\w, \vlen > +vssrl.vi v12, v12, 2 > +vssrl.vi v24, v24, 2 > +vse16.v v12, (a0) > +vse16.v v24, (t2) > +add a0, a0, 128*4 > +sh1adda1, a2, a1 > +bnez a3, 1b > +ret > +endfunc > +.endm > + > +.macro dmvr_load_h dst, filter0, filter1, w, vlen > +vsetvlstatic8 \w, \vlen > +addi a6, a1, 1 > +vle8.v\dst, (a1) > +vle8.vv2, (a6) > +vwmulu.vx v4, \dst, \filter0 > +vwmaccu.vxv4, \filter1, v2 > +vsetvlstatic16\w, \vlen > +vssrl.vi \dst, v4, 2 > +.endm > + > +.macro dmvr_hv w, vlen > +func dmvr_hv\vlen\w, zve32x, zbb, zba > +lla t0, ff_vvc_inter_luma_dmvr_filters > +sh1addt1, a4, t0 > +sh1addt2, a5, t0 > +lbu t3, (t1) // filter[mx][0] > +lbu t4, 1(t1) // filter[mx][1] > +lbu t5, (t2) // filter[my][0] > +lbu t6, 1(
Re: [FFmpeg-devel] [RFC] libpostproc splitout
Le torstaina 7. marraskuuta 2024, 22.04.04 EET Michael Niedermayer a écrit : > On Thu, Nov 07, 2024 at 02:48:13PM +, Derek Buitenhuis wrote: > > On 11/6/2024 11:11 PM, Michael Niedermayer wrote: > > > 3. actually remove libpostproc from master repository (2025 future) > > > (send to SPI/STF/Invoice in future)> > > I also did this exact work for Libav in 2012. It was very little work. Not > > 5k. > This is slander Yes, you are slandering Derek by accusing him of slander out of nowhere. Even if Derek were lying, that would not be slander, since the work in question is not a person and cannot be "slandered". And sorry but while I am all for splitting postproc to a separate repository, it is at best a few hundreds euros worth of consulting time. The difficult part, if there is one, is to reach the agreement to do it, not to actually do it. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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] [RFC] libpostproc splitout
Le perjantaina 8. marraskuuta 2024, 18.45.29 EET Michael Niedermayer a écrit : > > Wes from Meta gave a talk about this at VDD2024. > > is there a recording ? > do you have a link ? I think that day was recorded, but it will probably take a while before the videos are processed and released by the faculty. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] Fix incorrect enum type used for a local variable
Eugene Zemtsov: LGTM. Is there a way to reproduce any bug that this fixes? Will test for side effects and wait for a few days in case anyone has comments or concerns. Thank you ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] enc_recon_frame_test: don't print an error on EOF.
Before:
$ make tools/enc_recon_frame_test
$ tools/enc_recon_frame_test ~/Movies/cif/bus_cif.y4m libx264 'tune=psnr'
Error submitting a frame for encoding
After:
All 150 encoded frames match
---
tools/enc_recon_frame_test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/enc_recon_frame_test.c b/tools/enc_recon_frame_test.c
index c6da6750fe..83cc8343d3 100644
--- a/tools/enc_recon_frame_test.c
+++ b/tools/enc_recon_frame_test.c
@@ -178,6 +178,8 @@ static int process_frame(DecodeContext *dc, AVFrame *frame)
}
ret = avcodec_send_frame(pd->enc, frame);
+if (ret == AVERROR_EOF && !frame)
+return 0;
if (ret < 0) {
fprintf(stderr, "Error submitting a frame for encoding\n");
return ret;
--
2.43.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 V7] Patch to add interlaced HEVC decoding to HEVCDEC
From 613629758c059c941a43c3e1b64de59f4076f746 Mon Sep 17 00:00:00 2001
From: Jose Santiago
Date: Fri, 8 Nov 2024 10:57:07 -0600
Subject: [PATCH V7] Patch to add interlaced HEVC decoding to HEVCDEC
V7 Fixes FATE regression and cropping for reconstructed field pictures.
---
libavcodec/hevc/hevcdec.c | 24 ++-
libavcodec/hevc/hevcdec.h | 13 ++
libavcodec/hevc/refs.c| 426 +-
libavcodec/hevc/sei.c | 16 +-
libavcodec/hevc/sei.h | 129 +++-
5 files changed, 583 insertions(+), 25 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 1ea8df0fa0..d7179bdcf7 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -359,7 +359,18 @@ static void export_stream_params(HEVCContext *s, const
HEVCSPS *sps)
avctx->profile = sps->ptl.general_ptl.profile_idc;
avctx->level = sps->ptl.general_ptl.level_idc;
-ff_set_sar(avctx, sps->vui.common.sar);
+// There are some streams in the wild that were encode field pitcures
+//and set double height aspect ratio so that some players that do not
+//support interlaced HEVC display the field pictures with double
height.
+// Since we are now combining the field pictures into a single interlaced
+//frame, fix the sample aspect ratio to restore the correct shape for
the
+//reconstructed interlaced frames.
+if
(ff_hevc_sei_pict_struct_is_field_picture(s->sei.picture_timing.picture_struct)
&&
+sps->vui.common.sar.num == 1 && sps->vui.common.sar.den == 2) {
+ff_set_sar(avctx, (AVRational){1, 1});
+} else {
+ff_set_sar(avctx, sps->vui.common.sar);
+}
if (sps->vui.common.video_signal_type_present_flag)
avctx->color_range = sps->vui.common.video_full_range_flag ?
AVCOL_RANGE_JPEG
@@ -3821,6 +3832,7 @@ static int hevc_ref_frame(HEVCFrame *dst, const HEVCFrame
*src)
dst->rpl = ff_refstruct_ref(src->rpl);
dst->nb_rpl_elems = src->nb_rpl_elems;
+dst->sei_pic_struct = src->sei_pic_struct;
dst->poc= src->poc;
dst->ctb_count = src->ctb_count;
dst->flags = src->flags;
@@ -3851,6 +3863,8 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
av_freep(&s->md5_ctx);
av_freep(&s->h274db);
+ff_hevc_output_frame_construction_ctx_unref(s);
+
ff_container_fifo_free(&s->output_fifo);
for (int layer = 0; layer < FF_ARRAY_ELEMS(s->layers); layer++) {
@@ -3895,6 +3909,11 @@ static av_cold int hevc_init_context(AVCodecContext
*avctx)
s->local_ctx[0].logctx = avctx;
s->local_ctx[0].common_cabac_state = &s->cabac;
+if (ff_hevc_output_frame_construction_ctx_alloc(s) != 0 ||
+!s->output_frame_construction_ctx) {
+return AVERROR(ENOMEM);
+}
+
s->output_fifo = ff_container_fifo_alloc_avframe(0);
if (!s->output_fifo)
return AVERROR(ENOMEM);
@@ -3949,6 +3968,8 @@ static int hevc_update_thread_context(AVCodecContext *dst,
}
}
+ff_hevc_output_frame_construction_ctx_replace(s, s0);
+
for (int i = 0; i < FF_ARRAY_ELEMS(s->ps.vps_list); i++)
ff_refstruct_replace(&s->ps.vps_list[i], s0->ps.vps_list[i]);
@@ -4012,6 +4033,7 @@ static int hevc_update_thread_context(AVCodecContext *dst,
s->sei.common.content_light= s0->sei.common.content_light;
s->sei.common.aom_film_grain = s0->sei.common.aom_film_grain;
s->sei.tdrdi = s0->sei.tdrdi;
+s->sei.picture_timing = s0->sei.picture_timing;
return 0;
}
diff --git a/libavcodec/hevc/hevcdec.h b/libavcodec/hevc/hevcdec.h
index 73b792c880..4ce764f287 100644
--- a/libavcodec/hevc/hevcdec.h
+++ b/libavcodec/hevc/hevcdec.h
@@ -369,6 +369,10 @@ typedef struct HEVCFrame {
int ctb_count;
int poc;
+// SEI Picture Timing Picture Structure Type.
+// HEVC_SEI_PicStructType.
+int sei_pic_struct;
+
const HEVCPPS *pps;///< RefStruct reference
RefPicListTab *rpl;///< RefStruct reference
int nb_rpl_elems;
@@ -484,6 +488,8 @@ typedef struct HEVCLayerContext {
struct FFRefStructPool *rpl_tab_pool;
} HEVCLayerContext;
+struct HEVCOutputFrameConstructionContext;
+
typedef struct HEVCContext {
const AVClass *c; // needed by private avoptions
AVCodecContext *avctx;
@@ -502,6 +508,9 @@ typedef struct HEVCContext {
/** 1 if the independent slice segment header was successfully parsed */
uint8_t slice_initialized;
+// Interlaced Frame Construction Context.
+struct HEVCOutputFrameConstructionContext *output_frame_construction_ctx;
///< RefStruct reference
+
struct ContainerFifo *output_fifo;
HEVCParamSets ps;
@@ -664,6 +673,10 @@ static av_always_inline int ff_hevc_nal_is_nonref(enum
HEVCNALUnitType type)
return 0;
}
+int ff_hevc_output_frame_construction_ctx_alloc(
Re: [FFmpeg-devel] [PATCH] doc/bitstream_filters: elaborate on h264_redundant_pps
Will push in 12-24hr Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/mxfenc: Use nb_components, not av_pix_fmt_count_planes()
tor 2024-10-31 klockan 09:57 +0100 skrev Tomas Härdin: > tis 2024-10-29 klockan 08:48 -0700 skrev Pierre-Anthony Lemieux: > > LGTM > > Will push later today Wups, forgot to. Pushed now though /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/pixfmt: disable dithering in the scale filter
On Thu, 7 Nov 2024, James Almer wrote: Should fix fate failures across different systems. Signed-off-by: James Almer --- This only hides the bug in the dither path for unscaled planar yuv 8bit to hbd and vice-versa. Someone more familiar with the code should check what exactly is going on. LGTM, thanks! Good job in hunting this one down - it seems odd as the exact output value seems stable on each machine (and valgrind doesn't find any nondeterminism), but the output is different on most machines. // Martin ___ 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] [RFC] libpostproc splitout
tor 2024-11-07 klockan 00:11 +0100 skrev Michael Niedermayer: > Hi all > > Should libpostproc be split out into a seperate source repository ? > > Several people did over the years want libpostproc removed, and such > a task was part of the submitted and approved STF 2024 projects. > But when i recently started posting related work, tomas questioned > if spliting libpostproc into a seperate source repository actually is a good > idea. > > No invoice was submitted yet, so we could likely still change > this to something else, if thats what people prefer. > > To clarify this a bit (as its a bit convoluted) > Option A. > 1. split libpostproc out so it builds and links fine (already done) (send > to SPI/STF/Invoice in future) > 2. develop test system for libpostproc (2024 future) (send to > SPI/STF/Invoice in future) > 3. actually remove libpostproc from master repository (2025 future) (send > to SPI/STF/Invoice in future) > Option B. > 0. double check with STF/SPI that such change is ok > 1. split libpostproc out so it builds and links fine (already done) (send > to SPI/STF/ never send invoice) > 2. develop test system for libpostproc (2024 future) (send to SPI/STF, > never send invoice) (this will get used with the libpostproc inside FFmpeg) > 3. renegotiate actual libpostproc task to something else the community > wants > 4. whoever does the new task sends invoices and gets the whole money for > all 3 parts > > This looks a bit convoluted as iam trying to minimize the annoyance for STF so > we dont have issues in the future. (Iam especially avoiding moving any STF > payments > accross teh year end which is a issue IIUC for STF) > > each of the 3 milestones is 5040 Euro > > Please comment what you prefer, the > A. split libpostproc out or > B. leave libpostproc in ffmpeg and fund some other maintaince work with the > 15k Euro 15k sounds like money better spent on something else, for example improving the build system. Circular dependencies are kind of ugly, but they're not showstoppers given good build systems /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 11/15] avformat/flacdec:Return correct error-codes on read-failure
ons 2024-10-30 klockan 11:44 +0100 skrev Tomas Härdin: > I also made some test files to demonstrate the differences in behavior. > What's being addressed here is early termination of the file. One thing > to bikeshed over is whether to return AVERROR_EOF or > AVERROR_INVALIDDATA in that case. The attached files demonstrate a > change in return value depending on how short a flac file is. It might > make more sense to always return AVERROR_EOF since being truncated is > fundamentally the issue with the file in these cases Actually I feel like bikeshedding/philosophizing over this a bit since it is probably relevant to other parts of the code. I feel there is an important qualitative difference between a file being too short and a file containing bad data, and we'd like to within the best of our abilities tell the user what the problem is. But this isn't always so easy. Consider a length field followed by not enough data. This could happen for two reasons: either the file was terminated early or the length field was written incorrectly or somehow corrupted. Should we assume that the file was written correctly and cut short, or the opposite? In this specific case I think the answer is easy: always return EOF. Why? Because the streaminfo chunk is 34 bytes by definition, and unless the muxer is incredibly broken, an incomplete read is almost certainly due to the file being cut early We could in principle move the checks for metadata_size further up, but it's probably not worthwhile here. In a proper parsing framework this kind of stuff could be expressed in a grammar. For streaminfo it should match \x00\x00\x00\x22 exactly TL;DR: I'm going to change to returning EOF here, unless someone objects /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/mxfenc: Use nb_components, not av_pix_fmt_count_planes()
tor 2024-10-31 klockan 20:02 +0100 skrev Marton Balint:
>
>
> On Tue, 29 Oct 2024, Tomas Härdin wrote:
>
> > tis 2024-10-29 klockan 12:21 -0300 skrev James Almer:
> > > > From ce4b1dfb97530b242f899e5d1686f98fa83a7698 Mon Sep 17 00:00:00
> > > > 2001
> > > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
> > > > Date: Tue, 29 Oct 2024 16:13:04 +0100
> > > > Subject: [PATCH] lavf/mxfenc: Use nb_components, not
> > > > av_pix_fmt_count_planes()
> > > >
> > > > This fixed https://trac.ffmpeg.org/ticket/11267
> > > > ---
> > > > libavformat/mxfenc.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > > index 57be9e6ef6..e66df0fba2 100644
> > > > --- a/libavformat/mxfenc.c
> > > > +++ b/libavformat/mxfenc.c
> > > > @@ -1488,7 +1488,7 @@ static void
> > > > mxf_write_jpeg2000_subdesc(AVFormatContext *s, AVStream *st)
> > > > MXFStreamContext *sc = st->priv_data;
> > > > AVIOContext *pb = s->pb;
> > > > int64_t pos;
> > > > - int component_count = av_pix_fmt_count_planes(st->codecpar-
> > > > > format);
> > > > + int component_count = av_pix_fmt_desc_get(st->codecpar-
> > > > > format)->nb_components;
> > >
> > > I don't think anything ensures that av_pix_fmt_desc_get() here will
> > > not
> > > return NULL, so maybe instead do:
> > >
> > > > const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(st->codecpar-
> > > > > format);
> > > > int component_count;
> > > >
> > > > if (!desc)
> > > > return AVERROR(EINVAL);
> > > >
> > > > component_count = desc->nb_components;
> >
> > I can't really see how that would happen, but I suppose it doesn't
> > hurt.
> >
> > I see elsewhere in the code an assert that the returned pointer is not
> > NULL (mxf_write_ffv1_desc()), and explicit checks for it
>
> There is a similar check in your patch:
>
> - int component_count = av_pix_fmt_count_planes(st->codecpar->format);
> + const AVPixFmtDescriptor *pix_desc =
> av_pix_fmt_desc_get(st->codecpar->format);
> +
> + if (!pix_desc) {
> + av_log(s, AV_LOG_ERROR, "Pixel format not set - not writing
> JPEG2000SubDescriptor\n");
> + return;
> + }
>
> You should propagate back the error, not just silently ignore it. Or if
> this cannot happen, make this an assert instead.
Not a bad idea. write_desc in MXFContainerEssenceEntry returns void,
changing it to return int shouldn't be hard. I'll do it in a separate
patch
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] libavcodec/sanm: fix XPAL handling
Outlaws' RAE.SAN file did not properly fade out in certain scenes,
but simply turned to black as soon as the first XPAL chunk with
the apply command was encountered.
Signed-off-by: Manuel Lauss
---
libavcodec/sanm.c | 69 ---
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 022d4b347e..936746ace4 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -1033,6 +1033,45 @@ static int process_frame_obj(SANMVideoContext *ctx)
}
}
+static int process_xpal(SANMVideoContext *ctx, int size)
+{
+int16_t *dp = ctx->delta_pal;
+uint32_t *pal = ctx->pal;
+uint16_t cmd;
+uint8_t c[3];
+int i, j;
+
+bytestream2_skip(&ctx->gb, 2);
+cmd = bytestream2_get_be16(&ctx->gb);
+
+if (cmd == 1) {
+for (i = 0; i < PALETTE_DELTA; i += 3) {
+c[0] = (*pal >> 16) & 0xFF;
+c[1] = (*pal >> 8) & 0xFF;
+c[2] = (*pal >> 0) & 0xFF;
+for (j = 0; j < 3; j++) {
+int cl = (c[j] * 129) + *dp++;
+c[j] = av_clip_uint8(cl / 128) & 0xFF;
+}
+*pal++ = 0xFFU << 24 | c[0] << 16 | c[1] << 8 | c[2];
+}
+} else if (cmd == 2) {
+if (size < PALETTE_DELTA * 2 + 4) {
+av_log(ctx->avctx, AV_LOG_ERROR,
+ "Incorrect palette change block size %"PRIu32".\n", size);
+return AVERROR_INVALIDDATA;
+}
+for (i = 0; i < PALETTE_DELTA; i++)
+dp[i] = bytestream2_get_le16u(&ctx->gb);
+
+if (size >= PALETTE_DELTA * 2 + 4 + PALETTE_SIZE * 3) {
+for (i = 0; i < PALETTE_SIZE; i++)
+ctx->pal[i] = 0xFFU << 24 | bytestream2_get_be24u(&ctx->gb);
+}
+}
+return 0;
+}
+
static int decode_0(SANMVideoContext *ctx)
{
uint16_t *frm = ctx->frm0;
@@ -1472,34 +1511,8 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
*frame,
return ret;
break;
case MKBETAG('X', 'P', 'A', 'L'):
-if (size == 6 || size == 4) {
-uint8_t tmp[3];
-int j;
-
-for (i = 0; i < PALETTE_SIZE; i++) {
-for (j = 0; j < 3; j++) {
-int t = (ctx->pal[i] >> (16 - j * 8)) & 0xFF;
-tmp[j] = av_clip_uint8((t * 129 + ctx->delta_pal[i
* 3 + j]) >> 7);
-}
-ctx->pal[i] = 0xFFU << 24 | AV_RB24(tmp);
-}
-} else {
-if (size < PALETTE_DELTA * 2 + 4) {
-av_log(avctx, AV_LOG_ERROR,
- "Incorrect palette change block size
%"PRIu32".\n",
- size);
-return AVERROR_INVALIDDATA;
-}
-bytestream2_skipu(&ctx->gb, 4);
-for (i = 0; i < PALETTE_DELTA; i++)
-ctx->delta_pal[i] = bytestream2_get_le16u(&ctx->gb);
-if (size >= PALETTE_DELTA * 5 + 4) {
-for (i = 0; i < PALETTE_SIZE; i++)
-ctx->pal[i] = 0xFFU << 24 |
bytestream2_get_be24u(&ctx->gb);
-} else {
-memset(ctx->pal, 0, sizeof(ctx->pal));
-}
-}
+if (ret = process_xpal(ctx, size))
+return ret;
break;
case MKBETAG('S', 'T', 'O', 'R'):
to_store = 1;
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/2] libavcodec/sanm: enhancements
This set of 2 patches adds support for SMUSH codec47 subcodec1 interpolation table support, and fixes handling of the SMUSH XPAL (delta palette) chunk. Patch 1 aims to reduce the blockyness of quarter-sized keyframes: the codec stream provides data to construct a 256x256 table where the values of 2 adjacent pixels can be used as an index into this table to get a new pixel value to place in between the 2 reference pixels. The current subcodec1 implementation just creates a 2x2 block of the source pixel. Patch 2 fixes the intended fadeout of the scene in the LucasArts Outlaws RAE.SAN (ending) file. Now the there is a proper fadeout and fade-day-to-night transition instead of a sudden black screen. See [1] and [2] for a before and after the patch video. Tested with mpv on all the SAN videos of LucarArts Outlaws and Curse of Monkey Island games (both use SMUSH codec47). [1] http://mlau.at/sanm-before.webm (1,7MB, 40s) [2] http://mlau.at/sanm-after.webm (3,2MB, 61s) Manuel Lauss (2): libavcodec/sanm: add codec47 interpolation table support libavcodec/sanm: fix XPAL handling libavcodec/sanm.c | 136 +- 1 file changed, 97 insertions(+), 39 deletions(-) -- 2.47.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] libavcodec/sanm: add codec47 interpolation table support
Some codec47 frames come with an interpolation table:
Combining 2 adjacent pixels into a 16bit value, this value can
then be used as index into the interpolation table to get a new
pixel value. This is used for subcodec 1, which encodes a key-
frame at half width and height, and makes these frame less blocky
appearing.
Signed-off-by: Manuel Lauss
---
libavcodec/sanm.c | 67 +++
1 file changed, 56 insertions(+), 11 deletions(-)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 8b7c0d9556..022d4b347e 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -291,6 +291,7 @@ typedef struct SANMVideoContext {
int8_t p4x4glyphs[NGLYPHS][16];
int8_t p8x8glyphs[NGLYPHS][64];
+uint8_t c47itbl[0x1];
} SANMVideoContext;
typedef struct SANMFrameHeader {
@@ -856,6 +857,55 @@ static int process_block(SANMVideoContext *ctx, uint8_t
*dst, uint8_t *prev1,
return 0;
}
+static void codec47_read_interptable(SANMVideoContext *ctx)
+{
+uint8_t *p1, *p2, *itbl = ctx->c47itbl;
+int i, j;
+
+for (i = 0; i < 256; i++) {
+p1 = p2 = itbl + i;
+for (j = 256 - i; j; j--) {
+*p1 = *p2 = bytestream2_get_byte(&ctx->gb);
+p1 += 1;
+p2 += 256;
+}
+itbl += 256;
+}
+}
+
+static void codec47_comp1(SANMVideoContext *ctx, uint8_t *dst_in, int width,
+ int height, ptrdiff_t stride)
+{
+uint8_t p1, *dst, *itbl = ctx->c47itbl;
+uint16_t px;
+int i, j;
+
+dst = dst_in + stride;
+for (i = 0; i < height; i += 2) {
+p1 = bytestream2_get_byte(&ctx->gb);
+*dst++ = p1;
+*dst++ = p1;
+px = p1;
+for (j = 2; j < width; j += 2) {
+p1 = bytestream2_get_byte(&ctx->gb);
+px = (px << 8) | p1;
+*dst++ = itbl[px];
+*dst++ = p1;
+}
+dst += stride;
+}
+
+memcpy(dst_in, dst_in + stride, width);
+dst = dst_in + stride + stride;
+for (i = 2; i < height - 1; i += 2) {
+for (j = 0; j < width; j++) {
+px = (*(dst - stride) << 8) | *(dst + stride);
+*dst++ = itbl[px];
+}
+dst += stride;
+}
+}
+
static int old_codec47(SANMVideoContext *ctx, int top,
int left, int width, int height)
{
@@ -880,8 +930,11 @@ static int old_codec47(SANMVideoContext *ctx, int top,
av_log(ctx->avctx, AV_LOG_WARNING, "Decoded size is too large.\n");
}
-if (skip & 1)
-bytestream2_skip(&ctx->gb, 0x8080);
+if (skip & 1) {
+if (bytestream2_get_bytes_left(&ctx->gb) < 0x8080)
+return AVERROR_INVALIDDATA;
+codec47_read_interptable(ctx);
+}
if (!seq) {
ctx->prev_seq = -1;
memset(prev1, 0, ctx->height * stride);
@@ -900,15 +953,7 @@ static int old_codec47(SANMVideoContext *ctx, int top,
case 1:
if (bytestream2_get_bytes_left(&ctx->gb) < ((width + 1) >> 1) *
((height + 1) >> 1))
return AVERROR_INVALIDDATA;
-for (j = 0; j < height; j += 2) {
-for (i = 0; i < width; i += 2) {
-dst[i] =
-dst[i + 1] =
-dst[stride + i] =
-dst[stride + i + 1] = bytestream2_get_byteu(&ctx->gb);
-}
-dst += stride * 2;
-}
+codec47_comp1(ctx, dst, width, height, stride);
break;
case 2:
if (seq == ctx->prev_seq + 1) {
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] libavcodec/sanm: codec47: apply top offset also to diff buffers
SAN FRME objects specify width/height as well as offsets from top/left.
These offsets need to be taken into account for the diff buffers
as well. Fixes playback of all SAN videos of "Shadows of the Empire",
which have a constant top offset of 60 (640x272 video on a 640x480 window)
and show tons of ghosting and block artifacts.
Signed-off-by: Manuel Lauss
---
libavcodec/sanm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index fcf6234d8a..8bcffb1e90 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -913,8 +913,8 @@ static int old_codec47(SANMVideoContext *ctx, int top,
int i, j;
ptrdiff_t stride = ctx->pitch;
uint8_t *dst = (uint8_t *)ctx->frm0 + left + top * stride;
-uint8_t *prev1 = (uint8_t *)ctx->frm1;
-uint8_t *prev2 = (uint8_t *)ctx->frm2;
+uint8_t *prev1 = (uint8_t *)ctx->frm1 + left + top * stride;
+uint8_t *prev2 = (uint8_t *)ctx->frm2 + left + top * stride;
uint8_t auxcol[2];
int tbl_pos = bytestream2_tell(&ctx->gb);
int seq = bytestream2_get_le16(&ctx->gb);
@@ -940,8 +940,8 @@ static int old_codec47(SANMVideoContext *ctx, int top,
}
if (!seq) {
ctx->prev_seq = -1;
-memset(prev1, auxcol[0], ctx->height * stride);
-memset(prev2, auxcol[1], ctx->height * stride);
+memset(prev1, auxcol[0], (ctx->height - top) * stride);
+memset(prev2, auxcol[1], (ctx->height - top) * stride);
}
switch (compr) {
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] libavcodec/sanm: clear codec47 diff buffers with specific color
The codec47 header provides colors to use to clear the
2 difference buffers. This fixes artifacts (black hair, faces) in
Curse of Monkey Island "CURSERNG.SAN" video.
Signed-off-by: Manuel Lauss
---
libavcodec/sanm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 936746ace4..fcf6234d8a 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -915,13 +915,16 @@ static int old_codec47(SANMVideoContext *ctx, int top,
uint8_t *dst = (uint8_t *)ctx->frm0 + left + top * stride;
uint8_t *prev1 = (uint8_t *)ctx->frm1;
uint8_t *prev2 = (uint8_t *)ctx->frm2;
+uint8_t auxcol[2];
int tbl_pos = bytestream2_tell(&ctx->gb);
int seq = bytestream2_get_le16(&ctx->gb);
int compr = bytestream2_get_byte(&ctx->gb);
int new_rot = bytestream2_get_byte(&ctx->gb);
int skip= bytestream2_get_byte(&ctx->gb);
-bytestream2_skip(&ctx->gb, 9);
+bytestream2_skip(&ctx->gb, 7);
+auxcol[0] = bytestream2_get_byteu(&ctx->gb);
+auxcol[1] = bytestream2_get_byteu(&ctx->gb);
decoded_size = bytestream2_get_le32(&ctx->gb);
bytestream2_skip(&ctx->gb, 8);
@@ -937,8 +940,8 @@ static int old_codec47(SANMVideoContext *ctx, int top,
}
if (!seq) {
ctx->prev_seq = -1;
-memset(prev1, 0, ctx->height * stride);
-memset(prev2, 0, ctx->height * stride);
+memset(prev1, auxcol[0], ctx->height * stride);
+memset(prev2, auxcol[1], ctx->height * stride);
}
switch (compr) {
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavf/mxfenc: Make write_desc return int
Passes fate-mxf
/Tomas
From 8f221258a9e5328c4a03fef6e8eab18ce20ce4f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 8 Nov 2024 11:24:05 +0100
Subject: [PATCH 1/2] lavf/mxfenc: Make write_desc return int
This enables returning AVERRORs
---
libavformat/mxfenc.c | 61 +++-
1 file changed, 38 insertions(+), 23 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 664e8ca743..abc870f133 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -129,7 +129,7 @@ typedef struct MXFContainerEssenceEntry {
UID container_ul;
UID element_ul;
UID codec_ul;
-void (*write_desc)(AVFormatContext *, AVStream *);
+int (*write_desc)(AVFormatContext *, AVStream *);
} MXFContainerEssenceEntry;
typedef struct MXFPackage {
@@ -170,14 +170,14 @@ static const struct {
{ AV_CODEC_ID_NONE }
};
-static void mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
-static void mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
-static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
-static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
-static void mxf_write_ffv1_desc(AVFormatContext *s, AVStream *st);
-static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
-static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st);
-static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_ffv1_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st);
+static int mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
static const MXFContainerEssenceEntry mxf_essence_container_uls[] = {
{ { 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x02,0x0D,0x01,0x03,0x01,0x02,0x04,0x60,0x01 },
@@ -1545,7 +1545,7 @@ static void mxf_write_jpeg2000_subdesc(AVFormatContext *s, AVStream *st)
mxf_update_klv_size(pb, pos);
}
-static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st)
+static int mxf_write_cdci_desc(AVFormatContext *s, AVStream *st)
{
int64_t pos = mxf_write_cdci_common(s, st, mxf_cdci_descriptor_key);
mxf_update_klv_size(s->pb, pos);
@@ -1556,9 +1556,10 @@ static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st)
if (st->codecpar->codec_id == AV_CODEC_ID_JPEG2000) {
mxf_write_jpeg2000_subdesc(s, st);
}
+return 0;
}
-static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st)
+static int mxf_write_h264_desc(AVFormatContext *s, AVStream *st)
{
MXFStreamContext *sc = st->priv_data;
if (sc->avc_intra) {
@@ -1568,9 +1569,10 @@ static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st)
mxf_update_klv_size(s->pb, pos);
mxf_write_avc_subdesc(s, st);
}
+return 0;
}
-static void mxf_write_ffv1_subdesc(AVFormatContext *s, AVStream *st)
+static int mxf_write_ffv1_subdesc(AVFormatContext *s, AVStream *st)
{
AVIOContext *pb = s->pb;
MXFStreamContext *sc = st->priv_data;
@@ -1597,9 +1599,10 @@ static void mxf_write_ffv1_subdesc(AVFormatContext *s, AVStream *st)
}
mxf_update_klv_size(s->pb, pos);
+return 0;
}
-static void mxf_write_ffv1_desc(AVFormatContext *s, AVStream *st)
+static int mxf_write_ffv1_desc(AVFormatContext *s, AVStream *st)
{
int is_rgb, pos;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(st->codecpar->format);
@@ -1608,16 +1611,17 @@ static void mxf_write_ffv1_desc(AVFormatContext *s, AVStream *st)
pos = mxf_write_cdci_common(s, st, is_rgb ? mxf_rgba_descriptor_key : mxf_cdci_descriptor_key);
mxf_update_klv_size(s->pb, pos);
-mxf_write_ffv1_subdesc(s, st);
+return mxf_write_ffv1_subdesc(s, st);
}
-static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st)
+static int mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st)
{
int64_t pos = mxf_write_generic_desc(s, st, mxf_s436m_anc_descriptor_key);
mxf_update_klv_size(s->pb, pos);
+return 0;
}
-static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st)
+static int mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st)
{
AVIOContext *pb = s->pb;
MXFStreamContext *sc = st->priv_data;
@@ -1653,6 +1657,7 @@ static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st)
}
mxf_update_klv_size(pb, pos);
+return 0;
}
static int64_t mxf_write_generic_sound_common(AVFormatContext *s, AVStream *st, const UID key)
@@ -1719,22 +1724,25 @@ static int64_t mxf_write_wav_common(AVFormatContext *s, AVStream *st, const UID
return p
[FFmpeg-devel] [PATCH 2/2] lavf/mxfenc: Return AVERROR(EINVAL) in mxf_write_jpeg2000_subdesc() is pixfmt not set
Also passes fate-mxf
/Tomas
From 164175d6f7e2e1eab767c129d953e6e9ebbfc94d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 8 Nov 2024 11:26:24 +0100
Subject: [PATCH 2/2] lavf/mxfenc: Return AVERROR(EINVAL) in
mxf_write_jpeg2000_subdesc() is pixfmt not set
---
libavformat/mxfenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index abc870f133..a482a6a352 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1483,7 +1483,7 @@ static void mxf_write_avc_subdesc(AVFormatContext *s, AVStream *st)
mxf_update_klv_size(s->pb, pos);
}
-static void mxf_write_jpeg2000_subdesc(AVFormatContext *s, AVStream *st)
+static int mxf_write_jpeg2000_subdesc(AVFormatContext *s, AVStream *st)
{
MXFStreamContext *sc = st->priv_data;
AVIOContext *pb = s->pb;
@@ -1492,7 +1492,7 @@ static void mxf_write_jpeg2000_subdesc(AVFormatContext *s, AVStream *st)
if (!pix_desc) {
av_log(s, AV_LOG_ERROR, "Pixel format not set - not writing JPEG2000SubDescriptor\n");
-return;
+return AVERROR(EINVAL);
}
/* JPEG2000 subdescriptor key */
@@ -1543,6 +1543,7 @@ static void mxf_write_jpeg2000_subdesc(AVFormatContext *s, AVStream *st)
avio_write(pb, sc->j2k_info.j2k_comp_desc, 3*pix_desc->nb_components);
mxf_update_klv_size(pb, pos);
+return 0;
}
static int mxf_write_cdci_desc(AVFormatContext *s, AVStream *st)
@@ -1554,7 +1555,7 @@ static int mxf_write_cdci_desc(AVFormatContext *s, AVStream *st)
mxf_write_avc_subdesc(s, st);
}
if (st->codecpar->codec_id == AV_CODEC_ID_JPEG2000) {
- mxf_write_jpeg2000_subdesc(s, st);
+ return mxf_write_jpeg2000_subdesc(s, st);
}
return 0;
}
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] libpostproc splitout
On Fri, Nov 08, 2024 at 01:15:41PM -0500, Ronald S. Bultje wrote: > Hi, > > On Fri, Nov 8, 2024 at 11:45 AM Michael Niedermayer > wrote: > > > On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald S. Bultje wrote: > > > On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer < > > mich...@niedermayer.cc> > > > > my wish would be that the 15k could be spend on a plugin interface > > > > for libavfilter. > > > [..] > > > > Wes from Meta gave a talk about this at VDD2024. > > > > is there a recording ? > > > > Dr. Hamacher did make a recording (with a 3d cam, no less). You could ask > him if he can share the relevant section? See his website: > https://lab3d.kw.ac.kr/ > > > > do you have a link ? > > > > Wes posted a PDF on the VDD2024 Signal group. Does FB / Wes plan to submit this feature to FFmpeg for integration ? thx [] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/pixfmt: disable dithering in the scale filter
On Fri, Nov 08, 2024 at 04:56:38PM -0300, James Almer wrote: > On 11/8/2024 5:15 AM, Martin Storsjö wrote: > > On Thu, 7 Nov 2024, James Almer wrote: > > > > > Should fix fate failures across different systems. > > > > > > Signed-off-by: James Almer > > > --- > > > This only hides the bug in the dither path for unscaled planar yuv > > > 8bit to > > > hbd and vice-versa. > > > Someone more familiar with the code should check what exactly is > > > going on. > > > > LGTM, thanks! Good job in hunting this one down - it seems odd as the > > exact output value seems stable on each machine (and valgrind doesn't > > find any nondeterminism), but the output is different on most machines. > > The only tests that fail are those using the DITHER_COPY method in > planarCopyWrapper() when dither is used, and the only difference compared to > the no dither path is accessing the "dithers" static const array defined in > the same file. > Maybe compilers are doing something weird when aligning it, or accessing it? Not sure i fully understand but the brute force way to debug this is maybe just add a printf() to dump every value then diff between to see where differences start. 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] Add support for LJ92 compressed MLV files, attempt 02
On Mon, Nov 04, 2024 at 06:14:07AM +, South East wrote: > Hi all - what do I need to do to progress this? > > I'm not sure, but it sounds like Tomas thought patch 1 might need > someone with experience with Bayer taking a look. iam a bit overloaded with work ATM, but bayer or interlacing combined with jpeg gives me memories of segfaults. So maybe you can run this through some fuzzer with some samples that trigger the code pathes to check it a bit thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mov: use an array of pointers for heif_item
Pointers to specific entries in the array are stored in other structs, so
in the scenario where heif_item was reallocated when parsing an iloc box after
and iinf one, the pointers may end up referencing freed memory.
Fixes use-after-free with such samples.
Signed-off-by: James Almer
---
libavformat/isom.h | 2 +-
libavformat/mov.c | 75 ++
2 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 49a4753fad..5aab5bad9b 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -360,7 +360,7 @@ typedef struct MOVContext {
uint32_t max_stts_delta;
int primary_item_id;
int cur_item_id;
-HEIFItem *heif_item;
+HEIFItem **heif_item;
int nb_heif_item;
HEIFGrid *heif_grid;
int nb_heif_grid;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 8c3329b815..f9e5b9e199 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -197,10 +197,10 @@ static HEIFItem *heif_cur_item(MOVContext *c)
HEIFItem *item = NULL;
for (int i = 0; i < c->nb_heif_item; i++) {
-if (c->heif_item[i].item_id != c->cur_item_id)
+if (!c->heif_item[i] || c->heif_item[i]->item_id != c->cur_item_id)
continue;
-item = &c->heif_item[i];
+item = c->heif_item[i];
break;
}
@@ -8657,7 +8657,7 @@ static int mov_read_idat(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
-HEIFItem *heif_item;
+HEIFItem **heif_item;
int version, offset_size, length_size, base_offset_size, index_size;
int item_count, extent_count;
int64_t base_offset, extent_offset, extent_length;
@@ -8688,12 +8688,13 @@ static int mov_read_iloc(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
return AVERROR(ENOMEM);
c->heif_item = heif_item;
if (item_count > c->nb_heif_item)
-memset(c->heif_item + c->nb_heif_item, 0,
+memset(&c->heif_item[c->nb_heif_item], 0,
sizeof(*c->heif_item) * (item_count - c->nb_heif_item));
c->nb_heif_item = FFMAX(c->nb_heif_item, item_count);
av_log(c->fc, AV_LOG_TRACE, "iloc: item_count %d\n", item_count);
for (int i = 0; i < item_count; i++) {
+HEIFItem *item = c->heif_item[i];
int item_id = (version < 2) ? avio_rb16(pb) : avio_rb32(pb);
int offset_type = (version > 0) ? avio_rb16(pb) & 0xf : 0;
@@ -8703,7 +8704,6 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avpriv_report_missing_feature(c->fc, "iloc offset type %d",
offset_type);
return AVERROR_PATCHWELCOME;
}
-c->heif_item[i].item_id = item_id;
avio_rb16(pb); // data_reference_index.
if (rb_size(pb, &base_offset, base_offset_size) < 0)
@@ -8714,19 +8714,26 @@ static int mov_read_iloc(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
avpriv_report_missing_feature(c->fc, "iloc: extent_count > 1");
return AVERROR_PATCHWELCOME;
}
-for (int j = 0; j < extent_count; j++) {
+
if (rb_size(pb, &extent_offset, offset_size) < 0 ||
rb_size(pb, &extent_length, length_size) < 0 ||
base_offset > INT64_MAX - extent_offset)
return AVERROR_INVALIDDATA;
+
+if (!item)
+item = c->heif_item[i] = av_mallocz(sizeof(*item));
+if (!item)
+return AVERROR(ENOMEM);
+
+item->item_id = item_id;
+
if (offset_type == 1)
-c->heif_item[i].is_idat_relative = 1;
-c->heif_item[i].extent_length = extent_length;
-c->heif_item[i].extent_offset = base_offset + extent_offset;
+item->is_idat_relative = 1;
+item->extent_length = extent_length;
+item->extent_offset = base_offset + extent_offset;
av_log(c->fc, AV_LOG_TRACE, "iloc: item_idx %d, offset_type %d, "
"extent_offset %"PRId64",
extent_length %"PRId64"\n",
- i, offset_type, c->heif_item[i].extent_offset,
c->heif_item[i].extent_length);
-}
+ i, offset_type, item->extent_offset, item->extent_length);
}
c->found_iloc = 1;
@@ -8735,6 +8742,7 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
static int mov_read_infe(MOVContext *c, AVIOContext *pb, MOVAtom atom, int idx)
{
+HEIFItem *item;
AVBPrint item_name;
int64_t size = atom.size;
uint32_t item_type;
@@ -8774,15 +8782,21 @@ static int mov_read_infe(MOVContext *c, AVIOContext
*pb, MOVAtom atom, int idx)
if (size > 0)
avio_skip(pb, size);
+item = c->heif_item[idx];
+if (!item)
+item = c->heif_item[idx] = av_mallocz(sizeof(*item));
+if (!item)
+return AVERROR(ENOMEM);
+
if (ret)
-av_bprint_finalize(&it
Re: [FFmpeg-devel] [PATCH] avcodec/speexdec: fix decoding regressions
Hi On Thu, Nov 07, 2024 at 06:59:36PM -0500, shenleban tongying wrote: > fix ticket #11054 and #11078 > > * reduce false decoding errors > * fix wrong frame_size > > Co-authored-by: Paul B Mahol > Signed-off-by: shenleban tongying > --- > libavcodec/speexdec.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/libavcodec/speexdec.c b/libavcodec/speexdec.c > index d25823ef6e..d48bfca803 100644 > --- a/libavcodec/speexdec.c > +++ b/libavcodec/speexdec.c > @@ -1425,7 +1425,8 @@ static int parse_speex_extradata(AVCodecContext *avctx, > if (s->frame_size < NB_FRAME_SIZE << (s->mode > 0) || > s->frame_size > INT32_MAX >> (s->mode > 0)) > return AVERROR_INVALIDDATA; > -s->frame_size <<= (s->mode > 0); > +s->frame_size <<= (s->mode > 1); > +s->frame_size = FFMIN(640, s->frame_size); > s->vbr = bytestream_get_le32(&buf); > s->frames_per_packet = bytestream_get_le32(&buf); > if (s->frames_per_packet <= 0 || There is something wrong with the whitespace, also git am refuses to apply this automatically: Applying: avcodec/speexdec: fix decoding regressions Using index info to reconstruct a base tree... error: patch failed: libavcodec/speexdec.c:1425 error: libavcodec/speexdec.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. Patch failed at 0001 avcodec/speexdec: fix decoding regressions can you resumbit this without these issues or is there a git repo from where it can be taken (in case you have problems with sending mail) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What is kyc? Its a tool that makes you give out your real ID, while criminals give out a forged ID card. 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] avformat/vpk: fix divide by zero
On Sat, Nov 02, 2024 at 07:22:46AM +0100, Kacper Michajlow wrote:
> On Sat, 2 Nov 2024 at 01:54, Michael Niedermayer
> wrote:
> >
> > Hi
> >
> > On Fri, Nov 01, 2024 at 02:20:33PM +0100, Kacper Michajlow wrote:
> > > On Sat, 10 Aug 2024 at 18:49, Kacper Michajlow wrote:
> > > >
> > > > On Sat, 10 Aug 2024 at 11:25, Andreas Rheinhardt
> > > > wrote:
> > > > >
> > > > > Kacper Michajlow:
> > > > > > On Fri, 9 Aug 2024 at 22:51, Michael Niedermayer
> > > > > > wrote:
> > > > > >>
> > > > > >> On Wed, Aug 07, 2024 at 03:42:46PM +0200, Kacper Michajłow wrote:
> > > > > >>> Can happen after calling avformat_find_stream_info() when the
> > > > > >>> codec
> > > > > >>> fails to open, but return value is 0 and subsequent uses of this
> > > > > >>> context
> > > > > >>> have zero value in channel number.
> > > > > >>>
> > > > > >>> Found by OSS-Fuzz.
> > > > > >>>
> > > > > >>> Signed-off-by: Kacper Michajłow
> > > > > >>> ---
> > > > > >>> libavformat/vpk.c | 2 ++
> > > > > >>> 1 file changed, 2 insertions(+)
> > > > > >>>
> > > > > >>> diff --git a/libavformat/vpk.c b/libavformat/vpk.c
> > > > > >>> index 001ad33555..aa98ef2dd4 100644
> > > > > >>> --- a/libavformat/vpk.c
> > > > > >>> +++ b/libavformat/vpk.c
> > > > > >>> @@ -86,6 +86,8 @@ static int vpk_read_packet(AVFormatContext *s,
> > > > > >>> AVPacket *pkt)
> > > > > >>>
> > > > > >>> vpk->current_block++;
> > > > > >>> if (vpk->current_block == vpk->block_count) {
> > > > > >>> +if (par->ch_layout.nb_channels <= 0)
> > > > > >>> +return AVERROR_INVALIDDATA;
> > > > > >>> unsigned size = vpk->last_block_size /
> > > > > >>> par->ch_layout.nb_channels;
> > > > > >>> unsigned skip = (par->block_align -
> > > > > >>> vpk->last_block_size) / par->ch_layout.nb_channels;
> > > > > >>> uint64_t pos = avio_tell(s->pb);
> > > > > >>
> > > > > >> iam not sure if a parser or other should replace a valid set of
> > > > > >> parameters by an invalid
> > > > > >> (this patch implies that such a action occured)
> > > > > >>
> > > > > >> can you explain more detailedly by what and why channels is set to
> > > > > >> 0 ?
> > > > > >>
> > > > > >
> > > > > > You are right, it might be better to improve this to not override
> > > > > > the
> > > > > > params. Let me explain what happens, I didn't read through the whole
> > > > > > avformat_find_stream_info() to know what would be the best approach
> > > > > > yet. I will try to look at it, but if you have immediate ideas, that
> > > > > > would be nice.
> > > > > >
> > > > > > 1. avformat_open_input() sets nb_channels to 108
> > > > > >
> > > > > > 2. Just after that we call avformat_find_stream_info(avfc, NULL);
> > > > > > this
> > > > > > returns 0 (success), but as a result it overrides params already
> > > > > > present in the context.
> > > > > > log for reference, during the find stream info call
> > > > > > [ffmpeg/demuxer] vpk: Before avformat_find_stream_info() pos:
> > > > > > 538976288 bytes read:21 seeks:1 nb_streams:1
> > > > > > [ffmpeg/demuxer] vpk: Failed to open codec in
> > > > > > avformat_find_stream_info
> > > > > > [lavf] mp_seek(0x51218090, 0, size)
> > > > > > [lavf] 0=mp_read(0x51218090, 0x7fe4c7ce8800, 5000), pos:
> > > > > > 538976288, eof:1
> > > > > > [lavf] 0=mp_read(0x51218090, 0x52d0a400, 32768), pos:
> > > > > > 538976288, eof:1
> > > > > > [ffmpeg/audio] adpcm_psx: Decoder requires channel layout to be set
> > > > > > [ffmpeg/demuxer] vpk: Failed to open codec in
> > > > > > avformat_find_stream_info
> > > > > > [lavf] mp_seek(0x51218090, 0, size)
> > > > > > [lavf] mp_seek(0x51218090, 0, size)
> > > > > > [lavf] mp_seek(0x51218090, 0, size)
> > > > > > [ffmpeg/demuxer] vpk: stream 0: start_time: NOPTS duration: 0.069852
> > > > > > [ffmpeg/demuxer] vpk: format: start_time: NOPTS duration: 0.069852
> > > > > > (estimate from stream) bitrate=2 kb/s
> > > > > > [ffmpeg/demuxer] vpk: Could not find codec parameters for stream 0
> > > > > > (Audio: adpcm_psx, 538976288 Hz, 0 channels): unspecified sample
> > > > > > format
> > > > > > [ffmpeg/demuxer] Consider increasing the value for the
> > > > > > 'analyzeduration' (0) and 'probesize' (500) options
> > > > > > [ffmpeg/demuxer] vpk: After avformat_find_stream_info() pos:
> > > > > > 538976288
> > > > > > bytes read:21 seeks:1 frames:0
> > > > > >
> > > > > > 3. the nb_channels value is cleared in avformat_find_stream_info()
> > > > > > ->
> > > > > > avcodec_parameters_from_context() -> codec_parameters_reset() and
> > > > > > remains 0.
> > > > >
> > > > > This seems like the error: Why is AVCodecParameters being set from an
> > > > > AVCodecContext if the codec could not be successfully opened?
> > > >
> > > > avcodec_open2() is only emitting a warning, no other action taken.
> > > > https://github.com/FFmpeg/FFmpeg/blob/1b8d95da3a4a5c9441238928a36b653da693c286/libavformat/demux.c#L2603-L2605
> > > >
> > > > later "some" thing
Re: [FFmpeg-devel] GSoC Mentor Summit Reimbursement Request
On Wed, Nov 06, 2024 at 02:08:08PM +0100, Thilo Borgmann via ffmpeg-devel wrote: > Hi, > > I also request reimbursement for this years GSoC summit. > > My costs included: > > 903,91 EUR Flight (BER to SFO) > 248,71 EUR Hotel > - > 1152,62 EUR Total > = > > Which is around 1230 USD for me and around 690 USD for Frank and in total > well covered by Google's travel stipend. LGTM, thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] libpostproc splitout
Hi, On Fri, Nov 8, 2024 at 6:56 PM Michael Niedermayer wrote: > On Fri, Nov 08, 2024 at 01:15:41PM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Nov 8, 2024 at 11:45 AM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Fri, Nov 08, 2024 at 11:23:49AM -0500, Ronald S. Bultje wrote: > > > > On Fri, Nov 8, 2024 at 11:17 AM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > > my wish would be that the 15k could be spend on a plugin interface > > > > > for libavfilter. > > > > > [..] > > > > > > Wes from Meta gave a talk about this at VDD2024. > > > > > > is there a recording ? > > > > > > > Dr. Hamacher did make a recording (with a 3d cam, no less). You could ask > > him if he can share the relevant section? See his website: > > https://lab3d.kw.ac.kr/ > > > > > > > do you have a link ? > > > > > > > Wes posted a PDF on the VDD2024 Signal group. > > Does FB / Wes plan to submit this feature to FFmpeg for integration ? > IIRC that question was asked during the Q&A, and he was going to look into that. Ronald ___ 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".
