Playing these problem recordings in VLC it has the Audio stream as Stream 0 and thinks the Frame rate is 48,000 Frames per second.
Oh okay I understand now. Which video editor did you use? I have seen people use VideoRedo which I actually do have since I manually take out the commercials myself. I don't trust those automated programs since those haven't worked for me.
I use VideoRedo v6.
I have Channels DVR comskip create a VRD Project file and if I cut every frame of commercials out of those TVE recordings it saves without removing any resync frames and the resulting file has no issues with Windows Explorer.
If you create an override comskip.ini file with the following line added
output_videoredo3=1
Channels DVR comskip creates a VRD Project file with scene markers and cut points defined.
Then it's just a matter of fine tuning the cut points in VRD.
The problem recordings have the PCR on the Audio PID.
My video editor rewrites this when saving to put the PCR on the Video PID.
This can be seen by viewing the output of ffprobe -show_programs -i filename
If you have TSReader or TSReaderLite you can also see this by viewing the PMT.
Doing some experimenting with ffmpeg (I used the windows binaries) I found that doing a remux with just a stream copy to an mp4 file fixes things up. And since it's just a stream copy it runs really quick. Maybe a 'fix' is to convert the mpg files as the first step and use mp4 to save the recordings?
ffmpeg -i "filename.mpg" -c copy "filename.mp4"
Does anyone else have a Transport Stream analyzer?
I'm using 'Altais Digital DemuxToy Lite TS Anayser'
What I'm seeing is every TVE recording having stream 0 as the audio is missing the PCR.
The PMT table points to the Audio PID as carrying the PCR, but it's not there.
Other TVE recordings that show stream 0 as the video have the PCR.
PCR is Program Clock Reference
Is this mix up on stream 0 something that is happening when Channels is writing the .mpg file, or is it inherent in the TVE stream?
It's the stream coming from the networks. Channels doesn't rewrite anything; it takes the streams exactly as they're delivered to it.
I also verified with another tool that the PCR is missing from these recordings.
MPEG-2 TS packet analyser
They're actually MPEG2 Transport Stream (normally .ts file extension) containers.
Remuxing the problem files would help with Windows, but not sure that remuxing to an MP4 Program Stream wouldn't cause issues with Channels clients trying to play them.
MPEG Transport Streams are codec agnostic. It can be MPEG-2/H.262 or MPEG-4/H.264/AVC video, but it has no effect on the container.
What I meant was the .mpg files are not Program Streams, but Transport Streams.
Converting the MPEG2 Transport Streams recorded by Channels DVR to MPEG4 Program Streams by remuxing may not work for playback with Channels clients.
I'm not 100% sure, but I think Channels DVR expects its recording files to be in the MPEG2 Transport Stream container it saved them in, even though the file extension is .mpg.
You could just remux the files with
ffmpeg -i "filename.mpg" -c copy "filename.ts"
This should make the Video stream 0 and add a PCR to that stream.
one of mine for example
Input #0, mpegts, from 'SportsCenter 2020-10-27-2008.mpg':
Duration: 00:30:05.11, start: 0.016689, bitrate: 5492 kb/s
Program 1
Stream #0:0[0x101]: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 124 kb/s
Stream #0:1[0x102]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720, 60 fps, 59.94 tbr, 90k tbn, 120 tbc
Stream #0:2[0x103]: Data: timed_id3 (ID3 / 0x20334449)
Output #0, mpegts, to 'SportsCenter 2020-10-27-2008.ts':
Metadata:
encoder : Lavf58.20.100
Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720, q=2-31, 60 fps, 59.94 tbr, 90k tbn, 90k tbc
Stream #0:1: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 124 kb/s
Stream mapping:
Stream #0:1 -> #0:0 (copy)
Stream #0:0 -> #0:1 (copy)
Try it with one of your problem files.
If that works you could delete your original recording "filename.mpg" and rename the newly remuxed file from "filename.ts" to "filename.mpg"
Thanks for the tip. Replacing the original file with the renamed ffmpeg copy worked well. Channels clients still play the file without issue, and the file no longer causes Windows Explorer to hang.
Yep, works great.
Since it's just a remux it runs quickly.
If anyone is wondering what happened to
Stream #0:2[0x103]: Data: timed_id3 (ID3 / 0x20334449)
since it's not in the output.
It's timed metadata in ID3 format. Not anything needed in a recording.
If you're curious you can do a web search for timed_id3 or timed id3 metadata
Just wanted to say this before anyone does a mass remux of their TVE recordings.
You may want to wait until the devs respond before doing any mass remuxing.
Not all TVE recordings have this issue.
After you remux and replace your original recording file with the remuxed one you may have to;
1 Refresh Metadata (fast)
2 Regenerate Video Index (fairly fast)
3 Redetect Commercial (slow)
Sample size of one, but Channels kept the same metadata and com skip info, when I replaced the original file with the remux. But, the warning is a good one. I certainly don't have the need to mass remux everything. Most of my recordings are watched and deleted. But, occasionally there are files I want to archive myself.
Shame this issue still persists.
I have now been trying to deal with this.
Suggested a option added so that the server would do a post processing step of a quick remux to a different container format, like .mkv/.mp4.
Since it seems very clear to me that something in the way Channels is writing the file out/capturing the data, and writing the file headers and metadata, is the issue here. Cause, 100% fix is to remux the file with nearly any program, i have uses mkvtoolnix, shannaencoder or ffmpeg.
I have used Emby, some time ago, when i first had this issue, with Channels connected to it as a test, and its .ts file was fine. Also, using the url list export, can load the same channel up in VLC and use its capture option and that file is fine.
Edit: If Channels DVR can not be "fixed" or such a workaround added to it....then, is there some possible solution in tweaking Windows? Like a system setting, registry change, etc, to prevent the file Explorer from trying to read the file as a video, or generate a thumbnail? What about a third party program that would replace the Exploere thumbnail generation? I recall when i have install codec packs in the past, like Klite, it makes it so that Exploer can make thumbnails of files it could not before.
No, the issue is that Channels is writing out what they're given. You associate this issue with Channels, because that is how you receive these streams. But, the issue is really that the streams are messed up when they're received.
Yes, a remux could fix this. But that is not what the issue is at the root; the issue is that the streams are crap when they're received, and can only be "good" when they are post-processed.
So.....then not doing anything to fix what you can in the mean time...is ok then.
Adding a remux option, that fixes the broken file....is out of the question? why? who cares if it does not fix the root problem....that matters not, when the root problem is not fixable.
channels uses ffmpeg once, to make the file capture and make the .mpg...use it again to remux it to .mkv, then delete the .mpg and be done with it.
Unless i see proof that they have made a build that does exactly that, and that it somehow fails to work for some reason....then you can't really say or defend them in this matter. But its 100% works to do the remux using the same program ffmpeg that channels uses...so....i dont see what the fuss and rejection is about.
Problem with some TVE streams is that they lie about including the PCR in the audio stream.
There is no PCR and the audio stream is not the place for them anyways, they belong in the video stream.
Channels records everything in a Transport Stream (even though the file extension is .mpg) and a simple remux with ffmpeg fixes the lying TVE stream issue and makes Windows happy so it can parse the file details.