[mythtv] Looking for doco / data dictionary of mythconverg.RecordedMarkup table
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 /
> 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
# mythutil --getcutlist --chanid 1031 --starttime '2020-07-17 08:10:00'
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev