[HEVC] x265.EXE: mingw builds

[Fllear]

I am all that there is builds used. Falls right at the start, time to encode 10-15 frames after Windows severs process.

Can you try to convert this file for testing purposes: http://media.xiph.org/video/derf/y4m/akiyo_qcif.y4m
using https://x265.cc/builds/VC11-x86_64/8bpp/x265_0.4.1%2b528-4ca4da7bdd36.zip

Tested on an CLEAN (only Windows Updates) Win 8.1 Ent x64 english system:



btw. if the mingw builds also fail, its probably a source and/or x265 related problem.

176х144 normal encode
1280x720 crashes encode

[x265.cc]

176х144 normal encode
1280x720 crashes encode

Yeah, than its probably a x265 or source related problem. I will get a 720p file and test i myself.

[Fllear]

176х144 normal encode
1280x720 crashes encode

Yeah, than its probably a x265 or source related problem. I will get a 720p file and test i myself.

x265.exe normal encode 720p https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2275810&v...=1#post2275810

[x265.cc]

176х144 normal encode
1280x720 crashes encode

Yeah, than its probably a x265 or source related problem. I will get a 720p file and test i myself.

x265.exe normal encode 720p https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2275810&v...=1#post2275810

You should not compare two really different builds (Newest revision, VC11, 64bit with Older revision, GCC4.8.1, 32bit).

You can try to compare it with this version: https://x265.cc/builds/MSYS-x86/8bpp/x265_0.4.1%2b493-6d96d64c4e9a.zip

[Fllear]

You can try to compare it with this version: https://x265.cc/builds/MSYS-x86/8bpp/x265_0.4.1%2b493-6d96d64c4e9a.zip

Normal Encode 720p

[x265.cc]

You can try to compare it with this version: https://x265.cc/builds/MSYS-x86/8bpp/x265_0.4.1%2b493-6d96d64c4e9a.zip

Normal Encode 720p

im sorry.... next one please

https://x265.cc/builds/VC11-x86_64/8bpp/x265_0.4.1%2b493-6d96d64c4e9a.zip

If this version is also working, its an x265 related problem. (Due to an change in the latest versions)

And should be reported to the x265 mailinglist

[Acetyl]

I am all that there is builds used. Falls right at the start, time to encode 10-15 frames after Windows severs process.

I don't think it's anything wrong with his buildbot specifically. Potentially it's an issue with a change that was made, and MSVC11. My builds have been failing in a similar way to what you're describing. (Win 7 sp1 x64, doesn't seem dependent on OS)

[El Heggunte]

Tested commit 4ca4da7 on a 25-frame Y4M file,

using both a GCC build and a Visual C build from x265.cc:

no crashes, BUT only 21 frames were encoded

Definitely there is a bug or design flaw in the latest source-code
( what a surprise )

[x265.cc]

Tested commit 4ca4da7 on a 25-frame Y4M file,

using both a GCC build and a Visual C build from x265.cc:

no crashes, BUT only 21 frames were encoded

Definitely there is a bug or design flaw in the latest source-code
( what a surprise )

Yep, i've now also got an 720p y4m file to test with. The latest version which is working is "x265_0.4.1+518-a349dec61168.zip".

Probably not my fault

[Fllear]

Tested commit 4ca4da7 on a 25-frame Y4M file,

using both a GCC build and a Visual C build from x265.cc:

no crashes, BUT only 21 frames were encoded

Definitely there is a bug or design flaw in the latest source-code
( what a surprise )

Yep, i've now also got an 720p y4m file to test with. The latest version which is working is "x265_0.4.1+518-a349dec61168.zip".

Probably not my fault

Sample 720p tested

[LigH.de]

Under which circumstances should I prefer or avoid the 8bpp vs. the 16bpp version?

Is it similar to 8 bit vs. 10 bit of x264, a higher internal encoded value precision? May their support depend on the completeness of the decoder?

[x265.cc]

Under which circumstances should I prefer or avoid the 8bpp vs. the 16bpp version?

afaik the 16bpp version is kinda incomplete in comparison with the 8bpp version.

[tnti]

16bpp a higher internal encoded value

Correct

[Selur]

Problem is that afaik, there is no HEVC with 16bit (all the profiles I know of only support up to 12bit)
-> see: http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles

[tnti]

Wiki refers to the output of HEVC pixel accuracy
Rather than the internal processing precision

[Selur]

Okay, that is the confusion, normally output and internal processing precision is the same,...

[x265.cc]

Erm, looks like x265 is supporting yuv input from stdin since 12 hours..

[DarrellS]

Erm, looks like x265 is supporting yuv input from stdin since 12 hours..

When can we expect a build with stdin support?

[El Heggunte]

Erm, looks like x265 is supporting yuv input from stdin since 12 hours..

When can we expect a build with stdin support?

When they fix the bug/bugs that was/were introduced after commit a349dec (according to x265.cc)

<RANT>

a) I do not have a job at MultiCoreWare

b) come on people, is it really that difficult or time-consuming to send an e-mail to steve ätt borho d0t org

</RANT>

[x265]

Erm, looks like x265 is supporting yuv input from stdin since 12 hours..

When can we expect a build with stdin support?

When they fix the bug/bugs that was/were introduced after commit a349dec (according to x265.cc)

<RANT>

a) I do not have a job at MultiCoreWare

b) come on people, is it really that difficult or time-consuming to send an e-mail to steve ätt borho d0t org

</RANT>

The x265 project has set up communication channels, and these include the x265 development mailing list - x265-devel@videolan.org. These communication channels have been working great for everyone who wants to participate or contribute to the project (including the sharing of bug reports). Privately emailing our lead developer at his personal email address is bad form. Please don't do this.

Bug reports are welcomed and very helpful, but please remember to include the steps to reproduce the problem (generally, the build of x265 that you were running, the command line syntax, details on your test sequence or input source, details on your PC system configuration).

As we optimize x265 and add new features there are always bugs introduced in the tip of the code repository. If you want a stable build, pull from the stable branch (hg update stable). If you are getting builds from the tip (not sure? run hg summary), you will encounter bugs, just as our development team does. We have a large team running automated tests, and these tests flush out the bugs. Our development team fixes bugs fairly quickly, but it may take a day or so to show up as we have a 24 hour review process for all patches submitted, even our own.

[vhelp]

x265 and team, thank you all for putting up with our rants, among other things and with great patience!

[vhelp]

regarding post # 590

Jacobr, i played around and i found where the problem was with the artifacts when using your param string.

using ref 3 or higher causes artifacts when using the setting for that param string configuration. changing to 2 or 1 removed the artifacts completely. hope this info helps you and others with respect to x265.exe's ref parameter.

note: i only tested on 122 frames, 720x480 video source.

good quality using those params.

--frame-skip 0 --frames 122 --q 17 -F2 --keyint 80 --b-adapt 2 -b 3 --bframe-bias 30 --ref 2 --max-merge 5 --me 3 --rect --hash 0 --rd 0 --tu-intra-depth 3 --tu-inter-depth 3 --no-tskip --no-tskip-fast --input "g:\video.y4m" -o "g:\video.[545].hm10"

[vhelp]

- feature request, report -

since the encoded video is in raw form, is it possible to have x265.exe continue an encode after it stopped ?

for example, i have a larger video source, but only encode 122 frames worth. if after reviewing the playback quality, and i like it, i would like to continue encoding additional frames from where i left off. thus, frame 122, 123, 124, ... should work, give the encoder the last frame and video source, let it calculate the gop or idr or whatever its called in h265, and rebuild the video from that and continue. you could hold the necessary info in a .log file if the user chooses that and all the info could be extracted to rebuild from the last frame, much similar to how videoredo does it. thank you.

[El Heggunte]

At last, the stdin support... commit ccac3a7

usage:

avs2yuv input.avs -raw -o -|x265 --fps xxx --input-res wxh --blah-blah-blah -o output.hevc -

[x265.cc]

Erm, looks like x265 is supporting yuv input from stdin since 12 hours..

When can we expect a build with stdin support?

It was available 12 hours before i've made this post.

[El Heggunte]

Erm, looks like x265 is supporting yuv input from stdin since 12 hours..

When can we expect a build with stdin support?

It was available 12 hours before i've made this post.

Which means your index.html needs to be updated as fast as your directory listings

[x265.cc]

Erm, looks like x265 is supporting yuv input from stdin since 12 hours..

When can we expect a build with stdin support?

It was available 12 hours before i've made this post.

Which means your index.html needs to be updated as fast as your directory listings

It has been updated.. but not uploaded to the webserver

This should be fixed now..

[LigH.de]

By the way:

We already discussed how to support both YUV4MPEG and raw YUV input via pipe; for the early testing time without implementing an auto header detection, but just with parameters: If you have raw YUV input, on one hand, you'll have to specify several video attributes (width, height, framerate, possibly pixeltype) via parameters anyway, so on the other hand, you could simply indicate piping Y4M with one alternative parameter instead.

I repeat: We discussed. This is probably not yet implemented. "Soon™". You'll get notified.

[ozok]

I'll update my GUI so it'll benefit from stdin.

[El Heggunte]

I'll update my GUI so it'll benefit from stdin.

and then I'll add a link to it in post #1