View Full Version : Seamless Branching DVD: what I need?
dark.soft
30th April 2004, 15:15
Well I want to do a DVD with seamless branching, with a main movie and with another but with other scenes. So what I need? I have an m2v file of the entire main movie, I have the scenes to be replaced, I have the audio streams. I need other things? Please answer.
Dimmer
30th April 2004, 22:57
Check out the seamless branching using Scenarist (http://www.doom9.org/mpg/Seamless_Branching.htm) guide. In any case, you can only make non-seamless branching DVD with pauses at the branching points.
Unless you have access to a proprietary Panasonic or Toshiba authoring system (as Warner Brothers do, and I'm assuming you don't) there is only ONE way of authoring a true Seamless-Branching title - You need a MAC and just over $1k. I've been testing this program feature extensively for the last month and following a few programming tweaks, it will soon be released. Let me know if you need any further information on this.
The Scenarist workaround is an interesting method, but, as Dimmer correctly stated, does not yield a truly seamless result. While still in Daikin hands, I believe Scenarist was promised to be developed to include Seamless-Branching, but this seems to have fallen by the wayside (http://www.dmnforums.com/cgi-bin/readwholethread.cgi?forum=dvd_creation&post=020623115219.htm&toppostid=3371) following Sonic's acquisition of the program, much to the 'disappointment' (ahem!) of those who invested very substantial sums in Scenarist licenses :rolleyes:
Arky ;o)
dark.soft
2nd May 2004, 21:27
Yes thanks, if you can, tell me some more information. Bye.
Ok, since it seems you either have a MAC, or are prepared to acquire one (and it needn't be a powerful one for the purposes of using the program in question), the program you would require for authoring a Seamless-Branching title is TFDVDEdit 3 (http://tfdvdedit.com).
Many Doom9 members choose not to entertain this program because it is MAC-based. However, I believe this is a great pity because the power it offers is extraordinary. Anyway, I will not write an essay on it's wonders. I will simply point you in the right direction and let you draw your own conclusions. However, if you need any further assistance, you can ask either on the public forum on the dedicated website, or, by all means, ask me here, and I will do my utmost to assist you.
Regards,
Arky ;o)
Matthew
3rd May 2004, 03:02
Originally posted by Arky
Many Doom9 members choose not to entertain this program because it is MAC-based. However, I believe this is a great pity because the power it offers is extraordinary.
Indeed, from a commercial point of view, if a professional dvd authorer can afford Scenarist then the cost of a MAC + 1 grand for the additional functionality is very feasible. As I recall it's a post-processing type thing, right, so the guts of authoring wouldn't change. Just an added operation which involves copying across the VOBs from PC to Mac and then running TFDVDEdit.
Perhaps the lack of interest from many doom9 people is because they are only interested in backing up DVDs and as a result it just isn't feasible. If the lack of interest is actually from professional dvd authoring people, well that's a little short-sighted IMHO.
dark.soft
3rd May 2004, 12:32
Well, I haven't got a mac and I'm not going to buy one, but I am interested because if I find a good mac emulator (I don't know if there is one, I will search), it's a doable thing.
Sorry for my bad english.
MAC emulation would not be a good idea for use with TFDVDEdit. This program places a fundamental emphasis on I/O, and without bullet-proof emulation of this, the results could not be 100% certain. Emulation is not the magic answer it is often claimed to be.
You can pick up a second hand i-mac for very little money on eBay, which I would recommend as your best course of action if you wish to use 'Edit seriously. Don't forget, the alternative option for seamless-branching will set you back several hundred thousand dollars.
Makes a secondhand i-mac + TFDVDEdit look an absolute bargain, if you ask me... :rolleyes:
Arky ;o)
Originally posted by Matthew
Indeed, from a commercial point of view, if a professional dvd authorer can afford Scenarist then the cost of a MAC + 1 grand for the additional functionality is very feasible.
Absolutely, it's so feasible, it's a total no-brainer. Furthermore, the program will shortly add to it's feature list retrieval of DLT data to HDD for further re-authoring, and CSS implementation, and multiple simultaneous DLT writing (e.g. write both layers of a DVD-9 project to a drive each, at the same time) and a command interpreter, with variable speed walk-through! :eek:
Originally posted by Matthew
As I recall it's a post-processing type thing, right, so the guts of authoring wouldn't change. Just an added operation which involves copying across the VOBs from PC to Mac and then running TFDVDEdit.
Completely correct :)
As a longtime member of Doom9's forum, I have respectfully been deliberately reserved about posting about the program on the forum, but I believe events will soon overtake this, because, in the same way that Scenarist and Maestro have become synonymous with high-end DVD authoring, and are discussed multiple times a day, 'Edit may well prove to do the same. I guess it all depends if people can see the wisdom in spending a few hundred dollars on a MAC to gain tens of thousands of dollars worth of DVD authoring functionality. We shall see.
I will answer people's questions on the topic, should they arise, although these would probably be better directed towards the program's own support site, where there is a talented group of individuals, geared specifically towards it. Barely a day goes by there without someone devising yet another use for the program.
Arky ;o)
Trahald
5th May 2004, 15:21
A few months ago I buried my self in google.com looking for something for pc that can do seamless branching. I was even holding out hope there was maybe a linux option available. No joy.
DVD Lab pro is offering 'Movie Branching' when it comes out in may,june. but for the price $199 i fear its just referring to non-seamless multiple PGC (with shared vobids) capability.
Id like to be able to do it all on the PC platform. There is talk of a TFDvdEdit PC version for pc. Im not holding my breath. But it would be fantastic.
Originally posted by Trahald
A few months ago I buried my self in google.com looking for something for pc that can do seamless branching. I was even holding out hope there was maybe a linux option available. No joy.
The reason why there is no other S-B option available is that the number of software engineers in the world skilled and specialised enough to undertake such a programming task number probably less than a hundred, and more likely only in their tens. That is not to say that if a large software vendor put their commercial might behind a development team, this could not be achieved. It's just that no vendor appears willing or able to do so. Sonic appear to be largely uninterested in developing Scenarist, since their acquisition of the system from Daikin. S-B had apparently been promised as a future feature, but license holders have never seen this come to fruition. Other vendors do not sell systems for anything remotely approaching the license fee of Scenarist, and are thus less likely to invest hundreds of thousands of dollars in R+D for a program they only sell for a few hundred dollars. It's catch-22 for the end-user, unfortunately.
Add to this, the astounding complexity of interleaving streams for seamless playback and the dearth of options becomes doubly understandable. I have spoken at length with the programmer of TFDVDEdit's S-B feature, and the difficullties involved are simply staggering. The proprietary Toshiba system uses it's own MPEG encoder and multiplexer, and much of the groundwork is expressly laid by these, before the authoring system itself even gets near the video content. Any other, non-proprietary system, therefore, must be able to cope with the variations in output from numerous possible encoders, and numerous possible authoring systems/multiplexers. Thus, the goal posts are constantly moving, and believe me - there are huge variations in the output from different programs, even though they may still verify as DVD spec-compliant.
In trying to accurately 're-packetise' a VOB's contents into miniscule segements, for the purposes of interleaving, audio must obviously be kept adjacent to it's related video content. Given the above variations, and the fact that the DVD spec does not incorporate anything approximating to SMPTE timecode, you might get some inkling of what a gargantuan task it is to correctly assign all the VOB fragments to their required destinations in the interleave blocks while also keeping audio and video in synch!
Originally posted by Trahald
DVD Lab pro is offering 'Movie Branching' when it comes out in may,june. but for the price $199 i fear its just referring to non-seamless multiple PGC (with shared vobids) capability.
I have yet to absolutely confirm this, but I suspect that what MediaChance are referring to is actually duplication of VOB material, in order to make alternative PGCs playback 'seamlessly'. (
(incidentally, sorry for my delay in replying to your PM, Doom9 - things have been so hectic both prior to, and following, my return from NAB to the UK. I'll be in contact very soon).)
As you rightly state, conventional wisdom would simply use alternative PGCs to dictate varying logical playback routes across, and through, unchanged, and unduplicated VOB material. This works very well, except that the laser is forced to make huge leaps from one cell to another, where they are not adjacent, and this leads to a pause during playback, as the buffer empties and the laser realigns itself with the desired program cell.
Despite these caveats, I feel DVDlab is the most promising new contender for the Prosumer DVD authoring crown, given its opening up of much of the DVD spec to users (e.g. scripting). I wish the program well and I hope they can improve the verification reliability of the program's build folders. If they do, they'll have one hell of a hot product on their hands.
Originally posted by Trahald
Id like to be able to do it all on the PC platform. There is talk of a TFDvdEdit PC version for pc. Im not holding my breath. But it would be fantastic.
Although a PC port has not been completely ruled out, owing to the current intensity of development of the program, it is now looking unlikely, at least in the short term. You would not believe how many high end features are being programmed for it on a daily basis. As I said previously, however, the economics speak for themselves. How much would it cost you to do Seamless-Branching with any other system? If you work commercially, even on a very small scale, it's a total no-brainer.
Arky ;o)
SurfDrifter
10th May 2004, 00:32
Arky, i just want to ask your opinion.
I work professionally on DVD-Authoring, producing over 20 commercial titles per month. I was thinking seriously to say to my boss to move in a MAC environment, using DVD Studio Pro 2 (or 3 when it releases).
I know that the developing team of DVDMaestro is behind this application, so i guess it must be better than Maestro. I haven't seen a demo presentation yet, but i'll do it soon.
Now I read about TFDVDEdit that you mentioned. To put it simply, is this program an over-enhanced IfoEdit, in a way?
My final question is this. Regardless of platform, which program do you believe is the best for producing fast many titles, yet being powerful to make almost everything that DVD specs allow?
For me DVDMaestro is WAY faster that Scenarist.
Is it maybe DVD Studio Pro or another program?
Thanks
Hi SurfDrifter, good questions! :)
I've used both Maestro and DVD SP 2, and I must say I like them both. The deciding factor for me was license cost.
Maestro and DVD SP 2 are essentially the same program. DVD SP 2 is a ported version of the core Maestro codeset, to the MAC. It has a few nice features added (for example, Menu building automation and 'Drop Zones' make menu building extremely rapid, although these rely on Apple's Compressor encoding engine, which is under development at this time, but is currently producing out-of-spec MPEG encodes (e.g. excessive bitrate spikes), hence, I would advise not using this feature for the timebeing). If you currently have DVDMaestro, I would not expressly recommend that you swap to DVD SP 2, just for the sake of it. Firstly because they are essentially the same, secondly, because some functionality was removed when Maestro was ported to become DVD SP 2 (e.g. DTS audio multiplexing, which is being re-instated in DVD SP version 3), and thirdly, because the manner in which the program was ported (i.e. the programming language used to subsequently develop it on the MAC) has resulted in it being somewhat less responsive than Maestro (e.g. loading projects which contain many menus takes a very considerable time with DVD SP 2). It's a difficult question to answer. If you wish to use DVD SP instead, then by all means do so, but do be aware that it is not a simple case of 'upgrading' - it's more of a 'side-grade'.
Originally posted by SurfDrifter
Now I read about TFDVDEdit that you mentioned. To put it simply, is this program an over-enhanced IfoEdit, in a way?
Ouch! Much as I respect IFOedit, I hesitate to make direct comparisons, although people (yourself included) inevitably will. In so much as both programs offer the ability to undertake powerful manipulation of low-level DVD code, then yes, they are similar, but that really is where the similarity ends. TFDVDEdit is being developed at a truly frenetic pace, and offers dramatically more re-authoring power (see my discussion further down on just some of the forthcoming features, in Version 3).
Originally posted by SurfDrifter
My final question is this. Regardless of platform, which program do you believe is the best for producing fast many titles, yet being powerful to make almost everything that DVD specs allow?
As you know, there are caveats to all DVD authoring programs (yes, ALL! :D ).
Some of the fundamental disadvantages of both Maestro and DVD SP 2, in comparison to Scenarist, stem, paradoxically, from their advantage over Scenarist - namely, that they both use an abstraction layer. As you noted, this allows them to speed the authoring workflow dramatically. However, the abstraction layer in both systems has some funny habits:
#> Both of them write (by default) all Titles to a seperate VTS.
#> Both of them write lengthy (and inefficient) scripts to dummy PGCs in the VMG domain. This slows navigation considerably on complex projects, since the VMG domain is not always the most efficient route in a particular instance for navigating to a particular asset (I am not stating for even a moment that there is anything fundamentally wrong with dummy PGC scripts (in fact, they may be considered essential), BTW - it's simply the length and efficiency of their code, and the efficiency of their domain allocation which I am referring to)
Now, these habits can be worked around, if you know what you are doing:
In the First instance, Maestro did, in it's last couple of builds before the Apple takeover (I think this was 2912a, 2914c, and 2915a, but don't quote me on that), incorporate a new feature - 'Manual VTS Allocation', which overcame this failing, allowing Titles to be grouped together, if desired, into a common VTS, speeding navigation between the titles without needing to go to the head of the disk each time in order to achieve this. However, this function was removed when DVD SP 2 was coded! TFDVDEdit can manipulate domains and is thus a very nice partner to DVD SP 2, but is massively useful in combination with any system, even Scenarist.
In the Second instance, TFDVDEdit allows the saving of all commands (navigation) to a text file. It is then a simple task to strip out all the lengthy commands that the abstraction layer systems create (even DVD SP 1.5, actually, even though this is based on Astarte code and uses a different domain for it's dummy PGC scripts), and then you can re-author your navigation on an ultra-efficient spec-level, using leaner scripts and allocating these to the most appropriate domain in each instance. This isn't essential - it's entirely optional, but if you have a demanding client who insists on minimum navigation latency (quite rightly!), then you have the tools at your disposal to achieve this without spending tens of thousands on Scenarist. In other words, you get to maximise your efficiency in certain aspects of authoring with an abstraction layer system, but then have the option to put in a little more work, entirely at your own discretion, if you wish to bring the navigation up to the maximum speed which non-abstraction layer (e.g. 'spec-level') systems create as standard.
Buyers of Scenarist have not wasted their money, per se - Scenarist remains the most powerful standalone desktop authoring system. It's just that since the advent of this new supplementary program, which allows re-authoring 'after the fact', it has now become possible to achieve virtually everything that Scenarist can do, for a fraction of the cost.
Furthermore, 'Edit adds Mastering (with CSS and Macrovision, writing to multiple DLT devices simultaneously - halve the time necessary to master a DVD9 by writing each layer simultaneously to a seperate DLT drive! Additionally, you can retrieve projects from old DLT tapes to re-edit them!), Interleaving (true Seamless-Branching, promised to Scenarist license holders, but never brought to fruition), and troubleshooting (command interpreter - 'Tracer') capabilities which far exceed those of Scenarist.
Originally posted by SurfDrifter
I know that the developing team of DVDMaestro is behind this application, so i guess it must be better than Maestro".
That is an understandable conclusion, but not necessarily a 100% correct one. Apple did not retain all the Spruce Engineers, following their takeover of the company. They are now working on improving mastering support (e.g. DDP 2.1), and have already addressed the much-criticised DVD9 layer-break issues which haunted the program for so long. If you wish to demo DVD SP, then I strongly suggest you wait until Version 3 is released, because, as I said, mastering will be improved over Version 2, and DTS audio multiplexing will be reinstated (you may not feel the need for this, but if a client approaches you and asks you to do it, then you need to be able to say "yes").
Originally posted by SurfDrifter
For me DVDMaestro is WAY faster that Scenarist.
Well, this is the crunch. I have outlined to you that you can now achieve almost anything that Scenarist can do, for a fraction of the cost, and with varying degrees of authoring speed, according to your clients' requirements. The gulf that once existed between Scenarist and the rest of the authoring world simply no longer exists to any appreciable extent.
My best advice to you, in your particular circumstance, would be to:
definitely Give extremely serious consideration to buying a MAC (let's face it, if it's for work use, the cost is peanuts).
definitely Give extremely serious consideration to buying TFDVDEdit (believe me, I don't stand to gain so much as a penny if you do or don't, despite my involvement with the program as a serious enthusiast). Just check it out, and you'll soon know if it will serve your facility well or not.
definitely Get a demo of DVD SP, but wait for the release of Version 3 before doing so. Since it is a rediculously cheap license, you may wish to buy it and use it in tandem with Maestro for certain jobs. It's up to you. - I would not suggest abandoning Maestro just yet, though. It's still a great program and has plenty of life left in it yet, esp. if you use firewire drives (as I do) to transfer data from PC to MAC, to use TFDVDEdit for the purposes of adding functionality. Personally, I use my PC to prepare assets and encode them, then use firewire drives to transfer to MAC and author with DVD SP 2 (soon will be 3), then reauthor my VIDEO_TS build folders with TFDVDEdit, adding speed to my navigation and seamlessly-interleaving certain aspects of my project if required. 'Edit also allows me to (very powerfully) check my entire command set for errors / spec-compliance. It is also possible, using that 'save-to-text-file' function I mentioned, for you to email that text file to someone, and have them edit your command set (provided they also have the program), before emailing it back to you and letting you paste that command set into your existing build files, then saving and mastering to DLT! This could get you out of a seriously tight spot, on occasion.
If you have any more questions, I'll happily field them.
Regards,
Arky ;o)
SurfDrifter
11th May 2004, 00:57
Hey, that was a fantastic answer. Very informative! I wish we could talk generally about it, for pages! Anyway, it's very late here in Greece and i'm very tired to write a full answer (with many more questions?) and comments, but I had a question in mind today, after reading the seamless-branching technique using Playlists/Stories.
It's actually pretty easy, but i was wondering if the stories have to be straightforward. What I mean is this:
About a year or so a dvd called "Irreversible" was released.
I hope you know the story and the peculiarity of this movie; it plays backward. So it has 12 chapters (or sth) that you could easily watch them in reverse, so as to see it "regulary". So, for educational purposes, i created the movie in maestro and then created a playlist playing the chapters with this order. 12,11,10,9,8,7,6,5,4,3,2 and finally 1.
Of course this wasn't seamless, but i was wondering if this can be multiplexed seamlessly.
Also are there any limitations on the lenght or distance between the portions of the movie (using the TFDDVEDIT method) that assets might have?
Thanks and i'll be back soon.
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! :D
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...
Continued from above
(Incidentally, the reason this filler is so harmless, is that the nature of true Seamless-Branching interleaving is that each PGC is constructed so as to be ‘insular’ from it’s peers. This is in stark contrast to Multi-Angle interleave variants, which freely support navigation from one interleave block to another, during playback*. Having removed the PGC (‘PGC 2’) which related to the filler material, you may rest assured that no-one will be able to inadvertently (or even deliberately) access that material).
*MultiAngle and S-B interleave types both allow authoring of navigation between streams, using Button Over Video (with Forced Action, if you wish, for GPRM-conditional stream switching) and Cell commands. However, in the case of S-B interleaving, since the interleave architecture does not cater for direct referencing of adjacent interleaved blocks (they are interpreted by the player as essentially 'insular' - each PGC being followed though to it's conclusion, unless 'brute force', in the shape of B.O.V. or Cell comands is used, with an accompanying 'non-seamless' penalty), any attempts to switch between streams (interleave blocks) will require re-initialisation of the player's decoder, thus making the switch non-seamless.
Critically, however, Multi-Angle is not subject to this restriction, since it is specifically optimised for stream switching. Adjacent angle blocks are tightly controlled, so as to have identical GOP structure, and tables are provided at the head of each sector, describing the location of each 'adjacent' angle block relative to the playback position (negating the need for decoder reinitialisation when a switch is requested). This tighter control over assets, and increased level of content description, confers more rapid switching between interleave blocks and also (obviously) allows the use of the Angle key on the remote. Both types have their applications, and, in fact, M-A can be subdivided into 'Seamless' and 'Non-Seamless' types, but I won't get into that here!
Hence, in the situation I described above, relating to S-B interleave blocks, if you omit any B.O.V. or cell commands from your project that relate to stream switching, then the viewer will have no means at their disposal with which to 'switch' to the 'filler' interleave block - the angle key will go unheeded - the filler material is therefore rendered inaccessible and 'safe'. (Tx TF)
In conclusion, Seamless-Branching isn’t the perfect answer in your particular (and highly unorthodox!) situation, but it is an absolutely extraordinary authoring feature with numerous high-end applications, many of which have not even been devised yet, since the feature has, until now, only been in the hands of the privileged few. If you are serious about S-B authoring, then please check out my forthcoming tutorial (I’ll post a link here when it’s up, in a week or so). I hope it will whet your appetite (again, don’t forget that, manual VOB editing is also a definite future feature). Further than that, I hope you will join in the fun somewhere down the line, even if it is only, perhaps, via work. You appear to be pretty creatively-minded, and that’s what this is all about!
Regards,
Arky ;o)
P.S. You asked “Are There any limitations on the length or distance between the portions of the movie (using the TFDVDEdit method) that assets might have?”
Can you be a little more specific about what you mean, please? What I mean is that I am uncertain of the context in which you refer to ‘distance’. Could you give me a quick example, perhaps?
As I have outlined in this post, TFDVDEdit reallocates data from any ‘distance’ necessary in a physical VOB, according to least-action principals that yield the best compromise for all the PGCs included in the interleave procedure. In fact, as you will see in my forthcoming tutorial, I actually recommend, under certain circumstances, the creation of a VOB that is decidedly non-linear in nature, in the full knowledge that temporarily multiplexing certain program elements at the far reaches of a VOB, even though they may eventually be required in the middle of the final (interleaved) VOB, is of no consequence to the final result. Unlike Multi-Angle forms of interleaving, S-B interleaving places relatively few truly prohibitive conditions on the creative process, and provided you understand the few limitations and their workarounds, you’ll see how flexible it can be. For example, as you are doubtless aware, there are minimum and maximum jump distances that the laser is permitted to make, according to the DVD spec and these consequently place an emphasis on asset duration ratios, as discussed earlier on. The most appropriate jump distance in any given circumstance is the subject of complex calculations, based upon (amongst other variables) the number of alternative scenes being interleaved, and each of their bitrates. Where extremes of these ranges coincide, other strategies can be brought into play, such as MPEG filler, for example, or, in the worst case scenario, a little judicious duplication.
If you need any clarification on any of this, then I am happy to help in any way I can., although please do bear in mind that I am as busy as you are! :D
influenza
17th May 2004, 16:03
Wow Arky you've outdone yourself. i know your known for your very informative and extensive answering, but this is a real huge post. Thanks for all this usefull info :)
SurfDrifter
18th May 2004, 11:07
I just printed out the whole topic, so as to read it easily in my office...
The bad thing is that I have more questions to ask... :)
Originally posted by SurfDrifter
I just printed out the whole topic, so as to read it easily in my office...
The bad thing is that I have more questions to ask... :)
...and why would that be a bad thing? :)
(and you're welcome, Influenza. Glad somebody found it interesting! lol :D )
Arky ;o)
influenza
18th May 2004, 19:12
and why would that be a bad thing?
Because your answers significantly enlarge the doom9 forum database ;)
I'm glad to hear your 'adventure' in The States was a succes :)
SurfDrifter
24th May 2004, 19:08
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.
OK, i understood what happens now with seamless branching and to clear things out, when I was asking about "distance", i was referring on how long can the laser jump without emptying the buffers.
Back to my question. The 10% is ALWAYS used from the omitted chapter/chapters? This means that even if there's a chapter with duration 1 sec, will use as a "stepping stone" a 3-frame sequence?
Will this be seen on my television screen? In your example, let's say that chap.7 was 2 minutes long, that means that i will have to see 12 seconds of the omitted chapter? I guess not, but i didn't understand how the "stepping stone" works.
You appear to be pretty creatively-minded, and that’s what this is all about!
I'll give you 2 ideas that i have compiled in my spare time, just for fun.
1) Create multi-angle DVD menu.
I had a subtitle menu that had two options. Subtitles ON and subtitles OFF.
The actual selections were on a sign just like the neon signs on motels. The word "Subtitles" was lit always and the one angle was with "ON" selection lit and the other angle was with "OFF" lit. So every time the user pressed the button "ON" or "OFF" the angle was changin, so as to have the menu "Seamless" without stopping the audio track running. Of course this was a "button-over-video" thing.
2) Stop users from removing P-UOP's!
Doom9's members will hate me!
Let's say you have a series of FBI warnings, logos,etc. that suck big time, but you want to MAKE SURE (...what a sadist!) that your audience will see it.
Place them all at one separate VTS set and start linking them, from the first to the last. Of course you'll have activated all P-UOP's. Now, the last track you want your audience to see, link it to a dummy PGC on VMG, so as to lead it wherever you want.
Now, here's the fun part! Create a Root Menu at the VTS you have all the logos that leads to a dead-end, probably to phrase saying:"P-UOP's removal not allowed!". Do the same on the Title Menu on VMG and prohibit title menu call on all VTS's and of course Root Menu call(and everything else) on the VTS with the logos.
This means that if the P-UOP's are activated, everyting will work fine, but if someone removes them and presses Root Menu on his remote to skip them, it will lead him to dead-end!
Of course, Root Menu calls can be made on other VTS's, but no Title Menu call(since it will lead to dead-end). I'm sure it can be done (to have title menu calls that work correctly from other VTS, besides the one with the logos), if authored with proper GPRM arguments, but i was bored to go that deep.
Even imaging a phrase saying that "Illegal attempt to copy DVD. DVD playback halted!". :) It's going to be fun...
Now, you're free to hate me!
Apologies for the delay in getting back to this, Surfdrifter. I've been away from home for the last 6 days and am now back to writing my articles, so between both of these factors, I've not had much time for the forum.
Originally posted by SurfDrifter
OK, i understood what happens now with seamless branching and to clear things out, when I was asking about "distance", i was referring on how long can the laser jump without emptying the buffers.
Well, with respect, from a practical standpoint, this is a bit of a moot point. The DVD spec does, of course, stipulate both a minimum and maximum jump distance, so that the consumption rate of the Decoder (Vo) remains satisfied. However, within this range there is room to maneouvre, subject to the number of streams comprising the interleaved section, and their respective bitrates, for example. Therefore, although the DVD spec parameters must, of course, be satisfied, when calculating appropriate jump distances, these jump distances will vary considerably depending on the scenario at hand (also note that spec parameters aside, in practice, other variables will affect how well a player copes with interleaved material, such as seek time and data transfer rate of the drive itself, and how much buffer memory the designer saw fit to include.) In short, yes, there are maximum and minimum limits on jump distance, but real world situations dictate different distances according to specific context. I am writing a technical article on this at the moment, so it is pointless going into extreme detail here and now. (this article should satiate those of you with a thirst for the low-level stuff, although this is not necessary in order to put TFDVDEdit's Seamless-Branching interleaving capabilities to practical use).
Originally posted by SurfDrifter
Back to my question. The 10% is ALWAYS used from the omitted chapter/chapters? This means that even if there's a chapter with duration 1 sec, will use as a "stepping stone" a 3-frame sequence?
Will this be seen on my television screen? In your example, let's say that chap.7 was 2 minutes long, that means that i will have to see 12 seconds of the omitted chapter? I guess not, but i didn't understand how the "stepping stone" works.
Ahh, no, sorry - I was covering so much ground previously that I was not explicit enough on this point. The 10% is actually drawn from outside of the boundaries of the scene removal - in other words (using my previous example for the sake of descriptive consistency), approximately half the 'stepping stone' material could be drawn from the end of Chapter 6, and half of it from the beginning of chapter 8. This would mean that these small 'encroached-upon' portions would be duplicated, and therefore that the Seamless-Branching points would be moved sideways accordingly, so as to encompass them (i.e. moved sideways such that the branching began at the end of the preceeding common material / at the beginning of the duplicated material, and ended at the end of the duplicated material / the beginning of the subsequent common material. Obviously, we would not want these new cell boundaries to be directly accessible using the 'Next' or 'Previous' chapter keys, so we would author the cells so that they did not constitute new PTTs in their own right - a very easy task to accomplish using TFDVDEdit's PGC map).
Now although all of this could be manually achieved by taking it into account during the NLE process, and during the subsequent DVD authoring process, it is another element to contend with which it would be nice not to have to. In a(nother) stroke of sheer genius, John Brisbin has automated even this task, such that the DVD author need never even bother to take it into consideration! Consequently, one need only author as normal - all cell boundary manipulation, for the purposes of encompassing adequate 'stepping stone' interleavable material from the existing surrounding material, is taken care of behind the scenes. In fact, in an effort to improve efficiency even further, this automated routine does not draw material from both sides of the removed scene gap. Instead, it simply creates only one new cell boundary, so as to encompass material preceding the scene removal. This new cell boundary is of course created in the way I described, so as to avoid constituting a new PTT in it's own right. You just have to see this operate to see how unbelievably cool it is! :)
And just to reassure you, the results of all of this is a perfect Seamless-Branching title, absolutely indistinguishable during playback from the output of the Panasonic or Toshiba systems. Incredible, but true.
Creative Suggestions:
1) Multi-Angle DVD menus are a nice idea, and are technically possible in theory. They can be authored, that is not in question. Certainly, it is possible to build Titles and move them out of their compiled VTS domain to another (VTSM or VMG, for example). As has been noted by certain (creatively-minded!) individuals (Dimmer and yourself, being 2 such examples on the Doom9 board), there is a theoretical workaround for achieving consistent audio where full colour embedded graphics / video need to change appearance from one state to another. Furthermore, the use of forced-action buttons is entirely legitimate for angle-switching. However, the question is one of player-compatibility. There has been discussion on this topic on Tully's DVD List in the past. I do not recall the exact post, but I believe someone mentioned that player compatibility might be reduced (presumably on the basis of first-hand experience, but I can't be certain until I dig it out again). I will go back and find this post and include the relevant details extremely soon (am not on my home PC at the moment and can't remember my auto-completed password!). This is not to say that I have given up on the idea at all. It's definitely something worthy of investigation. It's just that we are talking about such rare and creative techniques here, that many DVD player designers do not take them into account, even though they theoretically fall within legitimate DVD spec parameters. Note that we will also be testing seamless interleaving in the menu domains, but this is not the same challenge to a player as multiangle is. Both are interleaved, of course, but it is the notion of 'angle-changing' that may (or may not - I hope it doesn't!) confuse a certain proportion of players out there. Time will tell.
2) You're a sick man! :D lol.
In principle, I guess you could do what you suggest, but I think you would be lynched for it afterwards - We'd start seeing the emergence of 'De-SurfDrifter' routines in IFOedit and DVD Shrink, to put people out of their collective misery! BTW, were you aware that TFDVDEdit can adjust UOPs on a NavPack by NavPack level? It's an insane level of control (although, unlike your example, these could theoretically be removed by anyone with ripping software. My perspective on DVD, though, has always been one of creativity, rather than ripping, so this does not really concern me). Prohibiting and allowing UOPs on this microscopically incremental basis means that, for example, you can disable angle switching only at certain periods during playback of the angle block. The creative possibilities are just huge.
If you have any further questions, or you feel I have not satisfied your existing ones, then please let me know.
Kind regards,
Arky ;o)
SurfDrifter
28th May 2004, 14:22
You're a sick man! lol
Maybe, but imagine the potential! (:D )
You could place REALLY HIDDEN extras there, that only fans of DVD's can discover, or maybe a simple hidden video, to serve as a watermark, since you'll be the only one to know that it exists.
Think about this idea.
In your extras menu, you place a button saying "Experts Section"
If the user selects it, it will lead him to a numerical pad, asking him to enter a 4-digit code. I bet you know how to make this thing work, so i won't explain how it would work.
The great fun would be, if you were saying that the code is hidden in a title or menu, that contains 1000 still images and ONE of them is the genuine code (with a riddle or sth). Everybody will start, ripping, demuxing the DVD, just to find the code. Well, at least for few days, because later the code will be posted in an easter-egg web site!
Or something similar, would be nice. The fun is to find interactive ways to make the end user have fun.
BTW, how you move a multiangle track from its compiled title to a Language Folder, so as to work as a menu?
BTW, were you aware that TFDVDEdit can adjust UOPs on a NavPack by NavPack level? It's an insane level of control (although, unlike your example, these could theoretically be removed by anyone with ripping software. My perspective on DVD, though, has always been one of creativity, rather than ripping, so this does not really concern me). Prohibiting and allowing UOPs on this microscopically incremental basis means that, for example, you can disable angle switching only at certain periods during playback of the angle block. The creative possibilities are just huge.
Now, on another subject...Yes, the creative possibilities are huge, but the creative possibilities of our customers are sth like...non-existent.
To put it simply, here in Greece the DVD is Stone Age. The "advanced"
customers ask for a "play all" when dealing with anime, but nothing more. Many come and say:"Just make it automatically play...Menus? What are these? Do you serve food here? Damn it man! I asked for a DVD, not a menu!"
Oh, and a little remark on the ...My perspective on DVD, though, has always been one of creativity, rather than ripping, so this does not really concern me.
I don't see any creativity, FORCING someone to see all the FBI logos, trailers, without being able to FF.
At least on VHS, you could FF this things. Besides, ONLY by existing in the DVD, serve their purpose. It's a legit thing to have an FBI warning. If the customer want to skip it, its his problem. If he copies it, he can't say to the court:"I FF the warning, so i didn't read it".
I ALWAYS leave my warnings and initial videos "unlocked", so as if the user presses Root or Title, to move directly to Main Menu.
And also don't forget that nowadays, people buy more and more movies due to collectability of the medium.
So, I don't to buy a "Widescreen Ultra Platinum Extended Superbit DVD Collector's Edition" and have several UNSKIPABLE trailers, logos, FBI warnings and EVERYTIME i insert the DVD, I'd have to watch them all from the beginning. Even when i put a movie late at night and fall asleep, the next time, i'll have to watch them all over again.
So, sometimes removing P-UOPS, it's very wise thing to do.
I bought "remote selector v.2.13", so as to remove P-UOPS "on-the-fly". It supports also Creative's DXR3, so it's even greater!
I, of course, agree with the creative part of your thought, but i can never accept, the fact that narrow-minded customers, want to abuse the power of DVD.
To tell you the truth, i might be "on the other side" now, but i started my adventure with DVD's with doom9.org! This site is responsible for my business career, so this means that some time ago, i was in the ripping scene...
DaRat
31st May 2004, 21:42
Hey! Nice topic, I have a few q's and comments if you guys don't mind. First Arky, why would your solution for a backward order pgc do it seamlessly. I just don't get it. Maybe because I'm a bit tired or my english is not good enough for this one. :D I was under the impression that the navigation stuff in the DSI packett can only point forward for the next chunk of data, so without duplicating the cells it still seems impossible for me. Or I missed something?
For the multi-angle menus I found the track buffer being the biggest problem. It plays whatever it has in it and then pick up the new angle data, so it results in a really poor response time (around 1 secs at least in my experience). It would be fun to make instant changes but for this you'd have to clear the buffer which can be accomplished only by doing a non-seamless stuff which would make this all pointless. Too bad. :(
On the creative part: also see the thread about menus w/animated subpics, it seems it _may be_ possible to do it but still did not had the time to make a test dvd and see how it works on standalones. If it could be accomplished it would mean a whole new way to make menus, just imagine... :D
Unortuantely there's no way to prevent clever people hacking your dvd apart, digging out the necesary info. With your copy protection all they have to do is set a single pre-command in the title/root menu linking to the real menu and remove protection stuff there. This goes for the code but it's possible to cause headache with this one if you put it in a video simply interleaved into the middle of the main movie. It would cost a good fortune to pick the correct nav pack to get the code not to mention the possibility to put in ALOT (and i mean ALOT, they won't take too much space) separate dummy pgc's there with unused menus and codes in them. :D
(edit: reminds, you could do this truly random, like multiplying a RND value by a counter's value which counts 'till the user press next, this would involve a shitload of work but it's pretty unpredictable except it's still possible to extract the content itself.)
Another creative thing is text screens with animated background. You can cut the space needed into 1/15. That's 15 pages of text for one motion menu which won't be too big since it should not contain any bright/colorful/fastmoving/etc object else the text would be hard to read. This is possible with acceptable response time (about 15 frames or 15/25th of a second <- pal land), I did a test for this also, it looks pretty cool, continuous video and audio for the text. :D The idea behind this is the same as it is behind the multi-angle: a subpics stream change won't make the action non-semaless.
Even another would be a truly seamless transition from one motiomn menu to other one. The idea behind this is to make a intro for the menu then loop about 12 frames forever (well, about 900 times, that roughly equals seven mins of menu :D) using Violao's seamless menu looping guide then, after user interaction link to a outro but this seems pretty hard to do (if not impossible) since it involves either a jump (forward but it's still a jump) or a check at the end of the loop which would obviously make it non-semaless. Tough it's not clear what would happen if a player sees a command but get a seamless flag before that. This would be cool also. :D
Anyhow you're right Arky. It seems most ppl are into this only because the backup thing. It's sad to see how few ppl post here (adv dvd auth) nowdays.
Originally posted by DaRat
...Arky, why would your solution for a backward order pgc do it seamlessly. I just don't get it. Maybe because I'm a bit tired or my english is not good enough for this one. I was under the impression that the navigation stuff in the DSI packet can only point forward for the next chunk of data, so without duplicating the cells it still seems impossible for me. Or I missed something?
Ordinarily, a reverse-ordered PGC would of course result in non-seamless playback - that was why I was at pains to carefully describe a solution which would 'fool' the seamless-interleaving routines in TFDVDEdit into physically reordering the VOB so that it physically matches the desired order of cell playback, according to the PGC. Because the cell has been physically reordered, the playback is now truly seamless, and there is no significant duplication (save for the 10% caveat I described in detail) because, in the example I gave, the original forward-ordered PGC is no longer required.
Originally posted by DaRat
For the multi-angle menus I found the track buffer being the biggest problem. It plays whatever it has in it and then pick up the new angle data, so it results in a really poor response time (around 1 secs at least in my experience). It would be fun to make instant changes but for this you'd have to clear the buffer which can be accomplished only by doing a non-seamless stuff which would make this all pointless. Too bad.
Well, it's not perfect, but you can improve the angle-switching response time by shortening your GOP structure when you're choosing your MPEG encoding settings. Obviously, the manner in which the interleaved jump distances have been calculated is an important factor here, too, and some programs are better than others at calculating these (the Mixed Angle and Multi-Angle interleaving routines of Maestro and DVD SP are, arguably, not quite as well-implemented as those in Scenarist, for example (recall that I said there is a range of possible values in any given instance, not just one possible absolute value. Therefore, there is room for 'strategy' on the part of the programmer, hence differences in the end results, depending on who programmed the interleaving routines, even though each of the strategies may 'work' and be perfectly spec-compliant).
Originally posted by DaRat
On the creative part: also see the thread about menus w/animated subpics, it seems it _may be_ possible to do it but still did not had the time to make a test dvd and see how it works on standalones. If it could be accomplished it would mean a whole new way to make menus, just imagine...
Yes, it CAN be done. I personally witnessed Prof. Uli Plank do this at the TFDVDEdit stand at NAB. The procedure is actually quite logical, but I'm afraid I can't describe it here because it is part of the members section of the 'Edit website.
Originally posted by DaRat
Unfortunately there's no way to prevent clever people hacking your dvd apart
Yes, I quite agree. As I said before, though, my interests lie in the realm of creating new projects, rather than disassembling them (I get the impression you may have interpreted that previous remark as a 'dig' at you, or the wider ripping community, SurfDrifter, but that's not how I meant it. I simply meant that just because someone can disassemble something does not mean it is not legitimate to create it in the first place, and there are some great creative reasons for prohibiting UOPs. It's just that P-UOPs always get a bad rep because of Hollywood studios' unfortunate penchant for using them to force viewers into watching FBI warnings etc.).
Originally posted by DaRat
Another creative thing is text screens with animated background. You can cut the space needed into 1/15. That's 15 pages of text for one motion menu which won't be too big since it should not contain any bright/colorful/fastmoving/etc object else the text would be hard to read. This is possible with acceptable response time (about 15 frames or 15/25th of a second <- pal land), I did a test for this also, it looks pretty cool, continuous video and audio for the text. The idea behind this is the same as it is behind the multi-angle: a subpics stream change won't make the action non-seamless.
Yeah, that's a nice one. See here (http://www.tfdvdedit.com/public/83.cfm) for a discussion on several ideas.
Originally posted by DaRat
Even another would be a truly seamless transition from one motion menu to other one. The idea behind this is to make a intro for the menu then loop about 12 frames forever (well, about 900 times, that roughly equals seven mins of menu ) using Violao's seamless menu looping guide then, after user interaction link to a outro but this seems pretty hard to do (if not impossible) since it involves either a jump (forward but it's still a jump) or a check at the end of the loop which would obviously make it non-seamless. Tough it's not clear what would happen if a player sees a command but get a seamless flag before that. This would be cool also.
Well, I don't see how you could jump from any (i.e. a random) point during playback of a motion asset and have the jump be seamless, regardless of whether you use interleaving or not. Unless I have misunderstood you, I think you are right - this doesn't seem possible.
Originally posted by DaRat
Anyhow you're right Arky. It seems most ppl are into this only because the backup thing. It's sad to see how few ppl post here (adv dvd auth) nowdays.
Well, I have learned a lot in DVD from Flexion and Doom9, for which I will always be thankful, and I hope I have given something back to fellow members, too, over the years. However, there does seem, perhaps, to be an even greater emphasis on ripping these days than there used to be. Don't misunderstand me - Fair Use is ok in my book, it's just a pity that there doesn't appear to be a larger proportion of people creatively authoring original material as well. However, it is the desire for creativity which led to this thread being started in the first place, so perhaps things aren't so bad...
John ;o)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.