TVE Beta: Recordings causing problems with Windows Explorer

I'm using non-Pro v5.4.84.771a

Guess this conversation should be on VRD's website.

Looks like you provided some valuable info from TS Doctor that might help the ChannelsDVR Devs.

For me explorer takes a while to display contents only on certain recordings, but it doesnt crash. Ive noticed that it only happens to recordings with wild bitrates. Meaning the bitrate jumps up then falls down if that makes sense. The lowest white line is 40kbps and the highest purple line is 12112kbps. those are wild swings

Capture1
Capture2

Here is afile that behaves normally in explorer:

Capture3
Capture4

Is this the same Bitrate Viewer you used?

https://www.videohelp.com/software/Bitrate-Viewer-2

Latest version
2.3 (October 7, 2011)

Does VRD Pro offer anything like that?

Yes, that’s it

So I've played with this some more today. I installed the latest official release build of VideoReDo TVSuite 5 (I actually had a license key for it from many years ago). When I open my test "Mama's Family" recording from above it does allow me to edit it without crashing, and processes it the same way you all describe with all the resync frame removal errors. Going through the files you can clearly tell the promos/commercials are sometimes in a super low resolution compared to the actual episodes.

I'd say AeroR1's "Bitrate Viewer" is confirming the same behavior I'm seeing, just in a different way. Those areas in his files where the bitrate bottoms out I'd be willing to bet are these low resolution commercials and promo insertions.

Thanks to you guys for tipping me off about the resolution difference acceptance in the VRD TVSuite too. I'm amazed that their Professional version intended for Broadcasters doesn't have the same feature considering we pay so much more $$ for it (but that is for their forums not this one). Lesson learned- I will keep both versions up to date from now on and use the "Pro" version when I'm working with files that require its features.

I think that's built on ffmpeg's ffprobe utility and is at least 8 years old.

I'm sure the ChannelsDVR devs have something more up-to-date than that, but it looks like a good tool based on its age for what it does.

I'm sure the issue is either discontinuities/sync errors in the TS stream created or some clock wrapping that the Devs will discover and handle. So many clocks and wrapping of time based fields when dealing with wrappers upon wrappers in streaming video HLS and TS and MPEG2/H.264... makes your head spin.

For me, Windows Explorer eventually comes back and the system is usable again. VideoRedo is able to open and process the suspect files. When running Quickstream Fix, it's always removing some number of audio frames to resync. Never have had issue with video frames. The Quicksteam Fixed version of the file plays nice with both Windows Explorer & Channels DVR.

I forwarded @reneg's log to VRD support and here's what they said:

Thanks for the log. The problem is that the file's video stream has a frame rate of 60 fps, but time stamps in the PES packets are increasing at a rate of 59.94. Can't tell which one is correct although if the source file plays in sync in VideoReDo then it's likely that the video stream's frame rate is incorrect.

Try this: Go to Tools>Options>H.264/HEVC options and change the Source frame rate from "Automatic" to "From stream". Then right after you open the file click on Tools>Show Program Info. Is the frame rate now showing as 60 fps or 59.94?

For the file that matches the VideoRedo Log file, it is showing 60 fps.

After Quickstream fix, it shows the following

I have another file that shows 48000 fps which causes problems with Windows Explorer,

On this second file with the VideoRedo options set to "From Stream" instead of "Automatic". I run out of virtual memory when trying to Quickstream Fix it. When I change the option back to Automatic, VideoRedo can process it without running out of memory. Most of my Channels DVR recorded files that don't cause problem are 29.97 fps.

1 Like

I did three test recordings from three different TVE channels.
Don't know where in the stream VideoRedo and comskip get the frame rate of 48000.00 fps, but they both do see that.

On all three of these VideoRedo SaveAs or QuickStreamFix will remove about 1,000 audio resync frames.

ch6110 (SCI) How It's Made 1920x1080p @ 29.97
[MTS] Statistics for "TV/How It's Made/How It's Made S02E01 2002-09-07 Eyeglass Lenses Granite Potato Chips 2019-08-04-1324.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=2 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=false saw_pmt=true highest_pts=342.464400
File plays in sync in VideoReDo
VideoReDo Source frame rate "Automatic" and "Calculate" shows 29.97 fps
VideoReDo Source frame rate "From Stream" and "From Container" shows 48000.00 fps

ch6104 (HGTV) Fixer Upper 1920x1080p @ 29.97
[MTS] Statistics for "TV/Fixer Upper/Fixer Upper S04E03 2016-12-13 Bright Open Design Transforms Couples First Home Together 2019-08-04-1324.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=36 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=false saw_pmt=true highest_pts=2169.032956
File plays in sync in VideoReDo
VideoReDo Source frame rate "Automatic" and "Calculate" shows 29.97 fps
VideoReDo Source frame rate "From Stream" and "From Container" shows 48000.00 fps

ch6108 (DIY) Barnwood Builders 1920x1080p @ 29.97
[MTS] Statistics for "TV/Barnwood Builders/Barnwood Builders S08E02 2019-04-14 Hidden History 2019-08-04-1324.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=79 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=false saw_pmt=true highest_pts=2155.389144
File plays in sync in VideoReDo
VideoReDo Source frame rate "Automatic" and "Calculate" shows 29.97 fps
VideoReDo Source frame rate "From Stream" and "From Container" shows 48000.00 fps

I'm recording a fourth, a movie on FXHD that should be done in 30 minutes.

Using VideoRedo QSF on this file results in 4669 audio resync frames removed.

ch6080 (FXHD) The Fate of the Furious (2017) 1280x720 @ 59.94 fps
[MTS] Statistics for "Movies/The Fate of the Furious (2017) 2019-08-04-1308.mpg": skipped=184 unhandled_packets=0 discontinuity_detected=20 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=false saw_pmt=true highest_pts=10285.445711
File plays in sync in VideoReDo
VideoReDo Source frame rate "Calculate" shows 59.94 fps
VideoReDo Source frame rate "Automatic" and "From Stream" and "From Container" shows 60.00 fps

For those of you seeing the VRD problem only on certain recordings, do those start on a commercial? One thing I've found that helps with that is to create basically just a rough trim to eliminate any potentially bogus frames at the start (set start and end points a few seconds outside the real ones for the show, making sure the start is set at actual programming and not an ad). Then, use Tools > Trim and Copy Source File, set to Use Selection markers, and save an intermediate file. Since this just straight byte copying without any processing, it doesn't have problems with any video changes. Then, load that file you just saved and do all the actual cuts on that and save it, and that has worked for me on everything so far. I also keep View > Display On-Screen Information enabled since it will display the resolution if it changes from whatever is at the start of the file, which is useful in making sure all the junk frames are removed. I have had a couple recordings drop from 1080p to 720p at commercial and never go back, and I just have to trash those and wait for a rerun.

Two of the three problem recordings that I've saved start recording during the closing credits of the previous show which in both cases was the same episode shown back to back. I pre-pad one minute and post pad three minutes on my recordings. My recordings are not displaying a resolution change in VideoRedo.

I've noticed more affinity towards streams that are not 29.97 fps having problems than anything else.

Not in my case either.
Appears to be something in the stream, either from the provider or from how ChannelsDVR captures the HLS streams from the provider into a .TS recording that mis-represents the true frame rate.

I'm keeping those 4 TVE test recordings I made in case the devs want more info on them.
They're either onto the problem or aren't responding to posts about it.

I'm only using TVE for one channel that's HD via TVE, where my Xfinity sub only has it in SD.

Any updates on this issue?

Another TVE recording where VideoRedo SaveAs or QuickStreamFix will remove either 3,369 or 85,950 audio resync frames depending on VRD Source frame rate option selected.

ch6108 (DIY) Building Off the Grid 1920x1080p @ 29.97
[MTS] Statistics for "TV/Building Off the Grid Killer Views/Building Off the Grid Killer Views 2018-06-26 2019-08-18-1100.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=76 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=false saw_pmt=true highest_pts=3683.336744

File plays in sync in VideoReDo.

VideoReDo Source frame rate "Automatic" and "Calculate" shows 29.97 fps and removes 3,369 audio resync frames.

VideoReDo Source frame rate "From Stream" and "From Container" shows 48000.00 fps and removes 85,950 audio resync frames.

@JJJJJ Recording begins during last minute of previous show and ends 1 minute into next show, so not beginning/ending on a commercial.

If I do my comm cuts and then save, it only removes about 40 audio resync frames (acceptable for me).

UPDATE: Redid my comm cuts making sure every frame that wasn't program material was cut out and now no audio resync frames removed. I also noticed the ts stream PCR is on the audio es stream pid in the recording and VRD puts the PCR on the video es stream pid when saving it. Still not sure exactly what is unusual with the recorded ts streams, but sure seems to have something to do with commercials, maybe video frame rate change like from 29.97 to 30 fps?

I still maintain my original theory.. it has to do with the providers inserting commercials of varying bitrates, frame rates, and resolutions in programs. VRD navigates them fine in the newer versions but if you pay attention when making cuts it is easy to identify the lower resolution commercials. They’re more blurry than usual and stand out in most cases. If you use a program like TS Doctor it clearly identifies these problem areas and tells you what the resolution drops to. Every instance of a drop is a commercial. The same issues occur if you capture a stream directly from WatchESPN outside of Channels. They display the same symptoms in Explorer and VRD and have the same resolution bouncing issues. I think this is a stream provider issue because it isn’t unique to Channels

1 Like

Definetly something with the adverts.

Using the same recording I inverted all my cuts in VRD so only the commercial blocks would be saved and I saved each of the 6 blocks (seen in green) one at a time. cb1.ts - cb6.ts. Every block gets audio resync frames removed.

cb1.ts
Video length: 00:02:04
Video size: 86MB
Output scenes: 1
Video output frames: 3724
Audio output frames: 2914
Processing time (secs): 8
Processed frames/sec: 465.50
Actual Video Bitrate: 5.26 Mbps
Audio resync frames removed: 430

cb2.ts
Video length: 00:03:26
Video size: 139MB
Output scenes: 1
Video output frames: 6202
Audio output frames: 4852
Processing time (secs): 10
Processed frames/sec: 620.20
Actual Video Bitrate: 5.09 Mbps
Audio resync frames removed: 497

cb3.ts
Video length: 00:03:15
Video size: 136MB
Output scenes: 1
Video output frames: 5854
Audio output frames: 4579
Processing time (secs): 14
Processed frames/sec: 418.14
Actual Video Bitrate: 5.27 Mbps
Audio resync frames removed: 711

cb4.ts
Video length: 00:03:03
Video size: 125MB
Output scenes: 1
Video output frames: 5514
Audio output frames: 4314
Processing time (secs): 10
Processed frames/sec: 551.40
Actual Video Bitrate: 5.19 Mbps
Audio resync frames removed: 506

cb5.ts
Video length: 00:03:25
Video size: 139MB
Output scenes: 1
Video output frames: 6159
Audio output frames: 4818
Processing time (secs): 12
Processed frames/sec: 513.25
Actual Video Bitrate: 5.12 Mbps
Audio resync frames removed: 574

cb6.ts
Video length: 00:02:19
Video size: 99MB
Output scenes: 1
Video output frames: 4173
Audio output frames: 3265
Processing time (secs): 11
Processed frames/sec: 379.36
Actual Video Bitrate: 5.39 Mbps
Audio resync frames removed: 640

It's not the dogs fault.

For this recording at least, case closed.
Each of the 6 commercial blocks contains the following encoded at 30 frames per second, where the rest of the recording is at 29.97 fps.

I think the reason why some software (including Windows) is getting confused with these TVE streams and thinking the video frame rate is 48,000.00 fps is because the audio stream is first (lowest pid, first stream) and the video stream is second (higher pid, second stream) and sees the audio sampling rate of 48,000.

Most ts streams have the video as the first stream and the pcr is usually on that. With these TVE streams the audio is the first stream and has the pcr on it.

Not sure if you use VRD, but you can see the issues if you comskip the recordings and view the comskip video.log file for the recording.

Example:

Lots of

Frame Rate set to 48000.000 f/s
DFps[1]= 29.970 f/s
RFps[1]= 29.970 f/s
AFps[1]= 29.970 f/s
Frame Rate corrected to 29.970 f/s

and then

Strange video pts step of 0.04533 instead of 0.03387 at frame 7
Strange video pts step of 0.05485 instead of 0.03387 at frame 16152
Strange video pts step of 0.04887 instead of 0.03387 at frame 17234
Strange video pts step of 0.04709 instead of 0.03387 at frame 18311
Strange video pts step of 0.04887 instead of 0.03387 at frame 27131
Strange video pts step of 0.04802 instead of 0.03387 at frame 45017
Strange video pts step of 0.04636 instead of 0.03387 at frame 45513
Strange video pts step of 0.04557 instead of 0.03387 at frame 46184
Strange video pts step of 0.05211 instead of 0.03387 at frame 59889
Strange video pts step of 0.04802 instead of 0.03387 at frame 60610
Jump in base apts from 2188.71532 to 2188.72930, delta=0.01398
Strange video pts step of 0.04887 instead of 0.03387 at frame 74094
Jump in base apts from 2663.14002 to 2663.15400, delta=0.01398
Strange video pts step of 0.04887 instead of 0.03387 at frame 90681
Strange video pts step of 0.04636 instead of 0.03387 at frame 92346
Strange video pts step of 0.04604 instead of 0.03387 at frame 93017
Strange video pts step of 0.04637 instead of 0.03387 at frame 93377
Strange video pts step of 0.04541 instead of 0.03387 at frame 93736

Frame  58450 (2023.281s) - Resolution change from 1920 x 1080 to 1280 x 720 
Frame  59889 (2083.305s) - Resolution change from 1280 x 720 to 1920 x 1080 
Frame  61957 (2158.671s) - Resolution change from 1920 x 1080 to 1280 x 720 
Frame  62848 (2188.754s) - Resolution change from 1280 x 720 to 1920 x 1080 
Frame  75620 (2633.095s) - Resolution change from 1920 x 1080 to 1280 x 720 
Frame  76509 (2663.179s) - Resolution change from 1280 x 720 to 1920 x 1080 

Parsed 106072 video frames and 118595 audio frames at    30.45 fps
WARNING: Actual framerate (28.800) different from specified framerate (29.970)
Internal frame numbers will be different from .txt frame numbers
WARNING: Complex timeline or errors in the recording!!!!
Results may be wrong, .ref input will be misaligned. .txt editing will produce wrong results
Use .edl output if possible

@chDVRuser posted information from the comskip log which got me looking at my logs too. I am noticing a correlation between "problem" files and how they are parsed by Comskip. I suspect that Windows Explorer is not able to recover like Comskip does. It seems that problem files have audio stream listed first, and then video stream. It appears that the frame rate gets interpreted from the audio sampling rate (48000) for some reason. I'm not familiar which specifics around containers, and may be using terminology wrong, but it does appear to be a recurring pattern on the shows I've recorded. Here are some examples:

Problem file 1 - excerpt from comskip log

Input #0, mpegts, from 'K:\ChannelsDVR\TV\Deadliest Catch\Deadliest Catch S15E18 2019-08-20 Dark Ship 2019-08-20-1959.mpg':
  Duration: 01:02:40.02, start: 0.033378, bitrate: 5102 kb/s
  Program 1 
    Stream #0:0[0x101]: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 126 kb/s
    Stream #0:1[0x102]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080, Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 96k tbc
    Stream #0:2[0x103]: Data: timed_id3 (ID3  / 0x20334449)

Initial audio pts =      0.000
Frame Rate set to 48000.000 f/s
DFps[1]= 29.970 f/s
RFps[1]= 29.970 f/s
AFps[1]= 29.970 f/s
Frame Rate corrected to 29.970 f/s
Format changed to [1920 : 1080]
Frame: 1	Ratio: 1.80	MinY: 1 MaxY: 1080 MinX: 1 MaxX: 1920
Frame: 1 Channels:  2

Problem file 2 - excerpt from comskip log

Input #0, mpegts, from 'K:\ChannelsDVR\TV\Queen Sugar\Queen Sugar S04E09 2019-08-14 Stare at the Same Fires 2019-08-14-1959.mpg':
  Duration: 01:03:41.05, start: 0.033378, bitrate: 3218 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, 29.97 fps, 29.97 tbr, 90k tbn, 96k tbc
    Stream #0:2[0x103]: Data: timed_id3 (ID3  / 0x20334449)

Initial audio pts =      0.000
Frame Rate set to 48000.000 f/s
DFps[1]= 29.970 f/s
RFps[1]= 29.970 f/s
AFps[1]= 29.970 f/s
Frame Rate corrected to 29.970 f/s
Format changed to [1280 : 720]
Frame: 1	Ratio: 1.80	MinY: 1 MaxY: 720 MinX: 16 MaxX: 1280
Frame: 1 Channels:  2

Sample of a "good" comskip log which doesn't cause problems:

Input #0, mpegts, from 'K:\ChannelsDVR\TV\Suits\Suits S09E05 2019-08-14 If the Shoe Fits 2019-08-14-1959.mpg':
  Duration: 01:04:51.99, start: 0.732544, bitrate: 4025 kb/s
  Program 1 
    Stream #0:0[0x101]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080, Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x102]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 96 kb/s
    Stream #0:2[0x103]: Data: timed_id3 (ID3  / 0x20334449)

Frame Rate set to 29.970 f/s
Format changed to [1920 : 1080]
Frame: 1	Ratio: 1.23	MinY: 1 MaxY: 1080 MinX: 82 MaxX: 1382
Frame: 1 Channels:  0

Here's another data point. For me, it's not problem recordings, it's problem channels which trigger this issue with Windows Explorer. I recorded random shows on these four channels and had problems with every recording. My TVE provider is Comcast.

  1. Discovery
  2. FX HD
  3. National Geographic
  4. OWN

I'm sure there are other channels that may cause issue, but these four are consistent for me.