Hardware h264 encoding (S805)

Moderators: mdrjr, odroid

Hardware h264 encoding (S805)

Unread postby crashoverride » Mon Oct 31, 2016 12:17 pm

Experimental support for C0/C1 H264 video encoding is available here:
https://github.com/OtherCrashOverride/c2_vpcodec/tree/S805

Note that /dev/amvenc_avc will need to have permissions adjusted or "sudo" will need to be used:
Code: Select all
sudo chmod a+rw /dev/amvenc_avc


I have tested it with c2enc and noticed there is some occasional glitching in the bitstream. I have not tested it with c2cap yet.
https://github.com/OtherCrashOverride/c2enc

[edit]
Testing has shown that using all I frames (GOP=0) produces a correct bitstream.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Tue Nov 01, 2016 9:20 am

I have been investigating the corruption issue. My understanding of things thus far is as follows. There are three components that must work together for encoding: firmware, kernel driver, and user space. Amlogic changes the user space to kernel driver API over time.

The original kernel driver in the repo apparently used an old API. There was a recent commit that updated it to a new API:
https://github.com/hardkernel/linux/commit/b2d20160196c75996ec7da15db23af6518ac495c
However, it appears this updates it to an API that is too new. Somewhere between the driver version we had and that commit is the version of the API the Amlogic provided libraries target.

It would be helpful to know the origin of the code in that commit.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby svpcom » Tue Nov 01, 2016 7:00 pm

This is a driver from latest android kernel (3.10) for odroid-c1 provided by Hardkernel. Original driver was outdated and didn't work with userspace API for S805 provided by AMLogic.
But new driver has a problem with corrupted x264 stream in case of fast motion. I've done some debugging and found that corruption happens when we go into "reencode" mode. I've compare API fro S905 and S805 and found that
S905 doesn't use reencode. I've backport changes from S905 to S805 API and it became works.

Ported userspace API for S805:
https://github.com/svpcom/codec_c1

Capture client (i've rewrite it from scratch for my purposes):
https://github.com/svpcom/c1cap

My forum post about c1 port.
viewtopic.php?f=116&t=24136&p=165851

crashoverride wrote:I have been investigating the corruption issue. My understanding of things thus far is as follows. There are three components that must work together for encoding: firmware, kernel driver, and user space. Amlogic changes the user space to kernel driver API over time.

The original kernel driver in the repo apparently used an old API. There was a recent commit that updated it to a new API:
https://github.com/hardkernel/linux/commit/b2d20160196c75996ec7da15db23af6518ac495c
However, it appears this updates it to an API that is too new. Somewhere between the driver version we had and that commit is the version of the API the Amlogic provided libraries target.

It would be helpful to know the origin of the code in that commit.
svpcom
 
Posts: 20
Joined: Fri Aug 26, 2016 7:15 pm
languages_spoken: english
ODROIDs: C0

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Tue Nov 01, 2016 9:20 pm

svpcom wrote:I've backport changes from S905 to S805 API and it became works.

The changes were not published before I started looking into this. If the API is now the same for S905 and S805, we should only need a single code path for both. I will investigate further.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Tue Nov 01, 2016 10:25 pm

I tested that using the master branch of c2_vpcodec instead of the S805 branch produces a good bitstream. Bitrate settings did affect the size of the output; however, I did not confirm they are correct. If someone has the time, I would appreciate their confirming these findings.

TL;DR = for S805 just use the regular c2_vpcodec. No changes are required.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Wed Nov 02, 2016 4:21 am

A branch of c2cap is now available for the c1:
https://github.com/OtherCrashOverride/c2cap/tree/c1

It requires two kernel patches to work properly:
https://github.com/OtherCrashOverride/l ... 3d56246584
https://github.com/OtherCrashOverride/l ... 4dc5f642e8

I tested it with the master branch of c2_vpcodec compiled on the c1:
https://github.com/OtherCrashOverride/c2_vpcodec

Note that the C1 Cortex-A5 is not as fast as the Cortex-A53 in the C2. This affects MJPEG performance since software libjpeg-turbo is used. Only 10-13 fps were achieved with 1280x720.

I should also note that the Odroid camera exhibits the same problems on C1 as it does on C2.

[edit]
Pull request for the patches is here:
https://github.com/hardkernel/linux/pull/247
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby MartinRi » Thu Nov 03, 2016 12:20 am

The reason for the corrupted stream with the s805 branch is the enabled reencoding in combination with prepending of SPS/PPS data to each IDR-Frame.

When using S905 encoder code (gx_enc_fast) only every gop+1 frames will be an IDR-Frame, all the frames inbetween will be P-Frames only - even if an IDR-Frame would be smaller.
With the S805 encoder code (m8_enc_fast) every gop+1 frames will be an IDR-Frame, the other frames will be encoded to P-Frames or - when they take 1.2 times more space than the last IDR-Frame - they are reencoded to IDR-Frames.

Reencoding reduces the size of the data produced by the encoder but takes additional time - so it probably depends on the use case (online/offline encoding) whether size or throughput is the priority.

The corruption occurs because of the way the SPS/PPS gets prepended to each IDR-Frame:
In https://github.com/OtherCrashOverride/c ... c.cpp#L159 the needed space gets reserved on the buffer and in https://github.com/OtherCrashOverride/c ... c.cpp#L181 the data is copied.
The first part depends on the return value of AML_HWSetInput == AMVENC_NEW_IDR, the latter on the type of the NAL produced by AML_HWEncNAL being equal to AVC_NALTYPE_IDR.
AML_HWSetInput only returns AMVENC_NEW_IDR for a) the first frame, b) for every gop+1 frames or c) when forced by some flag value.
But the type of the NAL produced by AML_HWEncNAL is (because of the reencoding) often not as predicted by AML_HWSetInput.
Therefore no space gets reserved on the buffer but the SPS/PPS data is copied anyway which overwrites the first bits of the IDR-Frame.

ffmpeg now reports "Truncating likely oversized PPS" because it can't find the start of the following IDR-Frame and expect it to be still PPS data.
Following P-Frames are now missing their real reference frame and produce bogus values.


A quick and dirty fix to be able to use m8_enc_fast (with reencoding) could be something like https://github.com/MartinRi/c2_vpcodec/ ... 5770f5ee19.
(When repeating the SPS/PPS data is not needed - e.g. when not streaming - one could just try to revert https://github.com/svpcom/codec_c1/blob ... achI.patch.)
MartinRi
 
Posts: 2
Joined: Wed Oct 26, 2016 6:18 pm
languages_spoken: english
ODROIDs: C1+

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Thu Nov 03, 2016 3:15 am

Thanks for analysis of the issue. The question now is are there any advantages to maintaining the "m8_enc_fast" code path? The only thing I saw in the code that was actually m8 specific was inline asm used for color space conversion:
https://github.com/OtherCrashOverride/c ... p#L41-L118

Since the libvpcodec API only accepts NV12, those code paths are never used. This affords the advantage of having a single code path because "gx_enc_fast" does not use inline asm:
https://github.com/OtherCrashOverride/c ... p#L42-L114

We still need to run some tests comparing the bitstream output using controlled input with c2enc. Ideally, the same input should produce the same output on C1 and C2 when parameters (gop, bitrate) are identical. I would like to test against the "m8_enc_fast" code path too.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby MartinRi » Thu Nov 03, 2016 7:10 am

It looks like the image format is currently hardcoded to AMVENC_NV21 in vl_video_encoder_encode - the img_format argument of vl_video_encoder_init is never used.
But after changing https://github.com/OtherCrashOverride/c ... c.cpp#L139 to AMVENC_RGBA8888 and modifying https://github.com/OtherCrashOverride/c ... #L108-L109 to
Code: Select all
int bufferSize = width * height * 4;
I was able to successfully execute (using the libvpcodec from s805 branch with my fix):
Code: Select all
ffmpeg -i ~/trailer_1080p.mov -an -f rawvideo -pix_fmt rgba - | ./c2enc -w 1920 -h 1080 -f 25 -b 2000 > trailer.h264
MartinRi
 
Posts: 2
Joined: Wed Oct 26, 2016 6:18 pm
languages_spoken: english
ODROIDs: C1+

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Thu Nov 03, 2016 8:10 am

The preferred method for color space conversion, particularly on Cortex-A5 (S805), is to use GE2D hardware acceleration instead of the CPU:
https://github.com/OtherCrashOverride/c ... #L607-L657

[edit]
The code is also portable between S805 and S905 and does not require re-writing as NEON asm does.

[edit 2]
Fix broken link

Added time stamp support to c2cap c1 branch. New command line option "-t" will overlay date/time text on captured video.

[edit 3]
c2cap c1 branch merged with beta1. Both C1 and C2 will now share the same code.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby odroid » Thu Nov 10, 2016 9:16 am

crashoverride wrote:Pull request for the patches is here:
https://github.com/hardkernel/linux/pull/247


It has been merged and released (-174) :)
https://github.com/hardkernel/linux/com ... 91e0b6f312
User avatar
odroid
Site Admin
 
Posts: 28610
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Hardware h264 encoding (S805)

Unread postby Pitrson » Thu Nov 10, 2016 6:14 pm

Great ! Thansk a million, will give it a try and let you know. Was waiting for this as I have C1 and XU4 only, so no reason to buy C2 8-)
Thanks.
Pitrson
 
Posts: 53
Joined: Mon Jan 18, 2016 11:16 pm
languages_spoken: english, slovak
ODROIDs: Odroid C1, XU4

Re: Hardware h264 encoding (S805)

Unread postby svpcom » Sat Nov 12, 2016 8:04 pm

Hi,
I've found that current rate control code (rate_control_gx_fast.cpp) doesn't drop frames if unable to increase QP (maximum supported 51).
For example bitrate became too high ( > 10Mbp/s) if I try to encode PAL (720x576) without input signal (i.e. show screen). According to amlogic sources
last working rate control code with frame drop exists only for m6 (m6_enc/rate_control.cpp) but code for S805/S905 has broken frame drop support.
Do you have any ideas how to fix this?


crashoverride wrote:The preferred method for color space conversion, particularly on Cortex-A5 (S805), is to use GE2D hardware acceleration instead of the CPU:
https://github.com/OtherCrashOverride/c ... #L607-L657

[edit]
The code is also portable between S805 and S905 and does not require re-writing as NEON asm does.

[edit 2]
Fix broken link

Added time stamp support to c2cap c1 branch. New command line option "-t" will overlay date/time text on captured video.

[edit 3]
c2cap c1 branch merged with beta1. Both C1 and C2 will now share the same code.
svpcom
 
Posts: 20
Joined: Fri Aug 26, 2016 7:15 pm
languages_spoken: english
ODROIDs: C0

Re: Hardware h264 encoding (S805)

Unread postby nmadrane » Mon Dec 12, 2016 5:47 am

Hi,

I am trying to integrate this hardware encoder into mediastreamer (which is the media framework of linphone). MediaStreamer already has 2 filters for software H264 encoding : one based on libX264 and one based on OpenH264. I just took one of them, deleted all software encoding stuff and called the Amlogic hardware encoder by using the library from :

https://github.com/OtherCrashOverride/c2_vpcodec

The ultimate goal is to have linphone integrated into the box (libreelec), so that I can start video conferences between the box and any other SIP phone. Everything seems to be ok. The encoding starts, it generates a H264 bitstream. I am continuously encoding the same image, just for testing :

test1.jpg
The image used as the input for the encoder
(23.19 KiB) Downloaded 977 times


I am absolutely sure that the H264 bitstream from the hardware encoder is good. I converted it to MOV with ffmpeg and the result is perfect.

The problem is with the RTP transmission. The bitstream has to be split into NAL units. MediaStreamer already has a function for that.

Code: Select all
int outCnt = vl_video_encoder_encode(handle, type, in, in_size, &out);   // perform hardware encoding (i am sure that "out" contains valid H264 data)
ms_h264_bitstream_to_nalus((unsigned char*)out, outCnt, &nalus);         // split into NAL units and store in a queue
rfc3984_pack(packetizer, &nalus, f->outputs[0], timestamp);                 // pack


But the produced NALs are too big for the max UDP MTU size. The RFC3984 packetizer included in MediaStreamer supports mode 0 (no split) and mode 1 (split).

When I use mode 0, it gives warnings about the size of NALs. This is normal, since my MTU is about 1300 and the NAL sizes are about 18 KB to 22 KB for I-Frames, and something like 3 or 4 KB for the others frames. Playing at the other end with a softphone gives a strange result. The top half of the image is ok. The bottom one is corrupt :

output.rar
The video as it is received at the other end, on a softphone
(31.56 KiB) Downloaded 105 times


(please note that the image is flipped down and the color are interpreted as RGB instead of BGR but this is not a big deal, I just have to adjust my RGB->NV12 conversion code).

When I use mode 1, I have a black screen.

I am testing on a LAN, there is only one router/hub between the box and the softphone. I tried several softphones at the receiver end :

With eyebeam, I have the half-frame corruption problem
With jitsi, no video at all (just black screen)
With linphone, no video at all (just black screen)

Do you think my problem is due to fragmentation ? Maybe the softphones I am using do not support packet-mode 1.
Is it possible to tell the hardware encoder what is the max NAL unit size ? That way I could give him the size of my MTU (which is I thing 1300) and force him to give me small NAL units.

I really don't understand why the bottom half of the movie is moving from left to right. It repeats over and over after 10 frames. 10 is the GOP size that I used for encoding. The input image is always the same (I am continuously encoding the same picture), so the output should be a fixed image...
nmadrane
 
Posts: 1
Joined: Mon Dec 12, 2016 1:22 am
languages_spoken: english, french

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Mon Dec 12, 2016 9:31 am

Make sure the bitstream format matches what your library expects. If I recall correctly, the bitstream format output by the hardware H264 encoder is Annex B format. You can use a H264 bitstream analyzer to gain more insight.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby schmidtbag » Thu Sep 14, 2017 11:03 am

I don't meant to necropost, but I'm very interested in trying to get this to work. I have the S805 build for c2enc and c2_vpcodec installed, but I don't really understand how to use it [properly].

I'm trying to do live 720p or 1080p 30FPS recording to a file with as little CPU usage as possible, while still compressing the video. I can't figure out how to use c2enc properly.
schmidtbag
 
Posts: 52
Joined: Sat Mar 30, 2013 10:19 am
languages_spoken: english
ODROIDs: U2 and C1

Re: Hardware h264 encoding (S805)

Unread postby mad_ady » Thu Sep 14, 2017 2:00 pm

Here's how I'm creating a hw encoded video from a series of pictures:
Code: Select all
/usr/bin/ffmpeg -r $FPS -i ./${BASE}-%*.jpeg -an -c:v rawvideo -r $FPS -pix_fmt nv21 -f rawvideo - | /usr/local/bin/c2enc -w $WIDTH -h $HEIGHT -f $FPS -b $BANDWIDTH | /usr/bin/ffmpeg -r $FPS -thread_queue_size 256 -f h264 -i - -an -c:v copy "$NFS/Webcam2-movies/$DATE/${BASE}-${DATE}.mp4"
User avatar
mad_ady
 
Posts: 4450
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: Hardware h264 encoding (S805)

Unread postby titody » Wed Feb 28, 2018 6:40 am

What setup works in reduce size of video (not resolution)? I try with bitrate but I dont understand bitrate in c2enc ... in ffmpeg , I use v:b 250k and the video lowers to that.
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby mad_ady » Wed Feb 28, 2018 1:27 pm

c2enc uses -b 250000 to do the same thing
User avatar
mad_ady
 
Posts: 4450
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: Hardware h264 encoding (S805)

Unread postby titody » Sun Mar 04, 2018 2:48 pm

mad_ady wrote:c2enc uses -b 250000 to do the same thing


Test it , but always gives 1200kbs and the output same size . Where its the problem? I want to make the video lower megabytes than the original.
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Tue Mar 06, 2018 12:12 am

schmidtbag wrote:I have the S805 build for c2enc and c2_vpcodec installed


Use the master branch:
crashoverride wrote:I tested that using the master branch of c2_vpcodec instead of the S805 branch produces a good bitstream. Bitrate settings did affect the size of the output; however, I did not confirm they are correct. If someone has the time, I would appreciate their confirming these findings.

TL;DR = for S805 just use the regular c2_vpcodec. No changes are required.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby titody » Fri Mar 16, 2018 2:08 pm

Use the master branch:


I use master branch but I cant reduce bitrate of videos only goes higher than the original.
I input a video of 657kbs bitrate and output goes to 2000...kbs , and the output video is bigger that the orginal .

Where I have to look for get my objective of lower the bitrates?
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Sat Mar 17, 2018 2:21 am

titody wrote:I input a video of 657kbs bitrate and output goes to 2000...kbs , and the output video is bigger that the orginal .

What is the exact command line you are using?
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby titody » Sat Mar 17, 2018 9:34 am

Code: Select all
What is the exact command line you are using?


ffmpeg -v warning -i "$r" -an -f rawvideo -pix_fmt nv21 - | c2enc -w $a -h $b -f 25 -b 250000 -g 0 | ffmpeg -r 25 -i - -i "$r" -c:v copy -map 0:v:0 -map 1:a:0 -c:a copy $nn.mkv

variable a and b I enter manually for match the same as input.

If original video have 600..kbs then suppose to have 250kbs aprox..?
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Sat Mar 17, 2018 12:13 pm

Increase the value of the "-g 0" argument. Using a "0" value means that all frames are I-Frames which are full frames. Try values of 10 or higher.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby titody » Tue Mar 20, 2018 3:56 am

crashoverride wrote:Increase the value of the "-g 0" argument. Using a "0" value means that all frames are I-Frames which are full frames. Try values of 10 or higher.

Reduce a little bit . I want 250k, not goes down to that .

I found that it works fine if I put higher bitrates and goes up to the number .

What are the uses of this prog , in how many form I can use it??
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Tue Mar 20, 2018 5:49 am

The c2enc options are shown here:
https://github.com/OtherCrashOverride/c ... pp#L20-L24
Code: Select all
   { "width",         required_argument,   NULL,   'w' },
   { "height",         required_argument,   NULL,   'h' },
   { "fps",         required_argument,   NULL,   'f' },
   { "bitrate",      required_argument,   NULL,   'b' },
   { "gop",         required_argument, NULL,   'g' },


width and height must match the image being used including any stride.
fps, bitrate, and gop (group of pictures) are used internally by the encoder library (not c2enc) to adjust the bitstream to maintain the desired bitrate.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby titody » Sat Mar 24, 2018 2:19 pm

width and height must match the image being used including any stride.
fps, bitrate, and gop (group of pictures) are used internally by the encoder library (not c2enc) to adjust the bitstream to maintain the desired bitrate.


Why q= or quality always on -1 ?

I still trying to get a low bitrate but its impossible. I had used the rpi omxtx concept tool and give fast results of reduce size but only works with some codecs . But the c2enc you made its works with any codec as input , but not do the job well.
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Sun Mar 25, 2018 9:05 am

titody wrote:Why q= or quality always on -1 ?

There is no "q" or "quality" parameter to c2enc. I am uncertain what is being asked.

c2enc is a "front end" to the hardware codec library. c2enc does not perform any compression itself. It only passes data to the hardware codec API. The amount of compressions depends on the source data and parameters provided and the hardware codec. For a lower bitrate, reduce the video frame size, frame rate, or both.

The hardware codec is a "realtime" encoder. This means it only produces "I" and "P" frames. Because it does not produce "B" frames, it can not compress as aggressively as an 'non realtime' encoder.
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby titody » Tue Mar 27, 2018 2:12 am

c2enc is a "front end" to the hardware codec library. c2enc does not perform any compression itself. It only passes data to the hardware codec API. The amount of compressions depends on the source data and parameters provided and the hardware codec. For a lower bitrate, reduce the video frame size, frame rate, or both..


What will be the command line if I want to reduse frame size , all in the same c2enc pipe ?
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby crashoverride » Tue Mar 27, 2018 7:33 am

c2enc does not perform any scaling. However, ffmpeg does and is described here:
https://trac.ffmpeg.org/wiki/Scaling
crashoverride
 
Posts: 3918
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Hardware h264 encoding (S805)

Unread postby titody » Tue Mar 27, 2018 11:36 am

crashoverride wrote:c2enc does not perform any scaling. However, ffmpeg does and is described here:
https://trac.ffmpeg.org/wiki/Scaling



Ok , what I want to know is how I use the hw accelerated c2enc inside the ffmpeg pipe for make process more faster?

I am just trying to find some use for c2enc ...
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english

Re: Hardware h264 encoding (S805)

Unread postby mad_ady » Tue Mar 27, 2018 12:57 pm

There are two examples of ffmpeg + c2enc/c2cap in this tutorial: viewtopic.php?t=23503. It doesn't do scaling, but it could be added in the first ffmpeg command.
User avatar
mad_ady
 
Posts: 4450
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: Hardware h264 encoding (S805)

Unread postby titody » Mon Apr 09, 2018 5:04 am

Someone have used c2enc and make a video of less than 1000kb/s bitrate??
titody
 
Posts: 19
Joined: Sat Sep 16, 2017 2:45 am
languages_spoken: english


Return to Ubuntu

Who is online

Users browsing this forum: No registered users and 2 guests