Closed Bug 1301038 Opened 8 years ago Closed 8 years ago

Windows : Dash video doesn't seek in a VOD file

Categories

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

48 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: richard.pialat, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Steps to reproduce: Use any of this dash players from the following webpages: dashif.org/reference/players/javascript/v2.2.0/samples/dash-if-reference-player/index.html http://dashif.org/reference/players/javascript/1.4.0/samples/dash-if-reference-player/index.html http://bitmovin.com/hls-mpeg-dash-test-player/ http://mediapm.edgesuite.net/dash/public/support-player/current/index.html Use the following video : http://cdn-vod-dash.globecast.tv/vod/HBS-2010-2011/video5s/dash/video5s.mpd Windows7 OS Play the video and seek Actual results: The seek never occurs and the video remains frozen on the last image played. Expected results: Seek should have worked, it works fine on other browsers.
Actually it works with bitmovin http://bitmovin.com/hls-mpeg-dash-test-player/ sorry for the confusion
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Can you provide a link to the fragmented MP4 file? It looks suspiciously to me like all your frames are marked as keyframes in the MP4 container.
Hi Anthony, The ismv file is quite big. Actually all frames are not key frames. Gop size is 50 frames and so key frames are at the beginning of each gop. However I had a look at the mp4 and noticed that the stss box is not present, which may be why you think all frames are key frames according to then norm. In my opinion this could explain related bug 1301039, but even if all frames are key frames, seek should work shouldn't it (resulting in macroblocks)?
Hi Anthony, for your information, using the same fragmented mp4 as a source for HLS works fine, we can seek. It also works with shorter videos. I can provide you links for more tests but not publicly.
(In reply to Richard from comment #3) > However I had a look at the mp4 and noticed that the stss box is not > present, which may be why you think all frames are key frames according to > then norm. The file is improperly muxed if keyframes are incorrectly marked in the container. Improperly muxed files can cause problems with seeking. I don't have a link to the file to check myself. The reason seek doesn't work is because passing non-keyframes to the Windows Media Foundation decoder causes it to error. The ffmpeg decoder on Linux is less fussy so it doesn't repro there. This seems to be a common problem. What tool are you using to mux your files? We're taking steps to ameliorate the issue in another bug but you will get best results overall by fixing your file.
Hi Anthony, thank you for your answer, as explained in the other case I opened for Mac OS, I'm waiting for some feedback from our encoder provider to know how I can force the stss box to be generated. Tool is from Elemental, I've seen that the box is there on mp4, not on ismv but it may be a setup error on my side. I checked the nightly build as it seems promising on Mac but it doesn't improve seek with my files on Windows.
Hi Anthony, I confirm the nightly build is working with dash-if and bitmovin. I don't know if I didn't test correctly yesterday or if some changes occured last night but it's now OK. Thank you for the support!
(In reply to Richard from comment #8) > Hi Anthony, I confirm the nightly build is working with dash-if and bitmovin. > I don't know if I didn't test correctly yesterday or if some changes occured > last night but it's now OK. > Thank you for the support! incorrectly tagged keyframes in the container would explain why it now works on nightly as we now ignore that mp4 information and instead scan the h264 inner content to determine if a frame is a keyframe. The best solution is to properly mux your data so that keyframes are properly tagged
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Hi Jean-Yves, Sorry I didn't confirm as I missed the request. I've just tested on version 50 and seek is actually still not working on different players. Sample video is still the same one: http://cdn-vod-dash.globecast.tv/vod/HBS-2010-2011/video5s/dash/video5s.mpd I can also confirm that when I tested the nightly build in September it worked. Thank you.
The changes that ignore incorrectly tagged key frame was added in 51. In the mean time, you'll need to fix your media segments so that they are spec compliant.
You need to log in before you can comment on or make changes to this bug.