[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    Re: [Discuss-gnuradio] gr-dtv | DVB-S2 : video bitrate const while symbol rate increased
From:       Ron Economos <w6rz () comcast ! net>
Date:       2017-10-25 13:10:55
Message-ID: c91b686e-c3ba-553f-2888-e02d8599274f () comcast ! net
[Download RAW message or body]

It should be noted that the original DVB-S2 code was written by Charles 
Brain G4GUO for his DATV-Express project. My role was to port it to GNU 
Radio and add the DVB-S2X extensions. So definitely standing on the 
shoulders of giants.

https://github.com/G4GUO/datvexpress_gui

Not all the DVB-S2X modcod's have been tested. Only the broadcast 
profile DVB-S2X modcod's have been tested with a Silicon Labs Si2183. It 
would be nice if you could test some of the more esoteric modcod's. Be 
aware that the phase noise performance of your USRP may prohibit 
constellations greater than 32APSK from working. Also, the GRC flow 
graph doesn't check for illegal parameter combinations (that is, you can 
create a flow graph that doesn't have a valid modcod).

https://twitter.com/drmpeg/status/775136169356996608

I do have an easier way to change parameters. It's a stand-alone Python 
script for the B210, but you should be able to adapt it to your specific 
USRP. There is illegal parameter combination checking in this script.

http://www.w6rz.net/dvbs2-b210.py

If you want to add command line options for even more convenience, take 
a look at some example code here:

https://github.com/drmpeg/dtv-utils/blob/master/dvbt-blade.py

Finally, since you're doing research you may be interested in a VCM/ACM 
implementation of DVB-S2.

https://github.com/drmpeg/gr-dvbs2

After you clone it, do a "git checkout vcm" to get to the special 
VCM/ACM branch.

Ron

On 10/25/2017 05:04 AM, Kai-Uwe Storek wrote:
> 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 <w6rz@comcast.net>:
>> 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
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[prev in list] [next in list] [prev in thread] [next in thread]