[Libav-user] Seeking by byte position in H.264 video
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.
PS this can also explain the behavior of ffmpeg for the "tail", if it
doesn't start with i-frame.
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
> without any container, just raw H.264 stream. I have some troubles with
> 1) Problem #1. I am using ffmpeg to cut let's say 143 frames from video in
> ffmpeg -i source.h264 -vcodec libx264 -b 1200k -r 30 -vframes 143
> 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 )
> In this way i get amount_of_frames = 143 for the previous example. But i'm
> about what should i use to get byte position in the file. Does AVPacket
> 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
> avcodec_decode_video2() immediately after av_read_frame, when packet.pos
> ( 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...
More information about the Libav-user