Pengvado could you have a look @ this

[CruNcher]

First i thought it might be a parser problem and Haali should look @ it but he cant reproduce it @ the moment as he doesn't use Cyberlinks Decoder and PV1 (DXVA), but now i found a way to avoid the slowdown problem with X264 ABR bitstreams (inside MP4/MKV) and Cyberlinks Decoder in PV1 (DXVA) mode the anwser is B-frames.
Im not quiet sure if that's the correct answer (i checked it ofcourse and non b-frame x264 abr bitstreams played back fine in Mp4/MKV for Cyberlinks Decoder with PV1 DXVA enabled) but i looked @ how Elecards Encoder in ABR saves B-frames and it is different from the way X264 does it (has nothing todo with B_pyramid nor weigthed_b or bime) the encoder/decoder display order is different with X264 it goes from one frame to the next like IPBBIPBB with Elecards Encoder it is like IBBPIBBP and with the later order there aren't such slowdown problems with Cyberlinks Decoder and PV1 (DXVA) only with the way X264 orders it (but also only in MP4/MKV) PV1 (DXVA) has slowdown problems (seems to be some kind of delay coused by the wrong decoding of b-frames that gets higher and higher over time and in the end would overflow PV1/DXVA Cyberlinks Decoder is useing).

So it seemes that reversing X264 encodeing order of B-frames should fix this slowdown problems :)

[akupenguin]

I don't know what you think Elecard is doing, but IBBP is impossible by the very definition of B-frames. Unless you mean open-gop, which is not a difference in frame orders but just some extra B-frames. And there's no way any codec can support open-gop while not supporting closed-gop, especially in h264 where open-gop is incompatible with idr-frames.

Why do you say ABR? Does it not happen in other ratecontrol modes? That would be even stranger, because it shouldn't be possible for a decoder to even know what ratecontrol mode the encoder used unless it cheats by looking at the options sei.

[CruNcher]

argh sorry yes my fault i analyzed the x264 encode within a .mp4 and the elecard as .avc and this is allready a difference for elecards stream analyzer in how the order is shown (if in .mp4 it shows the display order and when set to display the stream and vice versa for raw :P), when both files are in raw they show the same order IPBBIPBB ofcourse so that doesn't seem to be the problem but still the fact that the x264 stream muxed in .mp4 slowsdown @ playback and the elecard doesn't this slowly confuses me completly either Cyberlinks Decoder is faulty or gpac and libavformat are or Nvidias PV1 B-frame handling, jesus whats going on here.

PS: Could it be that maybe the extra SEI Encoder Info you add to the X264 streams is making Cyberlinks Decoder go mad ? i also still have this sample stream that doesn't playback @ all and shows a black screen and that is confirmed by someone else for PV2 with Cyberlinks Decoder and i have no idea what's going on. You can find info about all these interoperability problems with Cyberlinks Decoder and x264 here http://forum.doom9.org/showthread.php?t=124945 i didn't expirienced problems with commercial encoders and Cyberlinks Decoder yet, but x264 and Cyberlink is problematic under some conditions (mostly in combination with hardware accelleration via PV1/DXVA).

EDIT: OK i hope once and forall i found it, it seemes to be the direct_pred option that couses trouble with Cyberlink and PV1 DXVA i found a workarround by useing temporal but after creation of the .mp4 in either avidemux or mencoder it is damaged even if you use temporal prediction you have to first extract the raw stream (from the corrupted .mp4 you get from avidemux/mencoder (it might look ok but it isn't not for the combination of Haali Spliter and Cyberlink Decoder)) with yamb (mp4box) for example and create a new .mp4 this fixes the slowdown problem with Cyberlink once and for all if your stream was set on direct_pred=none/spatial/auto then you won't be able to mux the demuxed raw stream correctly with mp4box again it will end with a damaged .mp4 (not finished) direct_pred=temporal is the only way that i found that avoids this slowdown and remuxing problems with mp4box :) (FINALY)

Now it's up to the devs of the software above to find the bug that's couseing this strange behaviour with direct_pred,muxing it and hardware accelleration, gonna check now if this .mp4 can be sucessfully converted to working cyberlink .mkvs now and if those workarround .mp4 and .mkv are still compatible with all the Open Source applications, i have a good feeling :)