On Fri, Jun 5, 2009 at 9:55 AM, Art Clarke <acla...@xuggle.com> wrote:
> 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<trinio...@gmail.com> 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-u...@mplayerhq.hu > > 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-u...@mplayerhq.hu > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > Much thanks Art. I had been using the ffmpeg tutorial, which was okay. However, once I fully adapted ffplay's system to mine, it worked perfectly. A few momentary jitters at the beginning of the video, but that is more an I/O issue. I really appreciate the help, thank you. :) Now onto all of the other fun stuff like audio and subtitles! -Tyler -- Visit my blog at http://oddco.ca/zeroth/zblog
