<div dir="ltr"><div>Hi Arun,<br></div><div>May request your opinion on the clocking and basesink logs. Shall I provide more details or enable more logs ?</div><div>Kindly suggest.</div><div><br></div><div>Hi Enrique.</div><div>Thanks. I shall check and get back. In case you have more comments based on my latest updates, please suggest.</div><div><br></div><div>--Nitin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 3:55 PM, Enrique Ocaña González <span dir="ltr"><<a href="mailto:eocanha@igalia.com" target="_blank">eocanha@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">El jueves, 8 de junio de 2017 14:18:51 (CEST) Nitin Mahajan escribió:<br>
<br>
> The sequence of operations done on adaptive demux plugin are as follows:<br>
> On audio src pad of demux:<br>
> Flush buffered audio packets:<br>
> - push gst_event_new_flush_start()<br>
> - push gst_event_new_flush_stop(<wbr>FALSE)<br>
> - push new segment event<br>
> - push buffers with the time stamps corresponding to the current<br>
> presentation time<br>
<br>
</span>First of all, sorry if my comment isn't completely related to the problem you<br>
describe. Feel free to ignore it if it only adds noise to the discussion. I<br>
think it might be relevant, though.<br>
<br>
I'm having a similar problem in our use case: Two appsrcs pushing already<br>
demuxed buffers (video/x-h264 and audio/mpeg) and the pipeline filled of<br>
buffers. Then our app receives an update of some of the audio buffers (eg:<br>
higher/lower quality) and needs to replace the buffers already in the pipeline<br>
(playbin) in a seamless way (keeping the streamsynchronizer happy and the<br>
video stream unaware of the replacement in the audio stream).<br>
<br>
We do something similar to what you describe:<br>
<br>
- We ask the pipeline for the current position (the PTS of the buffer being<br>
rendered)<br>
- We send flush start and stop (false) events<br>
- Use gst_base_src_new_seamless_<wbr>segment() to send a new [position, old_stop]<br>
  segment (to convince appsrc to schedule the new buffers properly)<br>
- Fix the segment emitted by appsrc using a probe, so it's again [position,<br>
  old_stop] and clear flags (not reset-time).<br>
<br>
The new replacement buffers start to fill the audio stream of the pipeline<br>
again, the faad audio decoder does fine (thanks to the flush), and the audio<br>
buffers reach the audio sink (GstOMXHdmiAudioSink). So far so good.<br>
<br>
Then the problems start. For some reason, audiobasesink doesn't reconfigure<br>
its audioringbuffer properly. Normally, I have a diff of ~40 between segdone<br>
(the write position in the audioringbuffer) and readseg (the read position of<br>
the data that goes to the actual audio device). That matches with segtotal<br>
(the size of the audioringbuffer). However, after the flushes and new segment<br>
the diff is ~15000 (clearly wrong, much higher than segtotal). This causes<br>
gst_audio_ring_buffer_commit() (implemented by default_commit) to wait until<br>
the diff is again less than segtotal. It waits forever.<br>
<br>
This long audio sink wait stalls the audio stream and we start to lose audio.<br>
<br>
If you want to know if you're having the same problem as we have, enable these<br>
logs:<br>
<br>
 GST_DEBUG='basesink:TRACE,<wbr>ringbuffer:TRACE,audiosink:<wbr>TRACE,\<br>
           audiobasesink:TRACE,<wbr>audioclock:DEBUG'<br>
<br>
and grep for this kind of messages:<br>
<br>
 cat /tmp/log.txt | grep default_commit | grep 'diff'<br>
<br>
You should see the diff jump (from ~40 to ~15000) like this:<br>
<br>
0:00:25.508332021  1277 0x72e0d4f0 DEBUG             ringbuffer<br>
gstaudioringbuffer.c:1525:<wbr>default_commit:<<wbr>audiosinkringbuffer0> pointer at<br>
1033, write to 1072-1340, diff 39, segtotal 40, segsize 1764, base 0<br>
0:00:25.508480042  1277 0x72e0d4f0 DEBUG             ringbuffer<br>
gstaudioringbuffer.c:1525:<wbr>default_commit:<<wbr>audiosinkringbuffer0> pointer at<br>
1033, write to 1073-0, diff 40, segtotal 40, segsize 1764, base 0<br>
0:00:25.615070250  1277 0x72e0d4f0 DEBUG             ringbuffer<br>
gstaudioringbuffer.c:1525:<wbr>default_commit:<<wbr>audiosinkringbuffer0> pointer at<br>
1034, write to 16497-1204, diff 15463, segtotal 40, segsize 1764, base 0<br>
0:00:25.615523479  1277 0x72e0d4f0 DEBUG             ringbuffer<br>
gstaudioringbuffer.c:1525:<wbr>default_commit:<<wbr>audiosinkringbuffer0> pointer at<br>
1035, write to 16497-1204, diff 15462, segtotal 40, segsize 1764, base 0<br>
<br>
I haven't found a solution yet and by now we're just applying a workaround on<br>
the app side to avoid the need of replacing already buffered audio data.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Enrique Ocaña González<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.<wbr>freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a><br>
</div></div></blockquote></div><br></div>