Hi, > Luca Abeni schrieb: > > I am not sure why you are reordering frames... Are you using libavformat > both for reading and writing frames? If yes, there should be no > problems, and you should be able to use the input PTS and DTS for the > output.
Yes, I'm using libavformat for both reading and writing frames. Therefore my thought was too, that no reordering has to be performed. And now I know that's really not necessary because av_interleaved_write_frame works perfectly if the correct dts values are actually passed to it. I simply didn't pass them before and let libavformat calculate them for me. This works fine, if passed pts values are in presentation order and aligned perfectly (a constraint which the video stream I used didn't fulfill). > In the original email, you wrote that you got the "error, non monotone > timestamps" error. But the "monotone timestamps" check is performed on > the DTS (not on the PTS), and the DTSs you reported in your email are > monotonically increasing... That's correct. The check is performed on the current stream and given packet dts values. As a result of the input stream pts' mess the calculated dts from libavformat where doubled sometimes. > The problem you are seeing seems to be that the mpegts demuxer seems to > sometime return the same DTS for 2 consecutive frames. I do not think > this is due to B frames (I've seen even with files that do not contain > any B frame); it looks more like a bug in the TS demuxer. I still don't have a clue what happened exactly but I guess it could be the outcome of two slices in PAFF coded h264 material. These slices have to be presented together and must be decoded in advance. Probably the demuxer has a problem with that? But that's just a guess... Regards, Andre _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
