Hey, that’s another good question, SurfDrifter.
Before I even begin to answer it, though, I must make a very clear statement that the physical re-ordering of existing MPEG data (e.g. a VOB), according to cell boundaries (which, through the concept of PGCs, is how TFDVDEdit implements seamless interleaving), rests upon the critical assumption that GOP header I-frames have been encoded at the relevant cell boundaries. Attempts to re-order existing MPEG material by ‘cutting’ it at these points, and re-sequencing, will not necessarily be wholly successful owing to B frames potentially ‘losing’ their related adjacent reference frames following reorganisation of GOPs. Thus, seamless-interleaving can only be assured of success if assets have been specifically encoded accordingly. I will shortly be publishing a web tutorial on how to prepare suitable assets, and you will see the (simple but rigourous) lengths that have proven necessary in order to produce robust-enough GOP header I-frames in the subsequently-interleaved MPEG material. Consequently, given that you stated that you have already demuxed and reauthored the project, the best solution would be for you to slice and dice your elementary assets, and resequence them in the desired order, prior to remultiplexing. That being said, I’ll get on with addressing the theory of your question from the context of reauthoring without demuxing, using TFDVDEdit, which is, after all what prompted your question in the first place, is it not?
The question can be interpreted in a number of ways. However, rather than wrestle with what you may or may not have precisely meant, I feel that it may actually be
beneficial to offer answers to more than one interpretation, since it allows me to discuss a number of interesting issues and these issues may spark further ideas, which, in my view, is a great opportunity. Accordingly, I
hope that you will not feel that my multiple interpretations are misrepresentative of your intended query or that you have been misunderstood! After all, we’re all here to be creative, solve problems, and exchange ideas, right..?
Ok, if I firstly take the stance that you require not only a forward-ordered version of the story, but
additionally a reverse-ordered version, then in this particular instance, I think we are dealing with a slight misconception – although interleavable in
principle, this is not actually an example of Seamless-Branching and would not benefit from the procedure in the sense implied. In order to create seamless versions of both the forward and reverse PGCs, duplication of VOB material would be necessary. The reason for this is that DVD data, as you are well aware, lies on a linear track. During playback, this track is likewise followed linearly by the laser. Any deviation from this linear playback pattern, data being read from the track in a sequential manner, results in laser seek time, and probable buffer emptying as a consequence. Therefore, as you can imagine, one set of data cannot be sequentially ordered in both directions at one and the same time, no matter how skilfully it is distributed during an interleaving procedure!
By way of illustration, you can see below that PGC 1 would necessitate the physical placement of Chapter 1 data at the beginning of that PGC area on the DVD disk (remember that data cannot be read
seamlessly if it lies in the data track in a physical order at odds with the desired order of PGC playback,). However, PGC 2 would require the placement of Chapter 1 data at the
end of PGC 2 on the disk.
PGC 1 = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
PGC 2 = 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
Now, of course, this requirement could be satisfied by conceptualising the PGCs as follows, with PGC 2 starting first:
12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
but then we would have all other chapters disparate from each other, and, with only one instance of each physical cell of data, whichever way we might move a given cell to better suit one PGC, this would be at odds with the requirements of the other PGC.
Put simply, Seamless Interleaving is all about the skilful manipulation of data to most efficiently distribute it according to least-action principles, for multiple alternative PGC navigation, but it simply cannot circumvent the laws of sequential physical data distribution if seamlessness of playback is to be maintained. Consequently, wherever two or more PGCs refer to identical assets but dictate diametrically-opposed orders of playback, physical duplication of data must be employed in order to achieve seamless playback. Admittedly, seamless playback, in its very
essence, does involve the laser ‘jumping over’ VOBUs not related to the current PGC, in order to reach the next required group of VOBUs, to continue playback of the PGC without the buffer emptying. In this sense, the data on the
disk is not seamless, but the increments are small enough for the buffer to ‘bridge’ the jumps, and, critically, the data is nevertheless
sequential – i.e. the laser never has to jump backwards (nor could it) during seamless playback. Thus, the sequential rule is still adhered to.
Obviously, none of the above is relevant in a discussion of conventional PGC stories – only where absolute seamlessness of playback is required for both PGCs!
Despite all of this, there may still be justification for applying seamless interleaving to just such a scenario,
even though it will not reduce data duplication:
Interleaving the aforementioned scenario:
PGC 1 = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
PGC 2 = 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
so as to make the two PGCs ‘mingle’ with each other, could bestow the advantage upon the PGCs of enabling each of them to be accessed at similar (rapid) speeds from a selection menu, rather than one PGC’s physical VOB data residing much closer to the related VTSM data on the disk than the other PGC’s data (remember that in this unusual instance, where both PGCs must play seamlessly, they do, in fact, as described above, each relate to distinct sets of physical data). It’s a small point, but one worthy of consideration if you like to make navigation from menu to target asset as swift as possible, even where there may be alternative options available to the viewer. Primarily, the program is understandably aimed at ‘bona fide’ instances of true Seamless-Branching., involving certain proportions of shared cells between two or more PGCs, none of which have
entirely diametrically-opposed playback (although this is allowable, if asset duplication does not concern you).
Ok, leaving those secondary considerations aside, and returning to the core question of how to achieve seamless playback of a ‘reverse-ordered’ PGC, let’s look at an alternative interpretation, where we don’t need both PGCs.
In theory, I could have a VOB which was originally authored with a
physical distribution of chapters as follows:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
which, I believe, is what you have on your existing commercial disk, but wish to alter to a PGC with playback as follows:
12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
Now, as described earlier, in order to playback a PGC
seamlessly, the data to which it pertains must be arranged in the same sequential order. In this interpretation, however, we do not require the seamless playback of two diametrically-opposed PGCs. All we require in this instance is the
re-distribution of our physical data such that it conforms to the sequential playback order of just one ‘reverse’ PGC. Thus, no duplication will be required, but we must find some way to operate upon our VOB in order to manipulate it into the desired physical order, based upon the already-existing chapter cell boundaries.
This leads quite nicely onto discussion of yet another feature which will shortly be implemented in TFDVDEdit – namely that of manual VOB
editing on the PGC, cell, and even NavPack level. Before long, the program will be capable of inserting a NavPack, or Cell of VOB data into an existing VOB, or alternatively, removing a NavPack or Cell of data. Although there will initially be limitations on this, where a VOB comprises MPEG material that does not have a Closed GOP structure, the feature will nevertheless be extremely powerful, particularly for still menus, which often comprise just one GOP of data, which, by virtue of it’s brevity and isolation, is of a closed structure. This facility will be applicable both manually, and by means of PGC logic, although the final rules of implementation have yet to be finalised by the programming team. This feature alone has huge potential. What is so fascinating about each of the features being added to the program is that they each bring with them an exponential range of possible uses, given that multiple combinations are possible between them. Thus, the addition of one feature often transpires to be, effectively, the addition of several features, by virtue of these combinations. Furthermore, since the program offers features which have never before been available, and which are applicable to the output of literally ANY authoring system, ‘after the fact’, we are now witnessing the birth of creative ideas which have
never before been seen in the world of DVD authoring.
Back to the immediate present, though, TFDVDEdit already has the capability of redistributing VOB data, ‘automatically’ by means of the PGC interleaving function, devised expressly for the purposes of Seamless-Branching. Perhaps there may be some way in which we can harness this for alternative means. How can we, without invoking duplication of material, coax the interleaving function to reorder the material into the desired sequence? Well, there is no perfect solution (although this will come with the deliberate implementation of manual VOB editing, in the near future), but there is a potential workaround for the present:
12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
We cannot interleave a PGC with itself, that much is certain, and, in fact, we do not, in this instance, actually require interleaving per se. However, that is the only manner in which we can currently persuade TFDVDEdit to resequence a VOB (an amazing capability in itself). This isn’t really a ‘failing’ of the program – it’s simply a very bizarre situation that one would wish to re-sequence a VOB rather than sequencing it appropriately, during the original encoding / authoring (and again bear in mind my reservations about GOP header I-frames). Still, I like a challenge!
Acknowledging this fact, then, let’s think creatively. We must create a PGC of some description in order to ‘interleave’ it with our intended ‘reverse-ordered’ PGC. We now know that any attempts to create a PGC which deviates from the sequential order of our intended end result will only invoke duplication of data (and deleting that PGC following interleaving will not remove it’s associated interleaved data, so that’s not a solution to the problem), so we must avoid that at all costs. There is nothing to say we cannot remove certain cells from a PGC, though - this doesn’t create
opposing directions of playback.
One conventional style (there are several) of Seamless-Branching involves the creation of a ‘Highlight Reel’. This style of Seamless-Branching essentially involves the ‘removal’ of certain scenes from a Main Feature film, in order to compile a shorter version. However, S-B makes this possible without the need to duplicate all the material included in the shorter Highlight Reel. However, there is a small penalty – in order to have a ‘Highlight Reel’ PGC play seamlessly, yet draw it’s material from the Main Feature itself, it must be cleverly interleaved, at it’s ‘gaps’, with the main feature. So how is this possible? Well, obviously the common sections of both the Highlight Reel and the Main Feature require no duplication – they run (in my simplistic example, at least) in the same sequential order – that is to say, no PGs are sequentially opposed, across the two PGCs. However, while playing the Highlight Reel, the laser cannot make the huge leaps across the gaps where scenes have been removed, without playback pausing due to buffer underrun (non-seamless). Therefore, it is necessary for TFDVDEdit to create ‘stepping stones’ across the gaps, so that the laser need only make incremental jumps, meaning the video buffer does not run out. Obviously, these ‘stepping stones’ are not made from thin air – they are created automatically by the interleaving routines, which skilfully conjure MPEG ‘filler’ material for the purpose (there is, in fact, more than one way of achieving this aim, but I will not elaborate further on this at the present time, as it is not strictly relevant to this discussion). Now the relevance of this, in our example is that the ‘stepping stones’’ filler material is defined by the DVD Spec as needing to be a minimum of 10% of the ‘gap’ they serve to bridge. I will come back to this fact in a moment.
Consequently, having identified a ‘signature scenario’ that TFDVDEdit’s interleaving routines recognise, we can invoke them into efficiently re-ordering our VOB for seamless playback, and with extremely minimal duplication penalty, by contriving an analogous scenario, and this purpose would be served simply by creating the following two PGCs:
PGC 1: 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
PGC 2: 12, 11, 10, 9, 8, 6, 5, 4, 3, 2, 1
You will note that in PGC 2 I have removed chapter 7. Because of the manner in which I have contrived these two PGCs, they differ in such a way as to appear to TFDVDEdit as a ‘Main Feature’ (PGC 1) and a ‘Highlight Reel’ (PGC 2), they therefore constitute legitimate fodder for seamless interleaving. It doesn’t matter that the PGCs are in reverse order to the native physical order of the VOB. We have created the carrot TFDVDEdit requires in order to operate upon our VOB and ‘repacketise’ it, according to out own nefarious means!
TFDVDEdit will not duplicate any chapters because they are in consistent sequential order across both PGCs (albeit with one chapter missing from PGC 2). The only unusual attribute of our finished VOB will be that TFDVDEdit will have created and interleaved a small amount of material with Chapter 7 in PGC 1. The amount, as I described above, will be 10% of Chapter 7. Now this will be fairly negligible, however, you might care to look at all your chapters
prior to removing one in the manner that I did, in order to choose the chapter which is shortest, and will thus require the least amount of filler for interleaving purposes.
So, after interleaving we will be left with two PGCs. PGC 2 is now redundant – all we needed it for was enticing the program into performing the procedure, so we can now delete PGC 2 using the PGC ‘Program Map’ feature. If you have read the manual (and you say you have) then you will know just how outrageously simple PGC deletion is! Your final result (PGC 1) will comprise your original VOB material, reordered into ‘reverse’ sequence, and with a little harmless filler interspersing the chapter you chose for tricking the program into interleaving:
PGC 1: 12, 11, 10, 9, 8, -7-, 6, 5, 4, 3, 2, 1
Continued next post...