Simulink Queue Block vs Buffer Block

[Corey]

Hello,

Maybe I am in need of reading more fundamental programming / signal processing background, deeper than Simulink help files, but.......can anyone give a thorough description of the difference between the Simulink Queue block and the Buffer block? I realize one has much more control over the Queue block, but the fundamental difference(s) I am not sure of. Using one vs the other seems to greatly affect my model's operation though.

I am trying to send video over a UDP connection (via the UDP Send and Receive blocks).....using only buffers (to chunk the video signal into acceptably-sized segments to fit into UDP packets, and reassemble the video signal on the receive end) gets the video to display on the Video Viewer, although incorrectly - the display tends to be jumpy and sort of vertically scroll. Generally, some percentage of the bottom half of each frame is also shown at the top portion of the frame...the percentage seems fairly random. Also, using a Frame Rate Display block, it shows the frame rate varying wildly as the simulation runs. However, when using a Queue block somewhere in the signal chain, the frame rate seems to stay within about 0.0001 frames-per-second of the desired 30Hz.

I am wondering if some more intricate double-buffering is required, or am I just missing some fundamental concepts of Simulink?

Any help would be greatly appreciated.

Thanks,
Corey

[Alec Rogers]

Hi Corey,

The Buffer block changes the size (and therefore the rate) of a signal.
It does this in a constant way, and it only stores as much data
as is necessary to perform the conversion.

The Queue block, on the other hand, has ports that allow you to push and
pop the inputs. So, in contrast to the Buffer block, it is more about
signal storage than alteration of the rate and size of a signal.

With respect to your model, and what might be happening with respect to
the display, is it possibly explained by dropping UDP packets? In other
words, does the "top portion" of the video frame that is sometimes
erroneously displayed correspond to one UDP packet in size?

Finally, if your interest is just buffering the signal so that you have
a steady video frame rate, you might also be able to use a Delay block
(although that will depend on your model).

Regards,
-alec

[Corey]

Alec Rogers <alec....@mathworks.com> wrote in message <hi28k3$ipk$1...@fred.mathworks.com>...

Alec,

Thanks for your response. It is possible that I am dropping UDP packets...I will have to do some Wireshark testing to see about this.

I am curious - how would a delay block steady my video frame rate? Can you describe a simple case where this would apply?

Thanks,
Corey

[Alec Rogers]

Corey wrote:
> Alec,
>
> Thanks for your response. It is possible that I am dropping UDP
> packets...I will have to do some Wireshark testing to see about this.
>
> I am curious - how would a delay block steady my video frame rate? Can
> you describe a simple case where this would apply?
>
> Thanks,
> Corey

Hi Corey,

I was thinking that the UDP Receive block would conditionally feed the
incoming data (when it was received) to the delay block by using a
triggered subsystem (this is essentially combining the Sample and Hold
block with a delay block). I think that you you would end up with a
buffered zero-order hold (you would probably also need a rate transition).

In any case, this may be more complicated than using the Queue block
(and I've not tested it), so I would stick with your current solution as
long as it suits your needs.

More regards,
-alec

[Ahmed]

Alec Rogers <alec....@mathworks.com> wrote in message <hi28k3$ipk$1...@fred.mathworks.com>...

I am new to matlab and im also trying to transmit a live video stream using UDP in simulink... can u give me an idea as to how this can be done.... thanks..