On Sat, Mar 08, 2008 at 12:11:08PM +0100, Xawotihs wrote: > On Sat, Mar 8, 2008 at 1:51 AM, Michael Niedermayer <[EMAIL PROTECTED]> > wrote: > > > On Tue, Mar 04, 2008 at 01:53:10AM +0100, Xawotihs wrote: > > > Hello ffmpeg gurus, > > > > > > I've written a directshow splitter somehow working based on > > > libavformat, now I've decided to write a muxer. > > > > > > So, Directshow gives me some compressed "mediasamples" with a > > > timestart and timestop in what they call REFERENCE_TIME (1/10000000 > > > second since the beginning of the stream). > > > Now, I've got that and I need to fill libavformat AVStream structures > > > and also the AVPacket structure for each mediasample. So, because I'm > > > lazy I thought I would just hardcode the AVStream.time_base for all my > > > streams to 1/10000000 and just use the real duration of my packets > > > (timestop-timestart) for each packet as the AVPacket.duration ... big > > > mistake :) > > > > > > Actually it works for audio on the small wav file I produced, but for > > > video, my windows explorer freezes completly each time I open the > > > directory containing my produced .avi file ... When I open the > > > produced file in virtualdub, it tells me my files uses a framerate of > > > 10000000 fps and contains 99.1% overhead =) > > > > > > So, I looked at the code a bit and I noticed AVStream.duration is not > > > used at all in the AVI muxer, it's barelly used in the MOV muxer, and > > > kinda used in the MKV muxer... > > > Am I doomed to guess a constant framerate from my video stream and set > > > that as AVStream.time_base ? > > > > AVStream.time_base is not supposed to be written to by the user. You can > > set AVCodecContext.time_base. > > AVI has some overhead problems with large timebases, but the fact that > > MS can generate avis shows the API must provide a frame rate. > > > I just checked my code and I was indeed setting AVCodecContext.time_base and > not AVStream.time_base. Sorry for the confusion. > > So, to pick a concrete example, if I set > > AVCodecContext.time_base.num = 1 > AVCodecContext.time_base.den = 100000000 > AVPacket1.PTS = 0 > AVPacket1.duration = 400000, > AVPacket2.PTS = 400000 > AVPacket2.duration = 400000. > > It's completly normal that I'm creating a 10000000 fps AVI movies full of > NULL frame and once every 400000 frames, a real codec frame lasting > 1/1000000 second and not a 25 fps movie ?
Yes, lavf/lavc just do what you tell them to, There are no timestamps in avi the only way to achive 25fps with a timebase of 1/10000000 is to add a "few" null frames. > > For me the input needed to get such movie would have been: > AVCodecContext.time_base.num = 1 > AVCodecContext.time_base.den = 100000000 > AVPacket1.PTS = 0 > AVPacket1.duration = 1, > AVPacket2.PTS = 400000 > AVPacket2.duration = 1. This is invalid because the AVPacket durations when added dont match the timesamps (PTS/DTS) at all. So behavior of this is undefined ... > > When I looked at the AVI muxer code, I noticed that AVPacket.duration was > not used by the AVI muxer ... When I looked at the MOV muxer, I noticed the > AVPacket.duration seems strangely used and it seemed ok in the MKV muxer. > > My real problem is that DirectShow gives me at filter connection time an > average frame duration, I can easily use that to compute an average frame > rate, but that's just average, what will happen if suddendly a frame last > 1.5 times as much than the others ? You wouldnt be able to store that exactly, a duration 2 frame though could be stored. If DirectShow doesnt provide anything else then its not possible to store exact frame timestamps with directshow. With non avi simply using 1/100000000 or 1/1000 as timebase should work fine, with avi due to null frame overhead simply using the average and hoping its not just the average might work out mostly. Anyway there is no situation in which the average is usefull so DirectShow is misdesigned. What would be usefull is the simplest timebase in which all frames can be specified exactly. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
