Hi Tyler,
Not to take you off track, but the Xuggler project
(http://www.xuggle.com/xuggler) is a SWIG-based wrapper around FFMPEG
that works with Java. It should be possible to extend it for Python
support (and you can work around the threading issues) by
reimplementing the com::xuggle::ferry library for the Python API (my
guess is this is 1-2 weeks worth of work for a Python API expert with
some guidance from us).
But regardless, often the audio and video sync issues are because
you're incorrect calculating the timestamps coming out of FFMPEG. And
frankly, sometimes you have to keep track and generate the timestamps
yourself. In xuggler if you're interested, look at:
csrc/com/xuggle/xuggler/StreamCoder.cpp
In the decodeAudio and decodeVideo methods you'll see our timestamp
tracking code which might help you for reference
If you want to avoid looking at YET another code base, take a look at
the time stamp tracking code in ffplay.c in the ffmpeg library.
Lastly, make sure you have a good understanding of how time bases work
in FFMPEG and that you are converting your audio and video timestamps
to the right units. In Xuggler we choose to convert everything to
Microseconds (as does ffplay.c), and I suggest you do the same.
Here's a write-up we did for Xuggler users on what time-bases are:
http://wiki.xuggle.com/Concepts
- Art
> _______________________________________________
On Fri, Jun 5, 2009 at 9:48 AM, Tyler Laing<trinioler@xxxxxxxxx> wrote:
> Hello to all concerned,
>
> I am a GSOC student, currently working on writing an effective movie wrapper
> for Python/Pygame around the ffmpeg libraries.
>
> However, I have run into some issues, for which I need assistance and/or
> information.
>
> Short Problem: My video runs too fast.
>
> Explanation: I am operating under specific constraints which are:
>
> - No threads, or if possible no threads that manipulate the members of
> structures. The reason is that Python is not thread-safe, which ends up
> requiring a lot of threading primitives to do effective work.
> - No audio information. The accepted method of audio for video players
> seems to be using SDL's audio primitives, like SDL_OpenAudio, and so on.
> This spawns a thread which manipulates structures out of my control, except
> for during the callback.
> - I'd like to avoid placing events on or off the event queue, as the
> wrapper will be in use within games, which of course require the event queue
> to be left alone
>
> If you have an idea on how to work around the constraints, or why the
> constraint doesn't matter, I'd of course be glad to hear it. I have
> successful, fluid video, which unfortunately runs just a bit too fast. I
> would like some information on if it is possible to do video synchronization
> without the audio information, or if its even recommended?
>
> Thank you ahead of time,
>
> Tyler
>
> --
> Visit my blog at http://oddco.ca/zeroth/zblog
> libav-user mailing list
> libav-user@xxxxxxxxxxxx
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
>
--
http://www.xuggle.com/
xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and video.
Use Xuggle to get the power of FFMPEG in Java.
_______________________________________________
libav-user mailing list
libav-user@xxxxxxxxxxxx
https://lists.mplayerhq.hu/mailman/listinfo/libav-user