Re: mpeg2video slow seeking in Windows apps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]<

 



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 based18 - PAL frame based30 - NTSC filed based36 - PAL field basedIts 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
-- Krzysztof 'DK75' DuchnowskiGetFirefox - http://www.mozilla.com/firefox/Konfiguracja UTF-8 dla czytników - http://evil.pl/pip/utf/_______________________________________________MPlayer-users mailing listMPlayer-users@xxxxxxxxxxxxxxxxx://lists.mplayerhq.hu/mailman/listinfo/mplayer-users


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux