On 11/14/2017 8:28 PM, Sasi Inguva wrote: > For H264 files with no bitstream restriction flag, we aren't able to guess > the delay correctly. Especially if it's MOV container, because for MOV > container we just probe the 1st frame and stop in avformat_find_streaminfo .
You do not appear to be restricting this to one specific codec, or even codecs with B-frames. > When we are decoding , we increase the has_b_frames value from zero to 1 or > 2, when we eventually encounter B-frames in H264 decoder, but that is too > late and we have already dropped 1 or 2 frames. Lot of other fields in > codecpar are being set from the demuxer like channel_layout, sample_rate > etc. I am aware of the intend, however... The difference between filling those fields in and this patch, is that we can read those values directly, generally. This is a guess; a heuristic. A heuristic based on the GOP structure of a single codec. Where we guess where a GOP even starts. Nor does it seem to take into account non-friendly files, with oddly ordered and/or invalid timestamps (which it can't, based solely on PTS). I'm pretty tired of hitting insane edge cases in other types of files due to hacks added for some other specific set of file, but used for *everything*. This is a recurring theme in FFmpeg, so I'm trying to fight hard to keep more out... - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
