xvid_encraw - Patched with AviSynth input support

[henryho_hk]

No, I can't... It's the same CPU. :devil:

I have installed Celtic Druid's 2007/03/10 XviD compile in the new setup. I would try the last version and see if it's better.

[squid_80]

No, I can't... It's the same CPU. :devil:
You mean it's the same chip overclocked to 3ghz? It might be getting speed throttled due to overheating. Try checking the temps when it's encoding.

[henryho_hk]

It might be getting speed throttled due to overheating.

It's staying at 58~60 C at full load. Even if it's throttling, it's at 6x @ 2.5G, still way faster than 1.86G. That's why i am puzzled.

[squid_80]

Try running avsutil on the script (the newest version that reports the total time taken to play the script) at the new clock speed then drop to a lower clock speed and see if the time taken increases. If the time measurements are the same it's an avisynth problem; if the avsutil times are proportional to cpu clock speed(as they should be) then there's a problem with xvid.

[henryho_hk]

avsutil's clock time seems to be consistent with the bus speed (hence cpu & ram). It looks like a xvid related. I will try to test the encoding speed in Virtualdub tonight.
---------------
I tested avs2avi instead. At the same settings (TG's comp test, #threads=1), avs2avi is about 50% faster than xvid_encraw. That's far more than I would ever expect.
---------------
Seems the "threads=2" parameter of Colormatrix 2.1 is causing slowness in xvid_encraw. After I change it to "threads=1", the xvid_encraw is just a few fps slower than avs2avi.
---------------
An sincere apology to squid_80. After testing long encodes (>1hr movie, Colormatrix threads=1), the encoding speed difference further diminishes to 2~3fps. Yet the Colormatrix speed issue (threads=2) still remains.

[Brother John]

Here’s a strange thing a have been noticing for some time.

Situation: A video encoded with newest xvid_encraw and Matroska output (-mkv parameter). Xvid settings and 1pass/2pass don’t affect the problem.
When I try to play such a video, the player accesses the hard drive for quite a while. It looks like it’s buffering the video. After a while (about 20 secs for a 2 GB movie) it plays and seeks ok. This happens with all DirectShow players, all the common splitters and decoders as well as with VLC.
When I remux the file with MKVMerge (no special settings, simple blocks disabled because I assume encraw doesn’t use them) it plays immediately without the »buffering« effect.

It’s not a huge issue because remuxing is necessary anyway to add audio, but I’m still wondering: could this be a bug in encraw’s MKV handling?

[708145]

It’s not a huge issue because remuxing is necessary anyway to add audio, but I’m still wondering: could this be a bug in encraw’s MKV handling?

I had the same effect with an old version of mkvmerge.
So it might be a setting with the mkv dictionary.

[foxyshadis]

I think the large read comes from an insufficient cue contents. (Similar to the avi index.) mkvmerge has three options, none, key-frames, or all frames, and currently defaults to keyframes; most other muxers will write no cues, because they aren't known ahead of time. Without cues, the splitter will read the whole file to extract keyframes, or seeking would be impossible. (It could read on the first seek, but they don't....)

(That's not entirely true. In 2pass mode encraw has all i-frames known, and the locations can be filled with dummy values to be filled in at the end of the encode. mkvmerge probably works that way. Up to squid or someone else to consider implementing that though.)

Simpleblock can still help for xvid, btw. It's the audio tracks that really get the gain from using it, especially AC3 and DTS.

[squid_80]

It’s not a huge issue because remuxing is necessary anyway to add audio, but I’m still wondering: could this be a bug in encraw’s MKV handling?
It's not really a bug, xvid_encraw just doesn't put cues (used for quick seeking) in files that it outputs. They're still valid mkv files and I never put in the extra effort since as you pointed out remuxing is normally necessary.

[Brother John]

Thx for the explanation. As you said, it's not too important. Maybe some time, if you get really bored... ;)

[henryho_hk]

squid_80, have you tried the 01/04 (hope it's not a joke) GCC Core2 compile for XviD (http://ffdshow.faireal.net/mirror/XviD/gcc/xvidcore.Core2.7z)?

The encoding time and the fps are shown as -1:

25701 frames( 99%) encoded, -1.#J fps, Average Bitrate = 1808kbps
Tot: enctime(ms) = -1.#J, length(bytes) = 193906924
Avg: enctime(ms) = -1.#J, fps = -1.#J, length(bytes) = 7532

[kurt]

Had the same issue and posted on celtic_druids forum (http://celticdruid.no-ip.com/phpBB2/viewtopic.php?p=785#785).

for me the P4 & Prescott builds work fine...

[chipzoller]

I noticed that encoding with xvid_encraw sets the fourcc in the output file as MP4V (I think, anyway). Since I really haven't messed much with xvid_encraw I was just wondering why this isn't setting the fourcc to XVID or something. I wanted to try some experiments on decoding this output file (640x480, 60fps) using ffdshow and divx to see how each affected the playback on this system. I used the >30% comp. check (hq) in megui to encode the file.

[henryho_hk]

Do you mean xvid_encraw's MKV output?

[chipzoller]

Do you mean xvid_encraw's MKV output?
Yes. I just noticed I can force a fourcc when I remux in mkvmerge, so maybe that's just the simplest answer. I was just curious as to why xvid_encraw's MKV output set that fourcc.
EDIT: Evidently if using MKV as the output in encraw, remuxing in mkvmerge won't correct/replace the fourcc. Evidently this has to be done only with avi output.

[Brother John]

Xvid_Encraw creates MKVs with native MPEG-4 video streams. The ID system for those doesn't identify encoders but video formats (MPEG-4 ASP, AVC, MPEG-2, WMV etc). The FourCC is only used for VfW compatibility mode streams, like those created by the Xvid VfW encoder (e.g. through VDub).

Xvid, DivX, 3ivx and some others are all MPEG-4 ASP encoders and are identified accordingly.

[chipzoller]

Then is the only way to test decoders ffdshow and DivX by having xvid_encraw output to AVI then change fourCC when muxing to MKV (or leave alone if already set to XVID)? Because it seems DivX will not decode content if the fourCC is set to MP4V. Disabling the decoding options for both xvid and MPEG-4 generic in ffdshow renders the stream undecodable even with DivX is installed and generic Mpeg-4 playback set in the decoder options.

[henryho_hk]

Is there any way to extract these native MPEG-4 video streams from the MKV file and mux it in an avi?

[squid_80]

Because it seems DivX will not decode content if the fourCC is set to MP4V. Sounds like a DivX issue to me. Go bug them to support generic mpeg-4 asp in their decoder. Or just output to avi instead of mkv and change the fourcc.
Is there any way to extract these native MPEG-4 video streams from the MKV file and mux it in an avi?I think you have to do mkv->native stream->mp4->avi. Not too sure since I haven't done it myself but I think Bond has posted how to do it.
squid_80, have you tried the 01/04 (hope it's not a joke) GCC Core2 compile for XviD ?

The encoding time and the fps are shown as -1:That used to happen with ANY xvidcore build, when I first fixed the negative bitrate/time issues; I had to re-arrange the code to get it to work correctly. Seems like a missing emms instruction or possibly a non-volatile register not being saved, I just need time to look into it.
I thought there was also a post here about disabling N-VOPs thru xvid_encraw, I'm not sure if that's possible but will look into it.

[vanger]

I have strange problem with avs2qxvid...
Preset to use = TGHQ-58

start "TGHQ-58 - Pass 1/2" /b /wait /belownormal "D:\avs2qxvid\bin\xvid_encraw_2
0061213.exe" -zones 0,q,3,KO -threads 2 -progress 100 -max_key_interval 250 -pac
ked -quality 5 -vhqmode 1 -max_bframes 2 -bquant_ratio 162 -bquant_offset 0 -qty
pe 1 -qmatrix "D:\avs2qxvid\matrix\Didees-SixOfNine.cqm" -nochromame -turbo -pas
s1 "D:\avs2qxvid\tmp\zxxxz2.pass" -type 2 -i "D:\avs2qxvid\zxxxz2.avs"

xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 512 x 336, 25.000fps (25/1), starting from frame 0
xvid [info]: Number of frames to encode: 73744
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 3DNOW 3DNOWEXT TSC
xvid [info]: Detected 2 cpus, using 2 threads.
73701 frames( 99%) encoded, 112.14 fps, Average Bitrate = 1367kbps
Tot: enctime(ms) =657434.00, length(bytes) = 503621549
Avg: enctime(ms) = 8.91, fps = 112.17, length(bytes) = 6829
I frames: 556 frames, size = 28837/16033540, quants = 3 / 3.00 / 3
P frames: 26237 frames, size = 11261/295456472, quants = 3 / 3.00 / 3
B frames: 46951 frames, size = 4092/192131537, quants = 4 / 4.00 / 4

start "TGHQ-58 - Pass 2/2" /b /wait /belownormal "D:\avs2qxvid\bin\xvid_encraw_2
0061213.exe" -zones 0,w,1.0,KO -threads 2 -progress 100 -max_key_interval 250 -p
acked -quality 6 -vhqmode 4 -qpel -max_bframes 2 -bquant_ratio 162 -bquant_offse
t 0 -qtype 1 -qmatrix "D:\avs2qxvid\matrix\Didees-SixOfNine.cqm" -imin 3 -imax 4
-pmin 3 -pmax 5 -bmin 3 -bmax 5 -chigh 10 -clow 3 -bvhq -bitrate 1000 -pass2 "D
:\avs2qxvid\tmp\zxxxz2.pass" -stats "D:\avs2qxvid\tmp\zxxxz2.stats" -type 2 -i "
D:\avs2qxvid\zxxxz2.avs" -avi "D:\avs2qxvid\zxxxz2_TGHQ-58_br_1000.avi"

xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


xvid [info]: outputting statistics to D:\avs2qxvid\tmp\zxxxz2.stats
Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 512 x 336, 25.000fps (25/1), starting from frame 0
xvid [info]: Number of frames to encode: 73744, Bitrate = 1000kbps
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 3DNOW 3DNOWEXT TSC
xvid [info]: Detected 2 cpus, using 2 threads.
73701 frames( 99%) encoded, 35.35 fps, Average Bitrate = 1000kbps
Tot: enctime(ms) =2085700.00, length(bytes) = 368580465
Avg: enctime(ms) = 28.28, fps = 35.36, length(bytes) = 4997, psnr y = 42.92
, psnr u = 49.28, psnr v = 50.30
I frames: 556 frames, size = 25511/14184197, quants = 3 / 3.64 / 4
P frames: 26237 frames, size = 8172/214430966, quants = 3 / 3.81 / 5
B frames: 46951 frames, size = 2981/139965302, quants = 4 / 4.79 / 7

All completed..............

16.04.2007 0:46:20,03 - Checking Source
16.04.2007 0:46:24,01 - Loading Preset
16.04.2007 0:46:24,12 - Encoding Video
16.04.2007 0:46:24,12 - Encoding Pass 1
start "TGHQ-58 - Pass 1/2" /b /wait /belownormal "D:\avs2qxvid\bin\xvid_encraw_20061213.exe" -zones 0,q,3,KO -threads 2 -progress 100 -max_key_interval 250 -packed -quality 5 -vhqmode 1 -max_bframes 2 -bquant_ratio 162 -bquant_offset 0 -qtype 1 -qmatrix "D:\avs2qxvid\matrix\Didees-SixOfNine.cqm" -nochromame -turbo -pass1 "D:\avs2qxvid\tmp\zxxxz2.pass" -type 2 -i "D:\avs2qxvid\zxxxz2.avs"
16.04.2007 2:37:16,64 - Encoding Pass 2
start "TGHQ-58 - Pass 2/2" /b /wait /belownormal "D:\avs2qxvid\bin\xvid_encraw_20061213.exe" -zones 0,w,1.0,KO -threads 2 -progress 100 -max_key_interval 250 -packed -quality 6 -vhqmode 4 -qpel -max_bframes 2 -bquant_ratio 162 -bquant_offset 0 -qtype 1 -qmatrix "D:\avs2qxvid\matrix\Didees-SixOfNine.cqm" -imin 3 -imax 4 -pmin 3 -pmax 5 -bmin 3 -bmax 5 -chigh 10 -clow 3 -bvhq -bitrate 1000 -pass2 "D:\avs2qxvid\tmp\zxxxz2.pass" -stats "D:\avs2qxvid\tmp\zxxxz2.stats" -type 2 -i "D:\avs2qxvid\zxxxz2.avs" -avi "D:\avs2qxvid\zxxxz2_TGHQ-58_br_1000.avi"
16.04.2007 4:51:54,85 - All Completed
The real fps for 1st pass is ~11fps, for 2nd - ~9fps.

the avs script is:
DGDecode_mpeg2source("D:\capture\video\wsa.d2v",info=3).trim(0,73743)
ColorMatrix(hints=true)

crop(14,36,702,504)

FFT3DFilter(sigma=2,plane=4)

LanczosResize(512,336)

I think on my config (AMD X2 3800+ (2500Mhz)) it is too slow...
I have the same fps with the same avs-script on 2nd pass with x264 (HQ-Insane)...

Any ideas?

[henryho_hk]

Older versions of xvid_encraw show its own xvid encoding time and exclude the AVS processing efforts. Try the newest avs2qxvid package with xvid_encraw_20070203.exe. squid_80 has revised the fps calculation method to show the overall encoding speed.

---------------

Added: "-qpel" and especially "-vhqmode 4" are quite slow. For ">58%" and ">90%" presets, you may try the FAST version and see if you can tell the difference.

[vanger]

and how about speed of encoding?

[squid_80]

The encoding speed is fine - the raw encoding speed is 112 fps and 35 fps as reported by xvid_encraw. The filtering (fft3dfilter) is what is slowing it down so much.

[Revgen]

I currently cannot encode anything over 10000kbps with Xvid Encraw. I tried the latest version and the latest Xvid core form CD (March 10th version) and no luck. The VFW version works fine above 10000kbps, so I can't see why it would be xvid itself.

[henryho_hk]

This is a "feature" of xvid_encraw. Any -bitrate over 10000 is considered bps (but not kbps). If you wanna specify >=10000kbps, specify *1024, e.g. -bitrate 10240000

[Revgen]

Thanks. That's one step in the right direction.

Now I have another problem. The encode is still undersized. My VFW encode is perfectly encoded at 17000kbps while the encraw one is about 14800kbps. Is their a reason why this is happening?

Here's my .bat file.

E:
cd\MeGUIUpdated\tools\xvid_encraw
xvid_encraw -i G:\kong.avs -type 2 -w 1920 -h 832 -quality 6 -max_bframes 2 -framerate 23.976 -bitrate 17408000 -pass1 -max_key_interval 240 -qtype 1 -qpel -vhqmode 4 -bvhq -par 1 -noclosed_gop -nopacked -turbo -threads 2 -mkv G:\kongx.mkv
xvid_encraw -i G:\kong.avs -type 2 -w 1920 -h 832 -quality 6 -max_bframes 2 -framerate 23.976 -bitrate 17408000 -pass2 -max_key_interval 240 -qtype 1 -qpel -vhqmode 4 -bvhq -par 1 -noclosed_gop -nopacked -threads 2 -mkv G:\kongx.mkv

Thanks.

[Brother John]

Saturation maybe?
Xvid VfW uses min quant 1 to waste more bitrate in that case while Xvid_Encraw uses min quant 2 and produces a smaller file.

If you want to mimic VfW's behaviour add this to your 2nd pass cmdln:
-imin 1 -pmin 1 -bmin 1
Lowering VHQ or b-frame quantization or using a more detailled matrix makes a lot more sense, though.

[Revgen]

Thanks, that did the trick. I'll fiddle with the VHQ, B-frame quants, and the matices later and see what happens.

[Daemon404]

Hurm, here's a version witht he latest cvs code (May 25th) with matroska support:

http://www.highdeffguild.com/daemon404/enc_builds/xvid_encraw-cvs-may-25.7z

And, since apparently people are having a hard time finding the missing matroska.cpp and matroska.h files (no idea why they aren't in cvs), here:

http://www.highdeffguild.com/daemon404/enc_builds/xvid_matroska.7z

[celtic_druid]

When was it last updated in the CVS though?

[squid_80]

And, since apparently people are having a hard time finding the missing matroska.cpp and matroska.h files (no idea why they aren't in cvs), here:
I can provide an answer for that: I wrote them and they're a horrible mess of kludges and hacks so they weren't absorbed into xvid's CVS. Really the matroska handling should be completely rewritten from scratch but since they work as is I can't really can't be bothered.

[Daemon404]

When was it last updated in the CVS though?

April 28th, iirc. However, I really dont see any recent builds with matroska support.

I can provide an answer for that: I wrote them and they're a horrible mess of kludges and hacks so they weren't absorbed into xvid's CVS. Really the matroska handling should be completely rewritten from scratch but since they work as is I can't really can't be bothered.

I figured it was something like that. :P

[celtic_druid]

http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/examples/xvid_encraw.c?view=log
Not updated since Jan. My point was that builds with Xvid dynamically linked just need a new xvidcore.dll unless encraw itself is updated.

[Daemon404]

Hmm yea, dynamically linking would probably be a smarter idea.

And by Apr 28, i meant that's when xvidcore was last updated.

[Brother John]

I just stumbled one more time over the bit/kbit issue with the -bitrate switch. What about changing the help text to clarify this?
-bitrate [integer] : target bitrate (700)
values <= 10000 are treated as kbit/s
values > 10000 are treated as bit/s

[Selur]

btw. if current encraw supports -alt2pass would be nice to mention it in the 'help'

[squid_80]

This is what my build does:
Rate control options:
-framerate float : target framerate (25.0)
-bitrate [integer] : target bitrate in kbps (700)
-size integer : target size in kilobytes
-single : single pass mode (default)
-cq float : single pass constant quantizer
-pass1 [filename] : twopass mode (first pass)
-full1pass : perform full first pass
-pass2 [filename] : twopass mode (2nd pass)
-altpass2 [filename] : twopass mode (2nd pass alt)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-zones : see xvid_encraw -help zones
-max_key_interval integer : maximum keyframe interval (300)
I agree -bitrate could do with some clarification, but don't see the problem with -altpass2 not being mentioned?

[squid_80]

A new build is available: http://members.optusnet.com.au/squid_80/xvid_encraw.zip

See if you can spot the new feature (hint: you need a multi-core machine).

[Sharktooth]

eh:) i didnt get it yet, but if what you're talking about it's an automatic threading feature (without the need of a commandline switch), i will kiss your.... :D

[squid_80]

Old build:
>xvid_encraw -i test.avs -progress -frames 1000
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [warn]: Single pass defaulting to quant 4.00
xvid [info]: Input is 528 x 576, 25.000fps (25/1), starting from frame 0
xvid [info]: Number of frames to encode: 1000
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected cpus = 4, threads requested = 4, threads in use = 4
1001 frames(100%) encoded, 38.50 fps, Average Bitrate = 1340kbps
Tot: enctime(ms) =26000.00, length(bytes) = 6709775
Avg: enctime(ms) = 25.95, fps = 38.54, length(bytes) = 6696
I frames: 15 frames, size = 19720/ 295814, quants = 4 / 4.00 / 4
P frames: 427 frames, size = 11520/ 4919399, quants = 4 / 4.00 / 4
B frames: 558 frames, size = 2678/ 1494562, quants = 7 / 7.00 / 7
new build:
>xvid_encraw -i test.avs -progress -frames 1000
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [warn]: Single pass defaulting to quant 4.00
xvid [info]: Input is 528 x 576, 25.000fps (25/1), starting from frame 0
xvid [info]: Number of frames to encode: 1000
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected cpus = 4, threads requested = 3, threads in use = 3
xvid [info]: Threaded input reading active
1001 frames(100%) encoded, 57.66 fps, Average Bitrate = 1340kbps
Tot: enctime(ms) =17359.00, length(bytes) = 6709776
Avg: enctime(ms) = 17.32, fps = 57.72, length(bytes) = 6696
I frames: 15 frames, size = 19720/ 295814, quants = 4 / 4.00 / 4
P frames: 427 frames, size = 11520/ 4919399, quants = 4 / 4.00 / 4
B frames: 558 frames, size = 2678/ 1494563, quants = 7 / 7.00 / 7

[Sharktooth]

ok, i suppose i have to do it then...:D
in the meanwhile it got its way into megui auto-update...

[DarkZell666]

Pretty neat :D

But something else changed too :
B frames: 558 frames, size = 2678/ 1494562, quants = 7 / 7.00 / 7
becomes
B frames: 558 frames, size = 2678/ 1494563, quants = 7 / 7.00 / 7

I don't give a damn for 1 byte honestly, but I'm curious :p Is there any part of the code that's undeterministic ? Or is it a side effect of your new feature ?

[squid_80]

Look closer and you'll see why - using threaded input reduces the number of threads used for encoding by 1. Different number of threads = slightly different output.

[kypec]

@squid_80
Just curious, how did you achieve that performance boost?
I thought that xvid_encraw is just an interface to xvidcore.dll, isn't it?
Thus the encoding performance should be entirely (well, from 99% in our real PC world then) dependent ONLY on Xvid encoder engine installed, or not?

[Brother John]

You're right when you speak about pure enocder perfomance without any overheads, decoding, filtering etc. And multiple encoding threads is a feature of xvidcore.dll.

[squid_80]

xvidcore handles the encoding, but xvid_encraw is responsible for feeding it frames to encode. If those frames are coming from an avisynth script with lots of filtering they can take a while to be retrieved. Each time a frame is fed to the encoder encraw fires off a new thread to fetch the next source frame. Thus when the encoder is ready to encode another frame, the source frame is already waiting in a buffer ready to go.

[kypec]

Yeah, I see now where the performance boost comes from :)
Thanks for explanations squid_80 & Brother John

[plugh]

Is altpass2 working 'ok' for people in the multi-threading environment? There was a bit of code I added in there I was concerned about - ie coordination of variable 'vbvfill_before' in routines rc_2pass2_before and rc_2pass2_after.

Things were confusing enough with the b-frame re-ordering, I wasn't sure what would happen with multiple threads and don't have a multi-core machine to test with...

And for that matter, there was another code segment in rc_2pass2_before that didn't look quite right to me with frame reordering, let alone multiple threads - the |last_quant- new_quant| <= 2 bit - but I assumed the original author(s) knew what they were doing...

[squid_80]

Is altpass2 working 'ok' for people in the multi-threading environment? There was a bit of code I added in there I was concerned about - ie coordination of variable 'vbvfill_before' in routines rc_2pass2_before and rc_2pass2_after.

Things were confusing enough with the b-frame re-ordering, I wasn't sure what would happen with multiple threads and don't have a multi-core machine to test with...

I'm pretty sure it's fine, frames are encoded one at a time and the plugin before and after functions are always executed in order.

[plugh]

Thanks for the reply; I've been somewhat following the recent 'multi-threaded xvid' posts, and now understand that the threads are used _within_ a frame's encode, so that doesn't affect the plugins.

However, at least with the 1.1.2 core, what debug prints revealed to me was that while 'after' is called in presentation order (ie IBBP), 'before' is not.