<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Further investigation - it seems that alsasrc is creating audio buffers each with a timestamp of 0. I have run alsasrc -> audiorate -> wavenc and alsasrc -> wavenc and both show this timestamp. alsasrc does not appear to log any debug information.<br> <br> This timestamp means that audiorate drops all buffers after the first since all the subsequent ones are seen as duplicates.<br> <br> I do not know whether avimux gets upset by receiving timestamped video but audio with a timestamp of 0.<br> <br> Is this a bug on the part of alsasrc or a feature?<br> <br> Ian<br> <br> <div class="moz-cite-prefix">On 19/01/2013 16:31, Ian Davidson wrote:<br> </div> <blockquote cite="mid:50FACA7E.2090907@blueyonder.co.uk" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> I have done some analysis of the trace from Attempt 4, Outcome 1 in the document I attached previously.<br> <br> Execution ended after 1819237914 ns. In that time, I noticed that avimux logged "gst_avi_mux_do_one_buffer:<mux> selected pad <title></title> <meta name="GENERATOR" content="OpenOffice.org 3.4.1 (Win32)"> <style type="text/css">  </style>audio_0" 174 times, and each time the given time was <meta http-equiv="CONTENT-TYPE" content="text/html; charset=ISO-8859-1"> 0:00:00.000000000 <title></title> <meta name="GENERATOR" content="OpenOffice.org 3.4.1 (Win32)"> <style type="text/css"> <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } --......</style>. In the same time, 'do_one_buffer' was called for the video pad 27 times, starting at 0:00:00.6307555650 and ending at 0:00:01.669455512.<br> <br> It seems to me that the video data is getting passed through with a timestamp for each 'packet', but that the audio stream does not have an incrementing timestamp.<br> <br> Could this be causing the problem?<br> <br> Ian</blockquote> <br> </body> </html>