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.
1 Like
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.
Capturing what is given is the reality, and how it should be. Post-processing should not be necessary (even if desired in some circumstances).
No, not true. Ffmpeg is not made for the capture. The capture is saved as-is, without outside aid. The stream is saved, bits in-bits out.
Has anyone complied a full list of affected tve channels?
That would be really useful.
exactly......so.....why can't the Channles DVR sever then do this for the user....instead of the user having to manually do this.
I guess i miss understood you when you said this then...
So Channles is already processing the video file then?
If so, then why it is making a bad file? when i can make a good file using the same program>
If you examine the recorded file and see the audio stream is the first stream (0) and (falsely says) includes the PCR, then you identified the problem ones. Not all TVE channels have this issue.
1 Like
I know this....however, aside from recording all of the TVE channels, just to check for this, is not going to happen. Just wonder if anyone who uses tve enough had thought to compile a list.
I wonder about if it is just Windows File Explorer.....and if a third party file explorer software could be instead used to browse the server file share and not be affected by this issue. Though that would not fix the issue of a bad file that the user goes to play back normally and it locks up the computer...but at least it would allow for browsing and accesing the files.
You originally mentioned you have this issue with OTA recordings in your other post. Were they from an HDHR tuner? If so, this is not the root cause.