PSA: Using VAAPI to accelerate H.264 and HEVC encode on Intel-based hardware on Linux
1,658 views
Skip to first unread message
Dennis Mungai
Jun 27, 2016, 1:41:13 PM6/27/16
to Nairobi Linux Users Group
Hello, brethren, and glorious members of the master race!
As it turns out, we have a new release of FFmpeg (version 3.1 released
earlier today) that supports full H.264 and HEVC encode in VAAPI on
supported hardware that works reliably well to be termed
"production-ready".
What does this mean, brethren?
It means that when you're encoding content for use with your blogs or
some fancy youtube download, you can do it much, much faster on
hardware with lower processor utilization (so you can multi-task) ,
lesser heat output and, as a plus, is significantly faster (As tested
on my end, ~8.7x for 1080p and ~4.2x for 4k encodes with reference
media) compared to a pure, software-based approach as offered by
libx264 and similar implementations. Win, yes?
Here goes:
First, you will need to build ffmpeg (and libav, if you swing that
way) with appropriate arguments. --enable-vaapi switch should be
enough, though.
Here are my build options (Note that I load ffmpeg and libav via the
module system):
FFmpeg's configuration switches used:
./configure --enable-nonfree --enable-gpl --enable-version3
--enable-libass --enable-libbluray --enable-libmp3lame
--enable-libopencv --enable-libopenjpeg --enable-libopus
--enable-libfaac --enable-libfdk-aac --enable-libtheora
--enable-libvpx --enable-libwebp --enable-opencl --enable-x11grab
--enable-opengl --cpu=native --enable-nvenc --enable-vaapi
--enable-vdpau --enable-ladspa --enable-libass --enable-libgsm
--enable-libschroedinger --enable-libsmbclient --enable-libsoxr
--enable-libspeex --enable-libssh --enable-libwavpack --enable-libxvid
--enable-libx264 --enable-libx265 --enable-netcdf --enable-openal
--enable-openssl --enable-cuda --prefix=/apps/ffmpeg/git --enable-omx
Libav's configuration switches used:
./configure --prefix=/apps/libav/11.7 --enable-gpl --enable-version3
--enable-nonfree --enable-runtime-cpudetect --enable-gray
--enable-vaapi --enable-vdpau --enable-vda --enable-libmp3lame
--enable-libopenjpeg --enable-libopus --enable-libfaac
--enable-libfdk-aac --enable-libtheora --enable-libvpx
--enable-libwebp --enable-x11grab --cpu=native --enable-vaapi
--enable-vdpau --enable-libgsm --enable-libschroedinger
--enable-libspeex --enable-libwavpack --enable-libxvid
--enable-libx264 --enable-libx265 --enable-openssl --enable-nvenc
--enable-cuda --enable-omx
Then run make and make install to build and install the toolkits respectively.
(These are for reference only, a useful FFmpeg build will require you
to install appropriate dependencies for some build options as suited
to your environment and platform. Modify as needed)
When done, you may then create and load the appropriate environment
modules for both ffmpeg and libav as your choices go. Don't load both
at the same time, though :-)
Now, we get to the interesting bits:
Encoding with VAAPI :-)
You'll notice that we pass several arguments to ffmpeg as indicated below:
ffmpeg -loglevel debug -vaapi_device /dev/dri/renderD128 -i "input
file" -vf 'format=nv12,hwupload' -map 0:0 -map 0:1 -threads 8 -aspect
16:9 -y -f matroska -acodec copy -b:v 12500k -vcodec h264_vaapi
"output file"
Let's break down these arguments to their meaning:
(a) .-loglevel tells ffmpeg to log ffmpeg events as debug output. This
will be very verbose, and is completely optional. You can disregard
this.
(b). -vaapi_device: This is important. You must select a valid VAAPI
H/W context device to which you will upload textures to via hwupload,
formatted in the NV12 colorspace. This points to a /dev/dri/render*_
file on your Linux system.
(c). -vf : This is an inbuilt ffmpeg option that allows you to specify
codec options/arguments to be passed to our encoder, in this case,
h264_vaapi (Remember, we built this when we passed --enable-vaapi at
the configuration stage). Here, we tell ffmpeg to convert all textures
to one colorspace, NV12 (As it's the one accepted by Intel's QuickSync
hardware encoder) and to also use hwupload, an ffmpeg intrinsic, that
tells the program to asynchronously copy said textures to the GPU's
hardware surfaces created by VAAPI. Fun, right?
(d). - threads : Specifies the number of threads that FFmpeg should
use. By default, use the number of logical processors available on
your processor here. On Intel processors that support Hyperthreading,
multiply the number of cores your processor has by 2.
(e). -f : Specifies the container format specification you can use.
This can be Matroska, webm, mp4, etc. Take your pick (as per your
container constraints).
(f). -acodec: Specifies the audio codec to use when transcoding the
video's audio stream. In the example given above, we use ffmpeg's
muxers to copy the audio stream as is, untouched.
(g), -vcodec: Selects the video encoder to use. In this case, we
selected h264_vaapi, our key point of interest here.
The other arguments are pretty standard to FFmpeg and need no introduction :-)
If all well according to plan, your video file should be encoded to
H.264, muxed into the selected container and be done with.
Attached are a few screenshots from my system with statistics and
other fun stuff :-)
Enjoy.
Tranquilo, amigos!
Attachments:
1. ffmpeg_libva_hwenc_h264.png: Shows ffmpeg doing its' stuff.
2. htop_stats.png: htop screenshot. Note the CPU utilization, running
two parallel encodes in QuickSync mode, one 1080p and one 4k encode.
3. i7z_coreclocks.png: Shows processor clocks and statistics during
the encode. Compare that to idle_states_hsw.png data.
4. idle_stats_hsw.png: Intel's powertop's idle stats, see numbers for
both processor cores and the GPUs. QuickSync 's power efficiency is
demonstrated here. While in use, the core RAPL package can enter CC3
mode as the GPU's "turbo" and power state go up thanks to Intel's
Intelligent Power Sharing driver (ips module).
5. powerstate_gpgpu.png: Here, you can see Intel's Haswell IGP power
state mappings on full load from the QuickSync transcode in hardware,
thanks to VAAPI.
As it turns out, we have a new release of FFmpeg (version 3.1 released
earlier today) that supports full H.264 and HEVC encode in VAAPI on
supported hardware that works reliably well to be termed
"production-ready".
What does this mean, brethren?
It means that when you're encoding content for use with your blogs or
some fancy youtube download, you can do it much, much faster on
hardware with lower processor utilization (so you can multi-task) ,
lesser heat output and, as a plus, is significantly faster (As tested
on my end, ~8.7x for 1080p and ~4.2x for 4k encodes with reference
media) compared to a pure, software-based approach as offered by
libx264 and similar implementations. Win, yes?
Here goes:
First, you will need to build ffmpeg (and libav, if you swing that
way) with appropriate arguments. --enable-vaapi switch should be
enough, though.
Here are my build options (Note that I load ffmpeg and libav via the
module system):
FFmpeg's configuration switches used:
./configure --enable-nonfree --enable-gpl --enable-version3
--enable-libass --enable-libbluray --enable-libmp3lame
--enable-libopencv --enable-libopenjpeg --enable-libopus
--enable-libfaac --enable-libfdk-aac --enable-libtheora
--enable-libvpx --enable-libwebp --enable-opencl --enable-x11grab
--enable-opengl --cpu=native --enable-nvenc --enable-vaapi
--enable-vdpau --enable-ladspa --enable-libass --enable-libgsm
--enable-libschroedinger --enable-libsmbclient --enable-libsoxr
--enable-libspeex --enable-libssh --enable-libwavpack --enable-libxvid
--enable-libx264 --enable-libx265 --enable-netcdf --enable-openal
--enable-openssl --enable-cuda --prefix=/apps/ffmpeg/git --enable-omx
Libav's configuration switches used:
./configure --prefix=/apps/libav/11.7 --enable-gpl --enable-version3
--enable-nonfree --enable-runtime-cpudetect --enable-gray
--enable-vaapi --enable-vdpau --enable-vda --enable-libmp3lame
--enable-libopenjpeg --enable-libopus --enable-libfaac
--enable-libfdk-aac --enable-libtheora --enable-libvpx
--enable-libwebp --enable-x11grab --cpu=native --enable-vaapi
--enable-vdpau --enable-libgsm --enable-libschroedinger
--enable-libspeex --enable-libwavpack --enable-libxvid
--enable-libx264 --enable-libx265 --enable-openssl --enable-nvenc
--enable-cuda --enable-omx
Then run make and make install to build and install the toolkits respectively.
(These are for reference only, a useful FFmpeg build will require you
to install appropriate dependencies for some build options as suited
to your environment and platform. Modify as needed)
When done, you may then create and load the appropriate environment
modules for both ffmpeg and libav as your choices go. Don't load both
at the same time, though :-)
Now, we get to the interesting bits:
Encoding with VAAPI :-)
You'll notice that we pass several arguments to ffmpeg as indicated below:
ffmpeg -loglevel debug -vaapi_device /dev/dri/renderD128 -i "input
file" -vf 'format=nv12,hwupload' -map 0:0 -map 0:1 -threads 8 -aspect
16:9 -y -f matroska -acodec copy -b:v 12500k -vcodec h264_vaapi
"output file"
Let's break down these arguments to their meaning:
(a) .-loglevel tells ffmpeg to log ffmpeg events as debug output. This
will be very verbose, and is completely optional. You can disregard
this.
(b). -vaapi_device: This is important. You must select a valid VAAPI
H/W context device to which you will upload textures to via hwupload,
formatted in the NV12 colorspace. This points to a /dev/dri/render*_
file on your Linux system.
(c). -vf : This is an inbuilt ffmpeg option that allows you to specify
codec options/arguments to be passed to our encoder, in this case,
h264_vaapi (Remember, we built this when we passed --enable-vaapi at
the configuration stage). Here, we tell ffmpeg to convert all textures
to one colorspace, NV12 (As it's the one accepted by Intel's QuickSync
hardware encoder) and to also use hwupload, an ffmpeg intrinsic, that
tells the program to asynchronously copy said textures to the GPU's
hardware surfaces created by VAAPI. Fun, right?
(d). - threads : Specifies the number of threads that FFmpeg should
use. By default, use the number of logical processors available on
your processor here. On Intel processors that support Hyperthreading,
multiply the number of cores your processor has by 2.
(e). -f : Specifies the container format specification you can use.
This can be Matroska, webm, mp4, etc. Take your pick (as per your
container constraints).
(f). -acodec: Specifies the audio codec to use when transcoding the
video's audio stream. In the example given above, we use ffmpeg's
muxers to copy the audio stream as is, untouched.
(g), -vcodec: Selects the video encoder to use. In this case, we
selected h264_vaapi, our key point of interest here.
The other arguments are pretty standard to FFmpeg and need no introduction :-)
If all well according to plan, your video file should be encoded to
H.264, muxed into the selected container and be done with.
Attached are a few screenshots from my system with statistics and
other fun stuff :-)
Enjoy.
Tranquilo, amigos!
Attachments:
1. ffmpeg_libva_hwenc_h264.png: Shows ffmpeg doing its' stuff.
2. htop_stats.png: htop screenshot. Note the CPU utilization, running
two parallel encodes in QuickSync mode, one 1080p and one 4k encode.
3. i7z_coreclocks.png: Shows processor clocks and statistics during
the encode. Compare that to idle_states_hsw.png data.
4. idle_stats_hsw.png: Intel's powertop's idle stats, see numbers for
both processor cores and the GPUs. QuickSync 's power efficiency is
demonstrated here. While in use, the core RAPL package can enter CC3
mode as the GPU's "turbo" and power state go up thanks to Intel's
Intelligent Power Sharing driver (ips module).
5. powerstate_gpgpu.png: Here, you can see Intel's Haswell IGP power
state mappings on full load from the QuickSync transcode in hardware,
thanks to VAAPI.
Dennis Mungai
Jun 27, 2016, 5:50:14 PM6/27/16
to Nairobi Linux Users Group
And a github gist with the same + further instructions for achieving
the same using libav (for these that do use it):
https://gist.github.com/Brainiarc7/95c9338a737aa36d9bb2931bed379219
Thanks and regards,
Dennis.
the same using libav (for these that do use it):
https://gist.github.com/Brainiarc7/95c9338a737aa36d9bb2931bed379219
Thanks and regards,
Dennis.
Alan Orth
Jul 6, 2016, 2:00:52 AM7/6/16
to Nairobi Linux Users Group
I wonder if a Raspberry Pi 3 can do HEVC decode. I saw some initial reports that it could do 1080p, but obviously it gets trickier beyond 24 FPS and 4k resolution. Or maybe I should get one of those Intel NUC devices.
--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu...@googlegroups.com.
To post to this group, send email to nairo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Dennis Mungai
Jul 6, 2016, 4:03:33 AM7/6/16
to Nairobi Linux Users Group
Alan,
These Intel-based Skull Canyon NUCs are the bomb at the moment. They
can do that at ease.
I'm yet to test this on a Raspberry Pi 3, but I should gain access to
one of them soon so as to run some OpenMAX-IL - based video encoding
via ffmpeg..
These Intel-based Skull Canyon NUCs are the bomb at the moment. They
can do that at ease.
I'm yet to test this on a Raspberry Pi 3, but I should gain access to
one of them soon so as to run some OpenMAX-IL - based video encoding
via ffmpeg..
Ibrahim Ng'eno
Jul 6, 2016, 6:14:01 AM7/6/16
to nairobi-gnu
The pi can NOT do Hardware accelerated HEVC, and can only do AVC (h264) up to 1080p
Alan Orth
Jul 6, 2016, 7:57:53 AM7/6/16
to nairobi-gnu
Ah, that's a good point, Ibrahim. Pi 3 can decode some HEVC but it's only in software and your mileage definitely will vary — towards not working, of course — depending on the video's bitrate and resolution.
Those Skull Canyon NUC units look crazy rad but of course they're like 600 EUR...
Hard to compare with a 40 EUR Raspberry Pi 3!
Alan Orth
Jul 6, 2016, 8:12:48 AM7/6/16
to nairobi-gnu
Seems this NUC5CPYH from 2015 should be able to do hardware HEVC decode[0], and it's only 140 EUR[1]. I might get one...
Dennis Mungai
Jul 6, 2016, 8:13:04 AM7/6/16
to Nairobi Linux Users Group
I'm showing much love to my Skull Canyon here. Waiting for that
external thunderbolt 3 eGPU to arrive.
external thunderbolt 3 eGPU to arrive.
Dennis Mungai
Jul 6, 2016, 8:23:02 AM7/6/16
to Nairobi Linux Users Group
This is what I pre-ordered before launch:
http://www.razerzone.com/store/razer-core
A standard Thunderbolt 3 eGPU enclosure that should work with any
Thunderbolt 3 capable SKU. And you have to provide your own GPU.
Previous experiments with eGPU solutions on the ~2015 NUC have been
so-so, requiring one to acquire a PCI riser, a DIY eGPU kit connected
to a spare PCIe slot on the motherboard.
This is the DIY board I use(d): An Akitio Thunder2 PCIe box (with a
lot of messy wiring).
With the new NUC, it should be pretty straightforward, no more manual
risers and hacker-unfriendly DIY boards.
http://www.razerzone.com/store/razer-core
A standard Thunderbolt 3 eGPU enclosure that should work with any
Thunderbolt 3 capable SKU. And you have to provide your own GPU.
Previous experiments with eGPU solutions on the ~2015 NUC have been
so-so, requiring one to acquire a PCI riser, a DIY eGPU kit connected
to a spare PCIe slot on the motherboard.
This is the DIY board I use(d): An Akitio Thunder2 PCIe box (with a
lot of messy wiring).
With the new NUC, it should be pretty straightforward, no more manual
risers and hacker-unfriendly DIY boards.
Ibrahim Ng'eno
Jul 7, 2016, 12:03:48 AM7/7/16
to nairo...@googlegroups.com
Hehe,
Just throwing it out there, my Chinese raspberry pi clones (and
Android TV boxes) can do FHD HEVC without breaking a sweat (I'll test
4K when I get a suitable video and/or display) ... and they cost less
than the pi!!! Particularly excited about the capabilities of the
Amlogic S905x processor, as it promises hardware accelerated VP9
decode as well.
The progress being made pulling this chips into mainline is phenomenal
and whereas they may never be as well supported as Intels,they can
definitely get the job done.
-- Ibrahim
Just throwing it out there, my Chinese raspberry pi clones (and
Android TV boxes) can do FHD HEVC without breaking a sweat (I'll test
4K when I get a suitable video and/or display) ... and they cost less
than the pi!!! Particularly excited about the capabilities of the
Amlogic S905x processor, as it promises hardware accelerated VP9
decode as well.
The progress being made pulling this chips into mainline is phenomenal
and whereas they may never be as well supported as Intels,they can
definitely get the job done.
-- Ibrahim
Dennis Mungai
Jun 1, 2017, 6:00:47 PM6/1/17
to Nairobi Linux Users Group
Small update: VP8 hardware-accelerated encoding in VAAPI works really well on FFmpeg and libav for now (if you're coming in via the latest libva and intel-vaapi-driver packages on your distro of choice).
Good if you're considering tasks such as DASH streaming (with wrapped VP8 and Vorbis audio instead of Apple's HLS) on an Intel server platform.
Note the clock rates (on the mobile i7 6700HQ), power measurements via powertop, and the total system load.Good if you're considering tasks such as DASH streaming (with wrapped VP8 and Vorbis audio instead of Apple's HLS) on an Intel server platform.
Some pics attached below.
>>>>> >> email to nairobi-gnu+unsubscribe@googlegroups.com.
>>>>> >> To post to this group, send email to nairo...@googlegroups.com.
>>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>>> >
>>>>> > --
>>>>> >
>>>>> > Alan Orth
>>>>> > alan...@gmail.com
>>>>> > https://englishbulgaria.net
>>>>> > https://alaninkenya.org
>>>>> > https://mjanja.ch
>>>>> >
>>>>> > --
>>>>> > You received this message because you are subscribed to the Google
>>>>> > Groups
>>>>> > "Nairobi GNU/Linux User Group" group.
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> > send
>>>>> > an
>>>>> > email to nairobi-gnu+unsubscribe@googlegroups.com.
>>>>> > To post to this group, send email to nairo...@googlegroups.com.
>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Nairobi GNU/Linux User Group" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to nairobi-gnu+unsubscribe@googlegroups.com.
>>>>> To post to this group, send email to nairo...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups
>>>> "Nairobi GNU/Linux User Group" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an
>>>> email to nairobi-gnu+unsubscribe@googlegroups.com.
>>>> To post to this group, send email to nairo...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>>
>>> Alan Orth
>>> alan...@gmail.com
>>> https://englishbulgaria.net
>>> https://alaninkenya.org
>>> https://mjanja.ch
>>
>> --
>>
>> Alan Orth
>> alan...@gmail.com
>> https://englishbulgaria.net
>> https://alaninkenya.org
>> https://mjanja.ch
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Nairobi GNU/Linux User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nairobi-gnu+unsubscribe@googlegroups.com.
>> To post to this group, send email to nairo...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Nairobi GNU/Linux User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nairobi-gnu+unsubscribe@googlegroups.com.
> To post to this group, send email to nairo...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu+unsubscribe@googlegroups.com.
Alan Orth
Jun 4, 2017, 2:37:41 AM6/4/17
to Nairobi Linux Users Group
Cool, but I think hardware-accelerated streaming of VP8 is the perfect definition of "too little, too late" considering VP8 was barely even competitive with MP4 when it came out several years ago—now it's useless for anything other than academic curiosity!
>>>>> >> email to nairobi-gnu...@googlegroups.com.
>>>>> >> To post to this group, send email to nairo...@googlegroups.com.
>>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>>> >
>>>>> > --
>>>>> >
>>>>> > Alan Orth
>>>>> > alan...@gmail.com
>>>>> > https://englishbulgaria.net
>>>>> > https://alaninkenya.org
>>>>> > https://mjanja.ch
>>>>> >
>>>>> > --
>>>>> > You received this message because you are subscribed to the Google
>>>>> > Groups
>>>>> > "Nairobi GNU/Linux User Group" group.
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> > send
>>>>> > an
>>>>> > email to nairobi-gnu...@googlegroups.com.
>>>>> > To post to this group, send email to nairo...@googlegroups.com.
>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Nairobi GNU/Linux User Group" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to nairobi-gnu...@googlegroups.com.
>>>>> To post to this group, send email to nairo...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups
>>>> "Nairobi GNU/Linux User Group" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an
>>>> email to nairobi-gnu...@googlegroups.com.
>>>> To post to this group, send email to nairo...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>>
>>> Alan Orth
>>> alan...@gmail.com
>>> https://englishbulgaria.net
>>> https://alaninkenya.org
>>> https://mjanja.ch
>>
>> --
>>
>> Alan Orth
>> alan...@gmail.com
>> https://englishbulgaria.net
>> https://alaninkenya.org
>> https://mjanja.ch
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Nairobi GNU/Linux User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nairobi-gnu...@googlegroups.com.
>> To post to this group, send email to nairo...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Nairobi GNU/Linux User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nairobi-gnu...@googlegroups.com.
> To post to this group, send email to nairo...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu...@googlegroups.com.
To post to this group, send email to nairo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu...@googlegroups.com.
To post to this group, send email to nairo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Ibrahim Ng'eno
Jun 4, 2017, 5:44:31 AM6/4/17
to nairo...@googlegroups.com
Haha, calm down Alan, It is just the first in a series of steps,
considering that vp8 *and* vp9 support is increasing (every
conceivable mobile SOC has h/w decode at least) and Intel chips also
integrated this, I think it's a worthwhile goal to pursue, the VP8 is
just older so easier to implement, It'll probably be easy to enable
for vp9 and before you pooh-pooh vp9, It is the default set for
Youtube on Linux (and on the App depending on hardware support),
people be using webm, they just don't usually know that they are.
considering that vp8 *and* vp9 support is increasing (every
conceivable mobile SOC has h/w decode at least) and Intel chips also
integrated this, I think it's a worthwhile goal to pursue, the VP8 is
just older so easier to implement, It'll probably be easy to enable
for vp9 and before you pooh-pooh vp9, It is the default set for
Youtube on Linux (and on the App depending on hardware support),
people be using webm, they just don't usually know that they are.
Alan Orth
Jun 4, 2017, 12:11:50 PM6/4/17
to nairo...@googlegroups.com
I'm not a videophile or codec snob, just a realist. And, despite what the H.265 enthusiasts say, I do think that VP9 definitely has a place in this world and I would applaud any efforts to improve it. Here's a post from 2015 about VP9's use in low-bandwidth connections on YouTube:
Also, I have shared at least one post this year on this very mailing list about improvements to VP9's encoding speed. Also also, I wrote a blog post last year where I literally recommended VP9, despite it's absolutely horrible encoding speed:
Cheers,
--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu...@googlegroups.com.
To post to this group, send email to nairo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ibrahim Ng'eno
Jun 5, 2017, 9:27:34 AM6/5/17
to nairobi-gnu
I've shown people how much faster/smoother/clearer Youtube is on Linux when using the same Internet connection
convinced a few people to at least test out a dual boot (yeah, still proselytizing) On 4 June 2017 at 19:11, Alan Orth <alan...@gmail.com> wrote:
I'm not a videophile or codec snob, just a realist. And, despite what the H.265 enthusiasts say, I do think that VP9 definitely has a place in this world and I would applaud any efforts to improve it. Here's a post from 2015 about VP9's use in low-bandwidth connections on YouTube:Also, I have shared at least one post this year on this very mailing list about improvements to VP9's encoding speed. Also also, I wrote a blog post last year where I literally recommended VP9, despite it's absolutely horrible encoding speed:Cheers,
On Sun, Jun 4, 2017 at 12:44 PM Ibrahim Ng'eno <eeb...@gmail.com> wrote:
Haha, calm down Alan, It is just the first in a series of steps,
considering that vp8 *and* vp9 support is increasing (every
conceivable mobile SOC has h/w decode at least) and Intel chips also
integrated this, I think it's a worthwhile goal to pursue, the VP8 is
just older so easier to implement, It'll probably be easy to enable
for vp9 and before you pooh-pooh vp9, It is the default set for
Youtube on Linux (and on the App depending on hardware support),
people be using webm, they just don't usually know that they are.
--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu+unsubscribe@googlegroups.com.
To post to this group, send email to nairo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu+unsubscribe@googlegroups.com.
Dennis Mungai
Jun 6, 2017, 7:07:16 AM6/6/17
to Nairobi Linux Users Group
Related, an update on how to build the intel Hybrid driver package on
Linux for VP9 hardware decoding on Skylake + , and extras, considering
that for some reason, Ubuntu omits this step:
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
>>> email to nairobi-gnu...@googlegroups.com.
Linux for VP9 hardware decoding on Skylake + , and extras, considering
that for some reason, Ubuntu omits this step:
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
>>> To post to this group, send email to nairo...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Alan Orth
>> alan...@gmail.com
>> https://picturingjordan.com
>> https://englishbulgaria.net
>> https://mjanja.ch
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Nairobi GNU/Linux User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nairobi-gnu...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> Alan Orth
>> alan...@gmail.com
>> https://picturingjordan.com
>> https://englishbulgaria.net
>> https://mjanja.ch
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Nairobi GNU/Linux User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> To post to this group, send email to nairo...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Nairobi GNU/Linux User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nairobi-gnu...@googlegroups.com.
> "Nairobi GNU/Linux User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
Dennis Mungai
Jun 25, 2017, 6:02:02 PM6/25/17
to Nairobi Linux Users Group
Hello guys,
VP9 hardware accelerated encoding is now available on FFmpeg (git) for
kabylake systems and newer.
Follow this gist on build instructions and usage:
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
Alan Orth and Ibrahim, I believe this settles the feud on VP8 and
VP9's viability.
VP9 hardware accelerated encoding is now available on FFmpeg (git) for
kabylake systems and newer.
Follow this gist on build instructions and usage:
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
Alan Orth and Ibrahim, I believe this settles the feud on VP8 and
VP9's viability.
Reply all
Reply to author
Forward
0 new messages