[FFmpeg-devel] [PATCH 1/2] lavf: add AVFMT_AVFRAME flag

Nicolas George george at nsup.org
Sat Dec 28 16:21:45 CET 2013


Le sextidi 6 nivôse, an CCXXII, Michael Niedermayer a écrit :
> what does "undecoded_frame" mean ?
> muxers take as input packets, i imagine one could take a avframe
> instead. Which then might be called a uncoded frame or raw frame maybe

That is exactly what it is supposed to mean: provide the muxer with an
AVFrame instead of an AVPacket. It needs a name that is completely
unambiguous, both to show that it is not the normal API and to avoid future
conflicts with the fork. av_write_uncoded_frame() is very good.

> what happens when a muxer supports both raw frames and normal
> avpackets with compressed content, for example in 4 seperate streams
> raw pictures, raw pcm mjpeg & adpcm
> the later 2 are supported by some hw IIRC and
> we might not want to limit ourselfs to hw devices here, the API
> could be used with normal muxers too
> also what happens when the interleaved packet and
> av_write_undecoded_frame, get mixed, this seems likely for such case

I can suggest the coward's answer: document that av_write_uncoded_frame()
can not be mixed with av_interleaved_write_frae(), only with plain
av_write_frame(); in other words, applications that want to use
av_write_uncoded_frame() are responsible for interleaving.

Of course, anyone can implement the interleaved variant at a later time. If,
internally, the AVFrame is disguised as an AVPacket, it should even not be
that hard.

> if a muxer indicates support for direct AVFrames by some means
> and user applications would set a flag in AVPacket, packets without
> that flag and normal encoded raw bytestream content in data could be
> supported.

> what i meant here was, that if the existing methiods are used and
> AVPacket have a flag set, then the compatibility problem this draft
> fixes would not arise with ramiros variant AFAICS

I am sorry, I really do not understand what you mean here.

What I do not like in Ramiro's proposal (apart from the cast and sizeof
issue), is that it requires the application to do a special case, on pain of
crash or worse.

AVFMT_RAWPICTURE already has the same problem, of course, but it is only
used in muxers that applications are unlikely to use (what application would
use nullenc? yuv4mpeg is slightly more likely). Still, I would not be
surprised if a few applications had security issues due to not implementing
the RAWPICTURE special case.

What I would like is to have the principle that the usual encode+mux code:

	avcodec_media_encode(encoder, &packet, frame);
	av_write_frame(muxer, packet);

should work with all muxers. Faster routes for special muxers are available
to applications that want to use them, if they implement it:

	if (uncoded_frame_supported) {
	    av_write_uncoded_frame(muxer, frame);
	} else {
	    avcodec_media_encode(encoder, &packet, frame);
	    av_write_frame(muxer, packet);
	}

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/20131228/e16f21c2/attachment.asc>


More information about the ffmpeg-devel mailing list