But this one most certainly is. Under California law, hit and run involving injury could be charged as a felony.
Monthly Archive for July, 2008
I’m somewhere out on track during this session. It’s hard to tell if I’m in one of the cars visible in the distance.
Same driver, same track, same car (different rear diff) from November 2007.
Official Site
- pdf map at official site
cobwebby page at NA Tracks — features a topo map
(more to come)
I ran Buttonwillow with the San Diego Chapter of the BMW CCA. A few observations:
- The car is very quick. I started the weekend very slow, worked on smoothing out my inputs, worked on getting re-familiarized with the track, and gradually built speed. By Sunday afternoon I was putting together some very nice laps. There are some fast portions of the track that the car certainly can take much faster. I’m not there yet, but with enough seat time …
- The car is very balanced. With the current suspension set-up, the car never felt out of sorts. I got a little greedy cresting the rise at Cotton Corners, and got a touch of power oversteer, but with some feathering, it came right back. I took a variety of lines through the Offramp, and couldn’t find one that the car didn’t like. I experimented with different lines through Talladega, including some passes on the inside, and it was all good.
- Racing starts are very cool. One of the run groups was a BMW CCA Club Racing group. While watching the start of the first race on Saturday, I felt that old, familiar adrenaline rush. I’ve decided to upgrade my August school at Thunderhill to the club racing school group.
A few nights ago, I looked a long and hard to find a vendor with a thread file in stock, and the ability to ship quickly. Indeed, I got the shipment quickly — with the thread file shown as backordered. Nice. But I did get the metric and anti-metric thread gauges.
The thread files were plan B anyway. Plan A was to replace the rod end with the damaged thread. Since I wasn’t sure if the rod end was left hand thread or right hand thread, I ordered one of each. The package shipped and arrived a day later than promised, but arrived yesterday with a total of four rod ends — two left and two right. But the left hand threads rod ends came without a stud pressed into the ball joint, which made them useless.
But I still had a fifty percent shot.
Upon closer examination, the bad rod end has a left hand thread. Bummer … or words to that effect.
However, having my trusty thread gauges, I could tell definitively that the damaged stud has 24 threads per anti-metric unit of distance. It’s just not right to have a 3/8″ x 24 threads-per-inch fastener installed on a German car, but that’s what it is. Prior the having the thread gauges I wasn’t sure if I was dealing with metric fastener sized at 10mm x 1 or an anti-metric fastener sized at 9.525 mm x 1.058333333… (Can you tell by now that I hate using the units formerly known as English when doing mechanical work?)
The threads are just a little messed up, and I felt that I could probably force a nut onto the stud, but I wasn’t about to use force without being certain about what nut to use. But, being certain, and having a hardened nut, and scrounging up anti-metric wrenches that fit, I did use force. And it worked.
I flushed my brakes and did a tech on the car, and took some pictures in the process.
Right front sway bar link …
Left front sway bar link …
Hmmm … something missing? Maybe a nut and a washer?
The threads on the link end stud are damaged, and I couldn’t get a nut back on, at least just by hand. I just found out about something called a thread file which may be able to clean up the threads enough to salvage the link end. In the meantime I’ve ordered a new link end.
There are different flavors of high definition video out there. The two most popular are abbreviated as 720p and 1080i. Of those, I prefer 720p for motorsports video. I’ll talk about why.
Way back during the first part of the 20th century, the National Television System Committee (NTSC) came up with a broadcast standard that carries 60* pictures per second. This was a good choice. The 24 pictures per second rate used in film production is inadequate to convey motion properly. I’d like a rate even higher than 60, but that’s a reasonable number.
The 60 pictures per second of NTSC are a funny kind of picture. They’re field pictures, and have only half the scan lines of the image. Sometimes people describe NTSC as 30 interlaced frames per second. Sure, that’s a perfectly valid way to describe it, but it’s the wrong way to think about it. NTSC is 60 pictures per second — 60 field pictures.
The use of fields was a compromise between spatial resolution, temporal resolution and analog bandwidth. For the same bandwidth, one could transmit 30 frames per second, and have a problem conveying motion. Or one could transmit 60 frames per second at half spatial resolution, and have soft images. Today we have the capability to send 60 (or more) high resolution frames per second, because compression technology has solved the bandwidth issues.
But why not keep interlace with high definition? If we were all watching video on a CRT-based television, I’d say, sure, go ahead, do interlace. But we’re not. Most televisions use progressive display technologies rather than field-friendly CRTs. Most of these progressive televisions have high quality de-interlace technology built in, which greatly mitigates the visual impact of field to frame conversion. But increasingly we’re watching video on computers. And computers don’t know how to deal with fields.
You can take a garden variety LCD display, hook it up to a digital set-top box playing a field-based sequence over HDMI, and it looks pretty good. Take that same LCD display, hook it up the the HDMI port of a graphics card in a PC, decode the same interlaced video sequence on the PC, and the video looks like crap. Graphics cards don’t know how to process fields properly. Maybe some company will solve this, but don’t count on it.
What about 1080p? Well, what kind of 1080p are you talking about? If you mention 1080p to video production people, most of them immediately think of 1080p24 — 1920×1080 @ 24 progressive frames per second. A lot of “film” content is produced in this way. Bits on digital media replace images in emulsion. But 24 pictures per second is inadequate to convey motion. Yeah, 24 Hz is part of the “film look”, but the “film look” of motion is crap. Then there’s 1080p30. Same problem. Thirty pictures per second is inadequate. Then there’s the holy grail of HDTV: 1080p60. I can tell you, it’s awesome. Most high end, and even middle range consumer display devices can handle it. Cameras, recorders, editing and decoding technology — even in the professional arena — are lagging.
So for me, the answer boils down to this: 60 pictures per second, frame pictures not field pictures, and the highest resolution that is technically feasible. Right now, 720p is the best format in the consumer/prosumer space for capture devices that meets those criteria. For web-based video, 720p is a real stretch right now. So whenever I post that format, I’ll also post something more reasonable. A format I’ve called “quarter HD” in an earlier post — 640 x 360 @ 60p, 16:9 — is one possibility. Another possibility is 768 x 432, which has 36% of the pixel count of 720p rather than 25%. It’s higher resolution (by 44%), retains square pixels, and has the advantage of containing an integer number of 16×16 blocks of pixels (48 x 27 macroblocks), which is more compression friendly. And it should be decode-friendly on a late model notebook computer. However, “nine twenty fifths HD” doesn’t quite roll off the tongue. I’ll have to work on that.
*This was later changed to 60/1.001 (approx. 59.94 field pictures per second) with the introduction of composite color in 1953. For the sake of simplicity, I’m going to ignore the 1.001. But since composite is obsolete, the 1.001 should be banished to the kludge pile of history.
I did some analysis of the streams from the Sanyo Xacti HD1000 and from FCP’s H.264 encoder. (See previous post for description of how the streams were captured/edited/encoded.) Here are some observations about the coding of those streams.
HD1000 stream
I had seen a rumor on the internet that the HD1000 uses Ambarella’s encoder silicon. Based on parsing the stream, I have to say that someone is wrong on the internet.
Baseline profile, level 3.2. Thus, no B frames. Just IDRs and Ps.
IDRs every 30 frames, or approximately twice per second.
CAVLC rather than CABAC. (Another constraint of baseline profile.)
Inter prediction mostly 16×16 with some 8×16 and 16×8. Didn’t see any smaller partitions. Seems to be just one ref.
Intra uses 16×16 and 4×4.
The “trimmed” version output by Final Cut Pro prepends frames back to the first IDR prior to the “in” point, and seems to have lost one frame off the end (but that could have been pilot error.) The net is that FCP doesn’t have to dive into the video elementary stream to re-code the head and/or tail. Given the simple GOP and frequent IDRs, this approach is “good enough” for many applications. (When viewing the clip in the Quicktime player, the clip starts at my “in” point, but when using the analyzer, it starts at the IDR prior to the “in” point. There must be some offset indexing going on in the QT Player using a mechanism that I’m unfamiliar with.)
FCP H.264 stream Quarter HD stream
Richer use of H.264 syntax than the HD1000.
Main/3.1.
CAVLC, not CABAC.
IDR-B-P GOP. Non-stored Bs.
B’s use two refs, adjacent stored pictures (P or IDR). Ps use one reference — previous P (or IDR).
“Keyframes” in FCP jargon are IDRs.
Intra uses 16×16 and 4×4.
Inter uses 16×16, 16×8, 8×16, 8×8.
B’s use inter, skip, direct, bi-direct.
I had hoped to find something in the HD1000 stream that would explain why dual core machines have so much trouble decoding it in real time. But baseline profile should be pretty easy to decode, relatively speaking. One thing I learned from a brief visit to Fry’s is that Quicktime (surprise, surprise) runs faster on Intel processors running OS X than Intel processors running XP. An iMac with dual core 2.4 GHz processor ran the stream just fine. As I mentioned in the previous post, the VLC player behaved much better in XP than some other players. So there’s some SW issues associated with real-time decode of HD AVC. I shudder to think what will be needed to do 1080p60 AVC decode, esp. with CABAC.
Here are two versions of one of my laps at RFR.
The first is basically the camera output. In FCP, I set the in and out points, and did an “Export Quicktime Movie” operation, which avoids re-encoding. I assume FCP re-encodes GOPs at the in and out points as necessary.
It’s a 200+ MB file. On my fairly decent lap top (dual core 2 GHz with 2 GB memory) Quicktime 7.4 can’t keep up, and ran at about 20-30 frames/sec (out of 60 frames/sec). On a similar computer (with upgraded graphics capabilities), Quicktime ran about 40 frames/sec, Main Concept’s H.264 plugin for WMP had syntax problems, and the VLC Media Player was near flawless at 40% CPU utilization.
The camera file was 12 Mbps. The output of FCP is slightly above 14 Mbps. I’m not sure what the overhead is. Recoding the head and tail GOPs can’t account for that magnitude of difference.
The second file is quarter HD resolution, with 4 Mbps set as the cap for the H.264 codec. To generate this, I used “Export Using Quicktime Conversion”. Again, FCP has some overhead above the set bit rate, yielding a 4.2 Mbps final rate. The Quicktime player should be able to keep up with this file on most current machines. The file is 82 MB, so download may take a few minutes … or so.
640×360 16:9 59.94 frames/sec 4 Mbps H.264 from Final Cut Pro 2, transcoded from source above
Here’s a quick critique of my driving in this footage:
The Esses: There’s 5 to 10 mph more there. I wasn’t satisfied with the consistency of my line, so I wasn’t ready to find that extra speed. You can just brush the first two curbs (1, 1A). Riding them does bad things, especially when you drop off the end of the second curb into a hole.
Turn 3: Need to go faster, and then it’s possible to keep one position on the wheel and throttle steer from 2 to the entrance of 4.
Sunset Straight into 12: Rather than grabbing forth, I just backed off and waited for the braking zone. I need to practice heel-toe in that car if I’m going to do lots of shifting. For now, I kept the shifts to a minimum just to focus on line. (The synchros are pretty worn, so you really need to do a double clutch heel-toe.) Also, this particular braking zone is so wavy, there’s no sense diving in hard. Esp. with a stiff suspension, it’s hard to keep the tires on the ground, so a long, gradual braking is called for.
Turn 13: I played with two lines. This is the “go deep and rotate hard” line. There’s a “just left of middle until turning down for the apex” line that is worse geometry but makes use of better available grip on the surface. The latter line is more of a racing line. Not sure which is a faster qualifying line. (telemetry, telemetry, telemetry).
Turn 15: Same gearing comment as Sunset.
Turn 15A: There’s more grip available than I’m using.
Horse Shoe: Again, more grip available than I’m using. There are a couple lines I played with. “Ride the rim, then dive to apex”, and “double apex with a diamond”. This lap has a line kinda in between. Pick one, dude! The double apex made some instructors nervous, because it’s not the “school line”, and I could have easily taken the line from a couple guys (and have been sent home). Not sure which is the better qual line because I don’t really know how many g’s I can pull at the turn in, other than “a lot more than I did on that lap”.
Turn 23: Not a bad line that lap. Struggled with this corner. It’s a much faster corner than I took it, but, like the Esses, I was holding back until I got precision and consistency. It’s kinda like 6 at Laguna in that there’s a real sweet spot. The sweet spot isn’t as narrow as Laguna’s 6, but still, you want to be sure you can nail it before trying to push the limit.
My awning needs a little bit of repair work before the next event. (I likes the shade.) There’s a fastener in an odd location that’s hard to see. I’ve got all common sizes of metric and SAE hex keys. I’ve got a set of Torx drivers. None of those fit. Taking a closer look, it’s a frickin’ square drive, as seen in deck screws. Nice choice.
Come to find out, this is also known as a Robertson bit. To help avoid this kind of issue in the future, I’m buying a kit with 100 bits.