[FFmpeg-devel] [PATCH] avcodec/h264_metadata: add change pic_order_cnt_type option

[sharpbai at gmail.com]

To Andreas Rheinhardt,

> What does "will not accept a smaller value (such as 0)" mean?

As your said, the max_dec_frame_buffering is limited to 16. Set
it to 0 (on condition that we do know there is no reordered frames)
is not possible.

> Does it error out?

It is safe and will not break any files. It's not wrong and solves
your mentioned case. :)

> Notice that the change I am suggesting here is not safe in general.

Yes. It is not safe unless you know what you are doing. For safety
this feature must have some mechanism to detect the unsafe usage.

Let me introduce what my case is. First we encode using h264_videotoolbox
setting -bf to 0 (or not set. -bf default is 0) for speedy and lower
power consumption. Then we send the encoded bytestream to the other client
as quickly as possible. Then we decode using Android MediaCodec for speedy
and lower consumption. But we have found that the decoder output delays
about 18 frames, which is above 1 seconds at 15 fps. This is not acceptable.
Now we have changed the encoded bytestream before sending, which makes the
decoding delay down to 2 frames.

We could hardly change videotoolbox and MediaCodec. So the unsafe way in
general turns to be effective (or only, up to now) way at realtime scenario.

 
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 
To unsubscribe, visit link above, or email
ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".