UDP/Windows Media Player

[nilak]

I am experiencing several issues I would like to address concerning UDP and the Windows Media Player ActiveX container.

Firstly, to address the UDP problems I am having, I would like to transmit a video file over UDP (unicast) to another machine. I use the "Create/Replace File.vi", "Read File.vi" and "Close File.vi" VI's to access the video file. The data is then converted from a string to an unsigned byte array using the "string to byte array" function. The array is then indexed via a for-loop and then each element is fed into the "flatten to string" function which is then fed into data in of "UDP Write" function. The issue I am having with this is that I am unable to select the buffer size. Currently, the buffer size is simply the size of each element of the byte array. Is there a different vi that can replace the "string to byte array" function to enable buffer size selection? Can the "pos offset" input of the "Read File.vi" enable this somehow? The help file states that, "pos offset specifes how far from the location specified by pos mode to start reading or writing. You express pos offset in units of bytes. The default is 0." If I were to use this, I would have to use "pos mode" of 2 which states "Current- The operation begins at the current location of the file mark plus pos offset". Another option I was considering is whether to use a second for-loop and another array to store several values of one array into one element of the other array. I have been unsuccessful in finding any material regarding buffering UDP datagrams when the file size exceeds the maximum allowed packet size.

Secondly, I have been attempting to access Windows Media Player ActiveX containers, but have been unsuccesful in making WMP play streaming input. What I would like WMP to do, is to play the opened video file in real time as it is streaming both on the server AND client. On the server, I do not want to simply open and play the file that is being sent, but instead would like to wire the actual binary data that is being sent to "UDP Read.vi" to the WMP container, so that the data being sent over UDP is the data being displayed by WMP. Is this even possible with Windows Media player? On the client side, I would like to play WMP in real time as it the data is incoming, instead of saving the whole data to file and then reading it. From what I've found, WMP only allows a file to be opened from a location such as hard disk, url, or network machine. Is DirectShow a better alternative? Not sure how I would use that though. Any help would be greatly appreciated, and sorry for the long post.

[tst]

I don't know about the second part, but about the first part - reading different parts of the file is unrecommended unless the file is very large. As long as it can be held in memory, it's better to have one read, because the read operation is slower.
Then, instead of doing the conversions, have the UDP write in a while loop, and use String Subset with a shift register on the original data to extract and send as many bytes as you like. As far as I know, you have to manage UDP comm, so you may want to use TCP instead. You can find example with LV to show how to know how many bytes the other side is should be receiving.
You may wish to search google for information about streaming video.

[nilak]

---

@tst wrote:
I don't know about the second part, but about the first part - reading different parts of the file is unrecommended unless the file is very large. As long as it can be held in memory, it's better to have one read, because the read operation is slower.
Then, instead of doing the conversions, have the UDP write in a while loop, and use String Subset with a shift register on the original data to extract and send as many bytes as you like. As far as I know, you have to manage UDP comm, so you may want to use TCP instead. You can find example with LV to show how to know how many bytes the other side is should be receiving.
You may wish to search google for information about streaming video.

---

Your recomendation worked out great!! Just a couple of questions. When the file is finished reading, what is a good method of stopping the while loop. Can I simply compare the string (not sure what hex value/string indicates EOF) and wire a boolean output to the conditional terminal? Also, I do not understand why I need to use TCP instead of UDP. The example "UDP Receiver.vi" captures the exact UDP datagrams being sent.

Thank you for all the help.

nilak

[tst]

I wasn't suggesting that you read the file in the loop but that you read it once before the loop and then use a shift register and String Subset to decide which part of the string to send. One way to do this would be to place to String Subset VIs inside the loop, wire the string into them and wire the number of bytes to send into both of them, in one into the length and in one into the offset. The length one is wired into the send and the offset one is wired back into the shift register. You can stop the loop when there is an error, a manual stop or when the string you're using is empty.

I didn't say you need to use TCP, just that as far as I know, UDP offers no mechanism to make sure your data gets to the other side, unlike TCP. If your network is good, the data will probably get there, but you can't trust it. I haven't worked with UDP, but I think that since this a basic part of the protocol, there is nothing LV does about it automatically. If you can have some data lost, there is no problem. If you can't, use TCP or make sure your packets reach their destination. You should look for more material about UDP and\or UDP in LV to find out.

[nilak]

---

@tst wrote:
I wasn't suggesting that you read the file in the loop but that you read it once before the loop and then use a shift register and String Subset to decide which part of the string to send. One way to do this would be to place to String Subset VIs inside the loop, wire the string into them and wire the number of bytes to send into both of them, in one into the length and in one into the offset. The length one is wired into the send and the offset one is wired back into the shift register. You can stop the loop when there is an error, a manual stop or when the string you're using is empty.

I didn't say you need to use TCP, just that as far as I know, UDP offers no mechanism to make sure your data gets to the other side, unlike TCP. If your network is good, the data will probably get there, but you can't trust it. I haven't worked with UDP, but I think that since this a basic part of the protocol, there is nothing LV does about it automatically. If you can have some data lost, there is no problem. If you can't, use TCP or make sure your packets reach their destination. You should look for more material about UDP and\or UDP in LV to find out.

---

Sorry for not elaborating enough. I meant "when the while loop has forced the subset string vi to read at the end of the file". I had made it exactly as you've described it. I understand that UDP does not guarantee datagram arrival, but since I wish to stream video, it does not have to. I have read almost every post about UDP but have not found anything where UDP can be used for streaming video. Most posts are about sending a simple datagram, one which is already included in the examples folder. WMP posts are only about accessing simple property nodes for openfile/play/pause/stop. The problem I am having is that I cannot interface the Windows Media Player ActiveX controller with the UDP functions so that the video is played in-sync with data being sent/received (I want the video to be played both at sender and receiver for comparison). I am sure the information is out there, and will continue searching, but I was hoping it may be a bit faster (after searching for several days) to post a question here. I don't believe this is a repost but I can be wrong.

Regards,

nilak

[tst]

I think you should look for technical documentation on using the WMP ActiveX interface and on streaming video - I'm not at all sure that WMP supports streaming video in this fashion. It's possible you need to have a "video server" or something similar.