On Wed, Dec 16, 2020 at 08:09:29PM +0100, Nicolas George wrote: > Anton Khirnov (12020-12-13): > > IMO checksumming side data contents is a bad idea and should not be done > > at all. It's supposed to be an in-memory representation, which is > > inherently platform-dependent - besides endianness there are potential > > issues with padding or type sizes. If we want to test side data, we > > should use some other mechanism for it (e.g. ffprobe). > > I agree with this take, but I think you are only grazing the tip of the > iceberg here. > > I think than whenever we add a simple type (enum or structure) for use > as a side-data structure, frame property or similar, we should add a set > of function to perform the basic operations, with standardized names and > prototype: freeing, copy/cloning, printing, possibly checksumming, etc. > > Do you not agree it would be a worthy discipline? > > (Of course, if we agree on it, we need to revisit existing types to give > them these functions too.)
Maybe code which can generically serialize side data into a bit exact bytestream would be usefull. checksumming would be a one time implementation on top of this not a per side data one. Also transmitting this data accross a network or other would be trivial Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
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".
