[FFmpeg-devel] [PATCH 1/4] lavf: add write_uncoded_frame() API.
george at nsup.org
Sat Jan 4 11:18:05 CET 2014
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
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
> > + av_assert0(pkt->size == sizeof(AVFrame));
> this looks very hackish
That is just the counterpart for the "pkt.size = sizeof(*frame);" code
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the ffmpeg-devel