STICKY: Foundation (old) Camera Board information

[poing]

Well, the increase will be about 50% vertically, a bit less horizontally- noticeable but not huge.

If the default still image originates from a 1080p frame the used dimension is 1440 x 1080 pixels or 1.5 MP. If you can use the full sensor you use 2592 x 1944 pixels or 5 MP which is roughly 100% more both horizontally and vertically.

[mikerr]

Further evidence is that you can get wider uncropped field of view than the default by giving a horizontal resolution of 3500
http://www.raspberrypi.org/phpBB3/viewt ... 43&t=44077

It's true that I find video quality stunning, but still quality only "very good", but not amazing,
hopefully it turns out stills are currently using the 1080p option,
so a quality improvement for us all in the works

[Nu7s]

Just wanted to say thanks for releasing this. I've been playing around with it since I recieved it yesterday, and I'm really impressed with the quality and ease of use. Thanks!

[mikec79]

James,

Would I get a mp4 video out of RaspiVid if I change line 695 in RaspiVid.c

Code: Select all

encoder_output->format->encoding = MMAL_ENCODING_H264;

to

Code: Select all

encoder_output->format->encoding = MMAL_ENCODING_MP4V;

I found the following in mmal_param_convert.c, and I'm guessing those are our encoding options:

Code: Select all

static string_pair_t video_codec_enums[] = {
      { "h264",  MMAL_ENCODING_H264 },
      { "h263",  MMAL_ENCODING_H263 },
      { "mpeg4", MMAL_ENCODING_MP4V },
      { "mpeg2", MMAL_ENCODING_MP2V },
      { "vp8",   MMAL_ENCODING_VP8 },
      { "vp7",   MMAL_ENCODING_VP7 },
      { "vp6",   MMAL_ENCODING_VP6 },
   };

[jamesh]

Er, never tried it. Possibly...I can check which encoders are built in to the firmware tomorrow.

In the meantime, no harm in trying it....

Note that some of those formats wont be feasible at 1080p30 (the VP ones are not fully HW accelerated - they do use the GPU, but don't have the extra HW support that the H264 encoder has)

[jamesh]

ps. You'll also have the kudos of being the first person ever to get it working on a Pi. If it works....

[Bleugh]

Guys,
it ain't gonna be easy to remove the IR filter on these things!,
the filter itself is held in place on the sensor by the black, square 'plastic' lens holding casing - see photo attached.
The filter is tucked nicely under the circle at the 4 corners
to remove it needs the rear body of the module to be dismantled, problem is, there's a line of epoxy on the flexible circuit board which won't be removable easily

removing the lens is fairly easy though - just scrape off the three small blobs of epoxy that lock the thread in place, and twist the lens, holding the body firm (it's not glued onto the PCB very firmly)

Also, the module specs seem very similar to the Sunny P5V01A, which there's a datasheet available,
just looks likely that it's a different mounting than the 01A and non autofocus

dismantled camera module

RASPBERRY PI CAMERA MODULE DISMANTLEDsmallest.jpg (60.28 KiB) Viewed 29328 times

P5V01A
5.0M AF
8.5*8.5*5.4
1/4"
OV5647
Kantatsu
T5ES

[mikec79]

Er, never tried it. Possibly...I can check which encoders are built in to the firmware tomorrow.

In the meantime, no harm in trying it....

Note that some of those formats wont be feasible at 1080p30 (the VP ones are not fully HW accelerated - they do use the GPU, but don't have the extra HW support that the H264 encoder has)

No luck so far

Code: Select all

pi@raspberrypi ~ $ userland/build/bin/raspimp4 -o video2.mp4
mmal: mmal_vc_port_enable: failed to enable port vc.ril.video_encode:in:0(OPQV): ENOSPC
mmal: mmal_port_enable: failed to enable connected port (vc.ril.video_encode:in:0(OPQV))0xcdcd90 (ENOSPC)
mmal: mmal_connection_enable: output port couldn't be enabled
mmal: main: Failed to connect camera video port to encoder input
mmal: Out of resources (other than memory)
mmal: Failed to run camera app. Please check for firmware updates

[poing]

Guys,
it ain't gonna be easy to remove the IR filter on these things!,
the filter itself is held in place on the sensor by the black, square 'plastic' lens holding casing - see photo attached.
The filter is tucked nicely under the circle at the 4 corners
to remove it needs the rear body of the module to be dismantled, problem is, there's a line of epoxy on the flexible circuit board which won't be removable easily

removing the lens is fairly easy though - just scrape off the three small blobs of epoxy that lock the thread in place, and twist the lens, holding the body firm (it's not glued onto the PCB very firmly)

Also, the module specs seem very similar to the Sunny P5V01A, which there's a datasheet available,
just looks likely that it's a different mounting than the 01A and non autofocus

RASPBERRY PI CAMERA MODULE DISMANTLEDsmallest.jpg

P5V01A
5.0M AF
8.5*8.5*5.4
1/4"
OV5647
Kantatsu
T5ES

Is the filter very stiff? If it's just a thin sheet it might be possible to use epoxy on the end of a stick and glue that to the filter. Then when bonded pull the filter out. Just a thought.

[dom]

I found the following in mmal_param_convert.c, and I'm guessing those are our encoding options:

Code: Select all

static string_pair_t video_codec_enums[] = {
      { "h264",  MMAL_ENCODING_H264 },
      { "h263",  MMAL_ENCODING_H263 },
      { "mpeg4", MMAL_ENCODING_MP4V },
      { "mpeg2", MMAL_ENCODING_MP2V },
      { "vp8",   MMAL_ENCODING_VP8 },
      { "vp7",   MMAL_ENCODING_VP7 },
      { "vp6",   MMAL_ENCODING_VP6 },
   };

Sorry, the chip doesn't have support to encode those formats. h264 and mpeg4 are supported, although I've not tested mpeg4.

[wallarug]

I found the following in mmal_param_convert.c, and I'm guessing those are our encoding options:

Code: Select all

static string_pair_t video_codec_enums[] = {
      { "h264",  MMAL_ENCODING_H264 },
      { "h263",  MMAL_ENCODING_H263 },
      { "mpeg4", MMAL_ENCODING_MP4V },
      { "mpeg2", MMAL_ENCODING_MP2V },
      { "vp8",   MMAL_ENCODING_VP8 },
      { "vp7",   MMAL_ENCODING_VP7 },
      { "vp6",   MMAL_ENCODING_VP6 },
   };

Sorry, the chip doesn't have support to encode those formats. h264 and mpeg4 are supported, although I've not tested mpeg4.

Have to buy licence

[dom]

Have to buy licence

It's not a licence issue. There's just not the support in the hardware or the demand for the software to be written.

There is very little demand for us to produce, say, an MPEG2 encoder, when we have hardware support for h264 which is between 2 and 4 times as efficient in quality/size.
Hence, there doesn't exist an MPEG2 encoder.

There is more demand for decoders, due to legacy content/equipment, so more formats are supported for decode.

[mikec79]

Sorry, the chip doesn't have support to encode those formats. h264 and mpeg4 are supported, although I've not tested mpeg4.

No problem. I would be very happy with mpeg4.

[dom]

No problem. I would be very happy with mpeg4.

Technically that is the one other encoder the hardware can support, but that does require licencing, and I doubt there will be sufficient demand to make the lengthly licencing procedure worthwhile.

When h264 is free (already licenced), how many people will pay money for a substantially less efficient codec?

[jbeale]

Just to clarify... there is licensing required to emit a MPEG4 (.mp4) stream ("wrapper" around H.264) that is separate from the H.264 license?

[dom]

Just to clarify... there is licensing required to emit a MP4 stream ("wrapper" around H.264) that is separate from the H.264 license?

No. mp4 is a container, unrelated to the mpeg4 codec. No licence is required for that.

[mikec79]

Technically that is the one other encoder the hardware can support, but that does require licencing, and I doubt there will be sufficient demand to make the lengthly licencing procedure worthwhile.

When h264 is free (already licenced), how many people will pay money for a substantially less efficient codec?

Is there a way to get the h264 video in an mp4 container straight from the gpu?

I've seen post on converting the h264 video to mp4 using AVCONV and FFMPEG, but it would be much nicer if the original output was in a more usable format like mp4.

[Cheetah]

Just to clarify... there is licensing required to emit a MPEG4 (.mp4) stream ("wrapper" around H.264) that is separate from the H.264 license?

.mp4 != MPEG4 != H.264

Technically speaking, H.264 is a subset of the MPEG4 spec (Part 10, Advanced Video Coding). As a result, .mp4 and .m4v files often contain H.264 video, but ...

There is also a Part 2, Advanced Simple Profile, and I believe this is what is commonly referred to as MPEG4 video, and this may also be contained in .mp4 and .m4v files as I understand it.

I'm guessing from the examples that what's being emitted currently is a raw video stream? It shouldn't be too hard to wrap that in a standard container format.

[mikec79]

would it be possible to set the container type using MMAL using a line like the following?

Code: Select all

encoder_output->format->container = XA_CONTAINERTYPE_MP4;

or

Code: Select all

encoder_output->format->container = MMAL_CONTAINERTYPE_MP4;

[jamesh]

Technically that is the one other encoder the hardware can support, but that does require licencing, and I doubt there will be sufficient demand to make the lengthly licencing procedure worthwhile.

When h264 is free (already licenced), how many people will pay money for a substantially less efficient codec?

Is there a way to get the h264 video in an mp4 container straight from the gpu?

I've seen post on converting the h264 video to mp4 using AVCONV and FFMPEG, but it would be much nicer if the original output was in a more usable format like mp4.

I've been looking in to inserting direct to a container, but there are issues with the GPU firmware - untested code that isn't included in the Raspberry Pi firmware build. SO its not a quick fix.

[Cheetah]

I've been looking in to inserting direct to a container, but there are issues with the GPU firmware - untested code that isn't included in the Raspberry Pi firmware build. SO its not a quick fix.

Wouldn't it be easier, and more maintainable, if the containerization was done in the userspace app? I wouldn't think there would be much CPU load associated with that.

[jamesh]

I've been looking in to inserting direct to a container, but there are issues with the GPU firmware - untested code that isn't included in the Raspberry Pi firmware build. SO its not a quick fix.

Wouldn't it be easier, and more maintainable, if the containerization was done in the userspace app? I wouldn't think there would be much CPU load associated with that.

Possibly. You (ie community) already have the code producing the stream, so anyone out there is welcome to add the containerisation code.

[dom]

I've been looking in to inserting direct to a container, but there are issues with the GPU firmware - untested code that isn't included in the Raspberry Pi firmware build. SO its not a quick fix.

Wouldn't it be easier, and more maintainable, if the containerization was done in the userspace app? I wouldn't think there would be much CPU load associated with that.

Yes it would. The very first release of Raspberry Pi included a read_media component with support for some containers. But some common formats were completely missing (e.g. ts) and others were incomplete.
It all ran on the GPU and was closed source, so if it didn't do what you wanted, then tough. It also required an ugly service running on the arm to handle file accesses.

It's not hard to link with libffmpeg (like omxplayer does) which supports every possible container and is constantly improved. I think that's the correct solution.

In fact no code is needed something like

Code: Select all

raspivid -o - | ffmpeg -r 30 -i pipe:0 -vcodec copy video_out.mkv

should work just fine.

[mikec79]

I've been looking in to inserting direct to a container, but there are issues with the GPU firmware - untested code that isn't included in the Raspberry Pi firmware build. SO its not a quick fix.

Thanks, I guess I'll stick with using the VLC browser plugin to display a live stream via a html page.

[fastmapper]

Here is a focal length update.

Now that the full field of view is available for still photos, I have repeated my estimation of focal length. To do this I took photos of a measuring tape at 6 different distances from the camera. I estimate that the focal length of my Raspberry Pi camera is 3.60+/-0.01mm.

It would be great if the EXIF tags of raspistill images could be populated with a focal length of 3.6mm until a better value is available.