Le jour de la Récompense, an CCXXII, Michael Niedermayer a écrit : > user applications and libs which interface to FFmpeg or libavformat > through a URLProtocol or AVIOContext receive the AVPacket.data but > not AVPacket.side_data but the side data is often essential
Yes, I know that. And this is fact slightly wrong: the applications receive the muxed binary stream, which contains probably (but not always, seem framecrc) the packet data and possibly all or part of the packet side data. What I ask is what the actual use case: if an application wants to access the packet data and side data, why would it use a muxer and capture its output instead of examining the packets directly? > With this patch, such applications can set the flag and would > receive the complete data stream. The alternative would be for such > libs to be redesigned to interface to FFmpeg or libavformat > differently You mean to redesign the applications, I suppose? In that case, I think this is the only proper solution: when I read this patch, my immediate reaction was: someone is misusing the API, does not manage to achieve the desired result and thus wants to misuse the API even more. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
