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
No comments:
Post a Comment