Problems with two subs starting at the same time in MKV.

[bmfrosty]

Red and Blue are swapped for subtitle colors. It has been suggested that this might be an endian problem. I have been able to recreate this and have verified it by comparing against the output of vsfilter. It has been suggested that this is an endian problem. There may be other endian problems in positioning, but I'm still waiting for sample data.

Also, for ssa titles contained in MKV files, when two titles start at the same time, one of the titles is delayed to the end of the other. This can be seen in the karaoke in the attached mkv. I'm also attaching the .ass file that was muxed into the mkv to show the error is not there when played against an AVI.

colortest.mkv is attached.

colortest.ass is attached.

[bmfrosty]

mkv to show problems with subtitle colors and timing in simultaneous titles.

[bmfrosty]

Same ASS file as is in the MKV. Rename an AVI to the same name to show the difference in the karaoke line.

[bmfrosty]

These are also present in the linux branch.

[bmfrosty]

Verified that neither bug is present in "MPlayer 1.0rc2-4.1.3" installed via apt-get in ubuntu 7.10.

[bmfrosty]

From ass.h:

typedef struct ass_image_s {

int w, h; // bitmap width/height int stride; // bitmap stride unsigned char* bitmap; // 1bpp stride*h alpha buffer uint32_t color; // RGBA int dst_x, dst_y; // bitmap placement inside the video frame

struct ass_image_s* next; // linked list

} ass_image_t;

Libass wants 'uint32_t color' in format RGBA, but it appears that in ASS styles it's stored ABGR. I'm not sure if the individual bytes are little endian or big endian though. Shouldn't be too hard to figure out, but I'm probably too tired to wrap my head around it tonight. I'll be able to play with it on Friday afternoon and all day sunday.

[bmfrosty]

clarification. I know the hex bytes in the .ass file are big endian, but I don't know whether libass expects them to be big endian or little endian.

[bmfrosty]

Ah. Ok. So it appears that the individual bytes for colors should keep the endianness that they have, but should be in a different order. I think just the Blue and Red bytes need to be swapped.

[leafmuncher]

I've renamed the title as it was really two bugs in one.

[iordonez]

does problem still persist in .5b3?

[bmfrosty]

I will test when I get home tonight.

[bmfrosty]

I've tested this, and it still occurs in .5b3. I've done a little digging in the code, and it appears that there are two methods for the subtitles to be passed to libass - one is a stream, and the other is a file. As this only happens when the subtitles are being demuxed from mkv, I want to assume that the problem has to do with the streaming method. A workaround would be to demux the subtitles before playback and hand them to libass as a file. I spoke to Elan about this a little, and he mentioned that Rob Rudd has some ideas on how to fix this in streaming mode.

[iordonez]

Thanks for keeping up, I'm trying to move all tickets to the most current version so we know what is actually on our plate and what is old news... Since you've been so good I hope this gets fixed soon ;)

[leafmuncher]

This actually appears to be a bug in ffmpeg. Rudd identified the line to me:

8:27AM Rob Rudd: Hey, I found out where the issue with the same time subtitles are coming from 8:27AM Rob Rudd: However, I'm not quite sure what the correct solution is 8:27AM elan: sweet! 8:27AM Rob Rudd: it is in fact, howeer, in FFMPEG 8:27AM Rob Rudd: on line 727 of utils.c 8:27AM Rob Rudd: its forcing one packet 8:28AM Rob Rudd: to be after the duration of the previous packet I think 8:28AM elan: ha! i suspected it might have been that naughty ffmpeg 8:28AM elan: nice job tracking it down 8:28AM Rob Rudd: No problem 8:31AM Rob Rudd: ya, im positive thats the line, if I comment it out it works, but i have a feeling thats not the correct solution :p 8:31AM elan: heh heh 8:32AM elan: it's probably true for most types of packets 8:32AM elan: just not SSA (at least) 8:32AM Rob Rudd: actually when i look at it i dont understand the line 8:33AM Rob Rudd: why would you increment a packet's presentation time by its own duratin 8:33AM Rob Rudd: pkt->pts += pkt->duration; 8:33AM elan: yeah, that is rather strange 8:34AM Rob Rudd: haha well I try not to think too hard about it, i'll just accept ffmpeg as some crazy voodoo magic 8:34AM elan: unless the duration somehow comes from the last packet????? 8:34AM Rob Rudd: hmm 8:35AM Rob Rudd: ya, i can't make heads or tails of it atm, im sure there must be a reason for it 8:35AM Rob Rudd: I'll prolly look into it more later this week unless you figure it all out, haha 8:36AM elan: k, thanks for the hint...if i make any headway i'll IM you

[iordonez]

according to your comment this is also closed, correct?

[bmfrosty]

Yep. Fixed.