[mythtv] Looking for doco / data dictionary of mythconverg.RecordedMarkup table

[John Pilkington]

On 23/07/2020 21:43, Kingsley Turner wrote:
> On 23/7/20 9:11 pm, Roland Ernst wrote:
>>
>> On Fri, Jul 17, 2020 at 10:48 AM John Pilkington 
>> <johnpilk222 at gmail.com <mailto:johnpilk222 at gmail.com>> wrote:
>>
>>     On 17/07/2020 06:11, Kingsley Turner wrote:
>>     > G'day,
>>     >
>>     > I'm trying to understand how the RecordedMarkup cutlist works,
>>     is there
>>     > any doco on this?
>>
>> See https://www.mythtv.org/wiki/Recordedmarkup_table
>>
>>     >
>>     > What does the "PROG START" type indicate?  I would guess it's
>>     the end of
>>     > the first cut (and the cut-start at 0 is not recorded). But then
>>     a few
>>     > seconds later is a "CUT END", and now I'm confused.
>>
>>     I haven't seen this presentation before, but I think 'PROG START'
>>     will
>>     be the 'mythical bookmark' at the start time read from the schedule.
>>     You may want
>>
>>     "mythutil --getcutlist --chanid  $chanid --starttime $starttime"
>>
>>     >
>>     > Video at [2020-07-17 08:10:00] is
>>     [/Video4T1/TV/1031_20200717081000.ts]
>>     > RecordedMarkup.fetch( 1031, 2020-07-17 08:10:00 ) - 24 Markup Items
>>     > 24 Markups
>>     >      Frame 000000 UPDATED CUT
>>     >      Frame 000000 COMM START
>>     >      Frame 000000 DURATION MS = 3943000
>>     >      Frame 000000 TOTAL FRAMES = 98604
>>     >      Frame 000001 ASPECT 16:9
>>     >      Frame 000001 VIDEO WIDTH = 1920
>>     >      Frame 000001 VIDEO HEIGHT = 1088
>>     >      Frame 000001 VIDEO RATE = 25000
>>     >      Frame 004398 PROG START
>>     >      Frame 004585 CUT END
>>     >      Frame 030921 CUT START
>>     >      Frame 035813 CUT END
>>     >      Frame 050072 CUT START
>>     >      Frame 050075 COMM START
>>     >      Frame 054825 COMM END
>>     >      Frame 054837 CUT END
>>     >
>>     > I'm trying to create my own transcoder that can handle MP4 DVB
>>     (as the
>>     > existing one does not seem to), then working it back into the
>>     original.
>>
>>
>> For a transcode task, these bookmarks are of interest:
>> MARK_CUT_END and MARK_CUT_START define the part of the video/recording,
>> which has to be transcoded.
>> MARK_UPDATED_CUT indicates that someone else has updated the cutlist / 
>> markuptable.
>> In this case, the ongoing transcoding has to be stopped and terminated.
>>
> 
> I haven't been making much progress on this.
> 
> I cut a new video to test, and was absolutely careful to only make cut 
> at what MythTV said were "keyframe"s. (I edited the database-ouput text 
> above to match)
> 
> # mythutil --getcutlist --chanid  1031 --starttime '2020-07-17 08:10:00'
> Cutlist: 0-4585,30921-35813,50072-54837,65882-70641,79359-98658
> 
> The keyframe list dumped by FFMpeg does not match that of MythTV. FFMpeg 
> says the key/index frame for the above is ..., 4511, 4579, 4685, 4724, 
> 4828, 4901, ...  obviously the closest is 4579 (to the first CUT END).  
> If I cut with FFMpeg at this point, I get about 5 seconds of video 
> before the MythTV cut.
> 
> I thought that maybe I calculated the Frame-index to seconds incorrectly 
> (FFMpeg wants a start-time in seconds, so you divide the Frame Number by 
> the FPS, e.g.: 4579 / 25 -> 183.16 (seconds)). So I wrote a script to 
> try the cut from every frame from a few seconds before to a few after 
> this point, making a hundred or so 5 second clips.
> The one that looked closest to the MythTV cut-point was at frame 4621 - 
> not in either list as a keyframe.
> 
> The command I've been testing with is:
> ffmpeg -ss 183.16 -ignore_unknown -i /Video4T1/TV/1031_20200717081000.ts 
> -map 0 -map -0:s -t 5 -c:v copy -c:a copy cut-4579.mkv
> 
> According to everything I've read, using a video output of "copy" (-c:v 
> copy) makes FFMPEG only cut at keyframes.  So perhaps it's doing its own 
> seeking no matter what I choose.  Supposedly re-encoding the video 
> allows more accurate non-key-frame cuts, but I think the cut position 
> needs to be correct before worrying about this.
> 
> Sitting here writing this, the numbers are so far out, it makes me 
> wonder if perhaps I'm not looking at the database entries for the wrong 
> recording, but I'm fairly sure that's not it.
> 
> Probably changing 'mythtranscode' to handle DVB MP4 would be the best 
> way forward.
> 
> cheers,
> -kt

I wondered earlier if I should suggest looking at

https://www.mythtv.org/wiki/MythDVBcut

which offers two approaches to cutting h264 content.  One just chops the 
  recorded stream at video keyframes, the other uses ffmpeg in a way 
similar to the one you have tried, passing only one video and one audio 
channel.

Neither will deliver aesthetically perfect internal cutting.  Neither is 
integrated into the MythTV job framework.  Both cut at video keyframes 
and transient effects are likely. The coding and presentation is 
unstylish.  I haven't recently looked to see what else is available. 
But if you really want to do this you might find something useful in 
there.  Good luck... :-)

John