|
From: | Ron Economos |
Subject: | Re: [Discuss-gnuradio] gr-dtv | DVB-S2 : video bitrate const while symbol rate increased |
Date: | Wed, 25 Oct 2017 06:10:55 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
https://github.com/G4GUO/datvexpress_guiNot 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/775136169356996608I 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.pyIf 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.pyFinally, since you're doing research you may be interested in a VCM/ACM implementation of DVB-S2.
https://github.com/drmpeg/gr-dvbs2After 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 <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
[Prev in Thread] | Current Thread | [Next in Thread] |