<div dir="ltr"><div class="gmail_quote"><div dir="ltr">пн, 20 авг. 2018 г. в 18:38, Carl Eugen Hoyos <<a href="mailto:ceffmpeg@gmail.com">ceffmpeg@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2018-08-20 8:08 GMT+02:00, Vasiliy Volkov <<a href="mailto:volk.vasiliy@gmail.com" target="_blank">volk.vasiliy@gmail.com</a>>:<br><br>
No, I tested the sample you provided with current FFmpeg and it<br>
shows the correct frame-rate in the console output, no matter the<br>
number of threads, so I assume the issue is not in the decoder.<br></blockquote><div><br></div><div>So I use same code as FFmpeg, and other examples. It's the basic methods, which libav provides. So bugs are not expected here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you don't want to use the demuxer (it should have no overhead),<br>
then you probably have to copy the necessary heuristics to<br>
guess the framerate (as said, issues with H.264 timestamps<br>
definitely exist).<br></blockquote><div><br></div><div>The problem with demuxer not in overhead, but some encoders produce streams with wrong values in container.</div><div>So that's why we want to detect stream info from bitstream, which can't lie :)</div></div></div>