How can I stream very long H.264 videos over HTTP without long startup times? (or: MOOV atom too large)

Question

I want to stream videos of public meetings that are often 10 hours long. Users will generally be starting at some point in the middle of the video and jumping around frequently.

H.264 in an MP4 container seems like the current best option for encoding streaming video (right?). But these are large files -- about 1.3GB for one file -- and the metadata (MOOV atom) at the beginning of the file is itself about 40MB. If I understand correctly, clients need to download the full metadata before they're able to seek within the remainder of the file. Obviously, having to download 40MB before you can start streaming is unacceptable.

(My tests of streaming have been with VLC and the HTML5 tag in Chrome.)

I'm encoding the file using avconv, and am currently providing no additional settings beyond telling it which encoders to use (x264 and libfaac). I then move the metadata to the beginning of the file using qt-faststart.

Is there a way to make the MOOV atom smaller?

If not, are there other strategies to use (e.g. is splitting long videos into several files something that's frequently done? it seems like a real pain in terms of users seeking around the whole day's video)?

Or should I be using a different codec or container?

thanks!

Here's a breakdown of the file header structure, from AtomicParsley:

Atom ftyp @ 0 of size: 32, ends @ 32
Atom moov @ 32 of size: 40157673, ends @ 40157705
     Atom mvhd @ 40 of size: 108, ends @ 148
     Atom iods @ 148 of size: 24, ends @ 172
     Atom trak @ 172 of size: 20156304, ends @ 20156476
         Atom tkhd @ 180 of size: 92, ends @ 272
         Atom edts @ 272 of size: 36, ends @ 308
             Atom elst @ 280 of size: 28, ends @ 308
         Atom mdia @ 308 of size: 20156168, ends @ 20156476
             Atom mdhd @ 316 of size: 32, ends @ 348
             Atom hdlr @ 348 of size: 45, ends @ 393
             Atom minf @ 393 of size: 20156083, ends @ 20156476
                 Atom vmhd @ 401 of size: 20, ends @ 421
                 Atom dinf @ 421 of size: 36, ends @ 457
                     Atom dref @ 429 of size: 28, ends @ 457
                 Atom stbl @ 457 of size: 20156019, ends @ 20156476
                     Atom stsd @ 465 of size: 147, ends @ 612
                         Atom avc1 @ 481 of size: 131, ends @ 612
                             Atom avcC @ 567 of size: 45, ends @ 612
                     Atom stts @ 612 of size: 6115608, ends @ 6116220
                     Atom stss @ 6116220 of size: 16960, ends @ 6133180
                     Atom ctts @ 6133180 of size: 5683824, ends @ 11817004
                     Atom stsc @ 11817004 of size: 28, ends @ 11817032
                     Atom stsz @ 11817032 of size: 4169724, ends @ 15986756
                     Atom stco @ 15986756 of size: 4169720, ends @ 20156476
     Atom trak @ 20156476 of size: 20001133, ends @ 40157609
         Atom tkhd @ 20156484 of size: 92, ends @ 20156576
         Atom mdia @ 20156576 of size: 20001033, ends @ 40157609
             Atom mdhd @ 20156584 of size: 32, ends @ 20156616
             Atom hdlr @ 20156616 of size: 45, ends @ 20156661
             Atom minf @ 20156661 of size: 20000948, ends @ 40157609
                 Atom smhd @ 20156669 of size: 16, ends @ 20156685
                 Atom dinf @ 20156685 of size: 36, ends @ 20156721
                     Atom dref @ 20156693 of size: 28, ends @ 20156721
                 Atom stbl @ 20156721 of size: 20000888, ends @ 40157609
                     Atom stsd @ 20156729 of size: 96, ends @ 20156825
                         Atom mp4a @ 20156745 of size: 80, ends @ 20156825
                             Atom esds @ 20156781 of size: 44, ends @ 20156825
                     Atom stts @ 20156825 of size: 9348168, ends @ 29504993
                     Atom stsc @ 29504993 of size: 28, ends @ 29505021
                     Atom stsz @ 29505021 of size: 5326296, ends @ 34831317
                     Atom stco @ 34831317 of size: 5326292, ends @ 40157609
     Atom udta @ 40157609 of size: 96, ends @ 40157705
         Atom meta @ 40157617 of size: 88, ends @ 40157705
             Atom hdlr @ 40157629 of size: 33, ends @ 40157662
             Atom ilst @ 40157662 of size: 43, ends @ 40157705
                 Atom ©too @ 40157670 of size: 35, ends @ 40157705
                     Atom data @ 40157678 of size: 27, ends @ 40157705
Atom free @ 40157705 of size: 8, ends @ 40157713
Atom mdat @ 40157713 of size: 1320096566, ends @ 1360254279

Answer 1

If you have the ability to use a flash player like jwplayer try the flv format. You can still use your H.264/AAC combination within it. However your files will start streaming immediately. You don't have to re-encode. Just remux

ffmpeg -i input.mp4 -acodec copy -vcodec copy -bsf h264_mp4toannexb out.flv

If you must use mp4 files then you should use fragmented mp4 files to achieve it. Similar to smooth streaming [though that was for a different purpose also].

Answer 2

How you present the recording has a lot to do with how it is precached. Are you using a playlist format to eventually link to the content? Is the VideoLan Client reacting better or worse than say the defacto movie players.

Is HTML5 an option so that you can immediately make seeking options available through simple javascript? For what it's worth most HTML5 aware browsers do a pretty good job of maintaining a respectable buffer length.

http://en.wikipedia.org/wiki/HTML5_video

In the long run I'd advise getting an appropriate YouTube or Vimeo account and publish the content there to take advantage of their infrastructure and reduce your own bandwidth requirements substantially.