On Thu, Mar 09, 2017 at 12:07:38AM +0100, Nicolas George wrote: > L'octidi 18 ventôse, an CCXXV, Hendrik Leppkes a écrit : > > So how do we fix fate now? Change the datatypes to uint32_t, remove > > the size print out? > > Shouldn't keep all 32-bit fate clients broken for much longer. > > Changing the types like that will not guarantee that all architectures > have have the same struct size, it will only make it happen because all > 32-bits architectures are basically identical and all 64-bits > architectures too. > > If we want a guarantee, we need to consider side data as an octet buffer > where fields must be explicitly serialized and deserialized. But I think > this would be piling worse design on top of bad design. > > In the long run, we should either get rid of side data entirely or turn > it into something actually useful. Right now, it only brings complexity > with zero benefit. >
> In the short run, I would say that printing the side data size in > ffprobe is wrong: this size is an artifact of FFmpeg's internal data > structures, not a property of the file, printing it makes as much sense > as printing sizeof(AVPacket) instead of packet->size. it is a property of the file in multiple cases through the split side data code but even if this is removed for example AV_PKT_DATA_NEW_EXTRADATA is just binary data from the file the length is from the file or AV_PKT_DATA_STRINGS_METADATA, which are multiple zero terminated strings and there is AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL which again is basically binary data and length from the file If you remove displaying the size based on the argumnet that it ideally should be the sizeof of a struct and thus should not be printed. Then that change should be limited to the cases where this argumnet applies [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel