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

Michael Niedermayer michael at niedermayer.cc
Thu Mar 9 21:48:51 EET 2017


On Thu, Mar 09, 2017 at 07:48:53AM +0100, wm4 wrote:
> On Thu, 9 Mar 2017 02:20:03 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> > > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:  
> > > > Hi,
> > > >
> > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 <nfxjfg at googlemail.com> wrote:
> > > >  
> > > >> On Wed, 8 Mar 2017 14:09:53 +0100
> > > >> Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > >>
> > > >> If the size printing is removed then other code should be added  
> > > >> > to test for the size to match the correct value  
> > > >>
> > > >> Then it would be more reasonable to make av_packet_add_side_data()
> > > >> check whether the size is correct for the given side data type.  
> > > >
> > > >
> > > > I think you're both right here, this is a pretty good idea (for fixed-size
> > > > side-data types).
> > > >  
> > > 
> > > 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.  
> > 
> > +1
> > 
> 
> You're the one stopping the simple fix.

If you or anyone belives this, you can just ask me privatly if i meant
to object to the patch. Noone asked
one can even ask me in public, as in "do you object to this patch
being pushed ?"
and to save everyone the delay and troubble the awnser is

I do NOT object to it.
I would prefer if the final implementation would still print the size
where it is relevant. That can be done in a seperate patch. Its
important to fix this issue so it should not be delayed by this
discussion (thats the long form of the "+1" above really)

But instead of asking, you publically claim that iam stoping the fix.
that is not ok IMO


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

It is what and why we do it that matters, not just one of them.
-------------- 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/6b061728/attachment.sig>


More information about the ffmpeg-devel mailing list