I have created two custom settings, one for x264, the other for x265. They have same settings for audio. Video codec settings are two pass, other settings are almost default. x264 bitrate is 3000 Kb/s, x265 bitrate is 1710 Kb/s.
I have a DVB-T record, natively in x264. x264 custom setting does a good encoding but x265 fails at the 2nd pass with an error message saying "Cannot setup codec. Bitrate too low ?".
Any idea of what's happening ?
Admlog.log zipped in attachment.
I can see in the log that the temp folder used (d:\dvdrip in my case) is incomplete : instead of d:\dvdrip\temp files, I can read d:\dvdriptemp files. Is there a way to correct this ?
v2.6.15 ?
Sorry.
Yes, version 2.6.15.
Ok, just to tell what's happening. Encoding with x265 is working with only 1/3 of the recordings. A x265 failure always succeed with x264.
In one particuliar case, I got 3 recordings, same DVB-T recording with 3 different sources : they all fail with x265. A kind of malediction ?
Once again, if it's failing with x265, it's always succeeding with x264. The audio codec and audio parameters are the same.
Maybe it's related to hardware acceleration.
I will try to completly disable it, just to see the result.
Any idea anyone ?
What are the log saying ?
They are in %APPDATA%/avidemux/admLog.txt
I attached one with the first post of this thread. If it's not enough, just ask for another, I will send it (I don't have another here just now).
Thank you.
The interesting part is
[setPassAndLogFile] 08:25:12-864 Initializing pass 2, log file =d:\dvdrip\Mont-Saint-Michel, àl'épreuve du temps [h265].mkv.stats
Path=d:\dvdrip
Name=Mont-Saint-Michel, àl'épreuve du temps [h265].mkv.stats
Dirty path=d:\dvdripMont-Saint-Michel, \E0 l'\E9preuve du temps [h265].mkv.stats
clean path=d:\dvdripMont-Saint-Michel, \E0 l'\E9preuve du temps [h265].mkv.stats
[setPassAndLogFile] 08:25:12-867 Creating system file =<d:\dvdripMont-Saint-Michel, \E0 l'\E9preuve du temps [h265].mkv.stats>
[setup] 08:25:12-868 =============x265, setting up==============
[setup] 08:25:12-868 Starting pass :2
[setup] 08:25:12-868 Using average bitrate of 1710 kb/s
[setup] 08:25:12-869 Logfile d:\dvdripMont-Saint-Michel, \E0 l'\E9preuve du temps [h265].mkv.stats does not exist
where the separator after the directory name gets lost.
Keep names and paths brief and simple. Foreign ascii, deep paths, ... can pose issues across the different OS's.
This problem doesn't seem to be curable on the user's part because no simple file name can provide a missing separator after the directory name. Probably related to https://github.com/mean00/avidemux2/commit/e58bcf01aa0ace354fb6d7b05689a68e9a749615 (https://github.com/mean00/avidemux2/commit/e58bcf01aa0ace354fb6d7b05689a68e9a749615) or https://github.com/mean00/avidemux2/commit/b4ef66a0c26978d7c423feb85ac4653269ea7311 (https://github.com/mean00/avidemux2/commit/b4ef66a0c26978d7c423feb85ac4653269ea7311).
Original file name:
Quoted:\dvdrip\Mont-Saint-Michel, àl'épreuve du temps
Call from one program (segment) to another (terminal environment (dos?))
Quoted:\dvdripMont-Saint-Michel, \E0 l'\E9preuve du temps
Sorry I can't explain more technical. See bolded difference between the 2 (àé) foreign ascii.
The critical part is a missing "\" after d:\dvdrip, not the escapes later.
OK.
Not some control character (backspace or combination (home) with backspace) that did sneak in the filename?
I suspect that the issue as well as the different behaviour of x264 results from missing
ADD_DEFINITIONS(-DX265_USE_UTF8=1)
in avidemux_plugins/ADM_videoEncoder/x265/CMakeLists.txt similar to the analogue file in avidemux_plugins/ADM_videoEncoder/x264. Cross build is running to verify.
It will take some time. x265 is ridiculously slow on my PC on Windows, taking 5 minutes to complete the first pass for a 720p video 7 seconds long!
I think i had to patch x265 to add utF8 support
the latest version is not patched
Not completely sure
Now I've verified that adding
ADD_DEFINITIONS(-DX265_USE_UTF8=1)
to avidemux_plugins/ADM_videoEncoder/x265/CMakeLists.txt:4 fixes the issue when encoding in HEVC and saving video to a file whose filename contains characters like à. This might have got omitted at some point.
Is all this ANSI stuff still needed with Windows 7 and later? My NTFS partitions get wonderfully mounted in UTF-8 mode.
Would you please add it so it makes it into the next official nightly? It don't have time to go the usual way with pull requests etc. today, my apologies.
Will this correct the missing "\" in folder name too ?
I didn't suspect the diacritic characters. It seems obvious to me, as I'm French !
I will try it on a file that fails. I will tell you !
Thanks
Maybe you've found the clue !
All the recording that succeed had no diacritic characters.
All the recording that failed had diacritic characters !
UTF8 ! That's it !
Quote from: eumagga0x2a on November 30, 2016, 03:50:48 PM
Would you please add it so it makes it into the next official nightly? It don't have time to go the usual way with pull requests etc. today, my apologies.
Nevermind, I've opened a pull request, maybe as a stop-gap solution for now. This way utf8StringToAnsi function becomes unused, can it be safely removed together with references in the x264 and x265 code?
I can now confirm that all recordings can be encoded with x265 if I use no diacritic characters in the name of the destination file. Even those that previously failed.
Thank you for the trick.