<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
-->
</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<br>
<br>
<br>
<div class="moz-cite-prefix">On 18/01/2013 13:37, Ian Davidson
wrote:<br>
</div>
<blockquote cite="mid:50F95010.3080703@blueyonder.co.uk" type="cite">Hi
Tim,
<br>
<br>
No luck yet.
<br>
<br>
I did a number of tests and put the results in the attached
document (which has a Table of Contents to aid finding particular
sections). The document contains the complete script I used each
time - partly for completeness and partly so I don't lose
anything.
<br>
<br>
I did the script as detailed below with various levels of debug.
I removed the Audio branch, and I included videorate and
audiorate.
<br>
<br>
Without videorate/audiorate I consistently got an AVI file where
the audio was the complete length and the video was very short.
With both videorate and audiorate included, I got a very short AVI
file and I notice that audiorate repeatedly reported that it was
dropping 441 samples (which was all the samples it had apparently
received).
<br>
<br>
I am prepared to believe that I have done something stupid - but I
suspect that it is not all my fault!
<br>
<br>
Ian
</blockquote>
<br>
</body>
</html>