Order Now AdSolution Sign Up | Login » Bits on the Run Sign Up | Login »

Forums

/

Mod-H264-Apache with Django proxy with JWPlayer5.7

20 replies [Last post]
Reply

Streaming is working with the h264 apache module, and I am even able to proxy the MP4 stream through Django. I can open the streaming video url in Firefox, with or without a timestamp, and it streams instantly (not using a player, just opening the MP4 url in Firefox).

But when we try to use JWPlayer5.7, smaller videos (around 300MB) wait until they are completely downloaded before playing, and large videos (around 700MB) lock up the player, and won't play at all, or return any debug metadata when we enable it. With older versions of JWPlayer (probably a year old or more) and videos that are around 300MB, the video opens slowly, but we are able to jump around in the file before it downloads the whole video file. There is just a delay. Large videos still don't work.

I've looked in the apache logs at the requests made to the Django proxy, and the timestamps are being requested for the smaller videos on older version of JWPlayer, but not for 5.7.

Here is the configuration we are using:

jwplayer("media").setup({
    modes: [
           {type: "flash", src: "http://www. example.com /media/scripts/player.swf"},
   {type: "html5"}
   ],
    file: "http://www. example.com /example_movie.mp4",
    width: 702,
    height:490,
    provider: 'http',
    'http.startparam':'start',
    mediaid: 'example_movie.mp4',
    image: 'http://www. example.com /?.jpg',
    'plugins' : {'metaviewer-1': {
'position': 'left',
'size': '200'
}
}
  });

Here are the response headers:

HTTP/1.1 200 OK
  Date: Fri, 16 Sep 2011 19:19:57 GMT
  Server: Apache/2.2.8 (Ubuntu) mod_python/3.3.1 Python/2.5.2 PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch
  Content-Length: 411576731
  ETag: "a765037a5e53464793a1672aacba6e6e"
  Content-Type: video/mp4
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
Length: 411576731 (393M) [video/mp4]

Any ideas on what could be the problem?

Reply

IS the MOOV atom (the metadata) of the MP4 placed at the front? It sounds like this is placed at the end, causing JW Player to load the entire video before it knows the metadata/timestamps.

Reply

Yes, I've verified it by looking at the file with a hex editor.

Also we had a problem at one point where the metadata was at the end of the file, and the player wouldn't request timestamps. Then we used qt-faststart to move the data to the front of the file, and it started requesting timestamps. So that is not the issue here.

Reply

Hmm, then I wouldn't know quickly what could be the issue. Do you have a live example?

Reply

Unfortunately no. We only release live beta versions of things once we get them working. All of our development sites are internal.

Reply

Perhaps a specific page with just a video that illustrates the problem? It's hard for me to guess what's going wrong without an example ...

Reply

I am working on that right now. I will hopefully have it available in the next few days. Thanks for the help! Is there any way I can contact you once I've got the example up?

Reply

Yes, you can email me through jeroen [at] longtailvideo.

Reply
Reply

It does seem like there's an issue with the MOOV atom. When looking at an inspector window, the player indeed tries to load the entire video while buffering. This wouldn't happen if the MOOV was at the front.

The server is also returning mod_python errors when trying to load the video directly: "TypeError: can't pickle generator objects".

Have you tested this setup with another video, e.g. a small clip that does have the correct metadata? Something like this one:

http://content.bitsontherun.com/videos/nPripu9l-DaVyfMJc.mp4

In general, I'd also remark that using HTTP downloads for long clips gives not the best user experience. Since there's so much metadata (so many keyframes) in the video, buffering will always take a long time. If you use an RTMP server instead (like Wowza or Amazon Cloudfront), this issue won't be there.

Reply

I think we fixed it! We removed the user-data box (udta) and now the video plays. It's a little wonky because the video is so huge, but it works!

http://h264.code-shop.com/trac/discussion/topic/261#message1161

Reply

The video doesn't seem to sync up to audio until the entire video gets downloaded though? Any idea why that would be?

http://beta.texashistory.unt.edu/ark:/67531/metatest904/m1/1/

Reply

Hmm, one of the metadata entries can be the audio_offset. Now that's probably also located at the end ....

A tool like qt-faststart should fix all metadata-at-end issues. Did you try something like that?

Reply

Yes, and I've verified it with a hex editor. I mentioned that in a previous post above.

I've asked about video configurations in many channels and forums, and qt-faststart is equivalent to asking "Did you try turning it off and on again?" from the IT Crowd: http://www.youtube.com/watch?v=nn2FB1P_Mn8

Reply

It absolutely is - sorry for that. But it also fixes 99% of user's questions. I guess in your case there's still something different with the metadata from what Flash expects, otherwise the audio wouldn't jump into sync when the last byte is loaded. Not sure how to profile/fix though ...

Reply

Here is what I've gathered so far. The videos work with some browsers on some operating systems, but not all of them:

http://beta.digital.library.unt.edu/ark:/67531/metatest904/m1/1/

So far it works on:
Chrome - Ubuntu (chrome 14) and Windows (chrome 15)
Firefox - works in Windows only (Firefox 7) Doesn't work on Ubuntu (Firefox 3.6)
IE 9 - Gives an error saying "The video playback was aborted due to a corruption problem or because the video used features your browser did not support: http.//.........mp4"
Haven't tested it in Safari

The browsers that it doesn't work in (aside from IE, where it is just completely broken) it has to download the entire video before the audio and video syncs up and the video starts playing normally.

Any idea why it might work in jwplayer in some browsers+operating systems and not others?

Reply

There is definitely something wrong with the MP4 files, just difficult to tell what. I'm sorry, this jumps a bit too far into encoding, so I don't know...

Reply

I will try to get some ffmpeg people to help then, and hopefully report back some positive findings. Thanks.

Reply

Solved!

Removing the "udta" from the video is what made the video work. Other browsers weren't working because of user error. My version of flash wasn't working properly for Firefox on Ubuntu, apparently, so I re-installed that and it works fine.

Also we thought it wasn't working in IE either, but it was because when we were trying to emulate IE 8 and IE 7, we were doing it using the IE 64 bit version, which automatically tries to use HTML5. When we ran the 32 bit verion of IE and emulated the older versions (IE 7 and IE 8), it worked perfectly.

Thanks!

Reply

it would be super helpful to know with which software, encoders, and parameters the files were created

Reply

I always use - http://handbrake.fr/

Post new comment

  • Allowed HTML tags: <code> <blockquote> <em> <strong> <strike> <ul> <li> <ol>
  • You may post code using <code>...</code> .
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options