Closed Bug 1198062 Opened 9 years ago Closed 9 years ago

Firefox only presenting 360p resolution

Categories

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

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox40 --- affected
firefox41 --- affected
firefox42 --- affected
firefox43 --- affected

People

(Reporter: jya, Unassigned)

References

()

Details

(Whiteboard: parity-chrome,parity-ie)

When playing this video, we only show in the available resolution 360p.

Chrome shows all resolutions (from 144p to 1080p).

The reason for this is that YouTube queries mediasource.IsTypeSupported in order to determine if a video is supported or not.

They use the following mimetype:
video/mp4; codecs="avc1.4d0000"
or:
video/mp4; codecs="avc1.640000"

And our DecoderTraits::CanHandleCodecsType will return false if the level isn't >= LEVEL_1 amd <= LEVEL_5_1.
Because of this, YouTube doesn't present the resolution for such codec.

According to: According to RFC6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types (http://tools.ietf.org/html/rfc6381#section-3.3), codecs paremeters for H.264 are contained in the "avc1" sample entry, and are is represented as follows:

avc1.PPCCLL

PP = profile_idc
CC = constraint_set flags
LL = level_idc

According to Rec. ITU-T H.264 (02/2014), A.3.1 Level limits common to the Baseline, Constrained Baseline, Main, and Extended profiles

Table A-1 – Level limits:
shows that a level is a value between 1 and 5.2.

There is no specification about what a level 0 would be.

The only exception I could find was in "RTP Payload Format for H.264 Video" (rfc6184) I can read: "If no profile-level-id is present, the Baseline profile, without additional constraints at Level 1, MUST be inferred.".

I can find no other reference that a level_idc value of 0 is okay.
	
I believe our implementation is okay, and that video/mp4; codecs="avc1.4d0000" is an invalid mimetype.
However, it's not a black & white case, and there is potential room for a different interpretation.

Chrome and Safari accepts such mimetype, and as such they present all resolutions.
Chris, why do you think this bug is blocking 1193485?
Flags: needinfo?(cpeterson)
Bug 1193485 looks like it might be a duplicate of this bug, but I wanted to get a test case from that bug's reporter before closing it. In the meantime, I wanted to link these bugs in Bugzilla so people interested in either 360p bug would be CC'd on bugmail.

But if you feel bug 1193485 is a duplicate, feel free to close it. :)
Flags: needinfo?(cpeterson)
This YouTube bug affects all Firefox channels.
In my Windows VM, IE11, Edge, and Chrome default to 360p, but switch to 720p after playing for a few seconds.
Priority: -- → P1
Whiteboard: parity-chrome,parity-ie
That may just be a bandwidth thing.
Check the available resolutions after the page has loaded.

In this case only 360p is available at all. No other resolutions are available to Firefox.
Safari doesn't validate the value of the codecs parameter at all (Give it a nonsense value like "notavideo.ffffff" and it reports that it can play it), Chrome and Edge only do basic validation of the parameter (Does it start with "avc1" or "avc3") and ignores the "PPCCLL" segment entirely.
Youtube has now updated the video and it's working properly. (Did someone contact them?)

Perhaps the question then is, do we want or need to change the way we validate codecs?
Would it be advantageous or a bad idea to be more permissive in this circumstance?
(In reply to Caspy7 from comment #7)
> Youtube has now updated the video and it's working properly. (Did someone
> contact them?)

I contacted YouTube, but they haven't confirmed whether they fixed the problem. But it sounds like they have.


> Perhaps the question then is, do we want or need to change the way we
> validate codecs?
> Would it be advantageous or a bad idea to be more permissive in this
> circumstance?

I think we can stick to the spec, even though Chrome, Safari, and IE don't. This bug hasn't been a widespread problem and we've been able to convince the content providers to fix their content (so far). :)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to Chris Peterson [:cpeterson] from comment #8)

> This bug hasn't been a widespread problem and we've been able to convince
> the content providers to fix their content (so far). :)

:-/

Please, instill me with more of your confidence.
Confirmed, YouTube now queries the MediaSource.IsTypeSupported with valid mimetype

1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/webm; codecs="vp9")[not supported] 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; width=640)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; width=99999)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/webm; codecs="vp9")[not supported] 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; height=360)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; height=99999)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/webm; codecs="vp9")[not supported] 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; framerate=30)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; framerate=9999)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/webm; codecs="vp9")[not supported] 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; bitrate=300000)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e"; bitrate=2000000000)OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d4015")OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401e")OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401f")OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d401f")OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.640028")OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=audio/mp4; codecs="mp4a.40.2")OK 
1954161408[10060a3c0]: MediaSource(0)::IsTypeSupported: IsTypeSupported(aType=video/mp4; codecs="avc1.4d400c")OK
Yep, a (very small) subset of videos had bogus profile/level indications. New videos are fixed, old ones will be backfilled.
You need to log in before you can comment on or make changes to this bug.