[FFmpeg-devel] [PATCH 1/2] lavf: add AVFMT_AVFRAME flag

Nicolas George george at nsup.org
Mon Dec 30 12:09:38 CET 2013

L'octidi 8 nivôse, an CCXXII, Michael Niedermayer a écrit :
> what i meant was an API that would use:
> if (uncoded_frame_supported) {
>     packet->data = frame;
>     packet->size = 0; (or the correct size if 0 doesnt work out)
>     packet->flags |= AV_PKT_FLAG_AVFRAME;
> } else {
>     avcodec_media_encode(encoder, &packet, frame);
> }
> av_write_frame(muxer, packet);
> iam perfectly fine with doing these 3+ lines in a
> av_write_uncoded_frame(), actually i like that idea.
> what iam concerned about is that if the AVFrames are passed into
> "muxers" by bypassing the existing packet based code path completely,
> that its work going in the direction of a dead end.
> To correctly interleave frames and packets they pretty much have
> to use the same codepath

Ok, I understand, and I completely agree: internally, using the same code
paths is the only thing to do (especially since the interleaving and
timestamps calculation codes are quite non-trivial: let us definitely not
duplicate them), and wrapping the frame in a pseudo-packet is the simplest
way of achieving it.

But I would rather not have it visible at the public API level. Not only
because it is a hack, but also because, I realize, it would require more
code from the application: not only does it need to set the frame data, size
and flags field, but it also needs to copy all fields that needs copying.
Right now that is only the timestamps, but it could evolve.


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

More information about the ffmpeg-devel mailing list