1149487 - Progressive media streaming spawns a lot of byte range requests

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[joost]

Attachment: Build info from a firefox instance that does not work.

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Steps to reproduce:

I have provided a permanent link to a resource that does not work: http://platform.vixyvideo.com/start/0_ihi1bnx7_0_grjfkc77_2.mp4

Play the resource directly in firefox. Then seek. 


Actual results:

Firefox spawns a ostensibly random amount of byte-range requests some time out, some don't. 


Expected results:

Exactly one byte range request should have been spawned.

Comment 1

[joost]

Since I can't upload anymore attachments, here is the build info for my Linux based Firefox that does not display these symptoms:

about:buildconfig
Build Machine

aatxe
Build platform
target
x86_64-pc-linux-gnu
Build tools
Compiler 	Version 	Compiler flags
gcc 	4.8.2 	-Wall -Wdeclaration-after-statement -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
c++ 	4.8.2 	-Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -Os -fomit-frame-pointer
Configure arguments

--host=x86_64-linux-gnu --prefix=/usr --libexecdir=/usr/lib/firefox --with-l10n-base=/build/buildd/firefox-36.0.4+build1/./l10n --srcdir=/build/buildd/firefox-36.0.4+build1/. --enable-release --disable-install-strip --disable-updater --enable-application=browser --enable-startup-notification --with-distribution-id=com.ubuntu --enable-optimize --enable-tests --enable-crashreporter --with-branding=browser/branding/official --disable-gnomevfs --enable-gio --enable-update-channel=release --disable-debug --disable-elf-hack --enable-gstreamer=1.0 --with-google-api-keyfile=/build/buildd/firefox-36.0.4+build1/debian/ga --with-google-oauth-api-keyfile=/build/buildd/firefox-36.0.4+build1/debian/go

Comment 2

[joost]

Attachment: unnamed.jpg

Debug tools > network result from a Firefox build that does not work.

Comment 3

[joost]

I have recorded the behaviour in a screenshot: http://platform.vixyvideo.com/start/error.png

And recorded the traffic server side into this tcpdump file http://platform.vixyvideo.com/start/firefoxbug.cap

Comment 4

[max.schnur]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0

Firefox version was more specifically 37.0.2.

I was able to reproduce this issue on Mac OSX with another file too, by simply visiting this URL:

http://embed.wistia.com/deliveries/445225ab0b0309a8e75c5f324cf1cf0f73338feb/file.mp4

This file is encoded with the same settings as thousands of other videos in our system, but it seems to happen more frequently with this one than others.

Note that I wasn't able to make it happen under normal bandwidth conditions. I used CharlesProxy to throttle my network speed to 1000kbps with 150ms of latency.

Here are my CharlesProxy throttling settings:
http://embed.wistia.com/deliveries/83197605fcad62be77bdee330c2397bf881b3480.jpg?image_resize=500

Here is the cascade of byte range requests:
http://embed.wistia.com/deliveries/7959f6857c2eb59152a5eb550bee6085ace249bd/file.jpg

Here is what one of the requests looks like:
http://embed.wistia.com/deliveries/849f3323489c6d83cc40b2f82e4dd5033399fa53/file.jpg

While you can see the request is being made from a byte range to the end of the file, and the response is trying to deliver that request, the size of the data does not correspond to the byte range.

I checked on the server side and noted that our load balancer reported "CD" (Client Disconnected), so it appears that Firefox is aborting the request early for some reason.

I tested these requests using Edgecast, Highwinds, and Akamai CDNs, as well as streaming directly from our origin server. I also tested using the same video with slightly different encoding settings from Vimeo. In all cases, as long as available bandwidth was low, they exhibited the same problem.

Under low bandwidth conditions, I would expect Firefox to still make a byte range request or two, but it should wait until the server sends a substantial amount of data before making another one.

Comment 5

[Andrei Purice]

Marking this issue as Resolved > Incomplete since the reporter cannot be contacted further to provide an answer if the issue is still occurring.
Please feel free to re-open or file a new bug if anyone is still encountering this issue.