Hey, I don't know if you realise, but
a) you dont need to mull by 1000 if you are using floats. all the math is done first and then cast. if u want to round up then use ceil. float frameTime = 52.731; int64_t frame = (int64_t)((frameTime * 1000) * frame_rate.den / (1000 * frame_rate.num)); int64_t pts = m_pVideoStream->start_time + (frame * ((frame_rate.num * m_pVideoStream->time_base.den) / (frame_rate.den * m_pVideoStream->time_base.num) )); lets replace with symbols n = t * 1000 * Rd / (1000 * Rn) p = t0 + (n * Rn * Bd) / (Rd * Bn) = t0 + (t * 1000 * Rd * Rn * Bd) / (1000 * Rn * Rd * Bn) uh-oh p = t0 + t Bd / Bn pts = start_time + frameTime * time_base.den / time_base.num; your calc is wrong. to get the milliseconds per frame in my app i do 1000 * ticks_per_frame * AV_TIME_BASE * av_q2d(pCodecCtx->time_base) On Tue, Sep 22, 2009 at 11:53 AM, slippyr4 <[email protected]> wrote: > All, > > I'm sure this has been asked many times before, but nonetheless i > couldn't find an answer to my problem. > > In my app I have a need to calculate the PTS corresponding to the > frame closest to a particular time. For example, I might need to grab > the frame from a video that equates to 52.731 seconds into the stream. > I thought I had this working (I'd previously built against an svn from > about march 2009), but another part of my app have me cause to update > to the latest SVN and this seems to have changed things. > > Basically, I need to understand how the time_base in the stream and > the codec context can be used, along with the stream start_time, to > calculate pts. > > Previously, my logic was roughly like this:- > > Firstly, my MPEG2 source video (which is a nominal 25fps) has a > time_base in codec context of 1/50, but has ticks_per_frame of 2. My > logic up to now has been to combine these two into a single rational:- > > AVRational frame_rate = m_pVideoCodecContext->time_base; > frame_rate.num *= m_pVideoCodecContext->ticks_per_frame; > > then i can use that frame_rate to calculate the frame number:- > > float frameTime = 52.731; > int64_t frame = (int64_t)((frameTime * 1000) * frame_rate.den / (1000 > * frame_rate.num)); > > then, combining frame_rate and the stram time_base to get the pts:- > > int64_t pts = m_pVideoStream->start_time + (frame * ((frame_rate.num > * m_pVideoStream->time_base.den) / (frame_rate.den * > m_pVideoStream->time_base.num))); > > As I said, this previously working fine (at least with all the videos > I tried it with (various MPEG2 and h264 MP4). However, since I updated > to newer ffmpeg something has changed and the logic no longer works. > > My MP4 file under the new version of ffmpeg comes out as having a > codec context timebase of 1001/50000 and ticks per frame of 2. The > stream time_base is 1/3000. Following through the math, the results I > get don't correspond to actual pts that are in the stream. I can see > in the debugger that the PTS for this video increments in steps of > 1200, whereas before it incremented in steps of 1. > > I'm definitely missing a link somewhere. Somehow I need to know what > the increment is in PTS between frames, which for this MP4 seems to be > 1200. There must be some other AVRational value which relates the PTS > time_base with the increment. What is that rational? > > Thanks in advance for any guidance > > Jon > _______________________________________________ > libav-user mailing list > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
