Audio playing to fast using fflplay
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
* 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.