[Libav-user] Audio playing to fast using fflplay

iwastemoretimethanu willbeas88 at gmail.com
Wed May 15 21:51:03 CEST 2013

I'm not sure if anyone else has ran into this but the audio is playing much
faster than the video. Here is a little breakdown. Any help would be great,

_Here is what I know_: 

 * I know the sound being grabbed is correct because I made a playback 
   test function. 
 * I know the sound is being encoded into the video file because I can 
   hear the sound when played in ffplay or any other player. 

_Here is the problem_: 

 * When the output video is played, the video starts off at the correct 
   speed, but the audio is playing far too quickly. 
     o For reference, my test output is supposed to be 20 seconds. With 
       my current settings, this is 100 video frames and 100 audio 
       frames at 5 FPS. 
     o All 20 seconds of audio play in the first 5 seconds of the 
       video, which shouldn't be happening simply because the audio and 
       video are being encoded side-by-side (write_audio_frame() is 
       being called directly after write_video_frame()). 
*I also attempted to use atempo

_Here is what I have tried_: 

 * Changing pts values before the encode, after the encode, using the 
   native av_rescale_q() function to try and automatically set the pts 
     o  I have done quite a bit of research on this and it seems to be 
       the consensus that pts is supposed to be set before the frame is 
       encoded into the packet, and I have a formula that should work 
       for both the audio and video pts: 
         + frame_count * (1000/STREAM_FRAME_RATE) * 90 
         + ^ frame scale              ^ getting ms                     
               ^ pts is apparently supposed to be time * 90 
 * Reducing the frames per second to a safe value (well-below the 
   potential of the system) 
 * Switching between the av_interleaved_write_frame() and the manual 

_Here is what I think the problem could be_: 

 * I've always thought it could be the pts/dts that are off, as those 
   are what are supposed to be controlling the speed/when the sound is 
   played...but considering how many different ways I've modified these 
   and tried things that I think should have worked with my 
   understanding of them and how little any of my trials have mattered 
   in the output file, I'm beginning to think the possibility of this 
   being the problem is getting slimmer and slimmer. 

_Technical details about the audio data (just in case)_: 

 * Using SFML (Built off of OpenAL) to grab the data 
 * Developing on Windows, audio data is being grabbed from the muxer 
   with the microphone disabled. 
 * The sound data is PCM, 16 bit (stored as int16_t*) 
 * I started off using an algorithm that interlaced the audio with the 
   video manually by using a method of 
     o if audio->pts < video->pts, write another audio frame 
     o else write video frame 
 * I now just encode an audio frame after every video frame because it 
   /should /sync itself, considering the audio is being grabbed while 
   the video is being encoded 
 * I have access to the raw buffered audio data (int16_t*), the sample 
   rate (uint), the channel count (uint), and the sample count (size_t).

View this message in context: http://libav-users.943685.n4.nabble.com/Audio-playing-to-fast-using-fflplay-tp4657609.html
Sent from the libav-users mailing list archive at Nabble.com.

More information about the Libav-user mailing list