Orange Pi RK3399: HDMI recording on a budget // Review

#1

Originally published at: https://www.mickmake.com/post/orange-pi-rk3399-hdmi-recording-on-a-budget-review

image
The Orange Pi RK3399 is yet another board to join the ranks of RockChip RK3399 based SBCs. In true Orange Pi fashion, they give you everything, but is this SBC worth it? Continue reading Orange Pi RK3399: HDMI recording on a budget // Review

#2

Nice review, thanks a lot. I bought one after watching it.
As you have several RK3399 boards, would you have a recommandation for a heatsink/fan combo?
I think this board doesn’t have any specific plug for a fan, but I guess we could do something with the GPIO.

1 Like
#3

I really need to do a review on heatsinks. I don’t have a particular suggestion.

1 Like
#4

Thanks. And regarding the camera for this one, which one would you use?
I flashed the HDMI-IN image under Windows today, and the tool wrote things in Chinese, but I also saw 100%.
I started the board with an USB-C charger (which worked beforehands with the flashed Android), but I didn’t get any HDMI output.
I guess the Linux tool only works for X86 machines? I only have ARM Linux machines or X86 virtual machines.
As for now, my board is stuck in “MASKROM” mode. :roll_eyes:
What UART2USB would you use with this one?
Thanks.

1 Like
#5

I’ve used the uArt in the past. It provides a full galvanic isolation for the UART port, but pretty much every USB to UART PCB.

1 Like
#6

Can this board handle 4 CCTV Cameras (in terms of video processing)!?

1 Like
#7

Is a fan supported? Do we have to plug it on +5V/GND, or can we use a third cable to control the fan?

1 Like
#8

I’ve errors on capturing HDMI-IN, running your ffmpeg commands, give me two errors:
[video4linux2,v4l2 @ 0xab160250] The driver does not permit changing the time per frame
[video4linux2,v4l2 @ 0xab160250] Time per frame unknown

Do you known some of this errors?
Am I using a wrong driver or something?

Tanks…

1 Like
#9

I also have that kind of errors, but I get a video nonetheless…
Mike, it looks like during the test you used the FriendlyArm camera.
Did you manage to get the camera capture to work with the HDMI-IN image?
I finally managed to write the HDMI-IN image to the eMMC.
Thanks.

1 Like
#10

I doubt it can. I believe that the the four /dev/video* interfaces are alternate interfaces for the HDMI out and HDMI out/in, but in terms of processing, possibly can.

Yes, I saw those errors as well. I ignored them and still managed to get a recording. From memory, when setting 60fps recording it came up with those errors.

Oh nice! As an aside… The FriendlyARM way of doing it is so much better.

1 Like
#11

Adding up

Managed do run by compiling ffmpeg from source with some flags (may create a tutorial somewhere)

In my use case I have to stream ultrasounds live (hls, 30s delay is acceptable), for that, I need to mirror hdmi in to hdmi out and transmux hdmi in into .m3u8 and .ts files while uploading directly to s3, achieved that with the following scripts:

Mirroring the screen:

Hiding banners and logs -hide_banner -loglevel quiet capturing from hdm in -i /dev/video0 and sending rawinput -pix_fmt bgra -f fbdev to hdmi out /dev/fb0

#!/usr/bin/env sh
ffmpeg \ 
-hide_banner -loglevel quiet \
-i /dev/video0 \
-pix_fmt bgra \
-f fbdev \ 
/dev/fb0

Transmuxing hdmi in to hls:

Capturing with resolution -s 1280x720 at rate -r 60 (suporting old ultrasounds, and acceptable for my use case), capturing pixel format from yuv -pix_fmt nv12 to remove green efect, capturing from hdmi in -i /dev/video2 changing rate to 24 -r 24, using codec libx264 -vcodec libx264 with a small bitrate 700k -b:v 700k (acceptable for my use case), removing frames with same timestamp -vsync 2, forcing yuv420p pixel format -pix_fmt yuv420p (suported by most), with low level compression rate -preset superfast, using .m3u8 lists with 12 .ts files with 3s each -f hls -force_key_frames "expr:gte(t,n_forced*3)" -hls_time 3 -hls_list_size 12 -hls_flags delete_segments and saving files on folder /mnt/hls/stream.m3u8

#!/usr/bin/env sh 
ffmpeg \
  -f v4l2\ 
  -r 60 \
  -s 1280x720 \
  -pix_fmt nv12 \
  -i /dev/video2 \
  -r 24 \
  -vcodec libx264 \
  -b:v 700k \
  -vsync 2 \
  -pix_fmt yuv420p \
  -preset superfast \
  -acodec aac \
  -strict -2 \
  -f hls \
  -force_key_frames "expr:gte(t,n_forced*3)" \
  -hls_time 3 \
  -hls_list_size 12 \
  -hls_flags delete_segments \ 
  /mnt/hls/stream.m3u8
2 Likes
#12

That’s impressive, kudos!
I would L-O-V-E to read a tutorial on how to recompile ffmpeg from source on this machine, because I failed…
Did you notice higher performance with your recompiled version?
Thanks.

1 Like
#13

Hi,

Did you use micro SATA to SATA cable to test HDD? If so can you please share cable details?

Thanks!

1 Like
#14

I haven’t tried mSATA (btw, is it really mSATA, not mpcie?), but just SATA, with an SSD.
The cable I used is this one: [https://www.amazon.fr/gp/product/B019LJBK4K/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1](http:// SATA cable for Banana Pro and Banana Pi )