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

[Manuel Lauss]

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.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".

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

[Manuel Lauss]

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 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] ID3v2 demuxer

[Tomas Härdin]

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 an mp3 stream and possibly an
mjpeg stream for cover art, would then probe as "id3v2" with the same
kinds of streams

The way my current unfinished prototype works is inspired by concatdec.
It uses a subdemuxer to probe the file, starting after the ID3v2
header. Codecprops are then copied to the id3v2's AVStream for the
audio

A bit more work is necessary to deal with non-seekable files but it
doesn't look insurmountable

I may reorder the streams, so the cover art comes first, because it
comes first in the file and the audio codec can't be had until after
probing, at which point it would be too late to seek back. It could be
possible to create two streams in anticipation of there being cover art
but this is a bit of a pain

Non-seekable support also means holding the cover art in RAM for a
while. This probably isn't a big deal, but it can mean allocating up to
256 MiB. More realistically far less for most files. If discard could
be set before read_header() it would be possible to skip the cover art
entirely. Maybe we can add an option if users are really strapped for
RAM, but I doubt they are

Oh and finally I'm thinking of outputting the cover art once and only
once, regardless of seeks. That way it doesn't have to be kept around
in RAM

/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 2/2] avcodec/dnxuc_parser: rework DNXUC parser

[Marton Balint]

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 variants there isn't much use of 
saving the unmodified `pack` structure, because nearly all contained metadata 
is more or less redundant and also available one layer above in the MXF CDCI 
and RGBA Picture Essence Descriptors.


That's why I just passed along the `sinf`.packet_type and `sdat` frame 
content as the only useful information relevant for further processing. 
That's also enough information to recreate a functional equivalent DNxUC 
`pack` structure later again, if needed.


Nevertheless, I do not have any serious objections against your proposal. It 
simply makes sense for more efficient pass-through.


Actually if you change where the packet starts in the parser, the generic 
demuxing code will likely do a memcpy on the packet data... So the most 
efficient is to not change that... You also have to think not just the 
decoding use case, but re-muxing as well, so the codec having a 
well-defined packet format which works for all cases is important.


I will apply this in 1-2 days then.

Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Marton Balint]

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/knows about some part of 
code/technology, also by the file being in the source tree changes can 
have proper discussions. It is also functions as the list of people having 
commit access.


You might argue what responsibilites and rights a maintainer has other 
than commit rights. But it seems to me you want to avoid that discussion 
by deleting the file entirely.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[martin schitter]

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 I still would prefer a solution, which enables the use of common 
ffmpeg stream selectors to choose/mix/rearrange the available components 
more easily without this kind of format specific workaround.


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 variants there isn't much 
use of saving the unmodified `pack` structure, because nearly all 
contained metadata is more or less redundant and also available one 
layer above in the MXF CDCI and RGBA Picture Essence Descriptors.


That's why I just passed along the `sinf`.packet_type and `sdat` frame 
content as the only useful information relevant for further processing. 
That's also enough information to recreate a functional equivalent DNxUC 
`pack` structure later again, if needed.


Nevertheless, I do not have any serious objections against your 
proposal. It simply makes sense for more efficient pass-through.


I just see the desirable handling of multiple components slightly 
different. The DNxUC pack looks for me more like an embedded container 
which again may contain multiple component streams/tracks nested within 
a more general MXF container structure. From this point of view the 
contained component streams/tracks should be extracted/demuxed earlier.


Honestly I'm rather surprised, that someone still wants to improve 
this DNxUC related code, because I'm personally more in the mood to 
ask for reverting the already merged parts. I simply don't want to 
waste my time on useless fights...


I get it, reaching a consensus is not always possible and the debate can 
be demoralizing. But that is how it is, if you want to contribute to 
open source, you have to accept that. Some patches may get rejected 
today, maybe they will get accepted in a year with no fuss. It happens.


You are right!

Nevertheless, I really have to say, I have hardly seen an open source 
project recently, where contribution is so much time-consuming, slow and 
clumsy...


Regarding DNXUC and the MXF demuxer the main question is not even about 
the DNXUC decoder, but the MXF demuxer, if it should output RAWVIDEO 
codec (where possible) or always DNXUC codec. Deciding on this should 
not delay the inclusion of the DNXUC decoder the way I see it. And in my 
opinion the DNXUC decoder should support everything the format supports 
regardless of what the MXF demuxer does. (A library user might use his 
own demuxer and only the DNXUC decoder from ffmpeg).


On one hand I share the view of those collegians, which argue, that data 
picked from the `sdat` box is nothing else than RAWVIDEO, because it is 
indeed nothing fancy, not compressed, etc. But on the other hand it 
simply needs format specific further processing (e.g. 10/12bit 
unpacking) in most cases and I'm also especially interested in lossless 
and efficient float handling on the GPU, not the simple traditional bit 
depths. Unmodified float data usage and GPU focused data exchange simply 
isn't supported satisfyingly by the current RAWVIDEO handling in ffmpeg.


That's why I try to avoid this RAWVIDEO processing path.

DNxUC isn't a format, which you'll choose as a super inefficient storage 
solution for consumer content or to play directly on screen, but it's a 
useful kind of exchange standard in professional production workflows. 
One of the few options to transfer data between various different 
high-end tools in a lossless and GPU processing friendly manner.


It could enable the utilization of ffmpeg instead of Nuke or similar 
software for batch processing in some cases, where the current float 
handling resp. processing precision and conversion loss of most open 
source solutions is still a strict no-go.


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] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

[Martin Storsjö]

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   |  2 +-
libavformat/tests/movenc.c |  6 +++---
tests/ref/fate/movenc  | 14 +++---
3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7cdec28835..cc67e274e8 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7641,7 +7641,7 @@ static int mov_init(AVFormatContext *s)
  FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;
if (mov->flags & FF_MOV_FLAG_DASH)
mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
-  FF_MOV_FLAG_DEFAULT_BASE_MOOF;
+  FF_MOV_FLAG_DEFAULT_BASE_MOOF | FF_MOV_FLAG_DELAY_MOOV;
if (mov->flags & FF_MOV_FLAG_CMAF)
mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
  FF_MOV_FLAG_DEFAULT_BASE_MOOF | 
FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;


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 users integrating this into segmentation setups. (I presume 
that's why you changed the movenc test case as well?)


That's why I'd like to keep delay_moov an explicit opt-in - even if it 
kinda is necessary to get the timing entirely correct. Users that don't 
need it, and rely on getting the whole moov during avformat_write_header, 
would be broken by this change.


// 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] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

[James Almer]

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.

Signed-off-by: James Almer 
---
libavformat/movenc.c   |  2 +-
libavformat/tests/movenc.c |  6 +++---
tests/ref/fate/movenc  | 14 +++---
3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7cdec28835..cc67e274e8 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7641,7 +7641,7 @@ static int mov_init(AVFormatContext *s)
  FF_MOV_FLAG_FRAGMENT | 
FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;

    if (mov->flags & FF_MOV_FLAG_DASH)
    mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
-  FF_MOV_FLAG_DEFAULT_BASE_MOOF;
+  FF_MOV_FLAG_DEFAULT_BASE_MOOF | 
FF_MOV_FLAG_DELAY_MOOV;

    if (mov->flags & FF_MOV_FLAG_CMAF)
    mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
  FF_MOV_FLAG_DEFAULT_BASE_MOOF | 
FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;


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 users integrating this into 
segmentation setups. (I presume that's why you changed the movenc test 
case as well?)


The changes in md5 hashes there are only the missing dash brand in the 
output, afaict. I removed the dash flag (which is not what the test was 
about anyway) to make sure delay_moov was not included in the test that 
only wanted empty_moov.




That's why I'd like to keep delay_moov an explicit opt-in - even if it 
kinda is necessary to get the timing entirely correct. Users that don't 
need it, and rely on getting the whole moov during 
avformat_write_header, would be broken by this change.


But who uses the mov muxer with the dash movflag on its own instead of 
through the dash muxer, which explicitly enables delay_moov? afaik that 
flag only ensures the brand is added.
Functionality wise it does nothing more than select other flags. Or 
rather, it should only do that, right? And if it does not, whatever code 
looks for it should be changed to look for the fragment flag 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] Fwd: [RFC] libpostproc splitout

[Nicolas George]

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 mail, but I fully agree with you that this intervention of a
CC member is entirely inappropriate and abusive.

Regards,

-- 
  Nicolas George
___
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] ID3v2 demuxer

[compn]

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 so many software projects
over the years.

my suggestion/request is, if you do change id3v2, please
consider extensively security testing it before commit.

thanks
compn
___
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

[Derek Buitenhuis]

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/transparency problem.)

The CC only warns if someone complains to them about a specific email,
and warns in private.

Anyway, as per my email before, I'm re-unsubbing now. My intent was to
not be active on this list, but I got that warning privately in my inbox.

- Derek
___
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 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

[James Almer]

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 at what 
time, which affects things for API users integrating this into 
segmentation setups. (I presume that's why you changed the movenc 
test case as well?)


The changes in md5 hashes there are only the missing dash brand in the 
output, afaict. I removed the dash flag (which is not what the test 
was about anyway) to make sure delay_moov was not included in the test 
that only wanted empty_moov.


Ah, I see.

That's why I'd like to keep delay_moov an explicit opt-in - even if 
it kinda is necessary to get the timing entirely correct. Users that 
don't need it, and rely on getting the whole moov during 
avformat_write_header, would be broken by this change.


But who uses the mov muxer with the dash movflag on its own instead of 
through the dash muxer, which explicitly enables delay_moov? afaik 
that flag only ensures the brand is added.
Functionality wise it does nothing more than select other flags. Or 
rather, it should only do that, right? And if it does not, whatever 
code looks for it should be changed to look for the fragment flag 
instead.


I would expect that many users use it, as an umbrella option for "modern 
fragmented mp4 with all the flavours you need for segmented use". A more 
modern similar umbrella flag would probably be "cmaf" though, but that 
flag was added (much) later.


Yes, it's also possible to explicitly request 
"empty_moov+default_base_moof", but it's not possible to directly set 
the flag corresponding to FF_MOV_FLAG_FRAGMENT (which is "make sure 
we're fragmenting; if the user didn't specify an option for 
fragmentation, pick a default one"). But just picking cmaf or dash as 
umbrella option for these setups is convenient.



Any project doing segmented mp4, by segmenting externally (rather than 
using our muxers), can likely be using this flag - I use it myself in 
this fashion in $dayjob code. Yes I can obviously change that now that 
I'm aware of this change, but I would believe that there are a number of 
other users using it in a similar way - Hyrum's Law etc.


And while we do have our segmenting muxers (dashenc etc), I would expect 
that many of the advanced use cases do the segmenting themselves.


I.e., I was the one to add the dash flag back in the day, and I would be 
surprised by this change, if I hadn't caught it in review.


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 umbrella will not get correct 
timings just with it.


In any case, I'll drop this patch. People can just use +dash+delay_moov.



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] [RFC] libpostproc splitout

[Ronald S. Bultje]

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. I'd like to improve that.
"We're working on it."

(Or there is a big communication/transparency problem.)


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.

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".

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

[Arnaud Masserann]

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 possible
to read the media at 60Hz.

Signed-off-by: Arnaud Masserann 
---
 libavformat/avformat.h | 12 
 libavformat/isom.h |  2 ++
 libavformat/mov.c  | 20 ++--
 libavformat/utils.c| 29 +
 4 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 56c1c80289..25f2e59b22 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -440,6 +440,18 @@ int av_get_packet(AVIOContext *s, AVPacket *pkt, int size);
  */
 int av_append_packet(AVIOContext *s, AVPacket *pkt, int size);
 
+
+/**
+ * Like av_get_packet, but allocates the AVPacket's buffer from a pool.
+ *
+ * @param sassociated IO context
+ * @param pool the pool of buffers; must be initialized with a sufficient size
+ * @param pkt packet
+ * @param size desired payload size
+ * @return >0 (read size) if OK, AVERROR_xxx otherwise
+ */
+int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt, 
int size);
+
 /*/
 /* input/output formats */
 
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 4723397048..c608f30e04 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -273,6 +273,8 @@ typedef struct MOVStreamContext {
 } cenc;
 
 struct IAMFDemuxContext *iamf;
+
+AVBufferPool* pools[32];
 } MOVStreamContext;
 
 typedef struct HEIFItem {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a2333ac1fd..2668bdf78f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -9583,6 +9583,7 @@ static void mov_free_encryption_index(MOVEncryptionIndex 
**index) {
 static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
 {
 MOVStreamContext *sc = st->priv_data;
+int i;
 
 if (!sc || --sc->refcount) {
 st->priv_data = NULL;
@@ -9639,6 +9640,9 @@ static void mov_free_stream_context(AVFormatContext *s, 
AVStream *st)
 ff_iamf_read_deinit(sc->iamf);
 #endif
 av_freep(&sc->iamf);
+
+for (i = 0; i < FF_ARRAY_ELEMS(sc->pools); i++)
+av_buffer_pool_uninit(&sc->pools[i]);
 }
 
 static int mov_read_close(AVFormatContext *s)
@@ -10544,6 +10548,16 @@ static int mov_finalize_packet(AVFormatContext *s, 
AVStream *st, AVIndexEntry *s
 return 0;
 }
 
+static AVBufferPool *mov_pool_get(AVBufferPool* pools[32], int size)
+{
+int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!pools[index]) {
+int pool_size = 2 << index;
+pools[index] = av_buffer_pool_init(pool_size, NULL);
+}
+return pools[index];
+}
+
 static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
 MOVContext *mov = s->priv_data;
@@ -10617,8 +10631,10 @@ static int mov_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 return FFERROR_REDO;
 }
 #endif
-else
-ret = av_get_packet(sc->pb, pkt, sample->size);
+else{
+AVBufferPool* pool = mov_pool_get(sc->pools, sample->size);
+ret = av_get_pooled_packet(sc->pb, pool, pkt, sample->size);
+}
 if (ret < 0) {
 if (should_retry(sc->pb, ret)) {
 mov_current_sample_dec(sc);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index e9ded627ad..869e97c089 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -104,6 +104,35 @@ FF_ENABLE_DEPRECATION_WARNINGS
 return append_packet_chunked(s, pkt, size);
 }
 
+int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt, 
int size)
+{
+#if FF_API_INIT_PACKET
+FF_DISABLE_DEPRECATION_WARNINGS
+av_init_packet(pkt);
+pkt->data = NULL;
+pkt->size = 0;
+FF_ENABLE_DEPRECATION_WARNINGS
+#else
+av_packet_unref(pkt);
+#endif
+pkt->pos  = avio_tell(s);
+
+if(!pool)
+return AVERROR(ENOMEM);
+
+pkt->buf = av_buffer_pool_get(pool);;
+if(!pkt->buf)
+return AVERROR(ENOMEM);
+
+if(pkt->buf->size < size){
+av_packet_unref(pkt); // TODO test this
+return AVERROR(ENOMEM);
+}
+
+return append_packet_chunked(s, pkt, size);
+}
+
+
 int av_append_packet(AVIOContext *s, AVPacket *pkt, int size)
 {
 if (!pkt->size)
-- 
2.38.1.windows.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] Fwd: [RFC] libpostproc splitout

[Michael Niedermayer]

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 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, complete bullshit.
> > 
> > The CC is a lame duck.
> 
> +1
> 
> I naively thought it doesn't get much worse than the previous CC that
> might as well have not existed, but you're plumbing new depths here,
> what with arbitrary selective enforcement and private warnings. Real
> good secret police stuff, congratulations.
> 
> >  Forwarded Message 
> > Subject:Re: [FFmpeg-devel] [RFC] libpostproc splitout
> > Date:   Thu, 21 Nov 2024 15:18:04 -0500
> > From:   Ronald S. Bultje 
> > To: Derek Buitenhuis 
> > CC: c...@ffmpeg.org
> > 
> > 
> > 
> > Hi Derek,
> > 
> > On Thu, Nov 7, 2024 at 11:04 AM Derek Buitenhuis 
> > mailto:derek.buitenh...@gmail.com>> wrote:
> > 
> > This work was very easy and not worth even remotely close to 5K euro.
> 
> I had the exact same thought when looking at that thread, and the only
> reason I did not send it to ML was my being on vacation. So let me
> correct that now:
> 
> Splitting out libpostproc is easy and not worth even remotely close to
> 5K euro.

How much do you charge to split out libpostproc ?

Note you _have to_ maintain the code afterwards, not just treat it as if
split out means deleting it from ffmpeg.

It must in the end include a bugtracker, wiki, packages in distributions,
documentation, self tests and so on and probably alot more needs would come up

also git history must be bisectable, and future changes from ffmpeg buildsystem
must be merged

also look at libpostproc, this code is not upto todays standards.
Iam sure you agree ?

To have libpostproc move forward as an independant (split out) and usefull
project. Its not just copy and pasting code.

This thing needs a new API, it needs a clean internal filter interface
Theres no way or sense in copy and pasting this and then "maintaining" it

I intended to do all the above and likely more for 15k euro.
And i have yet to see someone offer to do this for less. Its easy to
say "its worth less", iam still waiting for the one who actually does
it for less.

again, all the above, for 7k euro, ill pay you from my own money.
wheres the person who does that ? (and yes that includes passing review
and get into git and again maintaining it for the next few years, maintaining
build system, reviewing patches that get submited, fixing security issues,
awnsering developer questions, ...)

I was considering to add some AI based filters into this after all the
above is done.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If one takes all money from those who grow wealth and gives it to those who
do not grow wealth, 10 years later, almost the same people who where wealthy
will be wealthy again, the same people who where poor will be poor again.


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] Fwd: [RFC] libpostproc splitout

[Rémi Denis-Courmont]

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 provocative in 
that response? It is curt, perhaps dismissive - but then again, it is also a 
neutrally expressed opinion backed by actual experience.

I fail to see anything "unnecessarily" provocative. The only part of it which 
is truly unnecessary without losing the meaning is the word "even", which 
hardly makes a difference to the tonality.

If the CC finds it provocative to say that a task is easy or of low financial 
value, then I can only logically infer that the CC is abusing its trust to 
push an agenda which disagrees with not only Derek's opinions but also his 
empirical findings. Marvin already pointed it out, but when you put it in 
perspective, this is blatant double standards and (a vain attempt at) 
censorship.


Now here is a very simple guideline for CC member: if your decision can't 
stand public scrutinity, it is probably not a good decision.

-- 
レミ・デニ-クールモン
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] [RFC] [GA Vote required] Code of Conduct change re step down requests

[Rémi Denis-Courmont]

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
> a vote on the vote.ffmpeg.org for this proposed change to the Code of
> conduct.

So you want people to express themselves even more sarcastically and passive-
aggressively because they can no longer question someone else's suitability or 
responsibility for a position.

Will it be violation of the CoC to send a patch to remove or replace an entry 
in the glorious MAINTAINER file then?

What could possibly go wrong, I wonder. Oh wait, do you want to ban sarcasms 
too?

-- 
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] [PATCH] Use AVBufferPool in MOV

[compn]

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/frame to 11ms/frame,
> close to the perf of ReadFile (10ms/frame), making it possible
> to read the media at 60Hz.

was this tested with all mov samples or just those high bitrate ones ? 

i am wondering if it helps/hurts demuxing the ancient mov samples we
also support. see the nightmares here https://samples.ffmpeg.org/mov/

if hurts, i wonder if buffer pools could be used only for specific high
bitrate codecs in mov demuxer? 

not important just curious. nice job on the speedup!

-compn
___
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] mpegts.c: pat_cb(): ensure all PIDs are valid

[Marton Balint]

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 of fields in program association section
and Table 2-3 – PID table
---
libavformat/mpegts.c | 6 ++
1 file changed, 6 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 78ab7f7efe..6d5dc3050b 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2580,6 +2580,12 @@ static void pat_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
break;

av_log(ts->stream, AV_LOG_TRACE, "sid=0x%x pid=0x%x\n", sid, pmt_pid);
+if (pmt_pid <= 0x000F || pmt_pid >= 0x1FFF)
+{
+av_log(ts->stream, AV_LOG_ERROR, "Invalid PAT ignored "
+   "MPEG Program Number=0x%x pid=0x%x\n", sid, pmt_pid);
+return;
+}


Strictly speaking this is no longer needed, because the crash which is 
fixed by this is already fixed by the check above:


if (pmt_pid == ts->current_pid)
break;

Nevertheless, I am not against a more restrictive check for pids, so 
maybe extending the current check with this:


if (pmt_pid == ts->current_pid || pmt_pid <= 0x000F || pmt_pid >= 0x1FFF)

would be better. If you want to report an error however, maybe you should 
use av_log_once() to not spam the user about the same issue for every 
PAT packet?


Also you might consider using continue instead of return, after all there 
is a specific entry in the PAT which is bogus, maybe we should simply 
ignore only that entry.


Thanks,
Marton




if (sid == 0x) {
/* NIT info */
--
2.43.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 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] [RFC] [GA Vote required] Code of Conduct change re step down requests

[compn]

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.


Reasons for this change:
i am tired of seeing these step down calls for the last 15+ years.
none of these step down calls help anyone.
most people get upset when asked to step down.
new contributors are dissuaded when there are a bunch of people calling
for each others' heads.


Reasons against this change:
"but i really like asking people to step down!"
"the mailing list is more active with more flames!"
"its my last way to be mean on the list, without overtly breaking the
CoC!"
"its not mean to ask someone to step down! its just (insert reason
here)"


shouldnt it already be covered by another rule in the CoC?
specifying it out , and having the GA vote on it, will give the CC more
guidance for easier enforcement and less ambiguity.


thank you for your time.
-compn



diff --git a/doc/community.texi b/doc/community.texi
index 97a49f15ed..1e5e93c227 100644
--- a/doc/community.texi
+++ b/doc/community.texi
@@ -162,6 +162,8 @@ Looking at issues from a different perspective assists 
development.
 Do not assume malice for things that can be attributed to incompetence. Even if
 it is malice, it's rarely good to start with that as initial assumption.

+Do not ask any developer to step down from any position.
+
 Stay friendly even if someone acts contrarily. Everyone has a bad day
 once in a while.
 If you yourself have a bad day or are angry then try to take a break and reply
___
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

[Rémi Denis-Courmont]

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 after now people from almost all sides
> including myself, have critizized the CC (though for different reasons)
> 
> I do belive the CC will improve. It is made of people who ultimately
> want to help and improve the situation.

I don't know who abusively complained about Derek, but the obvious and primary 
beneficiary to silencing his argument in this instance would be you. You are 
also the number one person to object to any attempt at increasing transparency 
for a variety pretexts.

Moreover you have stated multiple times, including very recently, that you 
thought the CC should stop or tune down its actions. In light of all this, I 
am completely unable to believe any words from you regardless willingness or 
intent to improve the referred situation.

To top it all, I don't have much faith in the other CC members doing anything 
about it either. To your credits, unlike you, they have not been very vocal 
about their beliefs.

I don't know why it is so. Maybe CC has decided on unanimity and is always 
blocked. Maybe they don't care. Maybe they are overworked (I know at least one 
them is). Whatever, the CC has lost all my trust, and probably that of many 
other participants.


Looking forward to voting ALL of you out, to be honest.

-- 
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] [PATCH 1/2] libavformat/mpegts.h: add DVB descriptor_tag values already in use

[Marton Balint]

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 METADATA_DESCRIPTOR  0x26
#define METADATA_STD_DESCRIPTOR  0x27

+/* DVB descriptor tag values [0x40, 0x7F] from
+   ETSI EN 300 468 Table 12: Possible locations of descriptors */
+#define SERVICE_DESCRIPTOR   0x48
+#define STREAM_IDENTIFIER_DESCRIPTOR 0x52
+#define TELETEXT_DESCRIPTOR  0x56
+#define SUBTITLING_DESCRIPTOR0x59
+#define AC3_DESCRIPTOR   0x6A // AC-3_descriptor
+#define ENHANCED_AC3_DESCRIPTOR  0x7A // enhanced_AC-3_descriptor
+#define DTS_DESCRIPTOR   0x7B
+#define EXTENSION_DESCRIPTOR 0x7F
+


Thanks, applied with some cosmetic changes.

A patch which replaces the occurances in mpegts/mpegsenc would be nice.

Thanks,
Marton


typedef struct MpegTSContext MpegTSContext;

MpegTSContext *avpriv_mpegts_parse_open(AVFormatContext *s);
--
2.43.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 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] Crash in Niagara Workbench Streaming with FFmpeg 7.0.1+ (H.264 Codec) on Initial Attempts

[Rémi Denis-Courmont]

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 welcome to run 
a bisection to find out.

-- 
雷米‧德尼-库尔蒙
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] Fwd: [RFC] libpostproc splitout

[Rémi Denis-Courmont]

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 ffmpeg.

Err, but yes. From the perspective of FFmpeg-devel, once libpostproc is spun 
off from FFmpeg, then it is no longer maintained by FFmpeg developers. So we 
_must_ treat the hypothesis as a deletion from FFmpeg.

You can argue all you want about the cost of maintainance on libpostproc-
devel. As Vittorio noted, you probably find nobody who actually cares. But even 
if you do, it is no longer a question for FFmpeg-devel.

> It must in the end include a bugtracker, wiki,

If it stays in FFmpeg, then it does not need those things because it gets them 
from FFmpeg. And if it does not stay in FFmpeg, then those are no longer our 
problem.

> packages in distributions,

I think that distributions will gladly remove it if FFmpeg-devel acknowledges 
that it is dead. Even on Debian, it has very few reverse dependencies outside 
of FFmpeg, the usual culprits: Kodi, MEncoder, MPlayer, VLC, Xine. And I don't 
think that it is being used much even then.

> documentation, self tests and so on and probably a lot more needs would come
> up

> also git history must be bisectable, and future changes from ffmpeg
> buildsystem must be merged

WTH? It would take an insane amount of time to rewrite a synthetic bisectable 
history. That would definitely not be worth the effort (or not worth paying 
someone hourly wage for it anyway).

Surely there is more impactful potential use of STF funding.

> also look at libpostproc, this code is not upto todays standards.
> Iam sure you agree ?

Most probably but that's not a problem if we kill it or spin it off.

> This thing needs a new API, it needs a clean internal filter interface
> Theres no way or sense in copy and pasting this and then "maintaining" it

Who needs the thing to have a new API? Sure the API may be old and poorly 
designed but that is not worth fixing _per_se_. It would be worth fixing if it 
caused security issues, real bugs, prevented wanted new features, impeded 
writing new code around it, etc.

With my VLC TC hat on, I don't expect us to have time to rewrite the VLC 
libpostproc plugin considering how little (if any) use it gets. I imagine that 
Kodi is in a similar position, not to speak of the state of the Xine project.

> I intended to do all the above and likely more for 15k euro.
> And i have yet to see someone offer to do this for less. Its easy to
> say "its worth less", iam still waiting for the one who actually does
> it for less.

Didn't Kieran, I and a few other warn you against using FFmpeg-devel for 
making decisions on usage of STF funding? Can't say you weren't warned. Once 
again, you can't have it both ways.

You can choose to eat your words, ignore all the motivated opposition here, 
and take STF funding without the FFmepg community acquiescing. Or you live 
with the consequences of your own decisions and do not fund libpostproc, - 
because clearly nobody other than you cares about it.

-- 
雷米‧德尼-库尔蒙
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 2/2] libavformat/mpegts: demux DVB VBI data

[Marton Balint]

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 definition as, but different use
from, teletext_descriptor.


Hmm, adding a new codec for VBI data might be OK, but I am not sure if 
there is a better way to automagically let the framework know if there are 
teletext compatible VBI packets, so the teletext decoder can be used. Or 
maybe we should simply set the codec id to DVB_TELETEXT if there is a 
VBI_TELETEXT_DESCRIPTOR, and make the teletext decoder parse all data 
units in search for a comptaible data unit id?


Because if we set the codec to VBI for VBI_TELETEXT cases, won't this 
break the automatic probing of unknown codecs? (which otherwise might 
recognize the stream as teletext)? So maybe for VBI_TELETEXT_DESCRIPTOR 
case we should keep the coded id NONE and rely entirely on probing?



Thanks,
Marton


---
libavcodec/codec_desc.c | 6 ++
libavcodec/codec_id.h   | 1 +
libavformat/mpegts.c| 3 +++
libavformat/mpegts.h| 2 ++
4 files changed, 12 insertions(+)

diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index aeac75a6c5..63dbc3f155 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3720,6 +3720,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
.name  = "lcevc",
.long_name = NULL_IF_CONFIG_SMALL("LCEVC (Low Complexity Enhancement Video 
Coding) / MPEG-5 LCEVC / MPEG-5 part 2"),
},
+{
+.id= AV_CODEC_ID_DVB_VBI,
+.type  = AVMEDIA_TYPE_DATA,
+.name  = "dvb_vbi",
+.long_name = NULL_IF_CONFIG_SMALL("DVB VBI data"),
+},
{
.id= AV_CODEC_ID_MPEG2TS,
.type  = AVMEDIA_TYPE_DATA,
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 6bfaa02601..e7e984379c 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -596,6 +596,7 @@ enum AVCodecID {
AV_CODEC_ID_BIN_DATA,
AV_CODEC_ID_SMPTE_2038,
AV_CODEC_ID_LCEVC,
+AV_CODEC_ID_DVB_VBI,


AV_CODEC_ID_PROBE = 0x19000, ///< codec_id is not known (like 
AV_CODEC_ID_NONE) but lavf should attempt to identify it
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 78ab7f7efe..07b5ba996d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -890,6 +890,8 @@ static const StreamType DESC_types[] = {
{ 0x6a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_AC3  }, /* AC-3 
descriptor */
{ 0x7a, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_EAC3 }, /* E-AC-3 
descriptor */
{ 0x7b, AVMEDIA_TYPE_AUDIO,AV_CODEC_ID_DTS  },
+{ 0x45, AVMEDIA_TYPE_DATA, AV_CODEC_ID_DVB_VBI  }, /* 
VBI_DATA_DESCRIPTOR */
+{ 0x46, AVMEDIA_TYPE_DATA, AV_CODEC_ID_DVB_VBI  }, /* 
VBI_TELETEXT_DESCRIPTOR */
{ 0x56, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_TELETEXT },
{ 0x59, AVMEDIA_TYPE_SUBTITLE, AV_CODEC_ID_DVB_SUBTITLE }, /* subtitling 
descriptor */
{ 0 },
@@ -1887,6 +1889,7 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
}
}
break;
+case VBI_TELETEXT_DESCRIPTOR:
case 0x56: /* DVB teletext descriptor */
{
uint8_t *extradata = NULL;
diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index 729c8b07b9..d1fc4210ae 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -167,6 +167,8 @@

/* DVB descriptor tag values [0x40, 0x7F] from
   ETSI EN 300 468 Table 12: Possible locations of descriptors */
+#define VBI_DATA_DESCRIPTOR  0x45
+#define VBI_TELETEXT_DESCRIPTOR  0x46
#define SERVICE_DESCRIPTOR   0x48
#define STREAM_IDENTIFIER_DESCRIPTOR 0x52
#define TELETEXT_DESCRIPTOR  0x56
--
2.43.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 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 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

[Martin Storsjö]

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 umbrella will not get correct timings just 
with it.


Indeed, if you use this configuration, you can't handle cases that require 
the start times of tracks to be adjusted - that either requires delay_moov 
(which disrupts how the muxer is used via the API) or negative_cts_offsets 
as in the cmaf umbrella.



In any case, I'll drop this patch. People can just use +dash+delay_moov.


Ok, thanks!

// 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] Fwd: [RFC] libpostproc splitout

[Vittorio Giovara]

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
> euro.
> >
> > I had the exact same thought when looking at that thread, and the only
> > reason I did not send it to ML was my being on vacation. So let me
> > correct that now:
> >
> > Splitting out libpostproc is easy and not worth even remotely close to
> > 5K euro.
>
> How much do you charge to split out libpostproc ?
>

$0 because it's already done: https://github.com/dwbuiten/postproc
If you want, I'll tip you a ko-fi for merging the commit :)

Note you _have to_ maintain the code afterwards, not just treat it as if
> split out means deleting it from ffmpeg.
>

There is not a single voice in the community (except maybe yours) saying
that they want to maintain this library.
Hence it's not needed within this community - if people want to send
patches and apply all the fixes the repo URL is above


> I was considering to add some AI based filters into this after all the
> above is done.
>

Is this before or after you work on libsre, ffv1, snow, sonicaudio, and a
bunch of other tasks you're following? There is a limited number of hours
in the day you know! Holding the project hostage because you'd like to hack
on whatever you fancy or whatever you find funding for is not proper IN MY
OPINION.
-- 
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] libavcodec/mpeg12dec.c: add CC format for user_data 0x05 0x02

[Marth64]

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 subject "unsubscribe".

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

[Sean McGovern]

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_altivec.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libswscale/ppc/yuv2rgb_altivec.c
> b/libswscale/ppc/yuv2rgb_altivec.c
> index 9db305f43f..d42b39488e 100644
> --- a/libswscale/ppc/yuv2rgb_altivec.c
> +++ b/libswscale/ppc/yuv2rgb_altivec.c
> @@ -558,6 +558,7 @@ av_cold SwsFunc ff_yuv2rgb_init_ppc(SwsInternal *c)
>  if ((c->srcH & 0x1) != 0)
>  return NULL;
>
> +#ifdef SWS_USE_ALTIVEC_YUV2RGB
>  switch (c->dstFormat) {
>  case AV_PIX_FMT_RGB24:
>  av_log(c, AV_LOG_WARNING, "ALTIVEC: Color Space RGB24\n");
> @@ -579,6 +580,7 @@ av_cold SwsFunc ff_yuv2rgb_init_ppc(SwsInternal *c)
>  return altivec_yuv2_bgra;
>  default: return NULL;
>  }
> +#endif /* SWS_USE_ALTIVEC_YUV2RGB */
>  break;
>
>  case AV_PIX_FMT_UYVY422:
> --
> 2.39.5
>

Ping.

Also I have not checked but does this need to be rebased over-top of Nik
Haas' recent swscale changes?
(Yes, this is a thinly veiled wish we had a CI application that would just
tell me this outright on a merge request.)

-- Sean McGovern

>
___
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] [RFC] [GA Vote required] Code of Conduct change re step down requests

[Michael Niedermayer]

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 the vote.ffmpeg.org for this proposed change to the Code of
> conduct.
> 
> 
> Reasons for this change:
> i am tired of seeing these step down calls for the last 15+ years.
> none of these step down calls help anyone.
> most people get upset when asked to step down.
> new contributors are dissuaded when there are a bunch of people calling
> for each others' heads.
> 
> 
> Reasons against this change:
> "but i really like asking people to step down!"
> "the mailing list is more active with more flames!"
> "its my last way to be mean on the list, without overtly breaking the
> CoC!"
> "its not mean to ask someone to step down! its just (insert reason
> here)"
> 
> 
> shouldnt it already be covered by another rule in the CoC?
> specifying it out , and having the GA vote on it, will give the CC more
> guidance for easier enforcement and less ambiguity.
> 
> 
> thank you for your time.
> -compn
> 
> 
> 
> diff --git a/doc/community.texi b/doc/community.texi
> index 97a49f15ed..1e5e93c227 100644
> --- a/doc/community.texi
> +++ b/doc/community.texi
> @@ -162,6 +162,8 @@ Looking at issues from a different perspective assists 
> development.
>  Do not assume malice for things that can be attributed to incompetence. Even 
> if
>  it is malice, it's rarely good to start with that as initial assumption.
> 
> +Do not ask any developer to step down from any position.
> +

i would add these:

Stay On-Topic: Ensure your messages relate to software development or the 
specific purpose of the mailing list. Avoid unrelated discussions.

Be Respectful: Treat all members with courtesy and respect. Personal attacks, 
insults, or harassment of any kind are not tolerated.

Avoid Provocation: Refrain from posting inflammatory, controversial, or 
intentionally provocative messages. Focus on constructive discussions.

No Trolling: Messages intended to provoke an emotional response or disrupt the 
discussion are prohibited.

Professional Language: Use clear, professional, and inclusive language. Avoid 
offensive or derogatory remarks, even in jest.

Constructive Criticism Only: Offer feedback in a constructive and 
solution-oriented manner. Criticize ideas, not people.

Handle Disagreements Professionally: Disagreements are normal but should be 
handled respectfully. Assume good intentions and avoid escalating conflicts.

Report Issues: If you encounter behavior that violates these rules, report it 
to the list moderators rather than engaging directly.

Moderators’ Authority: Moderators have the final say on rule enforcement. 
Non-compliance may result in warnings, moderated posts, or removal from the 
list.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Steven Zhou]

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.5 drawtext reinit 
\\\'text=five\\\'',drawtext=text=zero:\
x=(w-text_w)/2:y=(h-text_h)/2:fontsize=30:fontcolor=white@0.8[vout]" \
-map "[vout]" -t 1 output.y4m
```
-StevenZ

___
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] libavformat/mpegts: demux DVB VBI data

[Scott Theisen]

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_teletext_descriptor, which has the same definition as, but 
different use

from, teletext_descriptor.


Hmm, adding a new codec for VBI data might be OK, but I am not sure if 
there is a better way to automagically let the framework know if there 
are teletext compatible VBI packets, so the teletext decoder can be used. 


Would another AVCodecID AV_CODEC_ID_DVB_VBI_WITH_TELETEXT that would use 
the teletext decoder work?  Would this be AVMEDIA_TYPE_SUBTITLE even 
though it also includes data?  (Also, what teletext decoder?)


Or maybe we should simply set the codec id to DVB_TELETEXT if there is 
a VBI_TELETEXT_DESCRIPTOR, and make the teletext decoder parse all 
data units in search for a comptaible data unit id?




That would work only if you don't want to use any of the other VBI data, 
which is what MythTV currently does, ignoring packets where 
data_identifier is not EBU data and data_field()s where data_unit_id is 
not EBU teletext data as defined in ETSI EN 300 472.


My main concern is if someone wants to decode the other types of VBI 
data how would they do that, or know to try, if it claims it is just EBU 
teletext data?


Because if we set the codec to VBI for VBI_TELETEXT cases, won't this 
break the automatic probing of unknown codecs? (which otherwise might 
recognize the stream as teletext)? So maybe for 
VBI_TELETEXT_DESCRIPTOR case we should keep the coded id NONE and rely 
entirely on probing?


I have no idea how this would interact with the automatic probing.

Regards,

Scott Theisen
___
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] avfilter/drawtext: fix memory leak when using "reinit" runtime command

[Steven Zhou]

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_drawtext.c
index 8de24625d6..038646b112 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1226,6 +1226,7 @@ static int command(AVFilterContext *ctx, const char *cmd, 
const char *arg, char
 
 ctx->priv = old;
 uninit(ctx);
+av_opt_free(old);
 av_freep(&old);
 
 ctx->priv = new;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

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 libpostproc is spun 
> off from FFmpeg, then it is no longer maintained by FFmpeg developers. So we 
> _must_ treat the hypothesis as a deletion from FFmpeg.

If libpostproc is split off i would work on libpostproc.
And i will ensure that the development environment there will be free of these
kind of debates. Meaning i and others can do several times more usefull work.
Also libpostproc is GPL and compatible with a wide range of GPL filters
that could then be provided through a new libpostproc interface


[...]
> > also git history must be bisectable, and future changes from ffmpeg
> > buildsystem must be merged
>
> WTH? It would take an insane amount of time to rewrite a synthetic bisectable
> history. That would definitely not be worth the effort (or not worth paying
> someone hourly wage for it anyway).

so now its an insane amount of time ?
before its not worth 5k

and yes, my split out code is fully bisectable and mergeble, in fact
that part of the work was not hard.


>
> Surely there is more impactful potential use of STF funding.

in the unlikey case that STF will accept FFmpeg in the future
after all these debates.
Then you can suggest these for STF 2025 (which thilo wanted to post
about already, but then he saw all the hostilities ...) And frankly
it cannot be expected from someone to subject themselfs to this.


[...]

>
> > I intended to do all the above and likely more for 15k euro.
> > And i have yet to see someone offer to do this for less. Its easy to
> > say "its worth less", iam still waiting for the one who actually does
> > it for less.
>
> Didn't Kieran, I and a few other warn you against using FFmpeg-devel for
> making decisions on usage of STF funding? Can't say you weren't warned. Once
> again, you can't have it both ways.

What problem do you speak about ?
I see no problem, I see ~4 people of several thousand subscribers who are
aggressive in the last years. thats like 0.2%

This does not seem to be an unsolveable problem to me.


>
> You can choose to eat your words, ignore all the motivated opposition here,
> and take STF funding without the FFmepg community acquiescing. Or you live
> with the consequences of your own decisions and do not fund libpostproc, -
> because clearly nobody other than you cares about it.

I already instructed SPI several days ago to donate the 5k to FFmpeg-SPI,
as i also said already.

The FFmepg community did in the past want libpostproc split out. Thats
what the people at the time who spoke up wanted. Now some people
think its a bad idea, and some people argue about the cost or what exactly
should be done.

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.

The parts i already did, i donate all the 5k as i said.
For the parts that where not done yet, iam still investigating what options
there are.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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 1/2] tools/general_assembly: add a mechanism for excluding people from GA list

[Anton Khirnov]

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/tools/general_assembly.pl
@@ -25,6 +25,10 @@ my @extra_members = (
 ['Shiyou Yin',  'yinshiyou...@loongson.cn', DateTime->new(year 
=> 2023, month => 11, day => 28)],
 );
 
+# list of names of people who asked to be excluded from GA emails
+my %excluded_members = (
+);
+
 sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
 
 sub print_help {
@@ -103,6 +107,11 @@ foreach my $line (@shortlog) {
 }
 
 $name = trim $name;
+
+if (exists $excluded_members{$name}) {
+next;
+}
+
 if ($count < 50) {
 my $true = 0;
 my @commits = split /(^|\n)commit [a-z0-9]{40}(\n|$)/,
-- 
2.43.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] tools/general_assembly: exclude Derek from GA emails

[Anton Khirnov]

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
@@ -27,6 +27,7 @@ my @extra_members = (
 
 # list of names of people who asked to be excluded from GA emails
 my %excluded_members = (
+'Derek Buitenhuis' => 0,
 );
 
 sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Marth64]

> 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@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] [RFC] [GA Vote required] Code of Conduct change re step down requests

[Vittorio Giovara]

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 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.
> >
> >
> > Reasons for this change:
> > i am tired of seeing these step down calls for the last 15+ years.
> > none of these step down calls help anyone.
> > most people get upset when asked to step down.
> > new contributors are dissuaded when there are a bunch of people calling
> > for each others' heads.
> >
> >
> > Reasons against this change:
> > "but i really like asking people to step down!"
> > "the mailing list is more active with more flames!"
> > "its my last way to be mean on the list, without overtly breaking the
> > CoC!"
> > "its not mean to ask someone to step down! its just (insert reason
> > here)"
> >
> >
> > shouldnt it already be covered by another rule in the CoC?
> > specifying it out , and having the GA vote on it, will give the CC more
> > guidance for easier enforcement and less ambiguity.
> >
> >
> > thank you for your time.
> > -compn
> >
> >
> >
> > diff --git a/doc/community.texi b/doc/community.texi
> > index 97a49f15ed..1e5e93c227 100644
> > --- a/doc/community.texi
> > +++ b/doc/community.texi
> > @@ -162,6 +162,8 @@ Looking at issues from a different perspective
> assists development.
> >  Do not assume malice for things that can be attributed to incompetence.
> Even if
> >  it is malice, it's rarely good to start with that as initial assumption.
> >
> > +Do not ask any developer to step down from any position.
> > +
>
> i would add these:
>
> Stay On-Topic: Ensure your messages relate to software development or the
> specific purpose of the mailing list. Avoid unrelated discussions.
>
> Be Respectful: Treat all members with courtesy and respect. Personal
> attacks, insults, or harassment of any kind are not tolerated.
>
> Avoid Provocation: Refrain from posting inflammatory, controversial, or
> intentionally provocative messages. Focus on constructive discussions.
>
> No Trolling: Messages intended to provoke an emotional response or disrupt
> the discussion are prohibited.
>
> Professional Language: Use clear, professional, and inclusive language.
> Avoid offensive or derogatory remarks, even in jest.
>
> Constructive Criticism Only: Offer feedback in a constructive and
> solution-oriented manner. Criticize ideas, not people.
>
> Handle Disagreements Professionally: Disagreements are normal but should
> be handled respectfully. Assume good intentions and avoid escalating
> conflicts.
>
> Report Issues: If you encounter behavior that violates these rules, report
> it to the list moderators rather than engaging directly.
>
> Moderators’ Authority: Moderators have the final say on rule enforcement.
> Non-compliance may result in warnings, moderated posts, or removal from the
> list.
>

Hey Micheal,

Instead of flooding the CoC with a series of ad-personam rules that will
grant immunity to you and stifle any voice of dissent, can you answer
whether you're a professional admin or not? Ignoring the question will only
make your optics worse.

Last I heard, you stepped down already
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176489.html, why are
you still behaving as project lead?

Deciding what information on the infra is public or not, keeping the
MAINTAINERS file around, adding duties to the role, deciding the funding
amounts of the projects you're working on 1h before submission, and so on,
all seem to make you the de-facto leader, ***in my opinion***.

Did something or someone made you change your mind?
Cheers
-- 
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] Fwd: [RFC] libpostproc splitout

[Rémi Denis-Courmont]

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 deleting it from ffmpeg.
>> 
>> Err, but yes. From the perspective of FFmpeg-devel, once libpostproc is spun 
>> off from FFmpeg, then it is no longer maintained by FFmpeg developers. So we 
>> _must_ treat the hypothesis as a deletion from FFmpeg.
>
>If libpostproc is split off i would work on libpostproc.
>And i will ensure that the development environment there will be free of these
>kind of debates. Meaning i and others can do several times more usefull work.
>Also libpostproc is GPL and compatible with a wide range of GPL filters
>that could then be provided through a new libpostproc interface
>
>
>[...]
>> > also git history must be bisectable, and future changes from ffmpeg
>> > buildsystem must be merged
>>
>> WTH? It would take an insane amount of time to rewrite a synthetic bisectable
>> history. That would definitely not be worth the effort (or not worth paying
>> someone hourly wage for it anyway).
>
>so now its an insane amount of time ?

No.

Preserving history is a five-minute job with git-subtree or similar, and worth 
a few €. Rewriting it to be susceptible to bisection is months of useless busy 
work that is NOT worth the time spent.

An expert with your skills has much more useful and valuable contributions to 
make than rewrite git history.

>before its not worth 5k
>
>and yes, my split out code is fully bisectable and mergeble, in fact
>that part of the work was not hard.

Rewriting history makes zero economical sense, especially for a project that 
sees so little usage.

>The FFmepg community did in the past want libpostproc split out.

Nobody objected to that.

We are objecting to your quote for it, in light of an existing implementation 
and competitive quote from Derek of 0€.

> Thats
>what the people at the time who spoke up wanted. Now some people
>think its a bad idea, and some people argue about the cost or what exactly
>should be done.

You don't need to tell me that. You're the one taking the task hostage by 
insisting that it be done by you on your terms.


___
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

[Vittorio Giovara]

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 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. I'd like to improve that.
> > "We're working on it."
>
> +1
>
> yes, i do infact think that after now people from almost all sides
> including myself, have critizized the CC (though for different reasons)
>
> I do belive the CC will improve. It is made of people who ultimately
> want to help and improve the situation.
>

If you really believed what you're saying, you would step down from the CC.
I have no proof you reported both Derek and me, but let's just say
suspicions are high.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Vittorio Giovara]

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 stop enjoying
> > > discussing with so many nice developers as we have recently active
> > > here.
> > >
> >
> > I don't know if you're being sarcastic or not,
>
> It appears then, that you must be aware that the discussions are quite
> "unfriendly". And that i cannot possibly be enjoying that.
>

You skipped the entire thread and replied to this point only.
But I thought mailing list was the only and best way to communicate and
organize software development.
And I'm sorry you're not enjoying this, it's what happens when people
disagree and voice their dissent with the establishment.
Maybe work to find an actual middle ground and change the status quo
instead of spreading the same story over 10 threads?


> Also as most people probably prefer many of these discussions to end
> I think thats what we should do, end them.
>

That's cool, step down from the CC, release the name of all the infra, give
full control to the GA, TC, and CC, and let's move to github/gitlab/gitea.
Then discussions will stop. Hope it's clear enough.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Vittorio Giovara]

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 ever change in ffmpeg.
>
> I disagree. It is useful to know who cares/knows about some part of
> code/technology, also by the file being in the source tree changes can
> have proper discussions. It is also functions as the list of people having
> commit access.
>
> You might argue what responsibilites and rights a maintainer has other
> than commit rights. But it seems to me you want to avoid that discussion
> by deleting the file entirely.
>

Deleting the file was a bit a of a move to catch the attention, I agree
that it can be informative to have a list of (active) people with their
area of expertise, but I don't think a random file continuously to be
updated and with ever changing rules being attached to role is the way to
go forward.
-- 
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] root access voting

[Vittorio Giovara]

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 EET compn a écrit :
> > > > > > Why does Michael need to ask the profession of an immediate
> > > colleague of
> > > > > > his? How can he claim that the answer (or lack therof) is a
> "red
> > > flag"
> > > > > > when he knows the answer full well on account of working for the
> very
> > > > > > same small business?
> > > > > michael works at fflabs, michael knows josh works at fflabs. i
> think
> > > > > we've successfully established this fact. good job everyone!
> > > >
> > > > Yes. Josh and Michael have the same employer and the same job, that
> > > being
> > > > contract FFmpeg software developer (whatever their official JD may
> be).
> > > >
> > > > Do you still not perceive the blatant paradox here? Let me spell it
> out:
> > > >
> > > > If that is indeed such red a flag, then Michael can't continue to
> be
> > > admin.
> > > > If it is not such red a flag afterall, then Josh's rejection is
> purely
> > > > pretextual (supporting Derek's "conspiracy theory").
> > > >
> > >
> > >
> > > michael is asking about josh's previous to fflabs jobs.
> > >
> > > i think?
> > >
> >
> > Why are you talking on behalf of Micheal?
>
> you can see remi quoted derek's mail as a conspiracy. my goal is to
> make messages between developers clear on intent and meaning, and to
> reduce flaming by having a common understanding of the english language.
> we may all speak english, but we were taught and use english in
> different ways. this obviously leads to miscommunications. especially
> because the rules we all use to make assumptions and inferring are
> different.
>

To be fair, the thread was pretty clear before you started messaging. And
then retracted some of your messages. And then started replying on behalf
of Micheal. --- in my opinion ---


> > He can answer these questions
> > himself,
>
> yes.
>
> > given that mailing lists are the best form of communication for a
> > software project.
>
> is this sarcasm? /s
>

Adding a /s at the end does not help or improve the clarity of your message.
I was referring to the fact that some people are dead set on using ML only,
and I am pointing out all the shortcomings of this media and fallacies of
that reasoning.


> one developer swore that they didnt have a conversation with me
> at vdd, and its only been two weeks ago. three developers said i
> misrepresented what was said at vdd. i wouldve preferred a recorded
> medium if i knew peoples' memories would be this awful to deal with.
>

That's not really what happened but given we're in a post truth world,
let's just drop it


> less rushing to judgment and more coding would be better for everyone.
>

I agree, be a good example and go do that :)
-- 
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".

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

[Leo Izen]

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 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a1883c48c..6fbd5b4665 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -82,6 +82,7 @@ Other:
   aes_ctr.c, aes_ctr.h  Eran Kornblau
   bprintNicolas George
   bswap.h
+  csp.c, csp.h  Leo Izen, Ronald S. Bultje
   des   Reimar Doeffinger
   dynarray.hNicolas George
   eval.c, eval.h[2] Michael Niedermayer
-- 
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".

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

[epirat07]

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 since and *this*
> is the result is, for lack of a better work, complete bullshit.
>
> The CC is a lame duck.
>
> - Derek
>
>
>  Forwarded Message 
> Subject:  Re: [FFmpeg-devel] [RFC] libpostproc splitout
> Date: Thu, 21 Nov 2024 15:18:04 -0500
> From: Ronald S. Bultje 
> To:   Derek Buitenhuis 
> CC:   c...@ffmpeg.org
>
>
>
> Hi Derek,
>
> On Thu, Nov 7, 2024 at 11:04 AM Derek Buitenhuis  > wrote:
>
> This work was very easy and not worth even remotely close to 5K euro.
>
>
> This comment ("This work is not worth XYZ") was unnecessarily provocative. 
> Please consider stating something as subjective as this as an opinion instead 
> of an assertion - like you did further on in this thread.
>
> Thank you,
> the CC [Steven, James, JB, Ronald - with Michael abstaining & not 
> participating]

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/transparency problem.)

> ___
> 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 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

[Martin Storsjö]

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 users integrating this into segmentation setups. (I presume 
that's why you changed the movenc test case as well?)


The changes in md5 hashes there are only the missing dash brand in the 
output, afaict. I removed the dash flag (which is not what the test was about 
anyway) to make sure delay_moov was not included in the test that only wanted 
empty_moov.


Ah, I see.

That's why I'd like to keep delay_moov an explicit opt-in - even if it 
kinda is necessary to get the timing entirely correct. Users that don't 
need it, and rely on getting the whole moov during avformat_write_header, 
would be broken by this change.


But who uses the mov muxer with the dash movflag on its own instead of 
through the dash muxer, which explicitly enables delay_moov? afaik that flag 
only ensures the brand is added.
Functionality wise it does nothing more than select other flags. Or rather, 
it should only do that, right? And if it does not, whatever code looks for it 
should be changed to look for the fragment flag instead.


I would expect that many users use it, as an umbrella option for "modern 
fragmented mp4 with all the flavours you need for segmented use". A more 
modern similar umbrella flag would probably be "cmaf" though, but that 
flag was added (much) later.


Yes, it's also possible to explicitly request 
"empty_moov+default_base_moof", but it's not possible to directly set the 
flag corresponding to FF_MOV_FLAG_FRAGMENT (which is "make sure we're 
fragmenting; if the user didn't specify an option for fragmentation, pick 
a default one"). But just picking cmaf or dash as umbrella option for 
these setups is convenient.



Any project doing segmented mp4, by segmenting externally (rather than 
using our muxers), can likely be using this flag - I use it myself in this 
fashion in $dayjob code. Yes I can obviously change that now that I'm 
aware of this change, but I would believe that there are a number of other 
users using it in a similar way - Hyrum's Law etc.


And while we do have our segmenting muxers (dashenc etc), I would expect 
that many of the advanced use cases do the segmenting themselves.


I.e., I was the one to add the dash flag back in the day, and I would be 
surprised by this change, if I hadn't caught it in review.


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?


// 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] Fwd: [RFC] libpostproc splitout

[Anton Khirnov]

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 and *this*
> is the result is, for lack of a better work, complete bullshit.
> 
> The CC is a lame duck.

+1

I naively thought it doesn't get much worse than the previous CC that
might as well have not existed, but you're plumbing new depths here,
what with arbitrary selective enforcement and private warnings. Real
good secret police stuff, congratulations.

>  Forwarded Message 
> Subject:  Re: [FFmpeg-devel] [RFC] libpostproc splitout
> Date: Thu, 21 Nov 2024 15:18:04 -0500
> From: Ronald S. Bultje 
> To:   Derek Buitenhuis 
> CC:   c...@ffmpeg.org
> 
> 
> 
> Hi Derek,
> 
> On Thu, Nov 7, 2024 at 11:04 AM Derek Buitenhuis  > wrote:
> 
> This work was very easy and not worth even remotely close to 5K euro.

I had the exact same thought when looking at that thread, and the only
reason I did not send it to ML was my being on vacation. So let me
correct that now:

Splitting out libpostproc is easy and not worth even remotely close to
5K euro.

-- 
Anton Khirnov
___
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

[Michael Niedermayer]

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 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 after now people from almost all sides
including myself, have critizized the CC (though for different reasons)

I do belive the CC will improve. It is made of people who ultimately
want to help and improve the situation.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] ID3v2 demuxer

[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 feedback

Honestly, not a fan of the idea. Does that imply that every file that
happens to contain an id3v2 header would now probe as id3v2 and not the
actual format? That would be HIGHLY confusing and probably break a lot
of assumptions our callers are making.

Also what I don't see in your email is any mention of what would this
improve for our callers.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

[Anton Khirnov]

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
> correctly packetize raw DNXUC bitstreams.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/dnxuc_parser.c | 122 ++
>  1 file changed, 44 insertions(+), 78 deletions(-)

Strictly speaking this is an API break as it changes the semantics of
the codec ID. I suppose it's not a problem in practice as nobody is
likely to be using it, but it probably deserves at least a minor bump.

-- 
Anton Khirnov
___
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] ID3v2 demuxer

[Tomas Härdin]

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 feedback
> 
> Honestly, not a fan of the idea. Does that imply that every file that
> happens to contain an id3v2 header would now probe as id3v2 and not the
> actual format? That would be HIGHLY confusing and probably break a lot
> of assumptions our callers are making.

Yes. Keep in mind mp3 isn't an actual container format. It's just an
essence stream. We do not pretend rawvideo or pcm_s16le are actual
containers either. I'm open to better ideas though.

Another option is adding a suitable "protocol" that strips the header.
This has its own set of problems. I also have a patch for not doing
ID3v2 stuff for formats that don't support it, such as rawvideo.

Note that this stuff wouldn't change proper containers where ID3v2 is
not the header, but contained somewhere else in the file, such as the
footer, for example AIFF.

> Also what I don't see in your email is any mention of what would this
> improve for our callers.

The ability to probe mp3 files with cover art larger than 1 MiB, and
also to skip reading said cover art over a slow connection while still
having functioning probe.

Another concern is HLS, which mandates ID3 support for MP3, AAC, ADTS,
AC3 and EAC3: https://datatracker.ietf.org/doc/html/rfc8216#section-3.4
The spec doesn't say whether by "ID3" it means ID3v1 or ID3v2.

One major oversight with ID3v2 is that it has mime type stored only for
the cover art and not the audio itself. This prevents its use as a
proper grownup container format.

/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] Fwd: [RFC] libpostproc splitout

[Derek Buitenhuis]

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, complete bullshit.

The CC is a lame duck.

- Derek


 Forwarded Message 
Subject:Re: [FFmpeg-devel] [RFC] libpostproc splitout
Date:   Thu, 21 Nov 2024 15:18:04 -0500
From:   Ronald S. Bultje 
To: Derek Buitenhuis 
CC: c...@ffmpeg.org



Hi Derek,

On Thu, Nov 7, 2024 at 11:04 AM Derek Buitenhuis mailto:derek.buitenh...@gmail.com>> wrote:

This work was very easy and not worth even remotely close to 5K euro.


This comment ("This work is not worth XYZ") was unnecessarily provocative. 
Please consider stating something as subjective as this as an opinion instead 
of an assertion - like you did further on in this thread.

Thank you,
the CC [Steven, James, JB, Ronald - with Michael abstaining & not participating]
___
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] Fwd: [RFC] libpostproc splitout

[Derek Buitenhuis]

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 could legitimately
warn me for, that would have been entirely acceptable. This just isn't
one of them. What is was for, is telling.

- Derek
___
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

[Nicolas George]

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 accusing them and who the witnesses
are except in exceptional circumstances. I think the CC should grand the
same right to their accused.

-- 
  Nicolas George
___
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] Crash in Niagara Workbench Streaming with FFmpeg 7.0.1+ (H.264 Codec) on Initial Attempts

[Kumar, Rahul via ffmpeg-devel]

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 issue.

Steps to Reproduce:
1. Use Niagara Workbench configured with FFmpeg 7.0.1.
2. Attempt to stream video using the H.264 codec (MaxPro camera driver in 
Niagara).
3. Observe crashes during the first few streaming attempts.

Observations:
* FFmpeg 6.0 works without crashes.
* Logs suggest a potential issue in memory allocation or initialization during 
early attempts.
* Crash logs point to ntdll.dll, which might indicate heap corruption.

Environment:
* OS: Windows 10 Enterprise
* Niagara Workbench Version: [Your Version]
* FFmpeg Versions Tested: 6.0(working fine), 7.0.1(crashing), 7.1(crashing)

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? Could this be related to 
recently resolved issues like CVE-2024-7055 or others?


Regards,
Rahul Kumar,
Honeywell


___
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] Crash in Niagara Workbench Streaming with FFmpeg 7.0.1+ (H.264 Codec) on Initial Attempts

[Frank Plowman]

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 
> FFmpeg from 6.0 to 7.0.1. Updating to 7.1 also did not resolve the issue.
> 
> Steps to Reproduce:
> 1. Use Niagara Workbench configured with FFmpeg 7.0.1.
> 2. Attempt to stream video using the H.264 codec (MaxPro camera driver in 
> Niagara).
> 3. Observe crashes during the first few streaming attempts.
> 
> Observations:
> * FFmpeg 6.0 works without crashes.
> * Logs suggest a potential issue in memory allocation or initialization 
> during early attempts.
> * Crash logs point to ntdll.dll, which might indicate heap corruption.
> 
> Environment:
> * OS: Windows 10 Enterprise
> * Niagara Workbench Version: [Your Version]
> * FFmpeg Versions Tested: 6.0(working fine), 7.0.1(crashing), 7.1(crashing)
> 
> 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? Could this be 
> related to recently resolved issues like CVE-2024-7055 or others?
> 
> 
> Regards,
> Rahul Kumar,
> Honeywell

Hi Rahul,

Are you able to provide steps and/or bitstreams which reproduce this
issue using FFmpeg alone and not in Niagara Workbench?  There are a
number of reasons using FFmpeg 7.0.1 could crash this software which are
not due to bugs in FFmpeg.  Most notably, does the software actually
support FFmpeg 7?  This is a major version bump and so FFmpeg 7 is not
ABI- or API-compatible with FFmpeg 6.

All the best,
Frank

___
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] Use AVBufferPool in MOV

[Arnaud Masserann]

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
instead; this matches the way mpegts uses the pool, but is probably
too restrictive since it forces all future users to have this array of
32 pools.
   - Duplicating av_get_packet in mov.c; but then
append_packet_chunked needs to be duplicated too.

Feedback is welcome.

On Fri, Nov 22, 2024 at 6:46 PM 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/frame to 11ms/frame,
> close to the perf of ReadFile (10ms/frame), making it possible
> to read the media at 60Hz.
>
> Signed-off-by: Arnaud Masserann 
> ---
>  libavformat/avformat.h | 12 
>  libavformat/isom.h |  2 ++
>  libavformat/mov.c  | 20 ++--
>  libavformat/utils.c| 29 +
>  4 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 56c1c80289..25f2e59b22 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -440,6 +440,18 @@ int av_get_packet(AVIOContext *s, AVPacket *pkt, int 
> size);
>   */
>  int av_append_packet(AVIOContext *s, AVPacket *pkt, int size);
>
> +
> +/**
> + * Like av_get_packet, but allocates the AVPacket's buffer from a pool.
> + *
> + * @param sassociated IO context
> + * @param pool the pool of buffers; must be initialized with a sufficient 
> size
> + * @param pkt packet
> + * @param size desired payload size
> + * @return >0 (read size) if OK, AVERROR_xxx otherwise
> + */
> +int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt, 
> int size);
> +
>  /*/
>  /* input/output formats */
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 4723397048..c608f30e04 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -273,6 +273,8 @@ typedef struct MOVStreamContext {
>  } cenc;
>
>  struct IAMFDemuxContext *iamf;
> +
> +AVBufferPool* pools[32];
>  } MOVStreamContext;
>
>  typedef struct HEIFItem {
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index a2333ac1fd..2668bdf78f 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -9583,6 +9583,7 @@ static void 
> mov_free_encryption_index(MOVEncryptionIndex **index) {
>  static void mov_free_stream_context(AVFormatContext *s, AVStream *st)
>  {
>  MOVStreamContext *sc = st->priv_data;
> +int i;
>
>  if (!sc || --sc->refcount) {
>  st->priv_data = NULL;
> @@ -9639,6 +9640,9 @@ static void mov_free_stream_context(AVFormatContext *s, 
> AVStream *st)
>  ff_iamf_read_deinit(sc->iamf);
>  #endif
>  av_freep(&sc->iamf);
> +
> +for (i = 0; i < FF_ARRAY_ELEMS(sc->pools); i++)
> +av_buffer_pool_uninit(&sc->pools[i]);
>  }
>
>  static int mov_read_close(AVFormatContext *s)
> @@ -10544,6 +10548,16 @@ static int mov_finalize_packet(AVFormatContext *s, 
> AVStream *st, AVIndexEntry *s
>  return 0;
>  }
>
> +static AVBufferPool *mov_pool_get(AVBufferPool* pools[32], int size)
> +{
> +int index = av_log2(size + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!pools[index]) {
> +int pool_size = 2 << index;
> +pools[index] = av_buffer_pool_init(pool_size, NULL);
> +}
> +return pools[index];
> +}
> +
>  static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
>  {
>  MOVContext *mov = s->priv_data;
> @@ -10617,8 +10631,10 @@ static int mov_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  return FFERROR_REDO;
>  }
>  #endif
> -else
> -ret = av_get_packet(sc->pb, pkt, sample->size);
> +else{
> +AVBufferPool* pool = mov_pool_get(sc->pools, sample->size);
> +ret = av_get_pooled_packet(sc->pb, pool, pkt, sample->size);
> +}
>  if (ret < 0) {
>  if (should_retry(sc->pb, ret)) {
>  mov_current_sample_dec(sc);
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index e9ded627ad..869e97c089 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -104,6 +104,35 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  return append_packet_chunked(s, pkt, size);
>  }
>
> +int av_get_pooled_packet(AVIOContext *s, AVBufferPool* pool, AVPacket *pkt, 
> int size)
> +{
> +#if FF_API_INIT_PACKET
> +FF_DISABLE_DEPRECATION_WARNINGS
> +av_init_packet(pkt);
> +pkt->data = NULL;
> +pkt->size = 0;
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#else
> +av_packet_unref(pkt);
> +#endif
> +pkt->pos  = avio_tell(s);
> +
> +if(!pool)
> +re

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

[Vittorio Giovara]

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 had been put towards a useful
project, instead of funding something that was already done.
-- 
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".