Oct 2006
FTP Shares & Home folders
31.10.06 21:01 |
OS X Server
| Permalink
The home has to be inside an FTP share. Otherwise
you'll get the FTP root contents instead. So to give
local users access to their home folders over FTP,
/Users would have to be set as an FTP share. The
other, not so flexible solution, is to keep all homes
within your FTP root.
Not keeping this in mind will throw your FTP users into the FTP root directory. The FTP transcript will say:
230-No directory! Logging in with home=/
Not keeping this in mind will throw your FTP users into the FTP root directory. The FTP transcript will say:
230-No directory! Logging in with home=/
|
Cool TEDTalks
BlenderCon 2006
... was amazing. Met some very nice people there.
Thanks to all of You! Will definitely try to be back
next year, although I'm still alittle woozy from all
of it. Not sure if I could go tomorrow...1/5 of the
work is still to be done... I also put up some photos of the event
(unfortunately didn't have time to take many).
Some words about the AV production. The whole show was done with 3 cameras + projector feed. In the main hall, we had everything running into preview monitors and a video mixer that was connected to a little JVC MiniDV cam for passthrough digitizing. That was then fed into a G5 running Wirecast which had two inputs (video from cam + still for fades) and two outputs: streaming (MP4 and raw DV (with AAC audio, wrapped in a MOV file)) the streaming was handled by Darwin Streaming Server, I still don't know what connection we were on.
Wirecast worked pretty well. I really like that you can define as much IO as you want. It did crash a few times and I think it's way overpriced (470 EUR), I'm pretty sure someone will come along soon and create something similar for far less money (eg next version of QT Broadcaster), 50 EUR would be OK.
For audio we had two mics in the main hall + presentation PC sound between which I tried to mix desperately (keeping all of them on would've been too noisy). Sound is hard in these little venues because there's little motivation for speakers to really make an effort and speak into the mic.
In the smaller room I just shot everything as DV (would HDV've made a difference?) off the screen with the Sony HVR A1E and recorded as much as possible onto a FireStore FS4 (I think this is the way to go for capturing, a bit too pricy at the moment though). The sound situtation was a little better here since we just had a lapell mic attached to the speaker and the onboard cam mic for ambient and questions. The FS-4 holds 3 hours of material which made timing difficult. Most of the sessions just ran back-to-back so I had no time to offload the material. This meant going to tape and that's a nightmare because you have to switch tapes (not fun with a bottom-loader sitting on a tripod with several addons in a room where you can hardly turn around).
The final compression workflow was kind of a positive surprise. We ended up using VLC's Streaming/Transcoding Wizard which, considering the circumstances, did a splending job. The main drawbacks were no scaling/cropping controls or exact choice for compression parameters.
There's a pretty big feature gap in VLC - it doesn't seem to support QuickTime reference movies. My plan was to store some of the shorter presentations as one big file and just create refs from each one and encode those into separate files but it didn't work. I think this could be a nice carrot for some VLC dev out there.
Finally Marco used rsync to send everything to the Blender Foundation server. I'm still in the final phases of getting the 3rd day and second room stuff online.
- Wireless mics for all the speakers. Many engineers like to use their hands also away from the podium.
- Better room organization. Some really popular sessions were unfortunately put in the smaller room. It was also obvious that BC will need a bigger venue next time.
- Video metadata. I didn't have time to properly tag the MOV files before compression. VLC will preserve any MOV annotation you've added when going go MP4. Loggging in general was pretty hard because of the tight schedule.
- Nicer graphics. I assumed we'd have some readymade bitmaps to cut to during breaks/before a session etc, but I was wrong. To take the guesswork out, just bring your own graphics and make it general enough for them to work as titles as well (ie don't use "we'll be right back...").
- NO tape. Shooting to tape in these situations is pretty pointless. Sessions are always longer than 60 min and there's alot of them. A nice 120 gig FireStore would be wonderful next time.
- Better compression. Screencasts compress very differently from live action so it's hard to find a codec that would do both perfectly (there are many lossless ones that are, but I mean online distribution). H.264 and multipass encoding will be the way to go next time (?)). The quality in general is pretty good, but a little too soft for the screencasts.
- Proper image ratios. Something went wrong with those.
- A solid naming scheme. I had thought of one but it fell apart (no index). Here's one for next year: bc07-2014130-name.mp4 (dd:hh:mm-name)
- Lower thirds for download versions (so people know who's talking and what the subject is).
For future reference
Some words about the AV production. The whole show was done with 3 cameras + projector feed. In the main hall, we had everything running into preview monitors and a video mixer that was connected to a little JVC MiniDV cam for passthrough digitizing. That was then fed into a G5 running Wirecast which had two inputs (video from cam + still for fades) and two outputs: streaming (MP4 and raw DV (with AAC audio, wrapped in a MOV file)) the streaming was handled by Darwin Streaming Server, I still don't know what connection we were on.
Wirecast worked pretty well. I really like that you can define as much IO as you want. It did crash a few times and I think it's way overpriced (470 EUR), I'm pretty sure someone will come along soon and create something similar for far less money (eg next version of QT Broadcaster), 50 EUR would be OK.
For audio we had two mics in the main hall + presentation PC sound between which I tried to mix desperately (keeping all of them on would've been too noisy). Sound is hard in these little venues because there's little motivation for speakers to really make an effort and speak into the mic.
In the smaller room I just shot everything as DV (would HDV've made a difference?) off the screen with the Sony HVR A1E and recorded as much as possible onto a FireStore FS4 (I think this is the way to go for capturing, a bit too pricy at the moment though). The sound situtation was a little better here since we just had a lapell mic attached to the speaker and the onboard cam mic for ambient and questions. The FS-4 holds 3 hours of material which made timing difficult. Most of the sessions just ran back-to-back so I had no time to offload the material. This meant going to tape and that's a nightmare because you have to switch tapes (not fun with a bottom-loader sitting on a tripod with several addons in a room where you can hardly turn around).
The final compression workflow was kind of a positive surprise. We ended up using VLC's Streaming/Transcoding Wizard which, considering the circumstances, did a splending job. The main drawbacks were no scaling/cropping controls or exact choice for compression parameters.
There's a pretty big feature gap in VLC - it doesn't seem to support QuickTime reference movies. My plan was to store some of the shorter presentations as one big file and just create refs from each one and encode those into separate files but it didn't work. I think this could be a nice carrot for some VLC dev out there.
Finally Marco used rsync to send everything to the Blender Foundation server. I'm still in the final phases of getting the 3rd day and second room stuff online.
Some things that could've done better/differently:
- Wireless mics for all the speakers. Many engineers like to use their hands also away from the podium.
- Better room organization. Some really popular sessions were unfortunately put in the smaller room. It was also obvious that BC will need a bigger venue next time.
- Video metadata. I didn't have time to properly tag the MOV files before compression. VLC will preserve any MOV annotation you've added when going go MP4. Loggging in general was pretty hard because of the tight schedule.
- Nicer graphics. I assumed we'd have some readymade bitmaps to cut to during breaks/before a session etc, but I was wrong. To take the guesswork out, just bring your own graphics and make it general enough for them to work as titles as well (ie don't use "we'll be right back...").
- NO tape. Shooting to tape in these situations is pretty pointless. Sessions are always longer than 60 min and there's alot of them. A nice 120 gig FireStore would be wonderful next time.
- Better compression. Screencasts compress very differently from live action so it's hard to find a codec that would do both perfectly (there are many lossless ones that are, but I mean online distribution). H.264 and multipass encoding will be the way to go next time (?)). The quality in general is pretty good, but a little too soft for the screencasts.
- Proper image ratios. Something went wrong with those.
- A solid naming scheme. I had thought of one but it fell apart (no index). Here's one for next year: bc07-2014130-name.mp4 (dd:hh:mm-name)
- Lower thirds for download versions (so people know who's talking and what the subject is).
Aging with Photoshop
Sony HVR A1E "Mini Review"
15.10.06 11:50 |
Permalink
The HVR A1E is a HDV camera from Sony that packs alot
of features in a small package. Only been able to
play with it for two days, but here goes:
Pros:
Cons:
- 1 sensor (it's CMOS, not CCD btw) - a bit noisy in low light. But probably less so than many other 1CCD cams
- Mic inside the camera body. You can hear the noise from the headphones
- Can't select builtin mic when XLR module is attached (at least I couldn't figure it out)
- Touchscreen menu works pretty fast but the animations are totally superfluous
- Price (?) It's a lot of camera, but it's also almost 3 000 EUR.
A pretty cool little camera. Some talented person could pull a lot of really high quality material with this one
Pros:
- Very compact form factor, nice sturdy body
- Very nice image quality
- two-channel XLR input module included
- DV, HDV and DVCAM (DV but faster) support, real 16:9 (anamorphic)
- Touchscreen menu
- Works pretty well with FCP (although getting HDV to work takes some time always...)
- A lot of configuration options
Cons:
- 1 sensor (it's CMOS, not CCD btw) - a bit noisy in low light. But probably less so than many other 1CCD cams
- Mic inside the camera body. You can hear the noise from the headphones
- Can't select builtin mic when XLR module is attached (at least I couldn't figure it out)
- Touchscreen menu works pretty fast but the animations are totally superfluous
- Price (?) It's a lot of camera, but it's also almost 3 000 EUR.
A pretty cool little camera. Some talented person could pull a lot of really high quality material with this one
More Useful Articles
14.10.06 12:31 |
Permalink
Are a users emails deleted with the user?
12.10.06 16:02 |
OS X Server
| Permalink
Shadow Girl
Creating users
useradd -g staff -c "Firstname Lastname" -d
/export/home/username -m -s /bin/bash username
passwd username
Silly that Solaris comes with root enabled. And then says setting a password is *optional* (I thought it meant not enabling the account at all). Solaris is weird (and not very pretty either).
passwd username
Silly that Solaris comes with root enabled. And then says setting a password is *optional* (I thought it meant not enabling the account at all). Solaris is weird (and not very pretty either).
If it smashes down
04.10.06 21:18 |
OS X Server
| Permalink