then some buffer on the receive side will overflow eventually.
Here's an 11 minute stream to test with. It's muxed at the same rate as
adv16apsk910.ts.
http://www.w6rz.net/thecooler16apsk.ts
Most likely the RX8200 is releasing the IP stream at a rate based on the
PTS's (Presentation Time Stamp) of the video or audio stream, which is
why VLC plays okay.
Ron
On 10/25/2017 12:53 AM, Marcus Müller wrote:
> 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
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment