[FFmpeg-devel] Channel layouts for aac encoding/decoding and vorbis decoding

[Nicolas George]

Le tridi 23 thermidor, an CCXVII, Benjamin Larsson a ?crit?:
> The FFmpeg codecs should use that layout for output and input. Though
> there are still some codecs that do not adhere to that.

Is it really the best option? Channels reordering is a non-trivial
operation, it may be costly.

I admit I did not run any benchmark, but if, for example, I use libfaad
through lavc and play the resulting file to the sound card, the idea that
lavc is converting the FC-FL-FR-RL-RR-LF order from libfaad to its internal
FL-FR-FC-LF-RL-RR while I have to convert it once again to FL-FR-RL-RR-FC-LF
as expected by ALSA, is somewhat disturbing. It would be best if the
reordering could be done only once.

Someone mentioned the similarity between channels ordering and colorspace,
and I agree that both notions are very similar.

But the message said that all video codecs decode to YUV420: that is not
true. Most video codecs decode to YUV420 because that is the pixel format
they use internally, but there are codecs that work with other pixel
formats.

(For example I just did: "ffmpeg -i colin.fli 't%05d.png'" to convert a FLI
file from an old DOS game into a sequence of PNG files: all the work was
done in PAL8, no conversion to YUV420 was done. If I force a conversion to
YUV420, a slight alteration of the colors is visible.)

As far as I understand the code in ffmpeg, if the pixel format from the
decoder is not accepted by the encoder, ffmpeg automatically inserts a
swscale converter in the process.

I think a similar solution for video codecs would be both the most practical
and the most efficient.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090810/5fadcf94/attachment.pgp>