FFmpegFrameGrabber won't grab till the end of video. about javacv HOT 12 CLOSED

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!

Issue 277 has been merged into this issue.

Works correctly right now. 

Thanks, 

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

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

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

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

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

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

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.

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

K

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