search

huceke / omxplayer

omxplayer
GNU General Public License v2.0
519 stars 503 forks source link

Live streams start late #47

Open julianscheel opened 11 years ago

julianscheel commented 11 years ago

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.

torarin commented 11 years ago

The HTTP and HLS streams I have tried have all loaded reasonably fast.

Could it be libavformat's fault?

julianscheel commented 11 years ago

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.

torarin commented 11 years ago

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

julianscheel commented 11 years ago

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.

julianscheel commented 11 years ago

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.

julianscheel commented 11 years ago

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.

SamuelGreen commented 10 years ago

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?

SamuelGreen commented 10 years ago

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.