[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.
michaelni at gmx.at
Sun Jan 19 02:29:25 CET 2014
On Thu, Jan 16, 2014 at 05:44:17PM +0100, Nicolas George wrote:
> Le septidi 27 nivôse, an CCXXII, Michael Niedermayer a écrit :
> > the asserts should be before the clone, i think
> Locally changed.
> > looking at this i wonder if this frame->packet change would not be
> > simpler if its done by the raw video encoder. (or a seperate
> > uncoded frame in packet encoder)
> > It would avoid complexity on the user application side except
> > the need to tell the encoder that it can return AVFrame in AVPacket
> > packets
> > The individual muxers would stay as they are in your patch and
> > av_interleaved_write_frame() would accept these
> > AVFrame in AVPacket packets from the encoder
> > the patch should be ok though if above has some issues / is worse
> The way I see this interface, the "frame->packet" encapsulation should not
> It happens internally, in the library, because it does something quite
> complex with the packets (interleaving, computing the timestamps) and it was
> better to use the same code path.
> It happens internally in ffmpeg.c too for exactly the same reasons.
> But ffmpeg.c is not a normal application: it is a very complex one, with a
> lot of cases to handle (stream copy, subtitles, bitstream filters, simple
> and complex filter graphs, etc.). It also deals with timestamps in the
> output packets (which seems redundant at this point, IMHO).
> I expect most applications that may use this API to be much simpler: get the
> frame from somewhere, encode it to PCM/rawvideo, mux it to the device. In
> that case, it is just a matter of skipping the encode step.
Do you know of such applications (i mean one actually existing not a
hypothetical one) ?
> To make my point differently: I consider disguising a frame as an AVPacket
> to be a hack. The mess with the magic number in the size should be proof
> enough of it. I can leave with it since it allows to achieve the goal in a
> simpler way, but I do not want it to seep into the public API.
I can understand you and i agree but somehow your actual patch to
ffmpeg.c is doing exactly what you are trying to avoid.
if ffmpeg would need this hackery then its sort of in the public API
even if not litterally so, the need for the hackery is in case of
ffmpeg like applications.
and ffmpeg like would be any file transcoding tool here.
not ffmpeg like would be a player using libavformat for displaying
ill write another reply to the actual patch with some ideas ...
> Furthermore, it is a fragile hack: packet data is supposed to be a simple
> binary blob, it can be copied and passed around easily. A frame structure is
> not that at all: refcounted buffers must be updated, side data and metadata
> must be copied, etc.
it would not be hard to check in public AVPacket functions for this
case and cleanly fail or even support it (which should be easy for
The big complexity of cloning, freeing, ... AVFrames and all is in
I dont know if this would be the right way forward but i disilike
the hacks and complexity in the ffmpeg.c patch
> IMHO, but I have said it already, the good step forward would be the other
> way around: store packet data in AVFrame. But that can not happen anytime
> Nicolas George
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel