1350200 - Crash in mp4_demuxer::MP4Metadata::GetTrackIndice with rust.test_mode

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect)

Description

[Matthew Gregan [:kinetik]]

This bug was filed from the Socorro interface and is 
report bp-95d797e4-b8d8-4381-adc7-2466f2170324.
=============================================================

On the page linked in the URL, specifically the video at https://troupster.com/wordpress/wp-content/uploads/2017/03/erethon_preview_resize.mp4, we hit the rust.test_mode check for the end_composition value.

In this case, I get for element 372 of 375, end_composition is 12533455 from mp4parse-rust (same as start_composition) but end_composition is 12600122 from stagefright:

(gdb) p indiceRust.indices[i]
$8 = {
  start_offset = 2826180, 
  end_offset = 2829445, 
  start_composition = 12533455, 
  end_composition = 12533455, 
  start_decode = 12466788, 
  sync = false
}
(gdb) p indiceSF[i]
$15 = (nsTArray_Impl<mp4_demuxer::Index::Indice, nsTArrayFallibleAllocator>::elem_type &) @0x7fff9fb065c8: {
  start_offset = 2826180, 
  end_offset = 2829445, 
  start_composition = 12533455, 
  end_composition = 12600122, 
  start_decode = 12466788, 
  sync = false
}

Alfredo, any ideas?

Comment 1

[Alfredo Yang (:alfredo)]

(In reply to Matthew Gregan [:kinetik] from comment #0)
> This bug was filed from the Socorro interface and is 
> report bp-95d797e4-b8d8-4381-adc7-2466f2170324.
> =============================================================
> 
> On the page linked in the URL, specifically the video at
> https://troupster.com/wordpress/wp-content/uploads/2017/03/
> erethon_preview_resize.mp4, we hit the rust.test_mode check for the
> end_composition value.
> 
> In this case, I get for element 372 of 375, end_composition is 12533455 from
> mp4parse-rust (same as start_composition) but end_composition is 12600122
> from stagefright:
> 
> (gdb) p indiceRust.indices[i]
> $8 = {
>   start_offset = 2826180, 
>   end_offset = 2829445, 
>   start_composition = 12533455, 
>   end_composition = 12533455, 
>   start_decode = 12466788, 
>   sync = false
> }
> (gdb) p indiceSF[i]
> $15 = (nsTArray_Impl<mp4_demuxer::Index::Indice,
> nsTArrayFallibleAllocator>::elem_type &) @0x7fff9fb065c8: {
>   start_offset = 2826180, 
>   end_offset = 2829445, 
>   start_composition = 12533455, 
>   end_composition = 12600122, 
>   start_decode = 12466788, 
>   sync = false
> }
> 
> Alfredo, any ideas?

hmm... it is the last frame of this video (in composition time order), it looks like another corner case.

Comment 2

[Alfredo Yang (:alfredo)]

This is another corner case, frame 372 and 374 have the same start_composition time == 12533455. Both rust parser and stagefright use start_composition time as key to calculate the end_composition time.

And indiceRust.indices[372].end_composition == indiceSF[374].end_composition, so I guess the difference could be from rust sort_by_key() algorithm has different behavior comparing to stagefright when the key is the same.

I can't tell which one is corrected. I'd check spec again if it mentioned any case like this.

(lldb) p indiceRust.indices[372]
(mp4parse_indice) $3 = {
  start_offset = 2826180
  end_offset = 2829445
  start_composition = 12533455
  end_composition = 12533455
  start_decode = 12466788
  sync = false
}
(lldb) p indiceRust.indices[373]
(mp4parse_indice) $4 = {
  start_offset = 2829445
  end_offset = 2830434
  start_composition = 12500122
  end_composition = 12533455
  start_decode = 12500122
  sync = false
}
(lldb) p indiceRust.indices[374]
(mp4parse_indice) $5 = {
  start_offset = 2830434
  end_offset = 2831691
  start_composition = 12533455
  end_composition = 12600122
  start_decode = 12533455
  sync = false
}
(lldb) p indiceSF[372]
(nsTArray_Impl<mp4_demuxer::Index::Indice, nsTArrayFallibleAllocator>::elem_type) $6 = {
  start_offset = 2826180
  end_offset = 2829445
  start_composition = 12533455
  end_composition = 12600122
  start_decode = 12466788
  sync = false
}
(lldb) p indiceSF[373]
(nsTArray_Impl<mp4_demuxer::Index::Indice, nsTArrayFallibleAllocator>::elem_type) $7 = {
  start_offset = 2829445
  end_offset = 2830434
  start_composition = 12500122
  end_composition = 12533455
  start_decode = 12500122
  sync = false
}
(lldb) p indiceSF[374]
(nsTArray_Impl<mp4_demuxer::Index::Indice, nsTArrayFallibleAllocator>::elem_type) $8 = {
  start_offset = 2830434
  end_offset = 2831691
  start_composition = 12533455
  end_composition = 12533455
  start_decode = 12533455
  sync = false
}

Comment 3

[Alfredo Yang (:alfredo)]

According to spec [1], I think the last two frames with the same composition time is incorrect. I don't think there is a way to know which one should be rendered first in demuxer layer.

It should be content problem.


[1] iso 14496-12 8.6.1.1, "A non‐output sample shall be given a composition time which is outside the time‐range of the samples that are output".