Hi Kai,
On 2017-10-24 23:40, Kai-Uwe Storek wrote:
Hey folks,
this is just a request for enlightenment. :-)
granted.
(Just kidding, who am I to decide who is enlightened and who's not?
It's Wednesday, so it's Ron's turn to grant RfEs; CC:'ed.)
I was playing around with the dvb-s2 modulation blocks. I started with
the example graph dvs2_tx.grc and the example video (adv16apsk910.ts)
and an ursp. At the receiver side, I used an ericsson rx 8200.
I then increased the symbol rate and noticed three things:
1) The bit rate of the transport stream shown by the rx8200 increased
from 17 mbps to 23 mbps (which is in line with rates calculated via
[1]).
2) A rate probe between the file source block and the BBheader block
shows an increased rate: From 2.1e6 (2.1 megabyte/s) to 2.9e6 (2.9
megabyte/s).
3) The shown video bit rate, analyzed by the rx 8200 (webgui) as well
as by VLC, that plays the transport stream which is distributed by the
rx 8200 via ip multicast, does *not* increase.
That's because the idea is that the MPEG transport stream that gets
transmitted is just padded to be of the constant over-the-air rate.
4) The playback of the video with VLC works pretty well in both cases.
Especially 3) is very convenient because a user of these gnuradio
blocks must only ensure that the rate of the DVB-S2 stream, determined
by symbol rate, modulation and coding, is higher than the necessary
video bitrate and everything is fine. :-)
exactly!
Here is my question:
With an increased symbol rate I noticed an increased "reading speed"
of source file / video ( 1) ). With my understanding this is a
contradiction. On one side, the video bit rate seems constant (Rx8200,
VLC) for both symbolsrates tested (which is intuitive right, because
the video does not need "more" bandwidth), but on the other side, the
video data are read out faster by the file source.
So, if you increase the symbol rate and hence the over-the-air byte
rate, you're supposed to increase the muxrate in your MPEG .ts file, I
think; ffmpeg lets you do that nicely with the -muxrate option.
So, where is the magic? Who is handling the rate adaption? Where are
the video bytes going that are "overread" by the file source in case
of an increases symbol rate?
I thought the magic here is actually buffering by VLC, but as you
already investigated:
A buffer on the receiver side is not the solution, because VLC stops
immediately when I stop the Tx flowgraph.
Hm, there goes my hypothesis, unless your RX8200 buffers itself but
stops streaming that buffered data immediately the moment it detects a
lack of satellite TX. I wouldn't know why it'd do that.
Hopefully, someone can point me in the right direction.
Sorry about my not-so-much right direction.
Best regards,
Marcus