sharp...@gmail.com: > To Andreas Rheinhardt, > >> Why is this not possible? I just told you how you could set >> max_dec_frame_buffering to a lower value. It seems you haven't tried it. > > Ahh...I thought what you care about is the unsafety of directly modifing > num_reorder_frames and num_reorder_frames to a lower value. >
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. > We have tested set max_dec_frame_buffering to 0 and num_reorder_frames to 0. > The result is the same as set pic_order_cnt_type to 2. > Just for confirmation: Setting num_reorder_frames to zero is not enough? > Setting max_dec_frame_buffering requires to modify sps only while setting > pic_order_cnt_type requires to modify every slice. I think your method > is better. > > Btw, for safety you could compare pic_order_cnt_lsb and frame_num in every > slice header. The difference should not be larger than (num_reorder_frames * > 2). > Or an error should be generated. > 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. - Andreas _______________________________________________ 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".
