Of DVD add-ons and media nodes

Blog post by engleek on Thu, 2010-06-10 14:44

Extending the media kit with the ability to read DVD is a challenge, but a unique opportunity to learn about the kit architecture and Haiku software integration. This time I'll be talking about my actual first development steps concerning DVD support.

First of all, I needed several DVD related libraries. I presented thise in my last post, and they proved easy enough to integrate. Apart from some include path and endian switching issues, they compiled without any fuss.

Well I say it was easy, but the next step was to change the library build system from Automake to Jam (and learn how to use Jam) in order to build them with Haiku, and make them directly available to my add-on as static libraries.

Seeing that most of the add-ons using extra libraries were plug-ins, my first intention was to make a DVD plug-in, simple and versatile. However, that wouldn’t have worked: Plug-ins are called by the media server, and given a BDataIO, or at best a BPositionIO, to see whether the plug-in can do the job, and only deal with these single data buffers, but libdvdnav treats the DVD as a whole, and needs a device path to function. The add-on would have to be fully-fledged.

Right now I’m working on that add-on, and specifically the actual media node, basing it on the video producer demo add-on. At the moment, it automatically tries to load a disk in the first disk drive, using some code from the cdplayer application, and sets up language and cache settings for reading.

My next step is to get that node to connect and produce basic video buffers that can be shown using the video window, and this is proving less than easy, mainly because DVDs use so many different formats.

To illustrate, here’s a quote from Wikipedia:

“Although many resolutions and formats are supported, most consumer DVDs use either 4:3 or anamorphic 16:9 aspect ratio MPEG-2 video, stored at a resolution of 720/704×480 (NTSC) or 720/704×576 (PAL) at 29.97, 25, or 23.976 FPS. Audio is commonly stored using the Dolby Digital (AC-3) or Digital Theater System (DTS) formats, ranging from 16-bits/48 kHz to 24-bits/96 kHz format with monaural to 6.1-channel "Surround Sound" presentation, and/or MPEG-1 Layer 2 and/or LPCM Stereophonic.”

Most media add-ons use only raw formats, and while there is quite a lot of code dedicated to non-raw media formats, learning how to use it, and adapting the node to such a media cocktail is another matter altogether. Tips and tricks are most welcome!

Comments

Re: Of DVD add-ons and media nodes

It means that any media application will can retrieve DVD data without have a proper libdvdnav version?

Re: Of DVD add-ons and media nodes

michaelvoliveira wrote:

It means that any media application will can retrieve DVD data without have a proper libdvdnav version?

Any application wanting to read a Video DVD (not sure about other types), can just use this add-on/node to access video/audio/subs, without directly interacting with the DVD libraries.

Re: Of DVD add-ons and media nodes

> Seeing that most of the add-ons using extra libraries were plug-ins,
> my first intention was to make a DVD plug-in, simple and versatile.
> However, that wouldn’t have worked: Plug-ins are called by the media server,
> and given a BDataIO, or at best a BPositionIO,
> to see whether the plug-in can do the job,
> and only deal with these single data buffers, but libdvdnav treats the DVD as a whole,
> and needs a device path to function.

Is that libdvdnav needs to knows the device path, to enable libdvdcss to do its magic, the issue of not knowing the origin of the BPositionIO passed?
What about defining and implemented a new public BPositionIO subclass, BDigitalVersatilDiskIO , that will vehicule the required device path down your plugin? In your reader plugin, you will reject any source but this one.

Regarding these "single data buffers", AFAIK a reader plugin can publish as many stream 'cookies' as he wants/needs to, and will push the corresponding stream data in ReadNextChunk() according to the cookie. See avi_reader for instance.
Why can't you follow the same road here?

Re: Of DVD add-ons and media nodes

phoudoin wrote:

Is that libdvdnav needs to knows the device path, to enable libdvdcss to do its magic, the issue of not knowing the origin of the BPositionIO passed?
What about defining and implemented a new public BPositionIO subclass, BDigitalVersatilDiskIO , that will vehicule the required device path down your plugin? In your reader plugin, you will reject any source but this one.

The main reason for developing an add-on instead of a plugin was indeed because of the required path problem, but there are other advantages, such as the better options for configuration, and the ability to more or less directly interact with the application.

I don't exactly know what kind of node the application would have to use to read a DVD if it was a plugin.

With this path, the node can ascertain which formats the DVD uses, then pass buffers to the plugins and offer RAW media directly, this instead of a plugin calling other plugins with little control from the user/developer.

phoudoin wrote:

Regarding these "single data buffers", AFAIK a reader plugin can publish as many stream 'cookies' as he wants/needs to, and will push the corresponding stream data in ReadNextChunk() according to the cookie. See avi_reader for instance.
Why can't you follow the same road here?

I've yet to look at producing multiple streams, one the roadmap that's just after producing one video stream. The advantage for avi_reader, is that you/it knows that the media is AVI when launched, where as opening a DVD could mean any number of formats. I myself prefer to open the DVD, then work out what plug-ins and nodes I need.

That's just my opinion though, I'm open to any others :)

Re: Of DVD add-ons and media nodes

I wonder if Blueray support is possible? I don't have a BD drive but its becomming more common. Supposedly most open source Blueray work happens here: http://altair.videolan.org:4280/

Also ffmpeg was just updated to 0.6 with matroska updates for webm and as well as vp8 support its has also apparently seen some speed improvments in a few codecs.

http://ffmpeg.org/