This adds support for the vdr marks file used by noad or markad.
Still missing is the skinning side to show those markers in the progress bar.
added: support for vdr cut scenes (marks file).
Can you please change the method signature to ReadVdrMarks?
Are these .vdr files related to the VDR PVR plugin?
I can change the method but I just used lower case as I thought we wanted to get rid of the camel notation.
the marks / marks.vdr files aren't related to the PVR plugin but to vdr itself. It uses it if you set cut markers or if noad or markad detect commercial skips.
This is one feature why I still use the vdr frontend instead of XBMC.
If the VDR marks are for commercial breaks should it use AddCommBreak instead? With that approach playback in XBMC will automatically skip during playback. Depending on how awesome the noad functionality is you could also use the EDL Advanced Settings to help clean up false positive commercial breaks.
I think scene markers can only be skipped to by using specific key bindings.
Not sure about the move to non camel case method signatures. Been a bit out of the loop re XBMC stuff.
You might want to considering incorporating this "get the list of comm breaks" functionality into the VDR PVR Addon down the track. That will be used eventually once XBMC playback uses the API exposed by PVR Addons to get the list of commercial breaks / cuts. I've been waiting for Eden to ship before spending time hooking that up to dvdplayer / EDL.
I didn't know the edl very well to know each of the methods but I'm happy that I'm accidental used the right one. noad and markad are great but not always correct so I would like to skip it manually like I do on vdr. also vdr indicates nicely in the progress bar where the cut scenes are which we still missing.
I don't know what the plan for the pvr vdr addon is. Currently the edl functionality is in core and the same seems to be for pvr? (at least edl.cpp is there too ;). once we have a plan what shall go into addons and what will stay in core for pvr I'm happy to help since I'll use it as well. Until then its mood to discuss IMO.
changed: use camel case to make if fit with the rest of the methods.
Is this something we can add to pvr? I think it makes more sense following a single path of integration.
we can add it to both since the edl feature is also in both. don't see a reason to just add it to pvr as I can still use it without the pvr extension to some extend.
I haven't actually looked at this patch closely, but just checking: Does it work properly with the splitted .vdr files?
i.e. as VDR recordings are generally split at 2 GB intervals to 001.vdr, 002.vdr, 003.vdr... and IIRC there is a single marks.vdr file.
In current core it doesn't since the files aren't stacked. But this isn't a edl issue but a stacking issue which could be adapted. I dunno the pvr code well enough to know if stacking for vdr files or via the pvr plugin is possible. If yes this patch will work there too.
Again: I use vdr and I would like to have that feature to get rid of vdr as a frontend. I'll have a look at the pvr branch later and if there's anything missing like stacking for those files I'll add that.
When using pvr vnsi client for vdr, recordings are opened by pvr input stream. This does currently not support edl. If we added required functions there I think we could do it in a more generic way and do the vdr specific functions in the addon.
edl is so deeply integrated into dvdplayer how can one use it without? ;)
I'll have a look at how pvr opens the stream but I hope we somehow can reuse the edl feature. I really don't wanna dig so deep into dvdplayer and as it was implemented it was easy to support other formats without writing much code.
Didn't checked the code yet but think I got it know. I assume regardless if the *.vdr files are local or not they're streamed through the plugin right? didn't thought of that since on my setup vdr and xbmc are on the same server.
Then please let me know what you intend to change to make it more "generic".
I am not that familiar with edl format. Just thought if there was a generic format we could add a ReadEdl method to the PVR api and request edl from the backends like vdr.
what do you think?
The format is different for all backends (see edl.cpp: ReadEdl, ReadComskip, ReadVideoReDo, ReadBeyondTV, ReadMythCommBreakList, ReadMythCutList).
I guess we need to receive the scene cuts/commercial breaks from the plugins and feed it to edl.cpp as dteirney said.
if this can be used both with and without PVR extensions, then it should go into mainline first. there are no pvr api calls to fetch an edl yet, so it would require some changes there first.
I didn't had a look at pvr yet but I doubt this will work. the current edl implementation gets the url of the video from dvdplayer and tries to get the scene cut file from this location via our vfs. if we get all the streams though the pvr plugin the edl class won't know how to access the file afaik.
I assume dteirney already implemented some similar methods for myth to get the cut marks. We could implement that via virtuals and just deliver nothing where it isn't implemented (wouldn't harm the existing plugins). But I have to look at the sources first.
The ultimate solution would be if the plugin could also extend our vfs on runtime. ;)
@anssih it is trivial to make VDR write to a single video file by disabling the file splitting, or alternatively to use the vdrnfofs add-on to expose them via fuse as a single .mpg+.nfo pair
this support for the marks.vdr format should definitely go into xbmc master rather than the pvr branch
@wsoltys are there any plans to rebase this against master?
Nope as we have feature freeze already and this would only make sense together with #1743 and some additions to the vnsi client.