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

Kingsley Turner krt at krt.com.au
Thu Jul 23 20:43:15 UTC 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20200724/ce9b6b2f/attachment.htm>


More information about the mythtv-dev mailing list