FFmpegFrameGrabber won't grab till the end of video.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. put the 27frame.mp4 in the same path as the test2.class
2. set the CLASSPATH (javacv.jar, javacpp......)
3. run the test2 class (which will load the 27frame.mp4 through the 
FFmpegFrameGrabber, and display each frame. 

What is the expected output? What do you see instead?
Although using FrameGrabber.getLengthInFrames() will give the correct number of 
frames (27 frames in the attached video), the FrameGrabber.grab() only grab to 
the 23rd frame. 

What version of the product are you using? On what operating system?
Linux mint14, java 1.7, with the latest javacv, opencv, and ffmpeg provided on 
javacv's webpage.  

Thanks, 

Zong

Original issue reported on code.google.com by Qzts...@gmail.com on 8 May 2013 at 2:33

Attachments:

• test2.class
• 27frame.mp4
• test2.java

[GoogleCodeExporter]

Yes, indeed, thanks for pointing this out. I created a fix for this here:
http://code.google.com/p/javacv/source/detail?r=345a0baa8ca1e8bf44bd4d7273635728
6acab82d
Works here, but let me know how it looks at your end, thanks!

Original comment by samuel.a...@gmail.com on 11 May 2013 at 5:38

• Changed state: Started

[GoogleCodeExporter]

Issue 277 has been merged into this issue.

Original comment by samuel.a...@gmail.com on 11 May 2013 at 6:20

[GoogleCodeExporter]

Works correctly right now. 

Thanks, 

Original comment by Qzts...@gmail.com on 13 May 2013 at 8:07

[GoogleCodeExporter]

Samuel, I suspect the fix has created a different bug. I am streaming from 
Wowza, and now when the stream is not sending any frames the grabber gets stuck 
in line ~537 on the native command:

int len = avcodec_decode_video2(video_c, picture, got_frame, pkt);

in the past, grabFrame used to return null in such cases. Now it just stucks 
the thread  

K

Original comment by klomm...@gmail.com on 13 Jun 2013 at 4:17

[GoogleCodeExporter]

Wouldn't that be a bug in FFmpeg? How does ffplay behave?

Original comment by samuel.a...@gmail.com on 16 Jun 2013 at 2:25

[GoogleCodeExporter]

FFmpeg is prompting "no frame" as long as nothing is coming from the stream. 
What happens with my stream is that shortly after a new stream is being started 
over the RTMP connection, potentially with different codecs/bitrate/audio 
channels number/etc. whick makes ffplay go cuckoo. That behavior is not 
problematic.

Before entering the latest fix, grabFrame would return null, and i could 
recognize the event. I could easily revert to the previous version which worked 
for me, but i think that as long as streams are involved the current behavior 
is no good, because it makes grabFrame hand indefinitely.

I am attaching a part of the ffplay printout

max_analyze_duration 5000000 reached at 5014000 microsecondsf=0/0
Input #0, flv, from 'rtmp://wowza.xxxxxxxxxxxx.com:1935/liveapp/Stream20':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: h264 (Baseline), yuv420p, 592x444 [SAR 1:1 DAR 4:3], 12.
42 tbr, 1k tbn, 24 tbc
    Stream #0:1: Audio: nellymoser, 22050 Hz, mono, flt
Stream discovered after head already parsed   5KB sq=    0B f=113/113
AVC: nal size 21151774= 122 aq=    6KB vq=    4KB sq=    0B f=113/113
[h264 @ 000000000598a860] AVC: nal size 21151774
[h264 @ 000000000598a860] no frame!
AVC: nal size 21151774= 122 aq=    6KB vq=    5KB sq=    0B f=113/113
[h264 @ 000000000598ae80] AVC: nal size 21151774
[h264 @ 000000000598ae80] no frame!
deblocking_filter_idc 13 out of rangeB vq=    6KB sq=    0B f=113/113
[h264 @ 000000000598b2e0] decode_slice_header error
number of reference frames (1+1) exceeds max (1; probably corrupt input), discar
ding one
[h264 @ 000000000598b740] number of reference frames (1+1) exceeds max (1; proba
bly corrupt input), discarding one
[h264 @ 000000000598b740] reference count overflow
[h264 @ 000000000598b740] decode_slice_header error
number of reference frames (1+1) exceeds max (1; probably corrupt input), discar
ding one

Original comment by klomm...@gmail.com on 19 Jun 2013 at 8:06

[GoogleCodeExporter]

If ffplay goes haywire, isn't it a bug in FFmpeg? How do you propose to work 
around that?

Original comment by samuel.a...@gmail.com on 22 Jun 2013 at 2:41

[GoogleCodeExporter]

Ah, no, there was a bug in the changes I made. This revision should work as 
before:
http://code.google.com/p/javacv/source/detail?r=a38bec82311333d7ae7d06decdd4a2af
e7c92455
Let me know if you still have problems with that one! Thanks

Original comment by samuel.a...@gmail.com on 22 Jun 2013 at 4:00

[GoogleCodeExporter]

Doesn't work for me. After playing the video for a couple of seconds the 
grabbing thread is getting stuck at FFMpegFrameGrabber.java:551 calling for 
av_read_frame. Then it just hangs, and doesn't continue its work.

As for the FFMpeg behavior when switching codecs in the same stream. Yes, i 
think it's a bug on their part, but so far when i recognize the stream 
characteristics are changing, i just drop the stream, and reload it. Ugly, I 
know, but for now this solution is good enough. 

Thanks

Original comment by klomm...@gmail.com on 25 Jun 2013 at 7:27

[GoogleCodeExporter]

Forget about the previous comment. I reverted to the previous version, and i 
keep getting the same behavior. Must have something to do with my local env.

Original comment by klomm...@gmail.com on 25 Jun 2013 at 11:04

[GoogleCodeExporter]

Tested it now, it works perfectly. Thank you for your help.

K

Original comment by klomm...@gmail.com on 28 Jun 2013 at 9:05

[GoogleCodeExporter]

Great, working fix is now included in the latest JavaCV 0.6 release!

Original comment by samuel.a...@gmail.com on 16 Sep 2013 at 4:09

• Changed state: Fixed