![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
OK, so I ordered some more backup tapes, and inevitably the parcel that
arrived contains a big glossy flying for all the other stuff I could be
buying.
So I flick through it and go "hmm, that's interesting. You can buy an
down in price."
Some of the items are more amusing. For example, if you look at any LCD,
one of the main specs they will quote at you is the viewing angle.
Because, unlike other display technologies, LCDs typically have a
pitiful viewing angle. So manufacturers have sunk millions into R&D to
find ways to increase the viewing angle.
Ah, but what's this I see? A "privacy filter"? Yes, it's a small piece
of plastic which is transparent only when viewed from certain
directions. In other words, you stick it to your screen to reduce the
viewing angle. WTF, people!? :-D
Then we find products which are just mystifying. Specifically, there's a
video camera that caught my eye. Several very strange things are going
on here.
First of all, it's supposedly a video camera, and yet it costs less than
This is highly suspicious.
quality was laughable.
And that's where it starts to get stranger. This camera manages to claim
that it shoots full-HD 1080p video. But if you scroll past the big shiny
newsprint and look at the technical specifications, you discover that it
has a piffling 7mm lens.
Quite why anybody would pay for an expensive 2MP photosensor and then
stick it behind a crappy 7mm lens I have no idea. The only possible
justification I can think of is "so that we can scream 'full HD' all
over the box".
Damn, some poor sap is going to buy this thing and be mighty
disappointed with the image quality...
The other puzzling thing is that the device fits in the palm of your
hand. (From the price and the lens size, we already know what kind of a
product this is, i.e., an expensive novelty item.) It says it records to
flash RAM, but surely full HD is going to fill that within minutes.
The product spec also claims it stores video as H.264, which surprises
me. I was under the impression that this requires some pretty serious
computer power (most especially for encoding).
Oh, and it's purple. WTF?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> The other puzzling thing is that the device fits in the palm of your
> hand. (From the price and the lens size, we already know what kind of a
> product this is, i.e., an expensive novelty item.)
A bit more expensive than you mentioned, but this company makes some
pretty cool small HD cameras for outdoor use:
http://www.goprocamera.com/
The video quality is pretty impressive, it's on my list.
> flash RAM, but surely full HD is going to fill that within minutes.
For 15 quid of SD card you can store 3 or 4 hours of full HD video. And
you can always buy more SD cards.
> The product spec also claims it stores video as H.264, which surprises
> me. I was under the impression that this requires some pretty serious
> computer power (most especially for encoding).
There are various levels of compression, I imagine a low power device is
not using some of the more extravagant features that a desktop PC would
use to increase the quality:bitrate ratio.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 25/01/2011 11:14 AM, scott wrote:
> http://www.goprocamera.com/
OK, that's pretty insane, right there. (Then again, nothing I'll ever do
will be cool enough to be worth filming, so...)
Also, it costs about 5x the price of this toy.
>> flash RAM, but surely full HD is going to fill that within minutes.
>
> For 15 quid of SD card you can store 3 or 4 hours of full HD video. And
> you can always buy more SD cards.
Spec claims it comes with a 4 GB flash card, but that's going to fill in
seconds I would imagine.
>> The product spec also claims it stores video as H.264, which surprises
>> me. I was under the impression that this requires some pretty serious
>> computer power (most especially for encoding).
>
> There are various levels of compression, I imagine a low power device is
> not using some of the more extravagant features that a desktop PC would
> use to increase the quality:bitrate ratio.
I was under the impression that the compression algorithm remains the
same regardless of what bitrate you select. Higher compression just
means that more of the data is discarded. The difference between, say,
Ogg Theora and WMV is the algorithm. Once you select an algorithm,
changing the bitrate just changes how much of the data gets kept.
Then again, I would think there's probably silicon for directly
computing DCTs and so forth by now...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Also, it costs about 5x the price of this toy.
"HD Hero 960" is only $180, which is only about 50% more than your camera.
> Spec claims it comes with a 4 GB flash card, but that's going to fill in
> seconds I would imagine.
Spec also claims it fills a 32 GB card in 4 hr 21m. So with the 4 GB
card I make that just over 30 mins. If it was me I'd buy a couple of
16GB cards, 2hr recording time per card seems pretty decent.
> I was under the impression that the compression algorithm remains the
> same regardless of what bitrate you select.
You want some options to play with? :-)
http://mewiki.project357.com/wiki/X264_Settings
The only one I heard about was the motion estimation algorithm,
obviously the better it can detect motion between frame the less bits
are needed to get a certain quality level. But there seems to be a load
more options to change stuff, in a battery powered device you would need
to carefully consider how much of an impact each had on battery life.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 25/01/2011 12:00 PM, scott wrote:
>> Also, it costs about 5x the price of this toy.
>
> "HD Hero 960" is only $180, which is only about 50% more than your camera.
OK, I didn't see that splashed across the front page.
Then again, I'll bet the big glossy video was shot with the flagship
product. ;-)
>> Spec claims it comes with a 4 GB flash card, but that's going to fill in
>> seconds I would imagine.
>
> Spec also claims it fills a 32 GB card in 4 hr 21m. So with the 4 GB
> card I make that just over 30 mins. If it was me I'd buy a couple of
> 16GB cards, 2hr recording time per card seems pretty decent.
They make flash cards that big now? Mmm, interesting.
I'm still surprised that you can fit 30 minutes into 4 GB. My camcorder
works with DVDs and it can handle less than 20 minutes, and that's only
standard definition. (And with far more compression than I'd like too...)
>> I was under the impression that the compression algorithm remains the
>> same regardless of what bitrate you select.
>
> You want some options to play with? :-)
>
> http://mewiki.project357.com/wiki/X264_Settings
OK, so you can change the frequency weightings and how often a keyframe
is put in, and so forth. I'm not seeing much that fundamentally changes
the whole algorithm such that it might require less computer power.
> The only one I heard about was the motion estimation algorithm,
> obviously the better it can detect motion between frame the less bits
> are needed to get a certain quality level. But there seems to be a load
> more options to change stuff, in a battery powered device you would need
> to carefully consider how much of an impact each had on battery life.
I was thinking more the problem of "how can we encode this fast enough
to be realtime?" It's not like the device has an Intel Xeon quad-core in
there, is it. From what I've heard, H.264 is very hungry for computer
power. (Although, as I say, I imagine the really hungry bits probably
have custom hardware acceleration in a device like this.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 1/25/2011 5:33 AM, Invisible wrote:
> Spec claims it comes with a 4 GB flash card, but that's going to fill in
> seconds I would imagine.
Nah... My 7D records 1080p HD video and can store probably about 15
minutes on a flash card that size.
>
>>> The product spec also claims it stores video as H.264, which surprises
>>> me. I was under the impression that this requires some pretty serious
>>> computer power (most especially for encoding).
>>
Not uncommon, especially for HD video. The encoding is usually done by a
purpose-built chip, rather that software on a general-purpose CPU.
>
> I was under the impression that the compression algorithm remains the
> same regardless of what bitrate you select. Higher compression just
> means that more of the data is discarded. The difference between, say,
> Ogg Theora and WMV is the algorithm. Once you select an algorithm,
> changing the bitrate just changes how much of the data gets kept.
Right, but the algorithm invariably has a trade-off for quality v.s.
speed. It can spend more cycles determining which bits are best kept, or
spend less time and dump the bits to storage, not always getting the
most important ones.
>
> Then again, I would think there's probably silicon for directly
> computing DCTs and so forth by now...
Been that way for a while. DVD players, portable media players, mobil
phones, etc ... all have hardware to do this, now.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 1/25/2011 6:11 AM, Invisible wrote:
> I was thinking more the problem of "how can we encode this fast enough
> to be realtime?" It's not like the device has an Intel Xeon quad-core in
> there, is it. From what I've heard, H.264 is very hungry for computer
> power. (Although, as I say, I imagine the really hungry bits probably
> have custom hardware acceleration in a device like this.)
Again... it doesn't need to ;) The signal processor is built for one
purpose: to change a stream of frames into a stream of H.264 encoded
data. If you build it with just that in mind, then you can meet the goal
of realtime compression, you don't need to worry about that chip being
able to run Windows 7 or Linux, or accessing various IO devices, or
doing your grandmother's taxes. You only need to worry about compressing
the data.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Spec claims it comes with a 4 GB flash card, but that's going to fill in
> seconds I would imagine.
A 4GB DVD can contain at least an hour of decent-quality video. And that's
just using MPEG-2. (Granted, HD video has a higher resolution, but with MPEG
the bitrate does not scale linearly with the resolution.)
> I was under the impression that the compression algorithm remains the
> same regardless of what bitrate you select.
MPEG-4 is a bit more complicated than that. It's not like it's JPEG.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 25/01/2011 03:42 PM, Warp wrote:
> Invisible<voi### [at] dev null> wrote:
>> Spec claims it comes with a 4 GB flash card, but that's going to fill in
>> seconds I would imagine.
>
> A 4GB DVD can contain at least an hour of decent-quality video. And that's
> just using MPEG-2. (Granted, HD video has a higher resolution, but with MPEG
> the bitrate does not scale linearly with the resolution.)
So how come BluRay disks are 5x the storage capacity, yet still have
roughly the same run time? I thought it was because HD video requires
more space to store.
>> I was under the impression that the compression algorithm remains the
>> same regardless of what bitrate you select.
>
> MPEG-4 is a bit more complicated than that. It's not like it's JPEG.
I thought it was more or less the case that *all* codecs work by
transforming the input, deciding how "important" each signal component
is, and then keeping only the most important bits, according to what the
requested bitrate was. I don't see anything there that makes a higher or
lower bitrate change the amount of compute power required.
(Well, OK, maybe I do. I know a some codecs do a DCT, quantise it, and
then entropy-encode the results. Bigger results = more stuff to encode.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> So how come BluRay disks are 5x the storage capacity, yet still have
> roughly the same run time? I thought it was because HD video requires
> more space to store.
On DVDs you'd be limited to under 2 hours if you used the maximum
bitrate (around 10 MBit/s IIRC), so you are forced to use lower bitrates
if you want to include menus and other various extras on the disc. With
BluRay, even if you used an average of 30 MBit/s (which is extremely
high quality with h264, and likely never actually needed, it usually is
around half that) you have about 4 hours run time. This is why you can
fit two versions of an entire film (eg 2D and 3D version) on a single
disc, plus all the extras. That would be impossible on DVD.
> I thought it was more or less the case that *all* codecs work by
> transforming the input, deciding how "important" each signal component
> is, and then keeping only the most important bits, according to what the
> requested bitrate was. I don't see anything there that makes a higher or
> lower bitrate change the amount of compute power required.
The whole point of video compression is trying to find patterns
frame-to-frame to reduce the information needed to reconstruct the
correct video (otherwise you'd just have a series of JPEG images). The
longer and more detailed you search for such patterns, the lower bitrate
you will be able to achieve for a given level of quality, or
equivalently higher quality for a given bitrate.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |