[Libav-user] AVSEEK_FLAG_BYTE resets packet dts

[Burk]

Thanks Alex, I have only tested with AVI/Xvid, but eventually will add MKV/x264. 
I see so ffmpeg is doing the counting internally, but when it seeks by file position it loses the point of reference. 
I guess seeking by index will know the target frame number that's why it works there.
I was hoping that the container or the codec will "waste" 8 bytes to remember the frame number in cases like that :-)
Cheers, Thomas




________________________________
From: Alex Cohn <alexcohn at netvision.net.il>
To: "This list is about using libavcodec, libavformat, libavutil, libavdevice and libavfilter." <libav-user at ffmpeg.org>
Sent: Sunday, November 6, 2011 12:51 AM
Subject: Re: [Libav-user] AVSEEK_FLAG_BYTE resets packet dts


On Nov 6, 2011 1:03 AM, "Burk" <burkheart at yahoo.com> wrote:
>
> Hi, in my video player when I seek by file position using av_seek_frame(..., AVSEEK_FLAG_ANY | AVSEEK_FLAG_BYTE)) then the following packets from av_read_frame have the dts field reset starting from 0 again. That behavior is only observed when using AVSEEK_FLAG_BYTE, which I really need in this case. This is problematic, because I have been using the packet dts field to compute the current time of the frame in the video. 
>
> Any work-around that I can use? Tried display_picture_number, but that is consistently 0. I am out of ideas now.
What kind of video format are you reading? In most cases, the packet number and display time cannot be read from the file or stream,  but only calculated by straightforward counting.
> Thanks in advance, Thomas
Good luck,
Alex
_______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>

_______________________________________________
Libav-user mailing list
Libav-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20111106/d71b0152/attachment.html>