[mythtv] Using the cut list editor and future plans (was Re: [mythtv-commits] mythtv commit: r26111 - in trunk/mythtv by mdean)

Michael T. Dean mtdean at thirdcontact.com
Fri Sep 10 19:15:54 UTC 2010


  Sorry.  This turned out to be a long post--even for me.  :)  It does, 
however, provide all the information I found when writing the code 
originally and the approach I'd like to take for the future code.

On 09/10/2010 11:21 AM, Jim Stichnoth wrote:
> I've been playing around with the new editor for a while now.  I have
> found a couple of things that are hard to do, because the editor is
> based on the notion of "cut areas" and doesn't have a symmetric notion
> of "preserve areas".
>
> Example 1.  Load the commskiplist, then find that a small preserve
> area is actually part of the commercial break and you'd like to merge
> it with the surrounding cut areas.  I.e., turn a "red,green,red"
> section into solid "red".  This would be easy if the DELETE key
> binding / menu item worked symmetrically for preserve areas.  (After
> writing this, I figured out that I could do this easily enough by
> moving to the beginning of the first cut area, deleting the cut area,
> and finally "move next cut start here".)

Right.  Or the opposite--go to the end of the 2nd area, delete the cut, 
and move previous cut end here.

You /could/ go to the frame before the first cut area and add a cut, 
then go to the frame after the second cut area and finish the cut--but 
it will also add an extra frame on each side of the cut.  In other 
words, new cut areas can span one or more existing cut areas without 
problems.

> Example 2.  Load the commskiplist, then find that the commflagger has
> determined a section of the program to be part of the surrounding
> commercial breaks.  I.e., you want to break up a solid "red" section
> into "red,green,red".  This happens especially often for the final
> 30-second bit of a sitcom, which the commflagger considers to be part
> of the commercials.  I haven't found a way to break up the cut area
> and insert a preserve area, without losing one end of the original cut
> area.  It seems that if SELECT (or some menu item) would allow
> temporary marks to be added within a cut area and not just within a
> preserve area, this problem would be solved.  Another approach would
> be a "Split Cut Here" operation that you do at one end of the new
> preserve region, then move to the other end and move the appropriate
> cut mark there.

History:

I originally had some stuff to add an "uncut" area to a cut, but it made 
the menu bigger, and wasn't very easy to use.  The original code added 
an area (rather than a temporary mark).  When you add a finite area, it 
turned out that the end always seemed to end up in a bad spot that 
required some adjustment.  And adjustment--requiring the user to specify 
which point to move--is more challenging than adding a new cut 
(requiring use of the menu).  So, I modified the approach to use the 
temporary marker approach, allowing SELECT, move (either direction), 
SELECT to define a cut area--which turned out to be significantly easier 
to use.  When I did this, I removed the code to add an uncut area to a 
cut area.

I decided not to allow any temporary marks within cut regions because I 
didn't know how to handle the things that users shouldn't do.  For 
example, you add a (temp) cut mark to an uncut area, then go to a cut 
area and try to add a cut, so now what do we do?  Or, you add a (temp) 
cut mark to a cut area, then go to an uncut area and try to add a cut.  
Where is the start and end--on the cut marks you added or do we include 
the cut area beyond?  What about all the middle cut starts and ends, 
when the defined section spans multiple cut areas?  Even if we add code 
that prevents the user from adding a cut mark when the temp mark is in 
the "other" area (cut/uncut), it seems only to add confusion to the 
process--"Why can't I add a cut mark here?"

The only behavior I was comfortable with was to remove the original temp 
cut marker from the "other" area and just put a new (temp) cut marker at 
the current position--so, basically undo the previous cut start and make 
the current frame a cut start.  That approach, however, "loses" the 
original marker (just like the approach I went with--next paragraph).  
So, it seemed that the additional confusion caused by allowing for 
adding an uncut area wasn't worth the benefit--especially since 
uncutting sections seems to be a not-so-frequently-needed function.

So the approach I went with was to disallow markers within cut areas.  
If you have a too-large cut area that needs split into 2 sections, you 
can go, for example, to the end of the first cut area, then move cut end 
to here.  Then skip your 30s forward and add a new cut (or cut to 
beginning/end--which is almost always where you'll need this around 
here, at least) and then find the end of it and finish the cut.  If the 
commercial detection missed that this was actually 2 breaks, chances are 
you would have needed to do some adjustment of the final frame, anyway.  
But, there's a better way...


For the future (a.k.a. how to get all the functionality you want and more):

The approach I'd prefer to use to prevent our "losing" the mark the 
commercial flagger found is not to add new editing controls--requiring 
users to choose from among more tools and forcing them to think even 
harder when editing.  Instead, the crux of your concerns seems to be 
"losing a mark."  In reality, nothing was lost here--we simply removed a 
cut mark that we had artificially created from other data.

So, I'd like to modify the cut list editor to allow new modes for 
seeking within the video and modify the UI to optionally show other 
(non-cut) marks (toggled with a menu--and, likely, using a different 
color or marker or whatever the themer chooses, and showing "commercial" 
or something other than "cut" when in an area).  Then, the user would 
use up/down to change the seek amount to "Detected Commercial Breaks" 
and could seek to the MARK_COMM_* marks.  I'm not yet sure whether the 
NEXTCUT and PREVCUT bindings should include these other marks and cut 
marks or only one style of mark, but it should be easy enough to decide 
once implemented and tested.

Then, if modified this way, uncutting an area from a too-large 
commercial break found by the flagger would consist of finding the end 
of the first break, selecting move cut end to here, then finding the 
start of the next break, starting a cut, then changing the seek to 
"Detected Commercial Breaks" and seeking to the next marker to set your 
cut end.

This is also the approach I'd like to use to allow the "snap to black" 
behavior Preston Crow talked about in this thread.  We would modify the 
commercial flagger to store a mark(s) for every section of blank 
frames*** (if you've enabled blank frame detection), as well as storing 
its usual flag list.  Then, users would be allowed to jump to the next 
or previous blank frames.  And, for that matter, mythcommflag could be 
modified to insert any other also-useful-later markers, and the editor 
could allow navigating with them.****

In addition, we could allow seeking to bookmarks (where multiple 
bookmarks will be allowed after some changes I have in progress), and 
whatever other***** good ideas people come up with.

Mike

*** I don't know enough about the commercial flagger to determine 
exactly how these blank frame markers would be added.  If they're 
typically a series of multiple blank frames, it could set a start and 
end frame.  If they're commonly single, it could set a single mark.  If 
they're commonly between every commercial, it could set them only before 
the first/last commercial or between each.

**** FWIW, I'm thinking these "additional" seek types should be beyond 
the "Cut Point" seeks and away from the time-based amounts--i.e. added 
at that end of the list so that users who don't care to use them won't 
see a difference in behavior/order of seek types.  Also, I'm thinking 
that when you select one of these non-time/non-cut-point seek types, 
that type would be automatically toggled to display on the OSD.

***** Not to imply that any of the above ideas are definitely good 
ideas--that will be determined by others' response to the ideas.


More information about the mythtv-dev mailing list