DVD-V authoring:
The assumption that another application environment would be required to author DVD-V content is proving true.
1. Obviously set-tops don't (and pretty much can't yet) handle Director-called content.
2. MX04 isn't DVD-V authorware
3. No other DVD-V authorware has anything even close to MX04's capability on the ROM side.
My recommendation for DVD-V authorware has stayed as "developer's choice" to date.
1. High-end environments have roughly equivalent functionality
2. This consideration has no identified impact on other considerations beyond the
(no-non UDF content in video_ts folder issue).
3. No reason why different authorware couldn't be used for different Dig Video editions
has been identified.
The ability of high end authorware to produce DVD-V content with certain online functionality is interesting but of dubious relevance for reasons previously described. This (and the set-tops video_ts folder requirement) all but assured that DVD-V content would be produced as a distinct module to be integrated in overall production.
Big-ticket authorware includes Abdobe (Premier, Encore), Spruce (Maestro), Pinnacle (Liquid), Avid, Sonic Solutions (Creator, Scenarist, Fusion, Authorscript). In addition to minimal integration of online functionality, top end authorware support full control over the entire DVD-V spec including background audio, animations & other visual environmental effects.
Very, very big ticket software used by the major movie houses sounds impressive indeed. Proprietary systems developed by big guns like Toshiba, these are end-to-end production and project management solutions geared to reduce time to market, synchronize distributed production and result in the highest attainable level of quality which is geared to reduce warrantee replacements for product runs in the millions. These are way out of your price range.
This lead me back to the ROM production court. Focusing again on the uses case scenarios, I sought to find out:
1. If MX04 would in fact cover all the computer bases.
2. What else was out there to do the job or do it better?
As usual, the use cases revealed a number of compatibility issues. The first big one is Mac but ironically it's not a ROM issue per se.
The Mac issue:
No project is complete without a Mac issue. According to Ralph, Apple refuses to release an API to access content stored on DVD-V leaving only two "off the shelf" ways to create WebDVD content for Mac:
1. Author the DVD-Video title using Apple's DVD Studio Pro authoring tool. DVD Studio Pro
includes DVD@ccess, allows association of a url with a specific track in the DVD-Video
space. Apple DVD player opens a web browser to the url. Apple also has a DVD player
app for Windows which does the same thing.
2. Use Director MX2004 to create an integrated GUI that includes content from both
the DVD-Video and DVD-Rom portions of the disc.
To be clear, this issue effects DVD-V play through DVD-V player software. I should mention that Steve isn't aware of this issue. It's one expert opinion against another until it's tested as far as I'm concerned. Usually, such things are resolved in greater understanding. In this case, understanding will come from the perspective of Mac DirectShow implementation. We haven't seen the last of this issue.
Problems:
1.1. The DVD player and the browser can't communicate with each other once the
browser has been launched. Multiple interface windows that must be navigated separately.
1.2. The Apple DVD player for Windows does not work properly on all Windows systems.
This makes compatibility for Linux/OSX irrelevant.
2.1 Director has included support for Mac systems. May be buggy.
Explained more fully, we can place ROM/Director content in a folder for PC w/ an auto-executable on the root and it will run fine. MX04 & updated Shockwave/Directshow will handle it. There's no support for Directshow calls on the Mac side w/ DVD content (guess why).
The ISO9660 folder:
A possible workaround is to create an ISO9660 compliant folder (integrated via UDF bridging, a technique that requires an identifier in the header of the disk track) w/ redundant content especially for Apple Mac along with the limitation of 32 maximum files on the disk root (per Ralph) and no non-DVD-V files in the ISO9660 video_ts folder (again per Ralph). This does raise the possibility of other ISO9660 folders with ROM content, I'm not sure about folders with HFS file systems (or even why we'd want them). I should note that the ISO9660 spec limits files to 1Gb, filenames to the 8.3 convention. Joliet extensions may provide a workaround. Another workaround is to forget about it and let Mac OS play the ROM.
Similar DirectShow limitations are reported for OSX and WinCE.