Summary:

• System
  • hostname: imarsu(.local)
  • root: openwrt
  • eth0: LAN port to local 192.168.100.0/24 subnet, dnsmasq
  • eth1: WAN
• Software
  • carpcd installed?
  • NFCclient installed and configured to start at boot?

• ./configure
• sudo make install

Debian based system:

All lib are in /usr/local/lib not /usr/lib. So the following is needed:

 <code>
 sudo su
 echo "/usr/local/lib" > /etc/ld.so.conf.d/usr_local.conf
 ldconfig
 exit
 </code>
 

   carpcd -d -c /etc/carpcd.conf
   

• The first sound and vibration signal indicate connection start. DO NOT remove the phone!
• The second sound and vibration signal indicate data transfer completion. Remove the phone within 5 seconds or wait for the 2nd data transfer!

ERROR cases:

• NFCDemo apps starts slowly (a few seconds).
• If acceleration tab not activated, go to other tab and back.
• If the NFC Reader seems to hang,

  • solution 1: replug CarPC power. It needs a few minutes to start.
  • solution 2: ssh to carpc as root (see login data above) and: /etc/init.d/nfcclient restart
  Edit

  Videos

  Sources:

• http://wiki.openwrt.org/doc/howto/usb.video
• http://www.oz9aec.net/index.php/gstreamer/473-using-the-logitech-c920-webcam-with-gstreamer
• Video stream primer: http://www.ezs3.com/public/What_bitrate_should_I_use_when_encoding_my_video_How_do_I_optimize_my_video_for_the_web.cfm
• http://sheldor.blogspot.de/2013/09/openwrt-based-video-recording-system_10.html
• http://programmaticponderings.wordpress.com/tag/motion/

As previously mentioned in the article linked above the container is simply a way of packaging together the audio and video stream while delineating how they are compressed.

When choosing between the MP4, MOV, FLV, WMV and AVI containers, MP4 is the best option. The complexity of the MOV container can cause devices to stall when playing video. The FLV container is only supported by the Flash plugin, which is not supported by the new HTML5 standard and Apple mobile devices such as the iPhone. The WMV container requires specialized plugins and is generally only supported by Microsoft products such the Zune, or Silverlight. The AVI container is not meant for web distribution, as it is targeted at desktop players (it is also not supported for web playback through our own players, but it is listed here to clear any confusion on the container).

The MP4 container is almost universally supported: Apple, Microsoft, Flash, and HTML5 all offer support for MP4 (there are some outliers). On top of that MP4 can use the H.264 video codec and the AAC audio codec, compatibility wise they are the best choices for compressing your video. H.264 video is supported by just about any player, browser, plugin and device available. It also offers one of the best algorithms for compressing your video on top of being freely available.

• Resolution: For better quality to bitrate ratio, also remember to keep your resolution in a value evenly divisible by 16, but do not alter a resolution to make it a multiple of 16 unless you over-crop, which will cause you to lose part of your image. Under-cropping or adding a black border around your image will decrease encoding efficiency. Scaling will just degrade the image.
• Frame Rate: The frame rate is how many unique consecutive images are displayed per second in the video to give the illusion of movement. Around 24 frames per second, the typical film rate which often gives a “cinematic feel,” is where most video creators land and is also a point that most human eyes are fooled into perceiving motion. This is not a standard of course, if your video is a screen cast you can get to frame rates as low as 5fps. On the other hand, large shifts between a pure white or pure black screens can have a perceivable fault below 30fps and footage of video games can often require 60fps to maintain smoothness. Television standards such as PAL (common in Europe and some parts of Asia) uses 25fps, while NTSC standard (used in the US and Japan) uses 29.97fps. Generally you should never exceed the frame rate of the source video. Obviously, the best results will be achieved if the frame rate is kept the same as your original source.

Unfortunately, to lower the bitrate you may have to choose a lower frame rate. Like most of these settings it is best to play around with the encoding to find a setting that looks best for your video. In order to do that it is advisable to consider the amount of action on screen. “Talking head videos” (a tripod shot recording a person talking at the screen) for example does not require a high frame rate because the motion is most likely subdued. While a video of a skate boarder will require at least 24fps to maintain smoothness. When you lower your frame rate make sure to accomplish it in even increments (such as splitting the amount in half) to avoid de-syncing of the video and audio streams.

• Constant versus Variable: One option you will notice when you go to encode your videos is a selection for VBR (Variable Bit Rate encoding) or CBR (Constant Bit Rate encoding). As a general rule VBR is for progressive or standard downloads and CBR is for use when using a streaming cloudfront.

VBR allows you to set a maximum and minimum bitrate. The compression algorithm then tries to efficiently compress the data dipping into the minimum bitrate when there is little to no motion on screen and spiking to the maximum defined rate when the motion is prevalent. This helps to give you a smaller overall file size, but the unpredictable spikes in bitrate can choke the playback of streaming videos.

CBR is used when a predictable flat bit rate is needed. The flat bitrate throughout the entire file comes at the price of efficiency for the codec. Usually resulting in a larger file, but smoother playback.

However these rules are not universal. Depending on your video you might want to use a VBR for a streaming playback if the spikes do not exceed your target user's connection speed. For example if there is only one high motion scene in a video, you will be wasting bandwidth on a constant bitrate throughout the entire file and may better serve your user's by using a variable bitrate. In any case try experimenting with the two settings to find what works best for your video.

• Quality versus Streaming: If you are not sure what your target connection speed is and you are not shooting to stream your videos, but do not want an abundant amount of bandwidth cost from Amazon, one method that works really well in determining a good bitrate is the Kush Gauge. To find a decent bitrate simply multiply the target pixel count by the frame rate; then multiply the result by a factor of 1, 2 or 4, depending on the amount of motion in the video; and then multiply that result by 0.07 to get the bit rate in bps. Divide your result by 1,000 to get a kbps estimate or by 1,000,000 to get a Mbps estimate.

Kush gauge: pixel count x motion factor x 0.07 ÷ 1000 = bit rate in kbps
(frame width x height = pixel count) and motion factor is 1,2 or 4

Screencast example
For example if your video is a low motion 5fps screen cast in a 1280 x 720 frame size you would have a formula like this:

1280 x 720 = 921,600 pixel count
5 frames per second
1 = Low Motion

(921,600 x 5) x 1 x 0.07 = 322,560 bps / 1000 = 322 kbps bitrate

High action video example
Another example on the other side of the spectrum would be a 24 fps high action shot of an action scene with multiple quick cuts in a 1920 x 1080 frame size:

1920 x 1080 = 2,073,600 pixel count
24 frames per second
4 = High Motion

(2,073,600 x 24) x 4 x 0.07 = 13,934,592 bps / 1000 = 13,934 kbps bitrate

For streaming this example would be a bad idea, unless your target audience lives in South Korea. If you do decide to offer a super high quality file, be sure to also encode a lower quality streaming video for clients that may not have the fastest broadband available.

When using this gauge with a variable bitrate (VBR), 75% of the resulting bitrate can be used for the minimum rate and 150% for the maximum rate.

If you do not want to do the math this bitrate calculator will give you a similar result:
http://www.adobe.com/devnet/flash/apps/flv_bitrate_calculator/

• Starting Points:

If you are completely lost right now and having trouble deciding what your video bitrate should be here are some starting points for you to experiment with for a streaming connection:

Output size 	Bitrate 	Filesize
320x240 pixels 	400 kbps 	3MB / minute
480x270 pixels 	700 kbps 	5MB / minute
1024 x 576 pixels 	1500 kbps 	11MB / minute
1280x720 pixels 	2500 kbps 	19MB / minute
1920x1080 pixels 	4000 kbps 	30MB / minute

In general though we recommend a bitrate of around 2 - 2.5 Mbps, which takes into account the average worldwide broadband connections. Once again we do however suggest you experiment with different settings and see how they work for you.

• The Other Side of the Equation

Once you have your video bitrate defined, you will still have to decide how to set the encoding for your audio. Most of the settings are straight forward because they can be copied from your source file, but if your file is slightly above your targeted bitrate you can make some small cutbacks on the audio. Even at extremely low bit rates, reasonable audio quality can be achieved.

First you need to figure out if you are going to encode with Mono or Stereo. If your source video was filmed in mono there is no reason to encode in stereo. You can however reduce a stereo stream to mono and it is generally advisable if the video is a simple speech. Talking head videos are usually good candidates for selecting mono over stereo.

For your sampling frequency it is suggested that you maintain around 44.1 kHz for most of your videos or 22.05 kHZ if once again you are recording only a simple speech. Anything below 22.05 kHz will begin to degrade and distort low volume sounds such as breathing to the point where it is noticeable. While above 44.1 kHz is mainly for audio focused projects.

In the end you will probably be looking at 96 - 164kbps for a stereo music tracks, for the same track in mono, bit rates as low as 56 - 80kbps may still be acceptable. If you are once again dealing with speech only tracks you can probably even get comprehensible sound as low as 16 - 24 kbps.

“Motion” is a software package that will capture videos or images when motion has been detected from a video source (the webcam in our case). The standard motion package that was compiled for OpenWRT does not have ffmpeg support.

We must enable ffmpeg support.

Following dependencies are required:

• libavcodec.a or libavcodec.so or *
• libavformat.a or libavformat.so not found:

Select them in make menuconfig

In openwrt build_root, find motion/Makefile and comment out –disable-ffmpeg.

 vim feeds/packages/multimedia/motion/Makefile

 35 CONFIGURE_ARGS+= \
 36   --without-optimizecpu \
 37   --without-jpeg-mmx \
 38   --without-sdl \
 39   --without-mysql \
 40   --without-pgsql \
 41   --without-sqlite3 \
 42 # --without-ffmpeg \

make package/motion/{clean,install} V=s
scp bin/x86/packages/motion_20110826-051001-2_x86.ipk root@10.0.8.147:/root/

Now install the package on OpenWrt box:

Remove package list

  rm /tmp/opkg-lists/barrier_breaker
  

Remove old motion and install the new one

  opkg remove motion
  opkg install motion_20110826-051001-2_x86.ipk

# Command to be executed when a movie file (.mpg|.avi) is created. (default: none)
# To give the filename as an argument to a command append it with %f
; on_movie_start value

# CBR
# Bitrate to be used by the ffmpeg encoder (default: 400000)
# This option is ignored if ffmpeg_variable_bitrate is not 0 (disabled)
ffmpeg_bps 500000

# VBR
# Enables and defines variable bitrate for the ffmpeg encoder.
# ffmpeg_bps is ignored if variable bitrate is enabled.
# Valid values: 0 (default) = fixed bitrate defined by ffmpeg_bps,
# or the range 2 - 31 where 2 means best quality and 31 is worst.
ffmpeg_variable_bitrate 0

I'll describe a fix first from which you may derive the problem: her is the fix:

install --group=motion --owner=motion -d /var/run/motion

once I did this then the init script would start motion.

Some other observations:

In the init script the "-b" flag to start-stop-daemon seems like the wrong thing to do, since motion can detach all by itself just fine and it is controlled in its config file. And actually using the config file setting causes problems with the -b flag here.

I could set the pidfile to /var/run/motion.pid but since motion runs as user motion this does not work.

This has actually been here since hardy, but I just upgraded to intrepid and see it still is here.

Apps: mjpg-streamer

Libs: GStreamer stuff

libgstreamer glib2, libpthread, libxml2 320927 GStreamer open source multimedia framework This package contains the GStreamer core library.

gst-mod-videomeasure libgstreamer 15779 This package contains the GStreamer videomeasure support plugin.

gst-mod-videosignal libgstreamer 8156 This package contains the GStreamer videosignal support plugin.

gst-mod-videotestsrc libgstreamer, liboil 17585 This package contains the GStreamer video test plugin.

gst-mod-mpeg4videoparse libgstreamer 7536 This package contains the GStreamer mpeg4videoparse support plugin.

gst-mod-mpegvideoparse libgstreamer 9305 This package contains the GStreamer mpegvideoparse support plugin.

libgstvideo libgstreamer 10410 This package contains the GStreamer video library.

Build_root version:

td@desktop201310:~/openwrt/trunk$ svn info
Path: .
URL: svn://svn.openwrt.org/openwrt/trunk
Repository Root: svn://svn.openwrt.org/openwrt
Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73
Revision: 38695
Node Kind: directory
Schedule: normal
Last Changed Author: blogic
Last Changed Rev: 38695
Last Changed Date: 2013-11-08 22:53:37 +0100 (Fri, 08 Nov 2013)

Frist compilation has error at gstparse. See ./configure –help and run with –disable-parse. So modify Makefile as follow.

feed/package/multimedia/gstreamer/Makefile

## Disable parse
  84 CONFIGURE_ARGS += \
 85   --disable-examples \
 86   --disable-tests \
 87   --disable-valgrind \
 88   --disable-parse \
 89   --without-x \
 90   --with-libiconv-prefix=$(ICONV_PREFIX) \
 91   --with-libintl-prefix=$(INTL_PREFIX) \
 92   #--without-libiconv-prefix \
 93   #--without-libintl-prefix \
 94 
 95 EXTRA_LDFLAGS+= \
 96   -Wl,-rpath-link=$(STAGING_DIR)/usr/lib \
 97   -L$(ICONV_PREFIX)/lib -L$(INTL_PREFIX)/lib
 98 
 99 TARGET_LDFLAGS += $(if $(ICONV_FULL),-liconv)

... ## Don't copy gst-launch* 'cause gstparse was disabled.
133 define Package/gstreamer-utils/install
134   $(INSTALL_DIR) $(1)/usr/bin
135   ( cd $(PKG_INSTALL_DIR); $(CP) \
136     ./usr/bin/gst-feedback* \
137     ./usr/bin/gst-inspect* \
138     ./usr/bin/gst-typefind* \
139     ./usr/bin/gst-xmlinspect* \
140     ./usr/bin/gst-xmllaunch* \
141     $(1)/usr/bin/ \
142   )
143 endef
144     #./usr/bin/gst-launch* \

TODO: what is EXTRALDFLAGS and TARGETLDFLAGS???