Re: [Discuss-gnuradio] gr-dtv | DVB-S2 : video bitrate const while symbol rate increased

[Kai-Uwe Storek]

Dear Marcus and Ron,

thanks for your support!

The longer video file revealed some "forward jumps" in the video which
I did not recognize using the short example video with it's many
"jumps" and "cuts". Either the Rx8200 or VLC is buffering only a
portition before jumping to the most update-to-date PTS. Question
solved. :)

I would like to use the opportunity to thank for the great dvb-s2
implementation in gnuradio blocks which helps in my research project!
Since all commits on [1] are made by you Ron: thanks for sharing this
fine code with the world!

Two more things in addition (should I better write a new mail?):
- I noticed that the rx8200 did not lock for all mod/cods - e.g.
DVB-S2X 16APSK 7/9 did not work for me. Have you tested all modcods
with external hardware? If not, I can do some more modcod tests with
the rx8200.
- I would recommend (and also try to implement) a change in the dvb-s2
blocks concerning the parameter configuration: Everytime when I want
to change the modcod I have to configure nearly all dvb-s2 blocks
which is really tiring. :) Whats about an additional config field
(type raw) in every block? If filled with a struct or dict, the
parameters (modulation, coderate) are used from the struct/dict
instead of the  combo-boxes of the blocks?

Best regards,
Kai



2017-10-25 10:46 GMT+02:00 Ron Economos <address@hidden>:
> If you're sending the stream too fast by increasing the symbol rate, 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
Kai-Uwe Storek



Privatsphäre auch bei eMails? eMail-Verschlüsselung leicht gemacht:

Thunderbird: http://www.thunderbird-mail.de/wiki/Enigmail_OpenPGP
Outlook:https://code.google.com/p/outlook-privacy-plugin/
Outlook (kostenpflichtig): http://www.gpg4o.de/en/product/productinfo-gpg4o.html

Mein Schlüssel: http://goo.gl/QGVvsw