Hi Syed, from my perspective, the only way packets could get lost in your scenario 2 is when your operating system's network stack decides to drop packets, which should only happen if there is a big backlog of unread ones. Try replacing the UDP sink by a file sink and see if that content is complete.
Anyway, you mention "quality is somehow not good"; I'm not quite sure what to make out of this. Usually, when you lose packets in an MPEG stream you lose frames or get visual garbage in some quadratic areas of the picture; is that the case? If you use ncat to save the received stream instead of mplayer to play it, how much smaller is the received file? Greetings, Marcus On 02/22/2014 10:52 AM, Syed Aqeel Raza wrote:
Hi Marcus, Thanks for your reply. I’ve already implemented all the test scenario’s mentioned in my earlier email. All are working and produced a streaming video at the destination end. However, the problem is with the video quality. Yes, you’re right the selected video has a bitrate less than 1Mb/s and for the case of test 2 it’s transparent too; but the streaming quality is somehow not good as in test 1 and it further degrade when moving to test 3 and test 4, respectively. Furthermore, I’ve not used any throttle block in any of the flowgraph yet. At the current moment, I am investigating the options to calculate the packet dropping rate within the flowgraphs. Regards, Syed Aqeel Raza
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
