Channels commercial detection issue, off by 10 seconds on each end

Channels DVR Server
#1

Quick recap, I use Channels DVR to record football games, and then Videoredo for editing.

Last year was my 1st season with Channels after many years with WMC, the auto-detect feature was a welcome addition, and was spot-on accurate. . :slight_smile:

This season, I have noticed the start and end times of the commercial detections are "forward" about 10 seconds to where it should be.

If I blindly use this detection, I would see the 1st 10 seconds of every commercial break and miss the 1st seconds of action after the break is over. Obviously, I don't want that.
Now, all is not lost, this still provides a great approximation of where all the breaks are, I just need to go into each one and correct them.

I wanted to bring this to the developers attention, maybe it is a Channels thing that has changed. Perhaps is it a VRD issue (which unfortunately has not, and will not, be updated moving forward)

Are there settings I can check in either program?

I appreciate the time and consideration

1 Like
#2

I found (before DRM was turned on) that my local stations ATSC 3.0 feeds were 10 seconds behind the ATSC 1.0 feeds. Maybe you're hitting something similar where the timings observed when you record don't match the same timings on the stream where the commercials were detected?

#3

while last weeks recordings were from CBS, this past Saturday was BTN, so there isn't any OTA factor at all here

#4

Are you using the Channels DVR generated .VPrj file

There are two of them.
The first one uses the same times that Channels stores and is named as the recorded file name.vprj alongside the recording.
The second one uses the times calculated by comskip and is in the Logs/comskip/fileid folder and named video.VPrj

I brought up the fact the times are different between these and was told it adjusts for the Initial video pts time in the recording.

If you want to mess around, there is a setting you can use in the override comskip.ini or the comskip API to adjust the offset for the comskip generated .VPrj file
videoredo_offset=2
;amount of frames subtracted from the videoredo cut time output, use negative numbers to shift to later.

1 Like
#5

Ill have to dig into that, whatever version i used last year, i also used this year, nothing changed, but maybe i deal with the frames issues

#6

Basically what I'm saying is Channels DVR creates a .VPrj file with markers that are offset later than the .VPrj file that comskip creates. I don't know about 10 seconds though. It offsets them based on the Initial video pts (Presentation Time Stamp) value in the recording.

So if the recording had an Initial video pts of about 10 seconds, the Channels DVR generated .VPrj file markers would be 10 seconds later than the comskip generated .VPrj file markers.

#7

There is a setting for padding but I do not believe Channels DVR makes use of that setting in Comskip.ini.

padding=0 (0-MAXINT)
;Amount of seconds each commercial will be reduced both as start and end.
;;When you always want to see the start and end of the commercial break this can be used.
remove_before=0
;Set the amount of seconds to remove before ALL commercials
remove_after=0
;Set to the amount of seconds to remove after ALL commercials

#9

where do i make that adjustment?

#10

Either in your override comskip.ini file if you use it, or using the comskip.ini API

Just remember the value you specify for videoredo_offset= is number of frames, not seconds. So for example a recording at 59.94 fps has about 60 frames per second.

Before doing this you might want to see what the Initial video pts is for one of those problem recordings. It can be easily viewed from the comskip log for the recording.

[mpegts @ 0x2294af40] Before avformat_find_stream_info() pos: 0 bytes read:32768 seeks:0 nb_streams:4
[mpegts @ 0x2294af40] After avformat_find_stream_info() pos: 0 bytes read:872592 seeks:2 frames:118
Input #0, mpegts, from '/shares/dvr/TV/The Smurfs/The Smurfs S01E09 1981-10-10 Romeo and Smurfette 2023-09-12-0430.mpg':
  Duration: 00:30:01.46, start: 81135.827456, bitrate: 3964 kb/s
  Program 9 
  Stream #0:0[0xb1]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn
  Stream #0:1[0xb3](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
  Stream #0:2[0xb4](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s
  Stream #0:3[0xbb]: Data: scte_35
Frame Rate set to 59.940 f/s
Initial audio pts =      0.000
Initial video pts =      1.018
#11

Yeah, I’m not gonna be messing around with that kind of assembly code level stuff… I appreciate the answer, but I’m not gonna be getting into the weeds like that

I’m hoping the developer can chime in and say why it was working spot on last year but not so much this year

#12

I've learned not to rely on comskip ever being accurate.
I use VideoRedo and like you, look at the markers as where the ads are and fine tune in VRD.
I use the Control key and left/right arrows to scrub through the video to I-frames and IDR-frames.
Capture
Hold down Control and tap right arrow takes you to the next I/IDR-frame.
Hold down Control and right arrow scrubs through the video quickly an I/IDR-frame at a time.

1 Like
#13

I have used that box before, mostly to change the amount of skip ahead and rewind time..... but i will incorporate what you have shown me here and it will be even more effective.

Can you give me a quick primer on what an i-frame is (which i have seen heard of before) and an IDR-Frame (which i have not heard of before)

Thank you

#14

Just try using the Control right arrow to scrub through a video.
The decoder has to decode the compressed information to display a frame.
I (and IDR) frames take less time to decode and thus navigating I & IDR frames are quick.

1 Like
#15

still off by 10 seconds (late) - and it wasn like this last year.

maybe it jus is what it is - especially with VRD on autopilot

#16

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.