Quote:
Originally Posted by nevcairiel
I've never had any real issues with H264 or MPEG2 timestamps, they usually are rather consistent. (VC-1 is another matter, different splitters give different results, but there are luckily only 2 ways they do it)
If you just look at the incoming timestamps, they will of course be out of order, because those are presentation timestamps. They belong to the frame they are attached to, and frames are delivered in decode order, not in presentation order.
Any specific clip that gives you trouble?
|
The DC.ts is a good example:
Time stamps are fine when LAV's "Enable VC1 timestamp correction" is checked. Out of order otherwise (including the default 'auto' option) or when using MPC internal splitter. Haali splitter is also fine (although MPC-HC refuses to use it for mpeg2 transport for some reason).
I don't have access to the DShow graph from within my DLL to query the connected filters and from a design point of view I think it's a terrible idea to patch my code according to the connected filters. Ill behaved filters should be handled by the DShow decoder filter if at all. I'll do a more deep scan of my clips to see if non VC1 formats behave well enough.
nevcairiel:
BTW LAV Splitter produces incorrect (or inconsistent with other splitters) frame rates, interlaced or telecined clips receive 59.97
AvgTimePerFrame in the initial VIDEOINFOHEADER. This is very confusing.