Spliting MP4 frame by frame

[shon3i]

Did exist some cli or other app which can split some mp4 video file, frame by frame.

Can this do mp4box and how.

Thanks in advice

[bond]

define what you mean exactly with "frame by frame"

[shon3i]

One frame i one mp4 file.

[bond]

One frame i one mp4 file.this is only possible with keyframes. i would be surprised if this is not possible with mp4box or avidemux

why do you want to do this?

[shon3i]

this is only possible with keyframes. i would be surprised if this is not possible with mp4box or avidemux

why do you want to do this?
Too long story. I have one beautiful idea in my mind, which i can release only if i can split file like this.

I will find some solution somehow.

[JoeShrubbery]

Well if it's possible to mux the streams into an AVI temporarily to do your editing with, I believe Virtualdub's latest experimental build 1.7.0 has the sorta thing you're looking for:

"Smart rendering allows frame-precise editing of compressed video by only recompressing small sections around edits, with the rest of the frames copied in Direct mode."

http://virtualdub.org/blog/pivot/entry.php?id=131#body

I've been using it recently, and it seems to work fairly well. Sorry to say that I'm unaware of any tools with native mp4 container support with similar functionality.

[bond]

this has nothing to do with mp4 or the container or the editing tool, so virtualdub also cant do it

you simply need a keyframe at the start of every video stream, and if the video stream is one frame long this frame needs to be a keyframe

therefore you need to reencode your file to a keyframe only videostream

[Zero1]

There is a way in mp4box. You simply use the -raws switch. It extracts each sample (in this case each frame) to a new raw file, for example:
mp4box -raws 1 infile.mp4

Where "1" is the TrackID (you can find TrackIDs by doing-info in mp4box).

That creates raw files though; can't help you with the muxing, other than suggesting you perhaps use the FOR IN DO commands.

What is this idea about? I'm very intrigued now.

[stegre]

this has nothing to do with mp4 or the container or the editing tool, so virtualdub also cant do it

you simply need a keyframe at the start of every video stream, and if the video stream is one frame long this frame needs to be a keyframe

therefore you need to reencode your file to a keyframe only videostream

Obviously true and very well put.

P and B frames cannot exist by themselves, without their neighbor I frame(s) [keyframes], so you can't take a P or B directly out of an MP4 file and have it exist by itself in its own file. You can only do that with keyframes, so to do what you want you must first reencode your file to all keyframes first.

Look, shoni, here's your proof (http://www.headbands.com/gspot/misc/Frame_644/), and here's another even more extreme one (http://www.headbands.com/gspot/misc/Frame_497/). These webpages are ~2MB each so give them a minute to load.

In each case, the first picture is an actual capture of a P frame from a hi-res MP4 file. In one case the P frame was only 2KB in the MP4 file, and the other was also small, around 6KB. As you can see in the pictures below each one, if you could store that kind of quality in 2KB - 6KB, you'd instantly obsolete jpg, JPEG-2000, and just about every other still image format in existence. You'd become a millionaire ;)

And it sounds like that's what you're proposing, if you're suggesting you can take P or B frames out of an MP4, put a few dozen bytes of "container" around it, and then display it as a 1-frame "movie".

If you re-encode to all keyframes, each frame will be large and then "the magic will be gone" - then your scheme is quite possible, though I don't happen to know of an app that will automate that process.

As far as the Nero suggestion, that feature does exactly that, re-encodes P or B frames to keyframes right around the edit point, but leaves the rest of the file alone - which is why they say "by only recompressing small sections around edits, with the rest of the frames copied in Direct mode". It’s a nice feature. But what you want, shoni, is, essentially all edits, so it would need to convert it to all keyframes - there'd be no part left to "leave alone". So it'd make it all keyframes, just like we're saying.

If you weren't averse to re-encoding to begin with, than I apologize for going on about it. You weren't quite clear on that point, but that's the direction the thread was going, so I figured I'd at least help put that part of the issue to rest. Once you have all keyframes, what you want to do is certainly possible, though I'm not sure what would be the best app to use to automate that beyond manually selecting 1 frame sequences and performing a "save as MP4" for each one. That sounds a bit tedious, though.

[shon3i]

@stegre,Thanks for suggestion, but that is not on my mind.
@bond I'v realise that

I just wanted to cross two or more mp4 files.

Beacouse i'm interesting for 1cd rips, sometimes that can be done even with H264, too many blocking in dark areas and fog is sometimes(i don't have word). CRF is only solution but in that cases for me is better to use DVD Shrink instead.

I tryed, Zones, different, CQM-s, denoising filters, but nothing can helpd a much.

Then, i compressed that movie (War of the Worlds) whit all avc codec which i have (Ateme, x264, Mainconcept) and i came to conclusion that Ateme have good dark scenes, Mainconcept have good fast motion scenes, and x264 have good slowmotion scenes.

I think when i make film from these encodings i will get much better quality for same filesize.

Maybe is BS, but i can't find better solution.

[Zero1]

The problem with that is if Mainconcept has better high motion scenes, it might be due to the ratecontrol. It could be using more favourable quantizers which would push up the bitrate for that particular scene, quite feasibly past that of the other encode. In that case using the first encode and replacing the high motion scene with Mainconcepts would mean the file would be oversized (since you are replacing a scene with one that is of a higher bitrate).

The other thing is prediction etc. Different encodes and different encoding options will produce different decisions regarding motion estimation and so on, so if you have a short sequence of:
I P B B B P B B B
with encoder A, the first B-frame will contain and reference different information than another encoding with different software or settings. As such cutting these together would produce some interesting effects or crashes.

Let's take this cut up scene for example. In the Red is x264, in blue is Mainconcept.

I P B B P B B P B B

Now since the encoders are different and make different decisions, The first blue B-frame might be looking for information from the previous (blue frame), but since the settings are different, that information no longer exists in the previous frame.

Also another problem is that frametypes can also vary. It could be that if you join, a P-frame could be looking for an I-frame, but because of the way you joined it, the frame it would try to reference is now a B-frame from a different encoder.

As mentioned before, the only way for this to work as expected would be to produce an I-frame only encode, but then that defeats the other objective.

[shon3i]

Zero1, thanks for explanation, i realise that, and i now focusing to change whole GOP. You right, there is must have some oversize, but in my type (War of the Worlds), mainconcept complicated scenes aren't bigger than x264's, but looks much better, and aslo have higher ssim