x265 HEVC Encoder

[littlepox]

merange 24 - 2.91fps, 51765.78kbps, psnr 35.228, ssim 12.801
merange 57 - 3.02fps??, 51685.29kbps, psnr 35.227, ssim 12.801


Crazy. My test earlier showed a 30% time reduce for me_range 57->25. I'd re-test to see what's the pattern.


Yep on non-edge areas there is a bit of loss, source's screenshot are yet denoised?

The source is from Blu-Ray and without any pre-processing. I know I should post screenshots about after-denoise-pre-encoding vs encoded, but I don't have the time so I used the one prepared earlier on. Anyway, since we know x265 is going to blur the non-edge areas, it does not make too much difference.


I also notice an artefact near chest on #5 (edit preceded by mandarinka)


see my reply above



Sometimes I have to remove (did u see Urusei Yatsura?), sometimes I have to add..

I hope they port aq3 and aq4, or something like triaq...

Yep. Pre-processing should be considered on individual basis, and generally I would say, the more grain you wish to keep, the less recommended you use x265.

I'm also looking forward to some improvements. I hope I'd use x265 to encode some movies, concerts @ near-transparent level, but it really disappointed me to show its incompetence after hundreds of tests.

[Lyris]

The NAB show starts Monday. We have a private suite where we'll have some great demos of our latest capabilities including real-time 4K encoding, high quality offline encoding, and decoding on a variety of platforms including tablets. We look forward to discussing our product roadmap with all of our customers and partners, and learning more about their plans and requirements.

If you're going to the NAB show, and you'd like to meet up, email me (tom.vaughan at multicorewareinc dot com). The x265 team's meeting schedule is nearly packed from 8 am to 6 pm every day, but we have a couple of slots open on Tuesday and Wednesday. I'll also be at Ben's Compressionist's party Tuesday night, but it looks like I'll get there a bit late.

Aaack! If I'd known about either of those events I'd have loved to have stopped by. Next year?

[LigH]

x265 1.6+239-5c3443546ccc (https://www.mediafire.com/download/dvqgap641qfbq2h/x265_1.6+239-5c3443546ccc.7z)

News: Support for SMPTE ST 2086 (HDR / Wide Gamut display metadata) and piping reconstructed video to a Y4M viewer.

[RBX]

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.

[benwaggoner]

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.


I would expect that lookahead would be particularly helpful with anime, as you'll get cu-tree, the equivalent of x264's mbtree. MBtree was a HUGE win for anime when it came out, as it was able to figure out what parts of a frame were reused in future frames, and make sure that bits went to making them high quality back in the IDR they first apperared.

Even if the size varies some, you should visually verify you're getting the same visual quality.

If long lookahead is actually harmful, you should file an issue with a repro over at the x265 bitbucket.


-Ben Waggoner (via TapaTalk)

[Motenai Yoda]

Crazy. My test earlier showed a 30% time reduce for me_range 57->25. I'd re-test to see what's the pattern.

Indeed I was testing with me hex and subme 2, not me star and subme 5.


The source is from Blu-Ray and without any pre-processing. I know I should post screenshots about after-denoise-pre-encoding vs encoded, but I don't have the time so I used the one prepared earlier on. Anyway, since we know x265 is going to blur the non-edge areas, it does not make too much difference.
Yep but may seem like a sneaky behavior lead to reference screenshots from non denoised source vs denoised encode ones, especially when you're complaining about x265's grain retention. ;)

[foxyshadis]

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.

CRF comparisons are only meaningful when you don't change anything else. If you do, you have to adjust CRF to get the same file size and look at the visual quality, unless you're capable of judging visual quality vs file size. Sorry, there are no shortcuts to actually watching.

If you aren't willing to watch and compare, there's not much choice but to accept the results. My gut feeling is that the larger size is balanced out by better quality, but I don't know that for sure.

[benwaggoner]

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--qg-size

[x265_Project]

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--qg-size
Me too... but I think it still needs fine tuning. In my initial tests I see lots of things that I like (with respect to visual quality), and some things that I'm less sure of. More testing and tuning is needed before fine-grained AQ can be incorporated into our default settings with confidence. Feedback on combinations of AQ mode, AQ strength and QG Size that seem to work best would be welcomed from the x265 community.

[divxmaster]

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--qg-size

I cant get qg-size 16 to make any difference at all. Byte output is identical with or without qg-size 16. This is using preset slow, so default qg-size should be 64 if not specified.

Using 1.6+239. It accepts the parameter fine and show it as a valid parameter in --help. Am I missing something, is it somehow not enabled +239 build?

params: --crf 20 --preset slow --sar 222:145 --rdoq-level 1 --min-keyint 23 --keyint 240 --pmode --deblock -3:-3 --psy-rd 0.5 --qg-size 16

Cheers,
Divxmaster

[x265_Project]

I cant get qg-size 16 to make any difference at all. Byte output is identical with or without qg-size 16. This is using preset slow, so default qg-size should be 64 if not specified.

Using 1.6+239. It accepts the parameter fine and show it as a valid parameter in --help. Am I missing something, is it somehow not enabled +239 build?

params: --crf 20 --preset slow --sar 222:145 --rdoq-level 1 --min-keyint 23 --keyint 240 --pmode --deblock -3:-3 --psy-rd 0.5 --qg-size 16

Cheers,
Divxmaster
The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.

[divxmaster]

The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.

Ah ok, got it. Yes I knew about it being pulled, but wasn't aware it was still in the CLI! Thanks. Hopefully LigH :) can compile soon. 1.6+239 build was posted 20 Apr, but I guess that source was < 17 Apr? Will try that qgsize 32. Cheers.

[MeteorRain]

Ah ok, got it. Yes I knew about it being pulled, but wasn't aware it was still in the CLI! Thanks. Hopefully LigH :) can compile soon. 1.6+239 build was posted 20 Apr, but I guess that source was < 17 Apr? Will try that qgsize 32. Cheers.

If you don't mind, you can give my build a shoot.

[divxmaster]

If you don't mind, you can give my build a shoot.

@MeteorRain, thanks will give it a try

While waiting for the fine grained AQ patch, Ive been doing some testing in the other direction, which
is creating x265 for mobile devices, seeing how low a bitrate can be used, but still with good quality.
Note this is for mobile devices, screen sizes I have are 4-10.1 inch.

Using params (thanks @burfadel):
--crf 28 --preset slow --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --pmode --deblock -1:-1

The resultant bit rates can only be described as incredible (all 10 bit x265):

sg1 s03e06 720x480 ntsc Bitrate 116kbps! *tivtc and qtgmc via 64bit vapoursynth
sg1 s03e07 720x480 ntsc Bitrate 241kbps
sg1 s03e08 720x480 ntsc Bitrate 173kbps
Irobot DVD 712x440 pal Bitrate 233kbps
k9 Pi DVD 712x552 pal Bitrate 162kbps

Quality is great on small screen sizes, and more importantly file size is miniscule, which is needed
for current microsd card sizes. These bitrates would mean all 10 seasons of sg1 would fit in
12-15gb!.

Cheers,
Divxmaster

[divxmaster]

The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.


I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

Another weird thing, when comparing +239 (qg disabled) vs +275 (qg 64), the new +275 file is bigger. I would have thought the file size shouldn't have changed, as the fine grained patch only started working on <64 ctu? (ok, its only .3% bigger).

These test are on 576p, 1080p may be way different.

Cheers,
Divxmaster

[LoRd_MuldeR]

I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

As always: If you want to compare different settings, then you have to ensure that the files come out at the same size. If you visually compare files of different size, your comparison will be biased! For example, if one of the files comes out larger, but also looks better, what do you learn? Did the particular setting that you were testing with this file actually improve something? Or does the file just look better because it ended up using more bits? Well, you just don't know!

Note that you can always improve quality, simply by increasing the bitrate - or vice versa. No need to change any settings (except the target bitrate) for that! The whole point about testing different settings is to figure out whether a particular setting improves quality at the same bitrate (same file size). Or, equivalently, whether it can retain the same quality at a lower bitrate (smaller file size). But the latter is more difficult to test, which is why we compare files of identical size.

[foxyshadis]

I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

Another weird thing, when comparing +239 (qg disabled) vs +275 (qg 64), the new +275 file is bigger. I would have thought the file size shouldn't have changed, as the fine grained patch only started working on <64 ctu? (ok, its only .3% bigger).

These test are on 576p, 1080p may be way different.

Cheers,
Divxmaster

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

[x265_Project]

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

Yes, we are still working on fine-grained AQ, and we are working to see if we can improve all AQ modes. QG-size is still experimental.

[divxmaster]

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

@foxyshadis & @x265_project,
ah, ok, thanks, that explains what is going on. Well let the testing begin. fine grained aq shows promise already for my low bitrate encodes detailed a few posts up. Visual comparison of specific 'hard to encode' areas, that I noted when fine tuning the params, look visually the same using qgsize32, but @ 3% smaller size.

Edit: looking at the samples on a bigger screen, the qgsize32 is actually better. Some obvious banding in one area under qg64 is gone under qg32. nice.

Cheers,
Divxmaster

[stax76]

avs reading support would be great for AviSynth+ 64-Bit users and tool makers.

[shinchiro]

For me QG-size 32 looks better more safer in most of scene (in anime, 720p). But for complex detail like this (http://prntscr.com/6y84ox), QG-size 16 looks more better

What is interesting, increasing me-range to 100-200 does not slowing encoding (in a certain case, it can speed up encode) :)

[aegisofrime]

Hi, I have a question about the future of x265...

I think we can agree that video encoding can be described by 3 parameters: Speed, quality and size.

An increase in one parameter requires a decrease in one or 2 of the other parameters.

My question is, will x265 do better than x264 in the above ratio in the future?

For example, assuming that quality and file size stays the same, will encoding speed increase in x265 over x264? Or will x265 always be slower than x264?

Hopefully I'm making sense, and sorry if this has been asked before!

[burfadel]

As far as size vs quality is concerned, x265 will be ahead of x264 just by the nature of h.265 vs h.264. However, the encoding efficiency largely depends on the quality of the source. When you re-encode something, you are also re-encoding the 'defects' introduced by the original compression, which lowers the encoding efficiency of the subsequent encoding.

x265 is getting a lot of AVX2 work it seems, so that will benefit Haswell+/Zen+ processors. Additionally, there are new instruction sets for 2016/2017 etc that may be beneficial for encoding. So, x265 may greatly excel upon x264 in terms of speed vs quality vs size. This is of course, assuming x264 doesn't get the same instruction treatment. Additionally, there is the possibility of efficient APU/IGP utilisation in the future, seeing as Intel are working on better incorporating their graphics, and AMD are likely, for consumers, to have APU's even in the 'enthusiast' range for the Zen CPU's. Now that DirectX 12 is upon us, this is actually advantageous as proper use of DirectX 12 will allow graphics processing to be distributed to the APU/IGP and discrete card accordingly. Furthermore, AMD are rumoured to further on this with even better combination of performance between their APU's and discrete cards in the future. This is relevant as if all consumer CPU's in the future also include graphics capability (and complete unification as has been discussed with HSA etc), it would potentially benefit encoding. Currently encoding hasn't benefited too much from this integration, but the integration discussed for the future it should do.

So, for the same level of development, x265 is likely to always surpass x264 in the future, but this largely depends on the future development of x264 and the instruction features utilised.

[stax76]

The poll made it clear where things are right now, next year might be x265's breakthrough, there might as well be another encoder or another codec, only time can tell.

[shinchiro]

Will x265 have something like MBtree in future?

[mandarinka]

Will x265 have something like MBtree in future?

It is already there and is on by default. Because HEVC calls its blocks CUs, it is called CUtree.

[Ajvar]

OpenCL is very expected. Nowadays Medium preset is 7-8 times faster than slower and that's why additional power would be very useful.

[divxmaster]

For me QG-size 32 looks better more safer in most of scene (in anime, 720p). But for complex detail like this (http://prntscr.com/6y84ox), QG-size 16 looks more better

What is interesting, increasing me-range to 100-200 does not slowing encoding (in a certain case, it can speed up encode) :)

Must be a strange quirk of anime, - If I change from default merange of 57 to 100, the fps goes from 12fps to 8.5fps (4770k@3.9)

Cheers,
Divxmaster

[MeteorRain]

avs reading support would be great for AviSynth+ 64-Bit users and tool makers.

Suggest using avs4x26x

[stax76]

Great, why working with AviSynth+ 64-Bit and direct avs support if you can continue with AviSynth 32-Bit and piping. :(

[x265_Project]

Hi, I have a question about the future of x265...

I think we can agree that video encoding can be described by 3 parameters: Speed, quality and size.

An increase in one parameter requires a decrease in one or 2 of the other parameters.

My question is, will x265 do better than x264 in the above ratio in the future?

For example, assuming that quality and file size stays the same, will encoding speed increase in x265 over x264? Or will x265 always be slower than x264?

Hopefully I'm making sense, and sorry if this has been asked before!
Video encoders can be characterized the tradeoff between 2 qualities: compression efficiency, and computational complexity.

Compression efficiency = visual quality at the desired average bit rate

Computational Complexity = the compute power required to run the encoder at a desired speed + setting on a target platform.

Once you pick a target encoding platform and setting, you could say the 2 important qualities of an encoder are compression efficiency and speed.

H.265 encoders use a more efficient coding standard, but the increased encoding efficiency is achieved only by increasing the complexity (increasing the required compute power). So, it's reasonable to expect x265 to be significantly more efficient than x264, using similar settings (a given preset, for example).

Today, x265 --preset medium runs faster on many systems than x264 --preset veryslow, and the encoding efficiency of x265 in this scenario is significantly better. Is this a valid comparison? For some, maybe. Others may be using x264 with a faster preset, and on their hardware x265 is not yet practical.

Any advanced instruction sets that x265 takes advantage of can be used to accelerate x264 (although there are many differences in the functions found in x264 vs x265).

[foxyshadis]

Great, why working with AviSynth+ 64-Bit and direct avs support if you can continue with AviSynth 32-Bit and piping. :(

What's stopping you from piping Avs+ 64-bit? Why is piping such a problem?

[stax76]

Why is piping such a problem?

The question should be: Why is avs such a problem?

[nandaku2]

@foxyshadis & @x265_project,
ah, ok, thanks, that explains what is going on. Well let the testing begin. fine grained aq shows promise already for my low bitrate encodes detailed a few posts up. Visual comparison of specific 'hard to encode' areas, that I noted when fine tuning the params, look visually the same using qgsize32, but @ 3% smaller size.

Edit: looking at the samples on a bigger screen, the qgsize32 is actually better. Some obvious banding in one area under qg64 is gone under qg32. nice.

Cheers,
Divxmaster

Thanks for all the interest in fine grained AQ. A few points.

1. Yes, the fine grained AQ patches change outputs even when qg-size is set to default. This is because I have now added rate-distortion optimization to deltaQP bits. Every time QP is changed within a frame (AQ/CUTree/VBV is enabled), deltaQP bits need to be encoded. This was not being accounted for earlier in the RD-lambda equation. With fine grained AQ, deltaQP bits need to be absolutely accounted for, else we could end up shooting ourselves in the foot, where too many bits are being used up by deltaQP, negating any improvements from efficient bit redistribution.

2. Because of deltaQP bits, the efficacy of qg-size varies heavily on video content. If you had a lot of skip blocks and low residual in the remaining blocks, changing qg-size may not yield much, there are few bits to redistribute, and deltaQP may hike up the final bitcount as well. However, high motion with lots of residual blocks will generally show improvements with qg-size. Our testing has shown qg-size 32 is pretty much consistently better than the default 64.

3. We're working on an optimization where we avoid changing QP (based naively on AQ calculations alone), instead weight QP changes based on residual energy and/or magnitude difference in QP. This should reduce cases of the first kind in point 2.

[nandaku2]

@littlepox

Thank you for the very detailed and informative writeup. We're overdue with a tune anime setting. And we're also reviewing x265 visual quality at very high bitrates - I believe this is very similar to the issue you've reported at low crf. There is also an open issue on the issue tracker that rdoq-level 1 does bad things to grainy videos.

[qyot27]

The proposed LAVF input patch is *almost* able to support AviSynth (if you add *.avs to the allowed extensions list), which would make it cleaner than porting x264's AVS input module. I was able to get a simple Version() script to encode, but if I tried loading real video through FFMS2, it would hang. I'm guessing it's because loading plugins is tripping it up somehow (or it's a Linux-only quirk specific to AvxSynth; I haven't got my cross-compile environment set up yet to test with Windows builds).

Otherwise, just using FFmpeg itself with libx265 linked in works too.

[stax76]

For me this would be never used bloat, StaxRip is currently a +70 MB package including two LAVF powered source filters.

[LigH]

x265 1.6+298-4a7176bab742 (https://www.mediafire.com/download/z3r9ly5cz5ax5a6/x265_1.6+298-4a7176bab742.7z)

New published parameter:

--qpstep <integer> The maximum single adjustment in QP allowed to rate control. Default 4

[Kurtnoise]

The question should be: Why is avs such a problem?
what do you mean ? There is no pb for me...

[MeteorRain]

For me this would be never used bloat, StaxRip is currently a +70 MB package including two LAVF powered source filters.

Have you tried put *.avs into LAVF allowed extension list and give it a shoot?
I've never tried that, but having AVS support might be a good idea.

[LigH]

As far as I remember, AviSynth scripts can be loaded with two different main APIs: Either via the "very compatible" (and almost obsolete) AviFile interface, or via the native AviSynth interface. Does LAVF implement the latter? If LAVF uses a fallback to load unsupported formats in AVIs via Video for Windows, and AviSynth scripts just along with it, it may rather be the former.

[nevcairiel]

LAVF was changed some time ago to use the native AviSynth API.

[stax76]

I'm probably the only one still using ancient AviFile API. :cool:

[Kurtnoise]

Hi Yuuki,

https://bitbucket.org/msg7086/x265-yuuki

Just some cosmetic mod, and (buggy?) l-smash / haali mkv muxer patch after heavy hacking on the core.
It seems that your builds do not support avisynth using lavf input patch, am I right?...how did you compile libav libs ?

[RBX]

CRF comparisons are only meaningful when you don't change anything else. If you do, you have to adjust CRF to get the same file size and look at the visual quality, unless you're capable of judging visual quality vs file size. Sorry, there are no shortcuts to actually watching.

If you aren't willing to watch and compare, there's not much choice but to accept the results. My gut feeling is that the larger size is balanced out by better quality, but I don't know that for sure.
I did another comparison with the latest build (lookahead 20 vs 72). 72 took less time, and produced larger size. Most of the screeshots I took were identical, but some with Lookahead 72 were larger and contained visual artefacts. I was using AQ mode 2 for these, and switching to mode 1 removed atrefacts in those particular frames but 72 still produced a bit larger size.


Also, edges get distorted in the encodes. Is there a known reason for this, or should I keep experimenting with the settings?

P.S. I use x265 16bpp.

[qyot27]

It seems that your builds do not support avisynth using lavf input patch, am I right?...how did you compile libav libs ?
I'm the one that mentioned that it kinda-sorta works, there wasn't anything to suggest that the builds as they are now were set up that way.



1) Configure FFmpeg with --enable-avisynth (a stripped-down build* that also disables the encoders and muxers will cut down on space, but is optional). Build.
2) Adjust the allowed extensions list in the qcloned repo's source/input/input.cpp #ifdef ENABLE_LAVF block to include *.avs. Adjust source/CMakeLists.txt by adding all the non-avcodec/avformat/avutil libs needed by the FFmpeg build to the linker list since the patch's ENABLE_LAVF option uses APPEND PLATFORM_LIBS rather than building the linker list by querying libavformat's, et al., pkg-config files. Build.
...
3) Possibly watch it explode if you try to load video through a source plugin, but see it work fine for Version(). Although like I mentioned before, the hanging with real video sources could be a quirk of the LAVF input source patch interacting specifically with dlopen and thus it may not happen on Windows.

*for example (albeit for 32-bit, and cross-compiled):
./configure \
--prefix=$HOME/win32_build \
--cross-prefix=i686-w64-mingw32- \
--enable-gpl \
--enable-version3 \
--disable-w32threads \
--enable-avresample \
--disable-encoders \
--disable-muxers \
--disable-doc \
--disable-debug \
--disable-devices \
--disable-avdevice \
--disable-filters \
--disable-avfilter \
--enable-avisynth \
--extra-cflags='-DPTW32_STATIC_LIB' \
--target-os=mingw32 \
--arch=x86

[ndkamal]

Which CLI I must use for -qg --size, I tested this one and I don't see any difference in visual quality :

x265 test.y4m --presets Slow --qg -size 32 test.hevc

I use x265 v1.6 298.

[LigH]

You are not expected to see any difference in every case. They may even be subtle in academic cases. No panic.

[ndkamal]

If I use the x265 Nic Mod V2, the fine grained adaptive quantization works well and the picture is near from what we can see in x264, but when I use --qg -size 32, I don't see any differences, below two pictures, the first with x265 v1.6 298 --qg -size 32 and the second with x265 Nic Mod V2.


http://t.imgbox.com/EWT3D4io.jpg (http://imgbox.com/EWT3D4io)

x265 Test.y4m --preset slow --qg -size 32 Test.hevc --bitrate 2000



http://t.imgbox.com/mq9hzarJ.jpg (http://imgbox.com/mq9hzarJ)

x265.exe Test.y4m -o Test.hevc --preset nic --bitrate 2000

[MeteorRain]

Adjust source/CMakeLists.txt by adding all the non-avcodec/avformat/avutil libs needed by the FFmpeg build to the linker list since the patch's ENABLE_LAVF option uses APPEND PLATFORM_LIBS rather than building the linker list by querying libavformat's, et al., pkg-config files.

I'm no expert on CMake. Would you mind share something about how to query that instead of using append platform_libs? I was quite worrying about this method but I don't have much idea how to solve it.

Patch welcomed on CMakeLists.txt:thanks: