How to get a single I-Frame??

[jeanl]

Guys,
I have a technical question for you. I'm looking into ways to "shrink" a motion menu cell into a still cell, and ideally I'd like to only keep the first GOP (ok maybe not the first one) and shrink it down into a single I-Frame (by keeping the first I-frame for example and dumping all the subequent B/P frames).

I've done tests with this idea (using vobblanker to replace the original menu cell with one that I extract as described above), and I'm finding that things work find if I extract a full GOP (tested on a standalone), but not if I only keep the first I-frame (the menu frame only partially displays, but the buttons highlights are still there, and working, it's quite a treat! ;) ).

So, does anyone know what I'm probably missing?
- Is it possible at all without re-encoding?
- Do I need to adjust the GOP structure somewhere in the VOB since I'm dumping many B/P frames? (didn't see where)
- In my tests, I kept the I-frame, but the end of it also had the beginning of a B frame, which I didn't remove (in other words, part of the last LBA also has the beginning of a B frame). That HAS to be bad, could that be the cause of my problem? Should I simply pad the LBA?


Thanks for any info.
Jeanl

[mpucoder]

Well, I've done it (to test Muxman) using a demuxed m2v and a hex editor. If it's not the first GOP remove everything before the sequence header (00 00 01 b3). Then remove everything from the second picture header (00 00 01 00) on. The last thing I had to do (to satisfy the verifier and caused no problem with playback) was change the temporal sequence number to 0 (it was from a closed gop).

My guess would be the decoder doesn't like a partial B frame - it will start to decode it. Replace the picture header and following data with a padding packet.

[jeanl]

Thanks a bunch mpucoder, I was hoping you'd be reading this!!!
Great, I know what to do next! ;)
Jeanl

[jsoto]

Mmmm, very, very useful info. Thanks to both of you.

jsoto

[jeanl]

Well, thanks to the hints from mpucoder, I was able to do exactly what I wanted: create a new cell from an existing one, keeping only the first I-frame and the subpics (that's to replace a motion menu by a still one). The "trick" was indeed to get rid of the beginning of the B/P frame in the last LBA of the I-frame (replace it with a padding packet).

The cell can then replace the original one, (vobblanker can do that easily) and the result seems to play fine on my standalone DVD player.

Success!!! :D

Thanks mpucoder for the hint. I'm finishing a small .exe that does the whole thing automatically (well, just the cell extraction, not the replacing which has to be done with vobblanker). I'll keep you guys posted.

@jsoto: vobblanker seem to have a NavPack pointer problem when cell replacing is used. I'll post about that in your thread.

Jeanl

[jeanl]

OK, more info, more problems!!!
- With lots of help from blutach, I found that it was not good to reset the highlight start time to 0, when extracting a still GOP from a motion menu. Apparently the highlight start time has to match the value in the subpic packs, or the buttons are not displayed.
- Now blutach also encountered a very strange case: He's got a DVD with a VOB cell that starts with a non-closed GOP! I didn't think that was possible!
mpucoder, is this bad authoring, or is it legit: the first GOP at the start of a cell that's non-closed.

Jeanl

[mpucoder]

legit and common. Someone started an urban legend that all GOPs in DVD should be closed, but it's not true (except in multi-angle).

Just because it is not closed does not mean that it requires a prior reference frame. The encoding sequence of IPBBPBBPBB is self-contained, but not closed.

[jsoto]

So, how can you know if a GOP needs a prior reference frame?

jsoto

[jeanl]

This one would for example, right:

BPIPBBPBBP

(is it legit?). The B frame refers to the last I-frame of the previous GOP. Right?
Jeanl

[jsoto]

:eek: Can a GOP start in a P or B frame instead of an I one?

[jeanl]

Originally posted by mpucoder
legit and common. Someone started an urban legend that all GOPs in DVD should be closed, but it's not true (except in multi-angle).

Just because it is not closed does not mean that it requires a prior reference frame. The encoding sequence of IPBBPBBPBB is self-contained, but not closed.
mpucoder, I'm a bit confused!
- Is it true that a non-closed GOP is one that needs a reference from another GOP (either forward or backward)?
- Why are you saying that IPBBPBBPBB is "self-contained"? It still needs the next GOP to be decoded right (because of the P frames EDIT: sorry B frames!) but it does not need the previous GOP, right?

Jeanl

[mpucoder]

Originally posted by jeanl
mpucoder, I'm a bit confused!
- Is it true that a non-closed GOP is one that needs a reference from another GOP (either forward or backward)?
no, it may use a reference frame from the previous GOP, which would look like:
IBBPBBPBB
Or it may be self-contained, which looks like:
IPBBPBBPBB
The key is how many reference (I or P) frames were encoded prior to the B. In the first case only one, so the B may or may not require a frame from the previous GOP. That is what the closed-GOP flag tells us, closed means the first B frames do not require 2 reference frames.

- Why are you saying that IPBBPBBPBB is "self-contained"? It still needs the next GOP to be decoded right (because of the P frames EDIT: sorry B frames!) but it does not need the previous GOP, right?
Jeanl
A GOP never needs the following GOP. Maybe you are getting display order and encoding order mixed up. We are talking about encoding order, the way it appears in the file. The reference frames are always encoded before the B frames (likewise the P frames rely only on the previously encoded I frame).
Also, a GOP must start with an I frame as the first encoded frame. That does not mean it is displayed first.

[jeanl]

mpucoder, thanks a bunch for taking the time to straighten me up, I was seriously wrong!!! And indeed, I was mixing up encoding order and display order (indicated by the temporal sequence number I guess).

If I'm understanding you correctly, you can't always tell whether a GOP is closed or open from just looking at the sequence of IBP frames. That's why we have the flag, to tell us if the B frames rely on a previously encoded reference frame.

OK, thanks again. :)
Jeanl

[jsoto]

Thanks also from my side. I was also wrong in some concepts.

jsoto

[mpucoder]

jean, that's true when there is only one reference frame in the GOP preceeding the first B frame. Otherwise the flag should not be set.

Then there's the broken flag...
It means a "normal" GOP, ie IBBPBBPBB which was not closed (so therefore relied on the previous GOP) has been orphaned by editing (previous GOP removed). This can be avoided / corrected by removing the first group of B frames and adjusting the temporal sequence numbers of the remaining frames downward by the number of B frames removed. Now you will see a "self-contained" GOP emerge - IPBBPBB
Broken and closed should never be set at the same time, if the GOP was closed you can not break it.

[jsoto]

Hey, I didn't ask about broken GOP flag but I really was wondering about its meaning...( mpucoder, do you also have a crystal ball? ).

One question more... If the broken flag is properly set (when cutting the VOB in a non-closed GOP)... Does the decoder (the player) have to honor the flag and skip the B frames?.

jsoto

[jeanl]

Originally posted by mpucoder
jean, that's true when there is only one reference frame in the GOP preceeding the first B frame. Otherwise the flag should not be set.

AH! OK. That's because a B frame can reference a reference frame up to 2 frames before? If there are 2 ref frames (IP for example) before the B, then we know that it's closed because the B frame cannot reference 3 frames back. If there's only 1 I/P frame, then it may or may not be closed. I'm paraphrasing you to make sure I understand. Am I right?


Then there's the broken flag...
It means a "normal" GOP, ie IBBPBBPBB which was not closed (so therefore relied on the previous GOP) has been orphaned by editing (previous GOP removed). This can be avoided / corrected by removing the first group of B frames and adjusting the temporal sequence numbers of the remaining frames downward by the number of B frames removed. Now you will see a "self-contained" GOP emerge - IPBBPBB
Broken and closed should never be set at the same time, if the GOP was closed you can not break it.

OK I understand that now. I had no idea what the broken flag meant!!! Your explanation is very clear.

Again, a million thanks for taking the time to enlighten us. There's probably a place where all this is fully explained (your site perhaps?), but so far I haven't been able to find it!

Jeanl

[mpucoder]

They should not try to decode the frames, but repeat the previous successfully decoded frame. But some decoders have clever ways of masking the errors.

And don't feel bad about being confused, I didn't get it at first, and the author of Scenarist didn't get it either. This is why Scenarist, and almost all authoring programs since, insist on closed GOP for multi-angle. Because the user can switch between angles they thought only closed GOP would do that without problems. But a self-contained GOP will do just as well.

[jeanl]

mpucoder,
I'm still confused!!!
Why do you say that IPBBPBBPBB is self-contained, but not closed?

The first 2 frames are reference frames, so why is it not closed? I does not depend on the previous GOP (as you said, it's self-contained), but why is it not closed????


Jean

[mpucoder]

Just semantics - closed means the closed flag is set and there is only the I frame before the first B. Self-contained means there is an I and P before the first B. Neither one depends on the previous GOP.

[jsoto]

"Self-contained means there is an I and P before the first B"
Err, a self-contained does have the closed GOP flag set or not?

jsoto

[mpucoder]

No, it does not. That flag is only to be used for IBB... to make it clear that the first B frames use no forward prediction (ie need only one reference frame).

[jeanl]

mpucoder, then you can have a frame like this
IPBBPBBPBB
and its closed flag won't be set! The closed flag is only used if a B frame is in second position, then.
So closed flag does not indicate the GOP is self contained.
If it's set, then it certainly is self-contained.
But you can be self-contained with the flag set to 0 as in:
IPBBPBBPBB

Am I understanding you right?
Jeanl

[mpucoder]

You got it!

[jsoto]

I'm going to ask still more...

How can you know where the I-frame ends?. You can trust in Vobu first reference frame end block, but how to find the byte number?. And, if you do not want to trust in vobu first reference end block?

jsoto

[mpucoder]

You look for the next picture header - 00 00 01 00. It will be byte aligned. If you are parsing yourself (not trusting the pointer) make sure you are inside the video stream - ie do not look within the pack and pes header, and make sure it is a video pack.

[jsoto]

So, picture header - 00 00 01 00, cannot be simulated in any case by picture data?

Many thanks again for all the info/clarifications.

jsoto

[jeanl]

Originally posted by mpucoder
You look for the next picture header - 00 00 01 00. It will be byte aligned. If you are parsing yourself (not trusting the pointer) make sure you are inside the video stream - ie do not look within the pack and pes header, and make sure it is a video pack.
jsoto, that's exactly what I do in vobcut: you have to search the full mpeg frame (if it's a video pack) for the pic header. If you find one, that indicates the end of your I-frame. The header is only byte aligned, so you have to look for it at every byte (or do a "smart search").
If you're only going to keep the I-frame, then you have to replace the rest with a padding pack (email me if you want the details for that).
Jeanl

[jsoto]

Thanks, probably I'm going to trust the pointer...

Well, I've to logout until Monday...

See you,
jsoto

[jsoto]

Eeeps, a last question...
Can the picture header be between two different packs?, let say 00 00 in one pack and 01 00 in the next one?

jsoto

[jeanl]

man I didn't think of that!!! That's wicked! I think it can, because otherwise there would be a need to pack the previous I-frame!!!! What the heck! I'm not too sure though! I certainly don't check for that.
Jeanl

[mpucoder]

Yes, it can - welcome to mpeg.
And it can end without enough room for a filler stream (in which case 0 fill is OK, not preferred, but it will work)

[mpucoder]

A suggestion - a form of state processing. Use one function to scan the video payload itself and return when it reaches the end or a full header. Return value = number of header bytes that matched. Use an outer function to handle the program stream, calling the video data scan function when in video data.

[blutach]

Gents,

I have been reading this thread with plent of interest.

Re the split header. Surely, in the first GOP, the I frame can hardly have a header spanning 2 LBAs. That doesn't seem sensible.

I mean, the only thing before it is a navpack. That ends and the I frame of a GOP starts. So where's the chance for the header to span 2 sectors?

Regards

[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

[mpucoder]

They are looking for the end of the I frame, ie second picture header.

[jeanl]

mpucoder, while you're still around :) (sorry for imposing!)

I"m having problem with the following thing:
- I'm keeping a single I frame (or a full self-contained GOP) extracted from a motion menu, along with all the audio packs (and the nav packs). Again, the idea being to turn a motion menu into a still menu (possibly with audio).

I would expect the resulting VOB to show the pic, and play the audio.
Instead, in PowerDVD, it shows a black frame, plays the audio, AND AT THE END displays the I-frame for a brief momen (I'm talking about playing the VOB, as in drag/drop into PowerDVD).

Any idea what could be wrong? I can do the same thing with a "real" still menu with audio (from a DVD) and PowerDVD shows the image first while it plays the audio. I'm having trouble pinpointing the difference...

If you can think of something obvious right off the top of your head, that would help tremendously.

A million thanks in advance! I promise I won't ask anything after that!
Jeanl

EDIT: I think I've got it: The PTS of the video does not match the PTS of the first audio pack, whereas it does in the "good" still frame with audio... Could that be it?

[mpucoder]

You need an end_of_sequence header (00 00 01 b7) after the single frame. You also need to set vobu_se_e_ptm to vobu_s_ptm + frame_duration.

[jeanl]

Thanks a bunch man! More stuff to look into! :)
Jeanl

[Sir Didymus]

Originally posted by mpucoder
Yes, it can - welcome to mpeg.
And it can end without enough room for a filler stream (in which case 0 fill is OK, not preferred, but it will work)

It can and it happens...
Observed (just few times on three or four titles, but it happens). Viewed while debugging a little mpeg parser written for testing purposes...

By the way want to propose this thread for the "best thread of the month" prize... :)

Cheers,
SD

[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!!!!! :D

: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 (http://www.mpucoder.com/DOS-soft/mpucoder-lair.jpg) :scared: (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 (http://www.mpucoder.com/DOS-soft/mpucoder-lair.jpg) :scared: (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!
:D

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 (http://www.videohelp.com/~jsoto/temp/hole.jpg) is my hole (my wife doesn't like the HW things, and they are hidden) and this (http://www.videohelp.com/~jsoto/temp/me.jpg) 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 (http://www.videohelp.com/~jsoto/temp/hole.jpg) is my hole (my wife doesn't like the HW things, and they are hidden) and this (http://www.videohelp.com/~jsoto/temp/me.jpg) 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

[blutach]

I haven't had time to read thru any of this yet, only to say jsoto, I'm coming to Spain, man. That is beautiful country.

Also, your desk is very clean (intestingly, mpucoder couldn't swing a cat in that computer farm!)

My setup very boring - won't post - and real pic of me is so ugly, it will surely kill all monitors! :D

Thanks to everyone and regards

[mpucoder]

Yup, the SCR can not be less than 146 2/7 (VobEdit calls it 146.085) but it can be greater. There is no harm in not adjusting it at all, just remove packs that are no longer needed.

That is just one hole I work in, the server room. here (http://www.mpucoder.com/jrogers/ME11.JPG) is almost a picture of me, taken in the control room where I developed my online NLE (ages ago now, the video was analog)

[2COOL]

OMG! Is that really you? I always envisioned how you look like behind your posts. Now I can put a face to the username! Is that an old-school Adidas jacket you got there?

[mpucoder]

Originally posted by 2COOL
OMG! Is that really you? I always envisioned how you look like behind your posts. Now I can put a face to the username! Is that an old-school Adidas jacket you got there?
I think it was K-Mart. It would be easier for me to read if that darn camera wasn't stuck to my face.

[blutach]

@mpucoder

We know you're a redsox fan, but do you always wear red???? Man, that is support for the team. Even in the off season!!!

Been a long time since I lived in the US, but (and you'll now hate me).... I love dem yanks!

Maybe some blue pinstripes for my posts in future? :D

Regards and thanks

[jeanl]

Guys,

Thanks to mpucoder's advice, I was successful in keeping the first I-frame plus the audio plus the subbpics. The trick that made everything work (on my standalone that is, everything was working find on the PC before that) was setting the end PTS for end_of_sequence (vobu_se_e_ptm) to the right value. My SYNCI and some of my VOBU_SRI pointers are still messed up, but at least on that standalone that does not seem to matter (but I intend to fix that of course).

So, thanks a bunch mpucoder! :)

Now a small question. I have seen still menus with audio where the first frame had an end_of_sequence, but vobu_se_e_ptm was not set (it was 0)! These were obtained with DVD Shrink (used to remux a still frame and audio). Is that poor authoring, or can this work in some circumstances?

Jeanl

[jeanl]

mpucoder, I also have another $1,000,000 question!
What if I want to keep the nth I-frame in the cell, with audio. In other words, I want the cell to only display what used to be the nth I-frame, but with the normal audio.

This means I have to re-multiplex the audio from the existing first I-frame with the nth I-frame. Can you tell me things to look out for? I'm really not familiar with all the multiplexing constraints, when it comes to decoder underflow etc.
For example, it is OK to put all the video packs first, then the audio packs? I'm guessing it's not, but how exactly do you determine how to do that?

What about subpic packs. I'm guessing the constraints are much less stringent there. Can I put them at the end of the first I-frame, or do they also have to be multiplexed somehow?

This is entering muxman territory, isn't it? ;)

Jeanl

[mpucoder]

OK, I could not find anything in the Philips DVD-Video Verifier User Manual (available here (http://www.licensing.philips.com/services/lover/h/documents1051.html) ) requiring vobu_se_e_ptm be set. It does state that an end_of_sequence is required if the video is shorter than the presentation period (vobu_e_ptm - vobu_s_ptm), and that a non-zero vobu_se_e_ptm without an end_of_sequence is an error. But not the other way around.

You are keeping the first I frame, right? A vob must have video in the first vobu. As for removing things in between no remuxing is needed. Just keep the SCR values as is, audio is very critical (in fact, and this may sound counter-intuitive, but audio has the highest priority, due to its small buffer, when deciding the content of the next pack). of ocourse a zillion pointers need to be updated, but...

So basically, remove things you don't want, leave everything else in the same order with the same SCR, and timing constraints will be met (if they were to begin with)

[jsoto]

For example, it is OK to put all the video packs first, then the audio packs? Seems this is what Muxman does. At least in the examples I have done.
SCR starts in zero, changes by 146,something in the following video packs and the first audio pack starts with a SCR of 19602 (last video pack has a SCR of 3000 more or less...)
PTSs of first audio , first video and first Nav are the same=25257 (PAL)

So, yes, I believe you can group all video packs togheter .. (patching the SCR of course)....

jsoto

[jsoto]

So basically, remove things you don't want, leave everything else in the same order with the same SCR, and timing constraints will be met (if they were to begin with)
But we want to show the selected I frame (which can be the last in the Cell) from the begining, so we need to "move" the video frame to the begining of the VOB.

jsoto

[jeanl]

Originally posted by jsoto
Seems this is what Muxman does. At least in the examples I have done.
SCR starts in zero, changes by 146,something in the following video packs and the first audio pack starts with a SCR of 19602 (last video pack has a SCR of 3000 more or less...)
PTSs of first audio , first video and first Nav are the same=25257 (PAL)

So, yes, I believe you can group all video packs togheter .. (patching the SCR of course)....

jsoto
then why is this not the case in almost ALL the DVDs I've looked at. I'm sure it depends on what was before the start of the Cell (in the previous cell) if you intend to have seamless playback! I'm sure muxman does that for the first Cell it creates because there's no continuity constraint with the preceding cell.
But if you want no gap in the audio, then I'm not sure you can leave a "large" gap in audio packs as we suggested because this might cause an underrun in the audio part of the decoder.

Jeanl

[jsoto]

But if you want no gap in the audio, then I'm not sure you can leave a "large" gap in audio packs as we suggested because this might cause an underrun in the audio part of the decoder.
Yep, good point. I didnt think on it...
But, look to the SCR differences between audio packs. They are so big... May be you can keep the SCR in audio packs (do not patch them) and insert the video packs checking if there is room between the SCRs (minimum distance is 146,something). If there isn't go to the next one.
jsoto

[jeanl]

jsoto, I don't understand how SRC works... I would appreciate any explanation! ;)
Jeanl

[mpucoder]

I see, you want to replace the first video with an I frame from elsewhere. Since this is a single frame we can ignore video buffer timing on the assumption that the buffer is empty to start with (non-seamless) and that the frame does not exceed the buffer size (in which case it would never work). In that case place the video packs after the NAV pack, incrementing SCR by 146 and 2/7 for each pack. Muxman uses the foillowing:

lSCR += 146;
if ((wSCR_ext += 86) > 299) {
lSCR++;
wSCR_ext -= 301;
}

But know the SCR of the next audio or other pack you are keeping, and multiplex it in when required.

[mpucoder]

Originally posted by jsoto
May be you can keep the SCR in audio packs (do not patch them) and insert the video packs checking if there is room between the SCRs (minimum distance is 146,something). If there isn't go to the next one.
jsoto
Exactly, they are very critical.

[mpucoder]

SCR controls the flow of data from the disk to the buffers. Too soon and the respective buffer overflows, too late and it underflows.

[jeanl]

Originally posted by mpucoder
SCR controls the flow of data from the disk to the buffers. Too soon and the respective buffer overflows, too late and it underflows.
OK, great! Now I understand its use (well, I'm beginning! ;) )
Jeanl

P.S. Thanks for all the above info. This is invaluable!

[jsoto]

Originally posted by mpucoder
SCR controls the flow of data from the disk to the buffers. Too soon and the respective buffer overflows, too late and it underflows.

And the PTSs control the output of the buffers, I guess...


Definitively, this thread should be nominated to the "best thread of the month" prize...

And the winner is..... mpucoder for sure!!

Man!, a zillion of thanks..

jsoto

[jeanl]

OK, I understand what jsoto and mpucoder are advising. Put video packs, and put audio packs when needed based on the SRC.
This means that we might have to grab audio from a subsequent VOBU, if the image we're replacing with is much much larger than the original image.
Imagine an original image of 5 video packs, 1 audio pack: (N=navpack)
NVVVAVV NAAAAA NAAAAA NAAAAA

We want to replace the first I-frame with a larger one, with 15 video packs.
We'd need to create something like:
NVVVAVVVAVVVAVVVAVVV NAAAA NAAAA

so some of the audio in the first VOBU would have to come from the susequent VOBUs, and in the end we could end up with fewer VOBUs than in the original. Not a problem I guess, but certainly a bit more complicated than keeping the first I-frame!!!

Do you agree jsoto?
Jean
P.S. I do agree with the best thread of the month (hey, why not of the year?) with the prize to mpucoder! THanks again man!

[mpucoder]

Originally posted by jsoto
And the PTSs control the output of the buffers, I guess...

er - dts starts it off, after that each frame of data leaves the buffer according to frame duration.
3003 for NTSC frame unless rff was set
3600 for PAL frame
2880 for ac3
960 for dts
2160 for mpeg audio
150 for LPCM
But for audio dts and pts are the same, which is why only pts appears in the header.

[mpucoder]

@jeanl - that can never happen, there is plenty of time between audio packs. Total time adds up to (usually) 45000 ticks.

[jeanl]

Originally posted by mpucoder
@jeanl - that can never happen, there is plenty of time between audio packs. Total time adds up to (usually) 45000 ticks.
AHHHH! One good news at last!!! ;)

Thanks a bunch mpucoder!
Jeanl

[jsoto]

Well, I've already asked this in other thread, but now we got the support of mpucoder and I'm going to abuse a little more... :)

I'd like to know how adjust the subs SYNCI pointers (after a strip, i.e.). What I do not know is how to get the End presentation time of the sub. Let say, the PTS is in the PES header, but I'm assuming a sub can be longer than a VOBU so to distinguish between 3fffffff (no sub) and the pointer to the right VOBU, you need to know when the sub start (its PTS) and when it ends (???) Is there other way than decoding the subs?.

jsoto
Originally posted by jeanl
Wait until I get home to show you some real hole!
Still waiting... :D :D

[mpucoder]

The only way is to decode it. Trace through the DCSQT until you find the last one (points to itself). Duration is the delay * 1024. But if you are not changing vobu_s_ptm or vobu_e_ptm for any vobu all you really need do is adjust the pointers that are there. The timing doesn't change, just the number of sectors in between.

[jsoto]

But if you are not changing vobu_s_ptm or vobu_e_ptm for any vobu all you really need do is adjust the pointers that are there. The timing doesn't change, just the number of sectors in between. Yes, that's what I'm doing in VobBlanker now, trusting the original (before strip) ones, but I'd like to know how to redo them from scratch. So, I need to learn the sub format before continuing in this way, may be in a future..., but seems

Trace through the DCSQT until you find the last one (points to itself). Duration is the delay * 1024
is enough to do it.
So, thanks again.

jsoto

[jeanl]

Guys,

I have a beginner's question:
In a VOB file, are PTS supposed to be
- Continuous (i.e. end PTS from VOBU = begin PTS of next) withing a Cell?
- Continuous from Cell to Cell?
- None of the above? (can they be non-increasing?????)

I have a vob that where the end PTS of 1/2 does not match the begin PTS of 2/1, I'm suspecting this is actually OK, but am I right?

If it's OK I need to change things in my code!
Jeanl

[jsoto]

What I understand is:
- Continuous (i.e. end PTS from VOBU = begin PTS of next) withing a Cell?
Yes. Always in a good authoring

- Continuous from Cell to Cell?
Yes, if seamless. No, if non-seamless (in a VID change, like yours, for example)

EDIT: IIRC, a change in CID (inside the same VID) must be always seamless.

If it's OK I need to change things in my code!Why?.

jsoto

[blutach]

@jsoto

Because the way cutvob processed, it assumed seamless all the way thru a VOB and this led to crazy times for each VCID, which didn't work.

Jean has my menu VOB now - this is what prompted his question. He has changed the code in B0.402 and IMO this works.

Regards

[mpucoder]

SCR and pts start at each vob - what you call a vid. They are continuous from vobu to vobu and cell to cell within the vob.

Don't blame me for the confusing names. A VOB is a video object, with a VobID unique to its titleset. VOBs are the video objects comprising one title, usually seamlessly multiplexed, and (I think) is simply the plural of VOB. VOBS are the video objects comprising one titleset (aka VTS) and means "Video OBject Set". Maybe it wasn't so confusing in Japanese, the language of the original specs.

[jeanl]

Thanks a bunch guys, I was on the right track, but not quite there yet!
jsoto, I thought of something yesterday:
When srinking a motion to a still, I don't think we need to set the still time in the IFO! How about simply setting the end pts for the first VOBU (the one with the image) to match the end PTS of the original cell? That way, you have a single-frame motion menu, not a still. At the end of playback, the cell command is executed (like in the original) and you go back to the beginning (most likely).
No messing with the still time, no messing with the cell playback time (remains the same) no messing with the cell command.

Simple, no?

Jean

[jeanl]

Originally posted by mpucoder

Don't blame me for the confusing names. A VOB is a video object, with a VobID unique to its titleset. VOBs are the video objects comprising one title, usually seamlessly multiplexed, and (I think) is simply the plural of VOB. VOBS are the video objects comprising one titleset (aka VTS) and means "Video OBject Set". Maybe it wasn't so confusing in Japanese, the language of the original specs.
did you say confusing? :D
You got to be kidding man. If they had been trying to confuse us on purpose, they wouldn't have done a better job :D! It's all part of a grand scheme of course!
Jeanl
P.S. Still working on the pic of my hole. Will post over the week end! ;)

[jsoto]

How about simply setting the end pts for the first VOBU (the one with the image) to match the end PTS of the original cell? I believe it is out of specs. VOBUs cannot be longer than 1 second (1.2 if they are the last in the cell). But may be it works...
jsoto

[jeanl]

Originally posted by jsoto
I believe it is out of specs. VOBUs cannot be longer than 1 second (1.2 if they are the last in the cell). But may be it works...
jsoto
Darn! that would have made it soooo simple!
OK, does that mean that if you want to make a slideshow, no audio, you HAVE to use cell still-times? You can't use one VOBU per picture, with an end PTS of however long you want it?
Jeanl

[jsoto]

if you want to make a slideshow, no audio, you HAVE to use cell still-times? You can't use one VOBU per picture, with an end PTS of however long you want it? That's what I understand, but I'm not sure... can be wrong.
EDIT: I'll look into some examples (menus) I have when I get home.

jsoto

[jsoto]

Err, the idea I have is to keep all navpacks as they are... Also very simple (although you have to pay the space of the navs)

Even in this case, not sure if a fake VOBU (only a nav) is out of specs or not.

jsoto

[jeanl]

Originally posted by jsoto
Err, the idea I have is to keep all navpacks as they are... Also very simple (although you have to pay the space of the navs)

Even in this case, not sure if a fake VOBU (only a nav) is out of specs or not.

jsoto
That's one thing the philips verifyer would catch..
But I don't like the idea of keeping all the nav packs, well, you're right, it's not really a big deal if it can fix other issues!

Jeanl

[jsoto]

it's not really a big deal 2KB per pack, so only 240-300 KB for two minutes!!. How much is this in the inmensity of 4,37 GB?
jsoto

[jeanl]

Originally posted by jsoto
2KB per pack, so only 240-300 KB for two minutes!!. How much is this in the inmensity of 4,37 GB?
jsoto
ROFL!!!!
YOu don't have to convince me! It's all the shrink-heads that you have to convince! They're a tough crowd to sell! ;)
jeanl
P.S. and besides, when everybody has dual-layer burners, the entire question will be mooooot!

[r0lZ]

There is a little side effect of keeping the playback as it was instead of converting the cell to a real still frame. When the cell has finished playing, it has to be played again from the beginning (with a LinkTopCell or similar). When this loop back occur, the subtitles are vanishing for one second or two.
Of course, it's not verry important. Note that setting the cell time to 255 will probably fix this problem, even if you keep all Nav Packs.

Take care: another scenario exists. If the original cell do not loop back (ie there is no LinkTopCell post or cell command), the playback must continue normally. So, if you decide to set the still time to 255, you must analyse the cell and post commands to be sure that it's safe.

[mpucoder]

For picture without audio you can use either cell still time (not infinite unless you want user to do something to continue) or empty vobus.

In other words, if, as a result of removing all but an I frame, you end up with nothing in the vobu but the NAV pack, that's OK.

A lot of questions could be answered by playing with Muxman :) Try it with a bmp or 2 and various still times, with and without audio, and VobEdit to see what it all looks like.

[jeanl]

Originally posted by r0lZ
There is a little side effect of keeping the playback as it was instead of converting the cell to a real still frame. When the cell has finished playing, it has to be played again from the beginning (with a LinkTopCell or similar). When this loop back occur, the subtitles are vanishing for one second or two.
Of course, it's not verry important.

but that's no different than in the original, right (except that you won't have the audio cue to indicate the menu is looping, might look a bit weird).

Note that setting the cell time to 255 will probably fix this problem, even if you keep all Nav Packs.
Take care: another scenario exists. If the original cell do not loop back (ie there is no LinkTopCell post or cell command), the playback must continue normally. So, if you decide to set the still time to 255, you must analyse the cell and post commands to be sure that it's safe.
Oh, I'm aware of that. That's exactly why I'd rather not set the still time (probably use empty VOBUs as mpucoder suggests). (and I don't know how to do that in the IFO yet ;) )
Jeanl

[jeanl]

Originally posted by mpucoder
A lot of questions could be answered by playing with Muxman :) Try it with a bmp or 2 and various still times, with and without audio, and VobEdit to see what it all looks like. [/B]
yes, you're right, as a means to see whether something's OK or not. But since we're starting with an authored cell and we don't want to re-arrange it completely (including adjusting all the difficult stuff like SRC, DTS and PTS), we don't have all the flexibility that muxman has...
Jeanl

[r0lZ]

Originally posted by jeanl
but that's no different than in the original, right (except that you won't have the audio cue to indicate the menu is looping, might look a bit weird).
Exactly.

[jsoto]

I don't know how to do that in the IFO yet If you keep all the navs (so, also the cell duration), its really easy...
- Change the lba in VOBU_ADMAP table (VMGM_VOBU_ADMAP, VTSM_VOBU_ADMAP or VTS_VOBU_ADMAP) to the new ones
- Change the Cell entry and end sectors in ADT table (VMGM_C_ADT, VTSM_C_ADT or VTS_C_ADT)
- Change the Cell entry and end sectors in PGC Playback tables

That's all.

EDIT: Sorry, also need to do a "Get VTS sectors".

jsoto

[jsoto]

Originally posted by mpucoder
Muxman uses the foillowing:

lSCR += 146;
if ((wSCR_ext += 86) > 299) {
lSCR++;
wSCR_ext -= 301;
}

Is there a typo or is there a reason I don't see?
I believe it should be
wSCR_ext-=300;

EDIT: In any case, I'm going to use lSCR+=147, because it's easier. do you see any problem on this?

jsoto

[mpucoder]

No typo, it produces this series:
0, 86, 172, 258, 43, 129, 215, 0 ...
Or, if an NTSC vobu starts on an odd field number (SCR is not multiple of 3003, but 1501.5 )
150, 236, 21, 107, 193, 279, 64, 150 ...
It works because 301/7 = 43, and we want a series that represents increments of 2/7
You can do it with floating point (300/7 = 42.85714286) and rounding, but this takes care of the rounding for you with less math.

Another side effect of using 146 2/7 is that 7 packs takes 1024 exactly. The reason is simple, the data rate of 10.08 was not chosen by accident, it is 14*8*90000, which is 14 bytes per clock tick.
2048/14 = 146 2/7 also 7*2048/14 = 2048/2 = 1024

No real problem with 147, and some things such as my DVR use it. It can mean delaying a pack, though, due to "harmonics" of the two (yours and the original's) methods. Using 146 2/7 means more good-fits, though, as it is the minimum increment.

[jsoto]

Ahh, I see... 146 2/7 is the average of the series...

Thanks.
jsoto

[Sir Didymus]

Originally posted by mpucoder
No typo, it produces this series...


Amazing... well, considering myself an expert on Numerical Analysis; having also many years of experience in DSP... Nevertheless feeling sometimes like I am living in the dark, when I see some enlightening arguments like this...

Edit: just counted - 55 characters of code... Very very dense, I would say...

[Sir Didymus]

Originally posted by mpucoder
...In other words, if, as a result of removing all but an I frame, you end up with nothing in the vobu but the NAV pack, that's OK.
...

I was [again] a little bit surprised to realise that VOBUs without video are admitted... So I checked in the Verifier Manual, and of course it is confirming this...

Maybe I can add a minor contribution, summarising few items from this document [mostly already stated in this thread], that can be useful, especially considering the possible generalisation of extracting one specific (not just the first) I-picture from a sequence...

1. First VOBU of a VOB should contain video data [...note, just first...].
2. A VOBU presentation period should be between 0.4 to 1.0 sec. [last VOBU of a cell may may last up to 1.2 sec.].
3. Presentation period of a VOBU should be equal to an integer number of video field periods [even in case VOBU does not contain any video data].
4. When the presentation period of the VOBU is longer than the presentation period of the video it contains, the last coded picture must be followed by a sequence_end_code.
5. A VOBU's video data must start with a sequence header.
6. A VOBU's video data must have a GOP header following the sequence header at the start.
7. A VOBU's video data must have an I-picture following the sequence and GOP headers at the start.

All the best
SD

[jsoto]

AFAIK, there is an additional restriction:
If one VOBU has video, the second pack must be a video one (the first is the nav one).

BTW, this restriction has made me to work with 146 2/7 instead of 147...., at least for the first & second packs

jsoto

[mpucoder]

This is why I recommend to download the verifier's user manual, it contains many quotes from the spec - almost to the point of violating the non-disclosure agreement.

On the 86/301 algorithm - my favorite mathematicians are Guass and Fermat. Favorite subject is modular arithmetic (which leads to some unique solutions to problems like this, and factoring)

[jeanl]

Originally posted by mpucoder

On the 86/301 algorithm - my favorite mathematicians are Guass and Fermat. Favorite subject is modular arithmetic (which leads to some unique solutions to problems like this, and factoring)

This has GOT to be the best thread ever! Starting from an I-frame to discussing modular arithmetic in the company of Gauss and Fermat! But don't forget Euler! Can't leave him out can you? He's the best rebuttal to Orson Well's famous quote (in "the third man") about Switzerland never having produced anything but the cuckoo clock!

Jeanl

[jeanl]

Originally posted by mpucoder
This is why I recommend to download the verifier's user manual, it contains many quotes from the spec - almost to the point of violating the non-disclosure agreement.
I did download it a couple days ago, and I agree, it's a goldmine! And it's searchable too! The official specs in paper form don't even have an index (I've seen them), good luck finding what you're after!
Jeanl

[mpucoder]

What about the Bernoulli's?
Yup, there are a lot of great mathematicians. Too many to list (I tried, then backspaced). But I can only have so many favorites, and exploring factoring using Fermat and Guass methods has been a hobby of mine. btw, I've come to the conclusion that no general purpose computer will ever be efficient at factoring (and so the RSA challenge will go unsolved), but that specialized hardware can be built (and probably has been by the NSA).

[Sir Didymus]

Well all genious, [while we are OT]... Someone really with a personal life "borderline" fashioned... But fashion was not invented yet... Gauss for example was a very big geniuos, but he was really really dirty, even for those times... He literally lived together with rats and almost never used water to clean himself... Nevertheless his work on Matrix Factorisation, Linear Algebra and the Theory of the Groups are really big achievements...

[jeanl]

speaking of rats...

I promised jsoto I would give him a picture of my hole. Here it is...


http://img205.exs.cx/img205/4804/hole4it.jpg


NOtice the nice printer. Cheap paper too!
:)
Jeanl

[jsoto]

:D :D
I can see your advanced flat monitor, but what kind of CPU is this?
:D :D
Cheers,
jsoto

[r0lZ]

Serious again, guys!

Does someone know what is the safest way to know for sure that a VOB is encrypted?

[jsoto]

I saw a thread in development forum...
http://forum.doom9.org/showthread.php?s=&threadid=72425&highlight=encrypted

jsoto

[r0lZ]

Thanks, Jsoto. It's is exactly what I wanted.

[Guest]

Where do I get this "verifier users manual" you speak of? Thank you.

[jsoto]

mpucoder posted the link in page 4 of this thread. Thanks!
http://www.licensing.philips.com/services/lover/h/documents1051.html
jsoto

[Guest]

Thank you. I scanned the thread but missed the link. Back to your normal programming...

[jeanl]

mpucoder,
How about this one!


lSCR += 146;
if ((wSCR_ext += 84) > 299) {
lSCR++;
wSCR_ext -= 294;
}


Just kidding! ;)

Anyway, the real reason for this post is that I found a DVD where SRC is increased from frame to frame by 146 85/300.

This is less that 146 2/7 so I'm puzzled. I checked but didn't find a "correction" in a later LBA (so the average would be 146.714..), the SRC keeps on increasing by 146 + 85/300. Is that bad authoring? Is that legit?

Jean

[mpucoder]

Are you sure that 7 packs later the SCR_ext isn't the same value, and that SCR increased by 1024? Scenarist, and maybe others, round down giving this sequence:
0000 000
0146 085
0292 171
0438 257
0585 042
0731 128
0877 214
1023 299
Notice that all after the first are low by 1/300, but from then on it is consistent - pack 28 has time 4095 299

If it does not have a difference of 146 086 5 out of 7 times then it is running too fast. I doubt that it bothers anything, or that Philips verifier will catch it.

[jeanl]

Originally posted by mpucoder
Are you sure that 7 packs later the SCR_ext isn't the same value, and that SCR increased by 1024? Scenarist, and maybe others, round down giving this sequence:
0000 000
0146 085
0292 171
0438 257
0585 042
0731 128
0877 214
1023 299
Notice that all after the first are low by 1/300, but from then on it is consistent - pack 28 has time 4095 299

If it does not have a difference of 146 086 5 out of 7 times then it is running too fast. I doubt that it bothers anything, or that Philips verifier will catch it.

Well, I checked, but look, they simply don't worry about it: The basic frac increment is 85, and they never correct for anything. Every 7 packs, they're too low by 5 (2*300 - 7*85)

SRC Int 371649 Frac 250 *
SRC Int 371796 Frac 35
SRC Int 371942 Frac 120
SRC Int 372088 Frac 205
SRC Int 372234 Frac 290
SRC Int 372381 Frac 75
SRC Int 372527 Frac 160
SRC Int 372673 Frac 245 *
SRC Int 372820 Frac 30
SRC Int 372966 Frac 115
SRC Int 373112 Frac 200
SRC Int 373258 Frac 285
SRC Int 373405 Frac 70
SRC Int 373551 Frac 155
SRC Int 373697 Frac 240 *
SRC Int 373844 Frac 25
SRC Int 373990 Frac 110
SRC Int 374136 Frac 195
SRC Int 374282 Frac 280
SRC Int 374429 Frac 65
SRC Int 374575 Frac 150
SRC Int 374721 Frac 235 *
SRC Int 374868 Frac 20
SRC Int 375014 Frac 105
SRC Int 375160 Frac 190
SRC Int 375306 Frac 275
SRC Int 375453 Frac 60
SRC Int 375599 Frac 145
SRC Int 375745 Frac 230 *
SRC Int 375892 Frac 15
SRC Int 376038 Frac 100
SRC Int 376184 Frac 185
SRC Int 376330 Frac 270
SRC Int 376477 Frac 55
SRC Int 376623 Frac 140
SRC Int 376769 Frac 225 *
SRC Int 376916 Frac 10
SRC Int 377062 Frac 95
SRC Int 377208 Frac 180
SRC Int 377354 Frac 265
SRC Int 377501 Frac 50
SRC Int 377647 Frac 135
SRC Int 377793 Frac 220 *
SRC Int 377940 Frac 5
SRC Int 378086 Frac 90
SRC Int 378232 Frac 175
SRC Int 378378 Frac 260
SRC Int 378525 Frac 45
SRC Int 378671 Frac 130
SRC Int 378817 Frac 215 *
SRC Int 379480 Frac 55
SRC Int 379626 Frac 140
SRC Int 379772 Frac 225


This being said, I can ignore that and use a proper increment scheme (the one you suggest seems quite good!).

Jeanl

[mpucoder]

There is one warning with that algo - make sure you never hit 300 or the result will be -1. I could ensure that in Muxman as the series always starts with 0 or 150, but you have to be more careful when patching.

[mpucoder]

I noticed an anomoly in that list, the last asterisk value of 215 is followed by 55. I would have expected 0.

[jeanl]

Originally posted by mpucoder
There is one warning with that algo - make sure you never hit 300 or the result will be -1. I could ensure that in Muxman as the series always starts with 0 or 150, but you have to be more careful when patching.
Yes, I noticed that, but I figured you know more or less the starting value (but maybe you don't!). There are starting values, probably that will yield a 300, right?
Originally posted by mpucoder

I noticed an anomoly in that list, the last asterisk value of 215 is followed by 55. I would have expected 0.

you're right! I missed that!!! I'll have to look into it!!!
Jeanl

[mpucoder]

Originally posted by jeanl
Yes, I noticed that, but I figured you know more or less the starting value (but maybe you don't!). There are starting values, probably that will yield a 300, right?
There are six bad starting values:
300-86 and downward (214, 128, 42)
And one cycle earlier 301+42-86 and downward (257, 171, 85)

[jeanl]

Originally posted by mpucoder
There are six bad starting values:
300-86 and downward (214, 128, 42)
And one cycle earlier 301+42-86 and downward (257, 171, 85)
yes of course, all you have to do is work you way back from 300...

[jeanl]

mpucoder,
As you might have guessed from the activity on this thread ;), both jsoto and I are working (not sharing code, though) on tools to shrink down motion menus to still menus (with or without audio). His version will be part of vobblanker, my version will hopefully be a small standalone tool. We're getting closer and closer to a working solution. We're now able to use any arbitrary I-Frame from the menu as the still, with or without audio.
I have a few more questions to ask, if that's OK with you:
- Assuming I'm shrinking a motion cell into a still without audio. This means the cell will now be much much shorter. I believe this implies there has to be a SRC discontinuity at the end of the cell, and there cannot be seamless playback (if that was the case originally).
- What exactly does SRC discontinuity mean? Does that mean the next pack SRC is too far away (how much is the limit?) from the current pack SRC?

Thanks a bunch for any pointers!
Jeanl

[jeanl]

mpucoder, another question!

Up to now, we've only dealt with progressive video, in which case it was easy: keep the first I-Frame and you're set. But with interlaced video we found that we needed to keep the first 2 frames.
- In our example, the first one is an I-frame, the second one is a P-frame. Can we always expect that? I'm guessing not :(
- So if the second frame is a B-frame, could this mean we might need to keep more frames to allow it to decode properly?

I'm a bit puzzled here...
Jeanl

[jsoto]

- What exactly does SRC discontinuity mean? Does that mean the next pack SRC is too far away (how much is the limit?) from the current pack SRC? 0.7 second is the maximum difference in SCR. I've read this somewhere...

So we are producing an out-of-specs VOB. To be fully compliant, I think we have to reset the SCR (and the PTSs) starting from 0 in the next cell. But, in my experience, settops do not complain about changing SCR drastically...

BTW, I cannot do this kind of things in VobBlanker because its internal logic. I need to do a big change and honor the VID/CID sequence in the VOB before thinking on them..

jsoto

[jeanl]

Originally posted by jsoto

BTW, I cannot do this kind of things in VobBlanker because its internal logic. I need to do a big change and honor the VID/CID sequence in the VOB before thinking on them..
jsoto
you mean, you can't adjust the SRC/PTS downstream, because of the way vobblanker works, right?
So do you set the SRC discontinuity flag (and reset the seamless playback) in the IFO when you shrink a cell (as in keeping only 1 I-Frame and no audio)?

Jeanl

[jsoto]

Up to now, we've only dealt with progressive video, in which case it was easy: keep the first I-Frame and you're set. But with interlaced video we found that we needed to keep the first 2 frames.
- In our example, the first one is an I-frame, the second one is a P-frame. Can we always expect that? I'm guessing not
I'm interested also in the semantics. Does exist a P-field? May be the I-Frame should contain two fields and VobEdit is labeling bad the fields, saying there is a P-Frame?

I still have a lot to learn.....

jsoto

[jsoto]

you mean, you can't adjust the SRC/PTS downstream, because of the way vobblanker works, right?
So do you set the SRC discontinuity flag (and reset the seamless playback) in the IFO when you shrink a cell (as in keeping only 1 I-Frame and no audio)?
Right and Yes.
jsoto

[mpucoder]

You guys are over-thinking a lot of this. If you leave all the following NAV packs as they were in terms of SCR, vobu_s_ptm, and vobu_e_ptm you will have no problems. You still have to zero out reference frame pointers and adjust other pointers, but the timing is correct.
Even if there is nothing else in the vobu but that NAV pack the original timing will be preserved.
SCR discontinuity is more correctly called STC discontinuity (System Time Clock) and it means what it says, a different timebase was used on the following vobu, usually a reset at a vob boundary. in normal practice the SCR will increment vobu-to-vobu by duration*frames. The muxer may vary this to accomodate peaks in bitrate. But the only constraint I know of is data cannot be placed in a buffer more than 1 second before decoding (dts-scr <= 90000)

[mpucoder]

This other thing with interlacing is interesting. I think what you're really talking about is picture_structure. There is an interaction with these fields in that a progressive frame must be encoded as a frame picture. But - non-progressive (aka interlaced) may be encoded as frame pictures or field pictures. This is the really important distinction - is it a field or a frame. If it's a field you do need the second field, and yes, it may be P.

btw - this is why mpeg freaks get annoyed with calling pictures frames - they are not frames until decoded (and possibly combined with another field picture, or field from preceeding frame with rff, or ...)

edit: had to correct my own terminology - picture_structure. It is in the picture_coding_extension.

[mpucoder]

@jeanl - to my knowledge I don't have an example of field picture encoding, could you send me a gop or 2 of one? I'd like to make sure Muxman works with them properly.

[jeanl]

Originally posted by mpucoder
You guys are over-thinking a lot of this. If you leave all the following NAV packs as they were in terms of SCR, vobu_s_ptm, and vobu_e_ptm you will have no problems. You still have to zero out reference frame pointers and adjust other pointers, but the timing is correct.
Even if there is nothing else in the vobu but that NAV pack the original timing will be preserved.
SCR discontinuity is more correctly called STC discontinuity (System Time Clock) and it means what it says, a different timebase was used on the following vobu, usually a reset at a vob boundary. in normal practice the SCR will increment vobu-to-vobu by duration*frames. The muxer may vary this to accomodate peaks in bitrate. But the only constraint I know of is data cannot be placed in a buffer more than 1 second before decoding (dts-scr <= 90000)
Well, I thought it was the way you describe it (based on some info you gave us earlier). However, I ran into a problem playing a modified DVD in IFOEdit DVD Play (I think M$ based). The 2 cells in question (1/1 and 1/2) were modified in that the first I-frame was kept, and all the subsequent video was dropped, but the audio/subpic/navpacks were all kept. I was expecting that to play normally. But it wouldn't! The first frame of the second cell wouldn't show, unless I set the SRC discontinuity in the IFO! To be accurate the 1st frame of 1/2 wouldn't show when coming out of 1/1, but it would show upon 1/2 looping back to its beginning.
I don't quite understand that...
The problem is that I didn't intend to set the SRC discontinuity flag in the IFO when I keep all the audio. But it seems from that example that it might still be a good idea... I certainly should reset the seamless playback though, right?
Jeanl

[mpucoder]

I don't understand why that is happening either. I'll have to play around with stills and cells - so far I've not used a chapter list when testing stills, so there may be something about cell boundaries.
The seamless bit can remain set, even through a discontinuity. But unless you have audio in both cells it would be difficult to notice a pause.

[jsoto]

I can also confirm unexpected behaviors in different settops. The new (cheapest ones) usually work, and also PowerDVD. But old ones (more strict, I think) doesn't like the fake VOBUs (without audio)

jsoto

[jeanl]

mpucoder,
What's the time difference between the SRC and the DTS/PTS for a subpic? I'm seeing 586 on that particular DVD I'm looking at. Does it depend on the format NTSC/PAL? I'm asking because if I need to move a subpic PACK to another spot in the cell (e.g. at the beginning), I'll have to update its DTS/PTS as a function of the SRC at which I put it, right?

I guess I could use the same different it originally had, right?

Thanks a bunch!
Jeanl

[mpucoder]

Let's back up a little - the pts/dts for a subpicture is the same as the video frame that it first overlays. The placement of a subpicture is immediately after the video pack with the first byte of the video frame to be overlaid. The only exception is if an audio pack must follow.
Simple way to look at it is consider the subpicture as part of the video stream you are moving, as the second (and later if it's longer) pack. Set its pts to that of the video frame, SCR according to the usual interval.

[jeanl]

Great!!!
Thanks a whole lot!
Jeanl

[jeanl]

mpucoder, I am facing a riddle that I don't get. No matter how hard I hammer it, it makes no sense. I'm wondering if you'll have an idea.

- Still about this idea of shrinking a cell to a still frame, + subpics (no audio in this case). My little prog is getting good at doing that.
However, I'm seeing something (on star wars episode 6) that I don't understand. I process a cell, say 6/1, only keeping the first I-frame and the subpics, and I'm attempting to turn that to a still. But it does not!. In other words, when the DVD plays that cell (PowerDVD), the time display starts at 0, but keeps on incrementing, 1s, 2s etc, using 100% of the CPU, until it reaches the original end time of the cell, then the cell loops back (it has a cell command), and the highlights disappear. This makes no sense to me because I've removed all references to the original timing of the cell:
- Start PTM and end PTM of the cell are set properly.
- Button highlight end times are set to -1, start = that of I-frame.
- PTS and DTS of the subs match those of the I-frame.
- The info in the IFO is adjusted properly: cell playback time properly set to 00:00:00.18, cell still time is 255, PGC playback time is equal to cell playback time (single cell). Cell flags are set to 2, audio status is reset etc etc etc.
- YET! Somehow, somewhere, there's a trace of the original duration!!! Because the player is counting exactly to the original end of the cell.

Now, I've determined that this info seems to be in the subpics. If I remove the subpic packs (and only keep the navpack and the first image), then everything is normal! (except of course, I don't have the highlights). The cell behaves exactly like a still (the counter does not count, the CPU usage in PowerDVD is 0%.
If I put the subpics in, the timing info seems to reappear.

I've looked in the subpic header, etc to see if there's any timing info, but I only see the PTS mentioned and it matches the I-Frame, so that can't be it, can it.

So my question is, what do you make of that?! I'm completely at a loss here. I don't understand what's going on. Any idea? Is there a hidden thingy somewhere that I'm not setting right???!!

Jeanl

[mpucoder]

It was my understanding that you wanted to keep subpictures and audio running. This method of stilling does continue the original timeline. The cell still time being set should stop it after one pass, though.
This is called by Scenarist a "still show". What keeps it running is the NAV packs. In each one you'll see normal vobu_s_ptm and vobu_e_ptm, also the vob_v_e_ptm will reflect the total cell time.

[jeanl]

Well, that's one option (keep the audio). Another option is to turn it into a complete still: 1 navpack, 1 full I-Frame, and however many subpic packs, and that's IT! 1 VOBU in all.
That works really well on many DVDs, but on star wars, somehow, the subpick packs preserve some notion of the original timing.

Does that make any sense?
Jean

[mpucoder]

Is it all in one vobu?

[jeanl]

Yes, 1 VOBU. Note that all the cells in that DVD behave exactly the same when I apply my processing, all but 1!!! The one that behaves like a still after my processing, was one to begin with!!!
I've tried to spot differences between that one and the ones I create, but I don't find anything conclusive, except that in the one that works, the subpics are at the end of the VOBU, while in mine they are 2 packs after the I-Frame (as they were in the original).
Jeanl

[mpucoder]

It's probably the duration in the subpicture itself. For a still the subpicture should have no STP_DSP command. And for a menu it should start with FSTA_DSP (Forced STArt). So far I know of no tool to disassemble a subpicture command set. I can help with that if you send one (extract as sup). Send it to muxman (at) mpucoder (dot) com (I have to spell it out, believe me, everytime I post an email address it gets spammed, so someone is scanning this forum)

[jeanl]

Originally posted by mpucoder
It's probably the duration in the subpicture itself. For a still the subpicture should have no STP_DSP command. And for a menu it should start with FSTA_DSP (Forced STArt). So far I know of no tool to disassemble a subpicture command set. I can help with that if you send one (extract as sup). Send it to muxman (at) mpucoder (dot) com (I have to spell it out, believe me, everytime I post an email address it gets spammed, so someone is scanning this forum)
Man, that's the explanation!, I didn't know there was duration info in subs! I'll send you my example, so you can look at it.

Thanks in advance for your invaluable help!
Jeanl

[jeanl]

mpucoder, what do you mean "extract as sup"? I've never done that before, what tool do I use? The VOB is on my PC...
J.

[mpucoder]

VobEdit can extract it. But if the whole thing isn't too big, just send the vob. My email server will accept up to 150MB.

[jeanl]

Originally posted by mpucoder
VobEdit can extract it. But if the whole thing isn't too big, just send the vob. My email server will accept up to 200MB.
I'll send you my extracted cell (just the VOBU I created), it's tiny...
Jeanl

[mpucoder]

Yep, both stream 20 and 21 have a stop command after 592 frames (19 seconds and 22 frames)
This is a lot easier if you unpack the entire subpicture unit, then you can follow the links. But the way I find it is to look at the last pack, the commands are at the end. They start after some zero bytes, the last 2 of which are the time code for the first set of commands (must always be zero). That is followed by a link either to the same set of commands, or the next set. Since there usually are only 2 sets, and the last one must point to itself, I just look for the same value near the end. In the case of stream 20, in pack 7 at 536 (use VobEdit, double click on the pack to view in hex) is the link to 24 CC. That link is repeated at 54e, and followed by a STP_DSP (02) command. Just before that is the time code (called STM) for the commands - 06 C8, which is 1736 in decimal form. To get the approximate duration in clock ticks multiply by 1024, which is 1777664 in this case. The reason I say approximate is that the subs are synced to the video. To get NTSC frames, divide by 3003 and round up. 592 frames in this case - now the exact time can be had by multiplying by 3003 (1777776).

But you probably just want to know how to get rid of it, right? You should just be able to change the link in the first set of commands to point to itself. You can calculate the new value based on the distance between the two links, or use the value in the first pack that leads the player to the commands. That is in pack 3 offset 22. The verifier might not like this, but the player should ignore anything after the FF byte in the first set of commands.

To be accurate you should probably follow the link at the beginning, and calculate the pes payload sizes until you get to the commands.

[jeanl]

woaw! This is entirely new territory to me! I have never heard of subpic decoding/interpreting/commands! So bear with me, if you can!
Thanks so much already for all this! Let me shoot back at you!
- How/where can I find more about all this? (hate to bug you all the time!)
- Whare are subpic commands? That's got nothing to do with DVD commands (navigation commands) right? How are they defined?
- What are links? How do I see them in hex? What do they do?

I'll stop right here! I'm going to go over the packs in vobedit and try to make sense of what you say! But I've got my explanation! I'm a happy camper!!! :)
Jeanl

[jeanl]

mpucoder,
Thanks for all the insights. I think I have a solution that does not require even looking at the subs, which will work in all cases. I'm sure glad I know where the problem came from though! A billion thanks!
Jean

[jeanl]

mpucoder, well, what I thought could work does not. Either we detect the stop command and set the still time to 0 (so the menu loops exactly as it used to, and everything is fine), or we detect and remove it!
Now, I'm wondering what's the best way to detect (and remove it).
- Assuming we know where it is, I'm guessing it's OK to replace it with an FF since I'm guessing there's not going to be any useful command after it, right? I've tried it a couple times, and it seems to work.
- The hard thing is to find that stop command. Looking for a 02 isn't enough of course, because of the data. I can probably kludge it if I assume there's only 2 packs...
Any pointers?
Jeanl

[jeanl]

mpucoder, you can ignore the message above, I figured it out, and go something working reasonably well.
Jeanl

[mpucoder]

I knew you'd figure out something - now if I can just find which one of 122 vlc codes I mistyped... (mpeg decoder)

[jeanl]

Originally posted by mpucoder
I knew you'd figure out something - now if I can just find which one of 122 vlc codes I mistyped... (mpeg decoder)
OMG! and I thought I had it bad! ;)
Good luck!

Jean

[jsoto]

@mpucoder

Here we are again, asking and asking.... :)

Well, I've seen many DVDs with more than one subs streams in menu domain (at least stream ids 0x20 and 0x21). But according IFO breakdown in your site, the number of subs (offset 0x0154) must be zero or maximum one in menu domain.

What am I missing? :confused:

TIA
jsoto

[mpucoder]

Where does it say that?
There can be up to 3 streams if the display modes allow it.

[r0lZ]

When the menu is in 16:9, you may have one stream for 'normal' display (ie full screen), one stream for 4:3 letterboxed, and one stream for 4:3 pan&scan.
Form the final user's point of view, there will be only one visible stream, because the correct stream is automatically selected for the current display mode.
This means there will be only one entry in the 'Domain Stream Attributes', but the stream status for that entry may refer to 3 different VOB streams.

[jsoto]

Originally posted by r0lZ
This means there will be only one entry in the 'Domain Stream Attributes', but the stream status for that entry may refer to 3 different VOB streams. Ah!. I see, sorry, seems it was a silly question....
jsoto

[jeanl]

mpucoder, one last little question! (well, don't really know about "last"!).
Is padding data mandatory at the end of a frame that does not occupy a full sector? In other words, imagine I have an I-frame, and an end-of-sequence code at the end of it, but imagine there's not enough space to put a padding start code with its length.

Can I just leave it as it is (i.e., end-of-sequence code and a few FFs), like:
iframe data .... end-of-sequence FF FF FF |

or do I need to add the padding start code across a new pack, like this:
iframe data .... end-of-sequence 00 00 01|
be length FF FF FF FF...

jeanl

[mpucoder]

Neither. If the space remaining is less than 8 bytes you stuff the pes header. This is done by adding the extra length to the pes header data length (fifth byte of the pes header) and putting stuffing bytes of 0xff after the header data but before the video data.

edit: don't forget to increase the packet length as well.
Typically the last pack will not also be the first for an I frame, so you should end up with a header that reads:
00 00 01 e0 pes start code for video stream 0
07 ec length of pes packet
81 00 flags
xx pes header data length (= number of stuffing bytes)
ff ... ff xx number (1-7) of stuffing bytes
video data

[jeanl]

Originally posted by mpucoder
Neither. If the space remaining is less than 8 bytes you stuff the pes header. This is done by adding the extra length to the pes header data length (fifth byte of the pes header) and putting stuffing bytes of 0xff after the header data but before the video data.
OK, thanks for the great info. This means I have to move the video data down, so the end-of-sequence code will occupy the last 4 bytes of the pack, right?

Thanks a whole lot again!
Jeanl
P.S. I'm guessing you saw that both jsoto and I released our apps to do motion2still in menus. I can't thank you enough for your help with that! I think I would still be scratching my head about these subpics stop commands!

[mpucoder]

Yup, the idea is to fill the pes packet exactly.

[jeanl]

Originally posted by mpucoder

edit: don't forget to increase the packet length as well.[/code]
yes, I had that in the back of my head, ready to fall off ;)
jeanl

[jsoto]

Originally posted by mpucoder
And it can end without enough room for a filler stream (in which case 0 fill is OK, not preferred, but it will work) This is what I'm doing if there is no room... filling with zeroes.
jsoto

[jeanl]

Originally posted by jsoto
This is what I'm doing if there is no room... filling with zeroes.
jsoto
I was wondering about that solution. Where are you putting the zeros, after the video but before the end-of-sequence, or after the end-of-sequence?
jeanl

[jsoto]

I'm replacing the sequence 00 00 01 00 with 00 00 01 B7 and filling with zeroes until the end of the pack ( max 5 bytes, in other case there is room for a padding stream, which is 6 bytes minimum)
jsoto

EDIT: I didn't test the solution because I didn't find an IFrame with the appropiate size, but with pes stuffing trick I can force the situation..

[jeanl]

OK I see. Just to clarify, sometimes you don't have a 00 00 00 01 (picture start code) because that's really the end of the I-frame and of the GOP But you still need the end-of-sequence code. Anyway that does not change anything to what you say. Thanks for the clarification.
jeanl

[jsoto]

A typo?
you don't have a 00 00 00 01 (picture start code) AFAIK, it should be 00 00 01 00
Yes, I'm looking for
00 00 01 00
or
00 00 01 B7

And replacing anyway the last byte with
B7
which is a little bit stupid in the second case :) , but the code is easier.

jsoto

[jeanl]

yes, that was a typo! (MenuShrink wouldn't work too well if I had those two mixed up ;)! )
jeanl

[mpucoder]

The zeroes will work, too, since they simply mean "expect a start code". It's not the preffered way, and most programs manipulating the video after you, even if they repack it, will retain the extra bytes.

[jeanl]

Great info, much easier for me that moving things around stuffing the header and adjusting the length (lots of places to screw up, and I only need one!!!)
jeanl

[jeanl]

mpucoder,
One more question: Imagine I'm trying to automatically detect a portion of a motion menu where things aren't moving too much (because presumably that would make a good still image).
If I assume that the encoding "quality" is constant over a small menu cell, does looking at how big B and P frames are make sense? Do you think there is a good correlation between the size of predictive frames (B and P) and the amount of motion there is in the video?

I don't know enough about motion vectors and the like to form a good opinion. Maybe there's a more direct way to assess motion in the video (like looking at the motion vectors, but that would not qualify as a simple way!).

jeanl

[r0lZ]

I imagine what you are trying to do. Good idea, jeanl!

[mpucoder]

It might make sense to do that. Motion vectors take bits, as does the encoding of the difference information. Either one is an indication that there is something different. So it stands to reason that if you're looking for a still without motion blur, it would most likely be in an area with small P/B frames.

[jeanl]

I will make some simple experiments (like reporting the size of P/B frames relative to their average size over the whole cell, as a function of time in the cell), and report back...
jeanl

[jeanl]

well, I didn't have much time to experiment with that idea :( and I'm running into a problem I haven't seen before. I'm seeing this start code in a subpic pack:
0x000001F0
which I saw one page on the web as describing as "ST_ECM"
Do any of you know what that start code describe? vobedit says "unknkown". I'm puzzled...

jeanl

[mpucoder]

It's called the "Entitlement Control Message" and is mentioned in ISO 13818-1, but because it is a private (application specific) message it's not fully described. It is a pes packet like the one used for NAV packets, ie no header extension data, just packet length.
It does not belong on a DVD, the only use I could find was for digital broadcasting to trigger Macrovision.

Edit: I found another use, but, again, for digital broadcasting, not DVD. It is used to coordinate descrambling in set top boxes. See here (http://www.hitech-projects.com/euprojects/smash/deliver/del05/del05-03.htm) do a "find" on "entitlement"

[jeanl]

Great mpucoder! Thanks a whole lot. I found it on a DVD though, so I'm puzzled... I'll look into it!
Thanks!
Jeanl