[Ffmpeg-devel] mpeg transport streams

Måns Rullgård mru
Fri Jun 3 10:22:15 CEST 2005


"Marcus Hunger" <marcus.hunger at mugler.de> writes:

> Am 1 Jun 2005 um 18:10 hat M?ns Rullg?rd geschrieben:
>
>> Could you explain the what theory of operation you have used?  What
>> are the changes you made to the demuxer?
>
> The main idea I wanted to implement was that the difference of two
> pcrs and the amount of data written between the accurrence of them
> define the actual bitrate. Assuming a constant bitrate is needed, this
> leads to two requirements:
>
> - there must be pcrs.

Not to mention that the standards is pretty strict about requiring
them, too.

> - the value of these pcrs must be calculated using a defined bitrate
> and the amount of data written since the previous pcr.

In a non-live muxer that is the only viable approach.

> Furthermore, pts/dts of the frame-data shouldn't be too much in front
> of the pcr to reduce caching demands on the player. So I orientated
> the pcrs written at the pts of actual frame. To still keep a constant
> bitrate, null-packets are inserted until the pcr equals about the pts.
>
> - null-packets
>
> Pts-values being in the past of pcrs don't make much sense, so every
> pts as increased by a constant offset (say 50000).
>
> - pts += 50000

The PCR must not reach the PTS of a frame until that frame has been
received and decoded.  Do you ensure this?

> To meet mpegts/dvb requirements of a maximum pcr-interval, a ts-packet
> with a pcr is written after a certain interval.
>
> - pcr-interval
>
> Frames do not get interleaved which should be no problem at high
> bitrates.

The problems caused by not interleaving frames do not depend on the
bitrate.  The thing is, a large video frame can easily take 100 ms to
transmit, which means that the decoder would have to buffer that
amount of audio data.  Many (hardware) decoder have much smaller
buffers than this.

> All bitrate/pcr algorithms are only done for video-frames, which
> should be changed to using the frames of the pcr-pid.
>
> The base of all timing is the amount of data written and the
> pts-values. The rtc of the pc is not used.
>
> I introduced setting a discontinuity indicator for the first pcr so
> concatenating ts-files should be possible. Doing this still causes
> cc-discontinuity-errors and I have no easy idea how to avoid them.

If you set the discontinuity indicator properly the demuxer should
ignore a discontinuity in the continuity counter.  I wouldn't be
surprised if many demuxers ignored the entire continuity issue.

> About the changes in the demuxer: I made these to tune into a certain
> dvb-service specified by it's name. The changes shouldn't break
> ffmpeg's current behaviour but I would agree in excluding it from this
> patch (if anyone complains).

Since the changes are separate, I think it's better to discuss them
separately.

-- 
M?ns Rullg?rd
mru at inprovide.com





More information about the ffmpeg-devel mailing list