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.
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
