[Ffmpeg-devel] [RFC] bytestream show and change

Alex Beregszaszi alex
Thu Jan 4 22:56:51 CET 2007


Hi,

> > > > >> > Since we have bytestream_put and _get which changes the pointer every
> > > > >> > time, anyone against _change and _show which does the same, but without
> > > > >> > advancing the pointer?
> > > > >> 
> > > > >> are they needed for any code? if no theres no sense in adding them
> > > > >> currently, also i dont like redundancy (LE/BE* / bytestream_show())
> > > > >
> > > > > I'm doing some code, which needs this. Currently it has LES_8/16/32 for
> > > > > writing such values, and LE_8/16/32 for reading.
> > > > >
> > > > > Which is better, adding LES_ or extending bytestream_ and replacing all
> > > > > LE_ occurances too?
> > > > 
> > > > Do not add anything with generic names like LE_*.
> > > 
> > > what about
> > > AV_<L|B><R|W><2|4|8> ?
> > > 
> > > so that for example AV_BW4 would be a big endian 32bit write ...
> > 
> > And you plan to remove the current bytestream_ stuff? I dont get the
> > rationale in this.
> 
> i am speaking about LE_* BE_* stuff not bytestream_ stuff

We have actually semi duplicates now. Bytestream stuff and LE/BE lot of
codes use LE/BE for sequantial reading, thus advancing the pointer after
reading.

Per my understanding, this would be the preferred way now:
* add AV_xyz, where x is L/B (little/big), y is R/W and z is the width
(2,4,8) (altought I would prefer AV_<R/W><L/B><8/16/32>
* change bytestream functions to use the above macros
* change all the old code which uses LE/BE for sequential reading to use
bytestream

If I got this right, I will implement it now.

--
Alex Beregszaszi






More information about the ffmpeg-devel mailing list