Lost video

[Ian Davidson]

I have done some analysis of the trace from Attempt 4, Outcome 1 in the 
document I attached previously.

Execution ended after 1819237914 ns.  In that time, I noticed that 
avimux logged "gst_avi_mux_do_one_buffer:<mux> selected pad audio_0" 174 
times, and each time the given time was 0:00:00.000000000 .  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.

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.

Could this be causing the problem?

Ian


On 18/01/2013 13:37, Ian Davidson wrote:
> Hi Tim,
>
> No luck yet.
>
> 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.
>
> I did the script as detailed below with various levels of debug. I 
> removed the Audio branch, and I included videorate and audiorate.
>
> 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).
>
> I am prepared to believe that I have done something stupid - but I 
> suspect that it is not all my fault!
>
> Ian 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130119/743dc0f9/attachment.html>