On Sun, Dec 12, 2010 at 5:05 AM, Nicolas George <
[email protected]> wrote:

> Le duodi 22 frimaire, an CCXIX, Thomas Worth a écrit :
> > Maybe I'm not understanding the self-imposed limitation.
>
> This is not a limitation.
>
> A codec transforms an image (AVFrame) into a sequence of bytes (AVPacket).
> A muxer writes a sequence of bytes to a structured file.
>
> These are two separates roles.
>
> The uncompressed video codec is trivial: you can (and did) implement it
> with
> a few memcpy, instead of the DCTs and entropy codings found in most video
> codecs. But it is still a codec, with a role completely distinct from the
> muxer. When the muxer gets the sequences of bytes, it does not know whether
> they were produced by a few memcpy or by thousands of lines of complex
> code:
> it just gets the bytes.
>
> As it happens, there is one muxer (yuv4mpeg) that can only output one
> particular type of uncompressed video. For that particular codec, someone
> thought it was a good idea to to implement it along with the trivial codec
> in order to gain a few microseconds by merging redundant memcpy.
>
> This was, IMHO, a bad idea. The length of this discussion to explain you
> this, and the need to make a special case in the main program, is proof
> enough of it.
>
> Every other muxer follow the standard API: you give it a sequence of bytes
> with a size, no matter whether the video is compressed or not. Doing things
> any other way would lead to duplicated code all over the place for dibious
> gain.
>
> > This "uncompressed" video IS raw
>
> And the QuickTime muxer does not care: it wants a sequence of byte.
> Concatenating the planes from the picture is your responsibility.
>
> The only point for which the fact that the video is raw is relevant is that
> you can build the packet with very simple code, or even ensure that it is
> directly built in place, rather than relying on a complex library.
>
> Hope this concludes the discussion.
>

Thank you for taking the time to explain this.
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user

Reply via email to