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. > > 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. 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.) - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
