Tracks are not required to be ordered by track id in the MOOV box

[udoprog]

Trying to decode such a file currently panics on this assertion:
https://github.com/alfg/mp4-rust/blob/master/src/reader.rs#L69

There's two possible solutions I can imagine:

1. Sort the tracks after reading them - this does however mean that there must be a hard requirement in the spec that track ids are contiguous.
2. Maintain a separate indexing from track_id to index to allow fns such as sample_count which uses the track_id to work like a HashMap<u32, usize>.

Personally I'd go for option 2.

[alfg]

Hi @udoprog,

Thanks for catching this. Option 2 sounds like a good idea. Maybe a track_id and track_idx. I'll check into this when I get a chance.

Edit: Also, thanks for your PRs. I'll try them out soon and merge. Jenkins queue is really backed up today. 😞

[udoprog]

Thanks, if you'd like I can do 2 as well.

You already seem to have GH Actions in place, so removing Travis might be an option if it's causing issues!

[alfg]

Contributions are welcome. :)

And yeah, GH Actions will probably have to do for now, but I'm sure the Travis queue will catch up tonight for the stable, beta and (optional) nightly Rust builds.

[nlfiedler]

In the mean time, would it make sense to replace the assert with a return of an Err result? That seems more suitable for a library.

[alfg]

Yeah, good catch. That should be updated to return Err.

[alfg]

#58