[MPlayer-users] mpeg2video slow seeking in Windows apps

[Jesse L. Zamora]

On Monday 30 March 2009 01:07:04 pm Krzysztof Duchnowski wrote:
> Jesse L. Zamora pisze:
> >>> mencoder tv://3 -tv chanlist=us-bcast:norm=NTSC:buffersize=20 -of mpeg
> >>> -oac  lavc -ovc lavc -lavcopts
> >>> acodec=mp2:vcodec=mpeg2video:vbitrate=4100 -o  ~/Record.mpg
> >>>
> >>> When playing the video, it's not freezy or anything, but seeking to a
> >>> different time in the video takes several seconds to load.
> >>
> >> The default keyint is rather large...
> >
> > Hmm.....setting keyint to 0 seems to make it play like a normal mpeg2 in
> > Windows Media Player & VLC, even though at first, there were tons of
> > errors or something until I set -mpegopts muxrate=20000! So, it seems to
> > work fine now, but I'd like to know, what is the keyint parameter anyway?
>
> Frames in MPEG based videos are encoded as [I], [P] and [B].
> [I] frames are full encoded frames so they're rather large and needs
> alot of bitrate to encode wihtout visible "garbage".
> [P] frames are encoded as delta ( difference ) from previous frame and
> as such are smaller and needs less bitrate to encode - encoders save
> much file size on that.
> [B] frames are bi-directional encoded frames ( delta from previous and
> next frame ) thus are smallest and saves most bitrate in stream.
>
> Every stream must start with [I] frame since it have full information
> about frame - it's a base; then it follows feew [P] frames  or mixture
> [P] and [B] frames, then [I], then feew [P] or [P]-[B] mixtures and [I]
> and so on. Such pack is caled GOP - GroupOfPictures; and it stores time
> code and bit errors beside RAW data.
>
> So when you seek player cant seek to any other frame than [I] because it
> cannot decode any other frame without surounded data. Unless it have
> code to use "index" to find nearest [I] frame and decode some data that
> will be used as reference to actually seeked frame. So, if you have
> "-keyint=250" that means that encoder is allowed to insert this [I]
> frames as far as 250 frames from each other ( it could insert it earlier
> - it depends on video compexity ) and if you seek to frame other than
> [I] and its possition is far away from previous [I] frame then player
> needs some time to decode from there to serve you your seek frame.
>
> MPEG2 DVD compilant stream must have GOP set to one of these value:
> 15 - NTSC frame based
> 18 - PAL frame based
> 30 - NTSC filed based
> 36 - PAL field based
> Its fixed sequence of [I], [P] and [B] frames.
>
> As you don't do DVD stream you don't need to use fixed GOP's but if you
> don't set "-keyint" to any value it will be used with "250" value (
> default for MPEG4 type video but not for MPEG2 - sane maximum is 300 for
> MPEG4 so I don't think 250 is good ) and that means that if you unlucky
> and you seek to frame 249 and one and only previous [I] frame is frame
> "1" then player must decode every 248 frame in beetwen but as it don't
> draw it on screen then it don't need to decode it in sysnc then it will
> go little faster but decoding 5s could last 1s before you will see your
> seeked position. ( uff )
>
> That's why seeking with some large "-keyint" value could be slow.
>
> So it is a sane value to set "-keyint" to your video FPS value or twice
> as much - no more.
>
> keyint = maximum keyframe interval
> "keyint=0" means "keyint=1" means every frame is [I] frame so video will
> be laaaarge without any possitve effect from it.
>
>
> PS: It's my understanding of things - any one please correct it

Wow, that made perfect sense! Thanks for explaining it. I've tried different 
keyint values here, and a keyint of 0 seems to work the the fastest (of 
course). I suppose there's nothing wrong with using 0, right? With lower 
keyint values, it seems as though the filesize increases, but filesize is not 
an issue here (since I burn of captured videos to DVD anyway!).

Thanks again,
Jesse L. Zamora