[mythtv-users] Problems when streaming from a web site

[Stephen Worthington]

On Sun, 6 Nov 2022 11:32:12 -0500, you wrote:

>
>On 11/6/2022 9:46 AM, Stephen Worthington wrote:
>> On Sun, 6 Nov 2022 08:39:17 -0500, you wrote:
>>> On 11/5/2022 10:02 PM, Stephen Worthington wrote:
>>>> On Sat, 5 Nov 2022 21:03:24 -0400, you wrote:
>>>>> The external tuner uses this ffmpeg command on reading:
>>>>>
>>>>> [RECORDER]
>>>>> command="ffmpeg -hide_banner -nostats -loglevel fatal -re -i %URL% -c:v
>>>>> copy -c:a copy -f mpegts -"
>>>>
>>> 1.mythcommflag --rebuild -f %FILE%
>>> Didn't work. Now when I skip ahead it says 0 length and doesn't work.
>> 
>> Did mythcommflag produce any warning or error messages?
>
>Just this. Don't know if it is a concern.
>
>mythtv at mythtv:/mythtv/recordings$ mythcommflag --rebuild -f 
>36114_20221105103000.ts
>2022-11-06 10:26:16.512971 C  mythcommflag version: fixes/32 
>[v32.0+fixes.202211050719.18f5b48ee1~ubuntu22.04.1] www.mythtv.org
>2022-11-06 10:26:16.512986 C  Qt version: compile: 5.15.3, runtime: 5.15.3
>MythTV Commercial Flagger, building seek table for:
>     Stacey David's GearZ - Upgrading the Yellow Van
>Rebuild started at Sun Nov 6 10:26:18 2022
>2022-11-06 10:26:25.803436 E  VideoProfile: No window!
>2022-11-06 10:26:25.803987 E  VideoProfile: No window!
>2022-11-06 10:26:25.892378 E  VideoProfile: No window!
>2022-11-06 10:26:25.892751 E  VideoProfile: No window!
>2022-11-06 10:26:47.659031 E  decoding error End of file (-541478725)
>Rebuild completed at Sun Nov 6 10:26:47 2022
>mythtv at mythtv:/mythtv/recordings$

The end of file error is not a problem - this happens with normal
broadcast streams and seems to be caused by the recording being
stopped in the middle of a group of related packets, so some video
packets are received but the matching audio ones are missing.  So the
decoder objects to the missing audio packets.

The "VideoProfile: No window!" errors I have not seen before and could
well indicate a real problem.  I have no idea what they mean.

>>> On 11/5/2022 10:02 PM, Stephen Worthington wrote:
>>>> On Sat, 5 Nov 2022 21:03:24 -0400, you wrote:
>>> 2. ffmpeg -i xxxx.ts -c copy t.ts
>>> Didn't make any difference
>> 
>> Every time you change the recording file, you have to run mythcommflag
>> --rebuild again before you try playing the file.  The skip data made
>> from the old file will definitely not work with the new file.
>
>Tried that. No difference. Still can't seek ahead. Sees length as zero 
>as before.
>
>>> On 11/5/2022 10:02 PM, Stephen Worthington wrote:
>>>> On Sat, 5 Nov 2022 21:03:24 -0400, you wrote:
>>> 3. initial multiplexing as an MKV work better than an MPEG transport stream
>>> Not sure how to do this.
>> 
>> I have never done this, but I think you just have to tell ffmpeg to
>> produce a .mkv output file, instead of .ts.  So try changing "-f
>> mpegts" to "-f mkv".  The rest of the recorder setup should also be
>
>I tried this and got a recorder failure. Doesn't like just changing the 
>mpegts to mkv.
>
>On 11/6/2022 8:49 AM, Peter Bennett wrote:
> > I suggest encode to h264 and aac using:
> >
> > -c:v libx264 -preset veryfast -crf 21  -c:a aac
> >
> > I use crf 21 for 720p, 23 for 1080p and 22 for 480p
> >
> > CPU usage is higher, but I have had perfect results and no skipping
> > problems. You can see my entire set of scripts here:
>
>This actually works and solves my skip problems. It creates smaller 
>files too since I used 21 (720p) and the video comes in as 1080p. 
>However, it seems to not record the last 7 minutes or so. I don't know 
>why. It pegs the CPU as expected but that isn't a concern of mine.

The fact that the CPU is maxed out is likely the cause of the problem.
It is unlikely that your CPU can do re-encoding like this in real
time, so the input buffers will be filling up until they reach their
maximum size, after which data will be lost.  The usual solution for
this is to just record the incoming data to disk without doing any
re-encoding, and then when it is complete, start the re-encoding
process so that it can run at its own pace.  Or to record to disk and
run the re-encoding as a parallel process that reads back from disk,
at its own pace.  There are other complications with doing the
re-encoding after the recording though - if you get too many
re-encoding processes running at once, you can cause the system to
start thrashing and everything grinds to a halt.  It can be CPU
thrashing, or too much RAM usage, or both.  So it is best to get the
end of recording processing to put the re-encoding processing into a
queue and control how many re-encoding jobs are done at once.  This is
what MythTV does with its job queue and its transcoding jobs, so I
think using the MythTV post-recording transcoding mechanism might be
the right way to do it.  I have never used that, so I do not know how
easy it would be to get it to do the right transcoding.

In any case, re-encoding should not be necessary.  It should be
possible to just fix the container and multiplexing and leave the
stream content alone.  However, ffmpeg may not be able to do this - it
can be very buggy.  So maybe a better tool like TSDuck would be able
to.

>Your Github repository for using FireTV is impressive. I'm not using it 
>now but I might. I have a FireTV at home.
>
>If I can't solve the "convert to libx264" truncation problem I'll have 
>to keep recording without being able to skip ahead. Truncating is worse 
>than not being able to skip.