Closed Bug 1301039 Opened 8 years ago Closed 8 years ago

Mac : Dash video artifcats when seeking in VOD file

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Version:
48 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: richard.pialat, Unassigned, NeedInfo)

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 Mac OS Play the video and seek Actual results: Seek occurs (contrary to bug ID #1301038) but there are artifacts. Expected results: Artifacts should not be visible, it works fine on other browsers.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Hi Anthony, for your information, using the same fragmented mp4 as a source for HLS works fine, we can seek without macroblocks. I can provide you links for more tests but not publicly.
stream above works fine for me with Nightly. I can seek without seeing any macroblock on mac (mac pro 10.11.6) Have you changed the stream since lodging this bug? in particular did you remux it so that keyframes are properly tagged as such in the container) ?
Hi Jean-Yves, No I didn't change anything. Sorry for what may be a stupid question but what is Nightly?
It is the latest version of firefox, built nightly https://nightly.mozilla.org/ Current nightly version doesn't rely on the container's information regarding keyframes. Instead it parses the H264 streams and look at the h264 NAL and identify if a h264 frames is a keyframe or not. Stable versions of Firefox (including beta or aurora/developer edition) do not, they rely on the information containing in the MP4 container. So if a MP4 isn't properly muxed, and mark a video frame as a keyframe when it's not, you will get problem when seeking, as determining the keyframe is essential for seeking to work properly.
That's clear! Do you know if this is a feature that is planned to be included in future versions? If this is the case any idea on the roadmap? Thank you.
Every 6 weeks, what is current nightly becomes developeredition/aurora, aurora becomes beta and beta becomes release... So it's just a matter of time for the fix to make its way to release. Now if you could try yourself that would help confirm that this is why I'm not seeing the problem. And if you don't see it, all it means is that you need to fix your MP4; ultimately that's where the problem is and we won't be the only players/browser having issues seeking.
I've opened a case at our encoder's provider to know if it's a bug on their side or if I missed a setup, still waiting for their feedback though. It's true that the problem is on all the players when using FF. There has been a fix on Chrome in the same way you plan to do it (they don't rely on the presence of the stss table anymore if I understood correctly). Seek also works fine with Edge (on Windows). And I'm not saying the issue is on FF, I understand that my mp4 misses an important table which should be there according to the specs, but it seems that I'm probably not the only one facing it as some workarounds/other checks seem to have been deployed elsewhere. However I am glad to know that even if no date is presently announced, it will be in a future release and I will also try on my side to get a fix on the fragmented mp4 we use!
we do not use the stss box either. It's not compulsory as part of ISOBMFF. We only rely on the default flags or the flags sets in the sample table (found in each moof) It will work fine with EDGE, because you're on windows and the WMF decoder drops frame it can't decode. You'll find that it will work okay with Firefox on Windows too. The Apple VideoToolbox decoder doesn't behave in the same fashion; it will either returns an error or return a corrupted frame (which is what you are seeing) The only way to fix this issue properly, is for you to fix the mp4.
And by the way I've just tested the stream with Firefox' release and I have macroblocks which are not there anymore with the nightly build. it confirms the test you've done earlier. Thank you for the support.
Flags: needinfo?(richard.pialat)
I'm going to mark it as closed. Feel free to re-open it if it still occurs.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Hi Anthony, 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.
(In reply to Richard from comment #12) > I can also confirm that when I tested the nightly build in September it > worked. > Thank you. In September, Nightly was FF51, not 50, so the fix is probably not yet in FF50.
You need to log in before you can comment on or make changes to this bug.