Subtitle playback issue in Snow Leopard

[raziel2001au]

I've just upgraded to the retail of Snow Leopard and found that when playing a video file with embedded SSA subtitles the video can take a minute or more to load - versus less than 5 seconds on Leopard.

I've been playing around and I've confirmed that it most definitely is the subtitles rather than the video or audio codec. All of my tests used the MKV file container, so there is a small chance that it is an MKV+SSA issue, but I think it is probably a general SSA issue. MKV's with no subtitles embedded do not have this problem. Once the video does start playing it seems to work alright, but of course with a minute worth of loading time it is quite nasty... Turning off formatted subtitles doesn't make a difference - so it is something much more fundamental that is going wrong during the loading, I have not tested whether this also affects SRT subtitles, but it might...

I'll post more info if I discover anything more, but I'm hoping this can be dealt with rather quickly since it is quite annoying - admittedly it isn't a complete show-stopper, but it sucks when you have to wait a minute for your videos to start playing.

EDIT: The forum changes the word A-S-S (without dashes) to some stupid 'stay polite' message, so wherever I used the word SSA, treat it as advanced substation alpha subs rather than the original, but I would assume this problem affects both SSA and A-S-S.

[Jean-Baptiste Kempf]

Does it happen everytime, or just at the first run of the movie?

[raziel2001au]

It happens every time you try and play a movie with embedded subtitles - even if you keep VLC running and just load a different file. Once it starts playing everything *seems* to be okay - it just takes ages to get there. I already checked my disk activity, it doesn't seem to be stressing the drive while it goes into this loading loop... It does seem to use up some CPU cycles though.

It does seem to load videos a little bit faster when VLC has already played one video and you keep the program open, but it is still 30 seconds vs. less than 5 on Leopard from a cold boot. Once you exit VLC and run it with a video to open, it will take a minute again.

Just looking at the problem on the surface it smells like a caching problem to me... like something that should be cached is not being cached correctly under Snow Leopard - fonts perhaps?

[fkuehne]

Hmm, 32bit builds of VLC may take a littler longer on their first launch, in case that no other 32bit application (such as Adium, iTunes or Firefox) was launched before it, as the OS needs to reload all frameworks in their 32bit version. This is definitely noticeable, but it doesn't explain your problem.

Does this also happen when playing files without subtitles and more importantly files which aren't in the MKV container format? (such as MPEG, AVI, MP4, etc.)

[raziel2001au]

Does this also happen when playing files without subtitles

No, as I've stated in my original post, if you remove the subtitles, the video starts as fast as it used to on Leopard.

and more importantly files which aren't in the MKV container format? (such as MPEG, AVI, MP4, etc.)

No, it has nothing to do with the file container. If you open a file without subtitles (avi/mkv/mp4 etc.) it will start playing almost instantly, if you then click [Video->Subtitles->Open Subtitles] and select any SSA subtitle file the video will freeze for approximately 1 minute before it continues playing...

Try it yourself with this test SSA subtitle file: http://www.megaupload.com/?d=QL48SNOB

[Jean-Baptiste Kempf]

I guess that is just that VLC on mac recreates the SSA fonts cache over and over.

[fkuehne]

Hmm, not unlikely indeed.

[raziel2001au]

I guess that is just that VLC on mac recreates the SSA fonts cache over and over.

I don't know if you're implying that VLC in general recreates the SSA font cache under the Mac, but I would like to point out that this issue is definitely a Snow Leopard only problem... Under Leopard these videos (with subtitles embedded) all start at normal speed on the same copy of VLC. Switch over to Snow Leopard and you have to wait a minute to load the same videos.

Clearly something is going very wrong under Snow Leopard, it is probably something really obvious, but this is unfortunately the extent to how useful I can be. I provided a sample SSA subtitle file in my earlier post with instructions on how to reproduce the bug, now it's up to you guys.

I'm hoping this gets fixed soon since 99% of my video library is MKV's with subtitles.

[Jean-Baptiste Kempf]

Maybe the issue is about the fontcache not being able to be saved...

[raziel2001au]

Maybe the issue is about the fontcache not being able to be saved...

That is exactly what I was thinking for a while now. I think it is possible that the permissions on a directory has changed on Snow Leopard - a directory VLC uses for its font cache, that would cause VLC to fail saving the font cache, forcing a rebuild every time you open a subtitle file. It could of course be more complicated than this, but it is what I am thinking is the most obvious explanation.

And trust me j-b, this is definitely the same issue described in that other thread (viewtopic.php?f=12&t=64302&p=214930), I've reposted some of my previous comments which will hopefully clarify things, but I really don't know how else to say it. MKVs without subtitles don't run into the loading problem and work fine, plus, loading subtitles by themselves causes the same problem even if you're not using an MKV file.

[raziel2001au]

This is part of the log, and I've indicated where the 1 minute freeze occurs with a bunch of asterisks:
libass debug: adding embedded font Prototype.ttf
libass debug: adding embedded font KozMinPro-Heavy.otf
libass debug: Setting libass fontdir: /Volumes/Home/Library/Preferences/VLC
******************** <- one minute freeze happens at this point - then continues with the rest below:
main debug: using decoder module "libass"
main debug: TIMER module_need() : 52931.105 ms - Total 52931.105 ms / 1 intvls (Avg 52931.105 ms)
main debug: thread (decoder) created at priority 0 (../../src/input/decoder.c:315)
main debug: thread started
main debug: `XXXXXXX.mkv' successfully opened
main error: Invalid PCR value in ES_OUT_SET_(GROUP_)PCR !

So something is happening between the fontdir debug message and the using decoder module message which is causing it to twiddle its thumbs for 1 minute.

[Jean-Baptiste Kempf]

Ok, that is what I guessed. This happens on reload of the fonts files. But it should do that only once. Never after again...

[fkuehne]

It your home folder stored on a volume, which is not the startup disk?

[bienc]

I have the same problem as the OP.

I was trying to open a 350mb .mkv file which used to take a couple of seconds to open in Leopard. I did a clean install of Snow Leopard on Saturday, and when I tried to watch an episode of a series that uses subtitles, it took about a minute to open up.

After reading the user's post about subtitles, I tried a 4gb 720p .mkv movie file that I have, which in Leopard, would take a bit to open just like the regular .mkv's with subtitles, but this one opened up in a spit second. A very nice speed boost at least on my system, but the .mkv's with subtitles take an excruciatingly long time to open.

[raziel2001au]

It your home folder stored on a volume, which is not the startup disk?

Yes, that is correct. I have 3 partitions, one for the OS and /Applications, one for my home folder and one for my Bootcamp partition... I've had the same setup in Leopard though, so I don't believe that is the cause of the problem - but that does explain why it sets the directory to /Volumes/Home .

[seqiro]

I can confirm that I am having the same problem after upgrading to Snow Leopard.

[Jean-Baptiste Kempf]

@raziel: do you know how to use strace?

Can you check that a fontconfig cache file is created somewhere?

[raziel2001au]

@raziel: do you know how to use strace?

Can you check that a fontconfig cache file is created somewhere?

Sorry, you'll have to be a bit more informative on this one... I don't usually debug under the osx environment and know next to nothing about the internals of VLC. Do you have some instructions I can follow?

[gonhidi]

Can you check that a fontconfig cache file is created somewhere?

Examining the file activity on a running VLC (a subtitled file had already been read) process through Instruments, I see the folllowing:

• The subtitled MKV is read.
• A /usr/X11/var/cache/fontconfig file with a seemingly random name is opened
• Many /System/Library/Fonts files are opened.
• All this has happened fairly quickly but then file activity pauses for around 35 seconds.
• Afterwards, more font files are opened at bursts for a few seconds.
• Finally, a couple more fontconfig cache files are opened, then several VLC preference files are examined and finally playback starts.

The fontconfig files exist on disk and are accessed on subsequent runs of VLC.

On a second run (fresh VLC run), apart from the dylib files read there are now two long pauses. Both happen between when LastResort.ttf is closed and LucidaGrande.ttc is opened (this time the fonts directory is examined twice).

[Jean-Baptiste Kempf]

Non fontcache is created?

[gonhidi]

No fontcache could be created: the /usr/X11/var/cache/fontconfig mode is 755 for root:wheel. I now realize that the fd returned for the cache files was -1, which I assume means that they failed to be opened (in rw mode), so your hunch about the source of the problem seems correct.

A chmod o+w on the directory let the cache be built (the file ownership for the three files changed from root to my user), so after one last long pause playback was back again to being reasonably instantaneous. I have run Disk Utilities permission repair to see if that fontconfig cache directory should have other settings but it has found nothing to repair.

[Jean-Baptiste Kempf]

No fontcache could be created: the /usr/X11/var/cache/fontconfig mode is 755 for root:wheel. I now realize that the fd returned for the cache files was -1, which I assume means that they failed to be opened (in rw mode), so your hunch about the source of the problem seems correct.

A chmod o+w on the directory let the cache be built (the file ownership for the three files changed from root to my user), so after one last long pause playback was back again to being reasonably instantaneous. I have run Disk Utilities permission repair to see if that fontconfig cache directory should have other settings but it has found nothing to repair.

How do the subsequent runs work?

[gonhidi]

How do the subsequent runs work?

Fine, both after restarting and with a couple of different soft-subbed MKV files: the fontcache files are checked and there is no access to the fonts directory.

Changing the font cache directory back to being read-only and even making the files belong to root (like the rest) seems to do no harm. Deleting the cache files makes the problem return.

[raziel2001au]

I figured it is probably a permissions issue. How hard would it be to fix this the proper way (so users just download it and it works without terminal hacks)? I don't know much about X11, but I'm assuming there is a reason why the fontcache is created where it is - could it be moved, say into /Library/Application Support/VLC?

[Jean-Baptiste Kempf]

Well, GonHiDi, that's what I thought
Thanks for confirming. We need to patch fontconfig to force the cache to be in VLC space for VLC 1.0.2