reading multiple frames of AVI

[enthusiast4]

Hello!

Is there a possibility of reading multiple frames of avi file? I am trying to manipulate a avi file to read it's multiple frames. I have read single Image by IMAQ AVI Read Frame.VI. But, I am trying to find a way to read multiple frames of AVI as a sequence i.e like a short Video.

Is there a possibility or any way out of reading the multiple frames?

[Bob_Schor]

Yes.  Look at the inputs of the Read Frame function.  Do you see the (probably-unwired-in-your-unposted-code) input "Frame Number"?  What do you think would happen if, say, 30 times per second, you put the numbers 0, 1, 2, 3, etc. into that input, say, in a For loop?

It is always easier for us to help you if you help us by posting your code, meaning "attach your VI".

Bob Schor

[enthusiast4]

Yes I know that by entering the frame number on IMAQ AVI Read Frame ,it displays the corresponding frame of an AVI file.What if i want to control the AVI file by user selected time duration.For e.g: the AVI file is of total 20s and the user wants to display the images only till  10s .

Below is my code.I wanted to display the sequence of all the frames till 10s but I am only getting a single frame which is at 10s. My mistake might be trivial but I am not understanding what is wrong.

[Bob_Schor · Accepted solution]

It is a common mistake when beginning with LabVIEW to "just start coding because the Graphical Format makes it just so easy".  Code without Design (or without "Style") is very difficult to understand.  And don't get me started on Express VIs (although I will make an exception for the File Dialog Express VI).

The code above asks the User for an AVI file, opens it, gets its Frame Rate and # of Frames, gets a Buffer to hold images, plays the AVI at the specified Frame Rate, then closes the AVI.  Simple and neat.

If you want to play the first 10 seconds, just compute how many frames that would be and use the same basic scheme.  If you want to view individual Frames, you would modify the For Loop to accept a Frame number, then display that Frame (recall that Frame Numbers conventionally start with 1 ("Show me Frame 1"), while LabVIEW indices start with 0).  All are "Variations on the Above Theme".

You seem to be using the "old-style" AVI VIs, rather than the AVI2 VIs introduced in LabVIEW 2012 (I believe).  That might be asking for trouble...

Bob Schor

[enthusiast4]

Thank you

---

@Bob_Schor wrote:

It is a common mistake when beginning with LabVIEW to "just start coding because the Graphical Format makes it just so easy".  Code without Design (or without "Style") is very difficult to understand.  And don't get me started on Express VIs (although I will make an exception for the File Dialog Express VI).

The code above asks the User for an AVI file, opens it, gets its Frame Rate and # of Frames, gets a Buffer to hold images, plays the AVI at the specified Frame Rate, then closes the AVI.  Simple and neat.

If you want to play the first 10 seconds, just compute how many frames that would be and use the same basic scheme.  If you want to view individual Frames, you would modify the For Loop to accept a Frame number, then display that Frame (recall that Frame Numbers conventionally start with 1 ("Show me Frame 1"), while LabVIEW indices start with 0).  All are "Variations on the Above Theme".

You seem to be using the "old-style" AVI VIs, rather than the AVI2 VIs introduced in LabVIEW 2012 (I believe).  That might be asking for trouble...

Bob Schor

---

Thank you for your valuable Information.Yes, I did. But,I just modifiled my code by connecting For Loop N' to the total time I want the Video to run(Time Duration=Frames/second * Number of Frames till where the user wants the Video to run).

Your code is useful to run simply the Video file

But, my Goal also is to check the timestamps of each fame and read the Frames. So, I used the "old style" AVI VI because the new AVI2 VIs doesnt provide anything by which user can write or read 'data' string which is important for me for writing timestamps on the AVI Frames.

[Bob_Schor]

---

@enthusiast4 wrote:
Thank you for your valuable Information.Yes, I did. But,I just modifiled my code by connecting For Loop N' to the total time I want the Video to run(Time Duration=Frames/second * Number of Frames till where the user wants the Video to run).

You are correct that my code does all the frames.  However, if you know the total time you want the video to run, I'm suggesting it is more logical (and easier to code, easier to maintain, easier to explain) to express this as Frames by saying Frames = Total Time * Frames/sec.

But, my Goal also is to check the timestamps of each fame and read the Frames. So, I used the "old style" AVI VI because the new AVI2 VIs doesnt provide anything by which user can write or read 'data' string which is important for me for writing timestamps on the AVI Frames.

I'm suggesting you have unnecessarily "complicated" the situation.  Video Frames Rates are set by the Camera, and can probably (??) be trusted to be accurate.  If you are not sure you can trust it, I recommend writing some code to create a Video that lasts (as accurately as you can get LabVIEW to do this) for, say, 30 minutes, and when it finishes, get Windows to tell you how many frames were stored.  If your camera saves at 30 fps and your LabVIEW code is able to "keep up", you should have exactly 30 fps * 30 min * 60 sec/min = 54,000 frames.  If this is the number you get, go ahead and "believe" the hardware and get rid of the unnecessary recording of TimeStamps.  Then you can use much simpler code along the lines I demonstrated and know you can "trust" it.  Now, who said "Trust, but Verify"?

---

Bob Schor

[enthusiast4]

---

@Bob_Schor wrote:

---

@enthusiast4 wrote:
Thank you for your valuable Information.Yes, I did. But,I just modifiled my code by connecting For Loop N' to the total time I want the Video to run(Time Duration=Frames/second * Number of Frames till where the user wants the Video to run).

You are correct that my code does all the frames.  However, if you know the total time you want the video to run, I'm suggesting it is more logical (and easier to code, easier to maintain, easier to explain) to express this as Frames by saying Frames = Total Time * Frames/sec.

But, my Goal also is to check the timestamps of each fame and read the Frames. So, I used the "old style" AVI VI because the new AVI2 VIs doesnt provide anything by which user can write or read 'data' string which is important for me for writing timestamps on the AVI Frames.

I'm suggesting you have unnecessarily "complicated" the situation.  Video Frames Rates are set by the Camera, and can probably (??) be trusted to be accurate.  If you are not sure you can trust it, I recommend writing some code to create a Video that lasts (as accurately as you can get LabVIEW to do this) for, say, 30 minutes, and when it finishes, get Windows to tell you how many frames were stored.  If your camera saves at 30 fps and your LabVIEW code is able to "keep up", you should have exactly 30 fps * 30 min * 60 sec/min = 54,000 frames.  If this is the number you get, go ahead and "believe" the hardware and get rid of the unnecessary recording of TimeStamps.  Then you can use much simpler code along the lines I demonstrated and know you can "trust" it.  Now, who said "Trust, but Verify"?

---

Bob Schor

---

I am playing a video file which is created by animation software and not grabbed and created by a camera.

[Bob_Schor]

---

@enthusiast4 wrote:

---

I am playing a video file which is created by animation software and not grabbed and created by a camera.

---

All the more reason to expect (a) the frames are designed to be viewed at a fixed Frame Rate, and (b) if the Frames include a TimeStamp reflecting their time of creation, and are independently generated by software, it is almost inevitable that the "Frame times" will be different.  The "logical conclusion" from the previous two assertions is that one should absolutely ignore the TimeStamps associated with the Frames and, instead, display at a fixed Frame Rate.

See my previous suggestions for how to do this.

Bob Schor