Cut points are late by 8 frames....
Cut points are late by 8 frames....
I am using Comskip with DVB-T files that are recorded as DVR-MS and I have it tuned to find all the commercial breaks beautifully...
However, I have noticed that the output cut list shows the cut points to be 8 frames later than I think they should be.
For example, at the beginning of a commercial break (during the black period) Comskip will mark the cut point at frame 6,008 - but when I view that area in VideReDo, I can see that the middle of the black period is at frame 6,000 and that frame 6,008 includes some of the first frames of the commercial. Similarly, at the end of the commercial break, the centre of the black period is frame 8,000 - but Comskip outputs the cut at 8,008 which includes the first few frames of the re-commencement of the program.
Eight frames doesn't sound like a big deal, but what it means is that when I watch the "cleaned" video, a flash of commercial will appear where the cuts were made, and I will miss a few frames at the re-commencement of the program.
I can't figure out why the cuts are out by 8 frames, unless it is due to using a DVB-T recording that might contain dropped frames and comskip looses track of the actual frame numbers? Or is there something odd about DVR-MS files and frame numbers?
Any suggestions as to what might be causing this, or where I might look for the cause/solution?
Otherwise, Comskip is working perfectly...
However, I have noticed that the output cut list shows the cut points to be 8 frames later than I think they should be.
For example, at the beginning of a commercial break (during the black period) Comskip will mark the cut point at frame 6,008 - but when I view that area in VideReDo, I can see that the middle of the black period is at frame 6,000 and that frame 6,008 includes some of the first frames of the commercial. Similarly, at the end of the commercial break, the centre of the black period is frame 8,000 - but Comskip outputs the cut at 8,008 which includes the first few frames of the re-commencement of the program.
Eight frames doesn't sound like a big deal, but what it means is that when I watch the "cleaned" video, a flash of commercial will appear where the cuts were made, and I will miss a few frames at the re-commencement of the program.
I can't figure out why the cuts are out by 8 frames, unless it is due to using a DVB-T recording that might contain dropped frames and comskip looses track of the actual frame numbers? Or is there something odd about DVR-MS files and frame numbers?
Any suggestions as to what might be causing this, or where I might look for the cause/solution?
Otherwise, Comskip is working perfectly...
-
- Posts: 116
- Joined: Sun May 14, 2006 9:15 am
I have the same problem but never found a resolution. See http://www.videoredo.net/msgBoard/showt ... ht=comskip
Thanks for the update kerry - its a shame that the thread at VRD stopped back in May, as I would like to get this resolved, too....
So it appears to be a discrepency between how Comskip counts frames and how VRD counts the same frames?
But we don't know which one is correct - Comskip or VRD?
Given that the discrepency does exist, it would be nice to be able to tweak Comskip or VRD back into alignment, but I guess that would only work if there was a constant mis-alignment? I am seeing 8 frames different, but you are seeing 4 frames - correct?
Have you done anymore testing to get to the real cause of this discrepency?
So it appears to be a discrepency between how Comskip counts frames and how VRD counts the same frames?
But we don't know which one is correct - Comskip or VRD?
Given that the discrepency does exist, it would be nice to be able to tweak Comskip or VRD back into alignment, but I guess that would only work if there was a constant mis-alignment? I am seeing 8 frames different, but you are seeing 4 frames - correct?
Have you done anymore testing to get to the real cause of this discrepency?
The PTS of the MPEG video stream is used by comskip to determine where it is inside the recording.
Missing mpeg frames, due to corruption of the transmission, are compensated for.
A constant offset of 4 or 8 frames would imply something wrong at the very start of the PTS to frame number initialisation.
If this is indeed constant for a certain environment then it would not be too difficult to have a setting to compensate for this.
My family actually likes a sub second commercial. We allway shout "no commercials anymore"
I may consider to implement this
Missing mpeg frames, due to corruption of the transmission, are compensated for.
A constant offset of 4 or 8 frames would imply something wrong at the very start of the PTS to frame number initialisation.
If this is indeed constant for a certain environment then it would not be too difficult to have a setting to compensate for this.
My family actually likes a sub second commercial. We allway shout "no commercials anymore"
I may consider to implement this
Hi Erik,
Yes, seeing a few frames of a commercial is no big deal, and it reminds you that you don't have to watch the next 3 to 5 minutes of commercials....
I will do some more testing to see if it is indeed always 8 frames of discrepency for me. If the number of frames of discrepency varies with each recording, then a fixed compensation would not help.
At least I now know it is not something that I was doing wrong....
Yes, seeing a few frames of a commercial is no big deal, and it reminds you that you don't have to watch the next 3 to 5 minutes of commercials....
I will do some more testing to see if it is indeed always 8 frames of discrepency for me. If the number of frames of discrepency varies with each recording, then a fixed compensation would not help.
At least I now know it is not something that I was doing wrong....
The reason we see some commercial is because we use a GOP based cutter.
Minimum cut resolution is one second so that is 25 frames.
That is the reason why I never bothered to be VERY accurate (read: exactly correct at the start or end of a black frame sequence)
But loosing the first 10 frames of the show could indeed be a problem.
Minimum cut resolution is one second so that is 25 frames.
That is the reason why I never bothered to be VERY accurate (read: exactly correct at the start or end of a black frame sequence)
But loosing the first 10 frames of the show could indeed be a problem.
I use VideoRedo Plus (VRD) to do the actual cutting as I understood that it is "frame accurate".
VRD does actually cut on the precise frame (irrespective of the frame being an I, B or P frame), but it looks like VRD calculates the actual frame number differently to the way that Comskip calculates the actual frame number - hence the discrepency of 8 frames?
For example, the output from Comskip will be to cut at frame number 2,500 which VRD will do - but frame 2,500 within VRD is 8 frames further along the video than what Comskip intended.....
I hope that makes sense?
VRD does actually cut on the precise frame (irrespective of the frame being an I, B or P frame), but it looks like VRD calculates the actual frame number differently to the way that Comskip calculates the actual frame number - hence the discrepency of 8 frames?
For example, the output from Comskip will be to cut at frame number 2,500 which VRD will do - but frame 2,500 within VRD is 8 frames further along the video than what Comskip intended.....
I hope that makes sense?
Could you do the following test.
Take a recording where Comskip has found errors in the timeline due to missing MPEG video frames and has "repaired" the timeline.
Look in the log file what frames ar missing (that is where the "jump" occurs)
Open the file in videoredo and move the the frame number where the jump should occur.
Singestep through the sequence and check if videoredo also makes the jump in frame numbers.
If videoredo does not make the jump but only counts the present frames there is a problem in frame number consistency.
I know Womble MPEGVCR implements the jump, meaning they look, just like Comskip, to the actual PTS and calculate from there the frame number.
Most video players also look at the PTS and "insert" the missing video frames in the timeline.
Take a recording where Comskip has found errors in the timeline due to missing MPEG video frames and has "repaired" the timeline.
Look in the log file what frames ar missing (that is where the "jump" occurs)
Open the file in videoredo and move the the frame number where the jump should occur.
Singestep through the sequence and check if videoredo also makes the jump in frame numbers.
If videoredo does not make the jump but only counts the present frames there is a problem in frame number consistency.
I know Womble MPEGVCR implements the jump, meaning they look, just like Comskip, to the actual PTS and calculate from there the frame number.
Most video players also look at the PTS and "insert" the missing video frames in the timeline.
Here's an example video file with timeline corrections (comskip log file output):-
Audio PTS jumped 20 frames at frame 103909, repairing timeline
Video PTS jumped 11 frames, repairing timeline
when I try to move to frame 103909 in VRD, the nearest I can get to is 103911. Then when I try to move to the next frame, VRD skips to frame 103933 - ahead by 21 frames....
I am doing this testing on a DVR-MS file. Maybe I should repeat it after I have used VRD to strip the DVR-MS wrapper off the file and to do a "Quick Stream Fix", before I pass it through Comskip? I understand that a VRD "Quick Stream Fix" will correct the timeline for missing frames, so that both Comskip and VRD would then be working with the same frame numbers? Does that make sense?
Audio PTS jumped 20 frames at frame 103909, repairing timeline
Video PTS jumped 11 frames, repairing timeline
when I try to move to frame 103909 in VRD, the nearest I can get to is 103911. Then when I try to move to the next frame, VRD skips to frame 103933 - ahead by 21 frames....
I am doing this testing on a DVR-MS file. Maybe I should repeat it after I have used VRD to strip the DVR-MS wrapper off the file and to do a "Quick Stream Fix", before I pass it through Comskip? I understand that a VRD "Quick Stream Fix" will correct the timeline for missing frames, so that both Comskip and VRD would then be working with the same frame numbers? Does that make sense?
Results of some more testing....
I ran the above DVR-MS file (recorded from a DVB-T broadcast) through VRD first as a "Quick Stream Fix", which also removed the DVR-MS wrapper.
I then ran Comskip against the "cleaned" MPG file and checked the commercial cut points. While still not perfect, it looks like the cut points are now within a couple of frames of the ideal centre of the black period, and would be visibly acceptable....
So, it looks like I need to "clean" the DVR-MS file with VRD first and create a mpg file, then run Comskip against the mpg file, and finally use VRD to remove (cut) the commercials and create a finished mpg file.
I ran the above DVR-MS file (recorded from a DVB-T broadcast) through VRD first as a "Quick Stream Fix", which also removed the DVR-MS wrapper.
I then ran Comskip against the "cleaned" MPG file and checked the commercial cut points. While still not perfect, it looks like the cut points are now within a couple of frames of the ideal centre of the black period, and would be visibly acceptable....
So, it looks like I need to "clean" the DVR-MS file with VRD first and create a mpg file, then run Comskip against the mpg file, and finally use VRD to remove (cut) the commercials and create a finished mpg file.
I just checked another DVR-MS file and the cut points look OK, so I don't think it is related to the DVR-MS wrapper.
I think that the original "8-frame delay" was a result of dropped frames in the source DVR-MS file. Once I "cleaned" the DVR-MS file with VRD's "QuickStream Fix" and then ran Comskip, it was much better.
So, I don't think you need to make any changes to Comskip. I will setup my process steps so that the recorded file is QuickStream Fixed first to correct for any dropped frames, and then run Comskip against the fixed file.
Thanks for your advice.....
I think that the original "8-frame delay" was a result of dropped frames in the source DVR-MS file. Once I "cleaned" the DVR-MS file with VRD's "QuickStream Fix" and then ran Comskip, it was much better.
So, I don't think you need to make any changes to Comskip. I will setup my process steps so that the recorded file is QuickStream Fixed first to correct for any dropped frames, and then run Comskip against the fixed file.
Thanks for your advice.....
More VRD-Comskip comparison on .dvr-ms files
I've been trying much the same comparison using the latest VideoRedo and Comskip versions on .dvr-ms (US broadcast ATSC) recordings produced by Vista RC2 Media Center. The software seems to run fine on Vista, which is great. I previously used comskip on BTV 4.4 .tp files
By carefully studying the csv spreadsheet and comparing with the VideoReDo window, I found that the video frame numbers were out by 17 (in the beginning) and 18 (towards the end). Comskip also showed an audio-video offset, apparent at advert breaks, of 20 to 24 frames (VRD seemed okay, although at a couple of points there may have been an audio-video lag of about 3 frames; it was hard to tell). Hence, for one advert break, an identifiable frame in VRD was at 47583, but was in Comskip output at 47601 (based on brightness and uniformity) or 47626 (based on sound).
Both of these lags make it problematic to use Comskip for automatic commericial skipping. I am currently trying to run QuickStream Fix first, but I'm having problems with this on .dvr-ms files under Vista, so my report will have to wait.
I do have an Excel spreadsheet (edited version of the .csv spreadsheet) and .dvr-ms file I can send to you, if it's of interest. However, as the video is 4.3 GBytes, it might take some time to upload (estimated about 18 hours if you have enough bandwidth at your end), and so this might not be advisable. I will write it to DVD and post it if it's of value.
Cheers,
-Karl
By carefully studying the csv spreadsheet and comparing with the VideoReDo window, I found that the video frame numbers were out by 17 (in the beginning) and 18 (towards the end). Comskip also showed an audio-video offset, apparent at advert breaks, of 20 to 24 frames (VRD seemed okay, although at a couple of points there may have been an audio-video lag of about 3 frames; it was hard to tell). Hence, for one advert break, an identifiable frame in VRD was at 47583, but was in Comskip output at 47601 (based on brightness and uniformity) or 47626 (based on sound).
Both of these lags make it problematic to use Comskip for automatic commericial skipping. I am currently trying to run QuickStream Fix first, but I'm having problems with this on .dvr-ms files under Vista, so my report will have to wait.
I do have an Excel spreadsheet (edited version of the .csv spreadsheet) and .dvr-ms file I can send to you, if it's of interest. However, as the video is 4.3 GBytes, it might take some time to upload (estimated about 18 hours if you have enough bandwidth at your end), and so this might not be advisable. I will write it to DVD and post it if it's of value.
Cheers,
-Karl
No need to send me the whol dvr-ms file now, lets first use some of the already available tricks.
First there is a setting to correct the audio-video delay
ms_audio_delay=5 ; Amount of frames to delay audio to video in dvr-ms
Did you try to change that setting?
On certain recorings I found the setting has to be 5, on others it had to be 20.
Could you try the effect?
Next, could you mail me the log file of the dvr-ms recording you analysed made with
verbose=10
I am particulary interrested in message like these
Don't send me the log of the analysis of the csv file because that has lost the "jumped" info.
Also mail me the zipped .csv, your comskip.ini and a corrected .txt file so we have common reference.
It would be nice if you could cut the first say 100mbyte of the dvr-ms file and upload it to my ftp server.
That will help me to diagnose the initial offset error.
First there is a setting to correct the audio-video delay
ms_audio_delay=5 ; Amount of frames to delay audio to video in dvr-ms
Did you try to change that setting?
On certain recorings I found the setting has to be 5, on others it had to be 20.
Could you try the effect?
Next, could you mail me the log file of the dvr-ms recording you analysed made with
verbose=10
I am particulary interrested in message like these
Because that is where things may go wrong.Video PTS jumped 1 frames, repairing timeline
Audio PTS jumped 1 frames at frame 7, repairing timeline
Video PTS jumped 2 frames, repairing timeline
Don't send me the log of the analysis of the csv file because that has lost the "jumped" info.
Also mail me the zipped .csv, your comskip.ini and a corrected .txt file so we have common reference.
It would be nice if you could cut the first say 100mbyte of the dvr-ms file and upload it to my ftp server.
That will help me to diagnose the initial offset error.