x265 - Work already started?

[foxyshadis]

Originally Posted by gnaggnoyil

sorry i didn't thought that it is a kind of "redistribution". i've uploaded a screenshot instead.

It is, but the GPL actually only requires "source code on request"; pointing to the exact git revision on bitbucket would satisfy the requirement, unless you applied any patches.

[roa]

Hi,
I made some tests for HEVC HM 9.0 and h.264 (ffmpeg).
For a video in CIF format, with a Gop size of 4, in lossy mode - 1bit/pixel I got the following results:
=> PSNR luma for h.264 = 30 dB
=> PSNR luma for HEVC = 31 dB
Does anyone have any idea? I think I should obtain much more better results with HEVC.
Thank you in advance

Originally Posted by roa

Hi,
I made some tests for HEVC HM 9.0 and h.264 (ffmpeg).
For a video in CIF format, with a Gop size of 4, in lossy mode - 1bit/pixel I got the following results:
=> PSNR luma for h.264 = 30 dB
=> PSNR luma for HEVC = 31 dB
Does anyone have any idea? I think I should obtain much more better results with HEVC.
Thank you in advance

I would use HM 10.1 or 11 for your tests. The trick to running the HM reference encoder is to create the right configuration file for your video input. In the HM distribution there is a cfg subfolder that contains standard configuration files. I would start with encoder_randomaccess_main.cfg. In this cfg folder there is a per_sequence subfolder that has the File I/O settings for each standard test sequence. You have to edit this section for your cfg file to match your input test video.

PSNR values will depend on the bit rate for each encoder, as well as the settings for all of the many decisions that encoders must make (run fast, or take your time and find the best possible result). PSNR values alone are meaningless. We have to look at PSNR vs bit rate, and at the same time, PSNR vs encoding speed. Of course, experts will also tell you that PSNR isn't the best measure of visual quality (and they're right)... but that's another topic.

By the way... we've posted a new Evaluator's Guide on the x265 repository... https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%2008-12-13.pdf

Tom
MulticoreWare

[Sagittaire]

Possible someone make x265.exe build with last source?

thx.

[MasterNobody]

Originally Posted by Sagittaire

Possible someone make x265.exe build with last source?

thx.

x265+src.zip version 0.3+355-23d8d29c5242 (rev 3512)

[Sagittaire]

Originally Posted by MasterNobody

x265+src.zip version 0.3+355-23d8d29c5242 (rev 3512)

well http://www.sendspace.com/ don't work. It's really bad idea to use that for download. I download a lot of spyware. It's really ... big and beautifull shit ... ;-). Anyway thx.

[phate89]

Originally Posted by Sagittaire

well http://www.sendspace.com/ don't work. It's really bad idea to use that for download. I download a lot of spyware. It's really ... big and beautifull shit ... ;-). Anyway thx.

It is enough read well and avoid to download the file with their download manager and it works well..

[LigH]

Maybe MediaFire has less annoying and confusing ads. (Hope you don't mind the mirror, MasterNobody.)
__

P.S.: Did I miss them already being available, or are AviSynth compatible decoders (e.g. LAV / L-SMASH) "planned soon™"?

[nevcairiel]

ffmpeg/Libav have a decoder in the works, which still needs a lot of cleanup, but is otherwise functional .. it may appear somewhat "soon" in the source tree, an exact time plan is impossible to say of course.

[LigH]

Well, x265 can read raw YUV or Y4M only still, so testers will get used to its handling rather soon.

What are currently recommended filename extensions for the raw H.265/HEVC output?

[easyfab]

With the hevc decoder patch for libav, the raw extension are : "hevc,h265,265"
And yes the decoder seems to work well with x265. Hope HEVC file format in mp4 and mkv will be soon available.

[LigH]

The MP4Box in GPAC 0.5.1 Nightly Builds multiplexes HEVC into MP4. I just tested the Sintel trailer which took ~1:23h with defaults.

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc
mp4box.exe -add sintel_trailer_1080.hevc#trackID=1:fps=24.0 -new sintel_trailer_1080_hevc.mp4

And its Osmo4 plays it ... well ... possibly not multi-threaded, it can hardly cope with FullHD resolution (1080p).

The default quantization of x265 (QP = 32) is too coarse. My result had ~360 kbps which is too little for FullHD; yet, it had a few surprisingly sharp details.

[easyfab]

Yes I know that GPAC can mux hevc in mp4 and there is also a Divx muxer for mkv and xhevc muxer for flv, but no real standard, if I remember correctly JEEB said that the HEVC file format is under certification procedure and the final draft is not available yet.

[xooyoozoo]

Originally Posted by LigH

And its Osmo4 plays it ... well ... possibly not multi-threaded, it can hardly cope with FullHD resolution (1080p).

DivX has released a plugin for their web player if you want to try playing HEVC in your browser. You'd need to use their MKV mixer, and they claim a quad core i5 can do realtime 1080p decoding with their Tears of Steel clips.

I haven't tested it, but maybe their decoder could be more optimized.

The default quantization of x265 (QP = 32) is too coarse. My result had ~360 kbps which is too little for FullHD; yet, it had a few surprisingly sharp details.

Just remember that, by default, biprediction is currently turned off in x265, which makes bitrate to quality assessments a bit more difficult unless you're explicit interested in low-delay scenarios.

I imagine all the fades in the Sintel trailer would also benefit from turning on weighted prediction too, and all this is currently quite unoptimized and slow.

[JEEB]

Originally Posted by jq963152

What about MMT container:
http://en.wikipedia.org/wiki/MPEG_media_transport
?

Currently in an FCD ballot (nowadays called the DIS ballot, but the lucia system seems to be using the older terminology), which will be finished in October. After that there will be a two-month FDIS ballot with the final draft.

[LigH]

I played a bit more with options and got some buggy results, green and pink squares popping up now and then; I believe it is related to shortcut options?

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc -q 20 -b 3 --weightp --weightbp --early-skip --fast-cbf

[filler56789]

Originally Posted by LigH

I played a bit more with options and got some buggy results, green and pink squares popping up now and then; I believe it is related to shortcut options?

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc -q 20 -b 3 --weightp --weightbp --early-skip --fast-cbf

-b N => currently this setting is problematic for the Lentoid DirectShow decoder; add to that the Wavefront Parallel Processing (which now is enabled by default), and the problems may get even worse.

[LigH]

It was played with GPAC 0.5.1 Nightlies' Osmo4. I doubt this one uses DS filters?

[filler56789]

So you can conclude the OpenHEVC decoder is not that good either

If you have an encoded bitstream that can't be decoded perfectly by a particular decoder, and you are wondering whether the encoded stream is compliant with the HEVC specifications or not, I suggest that you use the HM reference decoder to decode to YUV, then use YUVplayer to examine the decoded frames. This will answer your question (is it the encoder, or the decoder that is not working properly?) Of course, uncompressed YUV video requires a lot of storage space, so be sure that you limit the number of frames you are decoding.

Tom