[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.
michaelni at gmx.at
Thu Jan 16 18:04:16 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.
> 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.
> 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.
theres av_frame_clone() for avframes
> 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
fine with me, if you and application developers prefer that
btw, also the 2 solutions arent exclusive, we could do one now and
still if we find the need later do the other as well
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel