1206948 - HLS demo video is much smaller in Firefox than in Chrome, IE, or Edge

Status: RESOLVED INVALID

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

Description

[Chris Peterson [:cpeterson]]

In bug 577084 comment 15, Ingvar linked to his HLS demo. However, the video that is played back is much smaller in Firefox (38 and 40–44, Windows and OS X) than it is in Chrome, IE, or Edge. The video does not work in Safari.

http://rreverser.github.io/mpegts/

Comment 1

[Chris Peterson [:cpeterson]]

Attachment: chrome-screenshot.jpg

Chrome screenshot

Comment 2

[Chris Peterson [:cpeterson]]

Attachment: firefox-screenshot.jpg

Firefox screenshot

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3

Comment 4

[Alfredo Yang (:alfredo)]

Well, this problem is in onloadmetadata in firefox, when fire onloadmetadata, the video dimension is 16x32 before the first frame is decoded. After discussed with some media peers, they think this is correct behaviour. Script author should not expect to get the "real" video dimension in onloadmetadata. In other word, the video dimension in onloadmetata may be different with following decoded frames.
Although I'd like to fix it. But it seems I can't persuade peers for it.

So here I'd suggest author should check onloadeddata instead of onloadmetadata. onloadeddata makes sure the first video frame is decoded and the correct video dimension can be retrieved.

Thanks to :vliu help to clarify this problem.

Comment 5

[JW Wang [:jwwang] [:jw_wang]]

Attachment: Bug 1206948 - delay the notification of metadata to guarantee video size is correct when 'loadedmetadata' is fired in non-MSE case.

Review commit: https://reviewboard.mozilla.org/r/65812/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/65812/

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

Comment on attachment 8773138 [details]
Bug 1206948 - delay the notification of metadata to guarantee video size is correct when 'loadedmetadata' is fired in non-MSE case.

This patch fix the problem. I think this is an evangelism bug and we should ask the site developer to make changes to produce correct output to the user.

However, despite we are spec-conformant, I want to delay the notification of metadata until the 1st frame is decoded to ensure we have correct video size when 'loadedmetadata' is fired to reduce the impression that Chrome works but Firefox doesn't.

Hi Chris & Jya,
Can you share thoughts about this approach? Thanks.

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to JW Wang [:jwwang] from comment #6)
> This patch fix the problem. I think this is an evangelism bug and we should
> ask the site developer to make changes to produce correct output to the user.

The site developer, Ingvar Stepanyan (RReverser) <[e-mail]>, is CC'd on this bug. The source code is on GitHub:

https://github.com/RReverser/mpegts

Comment 8

[Alfredo Yang (:alfredo)]

(In reply to Chris Peterson [:cpeterson] from comment #7)
> (In reply to JW Wang [:jwwang] from comment #6)
> > This patch fix the problem. I think this is an evangelism bug and we should
> > ask the site developer to make changes to produce correct output to the user.
> 
> The site developer, Ingvar Stepanyan (RReverser) <[e-mail]>, is CC'd
> on this bug. The source code is on GitHub:
> 
> https://github.com/RReverser/mpegts

https://github.com/RReverser/mpegts/pull/32

Comment 9

[Jean-Yves Avenard [:jya]]

https://reviewboard.mozilla.org/r/65812/#review63420

I don't like the idea of having different behaviour depending on the container.
Plus, isn't the HLS stuff using MSE anyway? so that wouldn't fix it for that case if that's so.

Comment 10

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Jean-Yves Avenard [:jya] from comment #9)
> Plus, isn't the HLS stuff using MSE anyway? so that wouldn't fix it for that
> case if that's so.

No. HLS doesn't use MSE. Otherwise, the patch will never work.

Comment 11

[Jean-Yves Avenard [:jya]]

Comment on attachment 8773138 [details]
Bug 1206948 - delay the notification of metadata to guarantee video size is correct when 'loadedmetadata' is fired in non-MSE case.

https://reviewboard.mozilla.org/r/65812/#review63816

This is already the case for non MSE video, we must decode the first frame first to get the start time. loadedmetadata will only be fired once the first frame has been decoded and the exact dimensions size are known.

With MSE many players rely on loadedmetadata to be fired as soon as the init segment is loaded.

Comment 12

[Jean-Yves Avenard [:jya]]

(In reply to JW Wang [:jwwang] from comment #10)
> (In reply to Jean-Yves Avenard [:jya] from comment #9)
> > Plus, isn't the HLS stuff using MSE anyway? so that wouldn't fix it for that
> > case if that's so.
> 
> No. HLS doesn't use MSE. Otherwise, the patch will never work.

Well it should :) (use MSE) that's what MSE is for.

Comment 13

[Jean-Yves Avenard [:jya]]

The proper fix would be to have the moov atom originally created to have the proper dimensions to start with...

IMHO, this HLS player takes the wrong approach and will never work properly on browsers other than maybe chrome due to particulard in their implementation and their use of ffmpeg.

There is no mechanism in place for a plain media element (including mp4) to handle change of resolution, change of content or change of audio. It's doomed to fail anyway. You will never be able to make it work properly. There is no requirement to support fragmented MP4 outside of MSE.

MSE provides all that is needed and is currently the only W3C supported method for adaptative streaming.