Closed GoogleCodeExporter closed 9 years ago
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
Issue 277 has been merged into this issue.
Original comment by samuel.a...@gmail.com
on 11 May 2013 at 6:20
Works correctly right now.
Thanks,
Original comment by Qzts...@gmail.com
on 13 May 2013 at 8:07
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
Qzts...@gmail.com
on 8 May 2013 at 2:33Attachments: