Mailing List Archive

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?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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. If you somehow create one it may upset things. ISTR that
'recordings' and 'videos' get different treatment.

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.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 27/03/2021 01:50, Leo Butler via mythtv-users 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

... replying to your original question: have you tried the different
decoder options (Frontend Setup > Video > Playback) when trying to do
precision editing? I don't know how many of the changes there in the
last year have reached your setup.

And it occurs to me that I ought to look at this in relation to my
current 20-second 'hanging' inconveniences in DVB-radio cutting.

John P

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Stephen Worthington <stephen_agent@jsw.gen.nz> writes:

> 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?

Of course. Mythcommflag does not recognize any keyframes for a video
stream in a matroska container:

mythcommflag --chanid=1112 --starttime=20170312041000 --rebuild

MythTV Commercial Flagger, building seek table for:
Blue Bloods - Family Business
Rebuild started at Sat. Mar. 27 06:36:53 2021
Rebuild completed at Sat. Mar. 27 06:38:27 2021

2021-03-27 06:36:52.126955 C
mythcommflag version: fixes/31
[v31.0+fixes.202103051941.6c7c8b0351~ubuntu20.04.1] www.mythtv.org
2021-03-27 06:36:52.126975 C Qt version: compile: 5.12.8, runtime:
5.12.8
No I-frames found, rewinding...
2021-03-27 06:38:27.387359 E decoding error End of file
(-541478725)

Leo
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

John Pilkington <johnpilk222@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
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 3/27/21 8:04 AM, Leo Butler via mythtv-users wrote:
> John Pilkington <johnpilk222@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


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

John Pilkington <johnpilk222@gmail.com> writes:

> On 27/03/2021 01:50, Leo Butler via mythtv-users 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
>
> ... replying to your original question: have you tried the different
> decoder options (Frontend Setup > Video > Playback) when trying to do
> precision editing? I don't know how many of the changes there in the
> last year have reached your setup.

I don't see anything relevant there.

Maybe I didn't make myself clear, though. The problem that I am having
is this:

-I can create a seektable for a transcoded recording which mythtv
recognizes and understands;

-During playback, I can try to seek forward or backward. Mythfrontend
records the changed location on its information bar, but the playback
remains at the same spot in the file.

-Similar behaviour occurs when I enter the editor.

Before the upgrade, in v0.29, both seeking and editing worked
'naturally' for these transcoded files.

Leo
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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

> On 3/27/21 8:04 AM, Leo Butler via mythtv-users wrote:
>> John Pilkington <johnpilk222@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.

Leo
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

John Pilkington <johnpilk222@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. If you somehow create one it may upset things. ISTR
> that 'recordings' and 'videos' get different treatment.
>
> 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.

Re: -f mpegts.

I tried the following experiment. I cut a matroska container and remuxed
it to mpegts and matroska separately. I rebuilt the seektable for the
mpegts container. Seeking (in the editor or playback) works fine with
that video.

But...the file size of the mpegts is 9.5% larger than the mkv. That
9-10% overhead seems consistent across a few other recordings that I
have remuxed, too.

Leo
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 27/03/2021 17:17, Leo Butler wrote:
> John Pilkington <johnpilk222@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. If you somehow create one it may upset things. ISTR
>> that 'recordings' and 'videos' get different treatment.
>>
>> 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.
>
> Re: -f mpegts.
>
> I tried the following experiment. I cut a matroska container and remuxed
> it to mpegts and matroska separately. I rebuilt the seektable for the
> mpegts container. Seeking (in the editor or playback) works fine with
> that video.
>
> But...the file size of the mpegts is 9.5% larger than the mkv. That
> 9-10% overhead seems consistent across a few other recordings that I
> have remuxed, too.
>
> Leo
>
Yes. I have recently been recording from 'Sky Arts' which became
available via Freeview UK last September, so although it's mainly
repeats they are new to me. Format is 544x576 mpeg2 progressive, but
seems adequate. The recordings often show a surround-sound icon but
it's joint stereo at 128kb/s. When cut, concatenated and sync-adjusted
by ProjectX, mythffmpeg .ts output shows a muxing overhead around 5.5%,
which is higher than I used to get with mplex and a near-DVD output
format. I guess the overhead is there in .ts for better potential
recovery of transmission errors.

Peter's leanfront player used to stutter on most files in the mplex
format, and long ago I was told that mplex would fail at high bitrates.
I haven't tried them together recently, but the .ts files play flawlessly.

I mentioned the decoder setting because it does (or did) affect stepping
in the editor. If I used nvdec, in one direction only alternate key
presses were effective. And h264 still-frames were blurred...

John P
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org