[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