[FFmpeg-devel] [PATCH 1/4] lavf: add write_uncoded_frame() API.

[Nicolas George]

Le tridi 13 nivôse, an CCXXII, Michael Niedermayer a écrit :
> whats the use-case of this ?
> its not trivial for an application to interleave packets correctly
> for each muxer and could lead to broken files when it is done wrong

The normal muxing patch have both av_write_frame() and
av_interleaved_write_frame(), it seems natural to have the equivalent for
this API.

Also: this API is especially intended for devices, and they frequently have
only a single stream. If the application knows its muxer have only one
stream (it just created it!), then it can spare the overhead of the
interleaving code.

> > +        av_assert0(pkt->size == sizeof(AVFrame));
> this looks very hackish

That is just the counterpart for the "pkt.size = sizeof(*frame);" code
below.

> maybe PCM/RAWVIDEO could be assert0() here

I do not have a strong opinion about this, but I do not want to limit what
muxers are allowed to accept. For example, if someone implements lavd/vdpau,
it will accept AV_PIX_FMT_VDPAU_H264, and it may make sense to have the
codec be H264 rather than RAWVIDEO.

> if its just a random number that doesnt represent the size then it
> could as well be 0, that also would ensure that any use of it would
> be detected
> sizeof(AVFrame) works almost so its unlikely to be detected if some
> code does a memcpy of it but that then can fail mysteriously with
> shared libs and some being upgraded

I see your concern, but there is another side to the issue: there are few
places in the code that handle zero-sized packets specially. And it makes
for a weaker consistency check.

Would this be acceptable:

#define UNCODED_FRAME_PACKET_SIZE (INT_MAX - sizeof(AVFrame))

? It will cause invalid memory access if someone tries to copy the packet,
and it makes an even better consistency check.

Regards,

-- 
  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/20140104/b41bdd00/attachment.asc>