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.)
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.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.
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!
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.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.
I thought the magic here is actually buffering by VLC, but as you already investigated: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?
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.A buffer on the receiver side is not the solution, because VLC stops immediately when I stop the Tx flowgraph.
Hopefully, someone can point me in the right direction.
Sorry about my not-so-much right direction. Best regards, Marcus
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
