[..] >> After several hours of debug, I found why it act like this. >> >> As I was supposing it, packets fields from `av_read_frame' can depends >> of the state of the codec context. The function `compute_frame_duration' >> is testing `st->codec->time_base'. This value is probably updated when >> decoding frame. > > You have pretty much figured it out. But to help clarify the reasons: > > stream->* and AVPacket->* hold information about the demuxer (which is > invoked when you av_read_frame) > > stream->codec->* and AVFrame->* contain data about the codec (which is > invoked when you avcodec_decode_video) > > There is very little connection between the codec and the demuxer. It is > possible to have a container with PTS values and a codec without them. It > is possible to have container PTS and codec PTS that have both a different > rate and different starting value.
I understand that. I showed that the "little connection" can sometimes produce some unexpected behavior. To make it clear, in my case, AVPacket fields (PTS/DTS), not AVFrame fields, depends of stream->codec because compute_frame_duration rely on stream->codec->time_base as a fallack in some case and this time_base can be updated to a different value when decoding a frame. -- Frédéric Jolliton _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
