How to get a single I-Frame??

[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.