prevFrame much slower than nextFrame
Status: Beta
Brought to you by:
jsanpedro
Menu
▾
▴
I need some basic functionality of a videoplayer.
- play
- pause
- one frame to the right
- one frame to the left
when I press frame to the right it calls nextFrame. I can press as fast as i can and the video keeps up with me.
When I press frame to the left however (this calls prevFrame) it can take 0,5 - 1 sec before the video gives me the prevFrame. When I want to skip with 30 frames it can take up to 5 sec. Is there a way to speed things up here?
Greetings Pieter
Hi,
this is expected behavior. It's not the same to go forward than backwards in a video stream. Depending on the format of the video, the seek operation will take longer or shorter. I recommend to reduce seek operations, especially backwards.
Cheers,
Jose San Pedro
I was just hoping for a faster way of doing it.
Thx for your response.
Pieter
If transcoding the video is an option, you might be able to find a different format that works better.
This problem tends to be worst with videos that use motion-based coding, like mpeg. There are basically two problems:
Firstly, the video frames are not complete in themselves, but depend on differences from previous frames. To step forward one frame, you just need to apply a delta to the current frame. To step backwards, you have to seek to the previous I-frame, and then decode all of the frames between that one and the frame you want. For mpeg-2 I-frames usually come every 15 frames, so its not too bad. For mpeg-4 the GOP length is usually much longer, around 100 frames is typical, but it can be 200 or more.
Secondly, its hard to find a particular frame in a video file. If you had an index that gave you the location and type of each frame, there would be no problem finding the right I-frame. But most video files aren't indexed - formats like AVI support indexes, but they're optional so you can't rely on them being available. This means you need to either build the index on the fly, or do a binary search of the file to find frames with a particular timestamp. ffmpeg will usually choose the best method, but it might still be slow. Unfortunately, JMF works above all of these details, so there's not much you can do about it from the Java side.