On Sat, 4 May 2024, James Almer wrote:
On 5/4/2024 5:34 AM, Marton Balint wrote:
On Thu, 2 May 2024, James Almer wrote:
On 5/2/2024 6:23 PM, Marton Balint wrote:
On Wed, 1 May 2024, Michael Niedermayer wrote:
This allows detecting issues in side data related code, same as what
framecrc does for before already for packet data itself.
This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.
Can you at least add an option which allows disabling dumping the side
data? Changing the format of framecrc output again and again is not
very
The framehash/framemd5 muxer is versioned, which is what you should use
if you want parseable output.
Okay, but then the question is that why framecrc is using different code
and options?
Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). The
latter was renamed/aliased to framehash and made to use the AVHash API, which
supports all lavu hashing algorithms, and is versioned.
If anyone cared, framecrc could be also made into an alias of framehash that
defaults to adler32 output, but it would result in a massive change to
reference files, if anything because AVHash initializes adler32 with a 1
whereas framecrc does it with a 0.
If we are changing the output format, we might as well change this as
well...
Framehash also has side data hashing, so making framecrc output
arch-indenpendent but not framehash would be a bit inconsistent.
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".
