On Mon, Mar 10, 2008 at 12:16:12AM +0100, Xawotihs wrote: > 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 ?
AVPacket duration/pts/dts are specified in AVStream.time_base AVStream.time_base is set by the muxer, our avi muxer chooses AVCodecContext.time_base for video streams. I thought you were interrested just in avi-directshow, so i didnt mention this explicitly. The timebase choosen by the muxer depends upon what the container supports mpeg-ps/ts for example requires 1/90000. The muxer will not rescale your timestamps (this would be inprecise). [...] > > > 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. The values you store in the example above are invalid there is no point of view about this. They are as invalid as 0=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 =). You have absolutely no faint clue about what you are talking. Libavformat stores what you tell it to store. You ask it to store a timebase of 1/10000000, it does that (this is fine with most containers but not avi). You cant figure out the minimum timebase in which all frames can be specified without looking at all timestamps. libavformat exists in the same universe and is bound by the same mathematical laws, it can also not find the minimum timebase without knowing all timestamps. And the timebase is needed before storing frames in avi. Fundamental issue with avi+directshow, libavformat is not involved here. If directshow really doesnt provide any minimum timebase then i would suspect that it has intentionally been designed so that it is difficult to store non constant fps material in avi (MS pushing ASF like they did when they added explicit checks in msmpeg4v3 to prevent its storeage in avi) libavformat allows non constant fps in avi but this needs a reasonable timebase or you end with insane overhead. > > 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). We cant help you unless you provide complete information about what you are doing and what is not working. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
_______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
