Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 823764" data-attributes="member: 10858">Flushing might not be mandatory, but it might help keeping the renderer's in sync (dropped data could be happening only on the one stream - and definitely wont be same amount of gap on both streams).But I'm not 100% sure if it is really needed. Probably it is better not to flush since it would cause much bigger wholes in the timeline (all queued data in decoders and renderers would be dropped).Cannot remember what defines the queue lenght (or how it even works <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />) - would be good if someone could continue the audio renderer work (as he would be pretty much in the same situation than I as it has been over a year when I have last looked into that code).What comes to discontinuity handling, the old TsReader has worked with short discontinues at least. I have one .ts file that is having hundreds of different types of dropped data gaps - audio renderer is passing that &quot;reference&quot; without any issues. So the assumption about short gaps causing the renderer queue to behave badly is probably wrong. It must be something else.A log with the sample timestamps would reduce the quessing a lot <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /></blockquote>

[QUOTE="tourettes, post: 823764, member: 10858"] Flushing might not be mandatory, but it might help keeping the renderer's in sync (dropped data could be happening only on the one stream - and definitely wont be same amount of gap on both streams). But I'm not 100% sure if it is really needed. Probably it is better not to flush since it would cause much bigger wholes in the timeline (all queued data in decoders and renderers would be dropped). Cannot remember what defines the queue lenght (or how it even works :)) - would be good if someone could continue the audio renderer work (as he would be pretty much in the same situation than I as it has been over a year when I have last looked into that code). What comes to discontinuity handling, the old TsReader has worked with short discontinues at least. I have one .ts file that is having hundreds of different types of dropped data gaps - audio renderer is passing that "reference" without any issues. So the assumption about short gaps causing the renderer queue to behave badly is probably wrong. It must be something else. A log with the sample timestamps would reduce the quessing a lot :) [/QUOTE]

Verification