Repository navigation
Don't assume particuliar order of AttachedFile segment - #24
Conversation
|
Does this fix #19 ? |
|
No, the problem with #19 is that you call ass_render_frame before ass_add_font. |
Due my test, that issue is because of Is there any mkv to test this pr? |
|
I don't know how I can edit the EBML of a mkv, so I don't know how I could create a mkv where the I just know that the order isn't guaranteed, but I don't have any sample. |
For me, when I use opengl (with of course a mkv where the attachments section is at the end of the file), it sometimes show me the font and sometime it doesn't. So, that's why I think it call |
Is there any docs or other player process like this? |
|
From https://www.matroska.org/technical/ordering.html
|
|
We will kepp this pr and when we can find a mkv with this issue, then we can verify this pr and merge it. |
The previous code was assuming that, in the AttachedFile, the name and mime type were always before the data. This isn't true because the order is not guaranteed by the Matroska specification.
720a11a to
5b69689
Compare
|
As a reminder, mkvmerge always writes With this script (mkv_reorder_attachment.zip), I created a mkv where With the command Without this PR, I was getting this exception: With this PR, the mkv now play normally and we can see indeed the font. |
The previous code was assuming that, in the AttachedFile, the name and mime type were always before the data. This isn't true because the order is not guaranteed by the Matroska specification.