Don't assume particuliar order of AttachedFile segment

[moi15moi]

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.

[peerless2012]

Does this fix #19 ?

[moi15moi]

No, the problem with #19 is that you call ass_render_frame before ass_add_font.

[peerless2012]

No, the problem with #19 is that you call ass_render_frame before ass_add_font.

Due my test, that issue is because of MatroskaExtractor will stop parse when reach Cue tag.

Is there any mkv to test this pr?

[moi15moi]

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 FileData is before FileName and FileMediaType.

I just know that the order isn't guaranteed, but I don't have any sample.

[moi15moi]

Due my test, that issue is because of MatroskaExtractor will stop parse when reach Cue tag.

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 ass_render_frame before ass_add_font.

[peerless2012]

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 FileData is before FileName and FileMediaType.

I just know that the order isn't guaranteed, but I don't have any sample.

Is there any docs or other player process like this?

[moi15moi]

From https://www.matroska.org/technical/ordering.html

Except for the EBML Header and the CRC-32 Element, the EBML specification does not require any particular storage order for Elements.

[peerless2012]

We will kepp this pr and when we can find a mkv with this issue, then we can verify this pr and merge it.