Comment by AnotherGoodName | Hacker News Reader

Comment by AnotherGoodName | Hacker News Reader

AnotherGoodName

One thing i'd love to see added here is a blurb about the importance of the location of the video metadata in the file. Specifically that you need to have the metadata at the start of the file rather than the end of the file (which is the default) for low-latency playback on web.

Explained: Freshly recorded MPEG (and almost all other container types) typically saves the header at the end of the file. This is the logical place to store header information after recording as you just append to the end of the file you've just written. It's the default.

Unfortunately having the header at the end of the file is terrible for web playback. A user must download the entire video before playback starts. You absolutely need to re-encode the video with FAST-Start set.

The header location is the number one mistake that i've seen a lot of website and developers make. If you find your website videos have a spinner that's seconds long before the video playback starts check the encoding. Specifically check that you've set fast start.

I've seen companies who have a perfectly reasonable static site behind a CDN spend a fortune hosting their videos with a third party to fix the latency issues they were seeing. The expensive third party was ultimately fixing the issue because they re-encoded the videos with fast start set. The reality is their existing solution backed by a CDN would also have worked if they encoded the videos correctly.

This is what the MP4 format calls the "moov atom".

Writing metadata at the end, instead of periodically interleaving it inside the file, is not only useless for web playback, but also for any creation process (i.e., live recording) which intends to call itself robust. Imagine recording a 1-hour long video, only to have some unrelated issue abruptly stopping it all (e.g. the application crashes, or the video camera suddenly loses power), thus rendering an unplayable file because the damned metadata didn't get to be written at the end of the file...

(luckily there are post-process methods that in some cases are able to restore such broken files, but still, a priori the file will be unplayable)

> This is what the MP4 format calls the "moov atom".

One of the few surviving legacies of Apple technology created during the Jobs interregnum.

Like everything else not from NeXT, the modern Apple has killed QuickTime, but they can’t eliminate its concepts and wacky constants from the MPEG-4 standard.

And that's the reason fragmented mp4 were invented.

> The reality is their existing solution backed by a CDN would also have worked if they encoded the videos correctly.

For folks who might not realize you can fix this post-encode, you can do this:

  ffmpeg -i in.mp4 -c copy -map 0 -movflags +faststart out.mp4

Aside from source code and hundred page technical specs, is there any good source for this type of information?

ffmpeg-fu is pretty googleable actually

This is the sort of thing you can't help but run into when looking up ffmpeg incantations over the course of building a solution.

Just look how easily you ran into it when you weren't even looking for it.

For such a complex tool, the internet (like StackOverflow answers) ends up becoming a recipe book of practical solutions that would be hard to derive even if you sat down with the documentation and read it front to back. Nothing wrong with embracing that.

> A user must download the entire video before playback starts.

That was not my experience. If the web server announces the Content-Length of the video file, most browsers will make a range request for the end of the file and then go on from there.

Latency is still a bit higher this way, but no way near downloading the entire video file.

Yep, you make a really good point, thanks for the feedback. I think this bit would probably make sense to live in the upcoming "processing" section.

If anyone's interested, this is called the moov atom, and when you use "web playback" presets in tools like Handbrake, that's typically what it does is move that header to the beginning of the file. The progressive playback issues for files not optimized has improved somewhat when the file's host supports range requests, since browsers have gotten smart enough to try and check the end of the file for that header via range requests.

If you're interested in more along the codec/container line, one of my colleagues gave a talk on the internals of MP4 containers at Demuxed a few years ago[0] and another gave a Streaming Media keynote on the history of codecs and containers, particularly as they relate to online video[1].

[0] https://www.youtube.com/watch?v=iJAPTY3B7yE [1] https://www.youtube.com/watch?v=9Qo3WfsK4vc

Matroska is really great for streaming. It is a very featureful container, it can even be streamed over a lossy connection!

It is a shame that Chrome only allows it to contain vp8/opus. If it allowed all the codecs in mp4 I think it would see much wider adoption.

Reply on news.ycombinator.com