Are there any programmer,who can create vfw/directshow based X265 encoder?

[racer-x]

I don't know of any "Smart Rendering" editors for hevc sources, but you can do cuts on key frames and export stream copy with ffmpeg or a gui for ffmpeg like XmediaRecode. I'm guessing smart rendering of hevc sources won't come until there is real demand for that. I have little interest in those things anyway, I prefer a full fledged NLE for 95% of my video work.

[Mpxplay]

x265vfw v120 is updated with decoder side and x64 version. The direct stream copy (with VdubMod) and dshow playing (with Mpxplay-MMC) seems to work.
I've found that the 2-pass encoding crashes with original VirtualDub versions, but it seems to work with VirtualDubMod (x86).
Under testing...

https://sourceforge.net/projects/mpxplay/files/x265vfw

[DarrellS]

Nothing above works for me. The only way to open HEVC in Virtualdub is with the ffmpeg input plugin which does not work in old modded versions of Virtualdub. ffdshow does not support HEVC so the ffdshow plugin does not work. Once file is opened with ffmpeg, it cannot be direct stream copied or smart rendered. It either has to be opened with x265vfw or with ffdshow which does not support HEVC.

[poisondeathray]

Thanks.

It's working for me so far on some quick tests for both encode / decode in 32bit vdub, stable branch, 1.10.4, Win 8.1 x64

The decoder side has similar problems as x264vfw (occasional black frames, seek issues) , but it's to be expected with AVI and temporal compression . (I've confirmed it's using x265vfw as the decoder with file=>file information in vdub) . But I couldn't get HEVC in MP4 or MKV to open with this, only AVI. The input plugins would probably need to be updated for it to work, but vdub development doesn't look too promising and the main forum is down

The encode plays ok in media players such as mpchc, potplayer, etc.. but I think there are still some issues with the bitstream. For example it doesn't open with ffms2 or lsmash in avisynth, or ffmpeg/ffplay .

EDIT: actually I think it's the AVI container causing many problems, extracting the raw bitstream, rewrapping in a suitable container works fine. Likely current demuxers/splitter aren't expecting HEVC in AVI

[Mpxplay]

I've tested decoder side only with the self-made avi/hevc files (encoded with Vdub + x265vfw, opened again in Vdub), probably both sides (enc/dec) need more testing and bugfixes. I haven't installed any extra plugin for Vdub.
Additional problem can be for some players, that the encoder information is written into the bitstream by a vfw codec, it's not separated/written in the header. The x265vfw inside file output will change this behavior, when I'll make it...

[DarrellS]

Closer. It's adding 13 black frames at the beginning of each file. Direct stream copy worked but adding fill filter with curve editor and smart render to create transitions crashed Virtualdub. No error message. Everything just disappeared.

Having to re-encode hevc to avi is a killer. I tried to change a folder of hevc.mkv to hevc.avi with ffmpeg but the files were unplayable. Right now, it seems the only files that Virtualdub can read are the files that it created with the x265vfw codec.

As it is now, It's easier just to add the transitions and encode to hevc.mkv with the external encoder feature. The improvements you've made in the last couple of days gives me hope that you'll get everything figured out.

[LigH.de]

Right now, it seems the only files that Virtualdub can read are the files that it created with the x265vfw codec.

Well possible. It will only be able to read AVIs (no other container, not without additional code or plugins), and it will only recognize HEVC if the video stream is identified by a FourCC which is registered to the x265vfw decoder. Even upper/lower case may be important here!

[shekh]

Found this thread while searching for any x265 vfw

I often see complaints thet AVI (and vfw) is deprecated and does not support features of H264 etc etc
How can I see these limitations? What exactly is not supported? I `d like to get some basic understanding without reading full specs of everything.

So in real world, when I write x264 or the like into AVI using "vfw with hack" and then access that avi with ffmpeg, what is the real problem that I have?

[LigH.de]

The main problem is that the AVI container was developed with only uncompressed, independently compressed, or at most delta (simple difference) frames in mind. Bidirectionally predicted (= B) frames, which may contain differences to a previously displayed frame as well as differences to a frame which will be displayed in the future, were not yet considered, no VfW codec used such a technique yet (MPEG-1 video could, but was not meant to be stored in an AVI container, it had its ProgramStream format).

Storing B frames in AVI is an issue. The container does not easily support the storage of a frame which should not yet be displayed, but is already required to be decoded so that a B frame can be displayed earlier. One technique is to pack a B frame and its previously decoded, but later displayed (I or P) future reference frame together, and use a skip frame as placeholder at the opposite position. PCs with a lot of RAM can handle that. Some consumer players with a limited decoding buffer did not like that. This was already an issue for DivX / Xvid as implementations of MPEG-4 Part 2 (ASP).

This problem gets even worse for MPEG-4 Part 10 and H (AVC, HEVC) where B frames can have even multiple weighted references; and a second problem is added on top: These video formats also support independently inserted frames which can be crossed by references (imagine a scene interrupted by a brief flash, where differences before and after this one exceptional frame would be quite low).

AVI cannot tell apart an inserted I frame references may reach across, and an I frame which means the start of a GOP where the decoder can assume certainly that it doesn't know any frame before (called e.g. IDR = Intra-frame with Decoder Reset). AVI only knows "(independent) keyframes" and "(dependent) difference frames" (and frames with no content, just to expand the display duration of the current video frame being displayed). Modern video formats are more complex than this, though. Modern containers even support display timestamps at each frame to support variable frame rates.

Nevertheless, players and converters on a PC can probably handle such material in AVIs, if their splitter knows which "hacks" were used to circumvent the lacks of the container.

[shekh]

But I can save AVC with B-frames to avi and ffmpeg can play it. ffprobe can tell apart every packet. I guess frame types are derived from video bitstream, not from avi container.
When watching what happens with debugger, everything seems normal: receive packet, decode frame (with expected delay).
Vfw encoder returns packed frame for each source frame (with expected delay, but not packed together single block with all B-frames).
So I don`t understand how to see the problem if it exists.

I noticed some issue however: when I try to remux that avi to mp4, ffmpeg complains about missing pts. This is weird however because when decoding the pts are known (or not needed?).

[LigH.de]

The AVI container does not use Presentation Time Stamps per GOP or per frame. It has to be calculated by the one general duration per frame and the frame number.

As usual, "warnings" are not yet a reason for panic, just a complaint about imperfect conditions.
__

Depending on the structure ("packed bitstream" or not), the content of a frame may be "no content, placeholder" or "a B frame together with its future reference frame at once". Remultiplexing this content to a different container may not be too hard for ffmpeg or specialized tools. Opening such a video in a timeline based editor may be close to impossible if this editor does not split the double frame so that the skip frame gets the packed reference frame content. An application which doesn't know how to handle video streams with B frames may get confused and fail.

As I said, there are different techniques to handle B frames; "packed bitstream" is only one of them, so there must be at least one other. Unfortunately, I don't remember diagrams to point at, to show the advantage or disadvantage of each technique. I hope anyone else here will remember.

And a certain problem will be the lack of separation between I and IDR frames. If there is an inserted I frame, a video editor only knowing the AVI container will assume that it is safe to cut at this I frame, not knowing that references may cross it. The video after this inserted I frame will not be decodable anymore without artifacts. Only cutting at IDR frames will be safe, but the AVI container won't know the difference.

[shekh]

Thanks, from your explanation is seems the problem is app compatibility, the bitstream itself is not defective.
As long as ffmpeg is involved everywhere, the avi can be safely played on pc, converted, uploaded to web (youtube, google drive).
For instance if I open it in VD using my ffmpeg driver I cant tell the difference from same file in mp4.

[shekh]

@Mpxplay

I am introducing vfw extension approach (other thread)

The idea is to remove certain API barriers when using codec with VirtualDub (the codec may be binary compatible with normal vfw or drop it, I dont care).
For example I just send 16 bit frames to x264 without any extra packing / unpacking / Bitmap wrapping.
Do you want to implement any such extension in your codec?

[Mpxplay]

Sorry for the long delay...

x265vfw v1.30 is released on http://mpxplay.sourceforge.net

Diffs between v1.20 and v1.30
- updated x265lib to v2.2 release (build 102)
- updated FFmpeg decoder to v3.2.2
- enabled multi-threaded decoding (depending on the number of CPU cores)
- added x265lib command line options handling and list of them under Help ("?") button (needs test)
- x265lib errors are displayed in x265vfw error window (stdout redirection, missing EoL)
- added "Full" log level to display all x265 library messages (needs test)
- disabled "Update stat file" option by default
- modified x264.stats to x265.stats by default
- removed untested and probably unusefull GordianKnot workaround
- added "hvc1" and "hev1" to fourCC list
- binaries are built with MinGW 6.3

"latest" release files are removed from x265vfw directory, please visit my homepage for the latest versions

I haven't made major changes in the encoding method, so some problems is still the same
(like crashing in original VirtualDub, and x265vfw file output doesn't work)

@shekh
Currently I don't plan to break the VFW API (nor extend it).
VFW is good because we can use H265 with some older programs too.

[Mpxplay]

x265vfw v1.41 is released on http://mpxplay.sourceforge.net

Diffs between v1.30 and v1.41
- updated x265lib to v2.5 release (build 130), added new x265 command line options to x265vfw, corrected/modified some older ones
- x64 release has 10 and 12 bit (per channel) encoding modes too, can be controlled by "--output-depth" option
- corrected PC/TV (full/limited) range conversions
- added option "--input-range" to specify input light range, it can be "full" (PC) or "limited" (TV), default is "auto" (YUV: limited, RGB: full)
- replaced internal colorspace conversions by FFmpeg's ones: added GRAY8, GRAY16, RGB555LE, RGB48BE, ARGB64BE,
BGR48LE, BGRA64LE, YUV420P16LE, YUV422P16LE, YUV444P16LE pixel formats

[Mpxplay]

x265vfw v2.80 is released on http://mpxplay.sourceforge.net

Major changes are (besides the x265 lib updates) in the latest releases:
- file output writing (AVI,MKV,MP4,H265)
- added hw acclelerated (DXVA) decoding, added GUI switch (but removed FFmpeg logo)
- added hdr10plus library to x64 version (with extra cmd options)
- added colormatrix conversion to encoder side (RGB input)(at using "colormatrix" x265 commandline option) (supported color matrixes: BT709, FCC, BT740BG, SMPTE170M, SMPTE240M)

For the complete list of changes please visit
https://sourceforge.net/p/mpxplay/discussion/219198/thread/01da6315
or follow the developments on FB
https://www.facebook.com/mpxplay

[Revan654]

x265vfw v2.80 is released on http://mpxplay.sourceforge.net

Major changes are (besides the x265 lib updates) in the latest releases:
- file output writing (AVI,MKV,MP4,H265)
- added hw acclelerated (DXVA) decoding, added GUI switch (but removed FFmpeg logo)
- added hdr10plus library to x64 version (with extra cmd options)
- added colormatrix conversion to encoder side (RGB input)(at using "colormatrix" x265 commandline option) (supported color matrixes: BT709, FCC, BT740BG, SMPTE170M, SMPTE240M)

For the complete list of changes please visit
https://sourceforge.net/p/mpxplay/discussion/219198/thread/01da6315
or follow the developments on FB
https://www.facebook.com/mpxplay

I was wonder if P010 or P210 is supported or a way to get it to work in VD2? When trying to user it in VirtualDub it says unsupported. I would like to use it but I only have two option P010 or P210.

[Mpxplay]

I was wonder if P010 or P210 is supported or a way to get it to work in VD2? When trying to user it in VirtualDub it says unsupported. I would like to use it but I only have two option P010 or P210.

Added P010 (10 bits on 2 bytes, planar YUV 4:2:0) and corrected P016 (16 bits) input color types in x265vfw v2.81
Y8/Y800 is also corrected.
P21x is not supported yet.