[Libav-user] Seeking by byte position in H.264 video

Alex Cohn alexcohn at netvision.net.il
Sun Aug 7 14:01:25 CEST 2011


Note that you can start decoding h264 stream from a keyframe (i-frame).
Therefore a full index for the stream is almost useless. Usually, it's wiser
to store index to key frames.

Alex

PS this can also explain the behavior of ffmpeg for the "tail", if it
doesn't start with i-frame.

BR,
Alex

On Saturday, August 6, 2011, Дмитрий Дороговцев <
dorogovtsev.dmitriy at gmail.com> wrote:
> Hello. I am trying to implement some kind of seeking mechanism in H.264
files
> without any container, just raw H.264 stream. I have some troubles with
it.
>
> 1) Problem #1. I am using ffmpeg to cut let's say 143 frames from video in
this way:
>
> ffmpeg -i source.h264 -vcodec libx264 -b 1200k -r 30 -vframes 143
result.h264
>
> It works without any problems. After that i'm getting all frames in
pictures from obtained file
>
> ffmpeg -i result.h264 -vcodec mjpeg img%03d.jpg
>
> It works also fine, but after this i get set of images with names
img001.jpg - ... - img142.jpg.
> So i have 142 images instead of 143. Where is last( or first ) one?
>
> 2) Problem #2. I am trying to get amount of frames in the video using
> while( av_read_frame( this->pFormatContext, &this->packet ) == 0 )
> amount_of_frames++;
> In this way i get amount_of_frames = 143 for the previous example. But i'm
not sure
> about what should i use to get byte position in the file. Does AVPacket
packet.pos points
> to the proper position in the file, so i can use it for calling
av_seek_frame? Will it properly
> take me to the desired position of frame beginning? I'm curious because if
i call
> avcodec_decode_video2() immediately after av_read_frame, when packet.pos
equals 0
> ( i think, it's start of file ), then 3rd parameter *got_picture_ptr stays
equal to zero meaning
> that no frame could be decompressed.
>
> I need byte positions to create frame index without actual decoding the
whole video. After that
> i should be able to jump through it using av_seek_frame. If it is bad
approach for some reason,
> please give me an advice to the better solution. Thank you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20110807/f8369ce0/attachment.html>


More information about the Libav-user mailing list