Hi.
> If your timestamps are in milliseconds, I guess AV_TIME_BASE_Q is wrong
> (try something like {1, 1000}).
I simply multiplied the result by 1000 and it did the trick.
> If we are talking about the RTP TS (the PTS value that must be set in
> AVPacket before calling av_write_frame()), then 1/90000 is the correct
> time base for almost all the video payloads (for audio, the time base is
> 1/90000 in case of mp2/mp3, or 1/<frame rate> in case of other audio codecs).
Indeed, I set the PTS before writing it to either disk or RTP port.
The number of 90000 is specific to RTP, or it's a generic one? This
could answer me on another issue described below.
> Maybe some frames are lost/corrupt because of the wrong PTS values
> computed above?
Well the problem was with UDP connection - probably some frames were
lost in transit.
Ok, the new issue is that when I wrote the timed frames to disk
(rather then streaming them, as I hoped it would fix the frame rate
issues for recorded files too), I got about 5 seconds of video
recorded as 12 hours. The first picture actually didn't change for the
entire clip. Moreover, VLC reported the frame rate as 0.003055.
Any idea if the RTP timing method is good for recorded files as well?
If not, what are the methods there to deal with changing frame rate?
Thanks again.
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
