omxplayer
omxplayer copied to clipboard
huceke
Live streams start late
I'm testing omxplayer with http live streams currently, which actually means, that http-based read-ahead is not possible. In this scenario omxplayer takes very long (~8seconds) before it detects the stream details and starts the actual playback. Any thoughts why this takes so long? The provided content is MPEG2 in MPEG-TS container, which should be parseable in <1 second in any case. If there is no obvious solution, I will try to debug this within the next days, as far as my time allows.
The HTTP and HLS streams I have tried have all loaded reasonably fast.
Could it be libavformat's fault?
As far add I remember for hls streams the server has to provide at least one complete segment file from the beginning on. This would allow the client to do a read ahead. So this case might not be relevant. Also streaming of full sized files through http is likely not an issue as read ahead is possible in that case anyway.
Do you have tested with a http steam, which is actually a live stream serving data only at the streams original datarate? I fear the avformat_open_input is not really designed for this case.
Does NASAs live stream qualify? http://nasa-f.akamaihd.net/public_h264_400@54826?v=1.1.12&fp=LNX%2011,3,31,218&r=IFPQW&g=QGNPRGYTQFCB
That one might qualify. I will check it tomorrow when I have access to my raspberry pi. It's powered down right now, so no remote access.
Maybe the container format itself is relevant as well. That is flv for the NASA stream, while I see the issues with mpeg-ts streams. If you do have a dvb-card tvheadend should qualify as a good test.
I just tested the NASA example stream. That one does not show the problematic behaviour. I will try to find a public stream which triggers the issue.
Actually I did some more testing now. The time is lost in avformat_find_stream_info which takes ~5seconds for mpeg-ts live streams, which is very long. I'm wondering which parameters take that long to be retrieved and if they are really needed before starting the playback.
Hi, I'm having the exact same "slow start" problem. In my case it could be between 1-120 seconds before the stream starts. Did you find any solution to this problem?
We're using Wowza transrating an incoming rtmp H.264 stream to HLS. I did solve my "slow start" problem by doing a complete "transcoding" instead of "transrating". After this the "slow start" problem is no more. The first "transrated" version did start fast on all other devices and the problem was only shown in omxplayer on raspberry pi.