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

Michael Niedermayer michaelni at gmx.at
Sat Jan 4 15:42:59 CET 2014

On Sat, Jan 04, 2014 at 11:18:05AM +0100, Nicolas George wrote:
> 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.

whatever you prefer, just thought that this combination made no

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

a consistency check that triggers out of array writes doesnt seem
that great

size = 'F' // AVFrame
could be used but still this feels hackish

or a function could be added to libavutil to return the actual size
of the AVFrame struct


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140104/357af152/attachment.asc>

More information about the ffmpeg-devel mailing list