Error with mkv files

[Simkin]

Hi!

I have some large mkv files, and when i try to skip, lets say halfway or 1/4 or whatever into the movie, it take extremely long time for vlc to react, i have to wait and wait before anything happens.

I also have one file, that i can only skip halfway into the movie, anything further and i get a Visual C++ Redistributable error and VLC closes. However, if i remove the chapter from the file using mkvmerge, i can skip all the way, but it still take extremely long time. In Media Player classic this mkv file works flawless.

While some of my movies does not have this problem.

Whats up here?

[Lotesdelere]

Does it work any better if you extract all of the streams from the original file and then remux them ?
It is important to first extract the streams, a simple remux is not enough.

[Simkin]

Do you mean take out the video track, then the audio track and put i all together again with mkvmerge?

As i said, these videos works flawless in Media Player Classic.

[Jean-Baptiste Kempf]

Cueless MKV files?

[Lotesdelere]

Do you mean take out the video track, then the audio track and put i all together again with mkvmerge?

Yes exactly, please do it, so it will create a new internal timecode.

As i said, these videos works flawless in Media Player Classic.

I have understood that, I'm trying to find the reason why.

[TypX]

As i said, these videos works flawless in Media Player Classic.

I have understood that, I'm trying to find the reason why.

that's because Haali's demux seeks better on cueless files.it's on my todo list.

edit:

Now that I'm thinking of it... it may be remuxed with the latest versions of MKVmerge which screws vlc's cue parsing so the files appear cueless. I'm working on it right now.

If you want to work around this, for now, you can try this : Tools->Preferences->Show Settings = All then in Demuxers -> Matroska check "Dummy Elements" then save and restart VLC.

[Simkin]

As i said, these videos works flawless in Media Player Classic.

I have understood that, I'm trying to find the reason why.

that's because Haali's demux seeks better on cueless files.it's on my todo list.

edit:

Now that I'm thinking of it... it may be remuxed with the latest versions of MKVmerge which screws vlc's cue parsing so the files appear cueless. I'm working on it right now.

If you want to work around this, for now, you can try this : Tools->Preferences->Show Settings = All then in Demuxers -> Matroska check "Dummy Elements" then save and restart VLC.

That helped! thanks!

[TypX]

By the way, the correct fix has been commited. Feel free to test the nightly builds on http://nightlies.videolan.org/ and if you do, don't forget to disable this option. It should avoid broken files to behave badly.

[plotzzz]

Same problem for me. Now with "VLC-2.1.0-20121229-0002 nightly" random access is OK (no more long searches or getting stuck) but playback is jerky.
So what would be the safest way to mux today for stability in the future ? Keep MKVToolnix 5.8 or switch to 5.9 ?
Thanks

[TypX]

For now you can apply the dummy element trick described above

[plotzzz]

Ca ne résout pas le problème des saccades (qu'il n'y a pas avec la 2.0.1).

[TypX]

The possible causes are numerous... it could be a contrib issue or other changes. The best way to check is to give verbose logs. In my case I play mkvs without stuttering using an up to date vlc 2.1

[plotzzz]

I get these warnings with 2.1.0 and any "h264.mkv" files:

Code: Select all

main warning: picture is too late to be displayed (missing 32 ms) main warning: picture is too late to be displayed (missing 33 ms) main warning: picture is too late to be displayed (missing 34 ms) main warning: picture is too late to be displayed (missing 35 ms) main debug: picture might be displayed late (missing 2 ms) main warning: picture is too late to be displayed (missing 39 ms) main debug: picture might be displayed late (missing 2 ms) main warning: picture is too late to be displayed (missing 43 ms) main debug: picture might be displayed late (missing 6 ms) main warning: picture is too late to be displayed (missing 47 ms) main warning: picture is too late to be displayed (missing 87 ms)

It's just unwatchable, but ok with 2.0.1.

[TypX]

Do you use GPU decoding? It may be a contrib issue.
In any case you can also try to increase file-caching.

[plotzzz]

Do you use GPU decoding?

no

In any case you can also try to increase file-caching.

tried 300/600/1000ms without success.

I guess the most important would be to know which one of VLC or MKVMerge has a bad implementation of Matroska standards. It would be great if - what I consider the best player and the best muxer - were fully compatible

Just tried MPC-HC and I had the same lags...until I switched to VMR9 !! Tadaaaa! Hope this helps.
Thanks for your time.

[TypX]

Do you use GPU decoding?

no

You should really consider it since most GPU allow that and it lowers the CPU burden a lot. If you can't/don't want you can try to force ffmpeg threads to 1.

In any case you can also try to increase file-caching.

tried 300/600/1000ms without success.

Did you restart VLC after saving the preferences? Preferences changes are applied after restart.

I guess the most important would be to know which one of VLC or MKVMerge has a bad implementation of Matroska standards. It would be great if - what I consider the best player and the best muxer - were fully compatible

Just tried MPC-HC and I had the same lags...until I switched to VMR9 !! Tadaaaa! Hope this helps.
Thanks for your time.

MKVMerge makes the standards and I try to cope with it. Yet most of the changes are in up to date versions (2.1). This one has been backported to 2.0. branches for possible future release.

[Whomp]

I have the same problem now too. A few .mkv files I've gotten take a really long time to start playing the farther I skip ahead. Once they finally start playing, I'm able to skip backwards and forwards fine. I've never had this problem before, and now I've seen it more than once within the past few days.

Edit: The fix seems to have worked, thanks!