Reference time handling with VC-1

[CiNcH]

Hey guys,

I am really dying with this VC-1. All the BD stuff works flawlessly, except for VC-1 playback.

With some decoders (CyberLink DXVA), the renderer would drop a lot of frames, others (MPC Video Decoder DXVA) seem to swap frames (maybe P- and B-frames?) but without dropping anything (both is unexceptable of course). Does somebody know how to handle reference time within the splitter/source filter correctly for VC-1? We are currently calculating offset between MPEG PTS and DirectShow stream time and afterwards applying this offset (+ a little delay) to further PTS to get the reference time.

[benwaggoner]

Can you give a little more context here? Are you trying to make a Blu-ray disc with VC-1 video, and having playback problems on the desktop? What are you encoding with?

[CiNcH]

It is about developing a Blu-Ray player, or more specificly a m2ts demuxer. We are putting PTS in relation to DirectShow stream time and advertise it as reference time (for more detail see my first post) for the renderers to schedule their outputs. This works properly for H.264 and MPEG-2, but not for VC-1. Reference time has to be modified in some way. But how?

[Guest]

Why do you assume the problem is with the reference time calculation? Timestamping is done the same way for all transport streams irrespective of the video encoding. Of course the muxer must properly allow for frame re-ordering when generating the time stamps, but that is basic muxer functionality. If you'd like to post a sample TS that gives problems I can check that the timestamps are generated correctly.

[CiNcH]

I actually have no clue. Source material is not the problem. Casimir thinks that the problem is due to reference time. He does some frame reordering within the MPC Video Decoder wrapper before he sends the frames to the actual decoder (ffmpeg software decoder).

I am really lost. Best result is given by CyberLink in SW mode. The renderer drops a frame every now and then (but always at exactly the same position) which is also clearly visible. When it comes to DXVA, nVIDIA (PV2) gives exactly the same result, with ATi (UVD) the renderer drops a hell of a lot of frames.
If I use the CyberLink VC-1 decoder within PowerDVD everything is completely smooth.

Another interesting observation is that exactly where the renderer drops a lot of frames with DXVA and ATi with CyberLink, MPC Video Decoder (DXVA) seems to start swapping frames (but plays at full 24 fps without dropping anything).

[Guest]

He does some frame reordering within the MPC Video Decoder wrapper before he sends the frames to the actual decoder (ffmpeg software decoder). That is highly unusual and should not be necessary. Given this, I can't help anymore unless you justify this strange action in the context of what you are doing. You cannot just arbitrarily re-order frames in the encoded stream!

[CiNcH]

I am not doing this, Casimir is ;) . The re-ordering is done here (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/mpcvideodec/MPCVideoDecFilter.cpp?revision=995&view=markup) in the method SoftwareDecode. I only want to properly output VC-1 bitstream from the source filter's video pin and advertise correct timestamps ;) . It is working perfectly for H.264 and MPEG-2, but not for VC-1, tried several decoders (MPCVidDec, CyberLink, MainConcept).

[Guest]

Ah, you're just re-ordering the times not the actual frames.

If the same thing works for MPEG2 and AVC then maybe your B frame detection for VC1 is wrong. Show me the code for that.

[CiNcH]

If the same thing works for MPEG2 and AVC then maybe your B frame detection for VC1 is wrong.
We are not detecting any frame. We do not go that deep with parsing. We just extract ES from PES, devide ES into 8K chunks and deliver them downstream to the decoder within media samples.

[Guest]

Then how do you know how to do B frame re-ordering of timestamps?

[CiNcH]

Well, I thought there may be an easier way. We do not want to go as deep as frame parsing within the splitter. So this really has to be done for VC-1?

[Guest]

The code you pointed me too shows re-ordering based on the frame type but you say you don't parse the frame type. I'm sorry but I can't make any sense out of that.

[Guest]

What would I need to build that project to help you debug this?

[CiNcH]

Forget about the MPC code. We are still implementing m2ts demuxing into the DVBSource filter (nothing to do with MPC at all). We are able to handle all formats, MPEG-2, H.264, VC-1, AC3, DTS, EAC3, TrueHD, DTS-HD. As long as a BD or m2ts has a H.264 video stream, everything works out well. As soon as VC-1 comes into play, video is getting jerky.

I just talked to Casimir about the problem and he believes that there is something wrong with how timestamps are handled. He just pointed me at this re-ordering. But if I get it right, this re-ordering is also done for H.264 within MPC SoftwareDecode, so this does not seem to be something VC-1 specific which it has to be in our case since we are handling H.264 in exactly the same way and most decoders do work with this approach.

[Guest]

Well, if you give me something I can build and a stream to cause the problem I can probably help you. But really, there's nothing special about VC-1 that would account for this.

[CiNcH]

I will go for some more tests...

There are few decoders available for VC-1, and no standalone at all. All decoders come with complete processing chains (CyberLink, MainConcept, MPC, Sonic) and they may be doing some proprietary stuff...

[CiNcH]

You were right neuron2. I finally found a decoder which does the job perfectly together with DVBSource in case of VC-1... ArcSoft Video Decoder!

[Jay Bee]

You were right neuron2. I finally found a decoder which does the job perfectly together with DVBSource in case of VC-1... ArcSoft Video Decoder!

Could have told you that if I had seen this thread earlier. It's the reason for this (http://forum.doom9.org/showpost.php?p=1249154&postcount=10).

The strange thing to me is that even the MS decoder performs so poorly on MS' own format. I mean they could easily do fixes to it via MS Update but instead they leave their codec without decent support on their own OS...

[CiNcH]

Well... history repeats itself, we have had it in the beginnings of MPEG-2 and H.264. Many filters dealing with VC-1 are not yet mature enough..