[mythtv-users] Unusual PTS-related problem with Project-X and a recent BBC FOUR recording

[John Pilkington]

Hi: I routinely use my mythcutprojectx script to do basic cleaning and 
editing of recordings; over the last year around 5000 times (SD from 
dvb-t in the UK)

A recent recording of 'BBC Prom 11' emerged with a length of about 35 
minutes instead of the expected 80 minutes.  The Project-X log showed 
that this was because the PTS had been set back, from around 51 minutes 
to 6 minutes, about 33 minutes into the output file.  All subsequent 
GOPs were then dropped until the restarted PTS exceeded its earlier value.

I was able to create an almost complete recording by running the script 
twice, with cutlists set entirely before and entirely after the PTS 
reset, and using Project-X to rejoin the files.  Probably not worth the 
effort, but an interesting exercise.

I had seen an effect like this earlier when trying to process mpeg2 
files joined using cat. This was the first time I had seen it on air, 
but Google found a very similar reference from 2005.

http://forum.dvbtechnics.info/archive/index.php/t-1591.html

------------
There's a Project-X update here:

http://project-x.cvs.sourceforge.net/project-x/Project-X/

Download latest GNU tarball from the foot of the page.

ProjectX 0.91.0.01/01.08.2011 TEST PROJECT ONLY
----------

and this is a section of the log:

-> special PIDs for searching defined: { 0xC9 0x191 }
!> missing sync. byte @ 275124724
!> found sync. byte @ 275124840
ok> PID 0x00C9 has PES-ID 0xE0 (MPEG Video) (275128788 #22)
ok> PID 0x0191 has PES-ID 0xC0 (MPEG Audio) (275149092 #130)
-> cut-in @ GOP# 7 / new vframe 0 / new Timecode 00:00:00.000 (277489692)
-> video basics: 720*576 @ 25fps @ 0.7031 (16:9) @ 15000000 bps - vbv 112
-> starting export of video data @ GOP# 7
!> dropping useless B-Frames @ GOP# 7 / new Timecode 00:00:00.000
!> PID 0x0191 -> packet 7212094 @ pos. 1630998324 out of sequence (7/8) 
(shifting counter..) (~00:32:55.000)

There was some mild picture corruption here.  I don't know if it was as 
transmitted, or a receiving artefact. Perhaps the 'shortening' did 
something?

!> packet writing: length index out of bounds, shortened.. (191 / c0 / 
c0 / 16489 -- 2934 / 14 / 3840) @ PTS 00:51:14.276
!> ID 0xC0 (sub 0x0) packet# 16490, big PTS difference: this 34884196, 
prev. 276684859
!> dropping GOP# 4069 @ orig.PTS 00:51:14.424 (276698173), errorcode: 24
!> Pics exp/cnt 12/13, inGOP PTS diff. -2686723ms, new Timecode 00:32:55.000
!> startPTS of GOP# 4070 is earlier than the end of last GOP.. (exp. 
276698173)
!> dropping GOP# 4070 @ orig.PTS 00:06:28.180 (34936235), errorcode: 10
!> Pics exp/cnt 12/12, inGOP PTS diff. 0ms, new Timecode 00:32:55.000
!> startPTS of GOP# 4071 is earlier than the end of last GOP.. (exp. 
276698173)
!> dropping GOP# 4071 @ orig.PTS 00:06:28.660 (34979435), errorcode: 10
!> Pics exp/cnt 15/15, inGOP PTS diff. 0ms, new Timecode 00:32:55.000