[FFmpeg-trac] #6305(undetermined:new): Negative AVIndexEntry::timestamp value
FFmpeg
trac at avcodec.org
Thu Apr 13 12:40:16 EEST 2017
#6305: Negative AVIndexEntry::timestamp value
-------------------------------------+-------------------------------------
Reporter: s0m3 | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: unspecified | undetermined
Keywords: | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 1
-------------------------------------+-------------------------------------
Comment (by s0m3):
It's rather obvious for me but I guess we don't talk about the same thing.
For me, "PTS" is a timestamp that specifies when I should display the
frame on the screen.
Its value is the elapsed time from the beginning of the stream.
I convert it (from stream time unit) to 100ns unit for practical reason.
Suppose we have a stream at 25fps, each frame lasts 40ms = 400000 100ns.
So if I decode the 3 first frames, I should get pts 400000, 800000 and
120000.
When I start playing, I start my clock and I compute the remaining time
before the next frame to display.
I sleep the amount of time I computed and when I wake up, I ask the clock
what the current time is and test it against the next frame time.
If it's in my error margin, I display the frame, otherwise, I drop the
frame and wait for the next frame.
My clock start at 0 100ns and run at realtime if playback rate is 100%.
I know frames are not stored (in the stream) in display order but it
doesn't matter for me since it's decoder role to deliver me in the right
order.
To answer your question, here are the steps to get the sample file
attached to this bug:
{{{
1) create a 640x400 px white picture (I used Gimp) and save it as
white.png
2) D:\>D:\ffmpeg-3.2.4-win32-shared\bin\ffmpeg.exe -loop 1 -i D:\white.png
-t 60 D:\tmp.mp4 -debug_ts 2> logA.log
3) D:\>d:\ffmpeg-3.2.4-win32-shared\bin\ffmpeg.exe -i D:\tmp.mp4
-filter_complex "drawtext=fontfile=C\\:/Windows/Fonts/Tahoma.ttf:
text='frame %{n} %{pict_type} %{pts}': x=100: y=50: fontsize=24"
"D:\sample h264 with timecode.mp4" -debug_ts 2>
D:\logB.log
}}}
The resulting file has the following md5 sum:
a0d782eaa08bc4670baabdc2709d606d.
I compressed logA.log and logB.log into logs.7z and attached it to this
bug.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/6305#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list