mencoder EDL processing and MPEG TS timestamps

[jens]

Hi,

I was debugging several files where MENCODER wouldn't cut out any commercials although the EDL file generated by COMSKIP was obviously correct. I figured out the cause for this when I started mplayer with the -edlout option: The timestamp in the recorded MPEG data didn't started at 0, but was off several 1000s.

MENCODER is using MPEG timestamps for EDL processing and requires EDL lists to contain "absolute" time information (as compared to time being "relative" to the start of the recording). A simple solution would be a config option to fix/adjust EDL lists for use with MENCODER by adding the "absolute" timestamp obtained from the first frame to the "relative" cut points.

Cheers,
Jens.

[erik]

This is already possible
set
output_edlp=1
and the generated edl file wil use the first PTS as the starting PTS (see readme.txt in distribution zip file)

[jens]

Neither output_edlp nor enable_mencoder_pts gave useable results I've send you some log files and the resulting cut lists in private email. I have also included ".edlout" files obtained by playing the dvr-ms with mplayer and pressing 'i' at the beginning and again a few minutes into the recording.

17_06_2008_23_58_01 seems to have timestamps starting at 0 and cuts OK. EDLP is off 0.96 seconds???

18_05_2008_19_59_02 seems to have timestamps starting around ~11635s. EDLP is off 1.11s compared to EDL/XML.

18_05_2008_21_59_02 seems to have timestamps starting around ~18835s (makes sense, 2h=7200s later). EDLP is off 1.12s compared to EDL/XML.

18_05_2008_23_59_02 seems to have timestamps starting around 26035s (another 2h later). EDLP is off 0.24s compared to EDL/XML.


Recordings are all over 1GB...

[jens]

PS: Instead of a file with .EDLP extension, I would rather like to see the values in the .EDL file "fixed" as MCEBuddy (which I am using) isn't flexible enough to be redirected to a different file

[erik]

enable_mencoder_pts was been disabled but I have enabled it again for you in build 143 so you send have the pts offset in the edl output file.

edlp files are exactly like edl output except that the initial PTS is always added to the time codes.
when
enable_mencoder_pts=1
is set the edl file should give the same as the edlp file.
The difference between edl without enable_mencoder_pts and edlp (edl with enable_mencoder_pts) is the offset caused by the initial_pts.
The detection of the initial PTS can be implemented in many ways.
If you want to know how the detection works you can set
output_timing=1
this will cause comskip to generate a large .timing.csv file that contains the exact information on how the timeline was decoded for both audio and video and how the initial pts was calculated.
dvr-ms recordings have far worse PTS information so I strongly recommend to record in mpeg Program Stream (.mpg extension) or mpeg Transport Stream (.ts).

[jens]

Your upload seems to have failed (0 bytes)

[erik]

Stupid firewalls....
Solved.

[jens]

Hi Erik,

apologies I couldnt test your build earlier. Strangely, build 143 gives results identically to those I posted earlier, i.e.

(1) the EDLP files show a strange offset (around 1s) but do not reflect the PTS seen by mencoder/mplayer

(2) EDL files are different from EDLP (the offset is always 0) independent of the setting for enable_mencoder_pts

If the log file wouldn't report 0.79.143, I would assume that I use an old build, but I have double-checked pathes, logged config file settings etc.

I will email you a download location.

[phredeaux]

Hello, I'm interested in this being resolved as well as I've reproduced the same issue with large DVR-MS recordings (I'm the MCEBuddy author). I'll try to verify the issue also occurs with MPEG2. Has anyone got anywhere with this

[erik]

The 1 second offset is caused by problems finding the initial PTS which should be 0 but my algorithm does not work very well.