[FFmpeg-devel] [PACTH] Change av_get_channel_layout() syntax

[Michael Niedermayer]

On Tue, Oct 15, 2013 at 05:37:46PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2013-10-15 15:27:36 +0200, Michael Niedermayer encoded:
> > On Tue, Oct 15, 2013 at 03:10:54PM +0200, Stefano Sabatini wrote:
> > > On date Tuesday 2013-10-15 11:35:16 +0200, Michael Niedermayer encoded:
> > > > On Tue, Oct 15, 2013 at 10:48:35AM +0200, Stefano Sabatini wrote:
> > > [...]
> > > > > > i just meant that we could deprecate the use of decimal numbers for
> > > > > > channel masks as its somewhat odd and allows typos (lost c letter)
> > > > > > that is
> > > > > > 0x123 -> channel mask
> > > > > > 12c   -> channel count
> > > > > > 55    -> interpreted as mask for compatibility but deprecated
> > > > > 
> > > > > decimal syntax as channel mask is currently not supported, but it will
> > > > > be at the next major bump (in order to emulate the way we set channel
> > > > > layouts in lswr). So I can't see how we can deprecate something which
> > > > > is not yet supported.
> > > > 
> > > 
> > > > i meant that it should be deprecated for lswr to do that and also
> > > > probably the newly added stuff shouldnt really recommand its use
> > > 
> > > At the moment you set ocl/icl with: aresample=[io]cl=DECIMAL
> > > 
> > > since it's using AV_OPT_TYPE_INT to set the channel mask. Switching to
> > > AV_OPT_TYPE_CHANNEL_LAYOUT will be painless due to the hacked version
> > > of av_get_channel_layout.
> > >  
> > > > but thats just a suggestion, as the decimal variant seems ambigous
> > > > if one doesnt "know" how its exactly interpreted
> > > 
> > > You was the one to note that setting "aresample=ocl="PRId64"..." is
> > > quite handy, so now I can't see why it should be deprecated.
> > 
> 
> > people should use 0x%"PRIx64" it avoids the ambiguity
> 
> having to specify an hexadecimal is as ambiguous

hexadecimal meant channel mask previously through all APIs

decimal meant channel mask in swr and channels elsewhere
people may interact
with different APIs and versions and will not know which interprets
it which way.


>  
> > > 
> > > And yes it is ambiguous, but I think that "a number expresses the
> > > corresponding channel layout mask code" is still better (more
> > > intuitive) than "a number expresses the default channel layout with
> > > that number of channels".
> > 
> > agree of course
> 
> > ia just trying to say we should not recommand the use of decimals
> > for channel masks
> 
> > it even might make debuging harder if these show up in a bug report
> > that way
> 
> Which is not different from the hexadecimal form.

If i see a decimal channel mask in a bug report
first I do not know if its interpreted as mask or count, that depends
on where and which version and i wont remember that exactly in 3 month
second a bitmask as hex is quite readable 0x1241 has how many
bits(channels) set ? you see it immedeatly, but 4673 has how may set?


> 
> In short I think users should favor nominal forms, but both decimal
> and hexadecimal forms should be accepted.

thats what iam trying to say :)


> About bug reports, there is
> no way to prevent users to send unintelligible reports, restraining
> design because of that looks wrong to me.
> 
> Anyway the issue seems orthogonal with respect to the present patch,
> and can be addressed later.
> -- 
> FFmpeg = Funny and Fantastic Miracolous Peaceful Ecumenical Glue
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
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: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131015/c82d75a5/attachment.asc>