[mythtv] Ticket #8631: Treat cutlists like lossless transcoding
Jim Stichnoth
stichnot at gmail.com
Sun Nov 28 01:35:22 UTC 2010
On Thu, Nov 25, 2010 at 11:13 PM, MythTV <mythtv at cvs.mythtv.org> wrote:
> #8631: Treat cutlists like lossless transcoding
> ------------------------------------------------+---------------------------
> Reporter: Jim Stichnoth <stichnot@…> | Owner: mdean
> Type: enhancement | Status: assigned
> Priority: minor | Milestone: unknown
> Component: MythTV - General | Version: Unspecified
> Severity: medium | Resolution:
> Keywords: | Ticket locked: 0
> ------------------------------------------------+---------------------------
>
> Comment (by markk):
>
> I'm going to go 'on record' and state that I don't think this patch should
> be committed.
>
> Firstly, I personally find it counterintuitive to display a different
> program duration (or position) from the actual, known value. The potential
> for confusion is huge.
>
> Secondly, any confusion can only be mitigated by themers competently using
> the extra information available. Given that this is only likely to be a
> niche feature, I can see few themes actually doing that.
>
> Finally, it adds a level of complexity to the playback code that we could
> really do without. We are trying to make this code simpler and more
> understandable and the 'cost' here does not outweigh the 'benefit' in my
> opinion.
>
> --
> Ticket URL: <http://svn.mythtv.org/trac/ticket/8631#comment:5>
I disagree about the intuitiveness of the display. If I edit the
program, I think it makes perfect sense for it to appear that the cut
sections are actually gone. In fact, if I go on to transcode the
recording, exactly this happens. I'm admittedly biased, but I *love*
that I don't have to guess how much of the program is remaining.
I partially agree about the theming issue. While it's trivial for a
themer to use the appropriate strings, it does require particular
keybindings for full consistency, which the themer currently has no
control over.
As for code complexity, this patch only provides a cutlist-based
mapping between frame numbers and display times or relative seek
times, and doesn't touch what I thought is the underlying complex
code, e.g. AVFD.
I realize I don't have much say, but before closing this ticket, I
would make a suggestion, using #9109 as a motivation. The solution to
#9109 introduces a new inconsistency: in recordings with varying frame
rates, seeking is no longer consistent. E.g., jumping forward 10
minutes may end up jumping only 8 minutes, or perhaps 12 minutes. To
get consistent time display and seeking, myth needs to maintain a list
of frame rate changes in a recording. This would presumably be done
during recording, or in something like mythcommflag. Once this list
is available, a cut region could be treated as a section with a frame
rate of infinity. In other words, if #9109 is extended to provide
seeking that is consistent with proper time display, then cutlists can
be easily folded in.
Jim
More information about the mythtv-dev
mailing list