[struct]

This sounds pretty cool.

[Harry Muscle]

I've created a ticket to add the code for the new file format ... in case anyone is following this: http://trac.xbmc.org/ticket/10182

The new file format I'm proposing ends in .xdl (XBMC EDL) and is formated like:
START END ACTION

This is similar to the MPlayer EDL, but my format allows significantly more flexibility.

START and END can be one of the following:
FrameNumber
Seconds.Milliseconds
MM:SS.Milliseconds
HH:MM:SS.Milliseconds

START and END are independent of each other, so START can be a frame number and END can be Seconds.Milliseconds and everything will be fine (as long as START comes before END that is).

ACTION can be one of the following
f -> Frame Rate
a -> Audio Mute
v -> Video Blank
av -> Audio Mute and Video Blank
s -> Scene Marker
c -> Commercial Skip

For Scene Markers it expects only the START value no END, since a scene marker is based on only one time/frame index.

Also if there's an error on any one line, the code will skip the line and continue with the rest of the file (unlike the other currently implemented file formats).

If anyone has any feedback, suggestions, etc. feel free to let me know.

Thanks,
Harry

P.S. Example of file:

1234 1:23:45.678 av
33.444 123456798 c
9999 s

The above file would specify that from frame 1234 to 1 hour 23 Minutes 45 seconds and 678 milliseconds is an Audio and Video skip. Then from 33 seconds and 444 milliseconds to frame 123456789 is a commercial skip. Then frame 9999 is a scene marker.

This illustrated the flexibilty of the file, although most users would probably stick to one format for START and END like the following example with all frame number information:

1111 2222 av
3333 4444 c
5555 s

EDIT: Added support for specifying frame rate information in the file. The acton character for this is f. So it would look like this in the file:

23.978 f

You just have to make sure you have this line before any other lines that contain frame numbers.

[Harry Muscle]

Once the above patch get's accepted I'm thinking I'm gonna work on allowing errors in all the different EDL files and not having the whole file rejected (like mentioned by Nick8888) just reject the line with the errors.

Then I'll probably move onto implementing the audio muting and maybe the video blanking. Next we'll hopefully move onto making things pretty. Maybe have all the cut points show up on the progress bar (again like mentioned by Nick8888) or something like that.

Thanks,
Harry

[kricker]

So exactly how would one do all this EDL creation? Will there be some sort of way to make these edit points while watching the video in XBMC?

[Harry Muscle]

So exactly how would one do all this EDL creation? Will there be some sort of way to make these edit points while watching the video in XBMC?

Eventually that would be a nice feature to implement. In the mean time, the new XBMC EDL file is designed to be easily created by hand with a plain text editor. The hard part right now is figuring out which frame/time you wanna skip. But that can be done with all sorts of video editors. One very nice one (that's also free) is AVIDemux, which is what I'm currently using to come up with edit points to test against, etc. Basically you find the points you wanna edit and they copy and paste the time or frame info into a text EDL file.

Thanks,
Harry

[Flomaster]

where does this text file reside in?

the movie folder along with the nfo's, folder.jps etc?

-=Jason=-

[Harry Muscle]

where does this text file reside in?

the movie folder along with the nfo's, folder.jps etc?

-=Jason=-

That's correct. Here's a bit more info on EDL in general from the wiki: http://wiki.xbmc.org/index.php?title=EDL . Once this new file format gets accepted into the XBMC code I will add info to the wiki about this new format. But basically you create a new file with the same name as the movie but with an xdl extension. Then you edit it with a text editor and put in the info as outlined a few posts back.

Thanks,
Harry

[Nick8888]

nice progress! I do have one question though. Does it need a new extension? Considering there is already a significant amount of edl varieties, what is one more? I'm specifically worried it may end up being more work in the long run and less user friendly.

For example, what is the expected behaviour if both an edl and xdl exist?

Others may disagree though so I thought it was worth asking.

[Harry Muscle]

nice progress! I do have one question though. Does it need a new extension? Considering there is already a significant amount of edl varieties, what is one more? I'm specifically worried it may end up being more work in the long run and less user friendly.

For example, what is the expected behaviour if both an edl and xdl exist?

Others may disagree though so I thought it was worth asking.

The problem with all the existing EDL file formats is that not a single one of them allows you to specify frames and cuts. The closest we get is frames and commercial skips (which are handled differently from cuts and wouldn't allow frame accuracy). So to achieve frame accurate cuts the first step was to create a new file format that allows us to specify just that (plus a bunch of other stuff if we want).

As for the case of multiple files, like edl and xdl, the code will stop looking for further files once it finds one. I don't remember the order off the top of my head, but I stuck the xdl files in front of all the others, since I'm hoping this will become the build-in format and it would only makes sense it would take priority over other files. So the edl file would be completely ignored if it finds an xdl file.

Thanks,
Harry

P.S. I just reread your comments, were you referring to just the new extension ... or in other words suggesting we keep the .edl extension but support a more advanced format inside than currently? We could do that, but that would break support for the existing .edl files, which I didn't wanna do, no real reason, I just assumed it's better to add than remove. But that might be an idea, I'll wait to see what comments I get on the trac ticket and mention your proposal if it seems appropriate.

EDIT: You got me thinking and I think there is a way for us to use the .edl extension for the new format and still keep support for the existing .edl files.

[Nick8888]

Yes, I was under the impression xbmc already supported many different edl file formats, however upon rereading the wiki I realised they all do infact have their own file extension.

1. The Matrix.Vprj (VideoReDo)
2. The Matrix.edl (MPlayer EDL)
3. The Matrix.txt (Comskip)
4. The Matrix.avi.chapters.xml (SnapStream BeyondTV)

Only one *.edl file format is supported. Also of note, there is an .edlx as well which is an xml based edl, not currently supported by xbmc. It would be nice if everyone could decide on a unified approach.

I do like your proposed format. I was just curious as to whether it was best achieved by creating a new file extension. Is it something that could even be included in the .nfo ?

[KidKiwi]

Wow...this sounds really great. I discussed this possibility several years ago - wanting a way to access certain points in the video (like a chapter point directly after the title sequence), but at that point EDL wasn't that developed. I use DVDremakepro to add chapters etc where I want them, but it is NOT frame accurate (closet I frame I think) and it means triple handling them to get them ready for the NAS. This sounds like it'll fit the bill for me.

...Will there be some sort of way to make these edit points while watching the video in XBMC?

This would be great as well, but getting xbmc to be frame accurate sounds like a challenge.

[Harry Muscle]

Yes, I was under the impression xbmc already supported many different edl file formats, however upon rereading the wiki I realised they all do infact have their own file extension.

1. The Matrix.Vprj (VideoReDo)
2. The Matrix.edl (MPlayer EDL)
3. The Matrix.txt (Comskip)
4. The Matrix.avi.chapters.xml (SnapStream BeyondTV)

Only one *.edl file format is supported. Also of note, there is an .edlx as well which is an xml based edl, not currently supported by xbmc. It would be nice if everyone could decide on a unified approach.

I do like your proposed format. I was just curious as to whether it was best achieved by creating a new file extension. Is it something that could even be included in the .nfo ?

Where did you find info about edlx files? Tried googling it but didn't find much. Also I would think manually creating xml files isn't gonna be as easy as my proposed format, but it doesn't hurt to check into this format.

So do you guys think we should stick with using a new file extension to differentiate things? I'm sort of sitting on the fence whether to use .edl and have the code figure out which format the file actually is or just use the new .xdl extension.

Thanks,
Harry

EDIT: I'm starting to lean towards my original idea of creating a new file extension for this new file format. Sure it adds an extra file type, but I think it will avoid confusion in the end, since we won't have two possible file layouts for the same .edl file type. And like you mentioned, all the other supported file types each have their own extensions.

[Harry Muscle]

I've uploaded an updated patch to the trac ticket. Did a bunch of code streamlining and I also added support for specifying the frame rate of the file, in case XBMC doesn't detect it correctly. So there's now the extra option of doing this in the file to specify the correct frame rate:

23.978 f

You just have to make sure you have this line before any other lines that contain frame numbers.

Thanks,
Harry

[dteirney]

@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.

[Harry Muscle]

I'm glad we got your attention dteirney ... thanks for all the feedback.

My goal in designing the new file format was to have the most flexibility possible, which is why I wanted to be able to specify the start and end times in pretty much any format possible. Currently I use AVIDemux to figure out the cut points and it provides me with either HH:MM:SS.MMM or frames numbers, both of which needed a manual conversion to be useful in any of the existing supported files (also my frame calculations were never perfect since AVIDemux and XBMC detect ever so slightly different frame rates for the same video). I created the new format with the idea that no matter which video editor the user might be using they will be able to simply copy and paste the info from the video editor into the new EDL file without having to break out the calculator and convert figures. Then I just simply switched from using 0, 1, 2, 3 to something more descriptive.

As for the option of doing only a video blank ... well I'm not 100% sure what the use would be, but again, was going for maximum flexibilty and I figure someone could find a use. The only one I can think of is if there's dialogue in a movie that's important to the story, but it's happening in a child inappropriate place with inappropriate "scenery" in the background.

I'm guessing though that you wanna keep things simpler to avoid confusion, etc. The way I figure, we have a couple of options:

1. Leave things as currently proposed with a new .xdl file format

2. Create a new file with the extension .edlf that's identical to the existing .edl file format but instead of seconds uses frame numbers

3. Create a new file with the extension .edlf that's a combination of the two above ideas. It allows only frames for start and end times, but allows either 0, 1, 2, 3 or a, v, s, c for the action making it somewhat more user friendly to create and not mess up by using the wrong number (or the user can stick with the numbers if they so prefer). Also this would allow the f action to specify the frame rate for the movie in case XBMC detects it wrong. We could forget the av action and simply make v specify both audio and video blank so all actions would be one character to keep more in line with the existing EDL file format. Personally this is as simplified as I would prefer to go since it still allows for a decent amount of flexibility.

4. Don't create a new file extension but instead incorporate the new format ideas into the existing .edl file. So if the file has a 0, 1, 2, 3 action specified treat the start and end fields as the old EDL file format, but if it has one of the new letter actions specified allow full flexibility for start and end times, etc. This would be a good solution for instances where a user might already have existing EDL files, but wants to edit or update then using the new format. The code would allow both types in the same file so the user can simply append to the existing EDL file using the new format.

There's probably another option or two that's possible and if anyone can think of one feel free to propose it. Also anyone who's reading this feel free to comment on which format you would prefer, etc.

Dteirney let me know which one you like, since I think it'll be your call anyway since I'm guessing you'll be the one to approve the patch

Thanks,
Harry