Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > (HD) DVD, Blu-ray & (S)VCD > IFO/VOB Editors

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th May 2017, 19:05   #1  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
PGCDemux: extract one PGC VOB vs. multiple VOB ID's per PGC

Based on a VideoHelp thread, I got a bit confused about the features of PGCDemux and the meaning of structure units on a DVD Video.

I assumed that PGCDemux is able to extract one PGC to a continuous "PGC VOB" file. To achieve that, you will have to check two boxes (one of them depends on the other):

[√] Create a PGC VOB
+ [√] One file per VID (if this is not checked, you will get VOB files split at each GiByte).

Now, the DVD in the linked thread apparently has several VOB ID's in a PGC. This makes PGCDemux split the PGC VOB at their break. So I tried to read in the WWW what a VOB ID is, at all ... with only little results: It is used to group cells in a PGC. Okay. But why? No reasons explained under which circumstances one may need more than one VOB ID per PGC.

I wonder: Is it related to the Layer Break?

So I hope you can tell me reasons why some DVD's have more than one VOB ID per PGC, and if PGCDemux has good reasons to split the extraction here, or if you can make it ignore that and create a VOB output across VOB ID's for the whole PGC. If not ... then it may require different software to do so. Or concatenate the parts after extraction.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th May 2017, 08:25   #2  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
IMO, the usage of the VOBs depends mainly of the authoring program. I have noticed, for example, that on many commercial DVDs, the VOB ID changes for the layer break cell, but it's not at all mandatory. (The LB must be at the beginning of a new cell, but not necessarily at the beginning of a new VOB.)

Other than that, if a domain has several PGCs with different video content, it is of course mandatory to use a different VOB IDs for each clip. (It's why PgcDemux has its "One file per VID" option. It's handy to split a "play all PGC" to its different parts, such as episodes. But as you know, it will also split at most layer-break cells, even if you don't need that.)

IIRC, it is also mandatory to use different VOB IDs for the different angles of a multi-angle movie, but honestly, I don't remember exactly.

I don't think there are other cases where a VOB change is mandatory.
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 9th May 2017, 10:59   #3  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,769
To my knowledge there is no clear definition of what a VID is, with respect to its uses.
However, based on the movies I have analysed, I can tell that different VIDs are used when there are parts of movies (scenes) that come from different parts and "joined" in (logos, credits, sometimes the "defective" cells).
But most times the only different VID is associated with the last, empty cell - used to jump at the end of the movie.

The requirements of layer break does not explicitly request a VID change, only a new CID (which may have a new VID, or not).
__________________
Born in the USB (not USA)
Ghitulescu is offline   Reply With Quote
Old 9th May 2017, 16:24   #4  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 953
A VOB ID (VID) is the unique identifier of a VOB unit, as the CELL ID (CID) is the identifier of a cell within a VOB... No?

Quoting (from Dvd Demystified, 2nd edition, 2001)...

<<
Each video object set (VOBS) is composed of one or more video objects (VOBs). A video object is part or all of an MPEG-2 program stream. The picture resolution and display rate are the same for all video objects in a video object set. Granularity at the VOB level is designed to group or interleave blocks for seamless branching and camera angles. Each VOB set contains one or more VOB blocks. A contiguous block contains one VOB in contiguous sectors on the disc. An interleaved block contains multiple VOBs broken into interleaved units (ILVUs) that are physically interleaved on the disc to enable seamless presentation. The size of the ILVUs is determined by the data rate of the streams, with the size kept small enough that the pickup head has time to jump over the intervening units of other video objects to get the next unit in sequence before the track buffer is depleted.
A VOB is made up of one or more cells. A cell is a group of pictures or audio blocks and is the smallest addressable chunk. A cell can be as short as a second or as long as a movie. Some authoring systems call cells scenes.
>>

Last edited by Sir Didymus; 9th May 2017 at 16:28.
Sir Didymus is offline   Reply With Quote
Old 9th May 2017, 18:01   #5  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Thank you for your explanations, it's now clearer that there are several possible, but not many necessary reasons for multiple VOB ID's per PGC.

Furthermore, it seems that PGCDemux will split either at GiBytes or at VOB ID changes, so if you want a continuous PGC VOB despite several VOB ID's, you may have to use different tools (maybe vStrip). As long as I did not miss a combination of options which can make PGCDemux ignore VOB ID changes.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th May 2017, 18:04   #6  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
Quote:
Originally Posted by Sir Didymus View Post
A VOB ID (VID) is the unique identifier of a VOB unit, as the CELL ID (CID) is the identifier of a cell within a VOB... No?
Sure. But why 2 different types of blocks (VOBs and Cells)? Apparently, according to your quote, VOBs are necessary for seamless branching (multi-angle and multi-story), as I thought. It seems that they are mandatory only in that case.

Thanks for the info!
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 9th May 2017, 18:08   #7  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
Quote:
Originally Posted by LigH View Post
Furthermore, it seems that PGCDemux will split either at GiBytes or at VOB ID changes, so if you want a continuous PGC VOB despite several VOB ID's, you may have to use different tools (maybe vStrip). As long as I did not miss a combination of options which can make PGCDemux ignore VOB ID changes.
The VOB files are simply cut at specific points, without other changes. If you really want a single VOB file with several VOBs and greater than 1GB, you can use any option of PGCDemux, and then concatenate the resulting VOB files together to re-create a single VOB file. (The good old MS-DOS copy command can do that easily.)
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 9th May 2017, 18:51   #8  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
But that requires more than one tool... I guess vStrip may work in such cases. Or a real ripper, straight from the DVD disc.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 10th May 2017, 22:51   #9  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 953
Yes, r0lZ! How to say, it is complex, surely redundant (agreed!), but the DVD-VIDEO is specified this way.

The VOB data type for the DVD format is the key multiplexed format supporting the synchronised presentation of a video channel + 8 audio + 32 subpicture streams simultaneously, including nice multimedia features such as multiple video angles and seamless branching.

Video Object Sets are a collection of Video Objects, VOBs are divided into cells and cells are composed of VOB Units, that are a sequence of packs. This is the hierarchy.

Cells are more or less consisting of individual scenes of a movie.

If we want to support in a single video channel the presence of multiple angles of the same scene, it is (quite?) logical that the cell ID of a given scene is left unchanged among the different angles, using the VOBs and the VID, in the upper level of the data format to support this feature.

@ LigH: as reported by others in the original thread in the VideoHelp forum (manono has been pointing this out), very rarely there is a good technical reason - IMHO to demux a DVD into individual VOBS, apart the curiosity and the (always valid) willingness to learn about the format. Using the IFO structure (it is there for a reason, no?), and demuxing by PGC is the way to go...

Last edited by Sir Didymus; 10th May 2017 at 22:57.
Sir Didymus is offline   Reply With Quote
Old 10th May 2017, 23:00   #10  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Of course. The logical structure of a DVD Video medium is to be found in the IFO files. A pity PGCDemux has its quirks unter specific circumstances, it used to be one of the most useful tools when you already ripped the whole content from the disc. I wonder if an option can be added to split neither at segment sizes nor at sub-structure units of a PGC.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 11th May 2017, 07:54   #11  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,769
I really do not understand the problem.

The OP in the linked thread specifically asks for a demux/split according to VID then complains the tool does exactly what he asked for?

If he wanted the movie he should have selected the right option, "by PGC", since the movie is in one PGC only.

PS: there are movies split across two consecutive titles or similar, but very very rarely.
__________________
Born in the USB (not USA)
Ghitulescu is offline   Reply With Quote
Old 11th May 2017, 08:20   #12  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
He wants a single VOB file. PgcDemux splits the movie by VID or by chunks < 1GB. IMO, it's normal, because the VOB file is a DVD specific format, not like MPG. And since files >= 1GB are prohibited on a DVD, it is normal to respect that rule. However, I understand that some authoring programs require a single continuous VOB file to import it easily. IMO, it's a problem of the authoring program, not of PgcDemux, although an option to join the parts automatically would be nice.

Jsoto has stopped the development of PgcDemux, but there is a mod version available at VideoHelp. I don't know its author, but perhaps he will accept to add that option?
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 11th May 2017, 08:45   #13  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 953
@Gitulescu
There is no problem: we are simply "overlooking" to the request from a newbie who is in the stage of learning about the DVD-VIDEO data format (which is, frankly speaking, starting to become obsolete, after ~20 years from its introduction in the 1997)

Quote:
We live and learn. Thanks again to you all for your time.
@r0lZ
Naaa...
A single VOB file > 1 GB?!?!
It would be an unwise and silly feature...

You can built it easily (if you want, as you have already pointed out) by using the good old binary copy cmd line to concatenate files...

However, the resulting file will be:
- not needed to anything
- not useful to anything
- uncompliant with everything

What authoring program require a single continuous VOB file to import it easily?!?!

The authoring programs working with VOBS need to internally demux the data format into synchronized video, audio and subpicture assets. Why not feeding directlly them with the (properly demuxed) original assets, given that the existing features of PgcDemux are already fully providing this capability of extracting all of the individual assets, together with some nice ancillary information about audio delays, etc.?

Last edited by Sir Didymus; 11th May 2017 at 08:54.
Sir Didymus is offline   Reply With Quote
Old 11th May 2017, 09:03   #14  |  Link
r0lZ
PgcEdit daemon
 
r0lZ's Avatar
 
Join Date: Jul 2003
Posts: 7,469
I agree. Not sure why LigH wants a single file. Perhaps to play it with a player supporting VOBs? IMO, in that case, it is better to convert it to MPG.

Anyway, the interesting discussion in this thread is why there are cells and VOBs, and their respective usage. The output of PgcDemux is just fine for me, and IIRC I have never used it to create VOBs. I have always demuxed the elementary streams. So, for me, the 2 options to create VOBs by VID or 1GB chunks can simply be removed! But if they exist, it's probably because some peoples need them. It's why I have assumed that some authoring programs need the full VOB files as well. I use muxman, and therefore I don't know the other authoring programs.
__________________
r0lZ
PgcEdit homepage (hosted by VideoHelp)
BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV
r0lZ is offline   Reply With Quote
Old 11th May 2017, 10:16   #15  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,769
Quote:
Originally Posted by Sir Didymus View Post
A single VOB file > 1 GB?!?!
It would be an unwise and silly feature...
I could have used such a feature in the past.
One reason is to use larger than 9GB files, since again the DVD specs restricts to 9 the number of VOB files in a title.
How can one come to DVDs larger than 9GB? Simply by combining two discs containing two parts of a movie, in order to "shrink" the results in a DVD9 size. Doing them separately is suboptimal
Quote:
Originally Posted by r0lZ View Post
I agree. Not sure why LigH wants a single file. Perhaps to play it with a player supporting VOBs? IMO, in that case, it is better to convert it to MPG.
MPG does not have all the features VOB has.
__________________
Born in the USB (not USA)
Ghitulescu is offline   Reply With Quote
Old 11th May 2017, 14:31   #16  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
It's not me who wants that. It's the author of the VideoHelp forum thread. And he believes he wants to use a video editor to import a whole movie, which can read MPEG-PS (maybe including the VOB extensions).

I just wanted to know (academically) if it can be achieved with PGCDemux alone, at all. And from my experience, it's only possible if the PGC has only one VOB ID. If it has more than one, PGCDemux alone is not sufficient, you have to either concatenate parts, or use a different PGC-VOB extractor.

A continuous PGC-VOB file is not even that silly. Neither FFMS2 nor L-SMASH Works are able to handle a set of VOB segments (well, for both of them, extracting a continuous raw M2V video stream would work as well); and a VobSub extractor like VSRip works with a continuous PGC-VOB just as good as with a segmented VTS. When I ripped DVD's years ago, I preferred to demultiplex audio streams via "Stream processing", but extract video stream and subtitle streams together as PCG-VOB while reading from the optical DVD disc, then extracted VobSubs from this PGC-VOB with matching reduced IFO generated by the ripper.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 11th May 2017, 16:29   #17  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 953
Quote:
One reason is to use larger than 9GB files, since again the DVD specs restricts to 9 the number of VOB files in a title.
...
Quote:
A continuous PGC-VOB file is not even that silly.
...
These restrictions are there for many valid reason. First of all using directly VOB files for playback or video editing is not a good idea in general. Which angle to play/use? Which audio? Not to say about the subtitle colors that are gone away because they are located into different files (the IFOs). Then what about timecodes that after two hours jump back to 0? And sector indexes with addressing capability limited to 1 GB?
Please understand that I do not want to appear rigid and constrained to the "rules" just because they are "rules". The point is that if you pick out from a DVD-VIDEO a piece of data (a VOB chunk) presuming to get a consistent AV playable content, you make a mistake. Bad idea, poor understanding of the operation, very bad practice. What you get is not a "playable subset" of the DVD! It is a piece of data eradicated and disconnected from the structure where the crucial information needed to implement the coherent playback of this content is stored. Same sort of troubles happen when you try to create "larger than 9GB DVD". Users may be happy to apply bad practices, and application surely exists to handle more or less properly these chunks of VOB files, but these remain bad practices... That's just my opinion, of course...

Last edited by Sir Didymus; 11th May 2017 at 17:16.
Sir Didymus is offline   Reply With Quote
Old 11th May 2017, 18:03   #18  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Never forget to see advantages and disadvantages in the context of a specific use. A tool which ignores most of the reasons for disadvantages, anyway, may focus only on the few selected advantages for its own purpose. As long as the file stays on your harddisk only, and only during a conversion job, who cares about sector numbers on optical discs where it never goes back? If you use a decoder which cannot handle playlists, but only single media files, being a continuous file is so much more important for this specific decoder than any disadvantage for authoring tools it will never go back into.

BTW, I wonder about the 2 hour limit of timecodes you mention; which format are they related to? I already worked in a DVD Authoring studio, and I do remember that Digital Betacam tapes use timecodes around +10 hours (to avoid a counter underflow during a rewind, which causes issues), and the encoded MPEG-2 video in raw can store them easily. And decoders will probably prefer timecodes in the MPEG-2 stream when indexing MPEG-PS media files (no matter with or without used DVD Video extensions supporting non-MPEG audio in Private Streams).

Of course, I can agree to your opinion. You just may be focused on some rather unusual points of view when it comes to 1) ripping, 2) decoding, 3) deleting the ripped material when the copy is finished. But I confess I don't know how much editing the author of the VideoHelp thread had in mind. Your concerns may apply there more than in my context.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 11th May 2017, 23:10   #19  |  Link
Sir Didymus
Registered User
 
Join Date: Mar 2004
Location: Italy
Posts: 953
Well, yes... It's not related to the PTS and DTS and SCR on their own. The timestamps are stored in 33 bit entries (having a time resolution of 1/90KHz, which is enough to store much more than 2 hours)... And it is not exactely 2 hours. The story of this limitation depends from the general initial target for the specifications of the optical support. Given that a single layer of a DVD disc contains 4.7 GB of data, and dividing by a bitrate of ~5 MBps (the half of the max allowed bitrate), you get more or less two hours of "good quality" material stored in a DVD-VIDEO disc. The initial target specifications were at the beginning of the story absurdely precise about "the storage capacity of 133 minutes of high-quality A/V in the DVD-VIDEO discs"...

Nevertheless what you get is that if you start with legit individual VOBs and you join them with a straight and simple binary copy without recalculating all of the involved PTS and DTS and SCR timestamps, you can not avoid these "2 hours" jumps and discontinuities among the chunks...

Last edited by Sir Didymus; 11th May 2017 at 23:14.
Sir Didymus is offline   Reply With Quote
Old 12th May 2017, 08:15   #20  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,769
I do not know what the original poster in the originally linked thread intended to do. In my view, expressed some posts above, he misused the software.

But, based on what he and LigH and other said, I imagined there might be a reason why one would like to have such long and large file/s.

In my personal case, unrelated to what was discussed above, it was about a documentary series that had some episodes artificially split over a number of discs (the entire doc was a bit more then 9GB, and it was split to allow trailers and other useless things to be put in). No matter what I have done with current tools, freeware, I could have not managed to join them back, without employing a trick.
Do not mix this separate case with the others. It was only an example of why one would need such a function.
__________________
Born in the USB (not USA)
Ghitulescu is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.