About Me

Michael Zucchi

 B.E. (Comp. Sys. Eng.)

  also known as Zed
  to his mates & enemies!

notzed at gmail >
fosstodon.org/@notzed >


android (44)
beagle (63)
biographical (104)
blogz (9)
business (1)
code (77)
compilerz (1)
cooking (31)
dez (7)
dusk (31)
esp32 (4)
extensionz (1)
ffts (3)
forth (3)
free software (4)
games (32)
gloat (2)
globalisation (1)
gnu (4)
graphics (16)
gsoc (4)
hacking (459)
haiku (2)
horticulture (10)
house (23)
hsa (6)
humour (7)
imagez (28)
java (231)
java ee (3)
javafx (49)
jjmpeg (81)
junk (3)
kobo (15)
libeze (7)
linux (5)
mediaz (27)
ml (15)
nativez (10)
opencl (120)
os (17)
panamaz (5)
parallella (97)
pdfz (8)
philosophy (26)
picfx (2)
players (1)
playerz (2)
politics (7)
ps3 (12)
puppybits (17)
rants (137)
readerz (8)
rez (1)
socles (36)
termz (3)
videoz (6)
vulkan (3)
wanki (3)
workshop (3)
zcl (4)
zedzone (26)
Saturday, 19 October 2019, 22:59

Frame Accurate Seeking in H.264 streams with libavformat, FFmpeg

I had the need for accurate seeking in H.264 streams using jjmpeg (FFmpeg/libavformat) and spent some time over the last few days trying to work it out. JJMediaReader has a seek that works quite well but I knew it wasn't correct as it was offsetting the read timestamp by the stream start - I can't exactly remember why I did this but I think its because it didn't work very well otherwise.

Anyway ... I finally found out why. Depending on the container, when seeking it will go to the next or equal keyframe rather than the previous or equal. Sigh. So that offset I was using just happened to be enough to work most of the time and as it reported the same start-relative time it appeared to work properly.

So I changed the seek code to use a reverse offset for the seek point, and then it will run forward to get to the correct frame. This is based on the framerate rather than a fixed time offset because some of the video I have uses low framerates. This works but can be a bit slow as it might seek back too far.

To reduce some of the redundant work I thought of using the packet byte position to read the exact packet of the closest previous keyframe. Unfortunately it seems the container formats i'm using don't support AVSEEK_FLAG_BYTE so that idea went nowhere. Fuck.

The best solution so far has been to implement a two-value seek function. The first argument is the keyframe timestamp and the second argument is the desired frame timestamp. Thus it seeks to the keyframe first and then advances by single frames until the desired frame is decoded. Short forward seeks bypass the seek step This requires an external index but the application in question needed it anyway as it requires a wall-clock-time to frame-time mapping as well.


Tagged hacking, jjmpeg.
Fuck Adelaide, Fuck South Australia | Spring
Copyright (C) 2019 Michael Zucchi, All Rights Reserved. Powered by gcc & me!