[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.

Nicolas George george at nsup.org
Sat Jan 25 17:13:13 CET 2014

Le sextidi 6 pluviôse, an CCXXII, Michael Niedermayer a écrit :
> On Sat, Jan 25, 2014 at 02:47:38PM +0100, Lukasz Marek wrote:
> > I haven't follow this discussion deeply, but is it blocking to merge
> > first patch from the set: [PATCH 1/5] lavf: add
> > write_uncoded_frame() API.?
> no, just needs nicolas/the author to ask for it to be merged

IMHO, patch #1 can not be merged until the current discussion on the best
design for the API is finished, since patch #1 actually implements the API.

Lukasz, as the author of several devices and a player, can give his advice
on this. Ramiro too.

I can summarize the current discussion, I hope I am not over-simplificating:

My current proposal is this:
  - new method for the muxers;
  - new public function with an AVFrame* argument;
  - internally to lavf/mux.c, disguise/wrap the AVFrame into an AVPacket;
  - internally to ffmpeg.c, disguise/wrap the AVFrame into an AVPacket.

Michael's argument is this:
since ffmpeg.c needs the AVFrame-disguised-as-AVPacket pattern, other
applications will need too, and therefore the API should be just that, which
is very similar to the RAWPICTURE special case and Ramiro's original

My opinion concerning that is this:
ffmpeg.c is quite unusual and should probably not use this API at all (it is
meant for players, not transcoders). Players do not perform complex tasks on
AVPacket structures, and therefore do not need this frame-as-packet hack.

I would gladly hear the opinion of someone else who is trying to get lavd
suitable for actual output.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140125/8acc7bdb/attachment.asc>

More information about the ffmpeg-devel mailing list