On Mon, Aug 3, 2009 at 3:11 PM, Stephan Assmus <[email protected]> wrote:
> > Sorry for replying to myself, but for future reference, I want to tell the > solution to my problem, in case someone else stumbles over this. I have to > say that there is disappointingly little help from actual FFmpeg developers > on this list. I would expect at least questions for more information, if a > problem cannot be understood at first. > I would have expected more patience -- your original e-mail was sent less that 24 hours ago, and on a Sunday no less. Your response does little to encourage others to help. That said... > Is this behavior intentional? If not, maybe someone could point me at some > code that could be improved, so that opening the codec contexts is not > required anymore when just using the muxer functionality. > The problem is that your code that wraps avformat needs to be responsible for setting the timestamps in the right time-base, regardless of those other encoders. For example, you could have a video encoder doing H263 encoding that is outputting with a time-base of 1/15, but when inserting into FLV with libavformat, the packets need a time-base of 1/1000. I know this isn't code, but perhaps some background on time-bases would help: http://wiki.xuggle.com/Concepts#Time_Bases That article is written referring to the Xuggler API objects, but the concepts are the same for libav (Xuggler's API is a wrapper around libav similar to what you're doing, but in Java). AVCodecContext objects have their own units they can output timestamps in, and because the AVCodecContext doesn't know what AVFormatContext it will eventually end up in, AVStreams also have their own timebase. You must convert as appropriate using the av_rescale classes. See ffmpeg.c and ffplay.c for lots of examples of doing this. When decoding, they convert timestamps on packets from stream-time-bases into a time-base of 1/1000000, and when encoding, they convert as approrpriate to the right time base. Hope that helps, - Art -- 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 [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
