How to get a single I-Frame??

[mpucoder]

I came across one pack that contained just one byte of the video stream. Made me wonder if the transcoders take advantage of the chunkiness. Here was a case where shortening the video by only one byte would save 2048 bytes overall.

[Sir Didymus]

Observed something similar... (packets smaller than 6 bytes)...
Thinking at the way the packetization process of a mpeg stream, its clear it may happen...

What I've NEVER seen is the presence of 00 00 01 00 inside an mpeg stream...

Sometimes I wonder what happens in case of purposely patching with these values an m2v file, and remuxing it...

By the way, just for the sake of curiousity, do you actually check this type of events into MuxMan ?

SD

[blutach]

Originally posted by jeanl
Blutach, it's not the I-frame header, it's the header of the next video frame (i.e. a B or a P frame). That's smack in the middle of the video payload, and it can traddle a sector...
Jeanl

I understand now. But, as you have seen with the cut we have been doing, the cut to full GOP option works fine, so if there is a header issue, it's not affecting this method - only the single I frame one.

@mpucoder - Looking at this particular VOBU that jean is working with, it's stored as I BBP BBP ... I thought the storage order was usually I PBB PBB PBB ..., with the decoder then displaying the GOP as I BBP BBP. Is this normal that in this cas storage and display order are the same?

Regards

[mpucoder]

If the standard is followed to the letter it's not possible to do what they call "start code emulation" Everything is designed to prevent there from being 23 or more zero bits in a row (the trigger for a start code) - this is why marker bits exist. BUT simple mistakes, like padding a pes header with 0 bytes instead of 0xff, can cause problems.

I'm not sure which events you mean, but Muxman does need information from every sequence, sequence_extension, sequence_display_extension, picture, picture_coding_extension, and sequence_end header. And you know what damage a false interpretation can do

[mpucoder]

Originally posted by blutach
Looking at this particular VOBU that jean is working with, it's stored as I BBP BBP ... I thought the storage order was usually I PBB PBB PBB ..., with the decoder then displaying the GOP as I BBP BBP. Is this normal that in this cas storage and display order are the same?
Regards

If it's encoded as I BBP BBP .. then it displays as BBI BBP ... (regardless of what the tsn may say!)
Here's the rule:
You decode each frame in the encoded order, paced by the display.
If you just decoded a reference frame (I or P) put it aside and display the previous reference frame (except when starting up, in which case display nothing yet)
If you just decoded a B frame display it immediately.

[jeanl]

mpucoder, you RULE! (but that's no news!).
I added the end-of-sequence header, and that fixed it!
2 Mega-thanks.
Jeanl

[blutach]

@jeanl

You got a new version for me to test. It's been a couple of hours buddy!!!!!

:rofl:

[Dimad]

Originally posted by Sir Didymus
By the way want to propose this thread for the "best thread of the month" prize...

Indeed, very interesting thread.

[jeanl]

OK, I've made great progress thanks to mpucoder's hints.
I still have 1 problem, which I can't seem to find the solution too, so I'm back with a question!

- I'm now trying to turn a motion menu cell into a single-I-Frame cell with audio. In other words, I'm keeping all audio and subpic packs, compressing the first GOP into the first single I-Frame, and dropping all other GOPs in the cell.

- I've modified the first NavPack, and the I-frame pack in the following way:

• In the first NavPack, the second and third references frame end blocks are set to 0 (since there's no P frame to follow).
• In the first NavPack VOBU_SRI, I set the Next VOBU with video to 0xbfffffff (since there's no more video in the cell).
• In the I-frame GOP flag, I set the Closed GOP to 1, and broken GOP to 0.
• In the I-frame picture header, I set the temporal sequence number to 0.

After these modifications, I put back the cell in the VOB, adjust the IFO (mock strip), and test.
Things work quite well in lots of cases, BUT I have this one menu where the I-frame won't show only on my standalone (it plays fine in PowerDVD, WindDVD and IFOEdit Play DVD). On my standalone I can hear the audio, see the button highlights, but the I-frame isn't displayed.

I'm wondering what it could be that I'm missing.

- Could it be a presentation time problem? I'm not adjusting the PTS of the I-frame, could that be a problem?
- Could it be related to the fact that in the I-Frame's extension start code, the Top Field First is 0 (and the progressive frame flag is 0)???

Any pointer would be greatly appreciated.

Thanks a bunch in advance!

Jeanl

[mpucoder]

The tff should be 1 for the first frame in a sequence, that could be a problem.

pts should be the same as vobu_s_ptm (and as a double check, one frame later than dts).

vobu_se_e_ptm should be one frame duration later than vobu_s_ptm. (and there should be an end_of_sequence).

vobu_e_ptm should remain unchanged and match the next NAV pack vobu_s_ptm.

SRI won't mess up normal play, but if you want to get strict for all of the pointers not set to bfffffff the top bit should be cleared (it indicates video present in the referenced vobu)

frame duration: NTSC 3003, PAL 3600

single frame GOP is not closed, that flag is only for 2 or more frames, and second is B.

And for other things neither one of us thought of, you could demux after modifying then multiplex with Muxman and compare.

[jeanl]

Thanks a bunch mpucoder! I'll into all of this (most of which is already true, but not all!)

However, you mention:

single frame GOP is not closed, that flag is only for 2 or more frames, and second is B.

this is consistent with our prior discussion, but I've seen quite a few single-frame GOP with the closed GOP flag set! I'll follow your advice though.

vobu_se_e_ptm should be one frame duration later than vobu_s_ptm. (and there should be an end_of_sequence).

AHAH! I suspected that! I do put an end_of_sequence in my I-frame. Is vobu_se_e_ptm what vobedit displays as "End PTM of VOBU if Sequence_End_Code"?

SRI won't mess up normal play, ...

that's what I expected, and it does not in most cases, but it does in IFOEdit Play DVD (based, I guess, on M$'s direct-X code). I had to fix the pointers to avoid problems.

One last question (I forgot to ask!):
- Do I need to worry / fix the SYNCI information in the NavPacks? (offsets to audio packets and subpic streams have changed because I removed video packs).

Again, 1 MThanks!
Jeanl

[mpucoder]

The closed gop flag shouldn't really matter in this case.

Yes, that's what VobEdit calls the value, offset 0x041

Synci - I knew there would be something left out
First vobu should only need audio adjusted, but after that the NAV packs have to point back to the first NAV pack for subs. Note subs point to NAV packs, not sub packs. That actually makes it easy, because the value is simply 0x80000000 + current lba to point back to the beginning.

[jeanl]

Originally posted by mpucoder
The closed gop flag shouldn't really matter in this case.

Yes, that's what VobEdit calls the value, offset 0x041

Synci - I knew there would be something left out
First vobu should only need audio adjusted, but after that the NAV packs have to point back to the first NAV pack for subs. Note subs point to NAV packs, not sub packs. That actually makes it easy, because the value is simply 0x80000000 + current lba to point back to the beginning.

Great info!
OK, now I know what to do, I'm going back into my hole!!!
Thanks a bunch again!
Jeanl

[mpucoder]

Originally posted by jeanl
I'm going back into my hole!!!

But I just stuck my head out of mine (had to take a break from the twisted logic of scp files - only a lisp fan could love them)

[jeanl]

Originally posted by mpucoder
But I just stuck my head out of mine (had to take a break from the twisted logic of scp files - only a lisp fan could love them)

S**t man, and I thought I had it bad!


Jeanl

[jsoto]

because the value is simply 0x80000000 + current lba to point back to the beginning.

So, all the subs are always located in first VOBU (in menu cells)? Can they be in a different VOBU?
jsoto

[mpucoder]

If it's a single frame they will. Menus with motion video prior to the buttons coming on won't.

[jsoto]

What we are doing is a "motion2still" conversion in menus, so if I understand well, the original can have the subs in a VOBU different from the first one. I do not know how to manage this...

May be I can keep all the nav packs? . If we are preserving the audio, they are needed, but if we are deleting it they are not really needed.
Can a VOBU be "discontinuous" with the previous one? Imaging we delete some VOBUS in the middle of the VOB.

BTW, this is my hole (my wife doesn't like the HW things, and they are hidden) and this is myself (out of the hole, hehe).

jsoto

[jeanl]

Originally posted by jsoto
What we are doing is a "motion2still" conversion in menus, so if I understand well, the original can have the subs in a VOBU different from the first one. I do not know how to manage this...

jsoto, in my opinion, if you're keeping the audio then you don't have a problem, because presumably you're keeping every navpack, and the subs will appear when they're due.
If you're not keeping the audio, just the first I-frame and the subs, my take is that you have to keep the navpack before the subs, ajust its start PTS to match the end PTS of the previous navpack, and possibly adjust the PTS of the subs so they appear right after the video (for example they could match the start PTS of the corresponding NavPack. We have to experiment with all this!

Can a VOBU be "discontinuous" with the previous one? Imaging we delete some VOBUS in the middle of the VOB.

jsoto, all the DVD's I've looked at have continuous PTS (if that's what you mean). So I don't think they can be discontinuous, but I'm not too sure. You can always adjust the end PTS of the previous navpack to match the begin PTS of the next one right? But that might mean that the subs might appear after a delay (identical to the delay in the original menu).
EDIT: there's also a problem when you remove NavPacks, because the SRC has to be provided on a regular basis (every so many milliseconds), and it's provided in the NavPacks. Maybe mpucoder can shed some light on that aspect... (I'm willing to bet )

BTW, this is my hole (my wife doesn't like the HW things, and they are hidden) and this is myself (out of the hole, hehe).
jsoto

Man! That does NOT qualify as a hole!!!! Wait until I get home to show you some real hole! Nice pic on the bike though!!!
Jeanl

[jsoto]

EDIT: there's also a problem when you remove NavPacks, because the SRC has to be provided on a regular basis (every so many milliseconds), and it's provided in the NavPacks. Maybe mpucoder can shed some light on that aspect... (I'm willing to bet )

Yep, waiting mpucoder..., SCR is on every pack, I believe SCR differences cannot be lower than 146 but AFAIK they can be much more higher...

Man! That does NOT qualify as a hole!!!!

True..., this is a "soft" (light) hole..... but also mpucoder didn't show the more HW oriented ones he has... (there are some pics in his site ). I really like the HW (I worked on it during a long time in my professional life)....

jsoto