[Ffmpeg-devel] mpeg transport streams
Fri Jun 3 14:03:15 CEST 2005
Am 3 Jun 2005 um 10:22 hat M?ns Rullg?rd geschrieben:
> "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?
A warning is av_logged, if a ts-packet is written whose pes-packet has a pts < pcrbase -
50000. I understand, that this is not 100% correct, but since gops usually aren't bigger
than 50000 / 90000 seconds, I guessed this value isn't that far from reality. Speaking of
reality, I analized common dvb streams and found pts-pcr offsets of around 50000.
Adjusting that fixed value at the beginning of the encoding using gop-size and frame-
rate might be a future improvement.
> > 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.
I don't get your point. The decoder is forced to buffer data anyway until the pcr reaches
the pts. Since they might differ of about 50000 (> 100ms) I don't see any improvement
> > 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.
I wonder, if I implemented the standard right. My analizer says I didn't. But I have no
clue what's wrong. Our settop-box in fact does not care about it.
E-mail: marcus.hunger at mugler.de
Bitte nutzen Sie die E-Mail-Verbindung mit uns aus-
schliesslich zum Informationsaustausch. Wir koennen
auf diesem Wege keine rechtsgeschaeftlichen Erklaer-
ungen (Auftraege etc.) entgegennehmen. Der Inhalt
dieser Nachricht ist vertraulich und nur fuer den an-
gegebenen Empfaenger bestimmt. Jede Form der Kennt-
nisnahme und Weitergabe durch Dritte ist unzulaessig.
Sollte diese Nachricht nicht fuer Sie bestimmt sein,
so bitten wir Sie, sich mit uns per E-Mail oder
telefonisch in Verbindung zu setzen.
Please use your E-mail connection with us exclusively
for the exchange of information. We do not accept
legally binding declarations (orders, etc) by this means
of communication. The content of this message is
confidential and intended only for the recipient
indicated. Taking notice of this message or disclosure
by third parties is not permitted. In the event
that this message is not intended for you,
please contact us via E-mail or phone.
More information about the ffmpeg-devel