x265 HEVC Encoder

[x265_Project]

The team is working to fix the scene detection bug. We'll update you when a fix is available. This fix is required before we apply the v1.8 tag.

[LigH]

I'll keep checking for commits during the next days more regularly then. :)

[LigH]

x265 version 1.8 has been released. This release supports 12bit input depths, a large amount of AVX2 optimizations, entropy coding optimizations, as well as new quality features.

Full documentation is available at http://x265.readthedocs.org/en/stable/

=================================== API Changes ========================================================
Experimental support for Main12 is now enabled. Partial assembly support exists.
Main12 and Intra/Still picture profiles are now supported. Still picture profile is detected based on x265_param::totalFrames.
Three classes of encoding statistics are now available through the API.
x265_stats - contains encoding statistics, available through x265_encoder_get_stats()
x265_frame_stats and x265_cu_stats - contains frame encoding statistics, available through recon x265_picture
--csv
x265_encoder_log() is now deprecated
x265_param::csvfn is also deprecated
--log-level now controls only console logging, frame level console logging has been removed.
Support added for new color transfer characteristic ARIB STD-B67
================================== New Features ========================================================
limit-refs
This feature limits the references analysed for individual CUS.
Provides a nice tradeoff between efficiency and performance.
aq-mode 3
A new aq-mode that provides additional biasing for low-light conditions.
An improved scene cut detection logic that allows ratecontrol to manage visual quality at fade-ins and fade-outs better.
=============================== Preset and Tune Options ===================================================
tune grain
Increases psyRdoq strength to 10.0, and rdoq-level to 2.
qg-size
Default value changed to 32.

After fixing the scene change adaption, here is the new milestone as "merge with stable" build:

x265 1.8+2-55a4a9b920ff (GCC 4.9.2) (https://www.mediafire.com/download/qc8hxld632d8lo7/x265_1.8+2-55a4a9b920ff.GCC492.7z)
x265 1.8+2-55a4a9b920ff (GCC 5.2.0) (https://www.mediafire.com/download/hse8exx6qa1b6xz/x265_1.8+2-55a4a9b920ff.GCC520.7z)

[Barough]

Thnx for the new v1.8 compile LigH :)

[birdie]

So has version 1.8 been released or not?

http://ftp.videolan.org/pub/videolan/x265/ doesn't have it
https://bitbucket.org/multicoreware/x265/downloads no sign of it here.

[nandaku2]

So has version 1.8 been released or not?

http://ftp.videolan.org/pub/videolan/x265/ doesn't have it
https://bitbucket.org/multicoreware/x265/downloads no sign of it here.

Just uploaded to Bitbucket. The Videolan folks should be manually okaying the upload soon, I guess....

[LigH]

I "monitored" the source repository (checking each few hours) and compiled as soon as the sources were commited with a "merge with stable". Releasing binaries will take a while for every provider until they notice the new sources and start the compilation...

[x265.cc]

1.8+28-f8ad1ff7074a now at https://encoder.pw (New builds every ~15 minutes)

[foxyshadis]

Changes pushed since 1.8 was tagged include: 10-bit overflow fixes for rd and psy-rd, big speedups in SAO (~5% faster total encode when it's used), more 12-bit assembly, and a few misc little speedups. Most of them had been on hold while the scenecut bug was being fixed, it's pretty good to see the hard work still going into this.

[birdie]

Is 1.8 any better than 1.7 at details retention or we're not yet there?

[xxxxx]

Is 1.8 any better than 1.7 in banding (aq-mode 3) or we're not yet there? :)

[LigH]

Test it, tell us. :)

[littlepox]

Currently for high-quality ripping, I believe x265 is better than DivX or EasyRealProducer(rm/rmvb encoder), but still worse than x264 for detail retention.

[Barough]

x265 still have a bit to go on the detail retention part comparing to x264. Did a test with the 'aq-mode 3' enabled on a rather dark movie (Blade Runner) and the result was rather nice imo. But the video size increased with ~35% comparing to when using 'aq-mode 2'.

Something i really hope that will be improved soon is the encoding speed in general for x265.

[birdie]

On my low quality very dark source (17Mbit AVC video)

-preset veryslow -x265-params keyint=600:min-keyint=30:bframes=16:crf=17.5

1.8 improves 1.23% sizewise, IOW x265 1.8 encodes slightly more efficiently than v1.7. I haven't compared the resulting video clips yet.

Edit: v1.8 output is quite different however x265 still blurs everything out vs. x264 at comparable bitrate (which is in my case circa 3.2Mbit/sec for 720p@30fps quite static very dark video containing a lot of noise).

[LigH]

Check the recent changes related to "--tune grain", may be interesting to know which paramters need tweaks to retain noise.

I believe the main reason for detail reduction is the difference between AVC and HEVC algorithms in general... to be proven wrong, some day. ;)

[edison]

Does it support RGB lessloss mode now ?

[foxyshadis]

It's supported RGB lossless since... 1.1? 1.2? At least a year ago. Just use --colormatrix GBR, or for better compression, convert to 10-bit YCoCg and use --colormatrix YCgCo.

[Nazgul]

x265 still have a bit to go on the detail retention part comparing to x264. Did a test with the 'aq-mode 3' enabled on a rather dark movie (Blade Runner) and the result was rather nice imo. But the video size increased with ~35% comparing to when using 'aq-mode 2'.

Something i really hope that will be improved soon is the encoding speed in general for x265.

Which raises one obvious question, how aq-mode 3 looks compared to the other aq modes when the file sizes are normalized, either by adjusting the crf value or by doing 2-pass encodes at the same bitrate.

[benwaggoner]

Which raises one obvious question, how aq-mode 3 looks compared to the other aq modes when the file sizes are normalized, either by adjusting the crf value or by doing 2-pass encodes at the same bitrate.
Yeah, since aq-mode 3 reduces quantization in dark regions, it makes sense that it would raise file size at the same CRF with dark content. However, for dark content it should also raise the CRF required to look good, since it will reduce banding and blocking in dark regions.

[Nintendo Maniac 64]

Compression.ru's 2015 video encoder test results were released:

http://compression.ru/video/code...son/hevc_2015/

Included are x265, and x264, and VP9 along with other HEVC encoders.

[mariush]

The proper link is this one: http://compression.ru/video/codec_comparison/hevc_2015/

[littlepox]

The proper link is this one: http://compression.ru/video/codec_comparison/hevc_2015/

It's interesting to see that for usecase "ripping", x265 and VP9 are better than x264. This is partially due to that the judgement is done with SSIM, which, favors bluriness over grain retention.

Also they did not specify the bit-rate inteval. see the digits in the graph I'd assume it's fairly low, about x264_crf=26. This is the area that x265 already claims a solid victory.

[LigH]

Weekly default build with several additional fixes after the milestone stable:

x265 1.8+31-b6156a08b1de (GCC 4.9.2) (https://www.mediafire.com/download/sv9x87fc9z16wyf/x265_1.8+31-b6156a08b1de.GCC492.7z)
x265 1.8+31-b6156a08b1de (GCC 5.2.0) (https://www.mediafire.com/download/4bdvlk9w5n336qb/x265_1.8+31-b6156a08b1de.GCC520.7z)

[birdie]

It's interesting to see that for usecase "ripping", x265 and VP9 are better than x264. This is partially due to that the judgement is done with SSIM, which, favors bluriness over grain retention.

Also they did not specify the bit-rate inteval. see the digits in the graph I'd assume it's fairly low, about x264_crf=26. This is the area that x265 already claims a solid victory.

In short they were biased towards HEVC so they chose the parameters to improve its standing.

[littlepox]

Yeah, since aq-mode 3 reduces quantization in dark regions, it makes sense that it would raise file size at the same CRF with dark content. However, for dark content it should also raise the CRF required to look good, since it will reduce banding and blocking in dark regions.

From our test results, AQ3 in 10bit encoding contributes negatively. When forced to compare aq=3 and aq=1 in the same bit-rate, aq3 looks worse than aq1 even in the dark-site. If it's done in crf mode with every other parameters same, aq3 gives 30+% increase in the bit-rate but almost 0 improvement in visual quality. That's completely different as what we see for x264.

[benwaggoner]

From our test results, AQ3 in 10bit encoding contributes negatively. When forced to compare aq=3 and aq=1 in the same bit-rate, aq3 looks worse than aq1 even in the dark-site. If it's done in crf mode with every other parameters same, aq3 gives 30+% increase in the bit-rate but almost 0 improvement in visual quality. That's completely different as what we see for x264.
Ah. I was speaking about 8-bit encoding, not 10-bit. In 10-bit, the low-luma blocking and banding is much less of a problem in the first place.

[littlepox]

Ah. I was speaking about 8-bit encoding, not 10-bit. In 10-bit, the low-luma blocking and banding is much less of a problem in the first place.

For 8bit, our test suggest x264 is a far better choice with techniques involving adding ordered dither noise. Ordered dither noise is famous for its resilience to DCT-based lossy compression, so you may add a little (just a little, not much, not even visible) noise on the dark site and then feed it to x264, tweaking parameters of aq/psy-trellis/fgo to keep the noise pattern. You can get very a nice, band-less result even in a low bit-rate, and the cost is surprisingly cheap. In short, with certain well-designed techniques, x264-8bit can do almost as good as 10bit.

However, such technique fails on x265 miserably because x265 just washes the noise away, leaving a clean, banded dark-site, no matter how hard you tweak the parameters, daydreaming to keep the noise pattern.

[nandaku2]

From our test results, AQ3 in 10bit encoding contributes negatively. When forced to compare aq=3 and aq=1 in the same bit-rate, aq3 looks worse than aq1 even in the dark-site. If it's done in crf mode with every other parameters same, aq3 gives 30+% increase in the bit-rate but almost 0 improvement in visual quality. That's completely different as what we see for x264.

@littlepox: can you share a link to your source, and the commandlines you have used.

When we ported aq-mode 3 from x264, we did a bunch of tests tweaking for HEVC encodes, (also implementing some new Just Noticeable Distortion biases). Would it be useful to post these patches - I'm sure we could use some crowd-testing help for the visual quality problems.

[littlepox]

@littlepox: can you share a link to your source, and the commandlines you have used.


Due to the forum rules we are not supposed to share the source here (they are mostly Blu-Ray sources); but we did test them on multiple sources, from anime to movie.

Sources are usually in very good quality(as expected from BD), very little grain (so it makes sence to try x265).

For anime, the parameters are:

--preset slower --crf 16.0 --ctu 32 --max-tu-size 16 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1/3 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16

or you can change crf to npass, but make sure the output is about at a similar bit-rate and quality.

For films, the parameters are:

--preset slower --crf 19.7 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1/3 --aq-strength 1.0 --rd 5 --psy-rd 0.7 --psy-rdoq 5.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.8 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 16

These custom settings are the ones we explored as --tune animation and --tune film. We don't bother do do the test on default settings or tuning since the output is so outperformed.

[~ VEGETA ~]

anyone tried encoding in 12-bit? like anime episode or something similar to see the effectiveness of using 12-bit HEVC. How about playback?

[Nintendo Maniac 64]

The free report for Compression.ru's 2015 video encoder tests are now available.

Here's the URL again for your convenience:
http://compression.ru/video/codec_comparison/hevc_2015/

Note that some encoders are only included in the "Ripping" section, such as f265 and VP9.

[CruNcher]

It's interesting to see that for usecase "ripping", x265 and VP9 are better than x264. This is partially due to that the judgement is done with SSIM, which, favors bluriness over grain retention.

Also they did not specify the bit-rate inteval. see the digits in the graph I'd assume it's fairly low, about x264_crf=26. This is the area that x265 already claims a solid victory.

VP9 can have very beautiful detail retention and temporal grain/noise reproduction

bultje and dark shikari had a lot of discussion about that seems it inspired bultje to keep on track of x264s psy results ;)

https://people.gnome.org/~rbultje/vp9/etv5k-vp9-b5000.webm (also nice for generational transcoding tests)

https://people.gnome.org/~rbultje/vp9/etv5k.png
http://i2.sendpic.org/t/ez/ez0kjYthGP5AKGkK4C3c9Gpc0AN.jpg (http://sendpic.org/view/2/i/1wvva6E5yBdAp9EIKN710o2ltC1.png)

https://people.gnome.org/~rbultje/vp9/etvbr.png

[Motenai Yoda]

VP9 can have very beautiful detail retention and temporal grain/noise reproduction

bultje and dark shikari had a lot of discussion about that seems it inspired bultje to keep on track of x264s psy results ;)

IMHO vp9 try to retain grain a bit too much

[Boulder]

Isn't the idea of an Holy Grail-type encoder to try to represent the source as it is with the lowest possible bitrate? The user will then have all the power to remove things that don't please him beforehand.

[nevcairiel]

Isn't the idea of an Holy Grail-type encoder to try to represent the source as it is with the lowest possible bitrate? The user will then have all the power to remove things that don't please him beforehand.

The holy grail is to discard that information that the user won't notice anyway - since you need to throw away something, or you're a lossless codec. :)

[Boulder]

The holy grail is to discard that information that the user won't notice anyway - since you need to throw away something, or you're a lossless codec. :)Yes, should have clarified "represent the source visually as it is" :)

[littlepox]

2 problems with x265's loss of grain:

1. If we are encoding at a very low bit-rate where all we care is a watchable visual quality, then we are happy if x265 throws away the unimportant grain and focuses on actual details. However, if we allow more bit-rate for a better quality, film grains do play a role in maintaining the visual similarity between source and encode. It's not the most important measure, but still it has a seat.

2. Its predecessor, x264, can free us from worries without raising bit-rates or encoding time. One may argue that the washed image from x265 gives a better PSNR/SSIM output or whatever test metric, but we just don't care.

[foxyshadis]

It's more that x265's shepherds are a bit stymied on how to maximize quality without removing all the gains HEVC gives. There's tune-grain already, and that helps a lot, but it also hurts a lot bitrate-wise, to the point that you wonder why not stick with x264. The main sin seems to be that it doesn't tune more toward grain as the rate goes up, because HEVC should always be able to match x264 at any bitrate, even if it has to mostly restrict itself to AVC's capabilities. The bigger the transform you use, the more low-frequency detail you get but the less high-frequency (grain or noise); AVC uses 4x4 or sometimes 8x8 while HEVC has to select from 4x4, 8x8, 16x16, or 32x32, and somehow balance grain, and while it does the job very well for pretty much all of its video-conferencing customers, the logic is still too complex for satisfying us hardcore home users.

I mean, when it comes right down to it, noise is inherently incompressible, and grain is nearly so... despite the hype, you can't expect much improvement if you want to keep grain.

Still, I hope that someday someone will devise an elegant way to tradeoff noisy and clean, and no one will have to worry about the technical workings anymore.

[CruNcher]

Perseus can give this advantage that HEVC alone misses currently, it's the cherry on top ;)

[benwaggoner]

It's more that x265's shepherds are a bit stymied on how to maximize quality without removing all the gains HEVC gives. There's tune-grain already, and that helps a lot, but it also hurts a lot bitrate-wise, to the point that you wonder why not stick with x264. The main sin seems to be that it doesn't tune more toward grain as the rate goes up, because HEVC should always be able to match x264 at any bitrate, even if it has to mostly restrict itself to AVC's capabilities. The bigger the transform you use, the more low-frequency detail you get but the less high-frequency (grain or noise); AVC uses 4x4 or sometimes 8x8 while HEVC has to select from 4x4, 8x8, 16x16, or 32x32, and somehow balance grain, and while it does the job very well for pretty much all of its video-conferencing customers, the logic is still too complex for satisfying us hardcore home users.

I mean, when it comes right down to it, noise is inherently incompressible, and grain is nearly so... despite the hype, you can't expect much improvement if you want to keep grain.

Still, I hope that someday someone will devise an elegant way to tradeoff noisy and clean, and no one will have to worry about the technical workings anymore.
I think the key is not to encode the grain you have, but the grain you want. Give the same visual experience in a much more compressible way. I don't think x264 is doing a better job of accurately representing the actual source grain, but with mbtree and film grain optimization, it keeps the feel of the original grain better. But you'll see the grain move a lot less from frame to frame; it's more of a texture than completely temporally random noise. And the grain particles themselves will be somewhat softer, while the non-grain retains its sharpness.

[CruNcher]

I like Atemes HEVC Encoder results they seem already pretty stable in Temporal Grain Retention but Bitrate is obvious very high in all the Encoder results :)

ATEME Titan KFE 3.5.1 (4.5.1.0) (older results)

http://demo-uhd3d.com/fiche.php?cat=uhd&id=22

http://i1.sendpic.org/t/6h/6hBhtWQwjChJ91CYzz1lIZWpA8.jpg (http://sendpic.org/view/1/i/2TeJwHvgmTBOKc5gmx8NUoSGPSs.png)
http://i2.sendpic.org/t/9F/9FS5eKHSlwuS32932OWoPwYZlK7.jpg (http://sendpic.org/view/2/i/3fqdiun2qkVqSYZkTrzTCaxj3dg.png)
http://i1.sendpic.org/t/A0/A0pD4w1bqLIX0vQcSP8U5BI2L8b.jpg (http://sendpic.org/view/1/i/cDLnsK2mlYjJMbsO67TaN4DYDog.png)
http://i1.sendpic.org/t/jL/jLI2LWSKFNm3ziRCitvwKBZFNtS.jpg (http://sendpic.org/view/1/i/lVunEEzi3uE1B2BiILok02p4aH9.png)
http://i1.sendpic.org/t/y8/y8EQFGA9NM2009J2WTD2zXAu2Uq.jpg (http://sendpic.org/view/1/i/w56yBGE1Gmx1oDPTOOJw2s15AdS.png)



http://i1.sendpic.org/t/rS/rSikeffL2WmYQOqa8b7IAE0VPgv.jpg (http://sendpic.org/view/1/i/UgUoEs3AY4cLYpmtMw8HJlhUKO.png)

http://i1.sendpic.org/t/mr/mrTD2dsmuwZEm6ejuS98BXfup0U.jpg (http://sendpic.org/view/1/i/vmdk5n7fQ6I50ANKbQch8IjRNWp.png)

http://i1.sendpic.org/t/jh/jhtST3ClasCHH9ouc1AOlEoZbyK.jpg (http://sendpic.org/view/1/i/2N9JgmwxnA5fNKJFTC2YT2GRBGP.png)

http://i1.sendpic.org/t/rN/rNRIA9AhlqmM3vHpmEcycSW3iYm.jpg (http://sendpic.org/view/1/i/qz2ardTCXCPNRIbqxacMVhF8v33.png)

http://i2.sendpic.org/t/mq/mqZ9NHfqLl1IKWWQBpYIhwmwlZZ.jpg (http://sendpic.org/view/2/i/v62HFlmoUb6e4rdakgWMrGIAmL3.png)

http://i1.sendpic.org/t/cO/cO6oF0n8TMPjoNCgI8ehI7D3Qqd.jpg (http://sendpic.org/view/1/i/gQcCvugZFLAjQGJoep7sYtKrq8D.png)

Samsung seems to almost uniquely position the Encoder in Koreas Broadcast Environment also

As we all know Atemes Engineers where the only ones that conquered x264s psy and overall efficiency and they contributed to HEVC after that as well ;)

Whats really nice and Bad the Viewers gonna realize CGI Post Studio (Artificial) Grain and it's use per Scene for the first time much heavier, it will be really interesting how they gonna react when Scenes change their amount of Grain so heavily, are they gonna start and realize this inconsistency while watching ? :D

From extreme Grain to virtually no Grain @ all but Crystal Clear Digital IMAX 3D and CGI Render Results, everything for the Viewers eyes to enjoy or get disturbed with ? ;)

These Encoder results are though already outdated

[Audionut]

They should stop adding grain to the source. Make it a specific playback option, complete with decoder flags and the whole shebang.

So your content creator can specify in the flags that the playback system adds grain 2.3, which specifies the playback device to add a specific type of grain at playback.
Then the source becomes significantly easier to code within a limited bandwidth, the delivered product to the consumer becomes significantly easier to encode for people like us at this forum, and the grain in all it's glory gets added at playback.

Heck, the encoders could even be made aware of the grain being added at playback, and use this information to further improve encoding efficiency.

[LigH]

Weekly build; contains a linking order bugfix and a new option:
--intra-refresh Use Periodic Intra Refresh instead of IDR frames
Enables Periodic Intra Refresh(PIR) instead of keyframe insertion. PIR can replace keyframes by inserting a column of intra blocks in non-keyframes, that move across the video from one side to the other and thereby refresh the image but over a period of multiple frames instead of a single keyframe.
I could imagine that this feature might be incompatible with some consumer devices or authoring standards, who knows ...

x265 1.8+49-f335a9a7b908 (GCC 4.9.2) (https://www.mediafire.com/download/88u8tht6bzuxw1u/x265_1.8+49-f335a9a7b908.GCC492.7z)
x265 1.8+49-f335a9a7b908 (GCC 5.2.0) (https://www.mediafire.com/download/c4rap3f995kc4fq/x265_1.8+49-f335a9a7b908.GCC520.7z)

[CruNcher]

They should stop adding grain to the source. Make it a specific playback option, complete with decoder flags and the whole shebang.

So your content creator can specify in the flags that the playback system adds grain 2.3, which specifies the playback device to add a specific type of grain at playback.
Then the source becomes significantly easier to code within a limited bandwidth, the delivered product to the consumer becomes significantly easier to encode for people like us at this forum, and the grain in all it's glory gets added at playback.

Heck, the encoders could even be made aware of the grain being added at playback, and use this information to further improve encoding efficiency.

Some smart people thought long way back of how this could be achieved on the playout side ;)
What you imagine is existing already developed by Thomson and part of the AVC Standard ;)

https://hopa.memberclicks.net/assets/documents/thomson_fgt_hpa2006.PDF

[sneaker_ger]

It's also in the HEVC specs but no one uses it, not least since it's optional for decoders. It's not in-loop.

[Stacey Spears]

Some comments about the x265 docs w/r/t --master-display. (http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--master-display)

1st. The example provided says it is for P3. Here is what is presented: G(13200,34500)B(7500,3000)R(34000,16000) The G value is incorrect, 13200 produces 0.264. The G value should be 13250, which produces 0.265.

The next question I have is for the L value. From the x265 docs: L(%u,%u)” where %u are unsigned 32bit integers. From table 5 of CEA-861.3: Data Bytes 19 – 20 specify a value for the max_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 1 cd/m2... This is the same as the primaries and white point. Everything is using UINT16 per 863.1.

edit: Looks like the HEVC spec is calling for UINT32.

[x265_Project]

Some comments about the x265 docs w/r/t --master-display. (http://x265.readthedocs.org/en/default/cli.html?highlight=#cmdoption--master-display)

1st. The example provided says it is for P3. Here is what is presented: G(13200,34500)B(7500,3000)R(34000,16000) The G value is incorrect, 13200 produces 0.264. The G value should be 13250, which produces 0.265.

The next question I have is for the L value. From the x265 docs: L(%u,%u)” where %u are unsigned 32bit integers. From table 5 of CEA-861.3: Data Bytes 19 – 20 specify a value for the max_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 1 cd/m2... This is the same as the primaries and white point. Everything is using UINT16 per 863.1.

edit: Looks like the HEVC spec is calling for UINT32.
Hi Stacey,
We'll take a look at this. In the future, the best place for experts like you (or anyone who is reasonably sure they know what they are talking about) to report bugs is our x265 Issues Tracker (https://bitbucket.org/multicoreware/x265/issues).

Tom

[x265_Project]

Intra-refresh isn't used for high quality encoding for streaming or file-based playback. It's helpful in real-time low latency video applications. Spreading the intra-predicted blocks out across multiple frames means that you don't have one really big I frame followed by smaller P and B frames. In low-latency applications through a fixed channel bandwidth, this is helpful. Of course there are trade offs to overall compression efficiency. With a moving camera or moving subjects prediction suffers as you don't have a single stable reference frame that captured everything. But for fixed-camera low-latency video (like video conferencing), intra-refresh can be beneficial.

[sneaker_ger]

I was answering to the posts about the grain modeling, not talking about periodic intra refresh.