@
Harry and others, thanks for your interest and enthusiasm in this area. Some specific comments below. I don't get much time to look at XBMC stuff at the moment. Thanks to jmarshall for alerting me to all this great discussion.
@
Harry
re "For short skips it might take longer to seek to the end of the skip than to just play the frames (ie: a skip of 5 frames for example). So for short skips I would just blank the screen and add a small blurb about what's happening (sort of like what happens when XBMC has to buffer). I also would like to add the ability to skip just video, just audio, or both which would allow editing swearing, etc." -> the EDL support in DVDPlayer already hard drops (discards) frames for short cuts, i.e. < 10 seconds. The seeking should be full frame accurate, e.g. the previous reference frame is found and decoded forward from there to the seek point.
@
Nick8888
re "better visibility of edl existence (perhaps on the progress bar)". Yes, this would be awesome. Apparently this is non-trivial though. I bought this up with the dev team a while ago. Requires some Skinning/UI Rendering Engine support I believe. Perhaps raise a separate Trac ticket for this enhancement.
re "display all valid cuts. At the moment if the edl contains an invalid cut then the whole edl is disregarded." -> This is how the existing behavior was. It's debatable whether that was the right approach to take, but most of the file formats are generated by 3rd party commercial detection tools so should never have invalid cuts. Another option could be to somehow better alert the user that there was a problem with the EDL file. It's easy to change the code to be more lenient and ignore errors, but I'm not sure that is actually the right approach.
re "comskip integration with the pvr section". I'm not sure how the PVR playback will work this out - haven't looked at that branch yet. The existing myth:// protocol support already loads the commercial breaks for the recording from mythbackend.
@
Harry
re "There was a rounding error in the edl code that led me to believe that the EDL code isn't accurate enough, but I think it might be. I'll submit a patch to fix the rounding error right away" -> please submit a separate patch for the rounding error. I can't see any change in the trac patch that relates to rounding errors.
re "Like I thought, all that seems to be needed is a better file format that allows us to specify frames and cuts." -> A solution for this would be to use the existing .edl file format and semantics but treat the input "time" as a frame marker rather than a "time", perhaps with file extension .edlf. It doesn't appear that there is a great need for a file format that can read both frame markers and times. I would have thought that the creator of the file would want to choose to use times or frame markers.
re "Then I'll probably move onto implementing the audio muting and maybe the video blanking" -> I think looking at the audio muting would be a great thing to do. I don't know anything about how this would be done through DVDPlayer. Most of the EDL work that I did ages ago was to fix the playback behavior to properly support cuts in DVDPlayer and fix some of the logic in the EDL related classes to support that, and added support for commercial break skipping.
re "v -> Video Blank" -> what would people use this for?
@
kricker
re "So exactly how would one do all this EDL creation?" -> Most EDL files are generated by tools or manually. It would be great if the existing XBMC Video Bookmark capabilities, which effectively the same as Scene Markers, could be leveraged somehow. Maybe someone could look at pushing any Scene Markers within an EDL file to the XBMC Video Bookmarks (
http://wiki.xbmc.org/index.php?title=Vid..._Bookmarks). That could possibly be useful for flagged commercial breaks, e.g. XBMC could show the Video Bookmarks as the end of each flagged commercial break.
@
Harry
re "The closest we get is frames and commercial skips (which are handled differently from cuts and wouldn't allow frame accuracy)" -> The automated skipping / seeking for commercial breaks is identical to cuts so is just as accurate. The difference with commercial breaks is that they aren't physically removed from playback, e.g. you can rewind after the seek is performed and actually see what was skipped. Cuts are always seeked over, so rewinding will skip over them.
Summary:
My preference would be that the XBMC community doesn't completely make up a new file format. I would prefer to see the .edl file semantics continue to be used, but with a modification to specify frame markers instead of times if the community really sees this as necessary. Note though that XBMC EDL support in DVDPlayer is always going to be time based. Frame markers are simply converted to times internally based on the fps of the content. The seeking API in ffmpeg (as I understand it) does not support frame based seeks.