Comskip, EDL files and mencoder

[stattik]

Hi Erik,

When mencoder reads a ts file, it reads the timestamps in the file rather that starting from zero at the beginning of the file and counting up. A typical TS EDL file made by mplayer looks like this...

Code: Select all

55410.500000 55427.148438 0
55432.355469 55563.750000 0

Would it be possible for comskip to read these same timestamps when writing an EDL file?

Thanks.

[erik]

Yes, should not be a problem. will put it on the todo list.

[stattik]

Thanks Erik.

[erik]

There is a small problem.
When trying this with an actual TS file I can not understand how mencoder makes the calculation between a PTS value and the time value in the EDL file.

Normally it should be PTS/90000 = time in seconds but......
There is a unexplainable offset. Or the PTS calculation I do in comskip is wrong.
Any clues someone? Or a small TS file with well understood PTS starting value?

[erik]

Solved, and fixed a bug in the PTS decoder.

Do try build 79.97
Please take notice of the readme.txt file and set
enable_mencoder_pts=1
in your ini file.

[kerryklarson]

Solved, and fixed a bug in the PTS decoder.

Erik, could this be used for the VideoRedo frame discrepancy? Thanks.

[erik]

In my test streams I did not notice any difference in frame numbers but then I did not test with different settings of max_repair_size.
The PTS decoder error was related to an incorrect wrap around of the PTS.

[stattik]

Thanks for the quick turnaround Erik. I'll be testing it out today.

Just curious, how is the new EDL created? Does comskip follow the actual PTS values on the marked frame of does comskip use the initial PTS value to modify the original edl values to the new ones?

The reason I ask is because it may help the issue I've been having with preview mode switching from PTS based positioning to byterate based
framenumber interpolation when there is a "likely" error in the timeline.

Thanks again. I'll be back with results.

[erik]

I use the initial PTS.
Comskip decodes the mpeg and counts the actual present frames when max_repair_size is set to zero. So continuity errors are not detected.
However when max_repair_size is set to a positive value (40 or 200) then comskip reads the PTS and inserts dummy frames when frames are missing.

But...
On very large continuity problems (bigger then 1000 frames) the only solution would be to reconstruct a timeline, this is ok when processing the whole mpeg but very slow when doing a review. Of course it can be done but the effort is big.
I also can disabling the switching to softseeking (byterate based) but that is not sure to converge in al cases.

[stattik]

I have some initial results and they look good. So far I've only been able to record pillarboxed shows (old sitcom reruns) but comkip looks accurate. I'll hopefully be trying a full HD show tomorrow. I did find one odd result though. I ended up with an EDL file that had negative values...

Code: Select all

-1704.17	-1619.75	0
-1120.38	-940.37	0
-617.55	-441.27	0
-98.43	52.12	0
147.12	147.15	0

mencoder crashed when it tried reading the file. I'm guessing the PTS numbering restarted sometime during the show? I can upload the file if needed. (823MB)

[erik]

Could you upload the file?
I hope I only need till after the first commercial

[stattik]

It's uploading now.

[erik]

I tried your file.
This is the EDL

Code: Select all

93739.58	93823.87	0
94323.23	94503.25	0
94972.05	95002.35	0
95345.19	95375.62	0
95590.73	95590.77	0

No negative numbers.
I see you run on an AMD processor. I do not have access to an AMD processor, could you test on an Intel?

[stattik]

I tried it with a P4 and came up with the same negative numbers. I can try it again with a Pentium-M later today. I uploaded my comskip.ini to the FTP server.

[erik]

Will test also here.