Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/sanm: clear codec47 diff buffers with specific color

Hello, Ping? On Fri, Nov 8, 2024 at 12:51 PM Manuel Lauss wrote: > > 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

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/sanm: codec47: apply top offset also to diff buffers

Hello, Ping? On Fri, Nov 8, 2024 at 12:51 PM Manuel Lauss wrote: > > 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

[FFmpeg-devel] ID3v2 demuxer

Hi all So after looking at options for how to better deal with ID3v2 I'm leaning towards creating a demuxer for it. I'm writing this before going any further with it to get some feedback A proper demuxer would change things up especially for mp3, since a lot of files that now probe as "mp3" with

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dnxuc_parser: rework DNXUC parser

On Fri, 22 Nov 2024, martin schitter wrote: On 20.11.24 22:03, Marton Balint wrote: The parser's primary job is to packetize a non-packetized stream and maybe get some basic information about the packets which normally the container has. As long as we only support single component va

Re: [FFmpeg-devel] [PATCH] Update MAINTAINERS

On Thu, 21 Nov 2024, Vittorio Giovara wrote: I feel nobody, with some exceptions, really wants to be listed here, and this file is just an artefact that gets cargo culted because it's how things have been run and nothing can ever change in ffmpeg. I disagree. It is useful to know who cares/

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dnxuc_parser: rework DNXUC parser

On 20.11.24 22:03, Marton Balint wrote: The layering issue is for the decoder to take care of, not the parser. Yes, we could handle it in the decoder just like in case of OpenEXR, where we use a special `-layer` option to specify the component/layer to pick out of the input stream. But

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

On Thu, 21 Nov 2024, James Almer wrote: Instead of expecting the DASH muxer manually setting this, just do it here. This is required to write a simple edit list for audio tracks with triming samples, where negative CTS offsets can't be used. Signed-off-by: James Almer --- libavformat/movenc.c

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

On 11/22/2024 5:32 AM, Martin Storsjö wrote: On Thu, 21 Nov 2024, James Almer wrote: Instead of expecting the DASH muxer manually setting this, just do it here. This is required to write a simple edit list for audio tracks with triming samples, where negative CTS offsets can't be used. Signe

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

Derek Buitenhuis (12024-11-22): > I do not accept this warning, and I do not agree with your reasoning. > > The entire point of that thread was paid work, and cost matters. I worded > in an entirelty legitimate way. I do not agree with you on many things, including what you said on the criticised

Re: [FFmpeg-devel] ID3v2 demuxer

On Fri, 22 Nov 2024 10:51:21 +0100 Tomas Härdin wrote: > Hi all > > So after looking at options for how to better deal with ID3v2 I'm > leaning towards creating a demuxer for it. I'm writing this before > going any further with it to get some feedback i remember so many id3v2 vulnerabilities in

Re: [FFmpeg-devel] [RFC] libpostproc splitout

On 11/22/2024 12:59 PM, epira...@gmail.com wrote: > While I might not in principle disagree with the CCs action here, the (at > least perceived) inaction of the CC > in other cases makes this seem the CC has a huge double standard how to deal > with things… > (Or there is a big communication/tran

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

On 11/22/2024 10:04 AM, Martin Storsjö wrote: On Fri, 22 Nov 2024, James Almer wrote: On 11/22/2024 5:32 AM, Martin Storsjö wrote: On Thu, 21 Nov 2024, James Almer wrote: I'm a little reluctant to do this; IIRC the delay_moov flag significantly changes the sequence of what boxes gets output

Re: [FFmpeg-devel] [RFC] libpostproc splitout

Hi, On Fri, Nov 22, 2024 at 7:59 AM wrote: > the (at least perceived) inaction of the CC in other cases makes this seem > the CC has a huge double standard how to deal with things… I think that is a fair criticism - I agree we're generally too slow, actually I think most/all of us agree there.

[FFmpeg-devel] [PATCH] Use AVBufferPool in MOV

Most demuxers allocate a new buffer for each packet. For MOV, this can be problematic, because of some high-bitrate codecs like ProRes/HAPQ/NotchLC. Use pools of buffer instead. For some test media, demuxing goes from 20ms/frame to 11ms/frame, close to the perf of ReadFile (10ms/frame), making it

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

On Fri, Nov 22, 2024 at 03:20:44PM +0100, Anton Khirnov wrote: > Quoting Derek Buitenhuis (2024-11-22 13:38:01) > > I do not accept this warning, and I do not agree with your reasoning. > > > > The entire point of that thread was paid work, and cost matters. I worded > > in an entirelty legitimate

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

Le perjantaina 22. marraskuuta 2024, 14.38.01 EET Derek Buitenhuis a écrit : > I do not accept this warning, and I do not agree with your reasoning. As somebody who participated in that thread and made similar arguments, I find the response utterly ridiculous. What is even supposed to be provocat

Re: [FFmpeg-devel] [PATCH] [RFC] [GA Vote required] Code of Conduct change re step down requests

Le perjantaina 22. marraskuuta 2024, 21.41.02 EET compn a écrit : > Hello, > > as the CoC rules over the GA, then the GA probably has to vote on this > change? i didnt find any process for changing the CoC, so i send this > mail. I kindly ask someone more familiar with the voting system to start >

Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV

On Fri, 22 Nov 2024 18:46:19 +0100 Arnaud Masserann wrote: > Most demuxers allocate a new buffer for each packet. > For MOV, this can be problematic, because of some high-bitrate > codecs like ProRes/HAPQ/NotchLC. > > Use pools of buffer instead. > > For some test media, demuxing goes from 20ms

Re: [FFmpeg-devel] [PATCH] mpegts.c: pat_cb(): ensure all PIDs are valid

On Fri, 15 Nov 2024, Scott Theisen wrote: originally from: https://github.com/MythTV/mythtv/commit/a1d4d112c3f962a85ddd6248592421171fc8331c referencing: https://code.mythtv.org/trac/ticket/1887 ISO/IEC 13818-1:2021 specifies a valid range of [0x0010, 0x1FFE] in § 2.4.4.6 Semantic definition o

[FFmpeg-devel] [PATCH] [RFC] [GA Vote required] Code of Conduct change re step down requests

Hello, as the CoC rules over the GA, then the GA probably has to vote on this change? i didnt find any process for changing the CoC, so i send this mail. I kindly ask someone more familiar with the voting system to start a vote on the vote.ffmpeg.org for this proposed change to the Code of conduct

Re: [FFmpeg-devel] [RFC] libpostproc splitout

Le perjantaina 22. marraskuuta 2024, 15.38.32 EET Michael Niedermayer a écrit : > > I think that is a fair criticism - I agree we're generally too slow, > > actually I think most/all of us agree there. I'd like to improve that. > > "We're working on it." > > +1 > > yes, i do infact think that af

Re: [FFmpeg-devel] [PATCH 1/2] libavformat/mpegts.h: add DVB descriptor_tag values already in use

On Fri, 15 Nov 2024, Scott Theisen wrote: --- libavformat/mpegts.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h index 14ae312c50..729c8b07b9 100644 --- a/libavformat/mpegts.h +++ b/libavformat/mpegts.h @@ -165,6 +165,17 @@ #define

Re: [FFmpeg-devel] Crash in Niagara Workbench Streaming with FFmpeg 7.0.1+ (H.264 Codec) on Initial Attempts

Le perjantaina 22. marraskuuta 2024, 17.07.02 EET Kumar, Rahul via ffmpeg-devel a écrit : > Can you please suggest if any changes between FFmpeg 6.0 and 7.0.1 in the > H.264 codec or JNI integration could cause this behavior? Not specifically. I should not need to mention this, but you are welcom

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

Le perjantaina 22. marraskuuta 2024, 20.45.39 EET Michael Niedermayer a écrit : > How much do you charge to split out libpostproc ? > > Note you _have to_ maintain the code afterwards, Who says that it has to be maintained, how and why? > not just treat it as if split out means deleting it from

Re: [FFmpeg-devel] [PATCH 2/2] libavformat/mpegts: demux DVB VBI data

On Fri, 15 Nov 2024, Scott Theisen wrote: From: ulmus-scott DVB VBI data is defined in ETSI EN 301 775 and can include EBU teletext data as defined in ETSI EN 300 472. ETSI EN 300 468 defines teletext_descriptor, VBI_data_descriptor, and VBI_teletext_descriptor, which has the same definiti

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

On Fri, 22 Nov 2024, James Almer wrote: And if the prime use case in mind is the dash muxer, I don't see why the dash muxer can't keep on passing the delay_moov flag separately? It still does, but back to what you said, users of the mov muxer that use the dash flag as a framented output umbre

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

On Fri, Nov 22, 2024 at 1:45 PM Michael Niedermayer wrote: > > > > > > Hi Derek, > > > > > > On Thu, Nov 7, 2024 at 11:04 AM Derek Buitenhuis < > derek.buitenh...@gmail.com > wrote: > > > > > > This work was very easy and not worth even remotely close to 5K

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: add CC format for user_data 0x05 0x02

LGTM. Will wait a few days for any comments before merging. 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

Re: [FFmpeg-devel] [PATCH] swscale/ppc: disable YUV2RGB AltiVec acceleration

Hi, On Tue, Nov 19, 2024, 00:06 Sean McGovern wrote: > The FATE test 'checkasm-sw_yuv2rgb' currently fails on this platform, > in both little- and big-endian configurations. > > Disable it by default. > Add '-DSWS_USE_ALTIVEC_YUV2RGB' to CPPFLAGS to re-enable it. > --- > libswscale/ppc/yuv2rgb

Re: [FFmpeg-devel] [PATCH] [RFC] [GA Vote required] Code of Conduct change re step down requests

On Fri, Nov 22, 2024 at 09:41:02AM -1000, compn wrote: > Hello, > > as the CoC rules over the GA, then the GA probably has to vote on this > change? i didnt find any process for changing the CoC, so i send this > mail. I kindly ask someone more familiar with the voting system to start > a vote on

Re: [FFmpeg-devel] [PATCH] avfilter/drawtext: fix memory leak when using "reinit" runtime command

A quick way to demonstrate the memleak: ``` ./configure --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libharfbuzz make -j `nproc valgrind --leak-check=full ./ffmpeg -nostdin -y -f lavfi \ -i testsrc=size=640x360:rate=10 -filter_complex \ "[0:v]format=yuv420p,sendcmd=c='0

Re: [FFmpeg-devel] [PATCH 2/2] libavformat/mpegts: demux DVB VBI data

On 11/22/24 16:12, Marton Balint wrote: On Fri, 15 Nov 2024, Scott Theisen wrote: From: ulmus-scott DVB VBI data is defined in ETSI EN 301 775 and can include EBU teletext data as defined in ETSI EN 300 472. ETSI EN 300 468 defines teletext_descriptor, VBI_data_descriptor, and VBI_telete

[FFmpeg-devel] [PATCH] avfilter/drawtext: fix memory leak when using "reinit" runtime command

Free AVOption in drawtext private context when freeing old copy of drawtext private context during processing of "reinit" runtime command. Signed-off-by: Steven Zhou --- libavfilter/vf_drawtext.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawt

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

Hi Remi On Fri, Nov 22, 2024 at 11:04:50PM +0200, Rémi Denis-Courmont wrote: > Le perjantaina 22. marraskuuta 2024, 20.45.39 EET Michael Niedermayer a écrit [...] > > not just treat it as if split out means deleting it from ffmpeg. > > Err, but yes. From the perspective of FFmpeg-devel, once lib

[FFmpeg-devel] [PATCH 1/2] tools/general_assembly: add a mechanism for excluding people from GA list

To be used at their own request, when they do not wish to receive vote emails. --- tools/general_assembly.pl | 9 + 1 file changed, 9 insertions(+) diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl index 0dafa82e27..7e0f46093c 100755 --- a/tools/general_assembly.pl +++ b/

[FFmpeg-devel] [PATCH 2/2] tools/general_assembly: exclude Derek from GA emails

At his own request, he can remove the entry whenever he likes. --- tools/general_assembly.pl | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl index 7e0f46093c..bfcb67d988 100755 --- a/tools/general_assembly.pl +++ b/tools/general_assembly.pl

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: add CC format for user_data 0x05 0x02

> I don't know why this would work > and ccextractor didn't on your samples. I don’t know either, but it’s not working. With this patch it works very well. When I can, will try and write a bug report over there. ___ ffmpeg-devel mailing list ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] [RFC] [GA Vote required] Code of Conduct change re step down requests

On Fri, Nov 22, 2024 at 7:49 PM Michael Niedermayer wrote: > On Fri, Nov 22, 2024 at 09:41:02AM -1000, compn wrote: > > Hello, > > > > as the CoC rules over the GA, then the GA probably has to vote on this > > change? i didnt find any process for changing the CoC, so i send this > > mail. I kindl

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

Le 23 novembre 2024 01:19:12 GMT+02:00, Michael Niedermayer a écrit : >Hi Remi > >On Fri, Nov 22, 2024 at 11:04:50PM +0200, Rémi Denis-Courmont wrote: >> Le perjantaina 22. marraskuuta 2024, 20.45.39 EET Michael Niedermayer a >> écrit >[...] >> > not just treat it as if split out means deleti

Re: [FFmpeg-devel] [RFC] libpostproc splitout

On Fri, Nov 22, 2024 at 8:38 AM Michael Niedermayer wrote: > Hi > > On Fri, Nov 22, 2024 at 08:09:49AM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Nov 22, 2024 at 7:59 AM wrote: > > > > > the (at least perceived) inaction of the CC in other cases makes this > seem > > > the CC has a h

Re: [FFmpeg-devel] [PATCH] Update MAINTAINERS

On Thu, Nov 21, 2024 at 8:00 PM Michael Niedermayer wrote: > On Thu, Nov 21, 2024 at 04:56:09PM -0500, Vittorio Giovara wrote: > > On Wed, Nov 20, 2024 at 8:51 PM Michael Niedermayer < > mich...@niedermayer.cc> > [...] > > > And also the > > > friendly discussions we have recently, i just cant st

Re: [FFmpeg-devel] [PATCH] Update MAINTAINERS

On Fri, Nov 22, 2024 at 6:09 AM Marton Balint wrote: > > > On Thu, 21 Nov 2024, Vittorio Giovara wrote: > > > I feel nobody, with some exceptions, really wants to be listed here, and > > this file is just an artefact that gets cargo culted because it's how > > things have been run and nothing can

Re: [FFmpeg-devel] root access voting

On Thu, Nov 21, 2024 at 6:35 PM compn wrote: > On Thu, 21 Nov 2024 16:49:25 -0500 > Vittorio Giovara wrote: > > > On Thu, Nov 21, 2024 at 3:53 PM compn wrote: > > > > > On Thu, 21 Nov 2024 22:42:58 +0200 > > > Rémi Denis-Courmont wrote: > > > > > > > Le torstaina 21. marraskuuta 2024, 22.34.42

[FFmpeg-devel] [PATCH] MAINTAINERS: list csp.c and csp.h maintainers

Ronald S. Bultje wrote most of the code before there was a refactor and condense (which I mostly wrote). As such, listing both him and myself as maintainers of csp.h and csp.h, which previously had no maintainer listed at all (after conferring on IRC). Signed-off-by: Leo Izen --- MAINTAINERS | 1

Re: [FFmpeg-devel] [RFC] libpostproc splitout

On 22 Nov 2024, at 13:38, Derek Buitenhuis wrote: > I do not accept this warning, and I do not agree with your reasoning. > > The entire point of that thread was paid work, and cost matters. I worded > in an entirelty legitimate way. > > The fact that all the BS that has happened on this list si

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

On Fri, 22 Nov 2024, James Almer wrote: On 11/22/2024 5:32 AM, Martin Storsjö wrote: On Thu, 21 Nov 2024, James Almer wrote: I'm a little reluctant to do this; IIRC the delay_moov flag significantly changes the sequence of what boxes gets output at what time, which affects things for API use

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

Quoting Derek Buitenhuis (2024-11-22 13:38:01) > I do not accept this warning, and I do not agree with your reasoning. > > The entire point of that thread was paid work, and cost matters. I worded > in an entirelty legitimate way. > > The fact that all the BS that has happened on this list since

Re: [FFmpeg-devel] [RFC] libpostproc splitout

Hi On Fri, Nov 22, 2024 at 08:09:49AM -0500, Ronald S. Bultje wrote: > Hi, > > On Fri, Nov 22, 2024 at 7:59 AM wrote: > > > the (at least perceived) inaction of the CC in other cases makes this seem > > the CC has a huge double standard how to deal with things… > > > I think that is a fair cr

Re: [FFmpeg-devel] ID3v2 demuxer

Quoting Tomas Härdin (2024-11-22 10:51:21) > Hi all > > So after looking at options for how to better deal with ID3v2 I'm > leaning towards creating a demuxer for it. I'm writing this before > going any further with it to get some feedback Honestly, not a fan of the idea. Does that imply that eve

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dnxuc_parser: rework DNXUC parser

Quoting Marton Balint (2024-11-19 22:47:31) > The current parser does things which a parser should not, like skipping parts > of the packet header, but it does not actually able to packetize a raw DNXUC > bitstream. > > Rework the parser logic to work similar to other parsers and be able to > corr

Re: [FFmpeg-devel] ID3v2 demuxer

fre 2024-11-22 klockan 15:50 +0100 skrev Anton Khirnov: > Quoting Tomas Härdin (2024-11-22 10:51:21) > > Hi all > > > > So after looking at options for how to better deal with ID3v2 I'm > > leaning towards creating a demuxer for it. I'm writing this before > > going any further with it to get some

[FFmpeg-devel] Fwd: [RFC] libpostproc splitout

I do not accept this warning, and I do not agree with your reasoning. The entire point of that thread was paid work, and cost matters. I worded in an entirelty legitimate way. The fact that all the BS that has happened on this list since and *this* is the result is, for lack of a better work, com

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

On 11/22/2024 12:41 PM, Nicolas George wrote: > I do not agree with you on many things, including what you said on the > criticised mail, but I fully agree with you that this intervention of a > CC member is entirely inappropriate and abusive. There are many things I've said lately that the CC cou

Re: [FFmpeg-devel] [RFC] libpostproc splitout

Ronald S. Bultje (12024-11-22): > Right, and then there's that. Maybe we can start with the inaction bit > (it's easier to address, I think). But I'm open to further process > suggestions. For starters, I would mention that in various judicial proceedings accused have a right to know who is accusi

[FFmpeg-devel] Crash in Niagara Workbench Streaming with FFmpeg 7.0.1+ (H.264 Codec) on Initial Attempts

I am experiencing a crash in Niagara Workbench when streaming video with the H.264 codec. The crash occurs during the first 3-4 attempts to initialize the stream but then stabilizes afterward. This issue started after upgrading FFmpeg from 6.0 to 7.0.1. Updating to 7.1 also did not resolve the i

Re: [FFmpeg-devel] Crash in Niagara Workbench Streaming with FFmpeg 7.0.1+ (H.264 Codec) on Initial Attempts

On 22/11/2024 15:07, Kumar, Rahul via ffmpeg-devel wrote: > I am experiencing a crash in Niagara Workbench when streaming video with the > H.264 codec. The crash occurs during the first 3-4 attempts to initialize the > stream but then stabilizes afterward. This issue started after upgrading > FF

Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV

A few questions: - Should the pools be per-stream (in MOVStreamContext) or per file (in MOVContext) ? - I added an av_get_pooled_packet(AVBufferPool*) function in the avformat API. This might be undesirable. Possible alternatives: - Adding a av_get_pooled_packet(AVBufferPool*[32]) function inst

Re: [FFmpeg-devel] Fwd: [RFC] libpostproc splitout

On Fri, Nov 22, 2024 at 6:19 PM Michael Niedermayer wrote: > Obviously if people do not want it, then it wont happen. It would have been > nice if the people would have spoken up in the last 9 months and not waited > until after work had already started. > It would have been nice that STF funds