Hi On 15/01/07, Rainer Schubert <lintv@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 15 Jan 2007, Samuel Goto wrote: > Hi everyone,Any Hi Samuel, > I am developing a dvb s1 transmitter. Its input is a MPEG TS from a > mpeg encoder and its output is a DVB S1 stream to the RF satellite. OK. > I am having problems synchronizing the input bit rate to the output > baud rate and I was wondering if anyone could help me out on this list ( or > suggest me a better one =) ). The transmitter works for 7 to 8 minutes, but > then its output buffer overflows ( showing that there is a small difference > from the input rate to the necessary output rate ). The simplest way, I can think of, is to implement some kind of handshaking between the transmitter and your transmitting applikation. You should give the transmitter a chance to say "please stop sending data, until I am ready to receive more". It has been done on telephone modems in the past.
I think this is different from a modem. A modem does not often transmit live data. A mpeg encoder does. You cannot easily discard a part of an mpeg stream eighter. The number of bits required to encode a picture is very dependent upon the picture, and it is not possible to determine that exactly in advance. This means that you would require a large buffer if the bitrate goes too high for a moment, and this causes several problems. Firstly the PCR does not arrive at the correct time, reeking havoc with the internal clock of the reciever (which syncs on this), secondly, the decoder is supposed to get PES packets from the mpeg stream according to the DTS (decoding timestamp in the PES stream) which also get alot of jitter in this case. The result would be that most receivers would probably fail miserably at decoding the stream. My approach would be to lower the bitrate of the mpeg encoder to something that can fit within the transmitted carrier (ex. bandwidth - 100Kbit), then let the transmitting application request packets when it needs to send one (this makes sure that you get the exact right output bandwidth). If there is none available in the buffer from the encoder, it should get a stuffing packet instead. This would slightly increase the bandwidth of the stream, but would not cause any problems with eighter PCR, DTS, PTS or any other timestamps. Regards -Morgan-
> Thanks for your attention, > > Cya, Sam Regards, Rainer -- Rainer Schubert - Linux TV User Amateur Radio Call DL6HBO _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
