Some of it is obsolete now, like the ‘actor ordering’ issue.
But the automated scripts are still very useful!
@OttoKerner said:
Some of it is obsolete now, like the ‘actor ordering’ issue.
But the automated scripts are still very useful!
Yeah, I’m enjoying digging around. I’m also trying to find out more about interleaving MP4s; my general sense is that it’s a good thing.
@markmarz said:
I’m also trying to find out more about interleaving MP4s; my general sense is that it’s a good thing.
It is my understanding that every default “multiplexing” (or “muxing”) will ‘interleave’ video with audio and subtitle packets.
I’m not sure what there is still to investigate about this.
@OttoKerner said:
@markmarz said:
I’m also trying to find out more about interleaving MP4s; my general sense is that it’s a good thing.It is my understanding that every default “multiplexing” (or “muxing”) will ‘interleave’ video with audio and subtitle packets.
I’m not sure what there is still to investigate about this.
I don’t follow. I’m trying to find out whether it’s okay to use MP4Box which does interleave even when I specify an interleave value = 0. Are you saying that an MP4 is already interleaved? If yes, then why is this a feature of MP4Box?
Per gpac.wp.imt.fr/2011/02/02/mp4box-fragmentation-segmentation-splitting-and-interleaving/
Interleaving (-inter) is when (groups of ) samples of different tracks are stored alternatively in the file: e.g. N milliseconds of video samples, followed by N milliseconds of audio samples, followed by N milliseconds of video samples … Typically, interleaved samples are grouped within an interleaving window. Interleaving reduces disk accesses, playback buffer requirements and enables progressive download and playback.
@markmarz said:
Interleaving (-inter) is when (groups of ) samples of different tracks are stored alternatively in the file: e.g. N milliseconds of video samples, followed by N milliseconds of audio samples, followed by N milliseconds of video samples … Typically, interleaved samples are grouped within an interleaving window. Interleaving reduces disk accesses, playback buffer requirements and enables progressive download and playback.
That is the default for all ‘muxed’ file formats, especially when you are ‘optimizing’ them for streaming. Interleaving is at the heart of streaming media. Without it, there would be no streaming possible.
If your files were not already interleaved, then at playback start Plex would have to read the whole source file from beginning to end and only after that, playback would commence. You would definitely notice it, if that were the case.
I think we can rule that out, unless your files were made with some really old software and /or some really inappropriate command line parameters.
Keep in mind that the posting you are linking to is 6 years old.
@OttoKerner said:
@markmarz said:
Keep in mind that the posting you are linking to is 6 years old.
The link is just background information on interleaving. The current documentation I linked to earlier shows how to use -inter feature but doesn’t go into much detail why.
@markmarz said:
The link is just background information on interleaving. The current documentation I linked to earlier shows how to use -inter feature but doesn’t go into much detail why.
It doesn’t matter much.
Data streams on DVDs or BluRays are already interleaved.
Ripping software doesn’t change that.
tv video streams broadcast over the air, satellite or cable are interleaved as well.
Handbrake and every other transcoding software produces interleaved output by default.
Interleaving is a thing that an end user is not required to think about, nowadays.
Okay well it’s not something I’m pushing to do. It’s a side effect of what I really want, which is just to move the MOOV! I’ll keep playing around with Plex Transcoder to get it working from my shell script.
For anyone interested, another Linux alternative which happens to be available on OpenMediaVault is
github.com/FFmpeg/FFmpeg/blob/master/tools/qt-faststart.c
I tried it against a non-optimized MP4. The output was optimized, and all video & audio streams were preserved. It will only process input where the MOOV atom is the last atom in the file. That’s handy to avoid processing the same file twice. On the few files I’ve tested against, the output & input files are the exact same size. The source code shows that all he’s doing is moving the MOOV atom. Interestingly ffmpeg outputs a different size file, so something ‘extra’ is going on.
root@omv:~/work/mp4_optimize# qt-faststart "20,000 Years in Sing Sing (1932).mp4" "20,000 Years in Sing Sing (1932).qtfaststart.mp4"
ftyp 0 32
free 32 8
mdat 40 2293752140
moov 2293752180 4439780
patching stco atom...
patching stco atom...
patching stco atom...
writing ftyp atom...
writing moov atom...
copying rest of file...
root@omv:~/work/mp4_optimize#