Comskip Support Forum

Comskip is a free commercial detector, browse the forum for more information
It is currently Tue Sep 18, 2018 6:04 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Tue Nov 05, 2013 12:07 pm 
Offline

Joined: Tue Nov 05, 2013 11:32 am
Posts: 3
Sometimes (have yet to see a pattern?) the frames in the output txt-file goes waay off.
I think it only happens on a HD channel?
There seems to be an offset added to the frame numbers?
The result towards the end in the log file seems ok, though.

Example txt-file:
Code:
FILE PROCESSING COMPLETE  76730 FRAMES AT  2500
-------------------
2431184   2432952
2438396   2440148
2448080   2449715
2462846   2462847

From the log-file:
Code:
   ---------------------
   Initial Commercial List
   ---------------------
 0)  45067    46835   0:01:10.71
 1)  52279    54031   0:01:10.07
 2)  61963    63598   0:01:05.39
No change

Somehow, 2386117 gets added to each frame number in the txt file?

If I re-run manually, there is still the same offset.

Most of the time, Comskip works very well.

Using comskip81_056_donators with default settings together with Comskip Monitored on MediaPortal 1.5.0.

Any ideas..?

Edit:
Ok, I tried to post the complete log file in a separate post, but it was too big to be accepted.
I zipped the files instead:
Code:
http://www.hagastrom.se/comskipexample.zip

It is the show called _1 that has failed. The other one worked ok. These were two example recordings I made to gather test data. And no, I don't normally watch "Hem till gÄrden"... :roll:


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 05, 2013 7:26 pm 
Offline
Site Admin

Joined: Sun Aug 21, 2005 3:49 pm
Posts: 3209
Would you be able to upload the failing recording to my FTP server?


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 05, 2013 11:30 pm 
Offline

Joined: Tue Nov 05, 2013 11:32 am
Posts: 3
I have three recordings that gives this strange result, with frame counts above 2 million.
PM me about ftp details, and I will upload the smallest one; about 3 GB. I only have 5 mbit upstream, so it will take a while...

I also checked the results in older recordings:

During 2009 and 2010, the numbers in the txt file and the "Initial Commercial List" section in the log are always the same. These were made with an older version of Comskip, obviously.

More recent recordings have an added offset of between 4 and 14 frames in the txt file, compared to the values in the log file. The offset has been the same for all the "skips" in one recording, but seem to differ between recordings?

Since I discovered this "2 million frames phenomena" the other day, I've recorded several programs from that HD channel.

Most of these result in a txt file that seems ok, ie frame numbers within the file. However, comparing the txt file and the values in the log show strange results:

Code:
FILE PROCESSING COMPLETE 135189 FRAMES AT  2500
-------------------
3260   8594
24837   32285
49248   56514
90141   97967
123014   130388
136341   136478

   ---------------------
   Initial Commercial List
   ---------------------
 0)   2173     7502   0:03:33.36
 1)  23725    31159   0:04:57.91
 2)  48074    55319   0:04:50.64
 3)  88905    96712   0:05:13.04
 4) 121746   129099   0:04:54.95
 5) 135052   135190   0:00:05.48
1087
1112
1174
1236
1268
1289
The offset increases for each skip, to a point where the last skip point in the txt file is beyond the last frame: 136341, file length 135189 frames.

Another example, where the txt file results are beyond the file length:
Code:
FILE PROCESSING COMPLETE  25057 FRAMES AT  2500
-------------------
50780   52603
61439   61473

   ---------------------
   Initial Commercial List
   ---------------------
 0)  14364    16187   0:01:12.91
 1)  25023    25058   0:00:01.35

What additional processing is made after the log file is finished, and the txt file is written..?


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 06, 2013 7:16 am 
Offline

Joined: Tue Nov 05, 2013 11:32 am
Posts: 3
So I re-processed a couple of those recordings. It turns out the initial txt file was most correct, after all!
Code:
FILE PROCESSING COMPLETE 136466 FRAMES AT  2500
-------------------
3260   8594
24837   32285
49248   56512
90143   97969
123016   130390
136343   136480

   ---------------------
   Initial Commercial List
   ---------------------
 0)   3246     8580   0:03:33.36
 1)  24823    32271   0:04:57.91
 2)  49234    56498   0:04:50.55
 3)  90129    97955   0:05:13.03
 4) 123002   130376   0:04:54.95
 5) 136329   136467   0:00:05.47

The initial run was made while recording: "Launch at recording start". Maybe that is not reliable enough..?

The recordings with 2 million frames are the same, though.


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 06, 2013 9:22 am 
Offline
Site Admin

Joined: Sun Aug 21, 2005 3:49 pm
Posts: 3209
Could you set in your comskip.ini

output_timing=1

Rerun comskip on the 2 million frames and send me the generated ....timing.csv file?


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 12, 2013 4:40 am 
Offline

Joined: Thu Dec 12, 2013 4:25 am
Posts: 3
I'm having the same problem, although not to this extent. Mine are shifted a handful of frames - just enough to be annoying. I was testing it by cutting a file into smaller pieces using VideoRedo. In every case the shorter recording resulted in a correct txt file with no offset. So I just fed the entire recording through VideoRedo and the resulting txt file had no offset. I don't know what VideoRedo does (the file size isn't exactly the same, so there is some modification), but whatever it is causes Comskip to not insert the offset. Looking at the ...timing.csv for both files shows one starting at what looks like the offset frame, while the other starts at 1.

One that works:
Code:
type      dts            pts            clock          delta          offset
v clock   0   0   0   0   0
v  free   1   1   1   0   0
v  free   2   2   2   0   0
v  free   3   3   3   0   0
v  free   4   4   4   0   0


One that doesn't:
Code:
type      dts            pts            clock          delta          offset
v  init 11   11   11   0   0
v  free   12   12   12   0   0
v  free   13   13   13   0   0
v  free   14   14   14   0   0
v  free   15   15   15   0   0


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 12, 2013 7:42 am 
Offline
Site Admin

Joined: Sun Aug 21, 2005 3:49 pm
Posts: 3209
I found its a error in the decoding library I am using where the initial frame PTS is wrong.
I implemented some workaround and plan to release that soon.


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 20, 2013 6:41 am 
Offline

Joined: Thu Dec 12, 2013 4:25 am
Posts: 3
That's great! This was driving me nuts. I thought there was a setting or something somewhere I was missing.


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 22, 2013 11:18 am 
Offline
Site Admin

Joined: Sun Aug 21, 2005 3:49 pm
Posts: 3209
Can you test build 0.81.57 released today?


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 22, 2013 8:01 pm 
Offline

Joined: Thu Dec 12, 2013 4:25 am
Posts: 3
0.81.57 gives the same results as 0.81.56 (I noticed that the file sizes for comskip.exe were identical for the two builds, though).

I know that it used to work perfectly, so I ran the same files through 0.81.43. That build does indeed work perfectly, and the txt and log files are the same.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group