[HEVC] x265.EXE: mingw builds

[x265]

I don't know who x265.cc is, or why he feels that it is ok to use that username

Erm, cause i'm the operator of x265.cc?

He doesn't represent the x265 project.

Have i ever stated or indicated that?

or register that domain name

Is x265 a registered trademark? Do you need explicit this domain name? Currently there are a lot of x265.tld domains registered.

If you do not want that anybody is using your project name ("x265") or your source you should register the "x265" as trademark and publish x265 as closed source. Also i hope that you've asked the x264 team if you are allowed to use there name.

So if you really have a problem with the "x265.cc" TLD / using your source code / offering binaries or programing a buildbot, (what i not really believe..) please tell me this by mail. Thanks.

btw. i've planned to change the buildbot to build windows xp binaries at weekend..

x265 is a registered trademark. It is not OK for anyone else to use this product/brand name. We will handle this matter with you directly. And yes, the x264 team was consulted about, and approved of our plans to use the name x265.

Tom

[x265.cc]

x265 is a registered trademark. It is not OK for anyone else to use this product/brand name. We will handle this matter with you directly. And yes, the x264 team was consulted about, and approved of our plans to use the name x265.

Tom

Great. admin@x265.cc.

Currently our trademark register shows that "x265" owner in europe is

VideoLAN 18, rue Charcot 75013 Paris France

so it would be nice if you can clarify your ownership in this mail. Thanks

[El Heggunte]

So be it --- this is the reply from Steve Borho to Kurtnoise's suggestion:

> # HG changeset patch
> # User Kurtnoise <kurtnoise@free.fr>
> # Date 1381898006 -7200
> # Wed Oct 16 06:33:26 2013 +0200
> # Node ID 723e554191e14e6289342043225e485e656c27d7
> # Parent a998daed845922b3b880b48c0cafa32c422c941e
> Add Windows XP support in MSVC11 builds. This requires CMake 2.8.11 or later.

This would require the most recent release of CMake and MSVC 2012 Update 1, and we have no good way to query the update status of MSVC from this batch file. This info should probably live in the build README and on the wiki.

[Marchand]

Let's force the machines to the extreme x265 - 4K Resolution (TV, ultra-high-definition 3840 × 2160 =) Win7-64bits-QuadCore /Gui Ozok-Build-60 and Build-92:

General
Complete name : C:\Users\Marchand\Videos\00200.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : iso4
File size : 1.29 MiB
Duration : 7s 465ms
Overall bit rate mode : Variable
Overall bit rate : 1 444 Kbps
Encoded date : UTC 2013-10-17 00:13:49
Tagged date : UTC 2013-10-17 00:13:49

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L15.0
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 7s 200ms
Bit rate : 1 359 Kbps
Maximum bit rate : 1 647 Kbps
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.007
Stream size : 1.17 MiB (91%)
Title : h265:FMT=HEVC@GPAC0.5.1-DEV-rev4704
Encoded date : UTC 2013-10-17 00:13:49
Tagged date : UTC 2013-10-17 00:13:49

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 7s 465ms
Source duration : 7s 488ms
Bit rate mode : Variable
Bit rate : 129 Kbps
Maximum bit rate : 141 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -21ms
Stream size : 118 KiB (9%)
Source stream size : 118 KiB (9%)
Tagged date : UTC 2013-10-17 00:13:49

ffmpeg version N-55159-gf118b41 Copyright (c) 2000-2013 the FFmpeg developers
built on Aug 1 2013 18:04:40 with gcc 4.7.3 (GCC)
configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 52. 40.100 / 52. 40.100
libavcodec 55. 19.100 / 55. 19.100
libavformat 55. 12.102 / 55. 12.102
libavdevice 55. 3.100 / 55. 3.100
libavfilter 3. 82.100 / 3. 82.100
libswscale 2. 4.100 / 2. 4.100
libswresample 0. 17.103 / 0. 17.103
libpostproc 52. 3.100 / 52. 3.100
Input #0, mpegts, from 'C:\Users\Marchand\Videos\00200.m2ts':
Duration: 00:00:07.50, start: 11.608967, bitrate: 41182 kb/s
Program 1
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / 0x0086), 48000 Hz, 5.1(side), fltp, 1536 kb/s
Output #0, rawvideo, to 'C:\Users\Marchand\Videos\00200.yuv':
Metadata:
encoder : Lavf55.12.102
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 23.98 tbc
Stream mapping:
Stream #0:0 -> #0:0 (h264 -> rawvideo)
Press [q] to stop, [?] for help
frame= 180 fps=8.4 q=0.0 Lsize= 2187000kB time=00:00:07.50 bitrate=2386400.8kbits/s dup=1 drop=0
video:2187000kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.000000%

ffmpeg version N-55159-gf118b41 Copyright (c) 2000-2013 the FFmpeg developers
built on Aug 1 2013 18:04:40 with gcc 4.7.3 (GCC)
configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 52. 40.100 / 52. 40.100
libavcodec 55. 19.100 / 55. 19.100
libavformat 55. 12.102 / 55. 12.102
libavdevice 55. 3.100 / 55. 3.100
libavfilter 3. 82.100 / 3. 82.100
libswscale 2. 4.100 / 2. 4.100
libswresample 0. 17.103 / 0. 17.103
libpostproc 52. 3.100 / 52. 3.100
Input #0, mpegts, from 'C:\Users\Marchand\Videos\00200.m2ts':
Duration: 00:00:07.50, start: 11.608967, bitrate: 41182 kb/s
Program 1
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / 0x0086), 48000 Hz, 5.1(side), fltp, 1536 kb/s
Output #0, ipod, to 'C:\Users\Marchand\Videos\00200.m4a':
Metadata:
encoder : Lavf55.12.102
Stream #0:0: Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
Stream mapping:
Stream #0:1 -> #0:0 (dca -> aac)
Press [q] to stop, [?] for help
size= 120kB time=00:00:07.46 bitrate= 131.7kbits/s
video:0kB audio:118kB subtitle:0 global headers:0kB muxing overhead 1.771538%

yuv [info]: 3840x2160 25Hz, frames 0 - 179 of 180
x265 [info]: detected SIMD architectures SSE2 SSE3 SSSE3 SSE4.1
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: thread pool with 4 threads, WPP enabled
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME method / range / maxmerge : star / 64 / 5
x265 [info]: Keyframe Interval : 28
x265 [info]: WaveFrontSubstreams : 34
x265 [info]: QP : 32
x265 [info]: enabled coding tools: rect amp rdo rdoq lft sao sao-lcu sign-hide tskip tskip-fast rdoqts
[100.0%] 180/180 frames, 0.06 fps, 1359.09 kb/s, eta 0:00:00
encoded 180 frames in 2979.95s (0.06 fps), 1359.09 kb/s
x265 [info]: frame I:7 kb/s: 7340.77 PSNR Mean: Y:54.231 U:53.912 V:47.632
x265 [info]: frame P:173 kb/s: 1116.14 PSNR Mean: Y:44.916 U:45.278 V:45.898
x265 [info]: global: kb/s: 1358.21 PSNR Mean: Y:45.279 U:45.614 V:45.966

HEVC import - frame size 3840 x 2160 at 25.000 FPS
HEVC Import results: 180 samples - Slices: 7 I 173 P 0 B - 0 SEI - 1 IDR
IsoMedia import 00200.m4a - track ID 1 - Audio (SR 48000 - 2 channels)
Saving to C:\Users\Marchand\Videos\00200.mp4: 0.500 secs Interleaving

[deadrats]

There is no anti XP sentiment from the x265 project. I don't know who x265.cc is, or why he feels that it is ok to use that username (or register that domain name). He doesn't represent the x265 project.

you know tom, this is the type of attitude that really annoys me from the open source community and you see it everywhere. first i would like to say that i am not this x265cc guy (or girl) and have nothing to do with him but i find it odd that you would express displeasure at him/her choosing that screen name and/or registering that domain when your screen name and product name is deliberately chosen to lead one to the conclusion that your hevc encoder is somehow an evolution of that over-rated piece of crap x264, just as it was douche of their supporters to rag on you guys for choosing your name when x264 is clearly a play on xvid which in turn was just divx backwards.

and as for you being a PR man, i'm not sure "El" meant it as an insult, but is is obvious to the casual outside observer that part of your role is spin man, with the focus on trying to extract as much cash out of the project as you will be able to.

now i'm a business man and i don't think there's anything inherently wrong with wanting to cash out, but what i think is getting on some people's nerves is that your firm, with you at the helm, is putting on this kumbaya facade like you guys are doing it for the good of the community when it's obvious that you are trying to build up a following using the x265 name and when you have enough of an installed user base turn around and sell the software to a third party for big bucks.

again, i have no problem with a desire to make money but your stated attitude that "**** what the every day user wants, corporate sponsors come first with regards to bug fixes and feature requests", which is the justification you have used, sans the "****" for why x265 only supports yuv and y4m sources, is just shitty and the primary reason why i refuse to test your software, have no plans to ever use your encoder when it's finally done and why i intend to recommend to anyone that will listen to go with a competing encoder.

you guys don't deserve the average joe's support, stick with your corporate sponsors and do whatever they want and let us go to a better competitor.

[El Heggunte]

^
^
@ Marchand: thanks a lot for the useful post

.......

and as for you being a PR man, i'm not sure "El" meant it as an insult, but is is obvious to the casual outside observer that part of your role is spin man, with the focus on trying to extract as much cash out of the project as you will be able to.

In no way my intention was insult Mr. Tom Vaughan, I simply stated what I have perceived. Even when the "Public Relations people" happen to have a deep technical knowledge of the products/services they try to "sell", the fact is, they often present to the (potential) end-users just a selection of incomplete and/or incorrect and/or misleading info See for example the initial page of the X265 "developer" Wiki ---
--- it says,

Linux Instructions .........

Windows (Visual Studio) Instructions .............

Mac OS X ...........

when it clearly should be saying something like this:

GCC instructions ......

Visual Studio instructions .......

whatever instructions .....

Why? Because, while one can say "Visual Studio means Windows", it's not correct to conclude "GCC means Linux"
And no, I still haven't found the practical/effective difference between the "MSYS makefiles" and the "Unix makefiles" generated by CMake.

[x265]

There is no anti XP sentiment from the x265 project. I don't know who x265.cc is, or why he feels that it is ok to use that username (or register that domain name). He doesn't represent the x265 project.

you know tom, this is the type of attitude that really annoys me from the open source community and you see it everywhere. first i would like to say that i am not this x265cc guy (or girl) and have nothing to do with him but i find it odd that you would express displeasure at him/her choosing that screen name and/or registering that domain when your screen name and product name is deliberately chosen to lead one to the conclusion that your hevc encoder is somehow an evolution of that over-rated piece of crap x264, just as it was douche of their supporters to rag on you guys for choosing your name when x264 is clearly a play on xvid which in turn was just divx backwards.

and as for you being a PR man, i'm not sure "El" meant it as an insult, but is is obvious to the casual outside observer that part of your role is spin man, with the focus on trying to extract as much cash out of the project as you will be able to.

now i'm a business man and i don't think there's anything inherently wrong with wanting to cash out, but what i think is getting on some people's nerves is that your firm, with you at the helm, is putting on this kumbaya facade like you guys are doing it for the good of the community when it's obvious that you are trying to build up a following using the x265 name and when you have enough of an installed user base turn around and sell the software to a third party for big bucks.

again, i have no problem with a desire to make money but your stated attitude that "**** what the every day user wants, corporate sponsors come first with regards to bug fixes and feature requests", which is the justification you have used, sans the "****" for why x265 only supports yuv and y4m sources, is just shitty and the primary reason why i refuse to test your software, have no plans to ever use your encoder when it's finally done and why i intend to recommend to anyone that will listen to go with a competing encoder.

you guys don't deserve the average joe's support, stick with your corporate sponsors and do whatever they want and let us go to a better competitor.

First of all, please don't characterize what I've said, or what my motives are (or the motives of the x265 project). I can speak for myself. Please speak for yourself. People can draw their own conclusions.

All companies protect their trademarks. The reasons are obvious. We don't want our brand to be diluted by imposters. We don't want our customers or anyone else to be confused. As soon as this guy started posting as x265.cc, people started asking if he was speaking for the x265 project. We need to maintain the integrity of the product and the project. This is standard operating procedure, even for fully volunteer open-source projects. Trademark and brand integrity don't just benefit the company, they benefit consumers in the marketplace. As a customer of company x, do you want to know when you're speaking with company x, or are you ok with other people showing up with confusingly similar names, tricking you into believing that you're speaking with company x?

We've been clear on the business model of the project. This is a commercially funded open source project. It wouldn't exist if there was no one funding this very substantial effort. My company and the other founding members of the project wouldn't have invested if we couldn't achieve our commercial objectives (building an HEVC encoder that would be competitive with the many other proprietary encoders available in the market, in the required time frame). We've got a lot of work to do in a very short time. To succeed, we have to keep our developers focused on the highest priorities first. Have you seen the development roadmap? If the project fails on the commercial side, the open source community loses (less developers = less competitive code). If it succeeds (and so far, it is quite successful), it's a win/win.

We decided to go with the open source model for a variety of reasons, and we're fully committed to running this project the way any successful open source project should be run. We're getting excellent participation from the open source community.

I'm confused as to why you would choose to interact with the x265 project in this way. You wanted a feature, and clearly you're upset that your feature request didn't go straight to the top of our priority list. And so you've chosen to criticize and complain and slander us on a public forum. This is not the best way to interact with an open source project, in my experience.

Contributors are always welcome. Contributors earn the respect of their peers in the project, and they earn the right to have their ideas and requests considered. The important interaction happens through our official communication channels. We are looking for talented people to contribute to the project any way they can. Feel free to reach out to me directly.

Tom

[deadrats]

I'm confused as to why you would choose to interact with the x265 project in this way. You wanted a feature, and clearly you're upset that your feature request didn't go straight to the top of our priority list. And so you've chosen to criticize and complain and slander us on a public forum. This is not the best way to interact with an open source project, in my experience.

i'm not going to address anything else you said but allow me to address the above: the "feature" i want is a "feature" that every single person in this thread, and in other threads both here and that worthless forum dick9 has requested since the first public announcement of the x265 project, namely the ability to actually test the software without needing source files that measure in the 10's of gigabytes.

the simplest thing, the ability to use a lossy source has repeatedly been requested but you have explicitly told the end users to pound salt by flat out stating that your corporate sponsor's bug reports and feature requests come first.

i for one find it extremely hard to believe that a corporate sponsor wouldn't want the most basic functionality before anything else and that would be the ability to use sources other than y4m/yuv. you're telling me no corporate sponsor has said to you "hey, we shoot in HDV or AVC and we want to be able to feed those source files straight into x265 without needing to create a 150gb intermediate file first"?

this is why it smacks to me of pure, steaming bullshit and why it looks to me like you guys are just looking to cash out by playing the open source card as a bait and switch.

honestly? i think you guys have probably coded yourselves into a corner by deciding to try and use algorithms from x264, arguably the most over-rated piece of software ever and from internal testing you have concluded that the encode quality of x265 when fed lossy formats is sub-par so you have decided to make it extremely difficult, if not impossible, for the average joe to test your software and see for themselves how poor the encode quality is.

i know if i was running your project the first thing i would do is add the ability to accept lossy formats as well as code an open source decode library so that i could get the masses testing the software and spreading the word of x265.

there is an old saying "he who has a thing to sell and goes and whispers in a well is not so apt to get the dollars as he who climbs a tree and hollers". you guys, by refusing to add support for anything other than yuv/y4m are not only effectively whispering in a well but you're also refusing to tell anyone where that well is lest they hear the echo left behind.

making your software in such a way that the masses can actually test it is not a "feature request", imagine if i was trying to get you to buy a car and gave you all the brochures, let you sit in it, showed you the engine but absolutely refused to give you the key to start it, thereby making the only way to "test drive" the car by rolling it down a hill.

now the feature i would like to see is for you guys to port the reference hm12 hevc encoder to cuda and create an hevc encoder that runs either entirely or almost entirely on a gpu.

and before anyone says anything like "just because it runs on a gpu doesn't mean it will run faster", the reason a gou powered encoder would be preferable is because it makes the upgrade cycle for the end user much more cost effective and simpler.

as hevc gains more of a foothold and people start using it more and more the more end users will feel the need to upgrade their systems and upgrading a video card is a lot simpler and cheaper than upgrading motherboard, cpu and ram and reinstalling the OS.

[mgh]

Hard to produce a working file when every encoder uses a different command line. Every file I try to create ends with a crash in the encoder and the out put, although it kind of plays (corrupt frames) crashes every player.

Working sample commands would be nice for each encoder so we can tell if it's our command line or our system that refuses to create a working file.

I just formatted a spare drive and will install a back up image of my operating system when I knew everything was working fine. I've installed and uninstalled so much crap the last couple of months trying to get 265 and VP9 to work that I don't know how much damage I've done to the operating system.

Maybe XP with 4GB of memory and a Q6600 cpu is just not good enough to create a working file.

I have Q6600 and XP SP2. No problem whatsoever in handling Full HD videos from Youtube. Encoding is slow, but then so was encoding using Avisynth with complex filters. For the record, I get close to 1.5 fps.

[x265]

"... you have explicitly told the end users to pound salt..."

I have not. Not even close. Please stop mischaracterizing my responses.

i for one find it extremely hard to believe that a corporate sponsor wouldn't want the most basic functionality before anything else and that would be the ability to use sources other than y4m/yuv. you're telling me no corporate sponsor has said to you "hey, we shoot in HDV or AVC and we want to be able to feed those source files straight into x265 without needing to create a 150gb intermediate file first"?

I've been speaking with top technical teams at most of the major movie studios, post production houses, pro and consumer video equipment companies, application developers, video services, broadcasters, etc., and we haven't had one request for stdin input. I'm not saying we won't ever or don't want to add this feature, or that it isn't important for the wider open source community, but your assumption that everyone requires it or is asking for it is not accurate.

x265 is not an application, it's a core function library - designed to be called by an application. The application that calls x265 feeds the uncompressed (or decoded) frames into the encoder. As others have accurately stated, we are focused on the core HEVC video encoding functionality (taking uncompressed frames and producing the highest quality fully compliant HEVC bitstream for a given target bitrate). Our customers (and other open source projects) build video applications.

... you guys are just looking to cash out ...

By not delivering a feature that our commercial customers are asking for? This seems contradictory.

... by playing the open source card as a bait and switch.

Switch to what? Once you offer your software under the GPL you can never go back. Everything we build for our commercial customers will also be offered in the GPL version of x265. All of our customers who want the rights to make modifications must sign our contributor agreement (the same agreement posted on the project page). Any modifications that commercial customers make (or anyone makes) to x265 must also be contributed back to the project. There is no possibility of a bait and switch. Everything we are doing for our commercial customers, you benefit from, for free.

now the feature i would like to see is for you guys to port the reference hm12 hevc encoder to cuda and create an hevc encoder that runs either entirely or almost entirely on a gpu.

and before anyone says anything like "just because it runs on a gpu doesn't mean it will run faster", the reason a gou powered encoder would be preferable is because it makes the upgrade cycle for the end user much more cost effective and simpler.

as hevc gains more of a foothold and people start using it more and more the more end users will feel the need to upgrade their systems and upgrading a video card is a lot simpler and cheaper than upgrading motherboard, cpu and ram and reinstalling the OS.

Oh sure... another feature request!

The HM reference encoder can take minutes to encode a single frame of 4K video (on a fast machine). It is single threaded. x265 is coming along nicely, and is highly multi-threaded. In some of my tests x265 is 200X faster than the HM with full HM reference quality (and this is just on a notebook... the X factors are much higher on a server with many CPU cores). We can further multiply these X factors significantly with very little trade-off in encoding efficiency. But hey, if you like the HM, knock yourself out. I like to get my encoded video streams back in the same day, but that's just me.

Have you done any GPU accelerated software development Deadrats? Many parts of the encoding process are serial in nature, and there are many dependencies. It would never make sense to port the entire encoder to run on the GPU. The real question is, what can be accelerated, and how best to accelerate it?

You might want to keep an eye on our development roadmap.

Tom

[x265.cc]

MSVC11 project patch for XP compatibility by Kurtnoise in the doom9 forum

Not really matters if you build the makefiles without the batch files. Simply add the "-T "v110_xp"" switch to cmake.
Anyway nice work for batch users.

this guy doesn't understand what my patch does...the switch goes to the cmake command line.

What his patch does:

-Check if CMake Version is at least "2.8.11"
-Add "-T "v110_xp"" to the "make-solutions.bat" batch file (to cmake, not cmake-gui)

Thats it. You can't use this batchfile for automated builds do to the usage of "cmake-gui"

The whole magic:

"cmake -G "Visual Studio 11 -T "v110_xp"" ..\..\source" for dynamic builds
"cmake -G "Visual Studio 11" -DSTATIC_LINK_CRT=1 -T "v110_xp" ..\..\source" for static builds

-> NOT TESTED

So be it --- this is the reply from Steve Borho to Kurtnoise's suggestion:

> # HG changeset patch
> # User Kurtnoise <kurtnoise@free.fr>
> # Date 1381898006 -7200
> # Wed Oct 16 06:33:26 2013 +0200
> # Node ID 723e554191e14e6289342043225e485e656c27d7
> # Parent a998daed845922b3b880b48c0cafa32c422c941e
> Add Windows XP support in MSVC11 builds. This requires CMake 2.8.11 or later.

This would require the most recent release of CMake and MSVC 2012 Update 1, and we have no good way to query the update status of MSVC from this batch file. This info should probably live in the build README and on the wiki.

I would recommend to use MSVC2012 Update 3 anyway.

All companies protect their trademarks. The reasons are obvious. We don't want our brand to be diluted by imposters. We don't want our customers or anyone else to be confused. As soon as this guy started posting as x265.cc, people started asking if he was speaking for the x265 project.

You mean i'm responsible for what other people ask / if they are not able to read?

This buildbot (x265.cc) is NOT affiliated with, endorsed, or sponsored by the x265 development team (x265.org), MultiCoreWare Inc nor VideoLAN organization.

Probably i should also make this as singature.. in bold.

If you really against the unofficial "x265.cc - Buildbot" it would be nice if you contact me before weekend, so i will not rewrite it before i have to cancel it.

[LigH.de]

I am sorry that I have lost a thread in all that flaming (makes me wonder about your priorities):

Did anyone care about the crashes at the end of the encoding in the meantime?

[x265.cc]

I am sorry that I have lost a thread in all that flaming (makes me wonder about your priorities):

Did anyone care about the crashes at the end of the encoding in the meantime?

No errors in the build logfile. Looks like a clean build.

Build with out of the box MS VC 2012 Ultimate Update 3 + yasm 1.2.0, _could_ be a source related problem

//edit: currently test encoding it myself with the latest binary

//edit2: x265_0.4.1+396-1d6b3626f1b3.zip (VC11 x86_64) ..no crash:



I've used your encoding settings on an Windows 7 SP1 x64 System.

[LigH.de]

All the x265 0.4.1+396-1d6b3626f1b3 builds (MSYS as well as VC11, x86 as well as AMD64) crash too, after reporting the PSNR statistics (despite '--no-psnr' option).

It can be quickly checked by stopping the encoding progress with Ctrl+C, even then it crashes (and the MSVC builds crash even twice!).

x265 0.4.1+39-4014edcf2157 by El quits gracefully. Therefore I suspect some uncleaned stack/heap state or similar. The most annoying side effect is an incomplete output bitstream.
__

P.S.:

Your encode quit without crash? Interesting, then there is indeed a difference between our systems. Windows 7 SP1 x64 here too, just German locale. And only VC11 redist (opposed to SDK); but that shouldn't matter as the MSYS build crashes too ...

Ehm, huh? This time no crash.

[x265.cc]

All the x265 0.4.1+396-1d6b3626f1b3 builds (MSYS as well as VC11, x86 as well as AMD64) crash too, after reporting the PSNR statistics (despite '--no-psnr' option)

Oh okay. I've used your

x265.exe xx.y4m -o xxx.hevc -F 3 -q 12 -b 3 --b-adapt 2 --bframe-bias 30 --ref 3 -i 240 --weightp --no-psnr --ssim --rdpenalty 1 --csv xxx.csv

options, without crash.

CLI arguments, date/time, elapsed time, fps, bitrate, global PSNR, version
-o xxx.hevc -F 3 -q 12 -b 3 --b-adapt 2 --bframe-bias 30 --ref 3 -i 240 --weightp --no-psnr --ssim --rdpenalty 1 --csv xxx.csv xxx.y4m, 10/17/13 08:26:47, 275.51, 1.09, 763.95, 99.99, 0.4.1+396-1d6b3626f1b3

[LigH.de]

The last tests could be stopped without crashing. What makes me nervous is the fact that there was a brief internet outtage during the crashing tests.

One bug remains, --[no-]psnr and --[no-]ssim are not functional currently. No big issue, but might reveal a break in the chain of option parsing?!
__

P.S.:

They crash when the option "--weightp" is enabled. The non-crashing tests did not crash because I removed that for compatibility with 0.4.1+39.

[deadrats]

I've been speaking with top technical teams at most of the major movie studios, post production houses, pro and consumer video equipment companies, application developers, video services, broadcasters, etc., and we haven't had one request for stdin input. I'm not saying we won't ever or don't want to add this feature, or that it isn't important for the wider open source community, but your assumption that everyone requires it or is asking for it is not accurate.

maybe the reason none of them have explicitly asked for it is because they just naturally assume that such basic functionality is one of the first things you guys would include, not the last, if ever.

i know for a fact that many studios shoot movies and commercials with Sony Red One cameras, a digital camera that in REDCODE RAW format, a lossy format. you're telling me that no "top technical team" from "most of the major movie studios" has said to you "hey, how about supporting stdin input so that we can feed our edited movies into your encoder"?

if this is in fact 100% true then i hate to break it to you they have zero interest in your product, if they did they would want to test the encoding quality of your product.

Switch to what? Once you offer your software under the GPL you can never go back.

that is a flat out lie. the author of the software still owns the copyright to the software. there is nothing to stop you from taking the project closed source at some point in the future or switching to a different open source licensing scheme like the bsd or cddl license. hell the x264 guys did the same thing, they "forked" the software so that two versions exist, one under the gpl and one under the commercially friendly license, there zero stopping them from waking up one day and saying "we're stopping development of the gpl version, the community can use it as it sees fit but we will continue developing the commercial variant and keep any improvements just to that one".

Oh sure... another feature request!

that's not a necessarily a feature request, more like a suggestion, as i told you before if you want to have a marketable product that can generate substantial cash you have to go down a different road than the one you guys are on because you are way far behind your 2 major competitors and it's not likely that you will catch them.

The HM reference encoder can take minutes to encode a single frame of 4K video (on a fast machine). It is single threaded. x265 is coming along nicely, and is highly multi-threaded. In some of my tests x265 is 200X faster than the HM with full HM reference quality (and this is just on a notebook... the X factors are much higher on a server with many CPU cores). We can further multiply these X factors significantly with very little trade-off in encoding efficiency. But hey, if you like the HM, knock yourself out. I like to get my encoded video streams back in the same day, but that's just me.

to quote Andy Dufresne "how can you be so obtuse? is it deliberate?".

are you 5 years old? do i really need to spell it out for you? first you port the reference encoder to CUDA so that it works and then you work on threading it like you claim to have done with x265. for a guy that claims to have a team of highly skilled engineers that are experts in gpu powered encoders you certainly come off like you have a tenuous grasp of the english language let alone any real expertise in programming.

Have you done any GPU accelerated software development Deadrats? Many parts of the encoding process are serial in nature, and there are many dependencies. It would never make sense to port the entire encoder to run on the GPU. The real question is, what can be accelerated, and how best to accelerate it?

didn't you just say that x265 is "highly multi-threaded", those are your words right, i didn't imagine reading them, did i?

the reason i say to run the entire encoder on the gpu, as i pointed out, goes beyond pure performance reasons. as i stated, with an encoder that runs entirely on a gpu the product becomes very appealing to end users because now instead of having to invest big bucks in a dual socket multi-core setup with lots of ram and have to go through the trouble every time you want upgrade of having to reinstall the OS and software they can just upgrade their video card and call it a day. furthermore, where an intense 4k encode will load up all the cores of your cpu and eat up all your ram and effectively minimize what you can do with the pc while the encode progresses, an encoder that runs solely on the gpu you can add a second video card just for encoding and let that churn away while the rest of your pc is basically at idle.

that's one of the things i love about intels quick sync technology and why i hope they add hevc encoding soon, i can and have bought a cheap dual core SB based setup with the cheapest motherboard and ram i can find and used QS to do high bit rate 1080p encodes super fast while the cpu load was barely above idle.

i remember when cuda first came out and the first cuda encoders were released DS tried to port portions of x264 over to cuda (you can find his posts over at the nvidia developers forum) but didn't know what he was doing and so eventually gave up. he and his cohorts then took to various forums and blogs and basically shit all over cuda and gpu powered encoders, ripping them with some of the most retarded claims imaginable and decrying their quality and the ability of a gpu powered encoder to achieve the same quality as a software based encoder.

2 things though prove that he was full of shit and didn't know what he was doing: gpeg2, a gpu powered mpeg2 encoder that is no longer available that produced outstanding quality mpeg-2 and the elemental guys. since you claim to have so many industry contacts set up a meeting with the elemental guys that have full gpu powered vc-1, mepg2 and h264 encoders, with their h264 encoder that is not only faster than x264 but offers superior quality to boot.

want to see what real professional programmers can do with a gpu powered encoder? Oct 22-24 where they will demonstrate real time 4k hevc encoding on a gpu:

http://www.elementaltechnologies.com/

i will also give you another suggestion, i don't know how old you are but do you remember the "old" days of math coprocessors, basically it was a discrete floating point unit. i don't know if you ever coded for them using fortran or pascal or c but back in the day the way you used them was as a separate calculator, where you ran the calculations that needed that level of precision on the coprocessor but the actual use of the results was carried out on the cpu.

you should consider potentially implementing gpu acceleration in a similar fashion. one of the mistakes DS made early on was that he tried to have those early cuda cores perform parts of the actual encoding and he found that any speed benefit from having the gpu do the work was neutralized by the wait of having to shuffle data between the cpu and the gpu over the pci-e bus.

a smarter way would be to treat the gpu as a coprocessor and simply have it perform all the calculations that need be performed but return the results to the cpu for it to use during the encode process.

such an approach should make it much easier to fully utilize all the cores of a gpu without having to worry about latency from having saturated the pci-e lanes and there would be no possibility of a visual quality loss.

where there's a will there's a way, i really don't believe that there's any will on your part.

i'll leave you with this thought: it took years for h264 to gain any traction as it was too computationally intense for computers of the day and it took a while for companies to see the writing on the wall and start offering hardware based h264 encoders. i don't think the same will be true of hevc.

hevc has generated so much buzz and interest in such a short time that one has to believe that intel will be adding hevc support to QS and one would also have to believe that nvidia is actively looking into adding a hardware hevc encoder to their products. hell, you guys have a half assed implementation that basically useless and a thread about your cheesy encoder has almost 600 posts, the interest in hevc is intense.

you guys are behind the 8 ball, the development process is being run by knuckle scraping chimps, something as simple as std::in is persona non grata in your software and you already have 2 major competitors with working products, ready to be licensed and implemented now that produce excellent results.

are you a betting man? what do you think the over/under should be on when the first commercial encoding and/or editing solution will license your product and implement it in there offering? how about NEVER. that's right, i predict it will be a cold day in hell before any commercial, non-open source application includes x265.

i'm sure the free oss apps like handbrake, xmedia recode, media coder, avidemux and the like will include support but who really cares about them, right? they won't put a dime in your pocket, so other than some false prestige it doesn't do you guys any good.

x265 is destined to be a footnote and a bad one at that.

[x265]

I am sorry that I have lost a thread in all that flaming (makes me wonder about your priorities):

Good point.

Did anyone care about the crashes at the end of the encoding in the meantime?

You may have noticed all of the patches that have been committed in recent days. Things should be stabilizing in the next day or so.

Tom

[DarrellS]

Hard to produce a working file when every encoder uses a different command line. Every file I try to create ends with a crash in the encoder and the out put, although it kind of plays (corrupt frames) crashes every player.

Working sample commands would be nice for each encoder so we can tell if it's our command line or our system that refuses to create a working file.

I just formatted a spare drive and will install a back up image of my operating system when I knew everything was working fine. I've installed and uninstalled so much crap the last couple of months trying to get 265 and VP9 to work that I don't know how much damage I've done to the operating system.

Maybe XP with 4GB of memory and a Q6600 cpu is just not good enough to create a working file.

I have Q6600 and XP SP2. No problem whatsoever in handling Full HD videos from Youtube. Encoding is slow, but then so was encoding using Avisynth with complex filters. For the record, I get close to 1.5 fps.

That post was early in testing and the problem WAS with the commandline and Windows XP. Switching to -no-wpp fixed the problem at the time. Upgrades to the encoder fixed that problem. I have no problems now, encoding 1080p with the x265.exe encoder but like you stated, it's pretty slow. Not as slow as the earlier releases but still slow. I don't remember how much faster encoding standard definition was. Seems like I was getting close to 10 fps.


My major concern with the encoder is the lack of input through pipe. IMO, this should've been the first implementation for testing the encoder.

[Jacobr]

thread going a little bit off track ?

That post was early in testing and the problem WAS with the commandline and Windows XP. Switching to -no-wpp fixed the problem at the time. Upgrades to the encoder fixed that problem.
My major concern with the encoder is the lack of input through pipe. IMO, this should've been the first implementation for testing the encoder.

i will just bump because of issues i have with encodes with frame parallelism and --b-adapt 2. I used one of recent binaries from x265.cc 0.4.1.
trying to play it back with that lentoid decoder .14 version showed something like in attachment

 --q 16 -F2 --keyint 80 --b-adapt 2 -b 3 --bframe-bias 30 --ref 3 --max-merge 5 --me 3 --rect --hash 0 --rd 0 --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip --no-tskip-fast

btw, in my humble opinion, stdin should be there too. really should

[El Heggunte]

Jacobr, does the same error happen with the Osmo player, or the Reference Decoder ???

If "no", then the problem is in the Strongene decoder, but if "yes", then the problem is in x265 itself.

[vhelp]

jacobra--

is that animation/cartoon ? these are probalematic at times.
which video did you test playback on ? ie, mpc, or osmo4, or did you mux then play in osmo4 ?

if you muxed to mp4, only the osmo4 sw player will play it. nothing else (after muxing to mp4) will at this time.
if you are aiming at playing in a playable players (audio/video) the osmo4 sw player will do well.
but, you must mux properly for it to work or else you'll get issues like in your example.

use the following muxing method, assuming your video is video.hm10 to start with:

w/out audio
mp4box -add g:\video.hm10:fmt=hevc: -fps 23.976 -new g:\video.mp4

w/audio/video
mp4box -add g:\video.hm10:fmt=hevc: -fps 23.976 -add g:\audio.aac -new g:\video.mp4

i used your exact param and all went well. if video.hm10 file palyed in mpc-be (no audio) perfectly, and when muxed using above method, played w/out problem in osmo4 sw player.

edit: added two files, video.7z is video.hm10

ps: i am still using the older lentoid decoder.

[LigH.de]

You may have noticed all of the patches that have been committed in recent days.

Only marginally; not by following the commits log, only by the rapidly rising revision number...

Things should be stabilizing in the next day or so.

Your patience-practicing padawan.
__

@ El:

Do you still release too?

[tnti]

http://sourceforge.net/projects/mpcbe/?source=navbar
HEVC decoding support

Home / MPC-BE / Nightly Builds (from svn trunk) / MPC-BE v1.2.1.0 -dev build 3557

[LigH.de]

Always "one step beyond" MPC-HC.

[El Heggunte]

@ tnti: Thanks for the info ---

--- or not

@ El:

Do you still release too?

The appropriate answer would be longer than 8kB, which is far beyond your patience threshold

[LigH.de]

What a pity. So it is not simply a link to the next "suspicious filehoster abuse".

[Jacobr]

jacobra--

is that animation/cartoon ? these are probalematic at times.
which video did you test playback on ? ie, mpc, or osmo4, or did you mux then play in osmo4 ?

if you muxed to mp4, only the osmo4 sw player will play it. nothing else (after muxing to mp4) will at this time.
if you are aiming at playing in a playable players (audio/video) the osmo4 sw player will do well.
but, you must mux properly for it to work or else you'll get issues like in your example.

Thx for replies guys

Yea, it was anime and i muxed at first to mkv, but nothing will play it or even raw stream ( lentoid just sucking i guess )
I used the reference decoder and it did the job nicely. will try my luck with mp4 mux and osmo4 later on today, cause earlier i wanted to play it (mp4) and it showed *very* similar artifcts all over

Yours sample plays no problems btw, in mpc
ps. ill try and if i cant get it working ill post the sample encode

[tnti]

X265 is not yet ripe
This is the reason for the standard input is not supported

[Selur]

@tnti: what goals does it have to meet to be 'ripe'?