How to get a single I-Frame??

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