[mythtv] [mythtv-commits] Ticket #9556: Updated enhanced cutpoint edit functionality patch

[Jim Stichnoth]

On Mon, Feb 14, 2011 at 5:59 AM,  <noreply at mythtv.org> wrote:
> #9556: Updated enhanced cutpoint edit functionality patch
> -------------------------------------------------+-------------------------
>  Reporter:  Bill Stuff <billstuff2001@…>         |          Owner:
>     Type:  Patch - Feature                      |         Status:  new
>  Priority:  minor                                |      Milestone:  unknown
> Component:  MythTV - General                     |        Version:
>  Severity:  medium                               |  Unspecified
>  Keywords:                                       |     Resolution:
>                                                 |  Ticket locked:  0
> -------------------------------------------------+-------------------------
>
> Comment (by markk):
>
>  Bill
>
>  This is a big patch and I haven't had a chance to try and get it working
>  with trunk, so please forgive me if I've missed something.
>
>  Can you clarify what additional features this adds? (over and above the
>  obvious of providing the extra frames). Implementation details aside, this
>  is a lot of code for what appears to be a small amount of fairly niche
>  functionality - and something that adds additional overhead for a fully
>  completed theme.
>
>  Implementation wise:-
>
>  - I'd personally rather see this displayed and themed as part of the OSD.
>  This seems the most logical place to handle it (we already have the
>  current frame on screen), avoids the extra main UI integration (and the
>  complications involved) and makes it a little more future proof (the
>  implementation of guidedrid etc causes many problems and it needs
>  changing).
>
>  - I'm not sure I see the utility of displaying a series of frames that
>  are, for example, 60seconds apart. frame by frame yes - but otherwise it's
>  just confusing.
>
>  - If you stick to the next and previous X frames, you by and large have
>  these available already - or at least it would take relatively little work
>  to ensure that you have a buffer of 11 frames, and re-position to the
>  middle.
>
>  All told, I think I can see a far simpler solution that hence is more
>  maintainable and, if done properly, requires minimal theming. Unless I've
>  missed the point...
>
> --
> Ticket URL: <http://code.mythtv.org/trac/ticket/9556#comment:2>

I am a heavy user of the program editor, so I am highly interested in
this functionality, which I think should significantly speed up my
manual detection and fine-tuning of edit points.

I haven't tried the patch, but reading through, it looks like it
unnecessarily creates a separate editing screen and duplicates a lot
of existing code.  I agree with Mark that the functionality should be
part of the OSD.  I assume the OSD theme would determine how many
thumbnails to the left and right to display, along with their size,
position, transparency, etc.  The theme could also control how far
apart the frames are, in terms of the current jump amount times a
given multiplier.  For example, if I'm jumping 1 second at a time, I
might want to see thumbnails at half-second intervals, or maybe
2-second intervals.

To address Mark's comment about widely spaced frames.  I often set the
jump distance to 5 seconds and use the 10x button to jump 50 seconds
at a time.  At this granularity, I would definitely like to see
thumbnails at ~5 second intervals and not just a few frames apart.

One comment on performance.  HDPVR recordings tend to have 100+ frames
between keyframes.  ION VDPAU decoding of h.264 isn't much faster than
real-time, so it often takes 1 second to jump in the program editor.
It wouldn't be good to multiply that by 5-7x due to thumbnail
generation, so hopefully the thumbnails can be created in the
background by a separate thread.

Jim