[mythtv-users] Cutlist frames conversion offset?

Mike Atkinson kdx7214 at gmail.com
Mon Nov 9 02:53:11 UTC 2015


That was the part I was missing.  Thanks!

On Sat, Nov 7, 2015 at 11:17 PM, Jim Stichnoth <stichnot at gmail.com> wrote:

> 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
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20151108/7d337d96/attachment.html>


More information about the mythtv-users mailing list