Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing an MP4 Muxer for Fun and Profit

obsproject.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Writing an MP4 Muxer for Fun and Profit

#21

Post by der_rod »

CrendKing wrote: post #14

Can someone explain how does an existing media player understand the new mdat format without modification? I assume if they find a completed moov at end of the file, it would recognize the file as a unfragmented mp4. It should then try to find a list of recognized codecs directly inside the mdat (like in the first picture), but instead they will find another moov, a bunch of moofs and sub-mdats, all of which are clea…

The mdat box does not have a defined structure, and the specification actually states that attempting to define a structure is almost certainly a mistake. In order to find the data the player is looking for it has to read the moov box, which contains the byte offsets and sizes of "chunks" of data. Since there is no requirement for chunks to be contiguous, or even in the same file, we can simply skip over the fragmentation-related boxes within the data box.

Re: Writing an MP4 Muxer for Fun and Profit

#22

Post by ogurechny »

So this is a “soft” sequential access limitation (we can tolerate some random writes to data as long as it is small enough and short enough). I wonder if there are formats that result in finished indexed multimedia file with “hard” sequential access, when nothing can be overwritten.

Re: Writing an MP4 Muxer for Fun and Profit

#23

Post by cornstalks »

(context, this is talking about fragmented MP4 downsides)

> 2. They are slow to access on HDD or network drives, as each fragment's header needs to be read to get the complete metadata of the file and start playback

Huh? That's not right. The whole point of fragmented MP4 is that you can access any fragment without having to read the headers of the other fragments. That's why adaptive streaming is built around fragmented MP4.

Re: Writing an MP4 Muxer for Fun and Profit

#24

Post by ogurechny »

cornstalks wrote: post #23

(context, this is talking about fragmented MP4 downsides) > 2. They are slow to access on HDD or network drives, as each fragment's header needs to be read to get the complete metadata of the file and start playback Huh? That's not right. The whole point of fragmented MP4 is that you can access any fragment without having to read the headers of the other fragments. That's why adaptive streaming is built around fragme…

To figure out the total length of media streams, you need an external index metadata (web streaming) or a remux of the file that adds an index. The whole point of the article is removing the need to remux the file after recording, otherwise you can use existing solutions just fine.

Re: Writing an MP4 Muxer for Fun and Profit

#25

Post by TD-Linux »

ogurechny wrote: post #22

So this is a “soft” sequential access limitation (we can tolerate some random writes to data as long as it is small enough and short enough). I wonder if there are formats that result in finished indexed multimedia file with “hard” sequential access, when nothing can be overwritten.

Digital video tape formats (e.g. DV, HDV) are an example. Other containers that operate in this mode are TS and Ogg (and optionally, MKV). Any sort of live streaming format generally is, too.

Re: Writing an MP4 Muxer for Fun and Profit

#27

Post by cornstalks »

ogurechny wrote: post #24
cornstalks wrote: post #23

(context, this is talking about fragmented MP4 downsides) > 2. They are slow to access on HDD or network drives, as each fragment's header needs to be read to get the complete metadata of the file and start playback Huh? That's not right. The whole point of fragmented MP4 is that you can access any fragment without having to read the headers of the other fragments. That's why adaptive streaming is built around fragme…

To figure out the total length of media streams, you need an external index metadata (web streaming) or a remux of the file that adds an index. The whole point of the article is removing the need to remux the file after recording, otherwise you can use existing solutions just fine.

You can write a sidx for your index. And it doesn't require a whole remux.

Re: Writing an MP4 Muxer for Fun and Profit

#29

Post by der_rod »

cornstalks wrote: post #27
ogurechny wrote: post #24

Earlier quoted context omitted.

To figure out the total length of media streams, you need an external index metadata (web streaming) or a remux of the file that adds an index. The whole point of the article is removing the need to remux the file after recording, otherwise you can use existing solutions just fine.

You can write a sidx for your index. And it doesn't require a whole remux.

Unfortunately, some of the most popular/problematic software (default Windows video player and explorer) does not support `sidx` boxes.

Re: Writing an MP4 Muxer for Fun and Profit

#30

Post by somat »

Nice, when playing around one weekend trying to see if I could use ipfs as a transport layer for streaming video I got hung up because most video formats I tried behaved very poorly with inconsistent streams where you may not have the beginning. I ended up on mpeg-ts as the best behaving of the bunch. It felt a little weird, as I was sort of expecting something more modern to have better performance, but seeing as my goal was not to evaluate video formats but just ship them around I just accepted it and moved on.

Thinking back on it now, I just did a little trial and error until I found something that worked, but what would I search for if I was trying to find data on how... ?streamable? an encoding is?

If curious, I got my proof of concept working but it was unpleasantly slow. I blindly chunked the incoming stream into megabyte sized chunks registered the chunks on ipfs then used ipfs pubsub to announce the chunk to any watchers. The watcher would watch the pubsub channel for announcements download the chunk and try to reassemble it in order and play it. one neat side effect that I found was when the stream was done if I had stored all the ipfs address I could then generate a whole ipfs file structure you could use to download the stream at a later date.

Post reply on HN