0

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?

user9517
  • 114,104
  • 20
  • 206
  • 289
e-satis
  • 409
  • 5
  • 17

3 Answers3

2

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.

womble
  • 95,029
  • 29
  • 173
  • 228
  • This is nice and all, but If I would be able to use strace, find the problem and correct it myself, I would not ask the question here. – e-satis Aug 10 '11 at 07:29
  • 4
    Sometimes you do have to do your own diagnosis work. Not *every* problem has already been solved. – womble Aug 10 '11 at 07:40
  • Let me expand on my previous comment... we (or at least "I") are willing to help you learn how to use strace to find the problem yourself, if you (a) do a bit of work yourself in the right direction, and then (b) ask relevant, specific questions on Server Fault to get you over the humps you'll encounter (showing that you've been doing your own work will help people be more accomodating). That will provide you with a far more valuable outcome, long term, than just having to rely on other people having encountered the exact same problem as you and being here to tell you how to fix it. – womble Aug 10 '11 at 08:13
  • this assume I didn't try to solve the problem before coming here which is at best unfriendly. – e-satis Aug 10 '11 at 08:20
  • 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 08:26
  • That exactly the contrary: I am a very bad sysadmin and this is why I am asking the question. If I would have the skill to find the answer using strace, we wouldn't be arguing about it. – e-satis Aug 10 '11 at 08:30
  • 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 08: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 08:32
  • My point is: if a noob in a field comes to you after trying his best and you tell him: take this very complicate tools and find the answer yourself, how do you expect him to take it ? – e-satis Aug 10 '11 at 08:33
  • 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 08:35
  • Strangely I feel more like "thanks, but I know I can use strace for this, it would take ma a week or so to get the answer, if I come to you it's because I hope someone may have a better solution than spending 7 days debugging, solution that I already considered and would have applied with no better alternative found on the internet". But maybe it's just me. – e-satis Aug 10 '11 at 08:41
2

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
user9517
  • 114,104
  • 20
  • 206
  • 289
0

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.

Nagota
  • 19
  • 7