To Andreas Rheinhardt, > It is unsafe in the sense that it can lead to invalid and broken files. > But it is way safer than actually modifying the slice headers, because > the latter is absolutely irreversible, whereas one just needs to set big > enough values to fix files broken by setting too low values for > reorder_frames and max_dec_frame_buffering. For this a warning in the > documentation that wrong values might break files should suffice.
Got it. > Just for confirmation: Setting num_reorder_frames to zero is not enough? On my tested devices setting num_reorder_frames to zero is enough. But I can't ensure it will be effective on every decoder. > This is wrong: pic_order_cnt_lsb is typically incremented by two per > frame (but it can be different), whereas frame_num is only incremented > after a reference picture and only by 1. Furthermore, both these values > are only coded modulo a certain power of two and these powers can be > different. I have found that only on macOS 11 pic_order_cnt_lsb is incremented by two while on iOS 14 or other Android devices I have tested pic_order_cnt_lsb is incremented by one. You could try to generate a bytestream on iOS to verify it. sharpbai _______________________________________________ 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".
