Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a video streaming site with the following lighttpd configuration:

server.modules              = (
  "mod_compress",
  "mod_access",
  "mod_alias",
  "mod_rewrite",
  "mod_redirect",
  "mod_secdownload",
  "mod_h264_streaming",
  "mod_flv_streaming",
  "mod_accesslog",
  "mod_auth",
  "mod_status",
  "mod_expire",
  "mod_fastcgi"
)

server.document-root        = "/data/domain.com/"
index-file.names            = ( "index.html" )
server.tag                 = "xhttpd"
url.access-deny             = ( "~", ".inc" )
dir-listing.encoding = "utf-8"


mimetype.assign             = (
  ".gif"      =>      "image/gif",
  ".jpg"      =>      "image/jpeg",
  ".jpeg"     =>      "image/jpeg",
  ".png"      =>      "image/png",
  ".css"      =>      "text/css",
  ".html"     =>      "text/html; charset=UTF-8",
  ".htm"      =>      "text/html; charset=UTF-8",
  ".js"       =>      "text/javascript",
  ".mp4"      =>      "video/mp4",
  ".3gp"      =>      "video/3gpp",
  ".3gpp"     =>      "video/3gpp",
# make the default mime type application/octet-stream.
  ""              =>      "application/octet-stream",
)
mimetype.use-xattr        = "enable"

server.port                = 80
server.pid-file            = "/var/run/lighttpd.pid"
server.username            = "nginx"
server.groupname           = "nginx"

server.stat-cache-engine = "simple"   # either fam, simple or disabled

# see http://blog.lighttpd.net/articles/2005/11/11/optimizing-lighty-for-high-concurrent-large-file-downloads
server.network-backend = "writev"

# http://redmine.lighttpd.net/wiki/1/Server.event-handlerDetails
server.event-handler = "linux-sysepoll"


server.max-fds                  = 8192
server.max-connections          = 2048
server.max-write-idle           = 360
server.max-keep-alive-requests  = 4
server.max-keep-alive-idle      = 4
server.max-read-idle            = 30


# Files ending in .flv and .3gp are served by the module
h264-streaming.extensions = (".mp4" )

$HTTP["url"] =~ "mp4$" {
  connection.kbytes-per-second = 90
}

# Add Expires/Cache-Control header
$HTTP["url"] =~ "\.(mp4|3gp|flv)$" {
  expire.url = ( "" => "access 8 hours" )
}

The player is jwplayer, and all my videos are mp4 with metadata set at the begining at the file using mp4box. Lighttpd is patched with h264 codeshop code.

Unfortunately, while the streaming and seeking work perfectly, there is a big difference in the starting time of videos.

For short videos (2-5 minutes), it starts playing immediately. For Long videos (20 to 60 minutes), it can take minutes before starting playing which make leave the user since he believes the video is not working.

Why does this happen, and above all, how to avoid it?

share|improve this question
    
When you do figure this out please come back and let us know what is causing it and what the solution is. –  Iain Aug 11 '11 at 7:56
    
Still searching :-) –  e-satis Aug 11 '11 at 9:25

3 Answers 3

strace the lighttpd process to see what it's doing when a request like this is made; that'll tell you exactly what it's doing, and then you can trawl through the source to see why (assuming there's some sort of comments, anyway). Once you know what it's doing, you can then move on to how to fix it (if that's even possible).

My (completely unsubstantiated) guess is it's doing some sort of sequential scanning; probably using something O(n^2) (or maybe even worse) based on the fairly sharp increase in delay relative to the movie length (and, presumably, size). Alternately, I guess it could be something video-specific, and all your long ones just happen to trigger whatever delay-inducing codepath is causing the problem.

share|improve this answer
4  
Sometimes you do have to do your own diagnosis work. Not every problem has already been solved. –  womble Aug 10 '11 at 7:40
1  
No, it's assuming that didn't manage to solve it, and offering to help you do so. But if you instead want to get terribly offended that we don't immediately leap to the conclusion that you're SuperAdmin, that's fine too. –  womble Aug 10 '11 at 8:26
1  
@e-satis: Nobody here is a mind reader. Womble's suggestion is exactly what I'd have come up with; it's not a fix, but it's a great way to get more information. What's so unfriendly about that? –  SmallClanger Aug 10 '11 at 8:31
1  
Then let us help you become a better sysadmin, by trying to diagnose the problem yourself and seeking help when you get stuck. –  womble Aug 10 '11 at 8:32
1  
"Thank you, I'm not familiar with strace at all, I'll ask another question to gain the necessary knowledge once I've read the manpage to get a basic idea of how it works" would be a good response. Note that on the Internet, nobody knows you're a "noob" (although sometimes it's pretty obvious) -- take it as a compliment that I thought you might have known enough to already know strace. –  womble Aug 10 '11 at 8:35

I think that your mp4 files are being streamed to the client but the client can't find some information it requires so it is downloading the whole file before it starts to play. Try optimizing your mp4 files

mp4file --optimize somefile.mp4
share|improve this answer
    
Would that account for 1-2 minute videos starting "immediately"? I guess it would depend on the download speed... –  womble Aug 10 '11 at 8:09
    
I would think so as they are very relatively small. We really don't have much data to go on though. –  Iain Aug 10 '11 at 8:14
    
I doubt the file are downloaded entirely, but it's worth trying mp4file. Thanks for the tip. –  e-satis Aug 10 '11 at 8:18
    
Where do you get this mp4file command? I can't find it in mp4box subcommand, in debian repo, fedora repo nor on Google. –  e-satis Aug 10 '11 at 8:29
    
apt-file search mp4file suggests mp4-utils is the package you want in Debian. –  womble Aug 10 '11 at 8:33

Its because of MOOV atom size, the moov atom is a part of the file that holds the index information for the whole file. So when you are streaming a small file, moov atom is small thus video doesn't takes long to start. But when file size is large, even when you have fixed encoding issues, like moving moov atom in front, it takes some time to fetch moov atom first and then play video.

To overcome this, you can try switching to Http Dynamic Streaming by adobe. The video file is segmented on server side, its video chunks that are delivered and they stitched on player side for continous playback. It also supports seek at any point in timeline.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.