x265 - Work already started?

[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

[x265_Project]

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]

Possible someone make x265.exe build with last source?

thx.
x265+src.zip (http://www.sendspace.com/file/khd50p) version 0.3+355-23d8d29c5242 (rev 3512)

[Sagittaire]

x265+src.zip (http://www.sendspace.com/file/khd50p) 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]

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 (http://www.mediafire.com/download/bqtj4jpdv06vy16/x265_r3512.zip) 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]

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

DivX has released a plugin (http://labs.divx.com/node/127923) 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]

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

Currently in an FCD ballot (http://lucia.itscj.ipsj.or.jp/standard/servlets/DocumentSearch?ID=112&sn=2300800101000000&sg=24&st=1&stp=1&m=1&m2=0) (nowadays called the DIS ballot (http://www.iso.org/iso/home/standards_development/resources-for-technical-work/stages_table.htm#s40), 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

http://frupic.frubar.net/thumbs/30115.png (http://frupic.frubar.net/30115)

[filler56789]

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 :)

[x265_Project]

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

[LigH]

Well, uncompressed YUV was required by the encoder too, as long as it has no AviSynth or pipe support. At least the input in Y4M format is a little advantage, saving a few CLI parameters.

I will tell you if the reference decoder restored correct or bugged frames, as soon as RawSource (http://forum.doom9.org/showthread.php?t=39798) got updated to support AviSynth 2.60 MT alpha 4 (same CACHE_MODE interface failure as MaskTools 2). This decoder, unfortunately, appears to output plain YUV only, not Y4M; or did I miss the required parameter?

[LigH]

Chikuzen released (http://forum.doom9.org/showthread.php?p=1641673#post1641673) a new build of RawSource.

Result: HM 11 decodes with the same error. So it may be the proof for an encoder issue.

http://frupic.frubar.net/thumbs/30186.png (http://frupic.frubar.net/shots/30186.png) — frame 44

Raw HEVC file (http://www.mediafire.com/?tzk9y3s6rngioxs) (~10 MB), x265 r3512, current command line options:

-q 20 -b 3 --weightp --weightbp --no-early-skip --no-fast-cbf --rdpenalty 1

[filler56789]

Thanks for testing and reporting :goodpost:

And yes, ooops, my guess was wrong :o

[ozok]

I've been writing a small GUI for x265.exe. You can download it from here (https://bitbucket.org/ozok/x265gui/downloads). It's not much but beats command line IMHO if you wan to run tests. It'll first convert source to yuv then feed this to x265.exe and later will mux this h265 stream with audio into mp4. Also, you can save created command lines to make things easier. Feedbacks are welcome, as always.

[LigH]

Version 0.3+504 by Vid01 (https://docs.google.com/file/d/0BwG6R5Qjd1f2X2JUTjJnN3Fsbm8/edit?usp=sharing) appears to be less stable. It crashes early (<50 frames). Due to a recommendation, I will discuss this also directly in the VideoHelp forum thread (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2262808&viewfull=1#post2262808).

[edison]

I've been writing a small GUI for x265.exe. You can download it from here (https://bitbucket.org/ozok/x265gui/downloads). It's not much but beats command line IMHO if you wan to run tests. It'll first convert source to yuv then feed this to x265.exe and later will mux this h265 stream with audio into mp4. Also, you can save created command lines to make things easier. Feedbacks are welcome, as always.

Does it support .avs as import ?

[ozok]

I didn't try it but I think it'll fail because it needs audio at last step even if you select not to encode audio. I'll release a fix for that asap.

[ozok]

I updated GUI to build 92. Now disabling audio should work. Downloads are here: https://bitbucket.org/ozok/x265gui/downloads

[xooyoozoo]

Just FYI, some days ago they switch the fixed GOP structure into alternating P/B frames. Maybe it's a half step in preparation for other things, and I'm really hoping to see intelligent/adaptive frame decisions soon. In the meantime, though, quality dropped quite a bit compared to the old HM-like random access structure.

[Marchand]

x265 [info]: HEVC encoder version 0.3+614-0e0a822fd344
x265 [info]: build info [Windows][GCC 4.8.1][32 bit] 8bpp

https://shared.com/pwb6xve8kg

[edison]

I updated GUI to build 92. Now disabling audio should work. Downloads are here: https://bitbucket.org/ozok/x265gui/downloads

I think you need to add some GPAC .dl files into the package :)

I have tried some 4K .mp4 file as input but no one works.

[turbojet]

I updated GUI to build 92. Now disabling audio should work. Downloads are here: https://bitbucket.org/ozok/x265gui/downloads

What about piping yuv to x265 instead of writing to disk?

[LigH]

Would be useful, indeed; but for now, x265 has neither pipe nor AviSynth support.

[wOxxOm]

Regarding piping: what about making an Y4M mod of AVFS (http://forum.doom9.org/showthread.php?t=133313) as a workaround?

[LigH]

Hooking the file system with another kind of frame server, instead of implementing already well implemented features into x265?

[wOxxOm]

well, what else can I suggest? half a year has passed and x265 has no such basic feature as pipe support, so obviously it's infinitely hard to implement :D

[phate89]

well, what else can I suggest? half a year has passed and x265 has no such basic feature as pipe support, so obviously it's infinitely hard to implement :D
Half a year? Are you trolling?

[wOxxOm]

Half a year? Are you trolling?

am I? https://bitbucket.org/multicoreware/x265/commits/all?page=127

[nevcairiel]

You do realize that the devs are much more likely to implement the actual video coding, instead of some silly input plugins? :p
I don't think they consider it really ready for real-world usage, so those input things don't matter yet.

[wOxxOm]

nevcairiel, well, that's *obviously* why a suggested Y4M mod of AVFS would be a plausible workaround for *now*

p.s. unless someone would make a patched x265 build similar to the well-known patched x264 builds...

[LoRd_MuldeR]

If it can read YUV files already, implementing "pipe support" (i.e. reading the YUV data from the STDIN rather than from a "physical" file) should be done with one line of code.

And then you get Avisynth or VapourSynth or FFmpeg input for free ;)

- FILE input = fopen(input_path, "rb");
+ FILE input = (strcmp(input_path, "-")) ? fopen(input_path, "rb") : stdin;

Okay, for Windows support you'd need one more line of code:
_setmode(_fileno(stdin), _O_BINARY);


BTW: Looks like there is Y4M support already:
https://bitbucket.org/multicoreware/x265/src/3ea029900ab3ee58ed6b16c5c5a0a89975ba8c03/source/input/input.cpp?at=default

[LigH]

Commit, MuldeR. :)

[filler56789]

Commit, MuldeR. :)

No.

Compile and test. IF test.status=successful,
THEN commit = yes Yes YES
endIF

;) :D

[LigH]

Due to the edit:

BTW: Looks like there is Y4M support already:

Yes, x265 can read Y4M, which is certainly better than reading raw YUV.

But only from a disk file, that's the drawback. Having e.g. ffmpeg pipe Y4M into x265 would be useful, but x265 would have to choose STDIN as input "file" when its name is exactly "-" (but you will know better than me what else may be necessary, depending on the OS, e.g. forcing binary file mode?).

[turbojet]

It's understandable the core devs are focusing on video coding and as long as they can test it with current input options it's good enough. From a user's view it's very difficult to test (special input, decoder, etc.) and progress seems stagnant although it's not. Usability of the encoder is the biggest roadblock atm, improving it by simply allowing more inputs might lead to libav/ffmpeg decoders which might lead to more pull requests coming in which may land x265 more coders. From the posts on Doom9 seems they welcome contributions and are looking for developers.

During x264's infancy it had many input options and decoder support very early on even if the video quality/speed wasn't up to xvid's at the time.

[x265_Project]

It's understandable the core devs are focusing on video coding and as long as they can test it with current input options it's good enough.

This is true... thanks for understanding. We're in the midst of making some very substantial changes to implement frame-level parallelism. We're getting there, but this is not quite done (although the results at this point are very encouraging). Testing is being done with standard YUV or Y4M files (uncompressed video frames) as input. That being said, we understand the desire for x265 to have pipe and AVIsynth support.


From a user's view it's very difficult to test (special input, decoder, etc.) and progress seems stagnant although it's not. Usability of the encoder is the biggest roadblock atm, improving it by simply allowing more inputs might lead to libav/ffmpeg decoders which might lead to more pull requests coming in which may land x265 more coders. From the posts on Doom9 seems they welcome contributions and are looking for developers.

During x264's infancy it had many input options and decoder support very early on even if the video quality/speed wasn't up to xvid's at the time.

As LoRd_MuldeR points out, the beauty of x265 being an open-source project is that anyone can contribute the improvements that they would like to see, but aren't seeing fast enough. We absolutely welcome contributions, and we are looking for developers to join the project.

Tom

[LigH]

I'd love to be able to contribute, but C / C++ don't belong to the list of programming languages I know good enough... :o

Anyway: :thanks: for being busy and research the future of video coding.

[turbojet]

Is Lord_Mulder's 'patch' sufficient?

[filler56789]

@ turbojet: Lord Mulder's post does NOT indicate which file(s) are to be modified,
so, strictly speaking, his suggestion cannot be defined as a *patch* :(

[LoRd_MuldeR]

Is Lord_Mulder's 'patch' sufficient?

This was not an actual patch, just a broad hint on how this stuff is done in general ;)

Actually, x265 uses C++ fstream's rather than classic FILE* pointers, so a slightly different (though equivalent) solution will be needed.

I would write a proper patch, but I'm about to leave for vacation...

[filler56789]

This was not an actual patch, just a broad hint on how this stuff is done in general ;)

Actually, x265 uses C++ fstream's rather than classic FILE* pointers, so a slightly different (though equivalent) solution will be needed.

I would write a proper patch, but I'm about to leave for vacation...

Are you still on vacation? :)