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

Michael Niedermayer michaelni at gmx.at
Sat Dec 28 21:01:29 CET 2013


On Sat, Dec 28, 2013 at 04:21:45PM +0100, Nicolas George wrote:
> 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);

yes, i agree,
that was also supposed to work with what i had in mind ...


>
> 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);
> 	}

what i meant was an API that would use:

if (uncoded_frame_supported) {
    packet->data = frame;
    packet->size = 0; (or the correct size if 0 doesnt work out)
    packet->flags |= AV_PKT_FLAG_AVFRAME;
} else {
    avcodec_media_encode(encoder, &packet, frame);
}
av_write_frame(muxer, packet);

iam perfectly fine with doing these 3+ lines in a
av_write_uncoded_frame(), actually i like that idea.

what iam concerned about is that if the AVFrames are passed into
"muxers" by bypassing the existing packet based code path completely,
that its work going in the direction of a dead end.
To correctly interleave frames and packets they pretty much have
to use the same codepath

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20131228/43210afc/attachment.asc>


More information about the ffmpeg-devel mailing list