Re: genlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux