seeking/editing in mythfrontend
Moderator: Forum Moderators
seeking/editing in mythfrontend
I use ffmpeg to transcode my recordings to an x264-encoded video stream in a matroska container. I use ffprobe to update the recordedseek table after transcoding, and update the entry in the recorded table so that I can watch the transcoded recording in Recordings. I have been doing this for a couple years.
In both v0.28 and v0.29 (from the mythbuntu ppa), I was able to seek and edit these mkv files without difficulty. In v0.31/fixes from the same ppa, seeking and editing is broken for these transcoded files--it appears that any movement in the video is only by a keyframe. Playback is otherwise fine.
Seeking and playback are fine in vlc and ffplay. This is true if I move the file to Videos, too (I don't know about editing, because it lacks a seektable).
This seems like a regression to pre v0.28 behaviour.
Has anyone seen similar behaviour? Ideas about what caused the regression?
At the moment, I have re-worked my transcoding to use an mpegts container, and that works ok, but I really prefer the matroska, so I would like to know how to fix the problem.
TIA,
Leo
(I posted this to the mythtv email list at the end of March
http://lists.mythtv.org/pipermail/mytht ... 06779.html.)
In both v0.28 and v0.29 (from the mythbuntu ppa), I was able to seek and edit these mkv files without difficulty. In v0.31/fixes from the same ppa, seeking and editing is broken for these transcoded files--it appears that any movement in the video is only by a keyframe. Playback is otherwise fine.
Seeking and playback are fine in vlc and ffplay. This is true if I move the file to Videos, too (I don't know about editing, because it lacks a seektable).
This seems like a regression to pre v0.28 behaviour.
Has anyone seen similar behaviour? Ideas about what caused the regression?
At the moment, I have re-worked my transcoding to use an mpegts container, and that works ok, but I really prefer the matroska, so I would like to know how to fix the problem.
TIA,
Leo
(I posted this to the mythtv email list at the end of March
http://lists.mythtv.org/pipermail/mytht ... 06779.html.)
Re: seeking/editing in mythfrontend
Hi Leo,
As this seems to be a bug, I suggest that you create a Github issue for this. That will at least make certain that it is not forgotten, which unfortunately does happen occasionally when issues cannot be resolved immediately. The Github issue list is the poster board where devs can look at whenever they are bored.
Thanks,
Klaas.
As this seems to be a bug, I suggest that you create a Github issue for this. That will at least make certain that it is not forgotten, which unfortunately does happen occasionally when issues cannot be resolved immediately. The Github issue list is the poster board where devs can look at whenever they are bored.
Thanks,
Klaas.
- Steve Goodey
- Moderator
- Posts: 220
- Joined: Fri Feb 07, 2014 6:30 pm
- Location: Colchester, England
Re: seeking/editing in mythfrontend
... devs can look at whenever they are bored.
Don't forget the Wiki.
Re: seeking/editing in mythfrontend
Thanks, Klaas. I have filed a bug report https://github.com/MythTV/mythtv/issues/353.
Last edited by leobutler on Mon Apr 12, 2021 12:10 am, edited 1 time in total.
-
- Senior
- Posts: 265
- Joined: Sun Jun 15, 2014 1:08 am
Re: seeking/editing in mythfrontend
I recall the decision was to NOT generate seektables for mkv containers.
The fact it did work was an oversight.
[Myth]FFprobe does not update any seektable, do you refer to mythcommflag --rebuild ..
MKV design was meant to be be so clever it did not need a seektable shame about the timebase deficiencies.
MPEG-TS probably is the better container.
The fact it did work was an oversight.
[Myth]FFprobe does not update any seektable, do you refer to mythcommflag --rebuild ..
MKV design was meant to be be so clever it did not need a seektable shame about the timebase deficiencies.
MPEG-TS probably is the better container.
Re: seeking/editing in mythfrontend
The issue is not about seektables per se, but the mythfrontend playback of mkv containers. In Videos, seeking works correctly (without a seektable) as I wrote, but in Recordings neither seeking nor editing works (with or without a seektable).blm-ubunet wrote: ↑Sun Apr 11, 2021 7:03 pmI recall the decision was to NOT generate seektables for mkv containers.
The fact it did work was an oversight.
[Myth]FFprobe does not update any seektable, do you refer to mythcommflag --rebuild ..
MKV design was meant to be be so clever it did not need a seektable shame about the timebase deficiencies.
MPEG-TS probably is the better container.
I use some handwritten scheme code to do the transcoding and updating of the mythconverg database. And I need to use ffprobe to generate the data for the recordedseek table, because mythcommflag does not understand matroska containers (and it also fails with libx265+mpegts). With a seektable, in v0.29, I could edit mkv files using the mythfrontend player.
For my purposes, matroska is much better than mpegts, but I can understand that preferences differ.
Re: seeking/editing in mythfrontend
MythTV has never created or used mkv files for recordings so I'm with blm-ubunet on this one if it ever did work it was a fluke and not by design
Also are you sure ffprobe is creating the seek tables that doesn't sound possible
Also are you sure ffprobe is creating the seek tables that doesn't sound possible
Re: seeking/editing in mythfrontend
Paul, what you say may be true, but why would the video player and recordings player treat these mkv files differently?
After transcoding, I use ffprobe to extract the i-frame data, and update mythconverg's recordedseek and markup tables from that.
See https://git.sdf.org/nb0yjxtr/ffmpeg-myt ... h.scm#L515
Leo
-
- Senior
- Posts: 265
- Joined: Sun Jun 15, 2014 1:08 am
Re: seeking/editing in mythfrontend
I figured out later that you must be generating the keyframe offsets with external tool & stuffing back into DB.
That's a clever trick..
That might only work for video & audio packets without byte offsets.
Almost all broadcast mpeg-ts has an offset in AV packets (with same PTS) & never uses IDR I frames..
AIUI Mythtv uses the first video packet as time zero, almost all other AV software (mkvtoolnix, vlc etc) uses the first (earliest PTS).
I've struggled to find a ffmpeg/ffprobe/mediainfo cmd to extract that offset.
Mythtv's recorder needs a parser to find keyframes.
And the H265 parser has only just been added (I think).
You can generate seektables for videos.
But something about playback must have changed..
That's a clever trick..
That might only work for video & audio packets without byte offsets.
Almost all broadcast mpeg-ts has an offset in AV packets (with same PTS) & never uses IDR I frames..
AIUI Mythtv uses the first video packet as time zero, almost all other AV software (mkvtoolnix, vlc etc) uses the first (earliest PTS).
I've struggled to find a ffmpeg/ffprobe/mediainfo cmd to extract that offset.
Mythtv's recorder needs a parser to find keyframes.
And the H265 parser has only just been added (I think).
You can generate seektables for videos.
But something about playback must have changed..
Re: seeking/editing in mythfrontend
That would be an important point to put on the issue. We wouldn't want a dev spend days tracking down the problem only to find later it was down to something like this would weleobutler wrote: ↑Mon Apr 12, 2021 8:08 pmAfter transcoding, I use ffprobe to extract the i-frame data, and update mythconverg's recordedseek and markup tables from that.
See https://git.sdf.org/nb0yjxtr/ffmpeg-myt ... h.scm#L515