I recently bought Reolink RLC-410. It's almost perfect consumer grade camera and I've managed to record it's RTSP stream using raspberry running OpenWrt and ffmpeg4.
But unfortunately it only supports H264 and there are already H265 cameras on the market, like this one.
However my question is, if it is even possible to record H265 stream with ffmpeg on Raspberry Pi Model B (first generation) running on OpenWrt. And if so, what are the requirements? For example, will I need patched ffmpeg with H265 support? I don't mind upgrading Raspberry Pi to 4th generation, if it helps with H265. Or should I rather stick with proven camera and H264?
I'm asking because, from experience with H264 recording, which required libx264 and ffmpeg4, even though I'm not transcoding stream (libx264 seem to be required for dimension detection, otherwise video stream was not recorded).
Is this from a pure technology standpoint or do you really have space issues?
It should be possible to record H.265/HEVC however at best remuxing as the RPI will be way too slow to transcode unless you can live with like 1-2 FPS however given the design of the SoC such as ethernet hanging off USB etc it's not ideal and adds overhead.
Unless you have hardware acceleration working ARM HEVC is pretty much out of the question unless you have a server SoC or possibly the new Khadas VIM3 although none are supported by OpenWrt. In terms of support RK3399 is your best bet but you'll still need to look at another distribution and you'll still be looking at like 4-5 FPS or so (estimated) at 720p.
libx265 isn't ported to OpenWrt so you'll need to do that first, you can use Alpine and Arch Linux packages as templates.
Probably more from technology standpoint, since I do recording on raspi, space is not a concern for the moment (I can plug large hdd).
Since I'm not sure about reliability of stream recording, I'm also considering recording on sdcard. I already see some issues, like there can be only one stream consumer, since camera is only 100Mbit.
It should be possible to record H.265/HEVC however at best remuxing as the RPI
This is exactly my biggest concern. So thank you for leads here. I thought that maybe Raspberry Pi 4 has HEVC acceleration. I know, that is only hw decoding, but isn't that enough for storing H265 streams (I don't need to transcode them)?
USB is going to be more reliable than SD card, period. While I'm not sure about the bitrate HEVC saves about 30% of space (bitrate) at the same visual quality given that you can adjust the bitrate accordingly.
I don't know how much you can play around with the settings in the camera with but lets say your stream runs at 5Mbit, that would mean 24h of video footage would end up at 54000 Mbyte which is quite a lot for security footage.
However, 720p @ 5-10 fps should be doable in H264 with 1-2Mbit if the image is fairly clean which would result in 21600Mbyte (2Mbit) per day which is still quite a lot. A quad-core ARM64 SoC should be able to handle transcoding however (I can do some testing later).
Any type of hardware encoding means using vendor provided software more or less so, it all depends on what your requirements are.
you mean ethernet (LAN), right?
You mean USB storage connected to camera?
Regarding stream size, I can play quite bit with camera settings. Apart from changing resolution, which doesn't seem to be allowed lower than 2304x1296, I can change H264 profile (High, Main, Baseline) and bitrate (from 8192 down to 1024).
But this discussion, made me think about my real requirements. First I was thinking that I would record continuously all day, but after some thinking I made conclusion that nobody would actually watch the whole day stream to find some suspicious activity. So I rather set motion triggers, that will record 5 min. video after the motion is detected (and also sent PUSH message and email). For this short videos I don't think I'll bother with H265. Event though from technological POV it would be nice to have.
Realistically, as a commercial CCTV installer, I can share the following thoughts on this:
a) Motion based recording VS constant recording is pretty much the norm these days. Some applications require full continous recording, but for most "premise security" solutions all it does is give you more raw data that you have to jog through in order to find what you're actually after. On the other hand, if you really want to watch the baby bunnies in the back yard motion detection might not be sensitive enough (depends on your camera and how well they implement the detection)
b) IF you really want continuous recording, H265 will save you storage space. However for a single camera it's probably not really worth while as HDDs are cheap. Computationally it does not even begin to make sense to try and transcode H264 to H265. Modern commercial cameras have the H265 encoding hardware built into them and allow the output stream to be sent in that format.
c) The reason the CCTV industry is beginning to implement H265 is because once you get into 8 or 16 channel recording with 5MP or greater the extra costs of the H265 hardware in the cameras offsets the additional HDDs you'd need to do it all in H264. Realistically it's all about volume of data, and in a single or even 4 camera setup unless you've spent the money to get cameras with the encoding built in you're not going to care, just go add another HDD and be done with it.
No, the board itself...
Anyhow, this is tested on a Orange Pi PC 2 (Allwinner H5 @ 816Mhz, Quad Cortex A53) and you really need quite a bit more processing power to do transcoding. The board is running FreeBSD but it should give you an idea, do note that this build isn't aggressively optimized (O2) but it shouldn't affect performance that much.
youtube-dl -f 299 "https://www.youtube.com/watch?v=Xvz_NR44K58"
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '4K_The_Arrival_of_a_Train_to_Shimo-imaichi_-_SL_train_in_Nikko-Xvz_NR44K58.mp4':
major_brand : dash
minor_version : 0
creation_time : 2017-09-09T19:51:15.000000Z
Duration: 00:03:23.20, start: 0.000000, bitrate: 4943 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 96 kb/s, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc (default)
creation_time : 2017-09-09T19:51:15.000000Z
handler_name : VideoHandler
mv 4K_The_Arrival_of_a_Train_to_Shimo-imaichi_-_SL_train_in_Nikko-Xvz_NR44K58.mp4 sample.mp4
ffmpeg -i sample.mp4 -c:v libx264 -profile:v high -level 4.1 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M -filter:v fps=fps=10 1080p-1M-10fps.mp4
frame= 2032 fps=1.6 q=-1.0 Lsize= 24855kB time=00:03:22.90 bitrate=1003.5kbits/s speed=0.16x
video:24828kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.106813%
ffmpeg -i sample.mp4 -c:v libx264 -profile:v main -level 3.1 -x264-params "nal-hrd=cbr" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M -filter:v fps=fps=10 1080p-1M-10fps-lvl3.mp4
frame= 2032 fps=1.8 q=-1.0 Lsize= 24855kB time=00:03:22.90 bitrate=1003.5kbits/s speed=0.176x
video:24829kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.106845%
ffmpeg -i sample.mp4 -c:v libx264 -profile:v main -level 3.1 -preset fast -x264-params "nal-hrd=cbr" -b:v 1.5M -minrate 1.5M -maxrate 1.5M -bufsize 3M -filter:v fps=fps=10 1080p-1_5M-10fps-lvl3.mp4
frame= 2032 fps=1.8 q=-1.0 Lsize= 37261kB time=00:03:22.90 bitrate=1504.4kbits/s speed=0.177x
video:37234kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.071470%
ffmpeg -i sample.mp4 -c:v libx264 -profile:v main -level 3.1 -preset veryfast -x264-params "nal-hrd=cbr" -b:v 1.5M -minrate 1.5M -maxrate 1.5M -bufsize 3M -filter:v fps=fps=10 1080p-1_5M-10fps-lvl3-vfast.mp4
frame= 2032 fps=2.9 q=-1.0 Lsize= 37282kB time=00:03:22.90 bitrate=1505.2kbits/s speed=0.287x
video:37256kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.069232%
ffmpeg -i sample.mp4 -c:v libx265 -crf 28 -filter:v fps=fps=10 1080p-crf28-10fps-hevc.mp4
frame= 2032 fps=0.3 q=-0.0 Lsize= 32213kB time=00:03:22.90 bitrate=1300.6kbits/s speed=0.0304x
video:32185kB audio:0kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.087786%
Visually all are acceptable however you can notice a difference in quality changing profile from normal to fast/very fast but that's expected.