[FFmpeg-soc] [soc]: r1398 - dvbmuxer/mpegtsenc.c

[Baptiste Coudurier]

Hi

Michael Niedermayer wrote:
> Hi
> 
> On Fri, Oct 05, 2007 at 06:29:37PM +0200, Baptiste Coudurier wrote:
> 
>>Hi
>>
>>Michael Niedermayer wrote:
>>
>>>Hi
>>>
>>>On Fri, Oct 05, 2007 at 03:29:33PM +0200, bcoudurier wrote:
>>>
>>>>Author: bcoudurier
>>>>Date: Fri Oct  5 15:29:32 2007
>>>>New Revision: 1398
>>>>
>>>>Log:
>>>>use rc max rate only if it set, use bitrate if not, safer than (arbitrary?) big value for pcr computation
>>>
>>>the mux rate IIRC limits the maximum bitrates which can feed the video/audio
>>>(whatever they where called) buffers thus this change means that video must
>>>now be true CBR with min_rate=max_rate
>>>(or in other words this is a step from maybe compliant to certainly not mpeg
>>>compliant and is not useable for ffmpeg svn)
>>
>>Well considering mux_rate, in this ts muxer, is only used to compute
>>pcr/sdt/pat packets frequency and to calculate pcr, IMHO using average
>>bitrate would be better than using (1<<21)*8/s->nb_streams in terms of
>>errors.
> 
> 
> there must be no errors, a single error and you no longer have a mpeg stream
> but just random trash, to be called mpeg-ts/ps you must be compliant to the
> whole spec

Of course.

> how can an average (which can be arbitrary due to future not yet muxed data)
> be better than what it is currently?

Yes average is not exact, though it should be nearer correct value than
(1<<21)*8/s->nb_streams which has no sense in ts. Furthermore and I know
this not a proof of validity, elecard ts stream analayzer do not choke
on delta pcr errors anymore, even for vbr. So IMHO yes this is not
correct but it is better than what it was.

>>I think the same applies to mpeg ps muxer, which uses max_rate to
>>compute scr.
> 
> 
> the mpeg ps muxer stores the mux rate
> mpeg spec:
> -----
> Data from the Program Stream enters the system target decoder. The ith byte
> enters at time t(i). The time at which this byte enters the system target
> decoder can be recovered from the input stream by decoding the input system
> clock reference (SCR) fields and the program_mux_rate field encoded in the
> pack header.
> -----
> 
> so the program_mux_rate will have to be at least as large as the local
> bitrate (otherwise you would not be able to send these bits without
> underflowing the buffers)
> 
> 
> -----
> rate_bound -- A 22 bit field. The rate_bound is an integer value greater
> than or equal to the maximum value of the program_mux_rate field coded in
> any pack of the Program Stream. It may be used by a decoder to assess
> whether it is capable of decoding the entire stream.
> -----
> rate_bound is a global max of program_mux_rate
> your "suggestion" for the mpeg ps muxer simply sets rate_bound to an
> invalid value
> 
> that is about mpeg ps only
> for mpeg ts, well do whatever you like as long as the resulting stream is
> valid mpeg-ts

Yes, for PS it stores program_mux_rate in the system pack header.
What I meant is that ts is different from ps, and in TS there is no 22
bits field to store.

>>>also note that microsofts WMP is totally broken and its of no relevance if it
>>>can play a stream or not, they only must be compliant to what is written in
>>>the mpeg spec
>>
>>Oh yes, who cares about WMP ?
> 
> 
> when you write a MPEG muxer you have to follow the MPEG spec
> it specifies what MPEG-* is, that after all is the sense behind having a
> spec

Yes I totally agree with that.

> if you want to write a WMP-msformat muxer you can
> 
> you can even try to write a muxer which generates a stream which is
> valid mpeg and plays on wmp
> what you cannot is create a stream which violates the mpeg spec and
> pretent that it is mpeg
> 

Let's hope WMP can read compliant streams.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312