Direct264 - special x264 CLI build that supports input from DirectShow [Archive]

View Full Version : Direct264 - special x264 CLI build that supports input from DirectShow

roozhou

26th September 2008, 02:51

I modified the source code of x264 CLI and this build can now encode from any file playable through DirectShow. Life will be quite easier since avisynth is no longer needed.

Download link:
http://sourceforge.net/projects/direct264/

Changelog 2011-08-31
x264
Updated x264 to 2074

Changelog 2011-05-17
x264
Updated x264 to 1995

Changelog 2011-03-25
x264
1) Updated x264 to 1924.
2) AVI output in x264 supports >2G files.

Changelog 2011-01-22
x264:
1) Updated x264 to 1867
2) Added new parameter --dscrop <left:top:right:bottom>. Works under dshow input only. Cropping will be applied after ivtc and before subtitle rendering. It should be slower than --vf crop so recommended only for use with --sub.
3) YV12 will be preferred if internal resizer is used because swscale is slower on NV12 than YV12.
4) Automatically set default fps to 0.8x in --ivtc t and b mode.
CTAACEncoder & dshow2wav:
5) Fixed random crash during encoding.

Changelog 2010-12-27
x264:
1) Updated x264 to 1834
2) DShow interface now supports NV12. It will first try NV12. If failed, try YV12 later. Win7's built-in decoders are compatible with x264.
3) Fixed a bug in deldup filter.
CTAACEncoder:
4) Compatible with unicode filenames when using mp4 output
5) Updated encoder
VSFilter:
6) Updated to svn r2799. Add NV12/NV21 support to csri interface.

Changelog 2010-12-07
x264:
1) Updated x264 to 1794
2) Added new option "--timed-scenecut". With this option scenecut threshold will increase linearly with PTS instead of frame count. This is useful for VFR video.
3) Removed "--swapuv" since x264 now has "--input-csp".
Phase filter:
4) Improved ivtc accuracy. e.g. for AA BC CC pattern. Old filter will leave all 3 frames as is, new filter will drop BC frame.
CTAACEncoder:
5) Use non-DPL matrix for 5.1->2.0 downmix. To enable DPLII matrix, add "-dpl" to command line.

Changelog 2010-07-02
1) Updated x264 to 1659
2) Fixed a crash at very high bitrate (e.g. lossless)
3) Revert default value of keyint_min to keyint / 10
4) Reduce default number of threads on HT CPU
5) Compiled with VS2010

Changelog 2010-04-28
1) Updated x264 to 1564
2) Fixed a seeking bug in CTAACEncoder'

Changelog 2010-04-08
1) Updated x264 to 1523
2) Default keyint is automatically set to fps*10 (specifying --keyint 0 has the same effect)
3) CTAACEncoder no longer needs write a temp file in your TMP path when outputting to mp4/m4a files

Note that "--timecode" and "--timescale" parameters are removed. Use "--tcfile-in" and "--timebase" instead.

Changelog 2010-03-04
1) Updated x264 to 1471
2) Improved DVD .ifo file handling. A modified VTSReaderMod.ax is included, registration of VTSReader.ax is no longer needed.
3) CTAACEncoder will show unicode filename correctly(in 8.3 form) when it contain unsupported characters, and no longer crashes.

Changelog 2010-02-25
1) Updated x264 to 1462
2) Make weightp 2 and b_pyramid normal default for high profile(same as official release), but both disabled for main profile(compatible with PSP). Such workaround will be removed when "device" option is added.
3) Removed unwanted 0s in nal start code for avi muxer.

Changelog 2010-02-08
1) Updated x264 to 1416
2) Fixed bug in MP4 output
3) libx264 compiled by gcc since MSVC might have mis-compilation issues on encoder/analyse.c

Changelog 2010-01-29
1) Updated x264 to 1400 (added lavf input but no ffms input)
2) Improved dshow input's multi-threading performance
3) Fixed a bug of vsfilter in DirectVobSub mode
4) vtsreader.ax and decssfilter.ax are now combined to one dll

Changelog 2009-12-25
1) Fixed incorrect color(inverted UV) in subtitle loaded with --sub parameter
2) vsfilter automatically uses BT709 matrix in RGB->YUV conversion for HD resolution
3) fixed seeking problem in CTAACEncoder
4) Recompiled some modules, reduced executable size

Changelog 2009-12-17
1) Updated x264 to 1376
2) Print video duration before encoding(in hh:mm:ss) if the source video has duration.
3) Print actual timestamp of start time if --starttime is used. This is useful when you need to mux encoded video with audio.
4) Add a new 'd' mode to ivtc. Since field matching should be done before any filter including crop and resize, you have to use phase filter in ffdshow if you need to resize. The 'd' mode allow you to use phase filter in ffdshow and do ivtc in x264 based on phase filter's analyse.
5) CTAACEncoder allows decimals in -T and -E parameters and uses "sample-accurate" seeking. In dshow mode ""sample-accurate" seeking requires correct timestamps from decoders.
6) Fixed incorrect DPL II downmix coeffecients
7) CTAACEncoder no longer fails on unicode mp4 output file names.
8) Fixed 3 incorrect SAR value

Changelog 2009-11-23
1) Updated x264 to 1342 (weightp is turned off in all presets by default)
2) vfr support added to flv output
3) Fixed 2 bugs in x264's progress displaying
4) Automatically fix incorrect DVD sar returned by b0rked decoders (8:9/32:27/16:15/64:45 -> 10:11/40:33/12:11/16:11)

[How to use it]
This is a modified x264 build. A new demuxer "dshow" is added while the "ffms2" demuxer is removed. It also adds several new features.
Usage is quiet simple:
1) Put "dump.ax" from the archive into windows\system32 or the same directory of "x264.exe" and "CTAACEncoder.exe".
2) "dshow" is the default demuxer, so any video file that playable via directshow can be opened by x264. The command line is the same as using "ffms" or "lavf" as demuxer.
3) "CTAACEncoder.exe" encodes any audio streams in A/V files to aac files. Run it without parameters to see the full help. It uses Winamp plug-in to encode so enc_aacplus.dll and libmp4v2.dll is needed. A copy of modified enc_aacplus.dll is included. If there is any license issues plz let me know.
4) "dshow2wav.exe" decodes any audio stream in A/V files and output wav pcm to stdout. Use cmdline "dshow2wav.exe inputfile [aid]".
5) To directly encode DVD titles (both video and audio):
-- Find the .IFO file in VIDEO_TS folder on your DVD. Commonly the first title is VTS_01_0.IFO.
-- Encode it.

[New parameters in x264.exe]
If not mentioned, all following parameters are only available with dshow input
2) --deldup minfps[:lthresh[:mbthresh[:mbmax[:cthresh]]]] : This will enable a near-duplicate frame removal prefilter. See explanation below.
3) --smoothts : Adjust timestamps so that video plays smoothly. If you are encoding soft-telecined DVD titles, this option will turn 20fps/30fps/20fps... sequence to 24fps. Not needed for latest ffdshow.
4) --starttime hh:mm:ss.ssss, --endtime hh:mm:ss.ssss : Encoding will start or stop at the specified position.
5) --sub subfile : Add a subtitle file to the video. Need a patched vsfilter.dll.
6) --ivtc <mode>: Enable field matching/ivtc function in dshow input mode. See description below.
8) --versioninfo : Write SEI version information and encoding settings to H264 bitstream. Disabled by default. This option is available with all input and output.
9) --timed-scenecut : Scenecut threshold increase linearly with PTS instead of frame count, useful for VFR video.

Before you start to encode, make sure of following issues
1) Proper demuxers and decoders are installed. I recommend using ffdshow + haali/gabest spliiter + real alternative(if you want to encode realmedia files). Some commercial codecs do not work well in software mode. You can test your files in mplayer2 or graphedit(not WMP or mpc-hc!).
2) x264 only accepts YUV 4:2:0. If your decoder do not support YV12, set "Raw video" in "ffdshow video decoder configuration -> codecs" to "all supported" and check "YV12" in "output".
3) If you need to hardcode embedded mkv subtitles, register vsfilter.dll. Use --sub for external subtitles.
4) If you need to use avisynth filters, do not write a ".avs" script, just add it in ffdshow. Anyway some filters are not working in this mode.

[Deldup prefilter]
What is deldup prefilter?
* This is one part of my IVTC filter.
* For static and slow-motion scenes, this will remove duplicate frames so the encoding speed and encoded size will be significantly improved.

How does deldup work?
* It compare the the current frame and the last encoded frame, calculating the SAD of each 16x16 block and the whole image. If all of them are below provided threshold, the current frame is considered a duplicate frame and dropped.
* Codes are optimized with MMX, it is supposed to be quite fast.

How to use it?
In x264 cmdline, use "--deldup minfps[:lthresh[:mbthresh[:mbmax[:cthresh]]]]" to enable deldup prefilter.
* minfps: float. Indicate the minimum fps. If the interval between two frames exceeds 1/minfps sec., it will skip SAD checking.
* lthresh: float. The maximum SAD for Y plane will be set to W*H*lthresh. A negative lthresh will turn luma checking off. Default is 0.4.
* mbthresh,mbmax: integer. if the number of 8x8 blocks with SAD larger than mbthresh exceeds mbthresh, it will be considered a non-duplicate frame. Default is 400,80.
* cthresh: float. The maximum SAD for U and V plane will be set to W*H*cthresh. A negative cthresh will turn chroma checking off. Default is 0.6.

[Phase filter]
This is a field matching filter aiming at IVTC and fixing wrong field order.

To use it with --ivtc <mode> in x264:
Currently there are four ivtc modes: a, t, b, d
--ivtc a: Only field matching is applied with field order set to auto. Deldup filter is not automatically enabled. This mode is used solely for correcting wrong field order.
--ivtc t: Both field matching and deldup are applied with field order set to tff. Deldup is enabled with parameter 24:1:400:80:2 and will be dynamically changed according to Phase's matching result. You can also manually raise deldup's parameters if your video contains heavy noise.
--ivtc b: Same as t mode except field order set to bff.
--ivtc d: Use phase filter as ffdshow's DScaler plug-in. Field order is auto-detected. Useful when you need post-processing in ffdshow(e.g. resize) after ivtc.

Note that with ivtc turned on height must be mod4.

To use it in ffdshow:
1) Install ffdshow and put FLT_Phase.dll somewhere
2) Open ffdshow's Video decoder configuration
3) Check DScaler filter, click "..." behind "Filter", find FLT_Phase.dll and select it
4) If you need to IVTC, select "Odd only" for Top-Field-First and "Even only" for Bottom-Field-First. This should improve accuracy.
5) Do not use other filters before phase, especially cropping, resizing and deinterlacing.

roozhou

26th September 2008, 02:54

Here I explain how it works:

This is the first time for me to write a directshow app. "dump.ax" is actually a modified version of dump filter from M$ DXSDK. It provides a renderer accepting any media type. Instead of writing to files, it calls a Callback Routine and pass sample data as well as timestamp to the application. It also exports functions to initialize, play and stop. So any program can call these functions to grab decoded video frames or pcm data from a dshow graph.

During initializing, it first tries to render the file in dshow, then it search the filter graph for video renderer and audio renderer, and replace them with the dump filters.

To output vfr files, I set fps_num to a fixed value and mod fps_den for each frame. It works fine on mkv but fails on mp4. I guess ratecontrol in x264 will be greatly affected in this way (just guess, test needed).

Don't ask me why we need vfr. Most anime DVDs contains mixed content. Even some HDTV animes use 60fps in credit part. I need a timestamp based encoder like mencoder/realproducer to easily produce vfr videos.

Here is my wish list:
* Support ".grf" files.
* Encoding directly from DVD and TV.
* Combine aac encoder to x264 and mux aac to mkv or mp4.

I also need a one-pass adaptive ivtc dshow filter (not avisynth filter, they either need index or do not work in one-pass mode). I cannot find anything like that, so maybe i need to port one from MPlayer or write it from scratch.

Download link (Old versions):
Changelog 2009-10-27
1) Updated x264 to 1310
2) Use MMX optimized downmix routine for CTAACEncoder

Changelog 2009-10-17
1) Updated x264 to 1292
2) CTAACEncoder will automatically downmix 5.1 or 4 channel sources to stereo in dshow mode

Changelog 2009-09-11
1) Updated x264 to 1251
2) Fixed crash on non-mod8 resolution
3) Fixed y4m input problem

Changelog 2009-07-20
1) Updated x264 to r1183
2) Use default fps value when directshow returns invalid fps

Also updated ffmpeg to r19469. Now ffmpeg accepts mp3 and aac from mkv.

Changelog 2009-08-18
1) Updated x264 to 1214
2) Experimental avi output for x264 (based on avc2avi) with vfr support. You should set --fps to least common multiple of all frame rates if your video contains mixed fps footage. Output file should be less than 2GB.
3) Optimization in VC++'s inline asm code.
4) Minor fixes in CTAACEncoder.

Changelog 2009-07-29
1) Updated x264 to 1195
2) Phase filter works properly under YUV420P colorspace. --ivtc no longer require YUY2 input. 5% speedup with x264's default preset.

Changelog 2009-07-08
1) Updated x264 to r1179.
2) 1pass crf + 2pass bitrate mode works on variable framerate videos.
3) Fixed a bug in x264 MP4 output when fps_den = 1 and no b-frame is used.
4) CTAACEncoder now supports MP4 output. To enable MP4 output, use .mp4 or .m4a as extension of output filename.

2009-6-11
* Update x264 to r1163.
* Support multi-subtitles in x264. Enable with multiple "--sub subfile".
* x264 prints resolution and hint fps in console when encoding from dshow.
* Allow selecting audio stream through Haali Media Splitter and MPC/Gabest MPEG Splitter. You can select audio stream in DVD title and TS files by specifying aid in CTAACEncoder and dshow2wav.
* Slightly improve performance of dump.ax and phase filter.

http://files.filefront.com/direct264.../fileinfo.html

2009-5-20
* Improved user data stripping. Fixed green screen issue on QuickTime.
* Fixed incorrect log2f intrinsic for MSVC.
* Improved fade detect in deldup. It should now work properly w/ ivtc mode t/b.
* --smoothts now works properly when deldup is disabled.
* Faster nal encoder (based on VFR Maniac's patch)
http://files.filefront.com/direct264.../fileinfo.html

2009-5-15
* x264 updated to r1148
* Fixed incorrect dts/cts-offset issues when using mp4 output. Increased initial delay for mp4 so there won't be negative cts-offset.
* Added new parameter "--timescale <int>" to set the denominator of initial fps. If not set, x264 will choose a proper value according to fps.
* Changed parameter "--no-versioninfo" to "--versioninfo". User data is disabled by default.
* Changed default value of deldup's mbmax from 80 to width/10.

http://files.filefront.com/direct264.../fileinfo.html

2009-04-28
* Fixed incorrect pts and bitrate in non-dshow mode
* Fixed bug that deldup does not work when ivtc is off
* Fixed incorrect 30fps->24fps timestamp adjust when ivtc is on
* Removed width*height mod32 restriction on deldup, small speed boost on deldup's chroma plane comparison
* Increased deldup's default threshold
* Improved x264's help information(no lines exceeds 80 charaters)

http://files.filefront.com/direct264.../fileinfo.html

2009-04-20
* Updated x264 to r1143
* New function "ivtc" added to x264
* Bug fixed in CTAACEncoder's multithreading mode
* Encoding from raw YUV and Y4M is OK now
* Overlay Mixer and AVI Decompressor will be removed if found in filter graph
* Bug fixed in VSFilter's ssa tag parsing

http://files.filefront.com/direct264.../fileinfo.html

2009-3-20
* Updated x264 to r1128
* Assembly optimized x264_clz intrinsic for MSVC, slightly speed boost in aq.
* Now x264 --version will show VC version number, instead of "using a non-gcc compiler".
* Decrease priority of input thread in x264, may improve performance on multi-cores(experimental).
* No more crash/freeze after encoding finished.
* Added support for SVCD pixel AR (352x480, 352x576, 480x480, 480x576 @ 4:3/16:9).
* Dump.ax supports multi-instance in one progress.
* Added multithread mode in CTAACEncoder(enabled with -mt), similar to --thread-input in x264. Useful when decoding is slow (FLAC,APE,etc.).
* Faster SSA tag parsing in vsfilter, ~5% speed boost with large SSA/ASS files.
* Faster field matching in phase, 10%~30% speed boost.

http://files.filefront.com/direct264.../fileinfo.html

Dark Shikari

26th September 2008, 03:19

Whoa, I love this idea.To output vfr files, I set fps_num to a fixed value and mod fps_den for each frame. It works fine on mkv but fails on mp4. I guess ratecontrol in x264 will be greatly affected in this way (just guess, test needed).No, ratecontrol is CFR and bases the "fps" on the initial fps. Therefore, you must pass to x264 the average FPS of a file in order to get accurate results, at least in --bitrate mode.

roozhou

26th September 2008, 03:36

And what about --vbv-maxrate, will it work in vfr mode? I mean in low fps scene more bits for one frame are allowed and in high fps scene less are allowed.

Dark Shikari

26th September 2008, 03:40

And what about --vbv-maxrate, will it work in vfr mode? I mean in low fps scene more bits for one frame are allowed and in high fps scene less are allowed.No, it won't. This is a problem for Avail in broadcast also, as they have 30fps and 24fps mixed content due to telecine. Their proposed solution is a ratecontrol_reconfigure() function that changes the current fps of ratecontrol.

lilhobo

26th September 2008, 03:42

doesnt this mean we can use xh264 in NLEs?

Audionut

26th September 2008, 03:55

doesnt this mean we can use xh264 in NLEs?

No...

roozhou

26th September 2008, 04:01

doesnt this mean we can use xh264 in NLEs?

DShow is not frameaccurate and can only seek to key frame, you need to index first.

CruNcher

26th September 2008, 04:08

First of all nice work :)

DShow is not frameaccurate and can only seek to key frame, you need to index first.
I guess it has nothing really to do with Dshow but the Decoder i can seek frame accurate with a lot of commercial Decoders, though with many free ones it isn't possible.

roozhou

26th September 2008, 04:18

With an index of key frames things will be easier.

e.g. The user needs a frame at 19.00s. If i know there are two key frames at 10.00s and 20.00s, I will seek to 10.00s and repeat requesting the sequential frames until i get that at 19.00s. I can also buffer the skipped frames so when the user needs previous frames they don't need to be decoded again.

CruNcher

26th September 2008, 13:19

@roozhou
i have problems with dump.ax i get a "inadmissible access to memory area" warning if trying to regsvr32 it :( could be a DEP incompatibility because of the old VC6 compiler on
Winx XP SP3 here, you should use a new Compiler that supports the DEP/NX flag especially under Vista and starting with SP2 else users gonna get problems.

roozhou

27th September 2008, 03:08

Thanks CruNcher. I've never tested it on Vista. I think VS 2005 is not compatible with DXSDK 8.1 (e.g. variable definition in for loops).

Or try turning off DEP before regsvr32 dump.ax

cyberbeing

27th September 2008, 05:54

KornX

27th September 2008, 10:45

just my 2 cents:
great idea, i wanted to propose sth like that some time ago, but after seeing how the vfw guys get treated i was afraid :)

KornX

Sharktooth

27th September 2008, 13:52

VFW is obsolete and doesnt support mpeg4 and other modern codecs features (implementing them requires hacks and workarounds), while directshow (even if its a bit controversial...) supports them.

CruNcher

27th September 2008, 18:49

Keep up the good work roozhou, dshow x264 with vfr support sounds quite interesting (though I have yet to test it).

@CruNcher
I am also on WinXP SP3 with DEP enabled for "Windows Programs and Services Only" (which is the default AFAIK) and had no issue registering dump.ax with regsvr32. Do you have DEP enabled for "All programs and services"?

Hmm i know it sounds strange it does for me too i never had such a Bizarre Warning message from regsvr32 in my entire Windows life (this is the first time ever) trying to register a directshow filter so i checked regsvr32 and every other directshow filter works i can register and unregister with it.
Tried several times now only this dump.ax from roozhou is being rejected also of course checked if it's damaged that's not the case (did several downloads to different HDDs therefore and tried to regsvr32 it no chance still rejected)
DEP/NX here is Hardware Athlon-64 X2 Toledo and it's set currently /NoExecute=OptIn so @ Microsoft default.
Why it seems to try preventing a buffer overflow @ registration of dump.ax on my system I'm not sure about, though im not gonna disable DEP so fast rather the .ax should be checked not sure tough why it's working on your system flawless.

The correct error is = LoadLibrary("dump.ax") failed - Invalid access to memory location.

search on google for regsvr32 "Invalid access to memory" alot of VS6 users report this problem starting with SP2 it seems

cyberbeing

28th September 2008, 01:04

Well I have to say that is very odd since I also have a Athlon-64 X2 Toledo with /NoExecute=OptIn running SP3 and it sounds like all other settings are identical as well yet you are having a problem and I'm not :confused:

Maybe it's because I had previously installed the Visual C++ 6 runtimes (http://download.microsoft.com/download/vc60pro/update/1/w9xnt4/en-us/vc6redistsetup_enu.exe) and have all other C++ runtimes (7-9) installed?

roozhou

28th September 2008, 02:35

Hmm i know it sounds strange it does for me too i never had such a Bizarre Warning message from regsvr32 in my entire Windows life (this is the first time ever) trying to register a directshow filter so i checked regsvr32 and every other directshow filter works i can register and unregister with it.
Tried several times now only this dump.ax from roozhou is being rejected also of course checked if it's damaged that's not the case (did several downloads to different HDDs therefore and tried to regsvr32 it no chance still rejected)
DEP/NX here is Hardware Athlon-64 X2 Toledo and it's set currently /NoExecute=OptIn so @ Microsoft default.
Why it seems to try preventing a buffer overflow @ registration of dump.ax on my system I'm not sure about, though im not gonna disable DEP so fast rather the .ax should be checked not sure tough why it's working on your system flawless.

The correct error is = LoadLibrary("dump.ax") failed - Invalid access to memory location.

search on google for regsvr32 "Invalid access to memory" alot of VS6 users report this problem starting with SP2 it seems

I built "dump.ax" with "/MERGE:.data=.text /MERGE:.rdata=.text /SECTION:.text,EWR" to make it smaller. And a "Readable, writable, executable" .text section should make sense.

CruNcher

28th September 2008, 10:00

@roozhou
i found out what caused it www.threatfire.com after stopping it's service i could register your filter, though there must be a reason that it causes this behavior with your filter, i send the file to pctools maybe it's a problem (bug) in their behavioral protection.

roozhou

30th September 2008, 16:34

Updated to 2008-09-28, new deldup prefilter added.

CruNcher

1st October 2008, 00:32

hmm this is strange i encoded a VFR WMV (using wmvdmod.dll playbacks it with 29,970 FPS and shows runtime of 2:56) into .264 final encoded bitstream shows 25 fps and runtime of 3:11 sec then i encoded the same into .mkv now it's still shows the stream as 25 fps but runtime is 2:56 @ playback the video renderer renders it though like the initial source with 29,970 FPS hehe :) so the container bitstream FPS doesn't match right i mean it allways writes now 25 fps (couldn't that cause problems for some parsers so they would slow down) ?

roozhou

1st October 2008, 14:37

CruNcher:
Add "--fps 30000/1001". This will set the fps in H264 bitstream to 29.97, but has no affect on mkv timecodes.

CruNcher

1st October 2008, 15:59

roozhou

1st October 2008, 16:50

is there no way to get this automatically from the dshow decoder ? like x264 gets it from avisynth :)
so if the dshow decoder returns 29,970 FPS then set x264 --fps 30000/1001 but still let the user the possibility to manual override it <- would be a feature request :)

Sounds good. DShow returns average fps as well as DAR and interlace flag. I will make fps and sar automatically set in x264.

roozhou again this is great work and it really should get into git though i guess you would have todo some design changes here (explicitly only activate it for WIN32) and change the way you make .diffs what for a .diff format is this ?

I don't know how to make a single patch file that contains all the diffs of modified files. Now i am using "diff xxx.c.orig xxx.c > dshow_xxx_c.diff" to make patches.

Dark Shikari

1st October 2008, 16:58

I don't know how to make a single patch file that contains all the diffs of modified files. Now i am using "diff xxx.c.orig xxx.c > dshow_xxx_c.diff" to make patches.git diff

1st October 2008, 17:00

I don't know how to make a single patch file that contains all the diffs of modified files. Now i am using "diff xxx.c.orig xxx.c > dshow_xxx_c.diff" to make patches.
Use the -r parameter: diff -ur dir > patch.diff

Edit: DS's suggestion is a better idea when working with x264's git tree.

roozhou

7th October 2008, 05:49

updated to 2008-10-07

--fps and --sar will be automatically set.
add support for ".grf" files.

A patch generated by "git diff" is included. It also contains hrd_pulldown patch.

CruNcher

19th October 2008, 01:31

roozhou any update on the .mp4 output issue ? so far everything works really well except that :)
it goes heavily wrong muxing the output .mp4 with mp4box and audio :) the stream is only playback able without any problems by 3 decoder on windows (Cyberlink DXVA/Software Nvidia,ffdshow,MPC Video Decoder (Software mode)) :) else every other Decoder fails (using Haalis Splitter)

Audio Decoder (ffdshow)

Cyberlink DXVA/Software Nvidia (Perfect fluid sync playback just wow <- Perfect fluid and wow only for Hardware Playback ;) )
CoreAVC (stays sync but creates judder motion drops b-frames ?)
ffdshow (wow stays sync plays it rather fine no strange drops :) )
mplayer -nocorrect-pts (gets unsync but stays stable)
vlc (tries everything to sync it but judders and fails)
MPC Video Decoder DXVA Nvidia (forward,backward,forward,backward man that makes you go dizzy but sound is sync)
Elecard (gets unsync but keeps fluid motion)
DivX (gets unsync but keeps fluid motion)

so in this extreme case only 3 are watchable and the others all fail (ffdshow audio decoder)
1. Cyberlink
2. ffdshow
3. Mpc Video Decoder (Software) (practicly same result as ffdshow)

roozhou

19th October 2008, 07:47

MP4 output is broken, plz use .264 + timecodes output and mux them with audio using mp4box + dtsedit. It seems that vfr MP4 is a bit different with cfr MP4 and x264 is assuming cfr.

roozhou

19th October 2008, 14:25

updated to Oct 19

1)add dshow2wav tool
2)support dvdrip

buzzqw

19th October 2008, 15:15

excellent updates!

thanks !

BHH

CruNcher

20th October 2008, 00:09

wow it gets better and better :D

but roozhou it would be better to be able to hold the chain under control so that "dshow hell" can be avoided something like MPC filter control "merit,block,prefer" :) would be advisable easier to setup then .grf imho :) of course could be also done via external gui buzzqw ;)

MeteorRain

22nd October 2008, 04:12

kemuri-_9

22nd October 2008, 05:28

i remember several reports from numerous people about some avisynth 2.5.x builds (don't remember which versions off hand) working successfully under wine.
i know one person even has ffdshow working in it for using avisource() instead of having to rely on ffmpegsource()
so you could go that route as well until 3.0 becomes usable.

22nd October 2008, 07:02

hmm how about intergrate ffmpeg or something others to support direct file input and simple filters that working under linux or other posix based system?
before avisynth 3.0 i really have no idea what i can use to do preprocessing before x264. :(
In addition to running Avs2YUV (http://akuvian.org/src/avisynth/avs2yuv/) and AviSynth within Wine, you can pipe raw video from MPlayer or MEncoder to x264, or just use libx264 within MEncoder.
Then there are Avidemux and HandBrake that have their own filter stacks (both can be controlled by scripts, if necessary).

roozhou

22nd October 2008, 13:57

hmm how about intergrate ffmpeg or something others to support direct file input and simple filters that working under linux or other posix based system?
before avisynth 3.0 i really have no idea what i can use to do preprocessing before x264. :(

As soon as I added ffmpeg to x264, it becomes another mencoder:)

Anyway it seems easier for me hacking x264 than patching mplayer/mencoder.

buzzqw

22nd October 2008, 14:01

well mencoder is mencoder.. ffmpeg is ffmpeg.. and ffmpeg is a lot more friendly then mencoder
would be very very appreciated to get a ffmpeg build with all x264 options AND the same syntax as x264!

BHH

martino

22nd October 2008, 14:47

How is ffmpeg friendlier than mencoder?

buzzqw

22nd October 2008, 15:22

the sintax if more friendly
not to hassle with order of -vf filters, encoding only audio is a breeze, cropping syntax is a lot cleaner, no oac ovc lavc.. just plain codec library calling

imho ffmpeg is easier

BHH

22nd October 2008, 16:19

the sintax if more friendly
not to hassle with order of -vf filters
That's because there aren't that many filters in FFmpeg.

As soon as I added ffmpeg to x264, it becomes another mencoder
...without filters. Somehow I doubt Loren would accept FFmpeg dependencies within x264. It makes a lot more sense the other way around (and that's how it has been done already), or as your own standalone app. Personally I don't see the point since there are quite enough alternatives already.

Anyway it seems easier for me hacking x264 than patching mplayer/mencoder.
Why would you need to patch MPlayer/MEncoder?

roozhou

22nd October 2008, 19:16

That's because there aren't that many filters in FFmpeg.

...without filters. Somehow I doubt Loren would accept FFmpeg dependencies within x264. It makes a lot more sense the other way around (and that's how it has been done already), or as your own standalone app. Personally I don't see the point since there are quite enough alternatives already.

Why would you need to patch MPlayer/MEncoder?

Because of bugs. e.g. MPlayer -ao pcm always appends wav header at the end of stream when i am piping it to other program. That's why i developed dshow2wav. And MEncoder's mkv/mp4 muxer is complete broken with H264.

22nd October 2008, 19:52

Because of bugs. e.g. MPlayer -ao pcm always appends wav header at the end of stream when i am piping it to other program.
Um, use -ao pcm:nowaveheader, or if that doesn't work for some reason, the bug is probably quite easy to fix and MPlayer developers will certainly accept a patch.

CruNcher

22nd October 2008, 21:29

@nm
The problem is much worse piping is a catastrophe in mplayer/mencoder for win32 the problem is the waveheader can't be piped currently @ all, it needs to be fixed (patched) to do so.
It's only possible to dump the wav content into a external file currently with mplayer and mencoder doesn't even have this option @ all :( so you jumping around like crazy between applications to reach a goal such like Transcoding audio with Nero AAC.
Also as roozhou said MKV is broken and also the logic between libavformat and mencoder isn't working correct which again results in alot of effort in writing outside logic (to fix those issues temporary), to reach a simple transcoding goal :(
Integrating libavcodec/libavformat as a decoder into what we know currently as the x264 CLI would be a nice fork though all the logic in analyzing the demuxer info (of the original source bitstream information) has to be transfered correctly to the final output H.264 bitstream as well the container used information layer which i think is also some effort compared to fixing mencoder :)
Though this is the big power vs PIPING you have the information out of the Source available (via the demuxer) you don't need to manually enter it (though of course as i always say the possibility to manually overwrite these should still be given to the user if needed), or write outside logic that does it (GUI,Batch,ect))
Here is some example of a logic error (bug) inside mencoder http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1305 sure this is a small thing nothing big as Mencoders Mkv or piping being not 100% functional on win32 (efficiently) @ first but such small things can result also in allot of frustration especially if you do full automated transcoding :)
The only problem with x264 dshow i have currently is that sometimes the FPS goes lost via Dshow (happened for now only for .mov (quicktime files) somehow), but x264 dshow currently is a nice option for windows users compared to mencoder.
Simple/Advanced video post operations like deinterlacing, ivtc ,scaling, and croping ,denoising could be realized via Avisynth but as already said it's not platform independent yet and i think roozhou idea to bring those from mencoder into the CLI is great (though of course if mencoder would work correct it wouldn't be needed @ all)
So which ever way you gonna go roozhou i gonna try to support it the best way i can :) be it fixing mencoder,improving on it or continue creating this x264 cli based decoder/encoder :)

22nd October 2008, 21:55

roozhou

23rd October 2008, 03:02

kemuri-_9

23rd October 2008, 03:30

On windows it is easy to find out whether a file being written is a disk file or not. Look at my dshow2wav source, a simple GetFileType will work. But in mplayer, it uses fseek(fp, 0, SEEK_SET) == 0 and this is not working on windows.

that logic isn't valid, as x264 uses fseek similarly and it works perfectly on windows. (see the parse_qpfile code)

roozhou

23rd October 2008, 04:34

that logic isn't valid, as x264 uses fseek similarly and it works perfectly on windows. (see the parse_qpfile code)

Sorry for my English. I mean mplayer uses fseek(fp, 0, SEEK_SET) == 0 to determine whether the file is seekable and it fails on windows. The similar problem occurs in x264 get_frame_total_yuv where it uses fseek( h->fh, 0, SEEK_END ) and ftell( h->fh ) to determine the size of the file. This stupid way also fails on windows when reading from named pipe (aka FIFO). In my build I patched it with GetFileType and GetFileSize (only applied on Win32) and it is now working perfectly.

akupenguin

23rd October 2008, 05:34

So in which way is it broken... can windows seek in pipes, or is windows incorrectly not returning an error from fseek?

tre31

23rd October 2008, 07:19

Just thought I'd pop in too say this is exactly what I've been searching for, directshow encoding from a graph. I'm using ATI's hardware dxva decoding and vector adaptive de-interlacing straight into x264 keeping resolution the same at 1920x1080i and crf 22 looks pretty damn good, pity there is no hardware bob at double frame rate via ATI's hardware (that I can find). Anyway nice work :D

roozhou

23rd October 2008, 07:21

The problem is once you seek forward in a pipe or stream, you cannot seek backward. If the pipe is empty, it runs ok since x264 finds the file size is 0 and tries to read to EOF. But if the pipe has already been filled with data before x264 opens it, it seeks to the end of data and incorrectly reports the file size as the size of prefilled data.

roozhou

28th October 2008, 18:46

VFR mp4 output is ok now. Also add two options to set start and end position.

video_magic

28th October 2008, 23:23

Thanks for the work and the new version :)

tebasuna51

2nd November 2008, 10:15

@roozhou
With your dshow2wav.exe I obtain 16 bit stereo from a WMV with multichannel WMA audio (like I say you in Audio Ecoding forum).

Maybe the thread WMA 5.1ch. in WMV only decodes to stereo? (http://forum.doom9.org/showthread.php?t=110449) help you to improve this interesting tool.

roozhou

2nd November 2008, 11:46

@tebasuna51
Have you checked speaker setup in control panel? According to zembelli's words, you should set it to 5.1 to enable multichannel decoding.

tebasuna51

2nd November 2008, 21:04

@tebasuna51
Have you checked speaker setup in control panel? According to zembelli's words, you should set it to 5.1 to enable multichannel decoding.

Of course, I have attached a receiver with 6 analog input to PC audio output. All is Ok.

With DirectShowSource() in .avs the output is Ok.

With a simple Test6chan.wma the avs output is 16 bit/6 channels, with dshow2wav 16 bit/2 ch.

With the MS HD sample Amazing_Caves_1080.wmv, the avs output 24 bit/6 ch., with dshow2wa 16 bit/2 ch.

I'm talk about the changes in DirectShowSource than IanB make "to poke the High Res output(_HIRESOUTPUT)'"

Edit: with GraphEdit I have also 16 bit/2 ch

roozhou

3rd November 2008, 12:57

Of course, I have attached a receiver with 6 analog input to PC audio output. All is Ok.

With DirectShowSource() in .avs the output is Ok.

With a simple Test6chan.wma the avs output is 16 bit/6 channels, with dshow2wav 16 bit/2 ch.

With the MS HD sample Amazing_Caves_1080.wmv, the avs output 24 bit/6 ch., with dshow2wa 16 bit/2 ch.

I'm talk about the changes in DirectShowSource than IanB make "to poke the High Res output(_HIRESOUTPUT)'"

Edit: with GraphEdit I have also 16 bit/2 ch

Thank you very much for providing this information. In next version it will be fixed.

P.S. some one is working on a wma pro decoder which belongs to this year's ffmpeg google SOC project. As soon as it is finished, we can send the crappy WMAudio Decoder DMO to the ground.

roozhou

4th November 2008, 11:59

Updated again.
WMA Pro issue solved.

tebasuna51

4th November 2008, 19:17

@roozhou
Your last package: dshow_x264_20081104
still don't work for me.

Maybe your:

dump.ax 28/10/2008 16:15

is outdated, because:

dump.cpp 03/11/2008 16:43

roozhou

5th November 2008, 03:44

:stupid:
Plz download 20081105 build (http://files.filefront.com/dshow+x264+200811057z/;12255629;/fileinfo.html)

tebasuna51

5th November 2008, 12:24

Thanks. Now work fine.

tebasuna51

6th November 2008, 02:45

Maybe is not important but always is better put all waveheader fields correctly, you forget block_align (at end of dshow2wav.c):
waveheader.channels = ((dwAudioInfo >> 24) & 0xF);
waveheader.sample_rate = (dwAudioInfo & 0xFFFFFF);
waveheader.bits_per_sample = ((dwAudioInfo >> 25) & 0xF8);
+ waveheader.block_align = waveheader.channels * waveheader.bits_per_sample / 8;
+ waveheader.avg_bytes_sec = waveheader.block_align * waveheader.sample_rate;
- waveheader.avg_bytes_sec = waveheader.channels * waveheader.sample_rate * waveheader.bits_per_sample / 8;

roozhou

6th November 2008, 05:05

roozhou

7th November 2008, 03:29

Plz check the 11-06 build.

tebasuna51

7th November 2008, 13:10

I noticed that because oggenc2 prints warning on incorrect block_align.

The oggenc2 still can't work with dshow2wav because need correct datalength.

I make a feature request (http://www.hydrogenaudio.org/forums/index.php?showtopic=60755) to ogg developpers about that.

The official branch (http://www.hydrogenaudio.org/forums/index.php?showtopic=65975) seems accept the request (#1326) but still is in beta stage.

But John33 (oggenc2-rarewares) don't say nothing. Maybe next week (http://www.hydrogenaudio.org/forums/index.php?showtopic=60755#) (Mar 7 2008).

Maybe persons interested in oggenc2 encodes can remember to John33 the --ignorelength parameter.

---------------------------------------
Test with flac seems work with this parameters:
dshow2wav <input-file> | flac --force -o <output.flac> --silent --channel-map=none --ignore-chunk-sizes -

----------------------------------------
edit: the 11-06 pack work fine with block-align

tebasuna51

7th November 2008, 17:17

To encode now with oggenc2 or other encoders than need physical wav files you can use:

WavSplit
======
If you want encode to DTS or with some AC3 encoders you need monowavs, then:

dshow2wav <input_file> | WavSplit - <prefix.wav> -ignorelength

and you obtain: prefix_FL.wax, prefix_FR.wav, ...
Also can split in stereo wav files more easy for edit.

Wavfix
=====
If the wav file is > 4GB and you want use w64 format (or also rf64):

dshow2wav <input_file> | WavFix - <output.w64> -ignorelength -o 3

[-o #] Output header. 0=RAW, 1=WAV(Default), 2=RF64, 3=W64
The RiffLength and DataLength are rewrited with correct data (int64).

Maybe you need the multichannel wav output with WAVE_FORMAT_EXTENSIBLE header:

dshow2wav <input_file> | WavFix - <output.wav> -ignorelength -m 0

[-m #] MaskChannel. Force output WAVE_FORMAT_EXTENSIBLE. 0 to default for the numchannels detected.
This feature can be integrated in dshow2wav.

If you are interested I can send you these utils.

roozhou

7th November 2008, 18:00

In latest oggenc2 from rareware.org there is a "--ignorelength" option. And for neroAacEnc it's "-ignorelength" and for aften it's "-readtoeof 1".

tebasuna51

7th November 2008, 22:32

I was tired of ask to John33 about this. Thanks.

And yes the Aften -readtoeof 1 is other old little battle (http://forum.doom9.org/showthread.php?p=962455#post962455)

EDIT: Tested last oggenc2 from rarewares

Oggenc2.85 using libVorbis v1.2.0 2008-03-16
Oggenc2.85 using aoTuVb5.5 2008-03-31

and --ignorelength isn't supported.

roozhou

8th November 2008, 18:02

tebasuna51

9th November 2008, 02:05

Thanks. Now work --ignorelength

roozhou

25th November 2008, 12:27

Updated to 2008-11-25

x264 r1032
Added "--no-versioninfo" to remove encoding settings from bitstream.
Supports y4m from stdin, making piping from mplayer available

Dark Shikari

25th November 2008, 12:36

Updated to 2008-11-25

x264 r1032
Added "--no-versioninfo" to remove encoding settings from bitstream.As an x264 developer, I strongly request that you remove this option. I don't want to make it easy for people to strip encoding settings out of their files to cover up their incompetence and force me to do more detailed analysis for no good reason. At least force them to go into the code and do it themselves.

roozhou

25th November 2008, 13:54

As an x264 developer, I strongly request that you remove this option. I don't want to make it easy for people to strip encoding settings out of their files to cover up their incompetence and force me to do more detailed analysis for no good reason. At least force them to go into the code and do it themselves.

Actually I was just aiming at reducing overhead. And I guess it is easy for you to find out how bad their encoding settings are even without that information in bitstream :)

buzzqw

25th November 2008, 14:16

what about adding a crop and resize ability? (and maybe including hqdn3d denoiser...)
thanks!

BHH

roozhou

25th November 2008, 15:53

what about adding a crop and resize ability? (and maybe including hqdn3d denoiser...)
thanks!

BHH

You can find them in latest ffdshow. I will only add functions that current dshow filters do NOT have.

buzzqw

25th November 2008, 15:58

:(

i prefer a "direct" approach (and so like building a gui aroud it)

thanks anyway

BHH

roozhou

25th November 2008, 16:25

:(

i prefer a "direct" approach (and so like building a gui aroud it)

thanks anyway

BHH

I would rather hacking mencoder than adding this to x264. A GUI can do this job by setting ffdshow reg keys.

CruNcher

25th November 2008, 21:32

yep buzzqw leverage ffdshow it gives you alot of possibilities :)
also accessing avisynth for special effect purposes a very powerfull (OSS) base this could become under Windows :) very comparable to Nero Recode (and with the time beyond) just with X264 as Core and not only that with stable Dshow Decoder i think it would be even a good base for a NLE, (though very important here minimizing Dshow Hell as good as possible like with a chain management ala MPC) :)

i already build very simple logic (based on batch scripting around it) just 1 command and i can transcode all video stuff to H.264 in a snap very powerful also integrated it into the Windows Explorer :) trying to achive all that with Mencoder,ffmpeg and co under Windows gave me major headaches (especially with non supported Video/Audio by ffmpeg or the problems with mencoder piping under win32) and the best i can leverage all the metadata of the encoding into the final result :) it's even easier and faster then Mediacoder (and more stable based on Dshow, no joke, you just have to keep the chain under control) (also i can encode and live preview the encode result via GPU without makeing the encode slower, and jep also tested delayed live streaming of the result @ the same time everything seems to magicaly work and i can do live overlays too, and yeah also integrated it testwise with BDA (DVB-S2) works too :) (Broadcast stuff only Video yet no live muxing)

I can just say it Natively perfectly integrates into Windows that way (a nice efficient task optimized gui now for it would rock) :D

Guest

3rd December 2008, 15:26

I also need a one-pass adaptive ivtc dshow filter (not avisynth filter, they either need index or do not work in one-pass mode). That's not correct. Neither Telecide()/Decimate() nor TIVTC() require indexing or multiple passes.

roozhou

3rd December 2008, 17:04

That's not correct. Neither Telecide()/Decimate() nor TIVTC() require indexing or multiple passes.

That's right. But avisynth does require two passes. Can you encode vfr video in one pass without indexing w/ avisynth?

Guest

3rd December 2008, 17:34

We were talking about IVTC, not encoding VFR. And saying "Avisynth requires two passes" is absurd.

You obviously have an agenda so I won't bother you again with facts.

roozhou

3rd December 2008, 18:10

We were talking about IVTC, not encoding VFR. And saying "Avisynth requires two passes" is absurd.

You obviously have an agenda so I won't bother you again with facts.

Consider mixed progress + telecined video. TIVTC cannot do its work in one pass without indexing it first. And indexing should be treated as one pass.

CruNcher

4th December 2008, 03:03

I had a Problem of how to handle interlaced bitstreams automatically i didn't want to use the bad performing internal Software Deinterlacer of most Dshow Decoder so i analyze the Source now and then incorporate ffdshow into the chain (by just changing the registry entry for the colorspace rendering to all supported and to handle all frames as interlaced with yadif, works not bad) only when using a different decoder then fffdshow itself, it's a little inflexible then mencoder but it works. :)
Also tried that with Progressive as interlaced bad flagged streams seems not a big problem doesn't hurt much in transcoding quality (helps compression a bit too).
It's not perfect that way a integrated solution like your --deldup would be more effective and adaptive i guess same for ivtc, as internally you could get all the bitstream information @ playback :)

Source: http://www.mediafire.com/download.php?hnlqnznnzzw
1 Pass 5,49 fps Transcoding result: = http://mirror05.x264.nl/CruNcher/force.php?file=./dshow-batchframework/mc.ts-yadif.mp4 Transcoding time 0:01:33 :)

Mencoder doesn't support the Source yet

popper

5th December 2008, 17:58

roozhou

5th December 2008, 18:40

roozhou, have you ever looked at Eigen 2.0 for some x86 SIMD optimisations that might help improve the general speed of all the video coding (more Vectorization re-codeing is always good)work we see here at doom9, not least x264, you might enjoy it.

http://eigen.tuxfamily.org/index.php?title=Main_Page

and if you ever dabble in PPC linux ,then markos's freevec SIMD work is probably interesting too
http://www.freevec.org/

the benchmarks are very interesting for both platforms SIMD work.

Most of x264's time-consuming functions have already been optimized with SIMD instructions, so i don't think Eigen 2.0 would help a lot. And you'd better talk to Dark Shikari who is one of the current developers of x264.

Dark Shikari

5th December 2008, 20:40

roozhou, have you ever looked at Eigen 2.0 for some x86 SIMD optimisations that might help improve the general speed of all the video coding (more Vectorization re-codeing is always good)work we see here at doom9, not least x264, you might enjoy it.I have yet to encounter any program or library whose x86 optimization is even close to the same level as x264.

And if it was close, I would take the code, make it better, and use that instead.

roozhou

12th December 2008, 09:17

Updated to 2008-12-12

The new package contains two x264 builds, one is GCC 4.3.2 fprofiled build (x264.exe) and the other is MSVC 2005 PGO build (x264_msvc.exe).

This is my first attemp to build x264 with MSVC. Although several SSE2/SSSE3 functions are disabled for stack-alignment issues, MSVC build seems to run a bit faster than GCC build with low quality settings and the EXE is 25% smaller in size.

Anyone interested in comparing speed of GCC and MSVC builds could use each build to encode, and of course with the same settings. If one is significantly faster than the other, please post your command line here.

Dark Shikari

12th December 2008, 09:26

roozhou

12th December 2008, 09:46

And all intrinsics, and all inline assembly...

Where is the inline assembly in x264?

Yes my dshow patch contains gcc inline assembly and i added VC inline assembly to make it compile under VS 2005.

e.g.

#ifdef _MSC_VER
__asm emms
#else
asm volatile("emms \n\t");
#endif

Dark Shikari

12th December 2008, 10:00

Where is the inline assembly in x264?common/x86/utils.h

Intrinsics are in common/osdep.h (x264_clz and x264_endian_fix).

Also, you don't need to create an emms, we already have one (x264_emms, not an intrinsic).

roozhou

12th December 2008, 17:36

common/x86/utils.h

Intrinsics are in common/osdep.h (x264_clz and x264_endian_fix).

Also, you don't need to create an emms, we already have one (x264_emms, not an intrinsic).

I am porting all these to MSVC.

Just one problem, what does "+r" mean here in util.h?

"movq %%mm4, %0 \n"
:"=m"(output), "+r"(i_mvc)
:"r"(mvc), "m"(*(struct {int16_t x[4];} *)mvc)

Dark Shikari

12th December 2008, 20:36

I am porting all these to MSVC.

Just one problem, what does "+r" mean here in util.h?

"movq %%mm4, %0 \n"
:"=m"(output), "+r"(i_mvc)
:"r"(mvc), "m"(*(struct {int16_t x[4];} *)mvc)
The "+r" is a register constraint: its taking i_mvc as a value in a register and modifying it (hence the +).

Also, be very careful specifying your clobbers and dependencies: the whole "struct" nonsense is because we had to fool gcc into realizing that we were, in fact, dependent on the input array.

roozhou

12th December 2008, 23:00

The "+r" is a register constraint: its taking i_mvc as a value in a register and modifying it (hence the +).

Also, be very careful specifying your clobbers and dependencies: the whole "struct" nonsense is because we had to fool gcc into realizing that we were, in fact, dependent on the input array.

Here is the original gcc inline-assembly version

static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
{
int sum = 0;
uint16_t output[4];
asm(
"pxor %%mm4, %%mm4 \n"
"test $1, %1 \n"
"jnz 3f \n"
"movd -8(%2,%1,4), %%mm0 \n"
"movd -4(%2,%1,4), %%mm3 \n"
"psubw %%mm3, %%mm0 \n"
"jmp 2f \n"
"3: \n"
"sub $1, %1 \n"
"1: \n"
"movq -8(%2,%1,4), %%mm0 \n"
"psubw -4(%2,%1,4), %%mm0 \n"
"2: \n"
"sub $2, %1 \n"
"pxor %%mm2, %%mm2 \n"
"psubw %%mm0, %%mm2 \n"
"pmaxsw %%mm2, %%mm0 \n"
"paddusw %%mm0, %%mm4 \n"
"jg 1b \n"
"movq %%mm4, %0 \n"
:"=m"(output), "+r"(i_mvc)
:"r"(mvc), "m"(*(struct {int16_t x[4];} *)mvc)
);
sum += output[0] + output[1] + output[2] + output[3];
return sum;
}

And i "translated" it into MSVC inline-assembly

static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
{
uint64_t output;
__asm
{
mov eax, i_mvc
mov edx, mvc
pxor mm4, mm4
test eax, 1
jnz l3
movd mm0, [edx+eax*4-8]
movd mm3, [edx+eax*4-4]
psubw mm0, mm3
jmp l2
l3:
dec eax
l1:
movq mm0, [edx+eax*4-8]
psubw mm0, [edx+eax*4-4]
l2:
pxor mm2, mm2
sub eax, 2
psubw mm2, mm0
pmaxsw mm0, mm2
paddusw mm4, mm0
jg l1
movq output, mm4
}
return ((uint16_t*)&output)[0] + ((uint16_t*)&output)[1] + ((uint16_t*)&output)[2] + ((uint16_t*)&output)[3];
}

Unfortunately the latter one does not give the same result. I traced into the gcc build and it was using eax and edx as %1 and %2. Could someone tell me where the problem is?

Dark Shikari

12th December 2008, 23:02

return ((uint16_t*)&output)[0] + ((uint16_t*)&output)[1] + ((uint16_t*)&output)[2] + ((uint16_t*)&output)[3];I'm pretty sure that this line is enormous violation of strict aliasing.

You need to keep it declared as a uint16_t array.

CruNcher

13th December 2008, 15:02

@roozhou
i realized a slight speed increase with your msvc build when

Slow_mod4_stack is being used compared to the GCC build that doesn't use it :) (AMD Athlon 64 Toledo)
Though not sure if that comes from the MSVC VS GCC difference or the actuall modification yet :)

The difference
(msvc build) x264 [info]: using cpu capabilities: MMX2 SSE2Slow Slow_mod4_stack
(gcc build) x264 [info]: using cpu capabilities: MMX2 SSE2Slow

roozhou

13th December 2008, 15:05

I'm pretty sure that this line is enormous violation of strict aliasing.

You need to keep it declared as a uint16_t array.

Thanks, it works:)

And I wonder which one runs faster.

1

uint16_t output[4];
__asm{
...
movq output, mm4
}
return output[0] + output[1] + output[2] + output[3];

2

uint32_t output;
__asm{
...
movd eax, mm4
punpckhdq mm4, mm4
movzx edx, ax
shr eax, 16
add edx, eax
movd eax, mm4
mov output, edx
movzx edx, ax
shr eax, 16
add edx, eax
add output, edx
}
return output;

roozhou

16th December 2008, 17:16

Updated to 2008-12-16

Well, I finished porting all GCC inline-assembly to MSVC inline-assembly. They works fine for me(with minor cosmetics).

Hope someone could add it to git :)

common/x86/util.h

#define x264_median_mv x264_median_mv_mmxext
static inline void x264_median_mv_mmxext( int16_t *dst, int16_t *a, int16_t *b, int16_t *c )
{
__asm
{
mov eax, a
mov edx, b
movd mm0, [eax]
movd mm1, [edx]
mov eax, c
mov edx, dst
movq mm3, mm0
movd mm2, [eax]
pmaxsw mm0, mm1
pminsw mm1, mm3
pminsw mm0, mm2
pmaxsw mm0, mm1
movd [edx], mm0
}
}
#define x264_predictor_difference x264_predictor_difference_mmxext
static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
{
__asm
{
mov eax, i_mvc
mov edx, mvc
pxor mm4, mm4
test eax, 1
jnz l3
movd mm0, [edx+eax*4-8]
movd mm3, [edx+eax*4-4]
psubw mm0, mm3
jmp l2
l3:
dec eax
l1:
movq mm0, [edx+eax*4-8]
psubw mm0, [edx+eax*4-4]
l2:
pxor mm2, mm2
sub eax, 2
psubw mm2, mm0
pmaxsw mm0, mm2
paddusw mm4, mm0
jg l1
movd edx, mm4
punpckhdq mm4, mm4
movd eax, mm4
add edx, eax
movzx eax, dx
shr edx, 16
add eax, edx
}
}
#undef array_non_zero_int
#define array_non_zero_int array_non_zero_int_mmx
static inline int array_non_zero_int_mmx( void *v, int i_count )
{
if(i_count == 128)
{
__asm
{
mov eax, v
movq mm0, [eax]
por mm0, [eax+8]
por mm0, [eax+16]
por mm0, [eax+24]
por mm0, [eax+32]
por mm0, [eax+40]
por mm0, [eax+48]
por mm0, [eax+56]
por mm0, [eax+64]
por mm0, [eax+72]
por mm0, [eax+80]
por mm0, [eax+88]
por mm0, [eax+96]
por mm0, [eax+104]
por mm0, [eax+112]
por mm0, [eax+120]
packsswb mm0, mm0
movd eax, mm0
test eax, eax
setnz al
and eax, 1
}
}
else return array_non_zero_int_c( v, i_count );
}

kemuri-_9

16th December 2008, 19:26

roozhou

17th December 2008, 06:49

it would have a chance of going into the repository quicker if you:
1. got a clean checkout of the repository
2. add in your changes w/ preprocessor conditionals so only MSVC tries to compile it, without interfering with the current GCC code.
3. use diff to generate a cleanly applyable patch so it can be easily applied+tested.

then when there it has been confirmed to have no problems, it can then make its way in

Well, I am also building with GCC so don't worry about that.

Here is the patch.

diff --git a/common/x86/util.h b/common/x86/util.h
index b67c903..7d41d67 100644
--- a/common/x86/util.h
+++ b/common/x86/util.h
@@ -127,6 +105,96 @@ static ALWAYS_INLINE int array_non_zero_int_mmx( void *v, int i_count )
}
else return array_non_zero_int_c( v, i_count );
}
+#elif defined(_MSC_VER)
+#define x264_median_mv x264_median_mv_mmxext
+static inline void x264_median_mv_mmxext( int16_t *dst, int16_t *a, int16_t *b, int16_t *c )
+{
+ __asm
+ {
+ mov eax, a
+ mov edx, b
+ movd mm0, [eax]
+ movd mm1, [edx]
+ mov eax, c
+ mov edx, dst
+ movq mm3, mm0
+ movd mm2, [eax]
+ pmaxsw mm0, mm1
+ pminsw mm1, mm3
+ pminsw mm0, mm2
+ pmaxsw mm0, mm1
+ movd [edx], mm0
+ }
+}
+#define x264_predictor_difference x264_predictor_difference_mmxext
+static inline int x264_predictor_difference_mmxext( int16_t (*mvc)[2], intptr_t i_mvc )
+{
+ __asm
+ {
+ mov eax, i_mvc
+ mov edx, mvc
+ pxor mm4, mm4
+ test eax, 1
+ jnz l3
+ movd mm0, [edx+eax*4-8]
+ movd mm3, [edx+eax*4-4]
+ psubw mm0, mm3
+ jmp l2
+ l3:
+ dec eax
+ l1:
+ movq mm0, [edx+eax*4-8]
+ psubw mm0, [edx+eax*4-4]
+ l2:
+ pxor mm2, mm2
+ sub eax, 2
+ psubw mm2, mm0
+ pmaxsw mm0, mm2
+ paddusw mm4, mm0
+ jg l1
+ movd edx, mm4
+ punpckhdq mm4, mm4
+ movd eax, mm4
+ add edx, eax
+ movzx eax, dx
+ shr edx, 16
+ add eax, edx
+ }
+}
+#undef array_non_zero_int
+#define array_non_zero_int array_non_zero_int_mmx
+static inline int array_non_zero_int_mmx( void *v, int i_count )
+{
+ if(i_count == 128)
+ {
+ __asm
+ {
+ mov eax, v
+ movq mm0, [eax]
+ por mm0, [eax+8]
+ por mm0, [eax+16]
+ por mm0, [eax+24]
+ por mm0, [eax+32]
+ por mm0, [eax+40]
+ por mm0, [eax+48]
+ por mm0, [eax+56]
+ por mm0, [eax+64]
+ por mm0, [eax+72]
+ por mm0, [eax+80]
+ por mm0, [eax+88]
+ por mm0, [eax+96]
+ por mm0, [eax+104]
+ por mm0, [eax+112]
+ por mm0, [eax+120]
+ packsswb mm0, mm0
+ movd eax, mm0
+ test eax, eax
+ setnz al
+ and eax, 1
+ }
+ }
+ else return array_non_zero_int_c( v, i_count );
+}
#endif

#endif

kemuri-_9

17th December 2008, 07:04

oh right, forgot to mention to put in preprocessor conditionals so that it also doesn't try to compile it when compiling for x64

since in M$ infinite wisdom and power (/sarcasm), inline asm is not accepted for x64 building....

changing
#elif defined(_MSC_VER)
to
#elif defined(_MSC_VER) && defined(_M_IX86)
should be the most effective way to achieve this

the other option would be to export it out to assembly files to be compiled with yasm so that it could be used in both x86 and x64...
(granted getting the x64 part to actually work is going to be even more of a task)

roozhou

17th December 2008, 07:38

the other option would be to export it out to assembly files to be compiled with yasm so that it could be used in both x86 and x64...

No, they cannot be inlined once written in an asm file. I guess DS does not like these routines to be called as functions so he choose inline-assembly.

squid_80

17th December 2008, 12:27

since in M$ infinite wisdom and power (/sarcasm), inline asm is not accepted for x64 building....Visual Studio can't do it, but Intel's compiler has no such restrictions.

kemuri-_9

17th December 2008, 14:37

that's what i said!
but didn't know about it working for ICC since i don't use it...

Ranguvar

17th December 2008, 23:01

Why not (over MSVC)? ICC is free for private use on Linux, and last I checked, beat the holy crap out of GCC and MSVC in most scenarios. Obviously not against GCC with x264, but..

kemuri-_9

17th December 2008, 23:31

Why not (over MSVC)? ICC is free for private use on Linux, and last I checked, beat the holy crap out of GCC and MSVC in most scenarios. Obviously not against GCC with x264, but..

well, I already have mingw 32/64 & Vis Studio 2008 pro,
I don't need a 3rd C/C++ compiler.

both are free, mingw being open source, and Visual Studio through the msdnaa.

/OT

well if ICC can handle that inline asm fine for both x86 and x64, then there's more preprocessor conditionals to add...

CruNcher

18th December 2008, 01:18

Might be of interest to some intel is going to start the Beta of their new Parallel Composer for Visual Studio
http://isdlibrary.intel-dispatch.com/isd/2146/Intel%20Parallel%20Composer%20Parallelization%20Guide.pdf

Dark Shikari

18th December 2008, 01:39

Why not (over MSVC)? ICC is free for private use on Linux, and last I checked, beat the holy crap out of GCC and MSVC in most scenarios. Obviously not against GCC with x264, but..Last time I saw a test ICC beat GCC by something like 2-4% on x264, though on a few sets of encoding settings it actually lost by about 1%.

Remember, ICC has GCC compatibility mode, so it can read all the inline asm/etc without any compatibility hacks.

Ranguvar

18th December 2008, 04:44

Well, that's really quite unfair to benchmark with :p Of course you're not going to see huge benefits; almost anything in x264 that can be optimized by hand asm has. There's not many places left for a good compiler to strut its stuff. Or are those numbers from compiling without handwritten asm?

http://www.usenetbinaries.com/doc/gcc_vs_icc_benchmarks_perl.html
http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
http://sebastian-bergmann.de/archives/634-PHP-GCC-ICC-Benchmark.html

Actually, I am wrong, I way over-exaggerated the difference - brain fart, apologies. But while it isn't a HUGE difference, but it's noticeable, and fairly consistent.

I'm not a fan of ICC by any means, though :)

Dark Shikari

18th December 2008, 04:50

Well, that's really quite unfair to benchmark with Benchmark? This is a thread about x264. We only care about how much faster it is at--surprise--x264.

Ranguvar

18th December 2008, 05:16

Benchmark? This is a thread about x264. We only care about how much faster it is at--surprise--x264.

My original post was purely to point out that ICC had no real disadvantage as compared to MSVC, indeed would be preferable, and had a free version for Linux users (private use only). I probably shouldn't have mentioned speed as it was out of context, sure, but later I was just debating your statement in reply.

roozhou

26th December 2008, 08:00

Updated to r1061
Full source codes now available.

A GUI written in delphi is coming soon...

CruNcher

26th December 2008, 20:53

Thx roozhou can't wait for the GUI and soon GPU support :) (please keep the Directshow Chain Controll in mind)
Merry Merry Christmas to you :)

roozhou

15th January 2009, 12:24

Updated to r1077
I created a project on SF.net. Get src code from svn repository:
https://direct264.svn.sourceforge.net/svnroot/direct264

buzzqw

20th February 2009, 16:32

there are no new builds on sourceforge...

is the project dead ?

BHH

roozhou

23rd February 2009, 09:39

No, i am still working on it.
The damned China Great Firewall added doom9 to its blacklist for some unknown reasons. It is difficult for me to find a fast proxy in US to access this forum.

buzzqw

23rd February 2009, 11:19

that's stink!

BHH

roozhou

25th February 2009, 14:04

Wow i can logon to doom9 again :) Plz check my new build.

Changelog:
* Updated x264 to r1114
* Added field matching filter "phase"
* Improved accuracy of deldup filter on fade-in/fade-out
* CTAACEncoder and dshow2wav support unicode file name
* Slightly speed boost in x264
* Reduced memory leak in vsfilter

buzzqw

25th February 2009, 16:30

welcome back! and thanks for the new build!

BHH

sacharja

27th February 2009, 15:21

The damned China Great Firewall added doom9 to its blacklist for some unknown reasons. It is difficult for me to find a fast proxy in US to access this forum.
Use JAP (http://anon.inf.tu-dresden.de/index_en.html). It's the number one utility for anonymouse surfing. Actually it was made against censurship, impossible for any government to to track you down. Mirror: http://www.download.com/JAP/3000-2213_4-10671702.html

On topic: are you working on the GUI? Will it support all features of x264 or less than the vfw version?

roozhou

27th February 2009, 16:14

On topic: are you working on the GUI? Will it support all features of x264 or less than the vfw version?
Actually I have not been working on the GUI for several months since I don't have much time to learn how to make a GUI. It should support all features of x264 and additional functions that neither official x264 nor x264vfw has.

sacharja

28th February 2009, 17:13

Actually I have not been working on the GUI for several months since I don't have much time to learn how to make a GUI. It should support all features of x264 and additional functions that neither official x264 nor x264vfw has.
Hm, a GUI like VirtualDub would be cool. However if you're going to copy parts of it it might be faster to patch VD to accept WDM codecs.

If you want to stay platform independent you can use Qt framwork: http://en.wikipedia.org/wiki/Qt_toolkit

The quickest and dirtiest method would be Delphi. GUI Programs in Delphi are always really big because Delphi saves always saves all GUI elements. However this would be the easiest method.

roozhou

1st March 2009, 01:49

Hm, a GUI like VirtualDub would be cool. However if you're going to copy parts of it it might be faster to patch VD to accept WDM codecs.

VD uses outdated vfw not dshow.

If you want to stay platform independent you can use Qt framwork: http://en.wikipedia.org/wiki/Qt_toolkit

And directshow is windows only so i don't care about platform independence.

The quickest and dirtiest method would be Delphi. GUI Programs in Delphi are always really big because Delphi saves always saves all GUI elements. However this would be the easiest method.
Yes i am using Delphi. The executable is not as big as QT/GTK because it does not rely on any extra runtime library.

buzzqw

1st March 2009, 10:38

sacharja

1st March 2009, 10:57

Hm, a GUI like VirtualDub would be cool. However if you're going to copy parts of it it might be faster to patch VD to accept WDM codecs.VD uses outdated vfw not dshow.
Google:
Windows Driver Model (WDM) is the new basis for more modern drivers that will work with Win98, ME, 2K, and XP. WDM drivers are available for TV-cards either as generic chipset drivers or for specific cards. It supports a more robust featureset and interface, especially the ability to control built-in TV tuners (a shortcoming of VfW). However, the author of VirtualDub notes that it is confusing and difficult to program for compared to the straightforward simplicity of VfW.

Yes i am using Delphi. The executable is not as big as QT/GTK because it does not rely on any extra runtime library.
The difference is that you can adjust Qt to just include the needed GUI parts. Delphi instead includes all buttons, dialogs and god know what else. A good Qt program can be smaller than it's Delphi component.

roozhou

1st March 2009, 12:27

coding a gui isn't too hard.. the worst part is to set the directshow interface!

not all user will use ffdshow, other will use coreavc... other what else!

i strongly suggest to add some more options to your x264 command line
like fps, width, height, and ... maybe resizer to use (from ffmpeg or mencoder ?) or denoiser ? (hqdn3d)

BHH

You can use CoreAVC for decoding and ffdshow for postprocessing.

I prefer "as long as you can watch it, you can encode it". FFDshow allows you to preview and tweak when you watch it. But if i add filters to the command line, how can you know the real effect of these filters?

martino

1st March 2009, 13:18

And directshow is windows only so i don't care about platform independence.

It works under wine as well FYI.

buzzqw

1st March 2009, 13:30

roozhou

1st March 2009, 13:50

@roozhou

take this example:

i have a fullhd m2ts, and want to do a 720/XXX rip.

How i can set resolution ? must i use ffdshow resizer ? but on coreavc ? what can i do ?

users don't know registry, ffdshow tweak, avisynth, or whatever.. just want to set resolution and how big output file must be.

from developers view you must know what is the preferred decoder, and "tweak" it for your user otherwise the output file will not be resized

more over.. not all decoder support resizing!

so take your decoded frames (as directshow pass, and this is a responsibility of users!), apply a resizer, and encode.

hope to be understud

BHH

In ffdshow video decoder configuration's "Codecs" page, set "Raw video" to "All supported", then ffdshow will be automatically inserted between coreavc and dump renderer. It is not very difficult for a GUI to apply this by modifying the registry. A friend of mine also write a .bat script to implement resizing and cropping by modifying ffdshow's registry entries.

buzzqw

1st March 2009, 15:02

yes, that's true

but, imho, it's better if ffdshow isn't tweaked every time you encode

if crop/resize could be implemented on x264 it's better
but again ... just my 0.02€

BHH

roozhou

1st March 2009, 16:30

yes, that's true

but, imho, it's better if ffdshow isn't tweaked every time you encode

if crop/resize could be implemented on x264 it's better
but again ... just my 0.02€

BHH

I will add crop and ivtc to x264 soon. Resizing may be a bit complicated for me.

buzzqw

1st March 2009, 18:01

you could look at mplayer source for inspiration

thanks for your continuos work!

BHH

P.S. on what will be based ivtc ?

roozhou

2nd March 2009, 19:34

you could look at mplayer source for inspiration

thanks for your continuos work!

BHH

P.S. on what will be based ivtc ?

A small field-matching filter is already included in the latest dshow_x264 package. This is very similar to mplayer's phase filter but with MMX and SSE2 optimization it runs 3~6 times faster than mplayer's plain C code.

Currently it only works well in YUV 4:2:2 not YUV 4:2:0 so it can only be used in ffdshow. I will add a YUY2->field-match->YV12 interface and it can work with x264.

JohannesL

3rd March 2009, 03:58

Thank you so much for this awesomeness. Especially Deldup. Deldup is so much better than any of AviSynth's decimate filters, and decimation does shave off an underestimated amount of bytes.

I have one suggestion: --audiofile. That way we wouldn't have to use a separate muxer application to add sound.

roozhou

23rd March 2009, 04:14

Updated again
Plz check 2009-3-20 download link

buzzqw

20th April 2009, 12:14

thanks for the update!

(i just missed your post :p)

EDIT: any news about resizing/crop ?

BHH

roozhou

21st April 2009, 10:47

DShow x264 has been updated again
A new function "ivtc" is added to x264.

Make sure your decoder support YUY2 output, and simply adding "--ivtc t" to your x264 cmdline will enable ivtc.

It can automatically handle mixed hard/soft telecine DVD. Hard telecined parts will be IVTCed and soft telecined part will remain unchanged.

@buzzqw
I will try to add crop next month. There is no plan of adding resizing to x264 since it is too complicated. Actually i will never add a filter that does real modification to the source image. Cropping and field matching only "cut" or "move" parts of the image.

buzzqw

21st April 2009, 11:12

thanks for the update

what about deinterlace ?

BHH

b66pak

21st April 2009, 18:31

@ roozhou thanks a lot...

@buzzqw if you have avisynth and ffdshow installed you can do crop and resizing from ffdshow...start "ffdshow video decoder config" and go to "avisynth" field...enable it...paste your .avs [for example: Spline36Resize(624,352,2,3,4,-3)]...apply and OK...now double click your video to verify the results...if its croped and resized the go to encoding...dont forget to disable the "avisynth" checkbox after encoding!!!
_

buzzqw

21st April 2009, 18:35

@b66pak

good tip, thanks :)

BHH

roozhou

21st April 2009, 18:38

b66pak

21st April 2009, 18:41

sure...but is not as flexible as avisynth...
_

b66pak

21st April 2009, 19:27

@ roozhou i am a little unsure with --deldup and --ivtc a...

what would be the right setup for a 2pass encoding from a 30fps pulldown dvd source?
_

roozhou

21st April 2009, 19:30

sure...but is not as flexible as avisynth...
_

Can you provide an example? IMHO ffdshow works well in at least 99% of all cases.

b66pak

21st April 2009, 19:42

from ffdshow crop box: "Crop - width and height of cropped area are rounded to multiplies of eight"...i am not saying that avisynth should be used...i am saying that is more flexible...it was just a hint...everybody should use what is fitted for their needs...

what about:

@ roozhou i am a little unsure with --deldup and --ivtc a...

what would be the right setup for a 2pass encoding from a 30fps pulldown dvd source?
_

roozhou

21st April 2009, 20:20

@ roozhou i am a little unsure with --deldup and --ivtc a...

what would be the right setup for a 2pass encoding from a 30fps pulldown dvd source?
_

Use --ivtc t for each pass.

Crono141

25th April 2009, 18:16

Did we ever figure out how to crop and deinterlace with Direct264? Perhaps by passing parameters (such as cropping values and deinterlacing method) to ffdshow? Is this even possible?

I tried endcoding straight from IFO (School of Rock DVD). It seems that the .h264 video produced from this encode is messed up somehow. TSmuxergui reports "Bad SEI detected. SEI too short" about a bazillion times, then fails to mux. I tried again with ffdshow "deinterlace" and "autocrop" and got the same results.

I opened the resulting h264 video in VLC, and got a non-seekable video stream, but the ffdshow croppings moved and changed throughout the video (of the 5 minute sample I watched). It seems for cropping we need to have a way to pass cropping values to ffdshow. I'm not even sure if that is possible at command line or not.

Also, this movie is telecined, and I don't know of any way to remove that without using avisynth. I'm kindof a noob when it comes to various interlacings and how to handle them. I know avisynth can do it, but I was under the impression that the point of Direct264 was to avoid avisynth.

Hope this is somehow helpful to the developer.

roozhou

25th April 2009, 22:54

Did we ever figure out how to crop and deinterlace with Direct264? Perhaps by passing parameters (such as cropping values and deinterlacing method) to ffdshow? Is this even possible?
This can be done writing a .bat script that modifies reg keys.

Also, this movie is telecined, and I don't know of any way to remove that without using avisynth. I'm kindof a noob when it comes to various interlacings and how to handle them. I know avisynth can do it, but I was under the impression that the point of Direct264 was to avoid avisynth.

As I mentioned in previous posts, direct264 has a built-in ivtc filter. Just add "--ivtc t" to x264.exe's parameters.

roozhou

29th April 2009, 11:39

Updated again. Plz check the 2009-04-28 release.
A bunch of bugs in ivtc filter have been fixed.

b66pak

29th April 2009, 19:28

thanks...
_

b66pak

30th April 2009, 19:06

i have tested the -ivtc but it looks like it is rarely decimating the duplicate frames:

here is my test sample:

http://www.mediafire.com/?ag9le4amhbx

i have used "--ivtc t --deldup minfps 1"
_

L.E. the sample (MPEG2, 480i60 /1.001 (16:9) has 1955 frames @ 29.97...after ivtc with an .avs script [DGDecode_mpeg2source("E:\hard_pulldown_vob.d2v", info=3).ColorMatrix(hints=true, interlaced=true, threads=0).tfm(order=1).tdecimate()] i get 1564 frames @ 23.976...

your ivtc gives me 1724 frames...
_

roozhou

30th April 2009, 21:32

Use "--ivtc t --deldup 24:3". It gave me 1568 frames and looked OK. The default deldup parameter 24:1.2 may be too small to handle real action videos.

b66pak

1st May 2009, 17:48

thanks for the reply...you must explain more clear (end with examples) this statement:

"--deldup minfps[:lthresh[:mbthresh[:mbmax[:cthresh]]]]"

if i understand it write "--deldup minfps 1" means delete a dupe frame sequence until you get a minimum 1fps...

what is the meaning of "--deldup 24:3"?
_

L.E. i used with great success "--deldup minfps 1" with cartoons (like South Park) and i get an encoding with 60-70% of the original frames (1/3 shorter!!!!)
_

roozhou

2nd May 2009, 04:31

thanks for the reply...you must explain more clear (end with examples) this statement:

if i understand it write "--deldup minfps 1" means delete a dupe frame sequence until you get a minimum 1fps...

what is the meaning of "--deldup 24:3"?

"--deldup 24:3" means minfps=24, lthresh=3 and other parameters set to default.

"minfps=x" means skipping duplicate check if the interval of two frames are greater than 1/x secs.

If the video contains mixed hard-pulldown and soft-pulldown parts, minfps=24 will help keeping soft-pulldown part as is.

b66pak

4th May 2009, 19:50

hi, i try to and timecodes to a .mp4 but i can't find anywhere dtsedit...do you have a link to the most recent version?
_

P.S. and be kind an post the command line too...

thanks in advance...
_

roozhou

5th May 2009, 04:46

Why do you need dtsedit?
Direct264 will directly output vfr mp4. If you need extra timecodes v2 file, add to x264 command line "--timecode xxx" where xxx is the timecode filename.

b66pak

5th May 2009, 17:11

i have encoded to .h264 (it will be a lot of time wasted to encode again!)...can you provide the link please?

thanks in advance...
_

sometimes (random) the .mp4 generated by x264 are plagued by "invalid atom" error when you try to play it in QT...you can fix it only by demuxing to .raw and remuxing again...to avoid this i always encode to .h264 from the start...
_

roozhou

6th May 2009, 04:26

From a quick google search I cannot find any link available, so I uploaded it myself.

http://files.filefront.com/DtsEdit+20081009rar/;13716059;/fileinfo.html

It seems that mp4 output may produce negative pts offset value where it should be 0. It will be fixed in next release.

b66pak

6th May 2009, 18:51

thanks a lot...the readme, the help, and the .bats are in japanese (i think)...can someone help with translation?

@roozhou how do i use it? (command line for inserting/extracting timecodes from .mp4?)
_

L.E. after same tests i have success with this:

rem extract timecodes

dtsedit -o input.mp4_timecodes.txt input.mp4

rem insert timcodes

dtsedit -tc input.mp4_timecodes.txt input.mp4

there are a lot of other switches...it needs translation!
_

roozhou

15th May 2009, 11:08

Updated again.
MP4 output should be OK now.

@b66pak
Please try the latest build and check whether "invalid atom" error remains.

b66pak

15th May 2009, 16:58

thanks...
_

b66pak

15th May 2009, 18:51

roozhou

15th May 2009, 19:46

with QT i get a nasty 2sec green delay:

http://www.mediafire.com/?r2qci5jjomn

included _make.bat will demux and remux to a proper .mp4...
_

L.E. DtsEdit_20081009 didnt work so i used tc2mp4Mod20080617 ( http://zoome.jp/VFR_maniac/diary/6/ )
_

Can you provide the full command line you used to encode the clip? It seems the resulting timestamps are incorrect.

b66pak

16th May 2009, 16:33

x264.exe "20s-sample.mkv" --sar 1:1 --bitrate 1000 --keyint 24 --pass 1 --stats "20s-sample.mkv.2pass.VFR.L30.C0.mkv_stats.stats" --level 3 --min-keyint 1 --deblock 1:1 --no-cabac --subme 2 --partitions none --vbv-bufsize 10000 --vbv-maxrate 10000 --me dia --threads auto --thread-input --aq-mode 0 --progress --no-psnr --no-ssim --deldup minfps 1 --output NUL 2>"20s-sample.mkv.2pass.VFR.L30.C0.mkv_log_pass1.log"

x264.exe "20s-sample.mkv" --sar 1:1 --bitrate 1000 --keyint 24 --pass 2 --stats "20s-sample.mkv.2pass.VFR.L30.C0.mkv_stats.stats" --level 3 --min-keyint 1 --deblock 1:1 --no-cabac --psy-rd 0.6:0 --partitions p8x8,b8x8,i4x4 --vbv-bufsize 10000 --vbv-maxrate 10000 --threads auto --thread-input --aq-mode 0 --aud --progress --no-psnr --no-ssim --deldup minfps 1 --timecode "20s-sample.mkv.2pass.VFR.L30.C0.mkv_timecodes_v2.txt" --output "20s-sample.mkv.2pass.VFR.L30.C0.mp4" 2>"20s-sample.mkv.2pass.VFR.L30.C0.mkv_log_pass2.log"

_

roozhou

16th May 2009, 16:37

You should use "--deldup 1" instead of "--deldup minfps 1"
And try adding "--fps 24000/1001"

And did you get "mp4 [warning]: please use larger initial delay" in your logs?

b66pak

16th May 2009, 17:49

nope...

mp4 [info]: initial delay 0 (scale 24000)

_

roozhou

16th May 2009, 18:26

You are not using b-frames!
There should not be any dts/cts problem since dts == cts.

b66pak

16th May 2009, 18:35

yes i am not...i don't know what is the meaning of "dts == cts"...what i am trying to say is that with the last build i get 2 seconds of green screen at the begin when i play the .mp4 in QuickTime...older builds don't have this problem...can you play the sample in the previous link in QT without the green screen?
_

L.E. considering that this artefact is corrected by demuxing to raw and remuxing i suspect it is a bug of x264 mp4 muxer...
_

roozhou

16th May 2009, 19:01

VFR maniac

16th May 2009, 19:24

DTS = Decoding TimeStamp
CTS = Compositon TimeStamp

If a stream has B-frames, the decoding order is not equal to the composite order.

Green screen is generated on QT since decoding delay exists, so this is not a bug of x264 mp4 muxer if the stream has B-frames.
If you annoy this green screen and/or decoding delay, please insert edts/EditBox or set the first CTS to 0, or use splitters that deny decoding delay like Haali media splitter.

roozhou

16th May 2009, 19:42

@VFR maniac
b66pal was not using B-frames.
I checked his mp4 with ffmpeg. The initial delay is 0 and for every frame pts == dts.

The modification I made to x264's mp4 muxer should have no impact when B-frame is not used.
I also updated GPAC library from 0.4.5 to latest CVS. Is this a bug in GPAC?

CruNcher

16th May 2009, 20:50

wouldn't surprise me roozhou i wish bobololo would have chosen Ciscos muxer back then then implementing GPAC :(

VFR maniac

16th May 2009, 20:52

Hmm...　it is certainly first CTS=0 and no delay exists.
I do not understand the cause.

roozhou

19th May 2009, 13:32

@b66pak
Please try my new build. The green-screen bug has been fixed.

b66pak

19th May 2009, 19:46

thanks...it is working nice now...
_

unranger

22nd May 2009, 21:33

9) --timescale <int>: Set denominator of initial fps. Useful to achieve pure CFR mp4. If not set, x264 will choose a proper value according to fps. PSP only accepts timescale <= 60000

timescale = denominator or numerator? More info on this parameter?

roozhou

23rd May 2009, 10:15

timescale = denominator or numerator? More info on this parameter?

:stupid: It should be numerator of fps!
Fixed.

JohannesL

8th June 2009, 20:14

Isn't it about time you put a name in the topic title?

roozhou

8th June 2009, 20:36

Isn't it about time you put a name in the topic title?

Haven't planned to change the title. Any suggestion?

JohannesL

8th June 2009, 20:53

Direct264 - special x264 CLI build that supports input from DirectShow

From my experience, most people don't know what the heck "Direct264" is, since it's only mentioned in your MediaFire link. For a while I just called it "roozhou's x264 CLI build, search for it on doom9". Having an etablished name for your build is a good thing if you want to reach the masses.

roozhou

8th June 2009, 21:05

Well, Direct264 is a planned name of the GUI for my DirectShow tools, and it is still in early stage.
Anyway, thanks.

buzzqw

9th June 2009, 07:09

Well, Direct264 is a planned name of the GUI for my DirectShow tools, and it is still in early stage.

:cool:

want to test it :)

BHH

Sirber

9th June 2009, 22:48

really cool project! trying :D

Sirber

11th June 2009, 13:02

any plan for an x64 version?

roozhou

11th June 2009, 13:36

any plan for an x64 version?

As soon as i switch to 64bit Windows:rolleyes:

roozhou

11th June 2009, 17:32

New build available (2009-6-11)

b66pak

11th June 2009, 17:37

thanks...how do i force the first frame to be always an I frame? (in order to avoid delay in .mp4)
_

roozhou

11th June 2009, 17:53

There is no initial delay in mp4 from this build on.

b66pak

11th June 2009, 18:44

good news...but for my knowledge how do i force the first frame to be always an I frame?
_

roozhou

11th June 2009, 18:54

x264 always encode the first frame as an I frame.

Sirber

11th June 2009, 22:16

thanks for the new build! :)

Sirber

4th July 2009, 16:40

* Support multi-subtitles in x264. Enable with multiple "--sub subfile".

They will all display at the same time?

roozhou

4th July 2009, 17:31

They will all display at the same time?

Yes, you can have one in the bottom and one in the top.

Sirber

8th July 2009, 03:59

Is there a way to select a subtitle from the stream (like mkv) to be bundled into the video, like we can do for audio?

roozhou

8th July 2009, 04:28

Is there a way to select a subtitle from the stream (like mkv) to be bundled into the video, like we can do for audio?

No, so far I haven't found a way to extract complete subtitle out of streams via dshow. There is no way to turn on/off embedded subtitle from x264 cmdlines. You have to use vsfilter's DirectVobSub interface (regsvr32 vsfilter.dll) or ffdshow's internal subtitle renderer, or demux subtitles using mkvtoolnix or ffmpeg before encoding.

Sirber

8th July 2009, 12:47

k, thanks! :D

roozhou

8th July 2009, 14:09

new build available
check out the latest version from sf.net

b66pak

8th July 2009, 19:14

thanks...
_

roozhou

21st July 2009, 08:19

Updated x264 and ffmpeg

roozhou

29th July 2009, 16:42

Updated x264 to r1195

JohannesL

4th August 2009, 19:05

Any idea why --timecode "times.txt" does nothing? I'm running XP SP3.
x264 "AVS.avs" --crf 20 --8x8dct --deldup 1 --ref 3 --subme 6 --me hex --bframes 4 --timecode "times.txt" -o "Video.264"

roozhou

4th August 2009, 20:21

--timecode and --deldup are used for variable framerate output and are only available with DIRECTSHOW input.

One important thing you should know is that avisynth requires constant framerate output. You have to either duplicate frames or drop frames to maintain a fixed fps without breaking A/V synch. Some source filters like ffms do not add or drop frames but they throw away all timestamp information so writing a timecode file is pointless.

Please directly encode from your source file instead of putting it in an .avs script. This is why I make this tool. If you use avs, there is no difference between my build and official builds.

JohannesL

5th August 2009, 13:03

roozhou

5th August 2009, 13:17

So the only way to edit with an AviSynth script and still use --deldup is to make a lossless encode from the avs and then use the lossless encode as Direct264 input? >_> ffdshow's AviSynth tab is limited..

Try graphedit and .grf files.

Could you tell me which plugin you are using in your script?

JohannesL

5th August 2009, 17:18

I often use scripts that cut and join several video and audio tracks. Will that work in ffdshow's AviSynth tab?

roozhou

6th August 2009, 09:49

I often use scripts that cut and join several video and audio tracks. Will that work in ffdshow's AviSynth tab?

No, you cannot use trim inside ffdshow's avisynth tab. Instead you can use --starttime and --endtime to encode single segments of each video and join encoded segments altogether later on.

JohannesL

6th August 2009, 11:39

I'd rather use one AVS and encode with my BAT that makes a H.264 + Vorbis MKV out of an AVS.

popper

7th August 2009, 09:45

Here I explain how it works:

This is the first time for me to write a directshow app. "
...

Here is my wish list:
* Support ".grf" files.
* Encoding directly from DVD and TV.
* Combine aac encoder to x264 and mux aac to mkv or mp4.

I also need a one-pass adaptive ivtc dshow filter (not avisynth filter, they either need index or do not work in one-pass mode). I cannot find anything like that, so maybe i need to port one from MPlayer or write it from scratch.

roozhou, given its nearly 12 months on, i wonder if you got anywere with your Original wishlist ?

the one thing that strikes me as required still, is the internal aac,mkv/mp4 capability....

im not sure if its a generic mp4 container thing/fault but it appears we cant actually pipe our input throuqh any app (Direct264 in this case) in realtime to another app ,(only directly to a file on disk), im thinking "PS3 Media server" http://ps3mediaserver.org/forum/viewtopic.php?f=2&t=919&sid=2c6c26183c4a7dcb84390d00f913128e
and get a usable realtime transcoded HD.Mp4 file from the (windows) pipe....for 360 realtime playback.

is there anything you can do to help make this possible in the future as Mp4 is the only viable option for 360 AVC/AAC use really today.

popper

7th August 2009, 10:06

I'd rather use one AVS and encode with my BAT that makes a H.264 + Vorbis MKV out of an AVS.

if as you say you prefer AVS scripting as your input, in which case you dont need Direct264 then, any generic x264 compile will do, so why are you useing Direct264 ?

roozhou

7th August 2009, 17:43

@popper
Do you mean x264 streaming MP4 to 360 for realtime playback?
I have no idea how streaming works with MP4. AFAIK index of dts and pts are appended to the end of MP4 file after all frames are encoded. There are no timestamps along with each frame so how can a media player keep A/V synch. when playing an incomplete MP4 file?

JohannesL

7th August 2009, 20:59

if as you say you prefer AVS scripting as your input, in which case you dont need Direct264 then, any generic x264 compile will do, so why are you useing Direct264 ?
Because I like --deldup. Tough luck. It's not that important though, so I changed back to using generic compiles.

b66pak

8th August 2009, 17:09

@JohannesL load your .avs in ffdshow avisynth panel and fire up the direct264!
_

roozhou

18th August 2009, 13:42

Updated to r1214
Added experimental AVI output support (just for fun)

JohannesL

21st August 2009, 13:44

Added experimental AVI output support (just for fun)
So much for making people realize H.264 in AVI is bad..

roozhou

21st August 2009, 19:01

So much for making people realize H.264 in AVI is bad..

Yes it's bad, but it works.

popper

21st August 2009, 19:14

Updated to r1214
Added experimental AVI output support (just for fun)

hmm, i tryed the avi out on a simple first page direct264 download,depack,copyed a really old drwho.mkv there and did a simple
x264 drwho.mkv -o drwho.avi
it crashed x264 straight away.

wereas
x264 drwho.mkv -o drwho.mp4
(with divx/AAC=2 inside)
seems to work fine, its still going, so im not 100% sure yet, but it didnt crash x264 on starting and the encoding is progressing.
see below:

sounds dumb, but i am right in saying -o something.avi is the right way to tell your for fun 'avi container' output to be initiated ?

PS yes is the answer to to your question:
"@popper
Do you mean x264 streaming MP4 to 360 for realtime playback?
"

currently PS3 media server doesnt use mp4 as a realtime transcoding container, and always uses the wmv container on 360 as thats his/anyone's only option right now, apparently because of the way mp4 does whatever it does?, if infact there is a way to use mp4 for transcoding a stream he would like to know the tool that can do that and why that can but others cant, as would i.

im simply looking to find a way if its even possible as it stands without MS updating the containers (put a mkv in there please) the 360 has inside the firmware, to add AVC/AAC inside a container the 360 can stream and decode directly, thats Mp4 or avi as you cant put or transcode AVC/AAC into an wmv container and have it stream and play ON the xbox360 AFAIK ?.

update:
it finished and then crashed direct264 but seems to have written the full mp4 at least.

No it didnt, the files not usable, and 'mediainfo' cant get any usable info from the mp4 file after
File size : 311 MiB.

"x264 [info]: profile High, level 3.0
x264 [info]: slice I:406 Avg QP:22.24 size: 18289
x264 [info]: slice P:22373 Avg QP:25.20 size: 11161
x264 [info]: slice B:12312 Avg QP:26.52 size: 5627
x264 [info]: consecutive B-frames: 30.0% 67.9% 0.4% 1.7%
x264 [info]: mb I I16..4: 3.4% 95.2% 1.4%
x264 [info]: mb P I16..4: 1.5% 34.7% 0.2% P16..4: 37.3% 21.1% 3.4% 0.0% 0
.0% skip: 1.8%
x264 [info]: mb B I16..4: 0.4% 6.5% 0.0% B16..8: 56.8% 2.1% 1.2% direct:
10.2% skip:22.9% L0:31.5% L1:34.7% BI:33.9%
x264 [info]: 8x8 transform intra:95.1% inter:90.7%
x264 [info]: coded y,uvDC,uvAC intra:82.9% 21.0% 0.1% inter:48.9% 3.7% 0.0%
x264 [info]: ref P L0 73.7% 17.1% 9.3%
x264 [info]: ref B L0 89.2% 10.8%
x264 [info]: kb/s:1860.3"

roozhou

22nd August 2009, 03:48

hmm, i tryed the avi out on a simple first page direct264 download,depack,copyed a really old drwho.mkv there and did a simple
x264 drwho.mkv -o drwho.avi
it crashed x264 straight away.
"

It seems there was problems with your mkv file. Could you provide more information about your input file (at least "dshow [info]" line in x264's console output)?

popper

22nd August 2009, 06:39

It seems there was problems with your mkv file. Could you provide more information about your input file (at least "dshow [info]" line in x264's console output)?its really odd, after you said the above i looked into it.

at first i thought it might be the oddball 516x570 non mod16 file, so i made a 6 minute clip from the first one in avidemux with direct copy into another mkv container.

that oc changed the mediainfo data slightly.

and again that crashed as before, i made a rar and put the cli data in there too etc, uploading that now to filefront, but in the meantime i also went back to basics and loaded both files directly into graphstudio and that shows the right A and V graphs.

however i also then made an Doctor-Who.avs and loaded that indirectly loaded clip into graphstudio and MPC HC and that would NOT pick up a directshow video but did an audio filter....

so its odd and im lost now, directly it works in graphstudio , indirectly through a
"DirectShowSource("g:\direct264_20090818\ppp\Doctor-Who.aac-6-minute-clip.mkv")"
it does NOT, it also crashs graphstudio on close as your direct264 does.

it leads me to think, does your code also use AVS/graphstudio code to parse the direcshow filters graph ?

and whats gone wrong with some part of my chain!

am i missing something really silly and basic ;|

its probably not werth it now but the clips here if you want to see if it will crash http://www.filefront.com/14346601/DW-clip-direct264_20090818.rar

it think it wont OC after the above...

loading it directly plays fine OC, but loading the avs into mpc HC i get this
"G:\direct264_20090818\ppp\Doctor-Who.aac-6-minute-clip.mkv.avs::Avisynth video #1

Media Type 0:
--------------------------
Video: YV12 516x570 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 441180
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

BITMAPINFOHEADER:
biSize: 40
biWidth: 516
biHeight: 570
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 441180
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 28 00 00 00 04 02 00 00 3a 02 00 00 01 00 0c 00 (.......:.......
0040: 59 56 31 32 5c bb 06 00 00 00 00 00 00 00 00 00 YV12\»..........
0050: 00 00 00 00 00 00 00 00 ........

"
and the direct graphstudio shows
dw.mkv>coreaac audio decoder>ac3filter>directsound
and
dw.mkv>ffshowvideodecoder>vmr>video renderer connected.

but on the avs graphstudio is only showing
dw.avs>ac3filter>directsound

AND mpc HC played the sound...without video
but mpc is parsing at least the Video: YV12 516x570 25.00fps part out of it.... :confused:

popper

22nd August 2009, 08:49

right: this is doing my nut in now.

as before i just finished using the
DirectShowSource("g:\direct264_20090818\ppp\Doctor-Who.aac-6-minute-clip.mkv")

i downloaded the current 1222 from here
http://x264.nl/

i ran the avs as x264-1222
x264 Doctor-Who.aac-6-minute-clip.mkv.avs -o dw.mp4
it works, no crash.

i ran the avs as your direct264
x264 Doctor-Who.aac-6-minute-clip.mkv.avs -o dw1.mp4
it works, No crash.

i ran the avs as your direct264
x264 Doctor-Who.aac-6-minute-clip.mkv.avs -o dw2.avi
it works, No crash.

i ran the mkv directly again as your direct264
x264 Doctor-Who.aac-6-minute-clip.mkv -o dw3.avi
it crashs.

i ran the mkv directly again as your direct264
x264 Doctor-Who.aac-6-minute-clip.mkv -o dw3.mp4
it crashs as before.

conclusion: even though the avs doesnt work for the video part in mpc,or graphstudio :confused:

using indirect avs Does work fine for the Encoding.
using direct current direct264 does not For ME!

the only difference in the lines are

1222
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64

direct264
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 Slow_mod4_stack

and the dll's and ax as supplyed in your current direct264 download
does this make sense if its working directly from a clean dir for everyone else!
windows fully updated xp sp3, core 2 dual E4400, 2Gig ram.
i cant get on the quad today to try it clean there...

JFYI your slightly older 1214 x264 version also makes a slightly bigger mp4 file, not that that matters right now OC.

roozhou

22nd August 2009, 09:11

AND mpc HC played the sound...without video
but mpc is parsing at least the Video: YV12 516x570 25.00fps part out of it.... :confused:

My bad. I use x264_memcpy_aligned_mmx, which require WxH to be mod32, to copy frames in dshow input mode. You need to make mod32 resolution by cropping.

Since I always use ffdshow's cropping for testing(requires mod8 on both width and height), this bug has never shown to me.

It will be fixed in next version.

popper

22nd August 2009, 09:22

ohh well it was werth it then ;) glad it was a found bug and not my nut going wrong.

theres still my avs not working in mpc and graphstudio , but thats for another thread perhaps, or did i expose another bug somewere in them too!, it should work 'as is' shouldnt it.

BTW, thanks for taking the time to find that and fix it....

and regarding my above '12 months on' question to your
"* Combine aac encoder to x264 and mux aac to mkv or mp4"

that would be a Very good thing for my/most peoples generic needs if you can also have that in the next update :) please.

if input audio is Not already aac at given direct264 cli line input for instance '--aac 192' ,then Encode as per line, if no --aac line given then encode to a generic aac=128/or 192, else just demux and remux existing aac, anything else other than audio/video found there just demux and leave there for other 3rd party actions later if required by user.

or put a cli command switch to turn that off unless you also want to go down the --preset route for all other internal potential handling or perhaps exterally loading in several text file 'presets' for non video handling much as FFmpeg uses now for x264 video only OC.

i still need to find a good filter of some sort for processing the above B&W video clip to try and improve it as much as possible too, then find a simple away to put that in the processing chain once i find or someone advises me of a good setting etc...

IgorC

10th September 2009, 05:55

As many people don't visit audio and news subforums I didn't find more appropriate place than this to inform about new Apple HE-AAC encoder. http://forum.doom9.org/showthread.php?t=149447

roozhou

11th September 2009, 15:32

@popper
Plz download new r1251 build. The non-mod32 bug has been fixed.

popper

12th September 2009, 03:51

thanks roozhou

i ran your direct264-r1251 as
x264 Doctor-Who.aac-6-minute-clip.mkv -o dw1.mp4 and
x264 Doctor-Who.aac-6-minute-clip.mkv -o dw1.avi
it now works, and No crash, with these non mod16 DrWho clips
and r1251 is producing a slightly smaller output file than older versions too, so thats good ;)
99,506,568 bytes V 99,514,878 bytes.

are your internal Directx264 AAC Encoding/muxing .mp4 plans off the table in the near future for now BTW!

jethro

19th September 2009, 19:38

jmartinr

19th September 2009, 22:35

Is it possible to add resizing of video input in direct264? That with be great for automated batch scripts. So one batch file could encode audio & video of many similar files completely bypassing Avisynth and the need to edit each avs script manually...
ffdshow can do what you want. It has lots of ways to automate things. Especially if you set "raw video" to "all supported".

jethro

20th September 2009, 16:45

Yes, I know about resizing in ffdshow but this also affects normal playing, no? So one setting for playing and other for encoding, still manual change in-between. And batch files can be pre-made for more than one encoding device/profile. I think built-in resizing would be very useful to have for people using direct264, something alike mencoder's 1024:-10 would be awesome.

jmartinr

20th September 2009, 18:15

jethro

20th September 2009, 18:52

Thanks. Profiles will do what I want. Also a neat feature I found just now is that one can export particular settings to a .reg file, which works basically as profiles.

roozhou

20th September 2009, 19:55

You can use "regedit /s xxx.reg" in batch files to import xxx.reg to registry.

jethro

20th September 2009, 21:05

yes i was planning to do exactly that :)

roozhou

17th October 2009, 05:57

Updated to 2009-10-17
CTAACEncoder now supports downmixing 5.1 and 4 channel sources

easyfab

17th October 2009, 08:08

Thanks for the update.

I don't understand how to use CTAACEncoder / dshow2wav.exe so please could you give me a command line exemple or .bat exemple with CTAACEncoder / dshow2wav.exe for the conversion .avi or .mpg to .aac.

roozhou

17th October 2009, 15:11

CTAACEncoder -d -mt -b 64000 -o xxx.aac xxx.avi
dshow2wav xxx.mpg | neroaacenc -q 0.5 -ignorelength -if - of xxx.mp4

easyfab

17th October 2009, 15:51

CTAACEncoder -d -mt -b 64000 -o xxx.aac xxx.avi
dshow2wav xxx.mpg | neroaacenc -q 0.5 -ignorelength -if - -of xxx.mp4

thanks :) I'll get It . Works with dshow2wav and CTAACEncoder

Before your help I try something like that
dshow2wav xxx.mpg | CTAACEncoder -d -mt -b 64000 -o xxx.aac :rolleyes:

johnsonlam

18th October 2009, 16:53

VFW is obsolete and doesnt support mpeg4 and other modern codecs features (implementing them requires hacks and workarounds), while directshow (even if its a bit controversial...) supports them.

Yeah ... I know VFW is obsolete, but the "big application" VirtualDub not really works with DShow, and I'm not the command line geeks that can works with scripts without pain, so AVISynth make me clumsy, and still no one did "hack" the VDub plugin that make it works with DShow.

I can understand why people switch to Mac, I did 5 mins learn to use iMovie, but I love the VDub filter and really enjoy using VDub.

JohannesL

19th October 2009, 13:11

Yeah ... I know VFW is obsolete, but the "big application" VirtualDub not really works with DShow, and I'm not the command line geeks that can works with scripts without pain, so AVISynth make me clumsy, and still no one did "hack" the VDub plugin that make it works with DShow.

I can understand why people switch to Mac, I did 5 mins learn to use iMovie, but I love the VDub filter and really enjoy using VDub.
1) Not really relevant
2) VDub really isn't that awesome*. Try Avidemux.

*it has its uses though
edit: Avidemux > MeGUI

roozhou

19th October 2009, 15:15

@JohannesL
VDub supports frame copy while MeGUI does not. VDub can capture from webcam while MeGUI cannot. Without avisynth MeGUI can do nothing.

And plz do not hijack this thread.

johnsonlam

20th October 2009, 17:28

1) Not really relevant
2) VDub really isn't that awesome*. Try Avidemux.

*it has its uses though
edit: Avidemux > MeGUI

Glad to know MeGUI, since MeGUI don't have a homepage, need to dig out information from another thread.

But please don't start flaming, every software have it's own use, otherwise it can't stand the test of time.

seemees

22nd October 2009, 13:45

roozhou
Do this project use latest state of original 78 core of http://www.videolan.org/developers/x264.html?
With best regards, seemees

LoRd_MuldeR

22nd October 2009, 13:51

According to the changelog, it currently uses x264 r1292, which equates core 77.

roozhou

27th October 2009, 05:51

New build available

seemees

27th October 2009, 23:07

roozhou
A very very BIG thanks to you!!! This is a great tool (for me now). Can you make a 64-bit version of your pakage? It's need for Windows 7 64-bit encoding. To check speed of coding and cetra.
It it possible to compile in 64-bit environment? And make dump.ax too. And I download last version of your tools. But need to rename file dump.dll to dump.ax. Isn't it? Afrer that your great tool start works without error (Can't open file...).
With best regards, seemees

roozhou

28th October 2009, 02:42

My bad, fixed.

Since 7zip choose algorithm according to file extensions, I always rename dump.ax, decssfilter.ax and vtsreader.ax to *.dll. This will increase compression. Unfortunately I forgot to rename them back after making the package.

Please either rename the three files to *.ax or download the new package.

seemees

28th October 2009, 05:05

roozhou
You are cool, bro!!!
Thanks again (and all your work is very strong and very important). Do you plan to make a 64-bit tools? You solve problem with sttdin pipe, what now is using in
the 64-bits Windows 7. K-lite codec pack has 64-bit ffdshow decoders and haali media splitter 64-bit. All we want - your fantastic tool. To direct encode H264 from
any MKV file.
With best regards, seemees

roozhou

23rd November 2009, 15:28

Updated x264 to 1342
Since x264 devels have fixed stdin problem, the ".y4m" hack(y4m input from stdin) has been removed.

CruNcher

24th November 2009, 12:42

thx roozhou :)

mastrboy

29th November 2009, 23:16

will there be a 64bit version of this? (I have not read all the 13 pages in this thread, so might have been asked before)

I'm currently experimenting with avisynth and x264 32bit vs avs2yuv x264 64bit with by encodes, so if Direct264 would come in 64bit and would love compare it to the other alternatives...

roozhou

30th November 2009, 13:11

roozhou

17th December 2009, 16:53

Updated x264 to 1376
Also some new features

roozhou

25th December 2009, 14:55

Merry Xmas!!

New build available, several bugs fixed.

euthon

6th January 2010, 10:23

I'm a total noob when it comes to video encoding, so this project caught my attention because it does not require Avisynth.

I downloaded the package, ran the x264, but that was all I got:
dshow [error]: failed to render VTS.VOB
error code = 4
x264 [error]: could not open input file 'VTS.VOB'

The file opens just fine with the Windows Media Player...
I'm running Windows 7 64-bit (came pre-installed).

Could you help me to sort the problem out?

Thanks,
Andy

roozhou

6th January 2010, 13:07

Direct264 is a 32-bit program and you must have 32-bit dshow demuxers and decoders installed. Win7's WMP uses WMF decoders. Please take a look at this (http://forum.doom9.org/showthread.php?t=146910).

LoRd_MuldeR

6th January 2010, 13:17

roozhou

6th January 2010, 13:23

For VOB files I'd recommend Avisyth-Input with DGIndex/DGDecode (http://neuron2.net/dgmpgdec/dgmpgdec.html) instead of the DirectShow route. I know you want to avoid Avisynth, but it really isn't that hard!

You may also want to give Avidemux (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux) a try: No need for Avisynth, x264 built-in, no external decoders/splitters needed ;)

My purpose of making direct264 is to allow people encoding from various sources using the same command line in one pass, just like how they watch videos. DG tools requires additional index/demux pass so they are totally different.

CruNcher

6th January 2010, 15:33

and it works perfectly :) roozhou do you still work on the GUI in combination with filtering :) ?

roozhou

6th January 2010, 16:06

and it works perfectly :) roozhou do you still work on the GUI in combination with filtering :) ?

Someone has already created a GUI for me. It supports batch processing and filtering via ffdshow (by modifying registry). Unfortunately it is written in Lazarus and only has Simplified Chinese version. I will soon try to port it to Delphi and translate it to English.

CruNcher

6th January 2010, 17:12

Great got it gonna try it :)
for those who think language is no problem
http://u.115.com/file/f4630e1549

roozhou

29th January 2010, 08:38

Updated to x264 r1400

This is a huge update. Plz read the following notes:

1) ffms input is not included. dshow is the default demuxer. If you need lavf input, add --demuxer lavf
2) nal-hrd patch is excluded. It will be added back when it becomes official.
3) New features including starttime, endtime, subtitle, deldup and ivtc are not available in lavf input. However bitrate recompute in 2nd pass will work with lavf.
4) MP4 output will always use dts compression(no initial delay). It will automatically scale timebase if timebase_num is too small.

A new ffmpeg is available.

roozhou

8th February 2010, 07:31

Updated to x264 r1416

Snarko

8th February 2010, 15:11

Many, many thanks. I find that direct264 makes for even better handling of VFR and mixed telecine/interlaced than a 2 pass animeivtc does, especially in re: to fully interlaced segments such as credits.

Is there any chance of getting a version of direct264 with the VAQ4 mod added in?

roozhou

25th February 2010, 11:52

New build available

@Snarko
Sorry I no longer add any experimental mod/patch to my build.

Snarko

25th February 2010, 14:00

Thanks much for the new release. In this case, VAQ4 was committed to git as the new --aq-mode 2 around 2 days ago already, so I'm all set there. Thanks again.

roozhou

4th March 2010, 06:14

Updated to 1471
Now you don't need to register vtsreader.ax when encoding from DVD .ifo files.

roozhou

9th April 2010, 04:58

Updated to x264 1523 and ffmpeg 22822

b66pak

9th April 2010, 18:58

thanks a lot...
_

L.E. i can't find the new ffmpeg...
_

L.E.2 the newest of SF is ffmpeg_svn_r22636...can you (re)post r22822?
_

roozhou

12th April 2010, 03:12

Sorry, my HDD died on last Friday evening. I need a few days to recover everything.

roozhou

28th April 2010, 09:05

Updated to x264 1564

b66pak

28th April 2010, 17:24

thanks a lot...
_

roozhou

2nd July 2010, 08:09

x264 1659 build available

b66pak

2nd July 2010, 18:51

thanks a lot...
_

roozhou

7th December 2010, 15:18

x264 1794 build available.
Now you can use internal ivtc + crop + resize without the help of ffdshow.

b66pak

7th December 2010, 19:44

thanks a lot...
_

L.E. bug report:

my line:
x264 --vf resize:width=720,height=480,sar=10:11,fittobox=both
--profile main --level 3 --weightp 0 --ref 3 --b-pyramid 0 --no-weightb
--vbv-maxrate 10000 --vbv-bufsize 10000 -o test.mp4 test.mkv

the log:
dshow [info]: duration 00:00:04
dshow [info]: 960x720p 0:0 @ 24/1 fps (vfr)
resize [info]: resizing to 7422x7422
x264 [info]: using SAR=10/11
x264 [warning]: frame MB size (464x464) > level limit (1620)
x264 [warning]: DPB size (3 frames, 248020992 bytes) > level limit (0 frames, 3110400 bytes)
x264 [warning]: MB rate (5167104) > level limit (40500)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow Slow_mod4_stack SlowCTZ
x264 [info]: profile Main, level 3.0
swScaler: Compile-time maximum width is 5120 change VOF/VOFW and recompile
resize [error]: swscale init failed
_

roozhou

8th December 2010, 13:04

@b66pak

I think it's fixed in 1808

Author: Anton Mitrofanov <BugMaster@narod.ru> 2010-11-28 07:54:39
Committer: Jason Garrett-Glaser <darkshikari@gmail.com> 2010-12-06 06:58:35
Parent: fba116fc1245b940ef4e95da5527ea5bea8ed031 (Fix regression in rev1549)
Child: 71cf5fd3fb62752b84de39fd14284da9900afca5 (Fix incompatible csp format issue)
Branches: remotes/origin/master, remotes/origin/stable
Follows:
Precedes:

Really fix fittobox resize rounding code

b66pak

8th December 2010, 21:30

this was for small rounding errors like reported here (http://forum.doom9.org/showthread.php?p=1458989#post1458989) and here (http://forum.doom9.org/showthread.php?p=1460453#post1460453)...

this looks like broken:

dshow [info]: 960x720p 0:0 @ 24/1 fps (vfr)
resize [info]: resizing to 7422x7422
x264 [info]: using SAR=10/11
_

roozhou

9th December 2010, 16:07

@b66pak
This problem is also caused by round_dbl function, which is removed in r1808. MSVC's internal trunc function always gives me wired result here.

b66pak

10th December 2010, 01:31

r1820 is ok...can't you use it?
_

roozhou

27th December 2010, 13:29

x264 1834 is available.
Since NV12 support is added to dshow input interface, you can use Win7's built-in decoders with x264.

amfilica

28th December 2010, 03:01

popgo had shut down but it's still cool to see you here best chirstmas present !! nice job zhou

roozhou

22nd January 2011, 18:14

x264 1876 is released.
You can now use --dscrop to crop black bars before rendering subtitle via --sub.

b66pak

22nd January 2011, 20:43

thanks a lot...
_

roozhou

25th March 2011, 07:02

x264 1924 is available.
Since I cannot access my account on sf, new build is uploaded to mediafire.

b66pak

25th March 2011, 13:47

thanks a lot...
_

roozhou

17th May 2011, 06:14

x264 1995 available.

ckmox

17th May 2011, 09:26

Combine aac encoder to x264 and mux aac to mkv or mp4

nice plan, good luck with this while we wait patiently

and about your sourceforge account have you contacted them already?

roozhou

17th May 2011, 10:53

nice plan, good luck with this while we wait patiently

and about your sourceforge account have you contacted them already?
No. Actually I have no idea whom to contact. I am now using another developer's account to upload source code.

ckmox

18th May 2011, 01:00

the normal support may do it too IRC and Email -> http://sourceforge.net/apps/trac/sourceforge/wiki/Support

b66pak

18th May 2011, 19:49

@roozhou thanks a lot...
_

CruNcher

19th May 2011, 10:09

@roozhou
Do you have any idear how to find the bootleneck

http://forum.doom9.org/showthread.php?p=1502105#post1502105

i connected to the chain it's always very simple but lav splitter and cyberlinks demuxer 2.0 cause severe performance issue (Sandy Bridge here i5 -2400) the cores doesn't get either fully utilized anymore or it fluctuates :(
The output is identical only the time it takes isn't because of the inefficient core usage triggered by using either of both demuxer with Mainconcepts Decoder.

roozhou

20th May 2011, 02:43

CruNcher,
Have you tried other decoders than MainConcept?

CruNcher

20th May 2011, 16:26

Yep i looked a little deeper into it as well looks strange :(
and its definitely not your fault either :)
http://forum.doom9.org/showthread.php?p=1502471#post1502471
http://forum.doom9.org/showthread.php?p=1502479#post1502479

ckmox

5th June 2011, 13:27

@roozhou

can i request for a static build of direct264? i mean all those dll's and executable will be compiled/build on just one big executable file?

roozhou

8th June 2011, 02:09

@roozhou
can i request for a static build of direct264? i mean all those dll's and executable will be compiled/build on just one big executable file?

I encountered link problem when statically linking x264 to VSfilter and dump. And since they can be used by other module, probably i will only try to remove FLTPhase.dll in the future.

CruNcher

8th June 2011, 05:41

roozhou

8th June 2011, 07:48

roozhou do you use any different patch from the current trunk your build oversizes compared to other pure builds ? (jarod,masternobody), and for the heavy oversize arround 6 mb per encode the metric difference isn't much also the speed wouldn't justify it, could this be the mod4 slow stack ?.
The default -I is fps*10 instead of 250. This should have significant impact on frame type decision.

And I did notice small difference between libx264 built by MSVC and GCC before. Actually it's in analyse.c or encoder.c because if I compile analyse.c and encoder.c with GCC and everything else with MSVC, the encoding result would be identical to official GCC build. Since it does not affect frame type and the difference in final bitrate is very small, I am still using MSVC to compile libx264. Slow mod4 stack disables a few SSE2/SSSE3 functions, so it only affects encoding speed, which should be less than 1% AFAIK.

CruNcher

18th June 2011, 07:06

Hi roozhou i tested your dshow build again vs dshowsource and it seems in my test case dshowsource lost the last frame ( i guess no one really realizes that)
Your dshow implementation does it right :)

encoded 4672 frames (xvidvideo.ru build with directshowsource, any build via avisynth dshowsource)
encoded 4673 frames (roozhou x264 dshow implementation)

:)

though again the big problem is the file size difference that's really a bad thing (same settings, --crf 19)

normal x264 build avisynth dshowsource (--keyint 24)

x264 [info]: frame I:233 Avg QP:18.29 size:263186
x264 [info]: frame P:1196 Avg QP:21.23 size:157041
x264 [info]: frame B:3243 Avg QP:22.15 size: 93004

encoded 4672 frames, 23.03 fps, 23576.92 kb/s Filesize = 525 MB

roozhou x264 build (--keyint 24)

x264 [info]: frame I:233 Avg QP:18.28 size:263552
x264 [info]: frame P:1196 Avg QP:21.24 size:165123
x264 [info]: frame B:3244 Avg QP:22.17 size: 97450

encoded 4673 frames, 21.14 fps, 24610.44 kb/s Filesize = 548 MB

x264 roozhou build via avisynth dshowsource

x264 [info]: frame I:233 Avg QP:18.29 size:263007
x264 [info]: frame P:1196 Avg QP:21.24 size:164956
x264 [info]: frame B:3243 Avg QP:22.18 size: 97376

encoded 4672 frames, 21.15 fps, 24587.20 kb/s Filesize = 547 MB

really a big final size difference (bit waste) with no visual gain (+22 MB for your build in the final result, could you post a MSVC compiled build and a GCC compiled build of the latest x264 build 2008 with dshow ? )

I hope we finaly see this by default in x264 sometime and being decidable between dshow as default input and libav as backup and vice versa option.

roozhou

20th June 2011, 02:45

CruNcher,

You can download GCC builds by upyzl here: http://u.115.com/folder/f08b3bb7f21

CruNcher

20th June 2011, 03:20

thx roozhou yes his build doesn't show this difference it behaves like a normal non dshow build :)

x264 [info]: frame I:233 Avg QP:18.28 size:263671
x264 [info]: frame P:1196 Avg QP:21.23 size:157172
x264 [info]: frame B:3244 Avg QP:22.16 size: 92815

encoded 4673 frames, 22.52 fps, 23561.13 kb/s Filesize = 525 MB
x264 [info]: ended at Mon Jun 20 04:16:35 2011
x264 [info]: encoding duration 0:03:27

obviously their is also a speed and SSIM difference between the MSVC and GCC build result

MSVC: encoded 4673 frames, 20.88 fps, 24610.20 kb/s = SSIM Mean Y:0.9769205 (16.368db) = Filesize 548 MB
GCC: encoded 4673 frames, 22.52 fps, 23561.13 kb/s = SSIM Mean Y:0.9768332 (16.351db) = Filesize 525 MB

so as you said it seems to change something in the RC

upyzl

21st June 2011, 13:35

@ CruNcher

Well, as I'm hard to access many international netdisks such as mediafire now, I find Google Code is a good place:devil:

Builds and Diff download:
http://code.google.com/p/direct264umod/downloads/list

Brief Introduction:
http://code.google.com/p/direct264umod/

Also I'll update it after direct264 updated

b66pak

21st June 2011, 18:12

@upyzl thanks a lot...
_

upyzl

22nd June 2011, 00:57

@ b66pak

notice that I cancelled lavf demuxer, so If want to use it, you should shift to roozhou's direct264 or x264 with lavf builds:p

b66pak

22nd June 2011, 20:17

@upyzl your mod contains three x264 versions (x264_coreix, x264_generic, x264_K10)...excuse my ignorance but what are the differences between them?
_

oops...i did not see this:

* x264_generic.exe : For most PC (fprofiled)
* x264_coreix.exe : For Intel Core i3/i5/i7 CPU (Maybe Optimization)
* x264_k10.exe : For AMD K10/K10.5 architecture CPU/APU (Optimization)
_

CruNcher

24th June 2011, 22:31

yep also i would say coreix is indeed faster on my sandy bridge :)

upyzl

25th June 2011, 09:38

yep also i would say coreix is indeed faster on my sandy bridge :)

Good feedback:) In fact it's also faster on i5 650 (though just ~1%)
But because core2's gcc compiled direct264 ver is slower than generic's on Core 2, so I don't know gcc's optimization for Intel cpu...

Adjusted introduction

CruNcher

25th June 2011, 13:39

Could you also do a build with win32threads ?

upyzl

25th June 2011, 16:50

Could you also do a build with win32threads ?

All of them are win32thread;)
See build info

upyzl

6th September 2011, 05:00

well... many updates on Google Code (http://code.google.com/p/direct264umod/)

Added 10bit-depth build, but it seems there's still problem with 8->10 conversion in input/rawinput.c (though just limitRange)

upyzl

13th October 2011, 15:32

New builds(mod) available on Google Code.

b66pak

19th October 2011, 20:18

@upyzl your mod build forces always "--vbv-maxrate auto" and "--vbv-bufsize auto" when "--level val" is used...is there a way to overcome this? (may be a fixed build?)
_

P.S. using "--vbv-maxrate 0 --vbv-bufsize 0 " don't work...
_

06_taro

20th October 2011, 00:18

removing "automatically level" patch will solve this problem.

upyzl

20th October 2011, 05:00

b66pak

20th October 2011, 17:25

thanks a lot...its OK now...
_

upyzl

11th November 2011, 12:56

New builds available (mod ver).

Maybe a change should be tellable:
Except x264.exe, other 3 exe only support 4:2:0 output (for "a slight speed increase and significant binary size reduction when only one chroma format is needed" & 4:2:0 is much more widely used)

tre31

18th January 2012, 04:20

Hi has anyone looked at the potential of using an approach similar to Directshow->x264 encode, but using openvideo http://developer.amd.com/sdks/AMDAPPSDK/assets/OpenVideo_Decode_API.PDF API.

I know that OpenVideo is AMD specific, however further research leads me to find that OpenMAX AL/IL/DL will provide hardware accelerated decoding which could then be fed straight into x264 rather than using Directshow - which is only as good as the weakest link, and by that I mean it cannot get hardware acceleration as the whole process cannot use DXVA.

So .. just thought I through this potential method out there and see what the developer and others think about this process.

I have already seen this - and tested it as well, its pretty quick (but I'd prefer a similar method using x264 for end result); http://bluesky23.yu-nagi.com/en/index.html#AsVideoConv

roozhou

18th January 2012, 17:31

CruNcher

18th January 2012, 17:37

Nice roozhou so you finished i guess the major difference compared to Nevs (DXVA2) or Egurs (IMSDK,DXVA2) yours will be the only one also working for pre NT 6 Vista/7/8 DXVA1 systems :)

tre31

18th January 2012, 23:18

I have been working on hacking ffdshow to allow DXVA during video encoding for about one year. See this thread (http://forum.doom9.org/showthread.php?t=160371). Compared to developing on a new and AMD-only architecture, DXVA is much easier for me.

I am about to integrate this into Direct264, so be patient.

Good to hear, although I don't know about the completeness of the OpenMAX solutions, however they are on the opencl site - so I am kind of assuming that it is across Nvidia and AMD (and amd's solution is OpenVideo - in terms of direct architecture, nvidia is different not entirely sure how they do it, though the developer of DGIndex - neutron2 would know I am sure).

Anyway I go have a read through that thread and see how its progressing, and I will say that Direct264 is the only encoding solution I use and have done so for quite awhile, nothing like drag drop onto a batch file encode .. so simple :D

medmunds

19th September 2012, 02:32

Is there an x64 version of Direct264? How do I go about installing Direct264 (either the x86 or x64 version) so that it shows up in the filter list of GraphEdit? Will it be a Default filter there (black), or is it a DirectX Media Object (DMO) (green) or a filter that Uses Compression Manager (ACM/ICM) (blue)? Thanks!

upyzl

23rd September 2012, 06:20

Is there an x64 version of Direct264?
Because some direct264 assembler source code is not compatible with x64, it isn't.

How do I go about installing Direct264 (either the x86 or x64 version) so that it shows up in the filter list of GraphEdit? Will it be a Default filter there (black), or is it a DirectX Media Object (DMO) (green) or a filter that Uses Compression Manager (ACM/ICM) (blue)? Thanks!
I prefer you to use GraphStudioNext (http://code.google.com/p/graph-studio-next/)(of course use 32bit) and use Win7DSFilterTweaker or CodecTweakTool to disable MS filters(Because it is easy to cause problems with direct264...).

medmunds

25th September 2012, 19:37

Because some direct264 assembler source code is not compatible with x64, it isn't.

I prefer you to use GraphStudioNext (http://code.google.com/p/graph-studio-next/)(of course use 32bit) and use Win7DSFilterTweaker or CodecTweakTool to disable MS filters(Because it is easy to cause problems with direct264...).

Do I just copy the Direct264 files into C:\Windows\SysWOW64 and then use GraphStudioNext to register them, or what? Sorry if I'm missing something, I've just never had to manually install a DirectShow filter before now.

upyzl

26th September 2012, 02:21

Do I just copy the Direct264 files into C:\Windows\SysWOW64 and then use GraphStudioNext to register them, or what? Sorry if I'm missing something, I've just never had to manually install a DirectShow filter before now.

You could put Direct264 (folder) anywhere, Direct264 will call DirectShow Filters automaticly when you do encode
DirectShow filters should be registered (e.g. LAV Filters/FFDShow/Haali/AV Splitter...), except the VSFilter.dll(recommends add onto player's external filters)

GraphStudioNext is just for whether the video decoding is normal or not (drag the video into GraphStudioNext, normally recommends FFDShow-tryout or LAV Video), and checking whether the DShow filters it really uses comform to what you want to use

In brief, if you could play the to be video normal by 32bit MPC-HC(or other 32bit DirectShow players) without(turn off) the player's relative filters, that's enough;)