mirror of
https://github.com/nyanmisaka/ffmpeg-rockchip.git
synced 2026-01-24 07:31:22 +01:00
Use h264_rkmpp play rtsp stream, avcodec_receive_frame allways return -11. #22
Labels
No labels
bug
enhancement
help wanted
invalid
pull-request
question
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/ffmpeg-rockchip#22
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Coloryr on GitHub (Mar 5, 2024).
When debugging with breakpoints, it was found that
avcodec_receive_frameallways return -11.But using
h264is normal, it can display.@Coloryr commented on GitHub (Mar 5, 2024):
Use ffplay test is
When add
-vcodec h264_rkmppdisplay is null.@nyanmisaka commented on GitHub (Mar 6, 2024):
-11 is
AVERROR(EAGAIN). This means you need to feed more packets to get a new frame.You'd better learn how to handle
AVERROR(EAGAIN)from the official examples.https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/decode_video.c
@Coloryr commented on GitHub (Mar 6, 2024):
But enough data has already been thrown in, use
h264will get the result soon, but h264_rkmpp not.And not this issus when playing videos with higher bitrates in local, only occurs when pulling down the bitrate RTSP stream.
已经丢了足够多的数据了，使用
h264马上就能出帧了，但是用h264_rkmpp就是不出帧本地放高码率视频也没，就拉低码率rtsp流有
@Coloryr commented on GitHub (Mar 6, 2024):
movie.zip
I use ffmpeg rtsp to push this.
我用ffmpeg rtsp推流这个
@Coloryr commented on GitHub (Mar 6, 2024):
I tried to pull RTMP at a high bit rate, but there was no issus with it.
后面我试着拉rtmp高码率也没这个问题
@nyanmisaka commented on GitHub (Mar 6, 2024):
Can u test the video playback in ffplay locally without using rstp?
@Coloryr commented on GitHub (Mar 6, 2024):
Is work now.
but rtsp
No work.
This work
@nyanmisaka commented on GitHub (Mar 6, 2024):
Better to use
-v debugand see what's going on.@Coloryr commented on GitHub (Mar 6, 2024):
@nyanmisaka commented on GitHub (Mar 6, 2024):
Can u test https://github.com/JeffyCN/FFmpeg and see if it helps? It's a fork from rockchip maintainer.
@Coloryr commented on GitHub (Mar 6, 2024):
https://github.com/JeffyCN/FFmpeg Is work
@nyanmisaka commented on GitHub (Mar 6, 2024):
Can u try this patch d6a05bf?
@Coloryr commented on GitHub (Mar 6, 2024):
Nope, it's still
timeout, test version is@nyanmisaka commented on GitHub (Mar 6, 2024):
Pls try this branch https://github.com/nyanmisaka/ffmpeg-rockchip/commits/refactor-dec-logic/
@Coloryr commented on GitHub (Mar 6, 2024):
Is work now
@nyanmisaka commented on GitHub (Mar 6, 2024):
@Coloryr Can u try one more change and see if it still works?
9d14c5f878@Coloryr commented on GitHub (Mar 6, 2024):
Ok, but need wait until I have some free time
@hbiyik commented on GitHub (Mar 7, 2024):
@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.
d43f4f54e6/libavcodec/rkmppdec.c (L840)If there are decoder is buffer full, then that dynamic buffer estimation might be sus.
d43f4f54e6/libavcodec/rkmppdec.c (L881)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.
@Coloryr commented on GitHub (Mar 7, 2024):
I think it's rk_mpp decoder issus, the stream can play ues VLC or other player.
@Coloryr commented on GitHub (Mar 7, 2024):
Yes, it work.
@nyanmisaka commented on GitHub (Mar 7, 2024):
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.
@hbiyik commented on GitHub (Mar 7, 2024):
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:
https://github.com/JeffyCN/FFmpeg/issues/18#issuecomment-1529167815
https://github.com/JeffyCN/FFmpeg/issues/18#issuecomment-1784135052
@nyanmisaka commented on GitHub (Mar 7, 2024):
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?
@hbiyik commented on GitHub (Mar 7, 2024):
yes, i will mos def, i got the hang of it.
@hbiyik commented on GitHub (Mar 15, 2024):
@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...
@nyanmisaka commented on GitHub (Mar 15, 2024):
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
@hbiyik commented on GitHub (Mar 15, 2024):
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.
@Coloryr commented on GitHub (Mar 26, 2024):
It coming again with rtmp
@hbiyik commented on GitHub (Apr 9, 2024):
@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.
@nyanmisaka commented on GitHub (Apr 24, 2024):
Closing in
6f88a29and1fa586a.