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

[Michael Niedermayer]

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
how can an average (which can be arbitrary due to future not yet muxed data)
be better than what it is currently?


> 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


> 
> > 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

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20071006/d614e243/attachment.pgp>