The VideoLAN Forums

Any mkv and any vob file?

Or allow dummy elements in tools->preferences->show settings = All -> Input/Codecs -> demuxers-> matroska
Save and restart vlc.

If you choose this solution, please disable this option as soon as you upgrade to 2.0.6 since it handles badly broken/corrupted files.

Just to be sure, are you using a vlc 2.0+?

Either get a 2.0.6+ version on http://nightlies.videolan.org or go in tools->preferences->show settings = all then Input / Codecs -> Demuxers -> Matroska check "Dummy Elements" save and restart VLC. If you choose the latter, as soon as 2.0.6 is out please disable this option since it will ...

VLC 2.0.6 is a soon (I hope) to be released version. You can find it on http://nightlies.videolan.org Hardware decoding is when you use your GPU to decode the video. It can be found in Tools->Preferences then in the Input & Codecs thumbnail there is a checkbox "Use GPU accelerated decoding&...

This sounds like video driver issues and bad HDMI handling...

the latter is a bug fixed in 2.0.6+, either get nightly build (http://nightlies.videolan.org) or tools->preferences->show settings = all then demuxer->matroska->check enable dummy element save and restart vlc. If you do the dummy trick please disable it as soon as you get a new version of vlc since ...

It is more CPU intensive to render subtitles, scale and blend them than just playing hard subbed so it is not that part that is surprising. Especially since SSA subtitles feature many possibilities which can cost a lot of computation. Still... the fact that GDI is more efficient that Direct3D shows ...

Well it's very strange then... when GDI performs better than opengl and direct3D, it's usually time to update your GPU drivers.

I'm not sure to get your issue... when you play mkvs with ssa vlc drops frames? Did you try another video output?

Keep in mind that every time you change preferences you have to restart vlc.

First did you get your vlc from http://videolan.org/ or from a third party site? If the latter it may be a scam.
Else open a trac ticket on http://trac.videolan.org/vlc and upload the file on http://streams.videolan.org/upload

Well if you don't use the default values, you are most likely using bad encoding/muxing parameters. If the resulting file is 0 byte the file is really empty because vlc couldn't use the options you gave it.
You should check http://wiki.videolan.org/Documentation: ... _HowTo_New

The title is inside the metadata of your file and VLC won't change it. If you want to do that you have to remux your file with the new title.

I don't know windows tools so I can't decently recommend one but any file trimming program will do the trick. The first 40-50 MB should be enough to try to reproduce.

Ok. I'd say that it's a bug in vlc then and I'll need a sample to work on it. You can create a bug ticket on http://trac.videolan.org/vlc and upload a sample in http://streams.videolan.org/upload

This is a known bug (and fixed for 2.0.6+). You can either take a nightly build (http://nightlies.videolan.org) or enabling dummy element: tools->preferences show settings all then Input/Codecs->demuxers->Matroska check the dummy element box, save and restart vlc. Beware if you choose the latter, wh...

This is a known bug (and fixed for 2.0.6+). You can either take a nightly build (http://nightlies.videolan.org) or enabling dummy element: tools->preferences show settings all then Input/Codecs->demuxers->Matroska check the dummy element box, save and restart vlc. Beware if you choose the latter, wh...

you have to mux both into ts and then multicast the stream.

You can use tools like pastebin to copy the whole logs. So you say that with GPU decoding you still have lags? but no "main warning: picture is too late to be displayed" message? Can you show the logs when you enable the GPU decoding? Are you sure your file is ok? If yes... well can you pr...

The macroblocking when seeking is a video driver issue.

In this log you are not dropping frames. If you don't seek, is it still choppy during the action scenes? If yes it may be a bad encoding issue.

Do you use GPU decoding? If yes try deactivate it, save and restart vlc. If it fixes the problem you may have driver issue.

Else stop the playback (with the stop button) open tools->Messages set verbosity to 2, click play again and give us the full logs.

That's not the complete log. The interesting part for me is in the very beginning (hence the play after the message opening). Having seen synchro issues breaking the playback... you should try a 2.1 nightly build with directsound or waveout audio output.

With GPU decoding enabled (and after having restarted vlc)?
Can you share the logs? (stop playback, Tools->messages->set verbosity to 2, start playback again).

It's not the full report since it lacks the very beginning of the logs that describe the file.
In any case: "filesystem error: failed to read (Input/output error)" this is not good.

Automatic means mmdevice on Vista+. When you change the setting, you have to save and restart vlc to apply the changes.
As for the logs, post it here or use the pastebin like of your choice.