I am implemetin the support to use the libdvdread to export DVD filesystem via UPnP. My purpose is to create virtual folders as
I can use addContainerChain to create /DVD/dvd1.iso. However, how can I create items under it? When I use addObject, it will complain that the items is incorrect.
Ref<CdsItem> objtitle(new CdsItem());
snprintf(name,64,"Title %2d", i);
It will complains about the refID is incorrect. If I use the container ID as refID, it will complain the lcoation is different.
The question is that. How can I create correct items under the virtual path.
OK, here is how it works:
when adding a virtual item of type CdsItem (i.e. non-URL stuff), the item must reference the "real" item - the one in PC Directory.
So, for CdsItems you always have the non-virtual item that resides in PC-Directory, and then you have a bunch of virtual references which are scattered around the user defined virtual layout.
Now, let's look at what you are trying to achieve:
in your case, the - we call it "pure item" - is in PC Directory/DVD/dvd1.iso
You have to make sure that you use "ContentManager::addFile() to add it. Your language tracks will be virtual items, which may have some special parameters to help you identify when you have to do the extraction from the ISO.
So in pseudo-code:
int pcd_id = ContentManager::getInstance()->addFile(_("/DVD/dvd.iso"), false, false, true);
int prt = ContentManager::getInstance()->addContainerChain(_("/DVD"));
Ref<CdsObject> pobj = Storage::getInstance()->loadObject(pcd_id);
Ref<CdsResource> res = pobj->getResource(0);
Ref<CdsItem> objtitle(new CdsItem());
objtitle->setTitle(_("Test") + String::from(i));
Note the resource stuff: what we did here is - we added a "&dvd_track=0" parameter to the URL of the virtual object. So, when you receive that in the FileRequestHandler::open() you can identify that the request is made for a particular DVD track and you can then serve the appropriate data.
But well, if you guys are a company and have some commercial intentions it would probably be easier and cheaper to hire us to write a particular feature. We know our code very well so we can implement new features very efficiently; this will also guarantee that the feature will be merged into trunk. So maybe worth to give this a thought :)
Thanks for info.
My company put a lot of efforts to prompt digital home products. However, this is my personal project. We have implemented similiar features in our own media server. However, it works for Windows only. This is why I spend time to implemet it in the mediatomb.
Currently, I use the Tracknumber to pass the title number instead of parameters because I am not sure the purpose of parametrer. There are parameter and metadata. What's the difference between them?
My story is somewhat similar - I was working for a bigger company that was developing UPnP MediaRenderer devices, and there was no Linux UPnP server around (at that time not even Twonky), so I got my buddies interested and we started this project.
The tracknumber of a CdsObject can be user for sorting the items in the container, i.e. if you set the track numbers and give the container where those tracks reside the upnp:class of object.container.playlistContainer (use the UPNP_DEFAULT_CLASS_PLAYLIST_CONTAINER constant), then the items will be sorted by tracknumber, no matter how their title is (else items in a container are sorted by their title).
The setMetadata/getMetadata stuff refers to the UPnP metadata, things that will be visible in the XML (this however depends on the upnp:class of the object, because according to the spec there are certain metadata tags that can only be used with an appropriate upnp:class. Look at metadata_handler.cc, right on top, the MT_KEYS stuff and the getMetaFieldName() helper function, you'll see what I mean.
What parameter are you talking about? You mean - parameters in the CdsResource() class?
The parameters there can be anything, and they will be added to the URL of the resource, encoded as param=value, so when the player does an HTTP GET and you receive that request in your FileRequestHandler, you can look at the parameters in the URL and identify what kind of stuff it is and if you have to do anything special. So I'd rather use that instead of the track number.
OK, I believe that I should use parameter instead of tracknumber. I have implemented the first version of the DVD library. Currently, the mediatomb can scan the DVD ISO files and list it as
I can use my DSM520 to play it. There are still issues for trick modes. I should be able to fix it soon. However, I want to implement something like
Play by title
Play by chapter
In addition, I hope to generate thumbnail for each title and chapter in the future so that we can browse it like the DVD player.
Nice! Do you know if you can get the chapter names from the iso? I.e., not just 1,2,3,4 but the real names? Is there any useful metadata in the iso?
I know that the DVD has some barcode which can be used to look up the information about the movie in the AMG database, but I am not sure if that information is retained when the DVD is ripped. At least I could not find any useful information when ripping a DVD to VOBs.
The ISO file is a complete disc image. Therefore, if the barcode is there, we should be able to get it.
However, I don't know where the barcode is. It's great if we can use it to fetch data from movie database so that we can show the title name there.
However, I don't thing there the name of chapter or title is available because they just logic unit inside the DVD file-system. I intend to generate thumbnails for each title and chapter so that we can see them visually.
Currently, mediatomb does not support either upnp:icon or albumartURL. Will we add the support for them in the future?
I am not sure about the barcode either, it's the AMG DVD ID, take a look:
Here the id is: E164356 and as you can see we could easily use it get the information about the movie by constructing an URL with appropriate parameters. Unfortunately I do not have a single DVD around, maybe you can check if you find that AMG code on one of your DVDs and then grep through the image and see if it may be there too?
We do support album art, however I do not think that we can use it for video items:
check the ContentDirectory specification, 7.6.1, on page 86 you will see that the albumArtURI tag is only available when the upnp:class of the container related to musicAlbum and that would be wrong for DVDs. I am also not quite sure if we implemented the albumArtURI stuff correctly, since as I understand from repeated reading the tag is supposed to be delivered with a container and not with an item?
Currently we extract album art from ID3 tags and provide the albumArtURI tag along with the item.
As for upnp:icon - the spec says that this tag is only available with the videoBroadcast class to identify the channel logo, and the class identifies a "continuus stream", so I have my doubts about that as well. Actually, I have been searching through the spec, trying to find if there was something in place that we could use as a thumbnail for movies, but I could not find anything.
I guess one possibility would be to simply have additoinal res elements pointing to images; assuming that the item having a video and an image resource is located in a video container, one could probably assume that the images are previews/covers for the the video. But... to be honest I do not know a single player that would make use of that information.
So the major question is - what is appropriate according to the standard and does anyone support this? I guess we could add tons of cool features, but I doubt that the manufacturers will make use of them.
What do you think?
In Page 77 of the UPnP CDS specification,upnp:icon is interpreted as
Some icon that a control point can use in its UI to display the content,
The tv broadcast channel is just one of its usage.
The DSM520 will use the upnp:icon tag when it is under album browse mode. Unfortunely, other vendors explain this statement in the other way. In the DLNA, it suggest to use the multiple res as the thumbnail. The CP should pick one of its res as the thumbnail. Again, a lot of vendors does not respect it as well.
From the standard side, upnp:icon and multiple res is the only possibility.
DSM520 support former. In addition, if the albumartURI is available for video and picture, we will respect it as well. In the future release, the multiple res will be supported as well.
I will use upnp:icon and multiple resource. Is it OK?
Page 77 lists all available tags, but it does not describe what is allowed at what point,
if you read page 82 (and also all other pages describing the upnp classes):
"A ‘videoBroadcast’ instance is a continuus stream of video that should be interpreted as a broadcast (e.g., a
convential TV channel or a Webcast). It typically has at least 1 <res> element. The class is derived from
‘videoItem’ and adds the following properties:
upnp:icon is listed under those "following properties", and since they are added only in case of this particular upnp:class - then they are not available for other upnp classes.
It's the same with the upnp:originalTrackNumber thing, which is only allowed with certain UPnP classes.
At least that's how I understand the spec, I might be wrong of course.
I have not yet seen the DLNA spec, but there is a chance that I might get it, I'll find out soon when I return from holidays. If I do get the spec then I will implement the DLNA extensions as well.
I am not convinced about upnp:icon, but I will see that I add any thumbnails we might get for video as multiple resources. This is especially useful with YouTube support which I am currently implementing (since it also provides a link to a video thumbnail).
If you make sure to evaluate all resources - that would be great. Indeed, not many manufacturers are doing that, which is a pity since choosing from multiple resources is also helpful for transcoding support.
I think I might have something testable with transcoded YouTube vids + Youtube video thumbnails in SVN within a week or two.
Were you able to solve the seek problem with the streams extracted from the DVD iso?
I have solved that issue. Currently, I can provide correct content length and implement correct seek operation. Althrough, I need to do more testing to make sure the algorithm is correct. AT least for DSM520, all trick modes, including FF/FB/skip works fine now.
Of course, for open source, the best way is to release the code to the public and see the feedback. I will rearrange the source code and release the patch to you soon.
I hope that I can implement the thumbnail for each titles in one week.
Please check 2.5.4 at page 14. It says that
The available metadata tags for properties are described in section 2.3 on Service Base cCLasses(for the base properties), and in the Appendix(for AV working group defined extended properties).
The document define required properties for each classes. However, it is free for us to add properties listed in Appendix 3. Therefore, we can use upnp:icon for any purpose. It complaint to the UPnP AV standard. However, we can always argu that this is not a good way to do the job.
Hmm... I am still not convinced, are you sure that the "extended" properties are only allowed with those extended upnp classes?
See 2.3, page 6, in the table, the class description:
"A class is used to assign a type to an object, and identifies the minimum required
and optional set of properties that must be present on that object."
As I understand the available minimum required and optional properties are exactly defined by the class. Do you disagree?
Anyway, I think it would be better to use additional resources instead of upnp:icon for one simple reason - they "recommend" to use the same icon format as the UPnP device icons, which is PNG, for upnp:icon URI, but since its only a recommendation it theoretically could be anything. The problem is that there is no mimetype supplied with the icon URI, so an additional resource seems like a more stable way to handle this.
Where do you want to take the thumbnails from? As I understand they are not part of the ISO, or are they?
A patch would be very nice, preferably against latest SVN, and please make sure that you do not use C++ STL stuff, only our zmm layer. Thanks!
I agree that additional resources is better.
I will use ffmpeg to generate the thumbnail.
I have sent the patch. Unfortunely, due to a bug in libdvdread, I put a work around in the code which prevent us from call DVDClose until all instace of the DVDOpen are closed.
The reason is the CSS implementation of the libdvdread. The libdvdread use dlopen to load the CSS support from a seperate library. Unfortunely, this library will release the library in the DVDClose function. If there is another instace of DVDOpen is called, the following call to the second instace will crash before the libdvdcss library has been released.
Thanks, got it, I'll see that I integrate it soon! Will have to look closer at this libdvdread problem, thanks for the hint.
The other issue of this patch is that the object ID of these virtual items are changed whenever we restart the mediatomb. I have not looked into it yet. However, I believe that you should be able to fix it easily.
The persistent object ID is very important for CP to keep a valid reference to the items inside the media server. I don't know if this will happen for other regular items as well. If it is the case, I will treat it as a major bug although this will not violate any standard at all.
After being added to the Database our Object IDs do not change anymore; I anyway will have to do more finetuning with the patch regarding the integration into the overall architecture; basically that will concern the process of importing the ISO, I would also like to offer some scripting control over the expansion of the iso into virtual items, so users could change the layout of the expanded image.
Anyway, we now have to focus on finishing this release, so the DVD feature will appear in the release after that.