SGI: Video

O2 capture dropping audio

I'm attempting uncompressed capture from a camcorder. The result always has blank spots in the audio. The odd thing is that it's not dropping video frames - it just looses a bit of audio once in a while. If I use a compressed format, it works fine.

While the capture is runnig, everything else pretty much stops: keyboard input, mouse, etc. Mediarecorder is set to stop on any dropped frame. In fact, that's the only way I can get it to stop. I'm using a FC array, so I just pull the FC cable for a bit, and that causes a delay, which stops the capture.

Anybody have any ideas? This is a 175Mhz R10K, with 512MB memory, and a FC card (QLA2200).

Thanks,

Denver
denver wrote: I'm using a FC array, so I just pull the FC cable for a bit, and that causes a delay, which stops the capture.


Let me see if I'm reading this right: you stop the recording session, by disconnecting your harddrive???

At least you've won the first price for creativity d00d!

Never ever disconnect a live filesystem. You might (read: will) damage your filesystem, and as a consequence, your filez. The proper order is: close all open files (exit apps), unmount volumes, spindown drives, pray...

* Ask Bluefan how feeble filesystems are, even on plug&play (or unplug and play as you will) systems like Windhoos...

I'm just guessing but... maybe the dropped audio is a direct result of this.

One last question: at the time of unplugging your fibre-channel array, was your cupholder open or shut???
Glock wrote:
denver wrote: I'm using a FC array, so I just pull the FC cable for a bit, and that causes a delay, which stops the capture.


Let me see if I'm reading this right: you stop the recording session, by disconnecting your harddrive???

At least you've won the first price for creativity d00d!

Never ever disconnect a live filesystem. You might (read: will) damage your filesystem, and as a consequence, your filez. The proper order is: close all open files (exit apps), unmount volumes, spindown drives, pray...

* Ask Bluefan how feeble filesystems are, even on plug&play (or unplug and play as you will) systems like Windhoos...

I'm just guessing but... maybe the dropped audio is a direct result of this.

One last question: at the time of unplugging your fibre-channel array, was your cupholder open or shut???


Actually, it's not as bad as it sounds. It's not like pulling the plug on a SCSI drive. I'm not killing the power, all that happens is a momentary loss of sync on the FC connection. That causes a delay in the I/Os, but none are lost. I'm not saying this is a recommended procedure, just that I have no evidence that it caused any probelms here.

Otherwise, I agree about disconnecting a live filesystem - if you don't get it back in a reasonable time, the host can panic. If you loose any cached data, the filesystem gets corrupted.

In the past I've tested devices, HBA's, drivers, etc. Some tests involved introducing errors in the FC connection, to make sure everybody recovers properly. Some things are generally difficult to recover from, others are easier. Momentarily dropping the loop is one of the easier ones.

Thanks,

Denver
When I was messing around with striping Clariion arrays, if I disconnected the primary loop, the automatic failover to the secondary loop didn't happen for what seemed like a minute or so, certainly 30 seconds. One might presume that at a low level the FC-AL protocol is the layer that fights for the connection, and is one addition that regular SCSI doesn't have. So long as the loop can re-establish itself, it can then start queueing/unqueuing the regular SCSI traffic without disrupting the overlying protocols, and should work fine.
:O3000: <> :O3000: :O2000: :Tezro: :Fuel: x2+ :Octane2: :Octane: x3 :1600SW: x2 :O2: x2+ :Indigo2IMP: :Indigo2: x2 :Indigo: x3 :Indy: x2+

Once you step up to the big iron, you learn all about physics, electrical standards, and first aid - usually all in the same day
denver wrote: Anybody have any ideas? This is a 175Mhz R10K, with 512MB memory, and a FC card (QLA2200).


My guess is unresolved timing issue with R10k 150/175MHz CPUs in o2.
Think that best what you can do is to look for R10k 195/250 or even better R12k 300/400 CPU upgrade. Which IRIX version you use BTW?
Out of curiosity, for those in the know, how much hard drive real estate will a 30 minute standard camcorder video take up when captured to the O2?
Spidy wrote: Out of curiosity, for those in the know, how much hard drive real estate will a 30 minute standard camcorder video take up when captured to the O2?


Depends, but you may estimate slightly over 30GB for NTSC or slightly under 40GB for PAL uncompressed, compressed figures varying a lot.
zone wrote:
denver wrote: Anybody have any ideas? This is a 175Mhz R10K, with 512MB memory, and a FC card (QLA2200).


My guess is unresolved timing issue with R10k 150/175MHz CPUs in o2.
Think that best what you can do is to look for R10k 195/250 or even better R12k 300/400 CPU upgrade. Which IRIX version you use BTW?


Interesting. I didn't know there were timing issues with some models. But that could explain what's happening, including the way it's behaving during uncompressed capture.

I'm currently running 6.5.25f. Should have said that before.

Thanks
Dr. Dave wrote: When I was messing around with striping Clariion arrays, if I disconnected the primary loop, the automatic failover to the secondary loop didn't happen for what seemed like a minute or so, certainly 30 seconds. One might presume that at a low level the FC-AL protocol is the layer that fights for the connection, and is one addition that regular SCSI doesn't have. So long as the loop can re-establish itself, it can then start queueing/unqueuing the regular SCSI traffic without disrupting the overlying protocols, and should work fine.


Exactly. In fact, this isn't too much different from what happens if you have a hub in there, and connect/disconnect something else. The duration in my case was longer - a couple of seconds, but that's all. When the loop goes down, the ISP waits a while for it to restore before resuming operation. Otherwise it returns a timeout. If anything goes wrong with the current command, it just gets retried. .
denver wrote: Interesting. I didn't know there were timing issues with some models. But that could explain what's happening, including the way it's behaving during uncompressed capture.

I'm currently running 6.5.25f. Should have said that before.


I stated my guess not an authoritative answer. Regarding timing issue on early R10k o2's you may check sgi related newsgroups.
Also, note that later IRIX versions seems to have somewhat broken video support according to Ian Mapleson, his recomendation is 6.5.15 for video work on o2.
Here is a post on comp.sys.sgi.hardware by SGI systems engineer Alexis Cousein mentioning the problems.
zone wrote:
denver wrote: Interesting. I didn't know there were timing issues with some models. But that could explain what's happening, including the way it's behaving during uncompressed capture.

I'm currently running 6.5.25f. Should have said that before.


I stated my guess not an authoritative answer. Regarding timing issue on early R10k o2's you may check sgi related newsgroups.
Also, note that later IRIX versions seems to have somewhat broken video support according to Ian Mapleson, his recomendation is 6.5.15 for video work on o2.


Well, I think your guess was pretty good. I don't have a newer R10000 (or R12000) system at this point, but I do have a 180MHz R5000. Uncompressed capture on that one works quite a bit better, although it is a bit sluggish responding to the "stop" button. But that's not really a problem, at least it does stop.

I've since made a new system disk for that one with 6.5.15. I'm getting very good results going from the camcorder->O2->dvd.

Many thanks,

Denver
denver wrote: Well, I think your guess was pretty good. I don't have a newer R10000 (or R12000) system at this point, but I do have a 180MHz R5000. Uncompressed capture on that one works quite a bit better, although it is a bit sluggish responding to the "stop" button. But that's not really a problem, at least it does stop.

Glad to hear that you found solution. I noticed also that for some reason [stop] button takes a while to respond after capturing of longer sequence, and that behaviour seems to be unrelated with particular CPU type, I had this issue in past on older R10k and R5k boxes and also now on my R12k 400 and RM7k 300.
BTW you may also consider cheap upgrade with R5k 200 CPU, doubled (1MB) secondary cache makes difference.

denver wrote: I've since made a new system disk for that one with 6.5.15. I'm getting very good results going from the camcorder->O2->dvd.

Can you tell us more about o2->DVD workflow.
zone wrote:
denver wrote: I've since made a new syst
em disk for that one with 6.5.15. I'm getting very good results going from the camcorder->O2->dvd.

Can you tell us more about o2->DVD workflow.


Certainly. I haven't had time to work on this project lately, and I probably don't have the best answers, but I'll explain what I've done so far.

In simple terms, the work goes like this:
1. Capture the camcorder output (svideo) with the O2 using mediarecorder.
2. Do a bit of simple editing: trim the ends of the clip and add a title using moviemaker.
3. Convert the clip to MPEG2 with mencoder (FreeBSD).
4. Create the DVD files using DVDStyler (FreeBSD).
5. Burn the DVD with growisofs (FreeBSD).

I originally thought I was going to need to capture uncompressed because I was going to edit the result. But after doing some experimenting, I don't see a clear advantage. Besides, although I have been able to get the O2 to do uncompressed captures, it's a little unpredictable: sometimes it works fine, sometimes not. Capturing with compression is easier. So I could probably do the capture with dmrecord instead of mediarecorder.

After doing some research, I've been capturing to a QuickTime file, using JPEG-A compression, with YCrCb 422 packing. I usually bump the quality up from 75% to 95%.

I save (Export As) the edited result to an AVI file, using SGI JPEG compression, again with YUV 422 packing.

The mencoder command I use is:
# 4:3
SCALE=720:480
mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=$SCALE,\
harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:\
abitrate=192:aspect=4/3 -ofps 30000/1001 \
-o outfile infile

Once you have the MPEG2 file, there are a number of ways to get that onto a DVD. I've found DVDStyler to be simple and easy to use. It's supposed to also burn the DVD, but I always get an error at that point - I probably don't have the correct permissions on the dvd device. But it does tell you what command it's trying to use, so I just run that as root and that works fine.

So far I've been limiting all my clips to about 30 seconds. I don't want to spend an hour capturing something, then going through all the other work, only to discover that I made a poor option choice during the capture. I have a feeling that once I do start working with clips that are 30 minutes long instead of 30 seconds, there will be a whole new set of challenges.

Thanks,

Denver
[quote="denver"]
In simple terms, the work goes like this:
1. Capture the camcorder output (svideo) with the O2 using mediarecorder.
2. Do a bit of simple editing: trim the ends of the clip and add a title using moviemaker.
3. Convert the clip to MPEG2 with mencoder (FreeBSD).
4. Create the DVD files using DVDStyler (FreeBSD).
5. Burn the DVD with growisofs (FreeBSD).

I originally thought I was going to need to capture uncompressed because I was going to edit the result. But after doing some experimenting, I don't see a clear advantage. Besides, although I have been able to get the O2 to do uncompressed captures, it's a little unpredictable: sometimes it works fine, sometimes not. Capturing with compression is easier. So I could probably do the capture with dmrecord instead of mediarecorder.

After doing some research, I've been capturing to a QuickTime file, using JPEG-A compression, with YCrCb 422 packing. I usually bump the quality up from 75% to 95%.

I save (Export As) the edited result to an AVI file, using SGI JPEG compression, again with YUV 422 packing.

The mencoder command I use is:
# 4:3
SCALE=720:480
mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=$SCALE,\
harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:\
abitrate=192:aspect=4/3 -ofps 30000/1001 \
-o outfile infile
[/quote]

Wow, this is great info! I've recently been looking to digitize our home videos. (If you follow MacSlash, or digital_video/video_geeks on LiveJournal, then you've seen my questions.) I've got a beige G3 with the A/V package, and an O2. I need to capture video into a format I can then (ideally) transfer to my G5 PowerMac to edit/burn with iMovie. It's also got to be relatively easy, as my wife (non-techie) will probably be doing most of this. If it's too complicated I'll get stuck doing the capturing at minimum.

I knew about mediarecorder from my googling, but know very little about using IRIX in general. Also, my O2 seems to be on the blink...I set it to boot to serial so I didn't need a monitor, but not it doesn't want to boot at all, and I haven't any way to get a serial console attached. So that's an additional hurdle right now. Fortunately, I think I have discovered a MacOS 9 solution for doing the capture.

The next "problem" is lack of drive space. My O2 only has 9 GB and the Mac 20 GB (on its HFS part - it runs Linux on the rest of the drive). How much video am I going to be able to capture before I have to dump it to the G5? Will I be able to capture full frame full motion video with compression, or will I have to go uncompressed? I probably won't know until I try it. My guess is the O2 might be more qualified to do compression on the fly.