View Full Version : B-frames cut off end frames?
skyd
12th September 2003, 22:39
I apologize if this is a known issue but I couldn't find anything in my searches.
Whenever I encode using B-frames, the last few frames always get cut off the same amount as the max b-frames I set it to. So if I have it at 2 max b-frames, the last 2 frames are always missing in the final encode or if I set it at 1, the last frame is gone. (This is not counting the first dummy b-frame) The length of the avi is also reduced by the amount of those frames that are missing. I checked them through MPC 6.4.6.3, mplayer2, and vdub/mod. If I turn off b-frames, they are there like they should be. DivX 5.x also works fine when I use b-frames. I've tested it on several different clips both directly and with avisynth scripts as well.
I tried Koepi 24062003-1 and umaniac 17.07.2003 builds with the same results using vdmod 1.5.4.1, regular vdub 1.5.4 and even premiere 6.5.
These are the settings (2pass/CBR/CQ all have the same problem): MSP 6, h.263, VHQ4, Max I-frame 240, B-frame 2/150/75/0, Chroma motion and chroma optimizer and DX50 VOP compatibility.
On WinXP SP1 and dx9.0b. Using XviD or DX50 fourcc is the same.
Any ideas what's going on and is there a fix? (or will be done in devapi4 maybe?)
Thanks
sysKin
13th September 2003, 14:23
It's a decoding problem, not encoding. The last frame of an AVI contains all the frames that were buffered during encoding process.
What are you decoding it with? VirtualDub, as every other VfW-based program, will never get a chance to display these frames.
Directshow filters, however, should have no problems. I believe ffdshow just displays them. Other XviD-compatible decoders, like DivX and 3vix, also should.
Radek
skyd
13th September 2003, 21:01
I've tried it in MPC 6.4.6.3, mplayer2 (the old microsoft player 6.4), WMP9, PowerDVD 5.0 and Premiere 6.5. I believe all of these are DS Players.
I currently have Nic's decoder (16.07.03) installed for XviD. I also tried it with a DX50 fourcc to use the DivX 5.1 and 5.05 decoder and the same thing happens.
If it was just a decoding problem, shouldn't the length of the video at least remain the same rather than being reduced by the amount of b-frames I put in? Both the # of frames and the time of the video are reduced. I had made a clip where the last few frames were all scene changes so that I could tell where it got cut off and the more b-frames I put in, the more end frames that are missing on playback.
I actually didn't notice these things going on until I was checking out vqStudio, which requires the reference video and comparison video to have the same number of frames, and the XviD b-frame encoded ones had fewer frames.
KpeX
13th September 2003, 23:41
Let me guess...you were comparing an xvid avi to a mpeg2 source (through a Dvd2Avi project file). There are two issues here, decoding the b-frame avi (not done correctly, this is a known vfw issue and fixed with trim) and dvd2avi trimming frames, an issue which is currently in development. Just trim until you get the videos to match up. Doubt you notice the last two frames anyways.
skyd
14th September 2003, 03:30
Nah, I was testing it on my own captures/videos, not DVD rips. So they are usually in huffyuv/mjpeg or frameserved from premiere.
I posted because even though its only 1-4 frames, I'd at least expect what goes in should be what comes out, otherwise theres no purpose to making frame accurate cuts. Who knows, maybe someone wants to join clips in the future or reencode it or something but everything is thrown for a loop because of this? (since the audio portion will also probably cause things to desync)
I don't care so much about the comparisons because I don't trust pure numbers/psy-modeling and I do everything by eye but if there's really a bug here, the cause of it should be found.
I mostly encode SVCD/DVD stuff but recently decided to see how things have progressed on the XviD/DivX/etc front.
gizmotech
18th September 2003, 00:50
Well now this is kinda interesting to me.
Are the frames actually still present in the file, or are they actually missing? You mentioned the "issue" is only visible in vdubmod, but shouldn't be an issue in a DS application.
So is frame accurate cutting / joinning possible? This is of particular interest to me as I've recently started a project which involves frame acurate cutting and rejoining. If the frames are still there, my joinning application will join everything correctly, however if they are missing from the finished file...
GizmoTech.
sysKin
18th September 2003, 12:36
Originally posted by gizmotech
Are the frames actually still present in the file, or are they actually missing?
They are in the file, but the last frames are packed together in one AVI frame - which prevents most decoders from seeing them. In particular, VfW based decoders have absolutely no way of displaying them.
You mentioned the "issue" is only visible in vdubmod, but shouldn't be an issue in a DS application.Good DS application. Unfortunatly, XviD's DS filter is pretty poor (even thought Nic is doing great job) and it's not able to display them.
Ffdshow should have no problems, but I admit I haven't checked this.
Anyway, this is exactly the reason why Matroska team is pushing forward some weird "native" streams - to work around all the limitations. Mp4 files should also have no problems - but everything AVI-related, which unfortunately also includes ogm and current matroska streams - has limitations.
Radek
skyd
20th September 2003, 20:30
Ah, I thought you meant the problems were only in the player (of which I tried a couple more with no success), but not the actual decoder filters themselves. FWIW, I also tried ffdshow alpha 20030523 and the last frames are still not showing.
Pardon my ignorance, but what is the reason for packing in the last couple of frames into one AVI frame? It just seems more logical (to me) and easier that you'd at least use the same number of AVI frames as the source before putting everything remaining into the last frame.
sysKin
21st September 2003, 13:30
Originally posted by skyd
Pardon my ignorance, but what is the reason for packing in the last couple of frames into one AVI frame? It just seems more logical (to me) and easier that you'd at least use the same number of AVI frames as the source before putting everything remaining into the last frame. The resulting AVI has the same number of frames as source - it must be so even if we didn't want that, because that's part of VfW limitations.
However, it isn't the case when you're using VirtualDub(Mod) for encoding. This is because VD understands the initial "delay" frames created by DivX5 and XviD codecs and does not insert them into the AVI. Other programs will probably still put them (they are single-byte 0x7f frames) and the AVI will have the same number of frames.
By not inserting the 0x7f frames to AVI, delay between the frame displayed and the frame decoded is reduced to 1 frame (instead of 1+number of b-frames).
Radek
mfluder
21st November 2003, 17:52
Sorry for bringing this up again but I find this missing frames thing interesting.
I haven't experienced this end frames cut off probably because I'm using avs2avi for all my encodings and VDubMod only for editing. avs2avi encoded file has the same number of frames as the source and is well aware of how b-frames work and also has that maximum-1-frame-delay-no-matter-how-much-bframes-you-set. Although I have been using avs2avi for a long time I occasionally use VDubMod (and was using it before avs2avi came along) for encoding and I don't remember this missing frames thing. So I tried encoding with VDubMod 1.5.1.1a and guess what, all frames were there which was not the case with the latest version. Playing back avi encoded with latest version of VDubMod doesn't show the last frame but when playing back avs2avi and older VDubMod encoded avi you can clearly see last frame.
So, the question is: Considering all the facts that I have given above, don't you think that this is rather a bug in latest VDubMod than a way it is supposed to be?
mfluder
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.