[FFmpeg-devel] [PATCH 2/2] pngdec: expose gAMA and cHRM chunks as AVMasteringDisplayMetadata

wm4 nfxjfg at googlemail.com
Wed Sep 20 23:22:02 EEST 2017


On Wed, 20 Sep 2017 22:00:34 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Wed, Sep 20, 2017 at 08:32:59PM +0200, wm4 wrote:
> > On Wed, 20 Sep 2017 15:22:42 -0300
> > James Almer <jamrial at gmail.com> wrote:
> >   
> > > On 9/20/2017 3:18 PM, wm4 wrote:  
> > > > On Wed, 20 Sep 2017 04:00:28 +0100
> > > > Rostislav Pehlivanov <atomnuker at gmail.com> wrote:
> > > >     
> > > >> +    if (mdm.has_gamma || mdm.has_primaries) {
> > > >> +        AVMasteringDisplayMetadata *new_mdm = av_mastering_display_metadata_create_side_data(p);
> > > >> +        memcpy(new_mdm, &mdm, sizeof(AVMasteringDisplayMetadata));
> > > >> +    }
> > > >> +    
> > > > 
> > > > Use assignment instead of memcpy, duh.    
> > > 
> > > He shouldn't be using AVMasteringDisplayMetadata on stack to begin with,
> > > so no.
> > > 
> > > It's bad enough sizeof() has to be used at all already.  
> > 
> > Again you're just creating new problems out of thin air. We don't
> > realistically support mismatched libs, even if in theory we do. I wish
> > we could stop wasting time on things that don't matter at all.  
> 
> For past releases there was no dependace between the libs except
> what was implied by their version numbers and that was tested before
> release. Its also expected by some if not all distributions. And is
> generally the standard
> 
> More so we define versions based on semver, in our API docs.
> Which too requires specific (version dependant) package/lib compatibility.
> 
> From this it results that if sizeof can ever change without a major bump
> than sizeof cannot be easily used outside the lib its comming from.
> It can be used with precautions but that can becomes ugly quick
> 
> This does matter also in reality as its very easy by installing a
> new package on a system to pull in a update for a dependant lib. While
> the other libs wont be updated as there is no need to for installing
> that package.

I know all this, I'm just saying it's stupid to generate extra work for
"supporting" this.


More information about the ffmpeg-devel mailing list