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

Michael Niedermayer michael at niedermayer.cc
Wed Mar 8 14:04:11 EET 2017


On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote:
> On Wed, 8 Mar 2017 12:51:06 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote:
> > > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara
> > > <vittorio.giovara at gmail.com> wrote:  
> > > > This should address the mismatch between different archs  
> > 
> > iam not in favor of this solution
> > 
> > 
> > > 
> > > Removing the side_data_size from output should be fine, as its a
> > > implementation detail and as seen here can even vary between
> > > architecture or possibly even compiler.
> > > Maybe someone that uses that ffprobe output more often can comment?  
> > 
> > I use all kinds of stuff
> > if something is removed from ffprobes output it wont be tested anymore.
> > We should test more not less.
> > 
> > 
> > > 
> > > An alternative for fixing fate would be to use fixed size fields in
> > > the new sidedata, although the possibility of it breaking similarly
> > > again in the future then remains.  
> > 
> > I strongly prefer fixed size to be used in side data over platform
> > dependant fields. Not only does size become testable but theres also
> > a platform specific difference less in the interface which should
> > help bug reproducability between platforms
> > 
> > thanks
> > 
> > [...]
> 

> So why don't let we fate test e.g. sizeof(AVPacket)? Makes as much
> sense.

this is trolling

No change in our code could have sizeof(AVPacket) be "wrong"
but a
int side_data_size
can be wrong easily


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
-------------- 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/20170308/f7a18781/attachment.sig>


More information about the ffmpeg-devel mailing list