[mythtv-users] seeking/editing in mythfrontend

Leo Butler leo.butler81 at googlemail.com
Sat Mar 27 16:38:38 UTC 2021

Peter Bennett <pb.mythtv at gmail.com> writes:

> On 3/27/21 8:04 AM, Leo Butler via mythtv-users wrote:
>> John Pilkington <johnpilk222 at gmail.com> writes:
>>> On 27/03/2021 08:26, Stephen Worthington wrote:
>>>> On Fri, 26 Mar 2021 20:50:26 -0500, you wrote:
>>>>> I transcode my recordings to an x264-encoded video stream in a matroska
>>>>> container. I use ffprobe to update the recordedseek table after
>>>>> transcoding. 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 fine.
>>>>> Seeking and playback in fine in vlc and ffplay, fwiw.
>>>>> This seems like a regression to pre v0.28 behaviour.
>>>>> Has anyone seen similar behaviour? Suggestions on how to workaround the
>>>>> problems? Ideas about what caused the regression?
>>>>> TIA,
>>>>> Leo
>>>> Have you tried using the mythcommflag --rebuild option to rebuild
>>>> the
>>>> seek table using the official method?
>>> TTBOMK the MythTV seektable isn't used for playback of files in
>>> matroska format.
>> A seektable is certainly needed for editing and seeking in
>> mythfrontend, although not for playback.
>>> If you somehow create one it may upset things. ISTR that
>>> 'recordings' and 'videos' get different treatment.
>> To clarify: I transcode to mkv and replace the original recording with
>> the mkv.
>> And to repeat, with this method, seeking and editing with the transcoded
>> recordings worked flawlessly until my recent 'upgrade' to
>> v0.31/fixes. That upgrade was caused by the changes at SD and the
>> resulting need to get a current grabber.
>>> I 'transcode' to mythffmpeg  -f mpegts format, which is myth-native
>>> and plays well for me in the frontend or via UPnP or Firestick 4k.
>>> But all my video cutting, mostly from mpeg2 recordings, is
>>> keyframe-based;  I find that acceptable.  I still get the best results
>>> by using ProjectX to demux and sync-adjust before remuxing, but can't
>>> do that for h264.
>> 99.9% of my editing is of mpeg2 recordings, yes. You can find the ffmpeg
>> command (template) on line 405 here:
>> https://git.sdf.org/nb0yjxtr/ffmpeg-mythtv/src/branch/master/ffmpeg-myth.scm
>> The code automatically rounds cutpoints to keyframes (in the right
>> direction on each end of a cut).
>> I don't have any issues with playback quality, just seeking and editing
>> (the transcoding is so good, that I need to use the 'playback data'
>> information to verify that I am watching a transcoded file, not the
>> original). A year or so ago, I did change from the concat demuxer to the
>> concat filter, and that seemed to fix any problems I had seen with video
>> and audio streams going out of sync.
>> Leo
>> _______________________________________________
> Can you clarify, when you say seeking is not working, are you
> referring to seeking while editing? Does the jump forward and back
> during playback still work correctly?

Peter, seeking doesn't work correctly during editing or playback.

In both cases, the information bar indicates the location change, but
the player does not change the location in the video.


More information about the mythtv-users mailing list