Videos not playing in Dash.js

[axiomatic-systems]

Videos not playing in Dash.js

[barbibulle]

Is it possible for you to share the media file you used as input so that I can check what may be causing this?
Also, the command line option --encryption-args="--global-option mpeg-cenc.piff-compatible:true" here won't do anything, since you are not encrypting the content (no --encryption-key command line option given).

[jenjet333]

Hi @barbibulle Thanks for your help.
The video I am using can be found at http://www.sample-videos.com/video/mp4/480/big_buck_bunny_480p_50mb.mp4

I've also tried the sintel trailer at https://download.blender.org/durian/trailer/sintel_trailer-720p.mp4 but neither have worked.

I am not using any of the pre-compiled SDKs, but compiled the code myself using the x86-unkonwn-linux release version.

Thanks again!

[ayuk23]

@barbibulle Any update on this? I'm having a similar issue

[barbibulle]

I was able to reproduce this problem on Safari browsers. Other browsers (Chrome and Firefox) work fine.
This issue only occurs for very specific types of source videos.
This example video (sintel_trailer) is encoded in a strange way, and as a result confuses the media stack on Safari. What's unusual about this video is that the display time (aka CTS) of the first video frame is not 0. This is, by itself, not forbidden, but it is quite unusual.
I have posted a report of this to the Shaka player maintainers, and they will try and come up with a workaround in their library (see: shaka-project/shaka-player#286 (comment)).

In the meantime, I would like to know if anyone has experienced the same problem either:
1/ on a browser other than Safari
2/ with a video file for which the non-zero initial CTS condition isn't present

[jenjet333]

That's odd. I get this issue for both the Sintel and Big Buck Bunny videos when I'm on Chrome. I'm also using the dash.js player and not Shaka. Do you know what might be causing the problem for Dash.js?

[barbibulle]

Can you try fragmenting the file with the following option: --fragment-duration 2000 ?
(the input files you are using don't have a fixed GOP size, so the auto-detection of the optimal fragment size may not be reliable, so you should pick a reasonable target duration for the fragments, 2 seconds in this example, in order to avoid abnormally large fragments)
ex:
mp4fragment --fragment-duration 2000 sampleVideo.mp4 fragmented.mp4

[richardbushell]

@barbibulle

I have been looking into this, and have a test case where it appears that mp4fragment is actually storing an incorrect PTS in the video file, causing this issue reported.

Here's my workflow stages below:-
(I will send you a link to the original file separately)

1. ffprobe on ORIGINAL.MP4 file: ffprobe -show_frames original.mp4 > ffprobe1.txt 2> ffprobe2.txt
   Duration: 00:03:28.76
   Start Time 0
   Video PTS 0
   Audio PTS 0

2. mp4fragment: mp4fragment --debug --trim --fragment-duration 3840 original.mp4 fragmented.mp4 > "fragmenting_log.txt"

Using track ID 1 as anchor
==== Track ID 1 - dts=0, target=49152, start=0, end=96/5219 *** THESE ARE CORRECT ***
---- Track ID 2 - dts=0, target=184320, start=0, end=90/4893 *** THESE ARE CORRECT ***
==== Track ID 1 - dts=49152, target=98304, start=96, end=192/5219
---- Track ID 2 - dts=184320, target=368640, start=90, end=180/4893
etc...
(p.s. 3840 ms is correct and exact divider for video and audio)

3. ffprobe on FRAGMENTED.MP4 file ffprobe -show_frames fragmented.mp4 > ffprobe3.txt 2> ffprobe4.txt
   Duration: 00:03:28.84 *** 0.08 seconds too long ***
   Start Time 0
   Video PTS 0.08 *** WRONG ***
   Audio PTS 0
   p.s. There's one other strange thing worth mentioning. For many frames ffprobe now shows: pkt_duration=N/A, pkt_duration_time=N/A

(After DASHing, and later in my workflow it also shows in Safari 9 console log for DASH: Video buffered from time 0.08)

We are using latest mp4fragment (607) - could that be causing this? Or is the root cause deeper?

Please advise asap...

[richardbushell]

Just checked: the same file fragmented with:
MP4Box -frag 3840...
does produce the expected 0/0/0 fragmented file.

[barbibulle]

The reason for the result you're observing is that the input media has a non-zero edit list ('elst') which isn't being replicated in the output by mp4fragment. In most cases that wouldn't be an issue, but in this case it results in a small (0.08 seconds) time offset. This will be fixed in the next release.

[richardbushell]

That would be great thanks Gilles. If you could expedite a release build asap that would be appreciated as I am also trying to test and sign-off on some related non-zero start time issues within dash.js

Thanks again for tracking this down so promptly.

[richardbushell]

This seems to be fixed now, thanks.
In answer to your 2 questions above: we have noticed a LOT of inconsistency in the handling of non-zero CTS edit lists in different browsers and dash player implementations through MSE, the reference to time zero seems to cause errors and inconsistencies in implementations (often in seeking or replay). Perhaps a flag option in mp4fragment to rebase the CTS timings to zero would be a good option? The initial CTS MediaTime delay in an edit list within an MP4 file is often caused by the AAC audio primer delay or b-frame reordering, but it would be a great feature to be able to re-base/write the first CTS MediaTime value to 0 based on a flag option, and reduce subsequent CTS values accordingly? Obviously no edit list atom would then be need to be present anyway. Would this be possible as a user flag option?

[barbibulle]

That's a good point. I'll try to add this feature soon.

[richardbushell]

Awesome, thanks Gilles. We currently see this to be the most significant missing link between the original encodings (from a variety of sources) and reliable dash playback at the end of the workflow across the many combinations of dash players and browsers. This would be a true unifier. Thank you.