[FFmpeg-devel] [PATCH 1/3] avformat/matroska: Support JPEG2000 for demuxing

[Dave Rice]

Hi,

> On May 25, 2025, at 7:50 PM, Andreas Rheinhardt <andreas.rheinhardt at outlook.com> wrote:
> 
> compn:
>> On Sun, 25 May 2025 05:50:54 +0200, Andreas Rheinhardt wrote:
>> 
>>> Patches attached.
>>> 
>>> - Andreas
>> 
>> looks ok but i wonder if anyone is using the vfw ffv1 mkv in the
>> archiving universe on purpose. should we include a way to -vfw-codec-id
>> manual for those systems? maybe is unimportant but it would be good to
>> ask the ffv1 specification crowd about this change to mkv muxing. and
>> maybe resend patch separately from jpeg2000 decoding subject. hiding an
>> ffv1 change under jpeg2000 subj is weird.
> 
> Why should the FFV1 specification crowd object to us writing FFV1 files
> in the way they have been intended to be written since February 2017
> (since
> https://github.com/ietf-wg-cellar/matroska-specification/commit/51a600106bfa66f58a7f2c8e05fab091ab059ebd)?
> Anyway, I cc'ed Dave Rice, the author of the aforementioned commit.

Thanks for the cc. I’m here linking to related conversations on this. The V_FFV1 mapping was drafted in 2017 and besides this referenced commit, there’s a discussion about it at https://mailarchive.ietf.org/arch/msg/cellar/Kir-8JdOl6DTZFPrxy4XM-iRP7Q/ with feedback from others in the IETF Cellar working group.

At that time I had also posted a request to read the V_FFV1 codec id in https://trac.ffmpeg.org/ticket/6206 which Carl Eugen Hoyos resolved and then also copied the request into VLC.

The idea was to define a V_FFV1 codec mapping, promote support for reading that in the primary Matroska tools, then wait a certain length of time, then promote writing FFV1 / matroska with that codec mapping. I forgot to set a timer for that time between updating readers and updating writers, but at 8 years I suggest it’s time for this change.

>> said another another way, this change would change the checksums of
>> files if people tried to recreate their mkv. which is something that
>> archivists do sometimes.
> 
> That's generally what happens when you update your FFmpeg, not only for
> the Matroska muxer, but for any component that is under active
> development. We don't give guarantees that the output stays the same
> when using different git snapshots.

I agree with Andreas' sentiment. I think an expectation that the different versions of the same tool produce identical results under default options would be unhelpful and we’d lose some of the benefits of the ongoing improvement to that tool and the underlying standards. For instance, several years back the FFmpeg Matroska muxer enabled embedded top-level Element CRC’s by default. Now whenever a relatively modern Matroska file from FFmpeg has a bit flip somewhere, we can determine what element is impacted.

+1 to switch from defaulting to V_FFV1 over VFW mode.

> Specifically for Matroska, there have been multiple commits changing the
> output of basically every Matroska file created by our muxer (often by
> using fewer bytes to write length fields); see e.g. git log
> tests/ref/fate/matroska-flac-extradata-update
> (Btw: The second patch in this set shows that simply remuxing is
> dangerous for FFV1 in VFW-mode.)

[…]

Thanks Andreas!
Kind Regards,
Dave Rice