cheapest way to do video compression?

[mrf184]

Hi all,

I'm looking for a cheap way to implement a digital video transmitter; the video will be roughly 640x480 or 800x600, and I'm not looking for HD quality or anything, just a good enough video to see what's going on; the framerate should be at least 10fps. I want to target ~$5 to $10 (excluding the transmitter part).

I have been looking into the following options:
1. mp4/vp8 encoding on an orange pi or other SBC - unreliable, buggy software/hardware that can't be trusted in a remote application, consumes more power than I would like, long boot-up times
2. frame-by-frame jpeg compression on fpga - compression ratio not high enough
3. mp4 compression on fpga - e.g. https://github.com/bcattle/hardh264 - untested, not sure if it works at all; requires external ram (opens cans of worms - sram is expensive, dram requires a controller, cheap dram are all in bga package)
4. mp4 compression asic - haven't found any

It seems (4) is potentially the best solution, but unfortunately I haven't been able to find any chips suited to this purpose and fits in the budget. Is anyone here familiar with this problem and knows some parts?

[nctnico]

If you already have an FPGA then you also have the DRAM controller. One of the older iMX series chips from NXP (formerly Freescale) could be a good fit since many of them have hardware video encoders. With some effort you may not even need an OS so fast boot times are possible and the memory requirements are low.

[BrianHG]

Today, (don't go for orangepi) there are many other SBCs in the 35$ range which have both video in and out with h264 and some with h265 hardware compress and decompress capabilities which run linux or android.

Also, even cheaper 5GHz WiFi dongle HDMI in and out transmitters and receivers exist, but, you wont have the compression protocol & compression level settings and large memory video caching and more advanced standard network compliant WiFi capabilities of the SBCs, but they will be half price.

Also, for the SBCs, you can do a whole lot more, like remote desktop, have Ethernet & WiFi & Bluetooth.  Audio and Video & Mic inputs and outputs and a lot more.

If you want frame by frame, just use I-Frame only compression mode in h264, but, be aware that your bitrate will be 50 megabits for 1080p.  (You can expect at least 8 megabits for 480p)  Or, set your I-Frame interval forced to every 2nd frame and disable advance features like multiple I-Frames and bidirectional encoding which will cut that almost in half, but, make super fast error recovery and stream reconnects and file seeking.  You can do the same for MJPEG and expect high bitrates as well.  The advantage here is super quick recovery from bit errors or broken streams/stream reconnects.  Also include the feature for extra ancillary data for video editing.  It only adds a % or 2% on the total bitrate, but, allows quick recovery from biterrors and quick seeking within a stream.

Use .mp4 when delivering a final complete file, but if you will be streaming, the industry typically uses .ts which has info in it to deal with broken/corrupt data streams and disconnect/reconnect.

Almost all FPGA/Dedicated IC compressors/decompressors will deliver you a transport stream.  It is your computer's job to package the part of the stream you want into a .mp4 container, which means identifying the amount of time and data in that package and trimming the source data to the valid splicing/cut points.  You may need to also add index data into the .mp4 file & close it up before transmitting the file.

[Bruce Abbott]

The video will be roughly 640x480 or 800x600, and I'm not looking for HD quality or anything, just a good enough video to see what's going on;

Color or monochrome?

2. frame-by-frame jpeg compression on fpga - compression ratio not high enough

How high is 'high enough'?

[ThomasDK]

I remember seeing camera modules with built-in compression.

Don't remember if they only did jpeg compression on still images, but worth checking?

[SiliconWizard]

I'm looking for a cheap way to implement a digital video transmitter; the video will be roughly 640x480 or 800x600, and I'm not looking for HD quality or anything, just a good enough video to see what's going on;

How degraded are you willing to accept as to the image quality?

Converting each frame to monochrome (1 bit per pixel) by some simple dithering method + run-length encoding may lead to a good enough compression ratio. Of course it would not look good, but that may be enough for your needs. And it's not difficult to implement in an FPGA.

[BrianHG]

Are you looking for something like this?
http://www.ti.com/lit/ds/symlink/tms320dm357.pdf
Supports 480i and 480p.
It's more expensive than some SBCs.

This one is 1/3rd the price, but minimum lowest resolution video mode is 720p
https://www.mouser.com/ProductDetail/NXP-Semiconductors/ASC8848AETE/?utm_term=ASC8848&qs=NQoTdinTi9E%252bxe0pJx6cpQ==&utm_campaign=ASC8848AETE&utm_medium=aggregator&utm_source=findchips&utm_content=NXP
https://www.arrow.com/en/products/asc8850aete/nxp-semiconductors?utm_term=backorder&utm_campaign=arrow_findchips_2017&utm_medium=aggregator&utm_source=findchips&utm_content=inv_listing
https://www.arrow.com/en/products/asc8852aete/nxp-semiconductors?utm_campaign=arrow_findchips_2017&utm_medium=aggregator&utm_source=findchips&utm_content=inv_listing
It's also the top 3 are at the end of their life cycle.

This one is a streamer and is priced in the middle and still available WiFi streamer which you might be able to adapt and use:
http://www.averlogic.com/AL582C.asp

I-Frame only compressors:
http://www.microchip.com/wwwproducts/en/OS85623

Everything else is out of your price range.
I mean, 75$ to 500$ per IC, then you need the ram and all the support electronics, + 8 layer PCB & power requirements.

[Bruce Abbott]

I-Frame only compressors:
http://www.microchip.com/wwwproducts/en/OS85623

"Documentation data is currently unavailable." ?!?

[BrianHG]

I-Frame only compressors:
http://www.microchip.com/wwwproducts/en/OS85623

"Documentation data is currently unavailable." ?!?

You need to contact Microchip directly and I believe sign a NDA to get the specs and data sheets.
Don't ask why, but I believe they probably outsourced the IC from another tech firm and just manufacturing the silicon...

[mikeselectricstuff]

As you're looking for "cheap" I assume this is a reasonable volume requirement
There are probably  many obscure chips used in things like cheap drone cameras that record to SD cards, IP cams etc., and I'm sure they will be cheap, but you probably need to be doing significant volume to get hold of them and the data, devtools  etc.

Might be worth looking to see of something like an off-the-shelf IP camera module could be a viable option, assuming your video is coming from a camera to start with

[mrf184]

Thanks for all the suggestions, I should have mentioned the intended application which is live video streaming from an RC airplane. As such the video only need to be comparable to analog video, but latency is important.

As to image quality something similar to jpeg quality 30 is good enough (see attached image.) That image is 33KiB, which at 10fps would give you 2.7Mb/s. If that can be reduced to 1Mb/s it would be a significant improvement. I think to do that requires inter-frame prediction, which necessitates the use of external RAM, so it looks like I can't escape the DRAM problem either way...

I can't solder bga reliably, which all of those multimedia SoC chips seem to be in...

Color or monochrome?

Color is preferred, but if it isn't easily doable monochrome is fine too.

[janekm]

Thanks for all the suggestions, I should have mentioned the intended application which is live video streaming from an RC airplane. As such the video only need to be comparable to analog video, but latency is important.

As to image quality something similar to jpeg quality 30 is good enough (see attached image.) That image is 33KiB, which at 10fps would give you 2.7Mb/s. If that can be reduced to 1Mb/s it would be a significant improvement. I think to do that requires inter-frame prediction, which necessitates the use of external RAM, so it looks like I can't escape the DRAM problem either way...

I can't solder bga reliably, which all of those multimedia SoC chips seem to be in...

Color or monochrome?

Color is preferred, but if it isn't easily doable monochrome is fine too.

I think the best bet is probably to use an action-camera SoC, something like what Anyka make: http://www.anyka.com/en/productInfo.aspx?id=103 or this one with video compression: http://www.anyka.com/en/productInfo.aspx?id=105
You'll have to ask them for the datasheets and SDKs, of course.
They even have LQFP models so not hard to solder at all, and they even have RAM built in.

Alternatively it might be easier to use a ready-made module like this: https://item.taobao.com/item.htm?spm=2013.1.w4023-1274201234.4.56a8a51aOAFkPT&id=553042732589 (designed for IP camera applications).
There's a serial port on it so it may well be possible to get images off that instead of via Ethernet. Framing the video stream for sending over a radio link is challenging, though.

[mrf184]

How much compression are you looking into?
640*480*24bpp=921.6kB, you probably can fit that into 1MB memory of ADSP-BF706. That's a QFN88 chip with 400MHz 32-bit CPU (or 800MMACS for 16 bit, 1600MMACS for 8 bit).
It does NOT have in-memory 556<->888 compression engine, so unfortunately you can't store data in 556 format and process it without consuming CPU cycles to convert it to and from 888 color space.
But it does have 556 to 888 converter as part of ePPI, so you can interface 556 image source/sink without spending CPU cycles on color space compression.
ADI has a BLIP platform for image applications on ADSP-BF7xx, you might be able to get some free code and tech help on their support forum.

I'm looking for ~1Mb/s from a 640x480 10fps video, for image quality see picture in my last reply; it seems that I have to do inter-frame prediction to get that, which means I have to fit at least 2 frames in memory. I haven't found any mcu with that much on-chip ram or support for external sram/psram that don't cost a fortune, so for the diy route it seems only fpga is viable...

From the looks of it the current best options are:
(1) fpga + psram - under $10, but may take significant effort to get a h264 core working as well as adapt it to the psram, or cargo-cult a custom jpeg + inter-prediction compression algorithm which would be similar to h264 but need not be compatible
(2) ip camera from taobao, connected to sbc over ethernet - ~$20 total, hacky, and potential reliability issues

The gm8135 and hi3516cv300 based ip camera modules that are on taobao look interesting, as it looks like they already run linux, but I'm having trouble finding the kernel sources anywhere. It would be really nice to avoid the extra sbc, as that contributes half the cost and most of the reliability problems. Maybe I should buy some of those ip cameras and attempt some hacking.

[janekm]

Another simpler alternative could be using a USB camera module with h.264 encoding support: https://item.taobao.com/item.htm?spm=2013.1.0.0.45d84b1dmglNBU&id=551262654757 with a SBC (apparently h.264 and MJPEG is supported in the USB Video Class). Latency may be an issue though (same for all those IP cameras).

[mikeselectricstuff]

I'm looking for ~1Mb/s from a 640x480 10fps video, for image quality see picture in my last reply; it seems that I have to do inter-frame prediction to get that, which means I have to fit at least 2 frames in memory. I haven't found any mcu with that much on-chip ram or support for external sram/psram that don't cost a fortune, so for the diy route it seems only fpga is viable...

PIC32MZ DA has 32Mbyte of DDR RAM, though FPGA may be better for low-latency as you can pipeline & do multiple processing steps in parallel

[Bruce Abbott]

I should have mentioned the intended application which is live video streaming from an RC airplane.

Is this for FPV?

[Rasz]

I want to target ~$5 to $10

whats the input signal? what output do you want?

for a one off Pee + Pee camera is exactly $10

[mikeselectricstuff]

I want to target ~$5 to $10

In what volume?

[mrf184]

Is this for FPV?

Yes it is 
Current fpv transmitters on the market are mostly analog and either have very short range or transmits a lot of power (meaning consumes a lot of power). Digital fpv transmitters are all focused on HD rather than high range, plus they cost an arm and a leg.

whats the input signal? what output do you want?

for a one off Pee + Pee camera is exactly $10

There are no hard requirements on the input format, just that there be cheap cameras that are supported.
What's this "pee + pee camera" that you speak of? I don't seem to be able to find anything...

In what volume?

<$10 each @ 10pcs
<$20 each @ 1pcs

The allwinner v3s suggested looks very promising; there seems to be available drivers for the video encoder but it requires a binary .so (https://github.com/allwinner-zh/media-codec-lib/tree/master/lib32/lgnueabihf), and is tied to linux kernel 3.4. I'm going to look at it in more detail and see if the software side is workable.

[nctnico]

For these low volumes it doesn't make sense to look for such low parts cost. If you take a job instead of the time you will need to optimise the software for this project you will finish it sooner by buying an off-the-shelve solution. It is a very common mistake to look for low cost parts and not take engineering time into account. As a rule of thumb engineering costs rise exponentially versus the money saved per unit.

[mikeselectricstuff]

In what volume?

<$10 each @ 10pcs
<$20 each @ 1pcs
 
At that volume, the parts cost doesn't matter unless you put near-zero value on your time

[mrf184]

This isn't a one-off, it will most likely be a product sold on aliexpress and could be produced in very high volumes; the 10pcs price of parts is typically only a few percent higher than 1000pcs prices. I anticipate low volumes but have to plan for high volumes as well. Suppose I go with a $50 solution, that means my product has to be priced at least $100, meaning it will be uncompetitive and will have broken no ground. If I solve this problem at $10 and put out a $20 product, that can potentially open up a huge market for these long-range digital FPV transmitters. The extra R&D spent is justified; It IS an investment. However it is imperative that I don't bleed money if the order volume is low; the R&D investment is a done deal but selling items at cost is unacceptable.

For these low volumes it doesn't make sense to look for such low parts cost. If you take a job instead of the time you will need to optimise the software for this project you will finish it sooner by buying an off-the-shelve solution. It is a very common mistake to look for low cost parts and not take engineering time into account. As a rule of thumb engineering costs rise exponentially versus the money saved per unit.

This is assuming that this is a one-time event and that I only care about the ends and not the means, but in practice yes I assign $0 to my time if I'm learning something from it and it is fun work that I care about.

[nctnico]

How about creating a more expensive device first and then optimise when the volumes increase? That way you have a short time to market and you gain knowledge on how to create a cost optimised version based on actual customer feedback.

[Bruce Abbott]

Current fpv transmitters on the market are mostly analog and either have very short range or transmits a lot of power (meaning consumes a lot of power). Digital fpv transmitters are all focused on HD rather than high range,

What range do you want?

[mrf184]

What range do you want?

As far as possible given power limits; if it can be compressed to 1Mb/s it will have ~16dB more link budget than analog video, meaning ~6x the range in line-of-sight conditions with the same transmit power. At legal transmit powers (1W @ 915MHz in NA, 2W @ 923MHz in china) approximately 5km should be possible.