I noticed that with GSMovie there is a lot of memory allocation and garbage collection. This is because the videosink allocates a new buffer for each frame of the movie. In order to avoid that, you can add this line in GSMovie.java line 141 (current svn version)
Let me know if this causes any other error and if this modification will be introduced in the next release.
Hi Octavi… Great point! I added the setPassDirectBuffer(true) line to GSMovie, GSCapture and GSPipeline, and the examples work fine so far. This improvement deserves a new release very soon!
I included the changes in this new preview release:
Performance seems much better on Linux (4 SD videos playing at the same time, 30fps). On Windows I started to migrate to a new version of the gstreamer binaries, which is creating trouble (GSMovie doesn't work with mov files for instance), capture and custom pipelines seem to work though. Could you try it out and let me know the problems you find?
I tested 0.6-pre2 and the GSMovie.jump() method does not work as well as before (at least on Windows). For example the Scratch example shows always the same frame. When I use the jump() method in long movies and then print the time() there may be a difference of more than one minute.
Yes, I also noticed this problem. Working on a solution now…
I fixed the seek problem in the latest preview package. Let me know if it works ok.
I tested 0.6pre3 and the Scratch example works better. It also works well with my mov and wmv files, but the problem persists with long asf files encoded with VLC (DIV3+MP3). These files worked well before.
thanks for reporting.
my feeling is that the problem originates in the underlying gstreamer plugin…
I'll update gsvideo to use the final 0.10.6 release of gstreamer-winbuilds that just came out. Maybe this solves the issue
I tried the 0.6pre5 and there is still not much precision in some of my long asf videos :(
Let me know if I can do something to solve the problem.
ok, I have this issue in the list of things to solve for the final release of 0.6.
In the meantime, you could try some gstreamer-based player to check if the seek problem persists…
I tried various video containers and codecs (avi, mov, wmv, h264, dv, xvid) and the jump functionality seems to work fine, with the exception of mpg2. This probably depends on the underlying gstreamer decoder, and how well the seek method is implemented. The keyframe configuration during the encoding stage might have an effect as well.
I couldn't try the div3+mp3 codec from VLC, since the files I saved with it were played only as audio from gstreamer/gsvideo. I'll be releasing 0.6 soon, I recommend that you re-encode the videos that are giving you trouble. I have been using winff (http://winff.org/html_new/) for video conversion, it supports many different codecs.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.