dash_to_hls_api.cc assumes the timescale from mvhd is authoritative

[Uragawa]

It's possible for a track to have its own timescale specified in the mdhd box, not necessarily the same value as the one in the mvhd box. MP4Box is known to generate files where this issue happens.

[rbouqueau]

GPAC/MP4Box maintainer here. The technical explanation at https://github.com/gpac/gpac/issues/234#issuecomment-140026567

[noamtamim]

Similarly, sometimes the timescale value in the sidx box is the authoritative one. In our case, with a fragmented stream, each fragment has its own sidx with a timescale that is different than the one in mvhd.

[justsomeguy-google-com]

I need a clear sample with the problem.

[Uragawa]

@justsomeguy-google-com I requested it to our content division but it's taking a little longer than expected. Right now I have a .mp4 file with diverging timescales between mvhd and mdhd which has not yet been DASH'd, has no moof boxes and doesn't exhibit #3. I can provide that, along with the audio track in a different file, if it's any help. Also, I'm not allowed to post the URLs in public, may I use the e-mail address on your profile?

[justsomeguy-google-com]

When you get it into DASH go ahead and send it to me directly, justsomeguy@google.com.

Thanks

On Wed, Sep 23, 2015 at 10:36 AM, Alex notifications@github.com wrote:

@justsomeguy-google-com https://github.com/justsomeguy-google-com I requested it to our content division but it's taking a little longer than expected. Right now I have a .mp4 file with diverging timescales between mvhd and mdhd which has not yet been DASH'd, has no moof boxes and doesn't exhibit #3 https://github.com/google/universal-dash-transmuxer/issues/3. I can provide that, along with the audio track in a different file, if it's any help. Also, I'm not allowed to post the URLs in public, may I use the e-mail address on your profile?

— Reply to this email directly or view it on GitHub https://github.com/google/universal-dash-transmuxer/issues/4#issuecomment-142620932 .

[noamtamim]

@justsomeguy-google-com in the mean time, I have a test stream ready which I can share. See my above comment.

In our setup, the init segment has the mp4 headers, but not the sidx box. Instead, every fragment has its own sidx.

MPD:

http://cdnapi.kaltura.com/p/1281471/sp/128147100/playManifest/entryId/1_514vw3ly/format/mpegdash/protocol/http/uiConfId/30824441/a/a.mpd

Init segment: 

https://kalhlspd-a.akamaihd.net/dasha/p/1281471/sp/128147100/serveFlavor/entryId/1_514vw3ly/v/1/flavorId/1_,im0hef90,pgvq89kt,b2f2awxw,knrc0d0z,/forceproxy/true/name/a.mp4.urlset/init-f1-v1.mp4

First media segments of first representation:

https://kalhlspd-a.akamaihd.net/dasha/p/1281471/sp/128147100/serveFlavor/entryId/1_514vw3ly/v/1/flavorId/1_,im0hef90,pgvq89kt,b2f2awxw,knrc0d0z,/forceproxy/true/name/a.mp4.urlset/fragment-1-f1-v1.m4s

https://kalhlspd-a.akamaihd.net/dasha/p/1281471/sp/128147100/serveFlavor/entryId/1_514vw3ly/v/1/flavorId/1_,im0hef90,pgvq89kt,b2f2awxw,knrc0d0z,/forceproxy/true/name/a.mp4.urlset/fragment-2-f1-v1.m4s

For reference, the stream works fine in ExoPlayer and in Chrome.

[Uragawa]

@justsomeguy-google-com Our content division prepared a DASH video I can post publicly: http://ottvstrailer.blob.core.windows.net/dash/dhx.037467/0037467.mpd

Both #3 and #4 are present.

[justsomeguy-google-com]

I have a patch I'll upload later this week. It will check the trex if one exists and there is no duration in the trun or tfhd.

As far as the sidx, the only thing the sidx timescale should effect is the earliest_presentation_time and subsegment_duration, neither of which are used internally, so no changes there beyond the one patch noamtamim did.

[justsomeguy-google-com]

Wrong thread, sigh, too many open windows.

[justsomeguy-google-com]

But I do have a fix for this. The file you gave me plays. Everything should be good to go by the end of the week, just need an internal code review.

[noamtamim]

That's great, thanks!

[SeawardT]

This fix was pushed already. Let me know if this did not resolve your issue.