600006 - Flash cannot load video when response is Transfer-Encoding:chunked

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Simon Levesque]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

If you open an mp4 video with Flash and the video is given through Transfer-Encoding:chunked, Firefox will download the full video, but it will never be played in the Flash player (for Flash, the video is unavailable).

Workaround:
When in the response header the content-length is specified, all is working fine. Unfortunately, I am using Google App Engine with the Blobstore and it cannot give the content-length (if I specify it, it will be deleted)

Reproducible: Always

Steps to Reproduce:
1. Open a SWF file that will load a video
2. The video must be transfered by chunk without the content-length specified
Actual Results:  
Flash considers the video as being unavailable

Expected Results:  
The video should play

As far as I can see, it is only happening on the Windows version of Firefox. The Linux version is fine.

Also, all is fine with IE and Chrome

Comment 1

[Simon Levesque]

Someone told me that the Mac version has the same issue. The useragent is Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

Comment 2

[Keith]

Hi,
I want to confirm this bug. I found this bug to be occurring in both browser versions I've tested. And with two different versions of the Flash plugin (an older 10.1.x one and the current 10.2.x one).

The specific versions I've tested are:
Windows Firefox 4.0 beta 11 with both flash versions.
Windows Firefox 3.6.13 with both flash versions.

Adobe Flash 10.1.x something, can't remember really.
Adobe Flash 10.2.152.26, newest at time of writing.

JWplayer 5.4.1530
FlowPlayer 3.2.6

Also I can confirm Windows version of SRware Iron (Chromium browser clone) is not affected. Haven't checked IE though.

Further technical info (totally acceptable to tl;dr here): 
In my case without the Content-Length header, in Iron, the player's progress bar did not progressively fill with a darker color (a sign that more buffered data is available) and I was not able to seek in the video (not backward, not forward).
When Content-Length was sent, the darker color appeared as normal and seeking was possible.

Without Content-Length, in FF, the loading screen in JWplayer kept on going while the video was downloading and also after the download had finished.
With Content-Length, in FF, the video started and played like in Iron.

Cause/Fix:
I experienced the problem on a server using Apache2. GZip compression was enabled on all content (also my mp4 video).
According to rfc2616 (section 4.4 list item 3) when the transfer size is not identical to the content size the Content-Length header should not be sent by the server and should be ignored by the client (see http://www.ietf.org/rfc/rfc2616.txt).
This means Apache2 behaves in compliance with the RFC in not including the Content-Length even for static content when it is gzipped for transfer.

Quick fix was disabling gzip compression on the mp4 content, this was also the better option because compressing a h264/aac mp4 is largely useless.

To be sure I fabricated an example which was not compliant with the RFC. Gzip compression and a Content-Length which was identical to the content size (not the transfer size), this worked in FF. When omitting the Content-Length header and keeping the content gzipped the player kept loading but never plays. So FF and/or Flash is not in compliance with the RFC here IMHO.

Quirks I've experienced:
FLV vs MP4:
In my experience an FLV file will always play in FF, but without the Content-Length header in JWplayer it takes 2 clicks to start playing. The first click will start the video download and will return instantly and stop the player while the download keeps going. The next click will start playing the video, even while it's being downloaded.
Strange thing is, the progress bar is filled almost instantly with the darker color signaling the video is completely buffered even when I can see it's still downloading.
Seeking is also quirky, it works for backwards seeking and seems to work till the part that is already transferred. Beyond that will stop the player and playback can be started again by clicking play.

When Content-Length is given, all appears to work smoothly. Only one click needed and the progress bar progressively fills with the darker color and seeking doesn't stop the player.

Transfer speed:
When the transfer speed is fast enough (it's quirky, break-of-point for flv is around 500kB/s) the flv video's would play in FF. This can be a timing issue with chunked transfers in Apache, but I have no evidence.

Moov atom in mp4:
My MP4's have been crafted so that the moov atom is at the beginning of the file and should be available early in the transfer. Flash streaming should be possible with these files, as portrayed by Iron.

Comment 3

[Wayne Mery (:wsmwk)]

Reporter, can you still reproduce using a current version?
If no, please set status to RESOLVED and resolution to WORKSFORME.
If yes, please provide updated information.

Comment 4

[Simon Levesque]

I don't have any sample available since it makes 3 years I opened that defect. At that time, the provided URL was a quick way to test it, but I am now using Youtube to stream my videos.

I will close it then...