Embedded ASS/SSA Font (MKV) - Misbehaves (doesn't work on startup)

[GoogleCodeExporter]

1. Run GNOME-MPlayer
2. Open any MKV file which uses ASS/SSA subtitles with their own custom font(s)
3. Notice that the font is not being used; instead one can see the plain font
4. Open 'Preferences' Menu
5. Make no changes to settings
6. Close 'Preferences' Menu
7. Subtitles render correctly
8. Rinse and repeat for any/all other files.

Obviously, one would expect the correct subtitle font to be used when the
video file is opened. Instead, we see the generic plain font. It's bonkers
that it appears once you open and close Preferences. No changes made. Just
open and close.

GNOME-MPlayer 0.9.9.2, MPlayer SVN r31027 (14th April, with
Splitted-Desktop's LibVA/VA-API patches), Ubuntu 10.04 (x86_64)

If I need to submit more information, just poke me.

Original issue reported on code.google.com by suiseis...@gmail.com on 2 May 2010 at 6:30

[GoogleCodeExporter]

Can you run gnome-mplayer with the -v option and see the output. Perhaps there 
is an
option that is not being set properly on initial startup. Posting a sample 
fragment
(20-30 seconds of video with subtitles and shows the problem) would help.

Original comment by kdeko...@gmail.com on 2 May 2010 at 6:43

[GoogleCodeExporter]

I opened GNOME-MPlayer, opened a file; opened preferences, and closed 
preferences.

Sample fragment... It does it with *every* MKV I have which uses ASS/SSA 
subtitles
and an embedded font. Not sure as to the legality of posting a fragment 
somewhere,
since it's mostly Anime. But I just want to emphasise that it isn't isolated to 
a
selection of files.

Original comment by suiseis...@gmail.com on 2 May 2010 at 6:54

Attachments:

• mplayerlog.txt

[GoogleCodeExporter]

Looks like it is defaulting to using -noembeddedfonts where in the preferences 
you
have embedded fonts enabled, should be a simple fix once I am able to get to it.
Patch is probably in main.c in main and it is just not setting the 
embeddedfonts flag
correctly on startup.

Original comment by kdeko...@gmail.com on 2 May 2010 at 9:22

[GoogleCodeExporter]

Can you try SVN of gnome-mplayer... that code appears to work for me.

Original comment by kdeko...@gmail.com on 3 May 2010 at 12:55

[GoogleCodeExporter]

I was looking a little more at your log and it seems that the code to prefetch 
some
of the properties of that media file is not working on your machine. 

Can you please run gnome-mplayer with the --reallyverbose option and post that 
log.

Original comment by kdeko...@gmail.com on 3 May 2010 at 2:02

[GoogleCodeExporter]

Haven't had chance to try the SVN yet... but here's the log. Should have chance 
tomorrow.

Original comment by suiseis...@gmail.com on 3 May 2010 at 9:52

Attachments:

• verbosemplayer.txt

[GoogleCodeExporter]

OK, well, I just checked out SVN, and here's a log. It still exhibits the same
behaviour for me.

Original comment by suiseis...@gmail.com on 3 May 2010 at 10:35

Attachments:

• svnlog.txt

[GoogleCodeExporter]

yeah looks like the metadata is not getting grabbed until after the media is
started.. Probably a locking issue. What are the specs of your machine?

Original comment by kdeko...@gmail.com on 3 May 2010 at 10:38

[GoogleCodeExporter]

Can you try something for me...

in main.c at line 286 change

         while (demuxer == NULL && i < 10) {

to

         while (demuxer == NULL) {

And see if that fixes it.

Original comment by kdeko...@gmail.com on 3 May 2010 at 10:40

[GoogleCodeExporter]

Specs: Core 2 Duo P8700 (2.53 GHz), Mobility Radeon HD4650, 4GB DDR3 RAM etc.

I installed Ubuntu 10.04 on 3 wildly different laptops simultaneously, and it
exhibited the same behaviour on all of them.

*Will try the change today*

Original comment by suiseis...@gmail.com on 4 May 2010 at 6:04

[GoogleCodeExporter]

I made the change you suggested - it makes it work! Thanks a lot! What, in human
terms, does the change do? Would there be any detriment to that 'fix' being 
included
in the main release (i.e. is the "i < 10" required to account for something 
else)?

Original comment by suiseis...@gmail.com on 4 May 2010 at 8:57

[GoogleCodeExporter]

The i < 10 is a counter so that it doesn't loop forever. I would like to have 
the
safety of the counter so can you change the line to

while (demuxer == NULL && i < 100) {

And see if that fixes it as well. If so I'll change it to 100 in my code too. 
Perhaps
if you could try values of 25, 50, 75 and 100 to see what the minimum value 
needed
for you machine is, that would be interesting. You machine is actually faster 
than
mine (Core 2 Quad Q6600 (2.4Ghz, usually running at 1.6Ghz), Radeon 3650, 8GB 
RAM).
So it is interesting that 10 works fine for me.

Original comment by kdeko...@gmail.com on 4 May 2010 at 12:50

[GoogleCodeExporter]

100 works. So does 25. 10 doesn't work.

I haven't had chance to try this on other machines; but the machines it failed 
to
behave on were as crap as a one-point-something GHz single-core Celeron.

Original comment by suiseis...@gmail.com on 4 May 2010 at 5:59

[GoogleCodeExporter]

Set to 50 in SVN, closing issue.

Original comment by kdeko...@gmail.com on 4 May 2010 at 11:50

• Changed state: Fixed