FFmpegFrameGrabber logic is wrong again

[GoogleCodeExporter]

1.
pCodecCtx.frame_number() will return number of decoded frames for this context, 
it's not related to frame number in videostream

2.
avformat_seek_file with AVSEEK_FLAG_FRAME may not be supported by all demuxers.

3.
anyway, seeking like this you get nearest keyframe(Intra frame) and for example 
with GOP=300 you can be +-300 frames away from desired frame number.

sorry. for exact jumping you have to seek to keyframe before needed frame and 
decode all frames till desired with avcodec_decode_video2

Original issue reported on code.google.com by aleksey....@gmail.com on 29 Feb 2012 at 7:56

[GoogleCodeExporter]

Thanks for reporting these issues! So

1. What should we call then?
2. Is there an alternative? If there is no alternative, then IMO it's OK if it 
simply fails
3. If seeking is not properly supported, then the user can do it manually as 
you explain i.e.: decode up to the desired frame, but sometimes approximate 
seeks are better for performance anyway

Original comment by samuel.a...@gmail.com on 29 Feb 2012 at 11:04

[GoogleCodeExporter]

i think exposing frame-navigating interface with no accuracy is BAD DESIGN IN 
GENERAL.

if it's not accurate you should deal with time. this way you have current frame 
time from pts\dst discussed before(1). seek with ms if vstream=-1 or 
recalculate time to videostream timebase(2).
maybe it's even better to expose av_seek_file for seeking, as there is al least 
things like:
1. with no gurantie you can jump to keyframe after your needed frame
2. there is flag to seek backward if your frame before currently decoded frame.

Original comment by aleksey....@gmail.com on 1 Mar 2012 at 10:40

[GoogleCodeExporter]

It's always possible to expose the private variables from FFmpegFrameGrabber to 
let  users do whatever they want to do, such as messing with av_seek_file(), 
but the idea is to have a simple interface (FrameGrabber) common to all "frame 
grabbers", as much as possible... 

If you would have concrete code to propose, it would help a lot. Thanks for the 
feedback!

Original comment by samuel.a...@gmail.com on 1 Mar 2012 at 12:01

• Changed state: Started

[GoogleCodeExporter]

I've made a few changes based on your feedback. Please let me know if it looks! 
thank you

Original comment by samuel.a...@gmail.com on 16 Mar 2012 at 11:38

Attachments:

• FFmpegFrameGrabber.java

[GoogleCodeExporter]

from quick view it's looks ok.
not compliete sure for time math, as i did it with stream timebase unints 
rather milisecs.
i think you should use AVSEEK_FLAG_BACKWARD only if you jump backward. for 
normal forward seek, it's not needed.
iterating with grab() to needed frame is a bit excessive as you don't need to 
sws_scale(...) every frame.

is it workinkg well? can't test or code for few days...

Original comment by aleksey....@gmail.com on 16 Mar 2012 at 12:28

[GoogleCodeExporter]

Apparently, it's always a good idea to use AVSEEK_FLAG_BACKWARD :
http://code.google.com/p/chromium/issues/detail?id=48722#c8
to increase our chances of hitting an I-frame before the desired timestamp I am 
guessing, but have not confirmed this..

Anyway, I modified a couple of things, and it seems to work fine now yes. Not 
super efficient or accurate, but until FFmpeg gets better, it's hard to get 
more accurate frame numbers I think.

Original comment by samuel.a...@gmail.com on 16 Mar 2012 at 3:32

Attachments:

• FFmpegFrameGrabber.java

[GoogleCodeExporter]

Issue 172 has been merged into this issue.

Original comment by samuel.a...@gmail.com on 17 Mar 2012 at 5:28

[GoogleCodeExporter]

good to know about AVSEEK_FLAG_BACKWARD, thanks.
i dropped some time ago ffmpeg because can't get frame-accuracy. now i have 
idea with dynamic indexing, and probably will test it next week.

ps.
can't be sure but i think it's better to get duration from videosteam context, 
not from format - pFormatCtx.duration (can't give a prove or any reference for 
now)

Original comment by aleksey....@gmail.com on 17 Mar 2012 at 8:04

[GoogleCodeExporter]

"Indexing" as in something like the Frame Accurate Seeking Extension 
https://github.com/lbrandy/ffmpeg-fas right?

FFmpeg does seeking with the AVFormatContext, so I'm guessing we can safely 
assume it knows something about duration... In any case, it works fine here. 

Let me know if you find any problem with the code, thanks!

Original comment by samuel.a...@gmail.com on 17 Mar 2012 at 10:45

[GoogleCodeExporter]

I've added the new FFmpegFrameGrabber in the latest release. Let me know if 
anything looks amiss again, thanks!

Original comment by samuel.a...@gmail.com on 29 Mar 2012 at 12:42

• Changed state: Fixed