[Ffmpeg-devel] Which byte I/O API?

[Michael Niedermayer]

Hi

On Tue, Jan 23, 2007 at 10:20:55AM +0100, Michel Bardiaux wrote:
> Michael Niedermayer wrote:
> >Hi
> >
> >On Mon, Jan 22, 2007 at 05:59:02PM +0100, Michel Bardiaux wrote:
> >>I'm trying to ressucitate my BMP encoder. At the time it was criticized 
> >>for using the put_bits API: understandable but the existing decoder used 
> >> get_bits...
> >>
> >>So, the first order of business is to change the decoder to use a 
> >>byte-oriented API. But which one? bytestream.h, or the recent 
> >>intreadwrite.h?
> >
> >for reading/writing the header use whatever leads to the simplest / 
> >cleanest /
> >most readable code (put_bits, bytestream.h, intreadwrite.h, ... whatever
> >you like)
> >
> >for reading/writing the raw image use memcpy(), le2me_16() and uintXY_t
> >read/write ISO C style (expect to see the patch rejected if this is
> >inefficiently implemented like with bytestream.h or intreadwrite.h which
> >are designed for unaligned data)
> >
> Crystal clear: in this case, the existing code (decoder) is a valid example.
> 
> Wilco, but for the record, I seriously disagree with that view:
> 
> (1) Changeing style (from using get/put_bits to manual) in the middle of 
> the code damages readability
> 
> (2) Any inefficiency in the code moving the image data around, will be 
> completely drowned by the I/O time.

this depends on the where the stuff is stored, if its in memory (URLProtocol
with mem buffer or a pipe or a file on a ramdisk) then the time spend in 
get_bits()/put_bits() could easily exceed the I/O time

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070123/f11a8542/attachment.pgp>