Extracting info from IFOs for Slideshow/Storyboard PGCs

[Dr.Khron]

One of my Simpsons DVDs has a storyboard special feature for one of the episodes... you can listen to the audio track while a series of still frames flashes before you in real time.

I asked about how to encode this in the Avisynth forum. When someone mentioned that the timing information was stored in the IFO files, I realized that my question belonged here.

I fired up PgcEdit and took a look. Couldn't find anything.
The PGC is 22:58 min long, but it only consists of 238 frames and three cells... and yet it still appears as 29.97 FPS NTSC video. I can't find any useful information as to the original timing of the slides. However, it must be in there, since it plays just fine as a DVD.

[blutach]

Quite likely, the video is muxed as a single frame and then additional navpacks, each increasing the PTS until the next slide comes on.

Double click on the PGC in PgcEdit to see each cell's timing.

Regards

[r0lZ]

If your slide show has sound, then it is probably made of still pictures with audio. Only one single image is necessary. The sound track determines the timing. Even without sound, the same technique can be used, as blutach explained.

On the other hand, a picture-only slide show (w/o sound) can also be made of several single picture cells with a cell still time (eg. a pause) at the end of each cell. Seems it's not the case here, as you said "The PGC is 22:58 min long."

Anyway, in both cases, you can't convert easily such slide shows to real video streams, unless there is a trick that I don't know. You could, for example, try to repeat the single frames during a certain amount of time. The difficulty is to determine this amount.

Sorry, I can't help much more...

[Dr.Khron]

On the other hand, a picture-only slide show (w/o sound) can also be made of several single picture cells with a cell still time (eg. a pause) at the end of each cell.

Yes, this is the behavior I was expecting; ie. 238 cells for 238 frames. However, its 3 cells (3 cells, 3 PGs, 3 PTTs) with zero still times, and a full length run time for the PGC.

The solution I came up with was to run the AVS at FPS = 238/(run time in seconds) This makes it run the full length of the audio, but every slide has the exact same timing. Thats probably good enough, but I'm still curious about how the original timing is stored in the DVD.

The sound track determines the timing. Even without sound, the same technique can be used, as blutach explained.

Uh, not sure that I follow. You mean that the audio track has timing data embeded in it? Looking at the cell times in PgcEdit is not very enlightening, it just gives the frame counts for the two breaks between the three chapters.

[blutach]

Look inside the Vob with VOBEdit - you'll see exactly what we are talking about. A navpack, followed by some video packs, then some audio. More navpacks (the time is in these - see the VOBU start and end PTM entries at 0x0039 and 003d of the PCI block) and audio packs. The time is based on a 90,000Hz clock and so is very accurate. There is also an entry for the cell elapsed time at each navpack (0x0045).

Then, when the display of the frame is over, you'll see some new video and the process will repeat 238 times. :)

Regards

[Dr.Khron]

Aha, now it makes sense! Thanks for the guidance.

Of course, there is a ton of information in there I don't understand... I know that there is no comprehensive guide to VobEdit, but is there a good guide on how to understand the muxing information ?

[r0lZ]

mpucoder! :D

[mpucoder]

I forget whether Scenarist calls these a slideshow or a stillshow (the distinction is clear, but the choice of terms is not) One has no sound, and the timing is indeed in the ifo as each cell has a still time (which freezes everything, including any sound that may be muxed in).

What you are describing freezes just the video by adding "virtual frames". Each "slide" consists of one video sequence (and can be motion video, not just a single frame). The sequence is then extended by setting vobu_se_e_ptm (at offset 0x041 of the NAV pack for the VOBU containing the sequence_end) to the exact time (must be multiple of frame duration) to end the slide. If you demux the video you should find 238 sequence_end headers in it, these are required to add virtual frames to extend the playback time of the video.

In VobEdit vobu_se_e_ptm is shown as "End PTM of VOBU if Sequence_End_Code", which is the exact meaning of the value. Every VOBU in which the video has a sequence_end must specify this value. If the video is to run normally the value will be the same as vobu_e_ptm (offset 0x03d, 4 bytes prior to vobu_se_e_ptm) and no virtual frames will be added.

One very important feature of virtual frames is that, unlike a cell still, the timing continues to run and not only does audio continue to play, but so do subpictures.

MuxMan can produce titles like this, but unfortunately in the free version the timing is the same for each slide and defaults to 5 seconds. If the video contains 2 or more sequences, and the first sequence is a single frame, then MuxMan creates a slideshow automatically for you. The pro version can set individual times in an akward manner by using, in your case, 238 occurences of the same video file and specifying the start time as a sequence number

[Dr.Khron]

Thanks for your guidance.
I'm able to jump around in Vobedit now, and see the different packs... its easy to see when a Navpack is going to have the relevant line, becuase each frame is the exact same name of packs, and becuase the amount of audio packs muxed in is roughly proportional to the amount of time delay in that register.

I made an excel spreadsheet to do the calculations and output a text file with all of the Avisynth strings that I need, but that still means that I need to manually scroll through, identify the relevant navpacks, and cut and paste the value into my spreadsheet.

Is there any way to automate this process? Its kind of combersome, took me 15 min to do about a 1/3 of it.

If I could dump the text from ALL of the navpacks at once, I could paste it into excel, and easily sort out the relevant lines.

Are thier any other tools besides VobEdit that will allow me to view the navpack data? Maybe some way to demux just the navpacks?

[jsoto]

Not sure if helps, but pgcDemux can create a pseudo VOB file with only the (untouched) Navs. Easy to manage in Vobedit.
jsoto

[Dr.Khron]

Hmmmm... I'm already working from a Pseudo-VOB created by PGCDemux, I just left everything in. Having navpacks only might actually make it harder to identfiy the packs that contain the relevant timings.
In order to automate, I still need a way to dump the navpack info to a giant text file.

[r0lZ]

As far as I know, there are no tools to do that. But you can probably write a simple program to do it yourself. It is easy to find the chain of the nav packs, and the info you need to print should always be at the same location in the packs.

[Dr.Khron]

LOL, thats assuming I know how to program!
I work in finance (I'm a CFA), so I only know how to program in MS VBA, and even thats limited to mostly Excel and Access stuff. I don't know how to code real applications.

Basically, if my input is in text format (with or without commas), I can make it sing and dance... anything other then text, and I have no way of manipulating the data. Sorry man, I'm just not that bright. :)