gstavauddec could not drain decoder after hlsdemux switching bitrate
Locked
 
|
Hi, I'm modifying Android tutorial 5 for a HLS player. The branch used is 1.16.1. I encountered the issue in https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/189, so I do not use omx.google.aac.decoder. I do not know why the bug is still not fixed on 1.16.1. I use that from libav instead. Now the player plays HLS links with a constant connection-speed perfectly. But if hlsdemux switches bitrate, buffering drops under 10% immediately. I examined the following logs, it seams that gstavauddec cannot drain decoder after switching bitrate, which leads to the buffering problem. Is there a bug in gstreamer's code which results in this issue? Or is this buffering problem can be solved by turing buffer-duration or buffer-size? ---- Logs starts here ---- 19:04:03.201 V [InulPlayer] setMessage: Buffering 98% 19:04:03.204 V [InulPlayer] setMessage: Buffering 99%19:04:03.961 V [InulPlayer] setMessage: State changed to PLAYING ... 19:04:09.139 I ┌ 0:00:38.359795268 0x8a66ab80 ../ext/hls/gsthlsdemux.c:1601:gst_hls_demux_ 19:04:09.139 I ├ change_playlist:<hlsdemux0> Client was on 1500000bps, max allowed is 1134 19:04:09.139 I └ 260bps, switching to bitrate 800000bps ... 19:04:14.177 W ┌ 0:00:43.397305312 0x7cbf4db0 ../ext/libav/gstavauddec.c:628:gst_ffmpegaud 19:04:14.177 W └ dec_drain:<avdec_aac0> send packet failed, could not drain decoder 19:04:14.957 I Rkvpu_SendInputData(449): send eos 19:04:15.361 V [InulPlayer] setMessage: Buffering 5% 19:04:15.362 V [InulPlayer] setMessage: Buffering 10% 19:04:15.362 V [InulPlayer] setMessage: Buffering 11% 19:04:15.363 V [InulPlayer] setMessage: Buffering 12% 19:04:15.383 I ┌ 0:00:44.601697021 0x7cb9c980 ../gst/playback/gstplaybin2.c:3779:no_more_p 19:04:15.383 I └ ads_cb:<playbin0> setting custom audio sink <openslessink0> 19:04:15.383 I ┌ 0:00:44.603441188 0x7cb9c980 ../gst/playback/gstplaybin2.c:3786:no_more_p 19:04:15.383 I └ ads_cb:<playbin0> setting custom video sink <glimagesinkbin0> 19:04:15.384 V [InulPlayer] setMessage: Buffering 13% 19:04:15.402 V [InulPlayer] setMessage: Buffering 14% -- Sirius Wu _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: gstavauddec could not drain decoder after hlsdemux switching bitrate
|
|
Le samedi 09 novembre 2019 à 20:07 +0800, Sirius Wu a écrit :
> Hi, > > I'm modifying Android tutorial 5 for a HLS player. The branch used is > 1.16.1. > > I encountered the issue in > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/189, > so I do not use omx.google.aac.decoder. I do not know why the bug is > still not fixed on 1.16.1. I use that from libav instead. Feel free to submit a merge request if you have a solution for this. Note that omx.google.* are software CODECs, so they aren't always worth using over ffmpeg. > > Now the player plays HLS links with a constant connection-speed > perfectly. But if hlsdemux switches bitrate, buffering drops under > 10% immediately. > > I examined the following logs, it seams that gstavauddec cannot drain > decoder after switching bitrate, which leads to the buffering > problem. > > Is there a bug in gstreamer's code which results in this issue? > > Or is this buffering problem can be solved by turing buffer-duration > or buffer-size? > > ---- Logs starts here ---- > > 19:04:03.201 V [InulPlayer] setMessage: Buffering 98% > 19:04:03.204 V [InulPlayer] setMessage: Buffering 99% > 19:04:03.961 V [InulPlayer] setMessage: State changed to PLAYING > ... > 19:04:09.139 I ┌ 0:00:38.359795268 0x8a66ab80 > ../ext/hls/gsthlsdemux.c:1601:gst_hls_demux_ > 19:04:09.139 I ├ change_playlist:<hlsdemux0> Client was on > 1500000bps, max allowed is 1134 > 19:04:09.139 I └ 260bps, switching to bitrate 800000bps > ... > 19:04:14.177 W ┌ 0:00:43.397305312 0x7cbf4db0 > ../ext/libav/gstavauddec.c:628:gst_ffmpegaud > 19:04:14.177 W └ dec_drain:<avdec_aac0> send packet failed, could > not drain decoder This needs investigating. Seems like an interesting bug. > 19:04:14.957 I Rkvpu_SendInputData(449): send eos > 19:04:15.361 V [InulPlayer] setMessage: Buffering 5% > 19:04:15.362 V [InulPlayer] setMessage: Buffering 10% > 19:04:15.362 V [InulPlayer] setMessage: Buffering 11% > 19:04:15.363 V [InulPlayer] setMessage: Buffering 12% > 19:04:15.383 I ┌ 0:00:44.601697021 0x7cb9c980 > ../gst/playback/gstplaybin2.c:3779:no_more_p > 19:04:15.383 I └ ads_cb:<playbin0> setting custom audio sink > <openslessink0> > 19:04:15.383 I ┌ 0:00:44.603441188 0x7cb9c980 > ../gst/playback/gstplaybin2.c:3786:no_more_p > 19:04:15.383 I └ ads_cb:<playbin0> setting custom video sink > <glimagesinkbin0> > 19:04:15.384 V [InulPlayer] setMessage: Buffering 13% > 19:04:15.402 V [InulPlayer] setMessage: Buffering 14% > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
I tried to investigate it myself. As a first step I tried to print the return value of avcodec_send_packet. It's a Unknown error -1624. I cloned the source of FFmpeg branch 4.1, modified the source code of avcodec_send_packet, trying to find the cause of this error. But my modified FFmpeg cannot output any logs. I've pass GST_DEBUG="libav:5", but only messages from gst-libav-1.0 are logged. Those from FFmpeg are not logged. From what I have seen in gst-libav, debug category libav should also works for FFmpeg. Any idea to investigate this bug? Nicolas Dufresne <[hidden email]> 於 2019年11月9日 週六 下午9:19寫道： Le samedi 09 novembre 2019 à 20:07 +0800, Sirius Wu a écrit : -- Sirius Wu _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Nicolas Dufresne-5
Hi Nicolas, The "send packet failed" message is already fixed in the following commit. But the buffering drop still need to be investigate. I'm doing the investigation myself, could you give me some hint? Nicolas Dufresne <[hidden email]> 於 2019年11月9日 週六 下午9:19寫道： Le samedi 09 novembre 2019 à 20:07 +0800, Sirius Wu a écrit : -- Sirius Wu _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |