[libdvbpsi-devel] TS files that has PCR hickups

[Morgan Tørvolt]

> Sure. It happens on literally any DVD I use. I use the gui, but the
> command should be something like this:
> vlc --sout=#duplicate{dst=std{access=file,mux=ts,dst="test.ts"}} --sout-all

Sorry, my bad, the command line in Linux is:
vlc dvd:///dev/scd0@1:2
"--sout=#duplicate{dst=std{access=file,mux=ts,dst="test2.ts"}}"
--sout-all

>  > I would recommend that you run dvbsnoop (dvbsnoop.sf.net) on it. Use
>  >  the dump from this tool to look at the timestamps [ scripts helps here
>  >  :) ]. It also prints out a lot of other information which may help you
>  >  trace the problem. From what I'm looking at, I have a reasonable
>  >  confidence in your tool -- but it never hurts to double check.
>
>
> Of course =)
>  I am pretty certain that what I have found is correct, because I have
>  been reading the bitstream pretty much bit for bit. A second opinion
>  would of course eliminate the poblem being a classic "pebkac", so I
>  will do that =)

I have verified that I find the exact same problems using DVB-snoop.
DVB-snoop does this properly, shifting the bits one bit left, adding
the 33. bit, so the HEX values looks completely different from mine,
but checking the bits one by one, I find that it is the same. This is
"grep program_clock_reference_base" on the result from dvbsnoop:

        program_clock_reference_base: 0x0dd712508
        program_clock_reference_base: 0x0dd713c94
        program_clock_reference_base: 0x0dd715544
        program_clock_reference_base: 0x0dd716df3
        program_clock_reference_base: 0x0dd7186c1
        program_clock_reference_base: 0x0dd719f94
        program_clock_reference_base: 0x0dd71b7db
        program_clock_reference_base: 0x0dd71d0cd
        program_clock_reference_base: 0x0dd71e9bf
        program_clock_reference_base: 0x0dd7201c5
        program_clock_reference_base: 0x0dd721ae1
        program_clock_reference_base: 0x0dd7233e1
        program_clock_reference_base: 0x0dd724bc7
        program_clock_reference_base: 0x0dd72646a
        program_clock_reference_base: 0x0dd727d0c
        program_clock_reference_base: 0x0dd714219
        program_clock_reference_base: 0x0dd71f064
        program_clock_reference_base: 0x0dd729eb0
        program_clock_reference_base: 0x0dd72dfb6
        program_clock_reference_base: 0x0dd72f89d
        program_clock_reference_base: 0x0dd731183
        program_clock_reference_base: 0x0dd7329af
        program_clock_reference_base: 0x0dd7342b4
        program_clock_reference_base: 0x0dd735b23
        program_clock_reference_base: 0x0dd7373c7
        program_clock_reference_base: 0x0dd738c6c
        program_clock_reference_base: 0x0dd73a50a
        program_clock_reference_base: 0x0dd73bdef
        program_clock_reference_base: 0x0dd73d6e3
        program_clock_reference_base: 0x0dd73ef17
        program_clock_reference_base: 0x0dd7407fb

As you can see, it goes to dd72xxxx, then returns to dd71xxxx for a
brief moment the return back to dd72xxxx and continuing on. This is
the same spot where my tool finds this problem.

I have now also made two dumps of the same DVD in linux, and one in
windows. None are exactly the same, as the PCR time differs from file
to file. It seems to be using system time since boot or something like
that to set the timestamps. The actual content of the TS packets are
the same it seems, only the timestamps differs (PCR and DTS in the
video PES packets)

I can confirm though, that the first PCR error does occur in all of
the three copies at the exact same length from the beginning of the
file (in seconds and bytes), so it seems to be consistent across OS
and time.

Any ideas at this point?

Regards
Morgan