[MPlayer-dev-eng] Re: mpeg muxer & dvd pack scr

[Nico Sabbi]

Tobias Diedrich wrote:

>Nico Sabbi wrote:
>
>  
>
>>the SCR issue is much more complicate than this: at the moment it's 
>>determined
>>in terms of the dts; if you set it wrong it may (and very likely will) 
>>be in advance
>>of the PTS or it may be far from it.
>>Overall it's the most difficult term to manage in mpeg.
>>    
>>
>
>Well, iso138181 says "Program Clock Reference; PCS [system]: A time
>stamp in the Transport Stream from which decoder timing is derived".
>And "PCR(i) is the time encoded in the PCR field measured in units
>of the period of the 27 MHz system clock where i is the byte index
>of the final byte of the program_clock_reference_base field".
>Also "The value of the system clock frequency is measured in Hz and
>shall meet the following constraints: 27 000 000 - 810 <=
>system_clock_frequency <= 27 000 000 + 810, rate of change of
>system_clock_frequency with time 75*10^-3 Hz/s, Note - Sources of
>coded data should follow a tighter tolerance in order to facilitate
>compliant operation of consumer recorders and playback equipment"
>
>So AFAICS the PCR does not have to be synced with PTS or DTS,
>  
>

the pcr/scr  must follow one very important constraint:
SCR + 0.7 seconds <= [PD]TS

>instead it is synced with the rate that the data is supposed to be
>read from disc.
>And the mplex source says "Did they *really* need to put a 27Mhz
>clock source into the system stream.  Does anyone really need it for
>their decoders?  Get real... I guess they thought it might allow
>someone somewhere to save on a proper clock circuit."
>
>  
>

that's why I wrote it's unimportant

>>I don't have time to test your code right now (did you?), I'll do it 
>>when I'm back.
>>    
>>
>
>I did test it (but only the format=dvd case) and it produced nearly
>identical SCR as mplex and dvdauthor:
>
>pack  scr_base   scr_ext   scr
>0     0          0         0
>1     146        85        43885
>2     292        171       87771
>3     438        256 (257) 131656 (131657)
>4     585        42        175542
>5     731        128       219428
>6     877        214       263314
>7     1024       0         307200
>
>The values in brackets is where mplex uses a different value (due to
>rounding I guess).
>
>And this is from two dvds:
>pack  scr
>0     0
>1     43885 (43886)
>2     87771 (87772)
>3     131657 (131658)
>4     175542 (175544)
>5     219428 (219430)
>6     263314 (263316)
>7     307199 (307202)
>
>  
>

if you increase the scr with a fixed value that is bound to an 
unrealistic/nominal muxrate
(because it doesn't reflect the real one: audio+videp bitrates + overhead)
sooner or later if will fall too far apart from the [pd]ts and the above 
constraint
will be violated. At that point you should increase all of a sudden the 
scr to compensate
the delay.
You see much higher scr_increments in mencoder's output because the real 
muxrate
is much lower than 10.8 Mb/s: at all effects the real instant muxrate is 
used to
calculate the SCR increment (in terms of the bitrates of the duration of 
a/v data
you are writing; video is grouped in gops).
When I was in the early stages of development I used the 
nominal_muxrate, but I experienced
a lot of problems.

Additionally, the difference between the dts and the scr is a measure of 
the buffer fullness
of the demuxer's streams, which should never overflow (the current code 
doesn't
take care for this issue, either, but it's a thing that I'm planning to 
fix).

In any case I agree with you that the code to calculate the SCR must be 
rewritten.

    Nico