1279507 - Estonian Public Broadcasting HTML5 live stream TV video fails to load with FF 47.0 (OK with 46.0.1, 48.0b1)

Status: RESOLVED WORKSFORME

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

Description

[kivirynta]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

1. Create a clean profile.

2. Navigate to the http://otse.err.ee/k/etv/ live stream.


Actual results:

The live stream video does not load even after a long wait. You can see in the Network Monitor that after the initial traffic that includes a few mp4 chunk downloads, there are repeated GETs of DASH manifest_?????.mpd from wowza3.err.ee, without any more chunks getting downloaded from etvstream.err.ee or the stats getting updated at errstream.spring-tns.net.

NOTE: the programs marked with a blue bug icon in the TV schedule on the right-hand side are geoblocked outside Estonia and you may need to retry your test when a program is not blocked.

FWIW, Estonian Public Broadcasting/ERR is for Estonia what the BBC is for the UK and ETV is its primary channel, so this could potentially affect quite a few people in Estonia.




Expected results:

The live stream should load after a few seconds. This is what happens in both 46.0.1 and 48.0b1 with a clean profile on the same system.

Comment 1

[Loic]

I'm just testing a program which is not georestricted, and the player works fine.

Could you try with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[kivirynta]

(In reply to Loic from comment #1)
> I'm just testing a program which is not georestricted, and the player works
> fine.

In my testing, 47.0 has worked a couple of times, but that's <5% of the tries (I've lost count of the exact total, should be approaching 100 by now), whereas 46.0.1 and 48.0b1 haven't had a single failure yet. There's a huge version-specific discrepancy in the success rate. I wouldn't have created the bug if the failures were intermittent or even 50/50, but trying without success for 10 minutes in a row is not normal, especially when 46.0.1 and 48.0b1 have no problems in parallel testing during the same time period (to rule out network issues). Obvious things like restarting the PC, uninstalling and reinstalling the browser, etc. have made no difference in this.

> Could you try with a fresh profile, please.
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles

Thanks for the instructions, but I already did, with many fresh profiles in fact:
>> Steps to reproduce:
>> 
>> 1. Create a clean profile.

Comment 3

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

Works for me. Can you please paste in the graphics section of about:support?

Comment 4

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

This looks like a weird networking issue in that the site is unreliably available in 47. Stranger than fiction.

Comment 5

[kivirynta]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #3)
> Works for me. Can you please paste in the graphics section of about:support?

I tried it just now, and it worked for my 47.0 as well. The notable difference is that now, for the same live program, both 47.0 and 48.0b1 are getting served MPEG-2 video (video/MP2T, .ts chunks), whereas 46.0 still gets MPEG-4 (video/mp4, .m4s chunks). At the time I was having problems, all three were getting MPEG-4 streams. Just in case, I tried each version both with all the GMP plugins disabled (and their folders deleted) and with all of them enabled - it didn't make a difference in terms of getting served MPEG-2 or MPEG-4.

This sort of solves my immediate problem, as I can now use 47.0 to watch these streams. It's unfortunate to not be able to choose between LD/SD/HD like it's possible with MPEG-4, but at least they play.

I suppose it's up to you guys if you want to continue investigating why 47.0 was faring badly with ERR's MPEG-4 streams - if there's some way to tweak the settings to still get the server to send them to it.

I any case, here's my graphics setup from 47.0's about:support that you asked for:

Graphics
--------

Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Adapter RAM: Unknown
Asynchronous Pan/Zoom: none
Device ID: 0x2a42
Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled: false (6.1.7601.17514)
Driver Date: 2-11-2011
Driver Version: 8.15.10.2302
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 02bc1028
Supports Hardware H264 Decoding: Yes
Vendor ID: 0x8086
WebGL Renderer: Google Inc. -- ANGLE (Mobile Intel(R) 4 Series Express Chipset Family Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasAccelerated: 0
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo

Comment 6

[Patrick McManus [:mcmanus]]

could be a dup of bug 1277522 which is marked as fixed 47 but I don't think that's actually true from looking at the checkins. (it is still nom'd release?).. I just looked at the repo and it definitely isn't fixed on 47.

it is fixed in 48, so that would explain the behavior.

if dragana agrees we can dup this and ping ritu about any ride along chances.

an http log of a failure could be used to confirm https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 7

[Dragana Damjanovic [:dragana]]

bug 1277522 was pushed to beta only yesterday, so that could not have fixed it.

I could not reproduce it on Mac with 47.
Can you please make http log:  
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 8

[kivirynta]

FYI, you can still get the MPEG-4 stream in 47/48 by faking the user agent string of 46.0, e.g. "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0". And it still fails in 47.0, and still works in 48.0b1.

Trying with plain 47.0 should always work now, because it gets the MPEG-2 stream.

I'll have to do the HTTP log a bit later since I unfortunately didn't see the request prior to doing my user agent tests.

Comment 9

[kivirynta]

Attachment: FF 47.0 HTTP log on otse.err.ee (video/MP2T stream)

Comment 10

[kivirynta]

Attachment: FF 47.0 HTTP log on otse.err.ee (video/mp4 stream)

I've added the HTTP logs you asked for.

For the video/MP2T stream (47_http_log.7z):
1. Created a clean profile.
2. Ran FF once to close all welcome pages.
3. Ran FF with HTTP logging and went to otse.err.ee.

For the video/mp4 stream (47_as_46_http_log.7z):
The same, except
2b. Added to prefs.js
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0");

Comment 11

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

Patrick - can you take a look at the logs to see if we need to uplift bug 1277522 in release?

Comment 12

[Patrick McManus [:mcmanus]]

bug 1277522 was included in 47.0.1 (very recently).

Comment 13

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

kivirynta - is this working again for you?

Comment 14

[kivirynta]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #13)
> kivirynta - is this working again for you?

As I said before in comment #5, from a user prespective this is no longer a problem for me as after ERR started sending FF47 video/MP2T, the stream works OK for me. They've even re-added the LD/SD/HD quality selector since then.

From a technical perspective, 47.0.1 appears to have changed nothing compared to 47.0 - the video/mp4 stream (accessible by faking the 46.0 UA) still fails for me as before. So, it's really up to you guys if this is something you still want to try to investigate or not.

Comment 15

[Dragana Damjanovic [:dragana]]

The log that you have uploaded is for 47 and video/MP2T, which works. Can you make a log with 47 and video/mp4 stream (in comment #14 you wrote that is still failing)?

Comment 16

[kivirynta]

(In reply to Dragana Damjanovic [:dragana] from comment #15)
> The log that you have uploaded is for 47 and video/MP2T, which works. Can
> you make a log with 47 and video/mp4 stream (in comment #14 you wrote that
> is still failing)?

Doesn't the log from comment #10 fit the bill?
> Created attachment 8764884 [details]
> FF 47.0 HTTP log on otse.err.ee (video/mp4 stream)

Comment 17

[Dragana Damjanovic [:dragana]]

(In reply to kivirynta from comment #16)
> (In reply to Dragana Damjanovic [:dragana] from comment #15)
> > The log that you have uploaded is for 47 and video/MP2T, which works. Can
> > you make a log with 47 and video/mp4 stream (in comment #14 you wrote that
> > is still failing)?
> 
> Doesn't the log from comment #10 fit the bill?
> > Created attachment 8764884 [details]
> > FF 47.0 HTTP log on otse.err.ee (video/mp4 stream)

Sorry, I misunderstood...

The second log is for 47 receiving mp4 stream.

From the http log I do not see any problem. All network request are completed. At some point we do not get any new requests.
The only think that is strange is that nsHttpChannel are only destroyed at the end of the log, probably shutdown.

So not a necko problem. It would be interesting to know why 47 does not work with mp4.

Comment 18

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

Jean-Yves - do you know anything that may have caused this issue in 47?

Comment 19

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

Can we close this now that 48 is out?