On Tue, May 1, 2012 at 2:20 AM, Carl Eugen Hoyos [via libav-users] < [email protected]> wrote:
> jettoblack <jettoblack@...> writes: > > > I tried that and for H.264 it's definitely wrong if I use the frames > > in-order from the demuxer. It does work fine for MPEG-2 video. > > > > Should I file a bug report? > > Is the problem reproducible with ffmpeg -i input -qscale 2 out.avi > or ffplay file ? > Hi Carl, I really appreciate the response. The output file plays/trancodes without any problems using ffplay or ffmpeg. I don't know much about the internals of ffmpeg, but is it possible that the muxing process is reversing the issue? In any case, can you advise on how to determine the frame display index of a AVPacket? I've tried: A) the incremental order from the demuxer B) using the pts value: int frame_num = (pkt.pts * av_q2d(in->streams [videoStream]->time_base)) / (1 / frameRate); C) coded_picture_number (after decoding to AVPicture) When the transport stream contains MPEG-2 video codec, all of these methods work equally well. When it contains H.264 video codec, the pts and incremental order from the demuxer are definitely not in picture display order. coded_picture_number is giving the closest result but it is wrong on approx. every 150th frame (key frames?). Thanks! Jason -- View this message in context: http://libav-users.943685.n4.nabble.com/Frame-order-from-TS-demux-mpeg2video-vs-h264-tp4597204p4602029.html Sent from the libav-users mailing list archive at Nabble.com. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
