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

[Nicolas George]

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

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

   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
structure itself):

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

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/20140102/f940f9e9/attachment.asc>