PDA

View Full Version : IMVNetworkReceiveInfo question



Aaron Torpy
September 2, 2004, 14:16:30
Hello folks,

Sorry if this is a bit of a newbie question, but I was hoping someone could give me a definition for ‘sample’ as it applies to the IMVNetworkReceiveInfo interface.

I’ve been trying, unsuccessfully, to send MPEG4 video (~5kB/s) over a fairly slow ADSL connection (~10kB/s) using a pair of MVNetworkRenderer and MVNetworkSource filters. The MVNetworkSource is receiving data at the correct bit-rate, but the video doesn’t render at all (although the correct media type is received). After a minute-or-so of operation the IMVNetworkReceiveInfo interface from the MVNetworkSource filter reports statistics like:

Packets: 500
Media types: 100
Samples: 400
Lost packets: 0
Lost samples: 100000
Partial samples: 0
Data rate: 5000

So according to the IMVNetworkReceiveInfo interface no packets have been lost (good), but something like 99.6% of all samples were lost (really bad). What does this mean? I’m really confused.

Cheers,
Aaron Torpy

Bernd Peretzke
September 2, 2004, 17:52:45
Hi,

the "Lost samples" value isn't correct. Ignore it. Samples are data packets with video data. If you use media formats with single images (e.g. RGB24 or YUV) a sample contains one image. If you can't render the output pin from the network source filter, check if a MPEG4 decoder filter is installed.

Regards
Bernd

Aaron Torpy
September 3, 2004, 16:16:23
Thanks Bernd,

I think I’ve worked out the mystery. The MPEG4 decoder wasn’t working because it never received any key-frames. I got confused because the received bit-rate was about the same as the sent bit-rate (40kbit), but I didn’t notice that the 200kbit/s ‘spikes’ due to key-frames weren’t getting through because they were too big for the 100kbit connection. Between key-frames, however, the MPEG ‘change’ samples get through and maintained the average bit-rate at the 40kbit/s figure.

To cater for clients on slow connections I had been decreasing the frame-rate, but it looks like I should have been decreasing the MPEG quality so that the key-frames can still get through.

Anyway, thanks again for your help, it was much appreciated.

Cheers,
Aaron Torpy.