Use h264_rkmpp play rtsp stream, avcodec_receive_frame allways return -11.
#33
Labels
bug
Something isn't working
Comments
|
Use ffplay test is When add |
Coloryr
changed the title
h264_rkmpp play rtsp stream, avcodec_receive_frame allways return -11.h264_rkmpp play rtsp stream, avcodec_receive_frame allways return -11.
|
-11 is https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/decode_video.c |
|
But enough data has already been thrown in, use |
|
|
|
I tried to pull RTMP at a high bit rate, but there was no issus with it. |
|
Can u test the video playback in ffplay locally without using rstp? |
Is work now. but rtsp No work. This work
|
|
Better to use |
|
|
Can u test https://github.com/JeffyCN/FFmpeg and see if it helps? It's a fork from rockchip maintainer. |
|
https://github.com/JeffyCN/FFmpeg Is work |
|
Can u try this patch d6a05bf? |
Nope, it's still
|
|
Pls try this branch https://github.com/nyanmisaka/ffmpeg-rockchip/commits/refactor-dec-logic/ |
|
Is work now |
|
Ok, but need wait until I have some free time |
|
@nyanmisaka may be it is usefull to see -v trace output, i think the crucial part is buffer full msg which is logged in trace level. ffmpeg-rockchip/libavcodec/rkmppdec.c Line 840 in d43f4f5 If there are decoder is buffer full, then that dynamic buffer estimation might be sus. ffmpeg-rockchip/libavcodec/rkmppdec.c Line 881 in d43f4f5 Still speculating though.. @Coloryr is it possible you dump the rtmp stream to a file, and upliad somewgere, so that we can reproduce? Ps: sent from mobile. |
I think it's rk_mpp decoder issus, the stream can play ues VLC or other player. |
Thanks for the testing. @hbiyik I’m thinking of switching back to the jeffyCN’s send-packet/get-frame logic. Because it finishes the task more elegantly and has lower decoding latency (even lower than what I handled in #8). The only change is that we still cannot block during get-frame, otherwise some interlaced mpegts videos will not be able to bail out when errors occur, but will remain stuck. Also due to an assert in ffmpeg 6.1+, we can’t return EAGAIN in draining. |
|
i see, i remember jeffys loop had some implications in throughput and cpu load, and in some cases is spikes massively due to infinite loop, thats why i had switched to an algo which is high in throughput and high in latency and low in cpu usage. So there might be some trade offs there. But my old fork was doing backlog management by its own unlike this fork, things might have changed, therefore it might be reasonable to have some benchmarks there. Related: |
Yes there is a trade-off here. I'd like to keep the rkmppdec latency close to RK gstreamer, otherwise there will be tons of user complaints. Can you test the branch I mentioned above to see if it satisfies your requirements? |
|
yes, i will mos def, i got the hang of it. |
|
@nyanmisaka is there an ffmpeg way of measuring the decoder latency, i was in past using hand made print statements according to my taste, in the decoder and post processing them with excel, but it would be great if i could have some universal method of benchmarking the latency... |
|
IMHO, installing an RTSP server App on your Android phone and letting ffmpeg connect to the phone as a client is currently the most effective way to detect latency that I have found. You only need to compare ffplay on the computer side with the real-time recording on the phone screen. https://play.google.com/store/apps/details?id=com.toysoft.rtspserverpro |
|
ok then ill setup an rtsp server and add some logging in the decoder to measure the decoder latency, it is really necessary to graph the latency by time to compare i guess, visual feedback can be deceiving. |
|
It coming again with rtmp |
|
@nyanmisaka sorry i will not have much time soon to look in to this, if you think it is ok, may be you can just merge jeffy's decoder loop to main. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When debugging with breakpoints, it was found that
avcodec_receive_frameallways return -11.But using
h264is normal, it can display.The text was updated successfully, but these errors were encountered: