[HEVC] x265.EXE: mingw builds

[LigH.de]

The developers of x265 must make it compatible, vdub is excellent and easier than boring command line.

VirtualDub is foremost an AVI editor; and the AVI container is outdated, becoming obsolete. It has no B-frame support, therefore stuffing MPEG4-ASP (DivX, Xvid) in it was already "a hack" (with "packed bitstream" or the other technique whichj I never remember). It gets even worse with people trying to stuff MPEG4-AVC (H.264) into AVIs, even though it cannot separate I and IDR frames, and certainly not handle B-frames with multiple references. I hope noone will ever try to stuff MPEG4-HEVC (H.265) in the AVI container.

Being able to feed external encoders via pipe is nice, but not the purpose of VirtualDub.

Make the x265's settings easier and less, using too many functions to encode waste more time of humans.

Of all readers here, you have to demand that?! How about reading the "help" output of x265.exe before asking for a ready-made command line set? And isn't coloring and size-changing your post like confetti wasting your precious time you should have spent reading the available documentation with, instead?

And in general:

Developers shall at first focus on the features, not on the interface. Interface is for users. There are no users yet, because the encoder is not yet meant to be used. Only to be tested.

It's like complaining about the color of the lacquer before even the engine of the car is done.


Sorry for violating the Netiquette with this rant.

[DarrellS]

This is the misconception of almost everyone on the Doom9 forum and a few users here. Virtualdub has long since been an AVI editor. I hardly ever edit AVI anymore cause there just isn't that much AVI out there anymore. Everyone went to AVC years ago with the release of x264 in every container imaginable and with the right plugins you can edit just about anything in Virtualdub. Today, Virtualdub is much more than any modded version ever dreamed of being which is why I think everyone over at Doom9 is so anti Virtualdub and Avery Lee. A lot of the people over there built those modded versions or filters for Virtualdub. Besides all the input plugins and ACMs that fcchandler created, the Curve Editor pushed Virtualdub into another realm which made a lot of those special filters obsolete and Smart Rendering gave Virtualdub the ability to do frame accurate editing without having to re-encode the whole file. Now, the External Editor has made frame serving obsolete since you can now do all your editing and encode to just about any file type you want and put it in just about any container you want. All that is needed is a command line encoder that accepts "stdin or "-". The x265 encoder may never work in Virtualdub like the x264 encoder does but ffmpeg will make it possible to encode to x265 in Virtualdub when they implement the decoder and encoder. Hopefully that won't be too far away and we can stop having to create these stupid y4m files.

[LigH.de]

Well, alright; AVI may be an outdated format, but VirtualDub can still be a useful tool. I still do appreciate the legacy of Avery Lee, it is a quite clean and straight tool. Nevertheless, being based on VfW, it has its limits.

[LigH.de]

The competition is going public:

DivX 10 with HEVC plugin

[DarrellS]

Alright, I'm confused. I downloaded and installed DivX 10 from the above link and nowhere in the program files folder does it mention HEVC. When I tried to use the encoder, there were two profiles for HEVC but they were both grayed out and stated that the profiles were not yet available and that support is expected soon.

If the video on their website is HEVC then the web player works fine but it seems like they released the encoder before it was ready to be released and without support from mkvtoolnix and until they release an HEVC version of mkvmerge then the encoder is useless to anyone that is not capable of building their own mkvmerge.

[LigH.de]

You will probably have to get a HEVC plugin for DivX.

I am not very interested in installing it. It will be either crippled or expensive.

[El Heggunte]

Even if the DivX Bundle were not a meddlesome piece of bloatware, I would not use it for anything except some "disposable" encodes. As JEEB pointed out, it's improbable those MKVs will be accepted by the "normal" Matroska demuxers and splitters:

Originally posted by JEEB

Too bad they're using their ad-hoc HEVC-in-Matroska thing specified here. Matroska-devel more or less decided to wait for 14496-15 AMD2 (HEVC FF) to copy the extradata off of. And that still hasn't been pushed out for the last ballot . Last I heard there really weren't any changes done to it for like over a month or so, either. It's just not being pushed out.

For the time being, the "V_MS/VFW/FOURCC" approach still is the way to go, since it's compatible with LAV splitter and the Lentoid decoder, and therefore, playable in any decent DirectShow-based player.

[DarrellS]

I figured I got duped into installing this piece of crap again with promises of hevc encoding and decoding. I just removed it a couple of weeks ago because one: it can't encode hevc (I guess you have to buy the main concept encoder) two: it can't mux the hevc files because mkvtoolnix does not support the format, three: the player can't play any hevc files that I have and four: it likes to take over your system.

The whole time the software was installing it was telling all the things the new version can do and it can't do any of it without installing more plugins and encoders that it doesn't mention anywhere. I've googled for hours trying to find a DivX hevc encoder and there is not one to be found. The only way to get the muxer is if you are a programmer who can create a new build and according to mkvtoolnix, it can't be created on a Windows machine.

[DarrellS]

You will probably have to get a HEVC plugin for DivX.

I am not very interested in installing it. It will be either crippled or expensive.

I downloaded the only hevc plugin I could find and it is only for decoding.

[Jacobr]

You will probably have to get a HEVC plugin for DivX.

I am not very interested in installing it. It will be either crippled or expensive.

I downloaded the only hevc plugin I could find and it is only for decoding.

I had very bad experiences with previous release, i was pissed off about all the needless stuff it installed and processes it always kept running ( some updaters, schedulers, lots of stuff ), plus reg entries left all over the place after uninstalling, plus plugins problems etc etc ...
As for hevc plugin i didnt find encoding one either

As a side note, im still messing around with my gui, had problems with avi->mkv, so now i actually abandoned muxing to avi altogether and just am muxing mp4, then optionally mp4->mkv.
I was trying to get it working through mpc-hc muxer, i would get hevc stream into preliminary mkv with that ds muxer, but it wouldn't update the resolution of source hm10 file, suprisingly enough with avi muxer, it all would get updated, wonder if you have any ideas why.
Asking, because now i always need gpac to run things, before i would just ds mux to 1st mkv then remux [+subs&chapters] mkv->mkv.

[Skarstorm]

If you want to mux the files encoded with x265 into MKV so you could use DivX 10 Player to watch your video instead of using gpac & MP4box MKVToolNix v6.2.0 binaries (Promised Land Rovi v1.0.1) is the answer.
@ http://labs.divx.com/node/127905

[El Heggunte]

......

I was trying to get it working through mpc-hc muxer, i would get hevc stream into preliminary mkv with that ds muxer, but it wouldn't update the resolution of source hm10 file, suprisingly enough with avi muxer, it all would get updated, wonder if you have any ideas why.

Are you sure you meant "resolution" and not "frame rate" ?

Anyway, now that the Lentoid Source Filter can output the correct frame rate from the HEVC streams, you might use their modifed FLV muxer as well --- ¿ or not ?

[El Heggunte]

If you want to mux the files encoded with x265 into MKV so you could use DivX 10 Player to watch your video instead of using gpac & MP4box MKVToolNix v6.2.0 binaries (Promised Land Rovi v1.0.1) is the answer.
@ http://labs.divx.com/node/127905

Even better --- mux to MP4 with MP4Box, BUT play under DirectShow with the Strongene MP4 Demultiplexor.

Reasoning:

There is no standard for HEVC in MKV yet, and until there is, LAV will not support it.
And once there is, the DivX MKV files will not be compatible with the standard anyway.

Such a company should not invent their own format, instead coordinate with the Matroska developers. Their old files will in the future most likely not play properly in compliant players.

{ source: http://forum.doom9.org/showthread.php?p=1643046#post1643046 }

[DarrellS]

But the --wpp HD files will not play in any other player except the GPAC player. You have to build the MKVToolnix from the binaries so until someone (here preferrably) creates a build from those binaries since MKVToolnix is not, we cannot mux the x265 files with mkvmerge. I have MKVToolNix v 6.3.0 which is Promised Land Rovi and it will not mux x265. only the special build that you have to build yourself because neither divx or bunkis will build it.


I think the problem is with the x265 encoder though because these HD --wpp files will not work in anything (except the GPAC player but they're not giving up their secret). Virtualdub and MPC-HC will open the files but they are corrupt. The Divx mkv won't open in anything but the divx player. Not MPC-HC, Virtualdub or Graphstudio.


I encoded a 7 minute music video with the divx encoder and although the video looked great in the divx player, the ac3 audio was all scratchy sounding. I tried to open the video in MPC-HC which threw up an error about the DivX Demux filter but the audio played fine in MPC-HC.

[4h8s]

The developers of x265 must make it compatible, vdub is excellent and easier than boring command line.

VirtualDub is foremost an AVI editor; and the AVI container is outdated, becoming obsolete. It has no B-frame support, therefore stuffing MPEG4-ASP (DivX, Xvid) in it was already "a hack" (with "packed bitstream" or the other technique whichj I never remember). It gets even worse with people trying to stuff MPEG4-AVC (H.264) into AVIs, even though it cannot separate I and IDR frames, and certainly not handle B-frames with multiple references. I hope noone will ever try to stuff MPEG4-HEVC (H.265) in the AVI container.

Being able to feed external encoders via pipe is nice, but not the purpose of VirtualDub.


Sorry for violating the Netiquette with this rant.

It is more than .avi. Vdub's External Encoder can encode into .mkv...... .avi is poor, .mkv can store a lot of things inside. Vdub has good video filters too and can edit (cut, copy, paste, delete) frames.

I never use .avi as my container. .mkv is best.



The External Encoder is powerful.

It's like complaining about the ...

Not complaining, it is recommending, an advice, or an improvement. It should be easy.

[Vid01]

MulticoreWare pushed a new stable just a few hours ago. Here is the build for revision 98f0f7dde384:

Note this version defaults to a b-frames number of 3. Use -b0 to get the previous all-P frame behavior.

[Jacobr]

MulticoreWare pushed a new stable just a few hours ago.

Thx for that!
Wokrs fine, bframes enabled it seems yet slower that previous with them enabled too ( was down to 0.17fps with 848x480 at -b1 )

Are you sure you meant "resolution" and not "frame rate" ?

Anyway, now that the Lentoid Source Filter can output the correct frame rate from the HEVC streams, you might use their modifed FLV muxer as well --- ¿ or not ?

I did mean resolution which is why i was surprised. So do you think flv muxer is an option? mp4->mkv is my way to go now since the dimensions get updated, and i really want mkv as final container of auto-convert, so flv would be a stage also ( graphstudio possibly again ?) .
Someone here said bad things about stuffing hevc into avi ... well, been there, done that - it works except for bframes

As a general thing, seeking troubles rly start to piss me off, even osmo4 would crash/stall for me, i opened that encoded mkv with wmp ( lolz ) and only there it would "work" - meaning stall for ~20s and then laag for ~10s and then voila !

[Acetyl]

I've noticed that lossless modes are broken in the latest builds. A setting of --qp 0 seems to produce results that aren't lossless, both subjectively and objectively. (not to mention that a lossless 1080p encode with high motion isn't usually going to be 5 mb/s).

QP settings themselves don't seem broken, their spectrum just doesn't span from minimum quality to lossless. Happens regardless of other settings.


I'm building with vc11, but that shouldn't make any difference. Thought I'd mention it though, it was introduced at the same time they pushed a stable revision. Can anyone else reproduce this?


Doubt the problem isn't already known, unless it was something I did.
http://screenshotcomparison.com/comparison/41383

[vhelp]

i used the q=0 setting on my usual 122 frame test clip, it took aprox 4x longer to encode.

usual size for 122 frames is .663kb, the q=0 encoded to 6.1mb size.

it must be the param string you used. post yours.

[Acetyl]

--input "C:\Editing\Output\gits.yuv" --input-res 1920x1080 --fps 23.976 --rc-lookahead 16 --bframes 16 --rect --me 4 --wpp --amp --output "C:\Editing\Output\gits.hevc" --qp 0

are my typical test parameters, usually with only qp changing. I've tried switching these around (no bframes, no rect / amp, -q / --qp, default lookahead, no loop filter, no sao, etc), same result.

[vhelp]

i mainly use this param string since its the fastest on my very slow amd dual core desktop. i get aprox 0.75 fps encoding speed.

--frames 122 --qp 20 --keyint 24 --rect --max-merge 1 --hash 1 --wpp --no-rdo --no-rdoq --tu-intra-depth 1 --tu-inter-depth 1 --no-tskip --input "g:\video.y4m" -o "g:\video.hm10"

if i use yours, then it goes down to 0.02 fps or about 4 hours. so i lowered your 16, 16, 4 down to 2,2, 2 and the test encode says it will finish in 45 minutes. i'm at 29.5% complete, or 36 of 122 frames current filesize says 1.396mb so far.

[DarrellS]

MulicoreWare better get their asses in gear. DivX HEVC now has command line encoder and HEVC mkvmerge to mux the files. This encoder accepts Raw input, AVS input, AVI input and Piping from stdin.Works great in Virtualdub with the external encoder.

Encoder
http://download.divx.com/hevc/DivX265.exe

Muxer
http://download.divx.com/hevc/mkvtoolnix6.2.0-promised_land_rovi_v1.0.4.zip


Command line argument for Virtualdub external encoder


Video Encoder
C:\Tools\DivX265.exe
-i - -s %(width)x%(height) -br 4000 -o "%(tempvideofile)"
%(outputname).hevc


Multiplexer / video only
C:\Tools\mkvtoolnix6.2.0-promised_land_rovi_v1.0.4\mkvmerge.exe
-o "%(outputname)" --default-duration 0:%(fpsnum)/%(fpsden)fps "%(tempvideofile)"

Multiplexer / video and audio
C:\Tools\mkvtoolnix6.2.0-promised_land_rovi_v1.0.4\mkvmerge.exe
-o "%(outputname)" --default-duration 0:%(fpsnum)/%(fpsden)fps "%(tempvideofile)" "%(tempaudiofile)"



Not as fast as x265.exe. Encodes a 720x480 file at 2.75 fps on my machine. You need the DivX player to play the MKV files.



EDIT: --default-duration 0:%(fpsnum)/%(fpsden)fps does not work with the Rovi version of mkvmerge. You'll either have to enter the actual fram rate of your video or remove the muxer from your encoder set and manually mux the files after creation.


You'll need to place a copy of mmg.exe from MKVToolNix 6.2.0 to the Rovi MKVToolNix folder to use the muxer. The Rovi build does not come with a gui.

[El Heggunte]

To whom this may interest ,

the user Derek Buitenhuis has been ing the x265 mailing list very-well. Example:

From: Derek Buitenhuis <CENSORED@gmail.com>
Reply-To: Development for x265 <x265-devel@videolan.org>
To: x265-devel@videolan.org
Subject: [x265] x265: Questions and comments from an outsider
Date: Thu 2013-09-12 11:03 AM

So rather than break up all these (very general) comments between N
separate emails,
inlined in patch reviews, I figured one canonical place to air them
should be more
appropriate and conducive to open discussion.

In no particular order, some comments:


Code Style (or Lack Thereof)
----------------------------

Currently, x265 is a giant mess with no consistent code style,
practices, or guidelines.
Certainly nothing is enforced. Below is a list of issues to discuss
related to this.

1) Indentation: How many spaces do you indent? This is inconsistent
throughout the codebase,
patches regularily get pushed which randomly change it -- likely due
to haphazardly copy
and pasted code. This should be set and enforced, no? Perhaps a push
hook that LINTs the
patch? This is what Libav does.

2) Variable & Function Names: Again, inconsistent. some members have a
MS-style 'm_' prefix,
some have no prefix. Some have an 'n' prefix. Some have an 'x265_'
prefix, which ideally
should only be used for public API function namespacing.

3) References vs. Pointers: Self explanatory -- usage is inconsistent
between const pointers,
references, pointers, etc.

4) Function Code in Headers: Is this acceptable? Is there policy of when
to do this? It's done
seemingly at random currently, and is very confusing/ugly.

5) Formatting: Whitespace, code layout etc. Braces on ae line or next?
When? How to format
an 'if' statement? if(x)? if (x)? if( x )? if ( x )? Stuff like that.
VERY inconsistent.

6) Header Guards: Non-generic header guards are needed so as to not
contaminate the namespace
or conflict with system headers. __LIST__ is a good example of a bad
guard.

Certainly these sorts of things need to be enforced to some extent
within reason, or the codebase
is only going to get even more bad/messy.


Reviews (or Some Are More Equal Than Others)
--------------------------------------------

Some developers do not have their code reviewed. Some do. This sort of
thing won't go
down so well with community contributors, I think.

Also, developers mostly seem to send their code for review, but aside
from Steve, nobody
seems to review others' work.


Commit Messages
---------------

They're quite bad.

I understand that English is not the native tongue of many of the
developers, and I
think that they would have an easier time if there was a clear and
concise set of
rules for creating commit messages defined somewhere for them to follow.
A checklist,
perhaps. It's been my experience that this would help non-native
speakers, but that's
only one man's hearsay.


Memory Allocation/Reallocation/Freeing
--------------------------------------

It's a mess. A big one. The codebase is a tangled mess of inconsistently
used malloc(),
free(), new, delete, X265_MALLOC(), and X265_FREE(). X265_REALLOC() does
not exist. So,
which is it? Make up your minds! This will affect an future C ports.


Reimplementations of STL and Related Identity Crises
----------------------------------------------------

Why are you reimplementing STL classes like std::list? I could
understand if it was in C,
so as to aid in the promised future port to C, but it's being done in
C++, using new and
delete, etc. This makes no sense. There's no reason to do this other
than some misguided
Not In House syndrome or obsession with the resulting binary size. So,
uh, what?


Communication
-------------

Only Steve ever seems to be available on IRC, and since he travels a
lot, it's very cumbersome
to interact with the developers in real time. I don't even think the IRC
channel is listed on
the wiki page for contributing.


Intrinsics
----------

When will they die? When will new ones stop getting added? This may have
been answered already,
but I didn't hear/see anything.


Priorities
----------

This is by far the most concerning aspect for me, as an outsider. The
priorities for x265 seem
to be geared towards demos or a 'cash out'. Rather than making the
encoder *good*, first priorities
have gone to making it fast. This seems very backwards. Similarly, the
most useless ratecontrol
method is the only method being worked on, since MCW wants to demo HLS,
as far as I can tell.

Second to this, is that I don't completely trust that MCW will not
either stop work after
it demos / cashes out (or x265 is 'good enough'), or won't backseat
important things for the
sake of demos, etc.

I've seen Bad Things™ happen with corporations involved in FOSS time and
time again, so you
could say I'm once burned, twice shy.


</list>

I am sure I am missing some things, so any community members should add
any I forgot.

- Derek

[Selur]

my opinion to that:

• respect to Derek Buitenhuis for his work on ffmpeg/libav
• "Code Style...": points 1&5 are just ridiculous (doesn't he have an IDE which can fix this for him?) the rest I would agree on
• "Reviews": are always a problem, when you don't have paid people who do and like it (because most of the time it is totally boring)
• "Commit Messages": I agree some basic guide lines wouldn't hurt (but I don't think is really is much of a problem
• "Memory Allocation/Reallocation/Freeing": I agree that some consistency there really would be a good idea (but I don't see someone doing the necessary adjustments throughout the code)
• "Reimplementations of STL and Related Identity Crises": don't get that either, but never really looked into it
• "Communication": "to interact with the developers in real time" <- on a free project where the developers live in different time zones and have a normal job to attend too? Sorry, but sounds like a pipe dream to me.
• "Intrinsics": some guidelines wouldn't hurt
• "Priorities": can't say much about it, personally I too have mixed (but not as negative/paranoid) thoughts about MCW and x265.

As a side note: the whole chaos around coding style, commit messages, etc. isn't just negative. The lax of 'rules' also doesn't 'restrict' people.

[vhelp]

regarding the 98f0f7dde384-Vid01 build, the lastest so far.

I've noticed that lossless modes are broken in the latest builds. A setting of --qp 0 seems to produce results that aren't lossless, both subjectively and objectively. (not to mention that a lossless 1080p encode with high motion isn't usually going to be 5 mb/s).
.
.
--input "C:\Editing\Output\gits.yuv" --input-res 1920x1080 --fps 23.976 --rc-lookahead 16 --bframes 16 --rect --me 4 --wpp --amp --output "C:\Editing\Output\gits.hevc" --qp 0

are my typical test parameters, usually with only qp changing. I've tried switching these around (no bframes, no rect / amp, -q / --qp, default lookahead, no loop filter, no sao, etc), same result.

--frames 122 --qp  0 --rc-lookahead 16 --bframes 16 --rect --me 4 --wpp --amp --input "video.y4m" --output "video.hm10"
--frames 122 --qp  0 --rc-lookahead  2 --bframes  2 --rect --me 2 --wpp --amp --input "video.y4m" --output "video.hm10"

i used your params on my home deskto pc and the encode completed successfully.

however, when i fed those same params to an i3 at work, the encode stalled on the same frame number, 68 of 122, every time. when i checked taskmgr, the cpu % was always at 25% every time. so i got the impression it was (casually) stuck at frame 68 trying to decide what to do next while grazing 25% of cpu.

[mgh]

peculiar problem on my XP SP2.
Encodes to flv with audio using Lentoid encoder in GraphStudio, always play in windows media player and media player classic with the Lentoid decoders.

Encodes with x265 are perfectly playable once in a while. I have used parameters with which people have had success here. Most of the time, they encode beautifully, I get decent PSNR values as well as bitrates, and they have a black screen on playback.

I have checked that intermediate y4m files are OK using ffplay.

Is it because the Lentoid decoders are outdated?

[El Heggunte]

................

Is it because the Lentoid decoders are outdated?

First of all, decode the problematic streams through the latest HM Reference Decoder. IF the output looks broken, then you can bet the fault is of x265 itself --- otherwise, then the fault is of the Lentoid decoder.

[mgh]

................

Is it because the Lentoid decoders are outdated?

First of all, decode the problematic streams through the latest HM Reference Decoder. IF the output looks broken, then you can bet the fault is of x265 itself --- otherwise, then the fault is of the Lentoid decoder.

Where to get it?
Anyway, thought maybe problem because of trying to play elementary stream, so decided to mux a file into a container.
The file concerned could not be loaded in Graph Studio at all, so tried mp4box muxing to mp4. The muxing worked, but file wouldn't play in Osmo.
Just now tried loading the mp4 file manually using Strongene mp4 demultiplexer in GraphStudio, and rendering it to play. Success

[El Heggunte]

Where to get it?

mgh

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2262853&v...=1#post2262853

Anyway, thought maybe problem because of trying to play elementary stream, so decided to mux a file into a container.
The file concerned could not be loaded in Graph Studio at all, so tried mp4box muxing to mp4. The muxing worked, but file wouldn't play in Osmo.
Just now tried loading the mp4 file manually using Stromgene mp4 demultiplexer in GraphStudio, and rendering it to play. Success

With the latest Lentoid decoder and source filter, it should be possible to load and to play "raw" HEVC streams in Graphstudio --- and even in ActiveMovie OCX, just for fun

Just another wild guess ---
--- maybe the Strongene filters and/or the Osmo player are not entirely-compatible with XP's SP2.
Generally speaking, programmers who still care about Windows XP expect everybody to have already upgraded to SP3.
You have been warned.

[mgh]

[QUOTE=El Heggunte;2267897]

Where to get it?

mgh

[QUOTE]

Deservethat

With the latest Lentoid decoder and source filter, it should be possible to load and to play "raw" HEVC streams in Graphstudio --- and even in ActiveMovie OCX, just for fun

Just another wild guess ---
--- maybe the Strongene filters and/or the Osmo player are not entirely-compatible with XP's SP2.
Generally speaking, programmers who still care about Windows XP expect everybody to have already upgraded to SP3.
You have been warned.

Raw files play sometimes in Graphstudio.

Last time I tried loading in OSMO through right click on file- nothing. Tried again now to load file by opening OSMO and then opening file. Opened but shows only part of the video frame.

Tried another encode
Plays properly only when muxed through mp4box to mp4 ( have a 3 or 4 day old nightly build), and then through strongene mp4 demultiplexor in Graph Studio.

I had also suspected something to do with the XP SP2. Or may be I need to adjust the merits of the concerned directshow filters. I know how to go about it safely ( have done it a couple of times on my earlier machines). Have been a bit lazy, because that needs full concentration.

Thanks, you have given me a possible answer, let me check it out thoroughly.

Do have another machine with Wiin7 64 bit, about 20 % faster than this one.

Edit: After fiddling with OSMO aspect ratio menu, the videos play correctly now.