[mythtv-users] Cutlist frames conversion offset?

[Jim Stichnoth]

On Sat, Nov 7, 2015 at 5:39 PM, Mike Atkinson <kdx7214 at gmail.com> wrote:

> I need to maintain closed captions when transcoding.  I'm using MythTV
> 0.28 and right now mythtranscode is not working properly (leaves garbage
> for video and vastly reduced volume on audio).  I've written a little
> script using HandbrakeCLI to reduce file size and transcode, and then
> convert to mkv for use with MythVideo.   I can even add the captions back
> in at any time.  I use ccextractor to convert the captions into an srt file
> just fine.
>
> My problem is this.   When I read the cutlist and convert the frame
> numbers into the hh:mm:ss format I need for the srt file changes, I end up
> with incorrect values.   For example, one of my recordings has a cutpoint
> at frame 45166.   According to the front end, this is at 27:43.852 in the
> recording.  When I do the math, I end up with 27:07.040.  The further into
> the recording you go the worse the difference gets (as much as 8 minutes in
> a 60 minute recording).
>
> I suspect there is some kind of conversion going on with the frame
> numbers, but for the life of me I can't find it.   I tried digging through
> the source thinking that if I could find the code that converts frames to
> hh:mm:ss for the front end display during editing of a recording I could
> figure that out.   A few hours later and I've still not found that code lol
> - I'm sure it's buried in a support lib or something, but damned if I can
> find it.
>
> Anyone able to point me in the right direction to resolve this?   I've
> basically got the entire script completed if I can get this working.
>

 It's possible you're getting bitten by recordings with non-constant frame
rates.  This can happen when the broadcaster splices 720p ads into a 1080i
recording, or vice versa.  And there are other more obscure ways for these
kinds of things to happen.

MythTV deals with this by accumulating the timecode of every frame as it is
recorded (or during mythtranscode or mythcommflag --rebuild), and then
writing out the timecode for every keyframe into the seek table.  You can
access this data using "mythutil --chanid xxx --starttime yyy --getmarkup
mymarkup.xml".  If you look at the resulting mymarkup.xml, you will see
stuff like this:

      <seek data="130931" type="33" frame="3924"/>
      <seek data="256851428" type="9" frame="3969"/>
      <seek data="132432" type="33" frame="3969"/>
      <seek data="258378740" type="9" frame="3998"/>
      <seek data="133400" type="33" frame="3998"/>
      <seek data="260446364" type="9" frame="4030"/>

Ignore the type="9" entries which are for file seek offsets.  The type="33"
entries give mappings between millisecond timecodes (data="130931" ==>
02:10.931) and frame numbers.  Mythfrontend linearly interpolates between
adjacent entries for calculations like "what timecode is frame 3980", which
is pretty much always good enough.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20151107/507ec083/attachment.html>