Closed kjeacle closed 1 year ago
I see the same with your clip on my Sony Android TV. My usual script for h264 does, essentially,
mythffmpeg -fflags +genpts -i inputfile -acodec copy -vcodec copy -scodec copy -f mpegts outputfile
similar to the suggestion in the Readme, and then rebuilds the seektable. It cures the problem, and unlike the mkv option leaves the recording in standard MythTV format.
In fact I keep only the video and audio streams. For info, here are mythffprobe results for the raw and processed clips, omitting most of the complaints.
Raw: Input #0, mpegts, from '/home/john/SGs/RecsSG4/20055_20221231100000.ts': Duration: 00:03:06.74, start: 75887.521289, bitrate: 2155 kb/s Program 1 Stream #0:0[0x451]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 704x576 [SAR 16:11 DAR 16:9], 25 fps, 50 tbr, 90k tbn Stream #0:1[0x3e9]: Data: dsmcc_b Stream #0:20x4b5: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s Stream #0:30x519: Subtitle: dvb_teletext ([6][0][0][0] / 0x0006) Unsupported codec with id 94236 for input stream 1 Unsupported codec with id 94215 for input stream 3
Processed: Input #0, mpegts, from '/home/john/SGs/RecsSG4/20055_20221231102400.ts': Duration: 00:03:06.74, start: 1.400000, bitrate: 2095 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg, top first), 704x576 [SAR 16:11 DAR 16:9], 25 fps, 50 tbr, 90k tbn Stream #0:10x101: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
John, thanks for the info. Your example does indeed fix the problem.
As these are standard recordings from a national broadcaster (and not files that have been mangled in some way) I was hoping to avoid any transcoding as I don't run any other user jobs at present and the files are OK in Mythfrontend.
Perhaps there is no other option and this is the recommended fix for Leanfront.
I'm glad it worked for you. I suspect that this problem is another result of the treatment of timestamps during recording. See perhaps https://github.com/MythTV/mythtv/issues/600#issuecomment-1173058981
I have downloaded your sample and I can recreate the problem. I will trace the error to find the cause and see if there is a solution that does not involve post-processing the file.
leanfront Exoplayer requires that it know the length of the video in order to skip. The problem is that it is unable to find the length.
I tested playing this file with vlc and it also is unable to find the length (length shows as 0)
Tracing the code I found that it goes wrong when searching for timestamps at the beginning and end of the file. It never finds a valid timestamp.
I am not familiar with the layout of packets, I rely on Exoplayer for that. I cannot see the reason for the problem, other than there is a different layout from normal. If I could figure out a fix, I could submit it to Exoplayer, they are very receptive to fixed. Since vlc also cannot find the length, I assume there is an error in the stream. I am giving up on trying to fix this. or on asking Exoplayer to fix it.
You could easily add the ffmpeg command suggested by John as a user job to run after every recording. It should be very quick to run. Let me know if you need assistance with that.
Peter, thanks for looking into this. Unless something changes in how the stream is broadcast, it looks like a user job is the only option. I already have an ffmpeg script ready to go. Thanks again.
Recordings from the Irish DVB-T service (Saorview) never show length and it's not possible to seek.
I have tried increasing TS Search Packets to 100000.
This happens on both Shield and Fire Stick. Mythfrontend works OK.
Sample recording here: http://159.69.45.92/saorview.ts
Thanks!