Since there are some dissenting voices on IRC who think this should be exported as binary metadata, I'll summarize here why I think my approach is better:
Whether those attached pictures are "actually" metadata or not, they are also obviously encoded pictures. The entire point of Libav is dealing with media streams -- which includes encoded pictures. Therefore it makes much more sense to me to treat them as data we can process, instead of some opaque stuff. Next there's the issue of usability. A typical use case for an attached cover is to decode and display it. If we exported it as metadata, the user would have to * get the tag * somehow deduce the codec from it (meta-metadata anyone?) * allocate and setup the codec context All this has to be special code for processing pictures stored in metadata. Another use case is extracting this picture into file. In this special case, binary metadata is a little simpler since it's enough to just get the tag and write() its contents somewhere. But it still requires special code for processing covers. With my approach, lavf does most of the setup itself. The caller can simply use generic video decoding code. With this patch e.g. avplay can display the picture and avconv can extract/convert it like any other picture. No special code for processing covers is needed. Finally, allowing binary metadata is basically a compatibility break, since every user now must be able to deal with it. Of course if anyone has any strong arguments in favor of binary metadata, I'm listening. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
