GNOME Bugzilla – Bug 729360
playbin: Stall with buffering flag set, file:// or pushfile:// and high bitrate video
Last modified: 2017-05-16 19:41:59 UTC
While trying to test enabling buffer in playbin, I had this case where buffering stall after a while when using what I though was the easy case, filesrc. It happens for H264 stream at relatively high bitrate, e.g. Sintel.2010.1080p.mkv. It does not stall if streaming from http. Test stream: http://ftp.nluug.nl/pub/graphics/blender/demo/movies/Sintel.2010.1080p.mkv Test pipeline: gst-launch-1.0 playbin uri=pushfile:///tmp/Sintel.2010.1080p.mkv flags=video+audio+buffering I've get the same stalls with 1.2 and 0.10, surprisingly. So it does not look like a recent regression. Smaller videos just work. It happens also with the highest quality of MOV files from apple trailers.
Same here, seems to mostly happen on huge movies and especially matroska for some reason. Only happened for me when using "navseek ! xvimagesink" as video-sink, and then after seeking. Not on start.
Video: update_buffering:<multiqueue0> queue 0: visible 26/0, bytes 2157338/2097152, time 1125000000/5000000000 Audio: update_buffering:<multiqueue0> queue 1: visible 15/0, bytes 38400/2097152, time 480000000/5000000000 matroskademux is blocked waiting for space in the video queue The video bytes limit is easily reached, while both time limits are still very low. With buffering enabled downstream will block in PAUSED and the audio queue won't get filled to get buffering to 100% again. Downstream vqueue and aqueue are also filled in this scenario (3 buffers on video and over 1s in audio)
So what can we do about this one, other than increasing the buffer limits to yet another magic number?
(In reply to comment #3) > So what can we do about this one, other than increasing the buffer limits to > yet another magic number? I suppose this is the easiest solution for now. I'm not sure I understand enough, but I saw this bug about adding an event to tell downstream how much buffering is needed. Could that eventually be used ? If so, because I suppose demuxer don't really know in advance, will it be possible to grow that buffering dynamically as needed ? Again, I'm missing a lot of knowledge in the field.
(In reply to comment #4) > (In reply to comment #3) > > So what can we do about this one, other than increasing the buffer limits to > > yet another magic number? > > I suppose this is the easiest solution for now. I'm not sure I understand > enough, but I saw this bug about adding an event to tell downstream how much > buffering is needed. Could that eventually be used ? If so, because I suppose > demuxer don't really know in advance, will it be possible to grow that > buffering dynamically as needed ? Again, I'm missing a lot of knowledge in the > field. The use case for this event is that some formats (i.e. HLS) have a suggested buffering size but in a generic scenario this is hard to predict as we need to consider compression/dimensions at the demuxer level. Didn't we have an algorithm that would allow multiqueue to increase its limits automatically until it has prerolled? Maybe this is enough to give us a hint at the amount of buffering needed?
It is there, but only affecting the buffer limit. Not bytes or time. Once pre-rolled the limit will never shrink below the automatically grown limit.
How about demuxer suggest buffering size by using combination of Codec/resolution/bitrate information on it. ex) HEVC, H264 5.1profile, 3840 × 2160 resolution
Does the patch in bug #733235 fix this one too?
(In reply to Sebastian Dröge (slomo) from comment #8) > Does the patch in bug #733235 fix this one too? I tried, and that patch does not apply on git master.
With git master, ignoring this patch, the playback does not stall any-more, but it PAUSE/PLAY for buffering purpose very very often. That causes choppy playback.
Server is still too slow, but seems to work these days.