multistream video x264 in mp4, switching performance?

[smok3]

so i did an mp4 file with 3 different video streams and used some html/javascript to embed that to the web page offering users buttons like; cam1 | cam2 | cam3 (quicktime player)

now the question is: how to encode this streams so as the 'cut' will be as fast as possible? (you know like no-bframes, i frames on the same position?, ect...), actually i would like to see a nice x264 command line?

tnx for any suggestions

p.s. another thing: is it possible to encode multiple streams simultaneously with x264? (i mean in way that bitrate distribution will check all at once, so that when the cut occurs user will land on an image that is of similar quality.)

[check]

all you need is a low min and max GOP sizes. Try something like 10-50

[GodofaGap]

B-frames will actually help faster seeking, since they can be skipped.

[bond]

B-frames will actually help faster seeking, since they can be skipped.this is true if the following things are valid:
1) quicktime doesnt decode the b-frames when seeking (which i absolutely wouldnt trust that it does this)
2) you dont use b-frames as references (aka b-pyramid), which quicktime wouldnt handle anyways

[foxyshadis]

Even though it doesn't apply to quicktime at all, b-refs will be skipped just like any other b-frames while decoding from the start of the gop, because a P frame can never reference a B frame. It'll decode something like I-P-P-P-P-P-Bref-b to reach a frame deep in a gop.

[smok3]

tnx for replays, so what we have so far is:
- lots of I frames
- general qt compatibility
-------------------
- b-frames yes/no?
- cabac yes/no?

(i have an example online if somebody wants to see, but cant post the link here, since i have limited bandwidth with my host - but i can PM)

and another thing: is it normal that each video stream should have a separate hint track also? (if i want progressive download that is)

[Sergey A. Sablin]

Even though it doesn't apply to quicktime at all, b-refs will be skipped just like any other b-frames while decoding from the start of the gop, because a P frame can never reference a B frame. It'll decode something like I-P-P-P-P-P-Bref-b to reach a frame deep in a gop.

b-refs means reference frame and P frames wont reference it if and only if encoder made a stream in that way. if no restrictions on this was made from encoder side then P-frames will use b-ref for inter prediction process.

[akupenguin]

x264 does use B-refs for predicting P-frames. But even so, B-pyramid allows faster seeking than no B-frames, just not as fast as B-non-pyramid.

[foxyshadis]

Wow, I thought for a long time that the spec meant a heigharchial order to references, where only b-frames could reference a b-ref. I guess it's good to have that misconception cleared up.

[akupenguin]

"pyramid" isn't mentioned in the spec at all. It's just one thing you can do with given tools: reference management and reference list reordering.
Also, note that there is no such thing as a "B-frame" in the spec. Frames can contain multiple slices, and each slice can be I, P, or B. There may not be any reason to mix slice types within a frame, but it's allowed.

And just for an example of another gop structure that one could create using the same tools as pyramid: IBBBB... with all B-frames being references, and each macroblock is predicted using up to 2 previous frames.

Another: multiview video. If you have several cameras recording the same scene from different angles, there is some redundancy between the streams, but it's not really obvious how to exploit it. Creative use of H.264 B-refs is the winning candidate so far for SVC's multiview mode.

[smok3]

Creative use of H.264 B-refs is the winning candidate so far for SVC's multiview mode. example? :o

[DarkZell666]

I think he was just talking about a concept, and/or a future implementation of something that doesn't exist yet =)