Rivergate Software Inc. - makers of DVDAfterEdit

Posted Oct 25,2004 4:39 PM Harold

so i must confess that this is actually a few questions in one. i must also confess that having only had tfdvdedit in my hands for a few days some of my questions may be foolish and i may occasionally butcher some spec level terminology, but i have attempted the usual rtfm techniques prior to posting. i have also attempted to be forthright about the limits of my understanding.

so to begin with, i attempted to interleave two PGCs and got the following error:

"The selected PGCs contain 1054 NavPacks which exceed the maximum encoding rate for interleaved blocks allowed under the DVD Spec. See the log for details.

"However it may be possible to keep the average Vo within the specification limits during multiplexing. If not, the operation will fail at the end and your original configuration will be preserved.

"Ideally, you would re-encode the segments which exceed 8.0 Mbps and then interleave the PGCs."

so to begin with, what are NavPacks? are they the same as (or perhaps more accurately in view of having been multiplexed, analogous to) GOPs?

next, does this mean that my (vbr) encode has peaks over 8mbps? are the data rates that can be used in seamless branching restricted?

what is the "average Vo"? it sounds like it has something to do with the data rate, but exactly what is unclear to me.

on to bigger questions....

how sophisticated is tfdvdedit's interleaving algorithm? trai's article on seamless branching describes a fairly simple scenario in which three fairly similar (plus a cell or two her, minus a cell or two there) PGCs were interleaved and the process is in that case fairly straightforward, but what about more complicated scenarios? consider:

- two PGCs, one is ninety minutes long the other is ten minutes long. the former consists of every cell in the VTS, the latter consists of only the first and last cell.

- two PGCs both ninety minutes long, both consisting of the same cells, but one having the cells in the reverse order--viz., PGC 1 is [ A B C D E F G H I J ] and PGC 2 is [ J I H G F E D C B A ]? how does this scenario differ, if at all, if you are working with 100 cells in lieu of 10?

- what about greater numbers of PGCs in even more convoluted arrangements?

that should cover my questions for the moment. i should also note that i received that error while attempting to experiment with a scenario similar to the second one i described above. i was doing this for fun, fully aware that it might be a thoroughly ill-conceived and wrong-headed thing to do, but wanting to see what sorts of cool stuff seamless branching could do. so was my video just out of spec? should this have worked with a cbr encode? or am i barking mad for even thinking such thoughts?

cheers,
h

---

Posted Oct 25,2004 9:34 PM Arky

Questions, questions!! (all good ones, I might add!).

Hi Harold, welcome to our community. You have made the effort to read the manual so you most certainly need not apologise for asking questions. We're all here to learn (and we all make mistakes from time to time!), myself included. If I may, I'll break the essence of your post up into segments, and address your questions incrementally...

"so to begin with, what are NavPacks? are they the same as (or perhaps more accurately in view of having been multiplexed, analogous to) GOPs?"

Very close! Navpacks provide essential information to a DVD player about how to appropriately play content. In the multiplexed MPEG material on a DVD (i.e. a VOB), there is a NAVpack at the GOP-header I-frames (which is why you will not find many NAVpacks in a still menu!).

"next, does this mean that my (vbr) encode has peaks over 8mbps? are the data rates that can be used in seamless branching restricted?"

Correct. I would recommend, as a general rule of thumb, that you avoid peaks over 7.5mbps. There are a number of reasons for this. As Trai discovered, quite some time ago, DVDR does not cope with high bitrates very well, owing to its poor index of reflectivity - in other words, players struggle to retrieve large amounts of data from low reflectivity discs. If you are authoring for replication, then this, in itself, is not such an issue.

However, the DVD spec does still place fundamental restrictions on bitrate, and particularly stringently where interleaving is concerned. Both Multi-Angle and 'Seamless-Branching' content is interleaved, albeit using subtly different strategies. They do not share identical restrictions, though. S-B (more correctly known as 'Partial-Interleaved' / Seamless-MultiStory) streams have less strict limitations placed upon them than those destined for Multi-Angle projects. Whereas with M-A projects (irrespective of whether they are Seamless M-A or Non-Seamless M-A), the bitrate restrictions alter significantly according to the number of constituent streams (Angles) in the Angle Block, S-B streams need generally only be kept under 8mbps, irrespective of how many constituent streams (e.g. alternative scenes) there are in the Partial Interleave Block. Note that these restrictions refer to the sum bitrate of all audio streams + all subtitle streams + ONE video stream.

So, with a hypothetical S-B project, with a Partial-Interleave Block containing three alternative scenes/stories, and four 192kbps .ac3 audio streams, for example, you would calculate the max bitrate for your video encoding as follows:

192 x 4 = 768kbps total audio bitrate

Subs = (none, in this example)

8000kbps = max theoretical video bitrate for a Partial Interleave Block.

Therefore, 8000 - 768 = 7232kbps max bitrate for EACH video stream
within this particular Partial Interleave Block. Remember that, with Partial-Interleave blocks, the max bitrate restriction does NOT become more severe if you add more video streams to the interleave block, only if you add more audio / subtitles, as per the above calculation.

Coming back to the DVDR issue for a moment, there is an additional complication. Because interleaved content makes heavy use of a player's buffer and data searching capabilities, it places additional burden on the system as a whole, to be able to rapidly and reliably locate the next IOBU for the PGC ('story') being played at the time, while skipping over those IOBUs that relate to other versions of the story that have not currently been selected for playback. The upshot of this is that, again, where low disc reflectivity challenges a player's ability to retrieve adequate data without buffer underrun (and thus a pause in playback) occurring, then any additional burden, as would be the case with interleaved blocks, may be potentially magnify the problem - it takes a little time for a player to locate the next IOBU, even when the Data Search Information (DSI), in each IOBU NAVpack, tells the player the relevant sector address. We are only talking milliseconds, here, but everything counts when the buffer is so small, and when a player is already struggling to retrieve data from a low-reflectivity disc.

Irrespective of whether you are authoring for DVDR, or for replication, the same spec-defined bitrate rules must be followed, in order to ensure wide compatibility, but I would additionally recommend very strongly that,if authoring for DVDR, you take the above considerations seriously.

Lastly, on this topic, I would also strongly urge you to consider using CBR, particularly if you use Compressor (which currently produces outrageous spikes in VBR mode). VBR is legitimate for all interleave work, be it Partial Interleave (S-B) or conventional Multi-Angle work (be it Seamless or Non-Seamless). However, it is well known, in professional circles, that VBR can cause difficulties in real life authoring situations, when authoring interleaved content. This is due to a number of factors. One is that VBR makes the already-challenging task of calculating spec-compliant ILVU sizes that much harder, for an authoring system (in our case, with Partial Interleaving, that would, of course, be with TFDVDEdit, POST-build, but the point still stands).

Partial Interleaving is much more tolerant of discrepancies between constituent streams, and John's code is very robust, but, as authors, we still want to make our lives as stress-free as possible, so anything which improves our chances of avoiding errors (or, in the case of TFDVDEdit's stringent error-checking routines, error ~messages~) is surely a good thing. The archives on The DVD List are strewn with the carnage of professional authors, using professional tools, yet hitting the problem of failed (interleaved) multiplexes when using VBR assets. It is interesting, but perhaps not surprising, that I have never seen such a post, relating to anyone authoring with a proprietary Panasonic or Toshiba system. I attribute this to the fact that they have excellent support available to them, and to the fact that these systems are in the minority, in the authoring community. Much more than that, though, both these systems (which, other than TFDVDEdit, are the only ones in the world capable of true Partial-Interleaving) are tied to proprietary MPEG encoders, which are an INTEGRAL part of the authoring workflow. These encoders are actually setup differently according to the interleaving requirements of projects. This is an outrageous luxury which TFDVDEdit can only dream of, accepting, as it does, the output from every encoding and multiplexing system under the sun.

So here we have a situation where several things are known:

~Many encoders, be they hardware or software-based, do not adhere tightly to VBR peak settings.

~There is a history, in the professional authoring community, of failed multiplexes, even with professional authoring systems, where VBR assets have been used for Interleaved projects. There is thus a shared wisdom that CBR, while not critical, is a wise choice for interleaved projects.

~Although VBR is theoretically legitimate, within the confines of the DVD spec, for Interleaved projects, it may also be argued that this places additional demands upon an already-challenging procedure.

~There is little reported failure with Partial-Interleaving, in the professional community, BUT there are many reasons why this may be the case, some outlined above, none of which actually distance the procedure of Partial Interleaving from the same potential pitfalls as experienced with conventional Multi-Angle interleaving.

~TFDVDEdit, by it's very nature, has to cope with the output from innumerable authoring systems, and innumerable encoders. The number of possible combinations of software and hardware that contribute to the VIDEO_TS folders the program is expected to deal with, is simply staggering. TFDVDEdit has no control over what people throw at it, it is simply expected to accept it all and come out smiling. I can think of no single element of DVD creation that more exactingly challenges a piece of code than to perform a Partial-Interleave upon a multiplexed file which may have any number of variations in it, as a function of unknown encoding source, and unknown multiplexing source.

None of this is worrying to me, as a user of TFDVDEdit's interleaving capabilities - I know I am protected by rigourous error checking routines, for spec-compliance, but although it isn't worrying to me, it all adds up to a logical conclusion - to maximise my authoring efficiency, and not be faced with re-encoding footage because of spec-violating bitrate peaks, I can choose to use CBR. If faced with a long-form project that really would benefit greatly from VBR encoding, I can choose to:

~use an encoder which adheres sensibly to my chosen peak bitrate

~use conservative settings for peak bitrate

~avoid settings which result in large swings between minimum and maximum bitrate (and narrower bitrate swings are actually surprisingly common in Hollywood DVDs, anyway - it is not always beneficial to opt for low minimum settings that yield large bitrate swings). Huge bitrate swings do not provide favourable conditions for interleaving.

During tests, in the run up to NAB, I used settings approximating to the following:

min=4.5
avg=5.3
max=6.2

You may do as you please, with regard to encoding for S-B projects, but you have an informed choice! Incidentally, there is some discussion on the testing, and what we discovered, about encoders, here:

http://www.tfdvdedit.com/members/forum/openthread.cfm?forum=1&ThreadID=2...

Also please note that, as the post in that link says, concatenated segmental encodes are highly preferable for Partial Interleaving purposes, and this should not be underestimated.

"what is the "average Vo"? it sounds like it has something to do with the data rate..."

Correct. One interpretation is that it is the rate at which the decoder 'consumes' data, during playback. Owing to the limitations placed upon parameters such as 'jump distance' and buffer capacity (to name only a few), for example, there is a limit to how much data rate a player can practically cope with, while playing back an Interleave Block, without buffer underrun occurring. If the algorithm realises that your constituent streams violate the relevant areas of the spec, then John B. has ensured that TFDVDEdit will flag this (with a useful error message, unlike certain programs / operating systems we have all come across). The reason the warning flag also mentions that it may not necessarily prevent you from continuing with the interleave is that a given bitrate peak may, in synergy with other streams in the same Interleave Block, be 'distributable' without violating the spec. However, despite this message, if TFDVDEdit then goes ahead with an interleave and, during that physical procedure, realises that the other consituent streams will not combine successfully with the bitrate peak in question, then rest assured that it will not ignore this or pretend it never happened - TFDVDEdit WILL abort and tell you the reason why, so that you need not fear a failed replication job, on the basis of violation of this spec parameter.

"how sophisticated is tfdvdedit's interleaving algorithm? trai's article on seamless branching describes a fairly simple scenario in which three fairly similar (plus a cell or two her, minus a cell or two there) PGCs were interleaved and the process is in that case fairly straightforward, but what about more complicated scenarios?"

The short answer, is that John Brisbin's Partial-Interleaving code is very complex indeed, but it's capabilities will increase, as development continues.

That being said, let me briefly address your hypothetical conditions:

"- two PGCs, one is ninety minutes long the other is ten minutes long. the former consists of every cell in the VTS, the latter consists of only the first and last cell."

Conceptually, this isn't an especially complex condition for Partial Interleaving. However, it raises some interesting issues.

What you have described is a toally legitimate example of Partial-Interleaving (AKA 'S-B'). From a conceptual standpoint, it is possible to do exactly what you have described, and, indeed, it can be put into practice on a practical level. However, there are certain limitations to the spec which make this a situation where an author needs to consider certain practical implications.

As I'm sure you are well aware, the manner in which interleaving works (be it for M-A or S-B purposes) is by slicing the VOB into miniscule chunks/packets (ILVUs) and rearranging them (or 'repacketizing' the VOB). This must be done to very strict spec guidelines if the end result is to be within spec and thus be playable, without buffer underrun, in all spec-compliant players - in other words, the 'jump-distance' can only be just so big.

This means that where the maximum 'ratio' is reached, 'MPEG filler material' must be used, in order to keep the jump distances in spec. This still works 100% perfectly, but it is only prudent to point out that, in certain extreme situations, there could be an argument for simply duplicating your first and last cell material and placing this (physically) duplicated MPEG material at the beginning or end of the existing VOB, to be played in a conventional manner. My point here is that the author must not forcibly employ a technique simply because he or she can - it is important to evaluate each authoring situation as it arises. Sometimes the humble, conventional, method is still appropriate.

That having been said, your specific example refered to a ratio of 1:9, which, I believe, is quite legitimate for Partial Interleaving. Following a little further development, therefore, this condition should be extremely easy to author with TFDVDEdit. It is, essentially, a simplistic version of what the team have chosen to term a 'Highlight Reel' style of S-B, whereby several scenes are removed, at different junctures during a Main Feature, with (optional) transitions added to the VOB, which, once interleaved, will leave playback of the Main Feature unaffected, while playback of the shortened Highlight Reel will involve seamless jumping from one M.F. segment to a transition element, and then to the next required M.F. segment, and so on. Even the audio can be made to accomodate this, with alternative soundtracks, or simply shortened soundtracks, BOTH being available to the viewer.

"- two PGCs both ninety minutes long, both consisting of the same cells, but one having the cells in the reverse order--viz.,

PGC 1 is [ A B C D E F G H I J ]

PGC 2 is [ J I H G F E D C B A ] "

I was asked precisely this question, some months ago, on another forum. Partial-Interleaving is a many-splendoured thing, but it cannot circumvent the laws of physics. Data is laid out on a disc in a certain physical order. It doesn't matter what that order might be - just conceptualise the fact that it is where it is. Unless it is duplicated, it cannot possibly be in two places at the same time.

Therefore, when a disc is played, data, in whatever order it has been written to the disc, must be followed in a linear fashion if playback is to remain seamless - it may be incrementally-skipped, in the case of interleaved VOBUs, but any jump too large, or in reverse, or requiring large random accesses will result in buffer underrun. This is precisely the behaviour you can observe when playing a non-interleaved PGC that references data in an order that differs to the physical layout of the referenced data, on the disc. A pasue will result as the player seeks the next cell, since the referenced data lies elsewhere on the disc. DVD SP authors, and even Creator and Scenarist authors, suffer this indignity on a regular basis.

Consequently, one set of cells cannot possibly be played back linearly in both 'directions', given that the physical data only exists in one or neither of those desired playback orders.

To achieve your hypothetical authoring condition, it would be necessary to physically duplicate all but one of the cells, like so:

[ A B C D E F G H I J I H G F E D C B A ]
PGC 1 PGC 2

OR:

[ J I H G F E D C B A B C D E F G H I J ]
PGC 2 PGC 1

"how does this scenario differ, if at all, if you are working with 100 cells in lieu of 10?"

From a physical Interleaving perspective, the number of cells is not really a huge concern. A far more important consideration would be keeping within the maximum number of cells per PGC, according to the DVD spec.

"- what about greater numbers of PGCs in even more convoluted arrangements?"

Well, as I said, everything needs to be evaluated on a case-by-case basis. However, provided one fully understands the conceptual rules governing the practical application of interleave techniques to a VOB, then 'complexity', in and of itself, is not a specific problem.

I have been very involved with testing of this particular feature, and I fully appreciate your desire to push the boundaries of what is possible with the existing codeset (believe me, I, and a few other members, have done the same!).

However, although greater flexibility will eventually be implemented in the Partial-Interleaving routines, development efforts are, at the time of writing, being concentrated on Mastering. Having said that, John and Larry have been working their socks off and getting some well deserved success with Mastering, so hopefully their talents will soon be available for addressing other facets of the program, which, while functional at present, have even further potential.

John has been extraordinarily rigourous with his P-I code (and everything else he has contributed, actually), ensuring absolute spec-compliance. Because of this, we are not only fortunate to be able to use a tool that works correctly, but there are additional benefits. The more intimate John's understanding of interleaving (and thus how to slice and reconstitute a VOB, on literally the smallest possible level), the more he is able to transfer that knowledge to other areas of the program. I will say no more than that, for now, but I believe there are some very exciting features, to come, in the future, which will benefit from the interleaving work.

Back to the specific scenarios you have outlined above, the routines WILL be developed in order to be able to do that kind of work, but this will take some time, owing to the mind-boggling complexity of the coding task (rest assured, John is more than capable). It's basically a case of John allowing more permutations in the code for different real life 'conditions'. The core capability remains the same, even for quite convoluted conditions such as those you have described, in so much as the spec-defined rules for Partial-Interleaving still apply (jump distance / ILVU size boundaries etc.). As I understand it, it is the ~overlying~ logic, which interprets your PGC requirements appropriately, in order for the Partial-Interleaving routines to suitably operate upon the VOB, which needs to be updated to take account of other real life conditions.

If you have any more questions, then please never feel inhibited to ask them. This is a flame-free board with enthusiastic people who want to help and to learn.

Kind regards,

John.
('Arky')

---

Posted Oct 26,2004 4:43 AM Arky

I neglected to mention that, at the time of writing, the only tried and tested condition that works reliably with the current codeset is the style that is outlined in Trai's example, here: http://www.tfdvdedit.com/public/83.cfm

As I said, this situation will change, but that is the present status quo. Any attempts to author different styles of S-B, with the current codeset, may throw up sundry error messages. I stand by my discussion of bitrate issues, above, but I should have, additionally, pointed out that it is not unknown, with the present codeset, for max Vo errors to be flagged, in situations where one is attempting to author an alternative style of S-B (see the Beta forum for discussion on such a situation).

John.
('Arky')

---

Posted Oct 26,2004 1:13 PM Harold

hi john/arky (i do not know which you prefer),

thank you for the prompt and exhaustive reply! it set to rest most of my questions and was a good read as a bonus. your point that "because i can" is not a good reason for employing a technique is well taken: it was precisely _because_ i have yet to find an appropriate use for seamless-branching/partial-interleaving techniques that i chose to _abuse_ these techniques (if you will), knowing full well that i was doing so--the logic being that after one figures out what can be done with a tool, one is better equipped to figure out creative uses for that tool. after some reflection, i have a few more questions.

it would seem from your reply that one of the more serious limitations imposed upon P-I is that all seek operations (or all seamless seek operations, in any case) must be forward; thus the canonical tricks for optimizing seek times for a few predictable paths through sequential-access-mode data are precluded. to illustrate what i have in mind here, return to my 2 PGC example, now with a "sub-script" denoting an index:

[ A_1 J_1 A_2 J_2 A_3 J_3 B_1 I_1 B_2 I_2 B_3 I_3 . . . E_1 F_1 E_2 F_2 E_3 F_3 ]

were seeking backwards and seeking forwards to be equally supported this sort of arrangement might accommodate the sort of scenario i described--albeit in a sort of a yo-yo-like fashion.

since backwards seeking does not seem to be possible, is the "highlight reel" scenario simply accomplished by manipulating block sizes? your remark that 1:9 ratios are both possible and sensible leads me to think this is the case. in view of that, at what ratios does P-I cease to be sensible and/or possible?

also, with regards to concatenating mpeg streams, the thread you referred me to suggested that DVDSP 2 had some shortcomings in the way in which it accomplished this. is this still the case with DVDSP 3? could you (or anyone) elaborate upon the nature of these shortcomings (i.e. is it something to be avoided or is it just not suitable for partial-interleaving)? regarding the necessity of segmented encoding, is the issue that the encoders do not accurately place I-frames (which will dictate the placement of cell boundaries) or is the issue that the encoders tend to place "the wrong kind" of I-frame? i tend to think of I-frames as I-frames, but i recognize that this view may be naive.

once again, thanks for your in-depth reply.

cheers,
h

---

Posted Oct 31,2004 12:57 PM Arky

Hi Harold, sorry for the delay, I'm currently working nightshifts so my free time is somewhat curtailed. Please call me John - Arky is my nickname in Video circles purely because I used to be 'anonymous' until Trai brought me kicking and screaming out of the anonymity closet!

...ok...more questions...

Firstly, let me just say that the following represents my current understanding of the issues involved, but it is only fair to point out that I am still learning as I go along, and other members may have greater expertise on certain aspects of the discussion than I, so I welcome corrections/contributions to that effect...

"it would seem from your reply that one of the more serious limitations imposed upon P-I is that all seek operations (or all seamless seek operations, in any case) must be forward"

For the purposes of conventional PLAYback, yes, and I'm sure you are on the same wavelength as me, on this point. However, just to be explicitly clear about this, the ability of a player to FFW or REW, for example, is largely unaffected by interleaving - you may rewind, quite happily, through Partially-Interleaved content. ...and even where conventional playback is concerned, to be fair, P-I is no MORE limited than any other form of VOB structure, with regard to physical data layout vs. multiple logical playback path references (multi-PGCs).

I suppose a fairly simple rule of thumb is that anywhere you fall foul of the capabilities of P-I, duplication of VOB material is generally the solution. In certain circumstances, a combination of P-I and duplication may be necessary, with the penalty, of course, being a disc capacity hit, wherever duplication has occurred. It is my expectation that TFDVDEdit will be deliberately coded in order to take care of all such eventualities (indeed, it already does, to some extent), perhaps with warning messages to flag any significant capacity hits, owing to partial VOB duplication.

"since backwards seeking does not seem to be possible, is the "highlight reel" scenario simply accomplished by manipulating block sizes? your remark that 1:9 ratios are both possible and sensible leads me to think this is the case. in view of that, at what ratios does P-I cease to be sensible and/or possible?"

Yes, manipulation of ILVU sizes is precisely what makes Partial-Interleaving such a powerful and desirable feature, and also why it is so difficult to accomplish, from a programming perspective. John B. is the true expert on this, but I am given to understand that the maximum ratio is somewhere in the region of 1:10. Obviously, this is in contrast to the ILVU architecture of conventional M-A interleaved streams, where all constituent streams are re-packetized into ILVUs of greater (although not absolute) consistency.

"...with regards to concatenating mpeg streams, the thread you referred me to suggested that DVDSP 2 had some shortcomings in the way in which it accomplished this. is this still the case with DVDSP 3? ...Could you (or anyone) elaborate upon the nature of these shortcomings?"

It's not that DVD SP 2 is incapable of doing a respectable job of concatenation, but there were reasons for my remarks, at the time, which I feel still stand, including:

The GUI itself (of DVD SP 2) exhibits some weird anomalies when attempting to insert cell markers at maximum possible zoom. On a number of occasions, during testing, we discovered that, although DVD SP had appeared to add cell markers at the precise boundaries of the segments, revisiting them afterwards revealed that the markers had, in fact, been inserted a GOP ahead, or behind, of the intended boundary. Don't just take my word for it - try this yourself.

We also observed that DVD SP 2 has a habit of displaying audio tracks as being one or two frames longer or shorter than their accompanying video tracks, and this anomally is seemingly worsened when multiple clips are concatenated (initially, we postulated that this may simply be due to DVD SP's apparent interpretation of all NTSC files as 'Drop-Frame', but, using MPEG Append to flag files EITHER way made little or no difference to the DVD SP 2 GUI's visual anomally). Although this anomally did not appear to physically manifest itself in the multiplexed output, it was just too disconcerting for comfort, given the infinitesimally fine tolerances that are necessary in order to achieve perfect results with Partially-Interleaved Titles.

MPEG Append automatically inserts DVD SP cell boundary markers at segment joins, with absolute accuracy, so it's a serendipitous arrangement:

~to allow MPEG Append to do a perfect concatenation job (remember I said that John B. is rigourous about adhering to spec'? Well this also applies to MPEG Append).

~to negate the need for manual marker-insertion, once within the DVD SP environment, thus saving time, uncertainty, and potential marker placement errors.

"is it something to be avoided or is it just not suitable for partial-interleaving)?"

Broadly-speaking, I would not be totally unwilling to concatenate limited numbers of files on DVD SP's timeline, but I would certainly still favour the MPEG Append method, for the aforementioned reasons. When authoring P-I / S-B projects, though, I refuse to take any risks whatsoever, simply because of the incredibly fine tolerances that 'branching-points' must adhere to. In other words, the 'accuracy stakes' are higher, and mistakes cost time and money.

Don't misunderstand me, I'm not berating DVD SP 2 - I'm simply harking back to my previous remarks about workflow efficiency - professional authoring is all about keeping the compatibility and reliability percentages as high as possible, so Trai and I developed what we consider to be the most appropriate workflow for DVD SP authors wishing to create S-B Titles. Again, you may do as you please, with this information. Incidentally, if you author with Creator or Scenarist, then you have the luxury of being able to discretely multiplex your segments, and thus do not need to concatenate in this manner, but I won't get into that just yet!

...and with regard to version 3, the above issues and remarks still stand.

"regarding the necessity of segmented encoding, is the issue that the encoders do not accurately place I-frames (which will dictate the placement of cell boundaries) or is the issue that the encoders tend to place "the wrong kind" of I-frame? i tend to think of I-frames as I-frames, but i recognize that this view may be naive."

Well, I-frames are curious creatures, and, from a practical standpoint at least, there is, as you suspected, more than one kind. Without wishing to labour the point, Partial Interleaving places uncommonly-high demands upon the entire authoring process (even as far back as the NLE environment). Ordinarily, when jumping to a cell boundary, we would not consciously notice (because it is a significant 'leap' from wherever we were previously), that the process is generally a non-seamless one - in other words, we subconsciously 'expect' a lack of seamlessness in that undertaking; when we press the 'next chapter' button on the remote, we naturally expect there to be a slight pause while the next chapter/cell is located. However, with S-B, we have a somewhat unique situation, whereby cell boundaries are encountered by a player under varying circumstances, according to what PGC route (story version) has been chosen by the viewer.

In other words, these special cell boundaries are being approached from different ILVU locations, all permutations of which must nevertheless occur (subjectively) Seamlessly. The integrity of the I-frames that form these cell boundaries is therefore of the utmost importance, if all is to run smoothly, as intended. If one of these I-frames is deficient, in even the slightest way, there will be no 'natural/expected pause' to mask it's inadequacy - the viewer is expecting the Branching point to be navigable with total subjective 'transparency'.

Whilst navigating the interleaved section(s) of the VOB, the Track (Video) Buffer is skillfully prevented from emptying by the player's Presentation Engine, which, by observing both Vo and the Data Transfer Rate from disc to Track Buffer, along with the physical layout of data on the disc, maintains a constant stream of data to the decoder.
This juggling act is reliable but, owing to the latency of DVD drives, and the extreme paucity of track buffer memory, is vulnerable to Spec violations or discrepancies/inadequacies in the data stream. It is an extremely fine balancing act (hence the precision with which ILVU boundaries and jump distances must be calculated. Keep in mind that these values are intimately related to both the number of constituent assets in an Interleave Block and each of their bitrates).

Now, in principle, the use of an encoder's I-frame 'injection' facility, at designated timecodes (and, optionally, scene changes, too, provided M-A is not the intended interleaving type), should serve our purposes perfectly. However, as I remarked in my previous post, TFDVDEdit has to suffer the indignity of interleaving streams produced by a multitude of potential MPEG encoders, and different encoders deal differently with ostensibly-similar parameter settings, so again it is important for us to prescribe an authoring workflow (in this case, concatenated segmental encodes) which can be relied upon to yield consistent results, irrespective of the idiosyncrasies of alternative encoders.

One example of how an I-frame may be compromised at a critical Branching point, if I-frame injection is used, as opposed to the segmentation/concatentation technique, is exporting to Compressor, from the FCP timeline, in VBR mode. Since Compressor has a nasty habit of creating excessive bitrate peaks at I-frame injection points (amongst other places), it makes the prospect of a lengthy encode being followed by the discovery that certain I-frames preclude Partial Interleaving, a costly, frustrating, and (unfortunately) realistic one.

There are also further considerations that must be taken into account, if things are to operate flawlessly during playback of a P-I Title.

Given that, with P-I, we have a situation whereby several alternative streams must 'splice' (term loosely used) perfectly with a singular incoming stream, we do not really want the outgoing B-frames of each of these streams to reference the first I-frame of the singular incoming stream. Were this to happen, then, theoretically, the end result could be successful, but on a more practical level, it is safer to keep all constituent streams 'self-sufficient', as this results in a more 'robust' MPEG structure at those junctures. Were we to attempt to make the final B-frames of all alternative outgoing streams reference the common first I-frame of the singular incoming stream, we could never be absolutely certain that the results were consistent, even though they might, in certain circumstances, prove to be usable. Much better, in practice, to hedge our bets by encoding segments discretely and know that they will operate correctly and with maximum B-frame image quality (incidentally, there are also, theoretically, VBV Buffering issues where MPEG segments are 'spliced', but this is not something we need concern ourselves with, in the present discussion, provided all segments are encoded with identical parameters).

Now, it could be argued that a Closed GOP structure theoretically ensures that the I-frame immediately following a closed GOP should not be referenced by the final B-frames in that preceding GOP. This form of 'GOP-Header' I-Frame is a desirable structure for any location where 'Seamless-Branching' must occur, and is thus exactly what we wish to achieve. In principle, therefore, we could assume that (provided we do not intend to use Compressor) it is acceptable to dispense with segmental encoding, opting, instead, to encode a single MPEG stream, direct from the timeline, with forced/injected I-frames at branching points, provided that we also specify Closed GOPs, to ensure that each I-frame pertaining to a branch point is not referenced by preceding B-frames (CCE SP is one of the more intelligently-devised encoders on the market, and even if Open GOPs are chosen, in order to maximize overall encoding efficiency, the encoder is capable of automatically closing any GOPs adjacent to injected I-frames).

Inevitably, though, since we cannot be absolutely certain that all encoders will strictly honour each of the important parameters described above, it is prudent to follow the relatively fool-proof authoring workflow we have described (and, of course, even if we have chosen to encode with Open GOPs, the net result of segmental encoding and concatenation will be Branching points where outgoing B-frames do NOT reference incoming I-frames, so it is a method we can have a high degree of confidence in, with regard to true GOP independence at Branching points) ...Remember, Panasonic and Toshiba systems have dedicated encoders, costing tens of thousands of dollars, and developed expressly with the rigours of P-I work in mind. We have to make do as best we can, with what is available to the (relatively) impoverished common-or-garden DVD author! :-)

Perhaps because they were not envisaged for such such highly-demanding work, many encoders in the general marketplace have been developed seemingly without absolute respect for the critical importance and accuracy of certain structural MPEG parameters. Without wishing to sound disparaging about the general MPEG encoder market, do bear in mind that Trai and I encountered many problems, during our extensive tests, in the run-up to NAB, a depressingly large proportion of which were related partly, or in full, to inaccurate (VBR) bitrate control - something which is at the most fundamental level of encoding control. In light of this fact, you can, perhaps, understand our determination to offer TFDVDEdit licensees the most robust and practical approach to avoiding potential MPEG encoding pitfalls, when attempting to author P-I projects with TFDVDEdit, even if this means treating certain aspects of encoders with a degree of scepticism. While I do not claim to have the mathematical expertise to explain precisely why some encoders do a better job of encoding certain MPEG parameters (I'm afraid that's another one for John, some day!), some encoders clearly do a more reliable job than others, and that's a fact we ignore at our peril.

In summary, then, the following is recommended for P-I work, in addition to the points outlined in the previous reply:

~Although, from a DVD Spec' perspective (and unlike conventional M-A interleaving), P-I does not explicitly require closed GOPs, I nonetheless encourage you to opt for closed GOPs when authoring P-I projects. It's not critical, but I feel it is a wise choice (even though it may be argued that there is a slight efficiency hit as a consequence). It can also be (contentiously, perhaps) argued that closed GOPs increase reliability with DVDR media, due to reducing the amount of 'pre-fetching' necessary in order to decode portions of the GOPs (remember that P and I frames have to be decoded prior to the decoding and presentation of B-frames that are dependent upon them - B-frames are predicted from the closest two I or P frames, one in the past, and one in the future, although where this is not possible, Intra-coding is permissible). Interleaving is complex enough, already, so I would contend that we really don't wish to have dependencies across GOP boundaries unless it is unavoidable (if we are provided with streams pre-encoded at a compression house, for example).

~Do not be tempted to avoid concatenated segmental encoding.

~Ideally, opt to concatenate with MPEG Append, rather than on the DVD SP timeline.

~I would recommend, if you have access to a PC, downloading BitRate Viewer: http://www.tecoltd.com/bitratev.htm It will prove to be very imformative in situations where you are attempting to settle upon good P-I-specific encoding parameters for your particular encoder, and will immediately reveal if your encoder is misbehaving with peak bitrate.

Ok, now you have seen an explanation for the benefits of segmental encoding and, in the case of authoring with DVD SP (and other, non-Spec'-based authoring systems), subsequent concatenation.

However, if you author with a true Spec'-based system (e.g. Scenarist, Creator, and perhaps, one day, DVDLab or...TFDVDAuthor?! :-) ), this is where it gets more interesting (it's not that what follows is irrelevant to DVD SP et al - far from it, it's just that it is beyond the control of such authors, and so was not discussed above). You do not need to read what follows, but I thought I would offer you the information, since knowing additional details helps to fill in gaps in the bigger mental picture, and it was interesting to me, having tested P-I so intensively, on a practical basis.

Owing to the differing ways in which Audio and Video stream types are 'packetized' (on a fundamental level, in the conventional sense, I mean, not in the sense of RE-packetizing for interleaving purposes) they do not precisely conform to one another, on a mathematical level. This means that a certain amount of discrepancy must be allowed for, and accepted, during a multiplexing procedure (don't ask me for the precise mathematics - John B. did make a valiant attempt to explain this to my inferior brain, during a rare quiet moment, at the booth at NAB!). The DVD spec' makes no provision for the likes of SMPTE timecode, and this means that, despite these mathematical 'packet-discrepancies', there is, remarkably, nothing specifically keeping Audio and Video *locked* in synch with each other. Rather, the Spec' simply dictates that the decoder need only intialize at the beginning of each of the streams and decode each of them simultaneously, at the specified 'identical' rate.

As you might imagine, this lack of SMPTE, or similar scheme, is a total nightmare when faced with the prospect of repacketizing multiplexed Audio and Video into 'microscopically' small chunks (ILVUs), yet still ensuring precise allignment of ILVU Audio and ILVU Video packets. It's an extraordinarily complex and difficult task.

During the development of TFDVDEdit, the programming team discovered that there are common timing inconsistencies in the multiplexed output of virtually all authoring systems (even some extremely high-end ones...). Consequently, even when the additional demands of Interleaving (and thus, incremental repacketizing) are not on the agenda for a project, TFDVDEdit ensures that corrections are made to the relatively 'lax' multiplexing carried out by the preceding authoring system. These are corrected as a background task, simply by saving an opened project. However, P-I raises the stakes dramatically further, since the mathematical discrepancies between Audio unit structure and Video unit structure make maintaining allignment even harder and more critical, particularly at Branching points themselves.

It is because of these discrepancies, that it is beneficial, in an ideal world, to encode, and even Multiplex, segments discretely, in order to keep the discrepancies in check, rather than allowing them to 'accumulate' over a longer combined duration. DVD SP authors have to settle for a compromise, however, using concatenated streams, comprised of segmental encodes, which will not be multiplexed discretely. I still had great success with P-I Titles, despite this 'shortcoming' of DVD SP, though, so do not be disheartened. Follow the recommended workflow and you should have no problems authoring your first 'Seamless-Branching' Title. John Brisbin has done such an astonishingly good job of error-checking and automating the procedure behind the scenes, that even marginal multiplexed sources have the best possible chance of success, during the Partial Interleaving procedure (I wish you knew how much hassle the Toshiba and Panasonic boys go through, when doing P-I jobs! John has made the procedure *absurdly* easy for us humble TFDVDEdit users!).

As you are probably beginning to appreciate, the more you delve into the realms of complex physical (as opposed to logical) authoring structures, the more there appears to be a curious blurring of boundaries between the technical, theoretical, dictates of the DVD Spec', and the real-world practicalities of successfully achieving reliable and functional representations of those elements. Therefore, although the Spec' may not always insist upon certain methods or 'tweaks' (and, indeed, you may well be fortunate enough to achieve success without them), that is not to say that, in a real-world situation, it is not beneficial to embrace them, in order to increase overall efficiency and reliability. In other words, there is method in my apparent (workflow) madness!

I hope I managed to satiate at least a little of your curiosity on the above issues. As I said, I am still learning about this huge area of DVD authoring (if anyone spots any errors, please do correct me), and it seems, instead of reducing, the questions seem to grow at an exponential rate, the deeper one digs!

...but then, as Trai will tell you, that is a typical characteristic of Inquiry and is a great catalyst for learning! :-D)

Regards,

John.

---

Posted Nov 01,2004 4:58 AM ianshepherd

In my own experiments concatenating with DVDSP, I've found that if the join is on a hard visual cut, blocking artefacts can occur. Otoh I haven't seen this where there end/start frames are identical.

This is annoying, however, because we are very used to hard cuts in video, and I have found that one of the easiest ( subjective ) ways to get a convincing "branch" point is to use a hard cut, ie. NOT try and match the join points visually - it just gives you a whole load of extra hoops to jump through.

But, I agree with John, overall the MPEGAppend method is worthwhile even without this consideration, if only because ( say ) you need to adjust the content of one short section, you don't have to remux the whole thing. ( MPEGAppending is much faster than muxing. )

Ian

PS. John, how about a bit more detail in your replies ? [grin]

---

Posted Nov 01,2004 12:13 PM harold

hi ian,

correct me if i am wrong, but doesn't MPEGAppend operate on the elementary streams, not the muxed streams?

cheers,
h

---

Posted Nov 01,2004 2:59 PM ianshepherd

Hi Harold,

Yep, you're right - brainstorm on my part ! For some reason I slipped into thinking about yet another potential workflow, namely exporting a whole sequence and forcing I-frames at the branching points. In that case appending different sections is a more efficient workflow.

Brainstorms apart, my first point is still sound :-)

Ian

---

Posted Nov 01,2004 11:56 AM harold

hi john,

thanks for the long and detailed reply (again)! i for one am a huge fan of detail. the other thread over the weekend in the beta forum brought some additional issues to my attention, such as keeping the same number of cells in interleaved PGCs.

after splurging on TFDVDEDIT (but oh, it was worth it!), CCE SP is a bit beyond my reach at the moment (i hear nothing but praise for CCE SP, so it is on my wish list). however, it sounds like in a pinch one can get away with a segmented, closed GOP, careful, and CBR-based compressor workflow.

mind, i do not yet need to deliver a P-I/S-B project. i am just "doing my homework" so i encounter all these difficulties before i am on a deadline.

thanks again for all the information.

cheers,
h

---

Posted Nov 01,2004 12:39 PM Arky

You're welcome, Harold.

Just keep in mind that some of the limitations you may see me referring to in S-B-related threads will cease to be of concern, once those areas of TFDVDEdit's P-I code are developed further (boy, are we going to have some FUN once John B. has had the chance to develop that code!!)

With regard to CCE, I myself cannot yet afford SP - I make do wth CCE Basic. SP is on my wishlist, too, although I do still have some experience with it, on a trial-program (watermarked) basis (e.g. the facilities in SP for bitrate tweaking are just astonishing, and totally unmatched by other software-only encoders).

CCE Basic may lack such tweaking, and lack multiple (3 or more) encoding passes, but is only $58 and well worth the money, considering that it does use the same core encoding engine, and consequently produces marvellous results with all but the noisiest source footage. If you have a PC, then try the demo (and be sure to try ProCoder, too).

http://www.cinemacraft.com/eng/download.html#sp

Take heart from the fact that all the P-I testing Trai and I did before NAB, was done using common, easily-affordable, encoders, on both Mac and PC platforms.

If you must encode on the Mac, to be absolutely truthful, I would recommend that, although FCP itself is great, you still stay clear of Compressor (sorry, Apple!), and use MainConcept or BitVice encoders instead, for your MPEG 2 encoding.

John.

---

Posted Nov 01,2004 1:08 PM harold

hi john,

sounds like you are back on a more normal schedule. actually, i have no idea what time zone you are in, so perhaps not...

so is it your contention that CCE Basic is an improvement over compressor for all work or just P-I work? do you know if it plays nice with avids (where all of our intel-based horsepower is tied up)? does ProCoder behave similarly well with regard to producing P-I ready streams? it is nine times more expensive... then there is BitVice in between ...oh my head hurts!

anyway before we stray any further off-topic, thanks for all the advice. i'm looking forward to putting some of it into practice.

cheers,
h

---

Posted Nov 01,2004 1:54 PM Arky

I am in Wales, UK (GMT).

I'm still on the nightshifts (should really be sleeping right now!)

Personally, I dislike Compressor on a number of levels, not just for P-I work. P-I work notwithstanding, other users get acceptable results with Compressor, but I really do wonder if they would choose it as their first encoder if they also had PCs at their disposal...

ProCoder does a really nice job with noisy DV footage, and I use it instead of CCE Basic when my footage is 'noisy' (filmed in low light, for example). ProCoder and CCE Basic are both neck and neck, in my opinion, but there are times when I feel that ProCoder's strength is also, paradoxically, it's weakness (and do bear in mind that ProCoder is multi-talented - my remarks here are directed specifically at MPEG 2 encoding). ProCoder's strength with noisy footage seems to be due to some sort of adaptive noise reduction, but it can be seen, in some circumstances, that ProCoder exerts a slightly 'smoothing' effect on source footage. I notice it when encoding my Gliding footage, for example, where there is often footage of grass, on the airfield, being blown by the wind. Under these circumstances, CCE produces a less smoothed appearance than ProCoder. Having said that, ProCoder's apparent 'smoothing' (and this is a subjective thing!) is often not obvious at all, and allows the MPEG encoding engine to work more efficiently with noisy footage, and where bitrate is very tightly constrained. CCE still manages to avoid macroblock mosaicing more effecively than ProCoder, though...as I said, they're both good, and I like to choose between them according to the specific task at hand.

Coming back to P-I work, I like both these encoders very much, and both of them do a great job. They both respect VBR peak bitrate rather well. Trai and I did discover a strange anomally with ProCoder's flagging of Progressive streams, which ~occasionally~ yielded MPEG 2 streams that were flagged as BOTH Progressive AND Interlaced. We discovered this when we tried to import the streams into DVD SP 2 and it refused to parse them. Opening the offending streams in ReStream, back on the PC, the dual-identity of the flags became immediately apparent, and, having re-striped them correctly as Progressive only, sending them back to DVD SP resulted in them being accepted and parsed as normal.

On the basis of my testing with P-I, I discovered that BitVice is no angel when it comes to adhering to peak VBR bitrate, but provided you take account of this, with especially-conservative peak bitrate settings, it does then behave itself, unlike Compressor. Uli likes BitVice, for Mac encoding, and I can see why. On their product page, Innobits have ben promising a more advanced 'Pro' version of BitVice, for quite some time, which looks interesting, but no demos have been released, to date, as far as I am aware.

I don't use AVID, so I can't really comment upon direct compatibility with CCE, but there is no question that you could export an uncompressed .avi or .mov from AVID, on either platform, and then feed this into CCE standalone (either Basic or SP), on the PC.

Since, in terms of ~image quality~, MPEG encoding is often a very subjective thing, I suggest you find a number of pieces of source footage, each with different image quality characteristics, and run them through the demos of CCE and ProCoder (ProCoders baby brother, 'Express', is pretty good, too, although it is wizard-based and does not include Mastering Quality motion estimation):

http://www.canopus-uk.com/UK/products/procoder_express/pm_procoder_express.asp

I've successfully created P-I Titles with All of these encoders, as you saw in my older posting.

You really need to 'suck them and see' for yourself!

You can download CCE Basic and CCE SP demos from here:

http://www.cinemacraft.com/eng/download.html#sp

..and Canopus will let you download demos of ProCoder and ProCoder express, as will InnoBits, with BitVice:

https://www.innobits.se/download.php

You can checkout the MainConcept encoders (both Mac and PC versions) here:

http://www.mainconcept.com/products.shtml

Have fun.

John.