dash_to_hls_api.cc assumes the timescale from mvhd is authoritative about universal-dash-transmuxer HOT 12 CLOSED

GPAC/MP4Box maintainer here. The technical explanation at gpac/gpac#234 (comment)

from universal-dash-transmuxer.

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.

from universal-dash-transmuxer.

I need a clear sample with the problem.

from universal-dash-transmuxer.

@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?

from universal-dash-transmuxer.

When you get it into DASH go ahead and send it to me directly,
[email protected].

Thanks

On Wed, Sep 23, 2015 at 10:36 AM, Alex [email protected] 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
#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
#4 (comment)
.

from universal-dash-transmuxer.

@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.

from universal-dash-transmuxer.

@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.

from universal-dash-transmuxer.

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.

from universal-dash-transmuxer.

Wrong thread, sigh, too many open windows.

from universal-dash-transmuxer.

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.

from universal-dash-transmuxer.

That's great, thanks!

from universal-dash-transmuxer.

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

from universal-dash-transmuxer.