[FFmpeg-devel] [PATCH 1/4] lavf: add write_uncoded_frame() API.
george at nsup.org
Thu Jan 2 00:48:15 CET 2014
Le duodi 12 nivôse, an CCXXII, Stefano Sabatini a écrit :
> This sounds a bit weird. Indeed the feature should be directly
> accessible, without the need to use some testing code.
I do not understand what you mean here. What happens if the application
tries to write an uncoded frame to, for example, Matroska, where it makes no
sense because byte packets are needed? I see several possibilities:
1. It fails.
That is my current choice. But then, an application needs a way of
predicting it, because it is more convenient to initialize a codec
context before the encoding loop, and you probably do not want to start
writing your file header if you are not sure you will be able to find an
Hence the query feature.
2. It succeeds for formats that can be converted trivially (raw video and
PCM) and fails for other formats.
The application still needs to be ready to use an encoder, and an API to
check if the target format is considered trivial would still be useful.
That brings us back to case 1.
3. It succeeds unconditionally, allocating a codec context and doing the
I do not think that is what you are suggesting.
(Note that a high-level API doing 3 would be nice, i.e. I give a frame to
the library and it does everything necessary to get it into the file. But
that is not what I have in mind for now. Also, if we want that, we
probably also want a filter graph to handle automatic format conversion,
VFR-to-CFR, etc. And the same for decoding.)
> Also it is not clear how the user is supposed to test the feature.
> Probably a small test query function should be used instead.
The documentation says:
+ * To test whether it is possible to use it with a given muxer and stream,
+ * use the AV_WRITE_UNCODED_FRAME_QUERY flag with frame = NULL.
Do you have a suggestion on how to explain it better?
> probably unrelated, but I'm not sure this is correct since the codec
> time base may be different from the stream time base
The pts gets rescaled later, and it matches what lavc does (this part
emulates an encoder, "encoding" the frame to a packet with data the frame
else if (!(avctx->codec->capabilities & CODEC_CAP_DELAY))
avpkt->pts = avpkt->dts = frame->pts;
(I assume that codecs with CAP_DELAY are supposed to set pkt->pts and
pkt->dts themselves, of course.)
I will address your other comments once the design decisions have been
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the ffmpeg-devel