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

[Nicolas George]

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
happen.

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.

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
soon.

Regards,

-- 
  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/20140116/3f346b94/attachment.asc>