On Sun, Mar 9, 2008 at 4:11 PM, Michael Niedermayer <[EMAIL PROTECTED]> wrote: > On Sat, Mar 08, 2008 at 12:11:08PM +0100, Xawotihs wrote: > > 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.
OK, I'm starting to get it ... I first thought that your timebase was a generic clock concept similar to the timescale of quicktime's track ... but it's not that at all, it just has to be the minimum framerate needed to express all the frame duration of the stream. Btw, another good one that I found while playing with the mov muxer ... as I had the average frame duration in 1/10000000 second from directshow , and I read that I had to put the frame rate as time base, I just put AVCodecContext.time_base.num = 400000 AVCodecContext.time_base.den = 10000000 and then AVPacket1.PTS = 0 AVPacket1.duration = 1, AVPacket2.PTS = 1 AVPacket2.duration = 1. This time I should have done it correct, right ? Not at all, this caused my .mov file to play super fast ... because the mov muxer uses AVCodecContext.time_base.den only as timescale for its video track ... And I think audio tracks just uses the samplerate, they ignore the timebase set ... Maybe I should report that in the ffmpeg-devel list ? > > 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 ... Depends of your point of view I guess. This is perfectly valid directshow media sample. A lot of capture device returns mediasample with rtStart = N and rtStop = N+1. > > 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. Hehehe ... this timebase is perfectly known and is 1/10000000 seconds ... but libavformat is misdesigned and refuses to optimize the framerate when it's not expressed directly as 1/fps fraction =). I'm starting to think that libavformat cannot work correctly if the input is not ffmpeg itself : - I got decoding problems with b-frames when playing a remuxed stream with my libavformat muxer ... I think it's related to the packing mechanism being lost during the remux ... =( - I also got serious problems with the codec extradata ... extracting them from directshow mediatypes is a bit paintfull and not always working (I think I may have to actually decode some (I?) frames to get the formatted extradata ready to be muxed). _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
