>Great thanks again. So what I'm getting from this is that the pts/dts is in >absolute time, and require no offseting (just time_base conversion if they >are in different time bases). Looking at the ffplay.c code more (I didn't >understand what reordered_opaque was for, now I do, thanks). >This brings up another question though. The pts is almost never used, it >uses the dts of the decoded packet as the pts (since decoder_reorder_pts is >0 by default, and I've never seen a format where the packes have a dts == >AV_NOPTS_VALUE, although I'm sure it exists).
It requires offsetting of some sort. Look at where the input context is opened in ffmpeg. You'll see that it seeks back the start offset from the first frame. Dts can be 0 when you add a number of "still bitmaps" to a stream to be encoded. > (code from ffplay.c) >is->video_st->codec->reordered_opaque= pkt->pts; >len1 = avcodec_decode_video2(is->video_st->codec, > frame, &got_picture, > pkt); > >if((decoder_reorder_pts || pkt->dts == AV_NOPTS_VALUE) && >frame->reordered_opaque != AV_NOPTS_VALUE) > pts= frame->reordered_opaque; >else if(pkt->dts != AV_NOPTS_VALUE) > pts= pkt->dts; >else > pts= 0; As far as I understand it, it's a work around for some things not working correctly in some decoders. You should actually also look at the coded_frame member in the codec, since in theory if frame re-ordening happens, that should point to the correct frame (and thus pts). That's only valid for video, audio has code for it in ffplay and ffmpeg, but codec_frame isn't used if you look in the decoders for audio. >I guess I should just take this at face value and copy what it's doing, but >I'd love to undestand why not just use the reordered_opaque in all cases? Not all decoders set it afaik Your asking questions out of my league now, someone like Stefano might be able to answer better. erik _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
