Skip to content

Commit

Permalink
Fix assertion failure in create_sample_table triggered by fuzzing.
Browse files Browse the repository at this point in the history
Before 4499bc5, create_sample_table returned None if Track had no timescale
present.  After 4499bc5, it tries to create a dummy zero timescale instead.

This dummy timescale always uses 0 for the track id, which is invalid for
all other track ids and will eventually trigger an assert in
[track_time_to_us](https://github.com/mozilla/mp4parse-rust/blob/da2cb93d3cebbac2644907633b51fc5366a0cf76/mp4parse_capi/src/lib.rs#L605).

One solution is to create the dummy timescale using the current track's id
instead, but given the current code has been shipping for several years
without triggering this assert (outside of fuzzing), I don't believe we need
to use a dummy timescale for valid files. Given that, it seems better to
revert to the old behaviour of returning None from create_sample_table.
  • Loading branch information
kinetiknz committed Mar 11, 2020
1 parent e35ec78 commit 63ca8c6
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion mp4parse_capi/src/lib.rs
Expand Up @@ -1277,7 +1277,7 @@ impl<'a> SampleToChunkIterator<'a> {
fn create_sample_table(track: &Track, track_offset_time: i64) -> Option<Vec<Mp4parseIndice>> {
let timescale = match track.timescale {
Some(ref t) => TrackTimeScale::<i64>(t.0 as i64, t.1),
_ => TrackTimeScale::<i64>(0, 0),
_ => return None,
};

let (stsc, stco, stsz, stts) = match (&track.stsc, &track.stco, &track.stsz, &track.stts) {
Expand Down

0 comments on commit 63ca8c6

Please sign in to comment.