Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video playback issues #138

Open
Thaval opened this Issue Nov 5, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@Thaval
Copy link

Thaval commented Nov 5, 2017

Hi,

when working with video files, I came across some strange behaviours. The seek method of the Video(player) class takes very long. It looks like as if it takes as long as the time difference.
Let's say the current timestamp of the video is 10 (which means it's at 10seconds) and I want to jump to 20sec, so it's gonna take 10 seconds to seek. If I want to jump to 40sec, it's gonna take 30sec and so on.
Jumping backwards doesn't work at all. Resetting the video doesn't work, too.

@jonhare

This comment has been minimized.

Copy link
Member

jonhare commented Nov 6, 2017

How are you opening the videos with the XuggleVideo class? What you're describing sounds typical of a video opened with one of the constructors that takes an InputStream (where seeking forwards has to read through each frame & so takes time, and seeking backwards & resetting isn't possible)...

If that's not the case, then this is likely a limitation of the underlying Xuggle library & not something that can be fixed within OpenIMAJ.

@Thaval

This comment has been minimized.

Copy link
Author

Thaval commented Nov 6, 2017

Im opening the XuggleVideo by passing a String value of a local video file and running
container = IContainer.make(); openResult = container.open(urlstring, IContainer.Type.READ, null, true, true);
The strange thing is, that when dragging the seekbar in my GUI, the first frame of the video at the "drag-stop" position will be shown but the video continues very late, as described in my opening post.

If that's not the case, then this is likely a limitation of the underlying Xuggle library & not something that can be fixed within OpenIMAJ.

I didnt find any issue about that.. I guess this problem may occur because of the MediaAdapterListener as he automatically cares about when to show the next frame. Maybe he avoids "fast seeking" by sleeping internally. I'm not quite sure. I tried decoding the video manually but I can decode the video only once.

@Thaval

This comment has been minimized.

Copy link
Author

Thaval commented Nov 6, 2017

I think the problem lies in the VideoDisplay class after reviewing the code. Despite of the fact, that the enum Mode.SEEK is never read but can be written from outside the class throught setMode(...), the user always needs to wait as there is a default time to wait before reading the next frame.
May the problem be in the run() method of VideoDisplay:
If so, then I think the problem could be solved by asking if the current Mode is set to SEEK (which should be automatically the case if you call the seek method...) and then compare the current frame timestamp to the target timestamp, continue if the target timestamp is greater. If the current frame timestamp is greater, then set the Mode back to PLAY.

Unfortunately, this only works when seeking forward. When seeking backward, the video file needs to be reopened.

I would implement this by myself, but the code design (Video, VideoDisplay, Timekeeper) is too confusing for me and there are not getters for the sub-classes, so most things would be a copy and paste of all your code to just change 1 line of code, if I can see it right.
This shouldn't be aggressive and I apologize if so, I'm just asking politely to make some quick changes if possible.
Let me know what you think about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.