I am using fobs to process for example an mpeg2 encoded file.
I retrieve frame by frame, by calling :
- nextFrame()
- getRGB()
The size is 720*576 (so want full frames, not fields).
Afterwards I just show every frame on the screen, and I noticed that frame 0 == frame1, frame 2 == frame3, ...
And yes I am talking frames, since I get exactly 25 frames/sec.
Well I think I am.
What could be wrong, who can help me out ?
many many thanks,
Lieven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have exactly the same problem, both under win2000 (using mingw3.4.2) and linux (gcc).
By looking at the frames I do get, it seems that at a certain point a frame is simply not decoded in every even nextFrame() call.
Is this a known problem? (I could not find anything about it in the forum)
Sjaak
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this is not a known issue. Please provide more information about your system configuration and Fobs version (see complete list at http://fobs.sourceforge.net/documentation.html\). A link to the video file would be really useful.
Cheers,
Jose San Pedro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I recognise the problems. On both 32bit and 64bit machines and both under windows using mingw32 and under linux using gcc the problem is the same.
Indeed if you use nextFrame() and then getRGB() on an mpeg2 movie you get the problem descried above (at least with fobs 0.4.0 which is available for download at this moment).
If ffmpeg is used directly, every frame is extracted correctly so the movie file is ok and the data for the frames is present.
I needed all frames desperately so I started looking into the source code and playing around with the various readout options.
The result is that I have a work-around for the problem that results in slightly slower operation but at least all frames are read out. I'll try to summarise things:
- using nextFrame() and getRGB() gives the problem mentioned above.
- because I thought maybe some variable wasn't updated I tried nextFrame() + nextFrame() + prevFrame() + getRGB(). For a small test program this approach worked fine (although relatively slow). However, when I tried to apply this to a program that extracted more than just a few frames, things screwed up tremendously and a region of approximately 20 frames was read in fine. The location of this region was however slightly unpredictable from movie to movie (maybe some problems with the movie)
- Then I tried the getRGBA(char* buffer) function. (My movie contains just RGB data, but a different function might have a different implementation and might work better). And indeed using this function I do get every frame out of my movie. (I am not sure why, but maybe an extra copy is being made somewhere in the process??) Because of the extra alpha channel data more data will have to be moved around and this probably will slow down things slightly. Besides: maybe it helps to compare similar functions to find out what is the problem.
- Using the getRGBA(char *buffer) function, the data one actually gets back is NOT RGBA but BGRA (despite what the function name makes you think). This is however not a big deal if one knows it.
I did look into the code trying to maybe find the problem and correct it. But sadly I could not find the problem. Therefore, for the moment the best I can suggest is use the getRGBA(char* buffer) untill some better solution has been found!
If I am correct, lieven has a link to the movie file. Maybe he could post it here? I do not have it present at the moment.
Regards,
Sjaak
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the file. I'll try to work on it asap but it's not realy a good time for me (finishing my PhD thesis still!!). Somebody has found a workaround using getRGBA() instead of getRGB(), which may help you while I get sometime to find the issue (probably inside getRGB() function).
Cheers,
Jose San Pedro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm terribly sorry to tell I've been unable to find the problem in the source code. Both getRGB and getRGBA use the same lines of code, so I can't really explain the real cause of the issue. I currently lack the time to do a deep debug to find the real problem.
If you have a minute, please try to change the compareTimeStamps method:
<< if(isVideoPresent()) res = ::abs(t2-t1) <= 1000.0/getFrameRate();
>> if(isVideoPresent()) res = ::abs(t2-t1) <= 500.0/getFrameRate();
Probably nothing will change, but I can't think of anything else right now.
Regards,
Jose San Pedro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have already forgotten about this issue. It's been a long time since I could dedicate some time to Fobs. It'll be great to have some sample code because I've never come across this issue, and I kind of use fobs extensively.
Cheers,
Jose San Pedro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I have already sent you the code I am using ... Hope it helps to find the problem. And of course I can try any test or workaround you may think it can be useful.
One again, thas for your software and support.
Pablo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as I posted some time ago, I've been able to solve the issue by changing:
<< if(isVideoPresent()) res = ::abs(t2-t1) <= 1000.0/getFrameRate();
with
>> if(isVideoPresent()) res = ::abs(t2-t1) <= 500.0/getFrameRate();
in the Decoder.cpp file (compareTimestamps method).
Depending on the precission used to stored the timestamps in the video file, this comparison may lead to assuming next frame was just the same old one.
I'll commit the code to the CVS as soon as possible, but I'm right now in the process of migration to macintel from my old PPC.
Hope it works for you guys!!
Cheers,
Jose San Pedro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using fobs to process for example an mpeg2 encoded file.
I retrieve frame by frame, by calling :
- nextFrame()
- getRGB()
The size is 720*576 (so want full frames, not fields).
Afterwards I just show every frame on the screen, and I noticed that frame 0 == frame1, frame 2 == frame3, ...
And yes I am talking frames, since I get exactly 25 frames/sec.
Well I think I am.
What could be wrong, who can help me out ?
many many thanks,
Lieven
I have exactly the same problem, both under win2000 (using mingw3.4.2) and linux (gcc).
By looking at the frames I do get, it seems that at a certain point a frame is simply not decoded in every even nextFrame() call.
Is this a known problem? (I could not find anything about it in the forum)
Sjaak
Hi,
this is not a known issue. Please provide more information about your system configuration and Fobs version (see complete list at http://fobs.sourceforge.net/documentation.html\). A link to the video file would be really useful.
Cheers,
Jose San Pedro
Hi,
I recognise the problems. On both 32bit and 64bit machines and both under windows using mingw32 and under linux using gcc the problem is the same.
Indeed if you use nextFrame() and then getRGB() on an mpeg2 movie you get the problem descried above (at least with fobs 0.4.0 which is available for download at this moment).
If ffmpeg is used directly, every frame is extracted correctly so the movie file is ok and the data for the frames is present.
I needed all frames desperately so I started looking into the source code and playing around with the various readout options.
The result is that I have a work-around for the problem that results in slightly slower operation but at least all frames are read out. I'll try to summarise things:
- using nextFrame() and getRGB() gives the problem mentioned above.
- because I thought maybe some variable wasn't updated I tried nextFrame() + nextFrame() + prevFrame() + getRGB(). For a small test program this approach worked fine (although relatively slow). However, when I tried to apply this to a program that extracted more than just a few frames, things screwed up tremendously and a region of approximately 20 frames was read in fine. The location of this region was however slightly unpredictable from movie to movie (maybe some problems with the movie)
- Then I tried the getRGBA(char* buffer) function. (My movie contains just RGB data, but a different function might have a different implementation and might work better). And indeed using this function I do get every frame out of my movie. (I am not sure why, but maybe an extra copy is being made somewhere in the process??) Because of the extra alpha channel data more data will have to be moved around and this probably will slow down things slightly. Besides: maybe it helps to compare similar functions to find out what is the problem.
- Using the getRGBA(char *buffer) function, the data one actually gets back is NOT RGBA but BGRA (despite what the function name makes you think). This is however not a big deal if one knows it.
I did look into the code trying to maybe find the problem and correct it. But sadly I could not find the problem. Therefore, for the moment the best I can suggest is use the getRGBA(char* buffer) untill some better solution has been found!
If I am correct, lieven has a link to the movie file. Maybe he could post it here? I do not have it present at the moment.
Regards,
Sjaak
@jsanpedro : I have mailed you the link to the video file.
System :
WinXp
Fobs 0.4.0 (ffmpeg included i nfobs)
no JMF
kind regards,
Lieven
Hi,
thanks for the file. I'll try to work on it asap but it's not realy a good time for me (finishing my PhD thesis still!!). Somebody has found a workaround using getRGBA() instead of getRGB(), which may help you while I get sometime to find the issue (probably inside getRGB() function).
Cheers,
Jose San Pedro
Jose,
any news on this topic yet ?
kind regards,
Lieven
Hi,
I'm terribly sorry to tell I've been unable to find the problem in the source code. Both getRGB and getRGBA use the same lines of code, so I can't really explain the real cause of the issue. I currently lack the time to do a deep debug to find the real problem.
If you have a minute, please try to change the compareTimeStamps method:
<< if(isVideoPresent()) res = ::abs(t2-t1) <= 1000.0/getFrameRate();
>> if(isVideoPresent()) res = ::abs(t2-t1) <= 500.0/getFrameRate();
Probably nothing will change, but I can't think of anything else right now.
Regards,
Jose San Pedro
Hi everybody, first of all thanks for this project. I think it's great.
I am experiencing the same problems ... and the workaround given previously didn't work for me. I have tried different videos with the same result.
Maybe I can email you the code I am using.
Thanks in advance, regards.
Pab.
Hi,
I have already forgotten about this issue. It's been a long time since I could dedicate some time to Fobs. It'll be great to have some sample code because I've never come across this issue, and I kind of use fobs extensively.
Cheers,
Jose San Pedro
Hi, I have already sent you the code I am using ... Hope it helps to find the problem. And of course I can try any test or workaround you may think it can be useful.
One again, thas for your software and support.
Pablo.
Hi,
as I posted some time ago, I've been able to solve the issue by changing:
<< if(isVideoPresent()) res = ::abs(t2-t1) <= 1000.0/getFrameRate();
with
>> if(isVideoPresent()) res = ::abs(t2-t1) <= 500.0/getFrameRate();
in the Decoder.cpp file (compareTimestamps method).
Depending on the precission used to stored the timestamps in the video file, this comparison may lead to assuming next frame was just the same old one.
I'll commit the code to the CVS as soon as possible, but I'm right now in the process of migration to macintel from my old PPC.
Hope it works for you guys!!
Cheers,
Jose San Pedro
Sorry I've been away for a while. I just wanted to say that it worked great!!
Thanks for your time!
Pablo
Hello,
Finally I could test this (pff, more then 1 year later :-( ).
What I can say is that the 1000 --> 500 : it works.
One big question : why was this not included in fobs version 0.4.1 ???
kind regards,
Lieven
In FOBS 0.4.2 this fix is still not included, and as such the issue remains. The good thing is the suggested fix still works to get things right.
I hope it becomes official soon ;-)