X265

[Qyot27]

The problem seems to be that something about the Command Prompt is broken. It's not expanding the %1 and %~n1 placeholders correctly (insert obligatory 'this is why I prefer bash' comment). That might also serve to explain why running this stuff plain wasn't working either - if the Prompt is borked, then who knows what's actually wrong.

What brings you to that conclusion? I would assume the user would be complaining about software such as zarxgui not working if that were the case. I have heard that ffmpeg only works well with AviSynth 2.6, but I don't know exactly how that would error out.

If you look at the latest output, it's completely missing the input file name and the output filename is ".265". This is what points to the placeholders not expanding. It probably wouldn't affect Zarx264gui because the file open process is different and in the .bat generation it provides, it hardcodes the filename (it also doesn't pipe anything).

The rundown of what happened with FFmpeg's AviSynth support:
A) FFmpeg 1.2: still uses the old VFW-based AviSynth demuxer that was written by DivX and first committed back in 2006. Has no problems with either 2.5.8 or 2.6.
B) March 21st, 2013: Rewritten AviSynth demuxer that uses the library directly (like x264 does) gets committed.
C) The git version, and later FFmpeg 2.0, both have an issue with 2.5.8 that results in a crash - no error messages, just crash - when AviSynth has to use avs_get_row_size_p and avs_get_height_p through avs_bit_blt (in other words, any kind of real video; Version() was unaffected, and you could serve audio-only scripts through 2.5.8 without problems)
D) In August, this was patched to prevent 2.5.8 from even being used. The error message explicitly tells the user 2.5.8 isn't supported and that they should upgrade to 2.6. I can't remember, but FFmpeg 2.0.1 should contain this 'fix'.
E) 10 days after that, proper 2.5.8 support was restored*. The rewritten demuxer now has no gamebreaking issues with either 2.5.8 or 2.6. This proper support is present in git (since August 17th), FFmpeg 2.0.2 and FFmpeg 2.1.

*I actually got the commit message slightly wrong in regard to AvxSynth; it wasn't affected because it always ever used its own set of headers. That it happens to use 2.6's versions of those functions was just coincidence.

[l33tmeatwad]

Ah thanks, good to know

[jakkor]

My avs file is elysium.avs. How should to look .bat file?

[Qyot27]

Change the .bat to the following:

Code: Select all

ffmpeg -i "elysium.avs" -f yuv4mpegpipe "elysium.y4m"
pause
x265 --crf 18 --preset ultrafast -o "elysium.265" "elysium.y4m"
pause

If the script is serving something longer than a typical AMV, I'd suggest using Trim() to cut it down to 3 or minutes at the most. This is just for testing, because if you can run the commands independently, it'll show exactly where the problem is.

[jakkor]

error
video
[code]http://www.filefactory.com/file/v ... mp4[/code]

[jakkor]

It works when I added
ffmpeg -i "paranoia.avs" -an -pix_fmt yuv420p -f yuv4mpegpipe "paranoia.y4m"
pause
x265 --crf 25 --preset fast -o "paranoia.265" "paranoia.y4m"
pause

but I don't know what this. I found this here
http://forum.videohelp.com/threads/3577 ... ngw-builds

[Qyot27]

It's because the rext stuff hasn't been fully fleshed out in the HEVC standard (or x265) yet, so you have to convert it to YV12. It'd also have worked if you added ConvertToYV12() to the end of the script.

[jakkor]

File y4m is very large about 100gb so have to have big free spece disk.

ffmpeg -i "red.avs" -an -pix_fmt yuv420p -f yuv4mpegpipe "red.y4m"

x265 --crf 25 --preset faster -o "red.265" "red.y4m"
ConvertToYV12()
is it good now?


How to join file x265 with audio aac?

[jakkor]

Of course in avisynth convertoyuv.

[Qyot27]

If you have ConvertToYV12() in the AviSynth script, there's no need to use -pix_fmt yuv420p when using ffmpeg. The fact that y4m is uncompressed is why I said that if it's longer than an AMV, use Trim() to run the test.

As it stands, muxing it together with audio is only possible with mp4box right now. L-SMASH's support for it is experimental and has been disabled until the extension to the 14496-15 3rd edition is ratified, and the work on getting it into Matroska is hinged upon both that ratification and the work DivX is doing on the patches to mkvtoolnix. That's why I said this is where the real problem is.