[FFmpeg-devel] fate: Do not report side data size

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170309/bfa9ca65/attachment.sig>