View Full Version : frame drop ratio and b-frames?
Mug Funky
22nd October 2003, 12:31
hi all. i'm using the latest Koepi build of Xvid, and noticed that if the frame drop ratio is non-zero and b-frames are on, there's some bad "random motion" going on in b-frames in between dropped p-frames.
i wonder if frame dropping will be further developed?
i'm not worried, i was just doing some random tests to see if i could get better anime compression using that option. seems like it only works when b-frames are off, but then it defeats the purpose of chasing higher compression...
Mug Funky
3rd December 2003, 18:11
*bump*
been playing with the new Xvid 1.0 beta, and i must say it rocks!
the framedrop issue is still there, but the cartoon mode makes up for it :)
bond
29th March 2004, 16:59
i now also played around with frame drop ratio and noticed a behaviour that seems as when not coded vops appear not the previous frame gets displayed again, but some other wrong displaced frame
this leads into something which can be described as choppy or jumpy playback on some parts of the file
like if the frames are numbered from 1-10: 1,2,3,4...
it gets displayed like this: 1,2,4,3,4,5,6,5,7,8...
i also used b-frames (2 without packed bistream), FDR was 90 (with a setting of 15 i didnt get any n-vops)
i tested it with rc3
when i remux this .avi into .mp4 with the 3ivx muxer (which deletes all not coded vops and creates a variable framerate file instead) i dont get this wrongly displayed frames (but choppy playback, which is caused by the high framedrop ration (90) i assume)
edit: some small additions
edit2:
encodes with packed bitstream werent handled correctly with ffdshow and 3ivx (xvid worked fine)
without packed bitstream 3ivx had problems (ffdshow and xvid worked fine
remuxing to mp4 with 3ivx (n-vop compressing enabled) solved some problems
sysKin
30th March 2004, 14:17
Thanks a lot guys, the issue was just resolved.
It was an ugly bug.
Please download newest GaM3R's build and make sure that
1) it's really solved and
2) [important] the whole thing still works
:)
Radek
Mug Funky
31st March 2004, 16:44
thanks syskin...
just tracking down that build now.
Mug Funky
31st March 2004, 17:08
nice. it drops frames normally on encoding.
on decoding it seems that for any 1 dropped frame (determined by looking for black gaps in virtualdub's bitrate graph... not scientific i know) there are 3 frames completely still. i'm using 2 b-frames and stepping frame-by-frame in virtualDubMod.
i've yet to see how directshow handles this, or indeed a 3ivx muxed mp4.
[edit]
hmm... i seem to be getting shits. may be a GMC thing, as it happens at the edges of frame, mostly on zooms. i'll turn off all fancy stuff and try to isolate this.
[edit edit]
turned frame dropping to zero and didn't get them. hmm. all other settings the same. (cq2, no b-frames, qpel, GMC). i'll send ye a clip if need be.
[edit 3]
on second thoughts, i get it without GMC as well... frame drop ratio=30 + qpel, no bframes.
bond
5th April 2004, 14:20
ok just for completeness:
frame drop ratio now (rc4) doesnt work together with b-frames anymore (if b-frames are enabled no frames will get dropped)
it seems to work correctly for me now :)
HalfHuman
8th April 2004, 15:43
deactivate the "packed bitstream" and the dropping frame thingie is solved
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.