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@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
