Alleged x265 crash

[Sivar]

Have others had frequent, serious problems with x265?
Using the most recent Staxrip with x265 1.7, 1.8, and 1.8 nightlies I've found:

1) Use of --frame-threads 1 nearly always crashes x265 after a few percent of the file, the last log entry: av_interleaved_write_frame(): Broken pipe. I tried manually installing the most recent Avisynth with no change. Attached is a log from a failed encode of a 2-minute clip from "Captain America".

2) Sometimes x265 will unceremoniously die without error, warning, or log entry. Attached is a log from such a situation (sans error).


The problems may be related to StaxRip, but Stax76's software always seems so amazingly robust and well-designed, and once the encode is going I am not sure how it could cause such a failure mode. Perhaps AVISynth or other software may be involved, too.

As a side note, why would Doom9 of all forums not allow users to directly upload log files? Zipping them is not a big deal, but it seems strange.

[LoRd_MuldeR]

If you think you found a reproducible crash in x265, the first thing to do is: Eliminate Avisynth!

There are way too many things that can go wrong on the Avisynth side. So, to be 100% sure this really is a x265 issue, run x265 directly from command-line and encode directly from an existing Y4M file. Or, maybe, pipe input from FFmpeg.

If the problem then still occurs, please post your exact x265 version and the exact x265 command-line to reproduce the crash - alongside with the shortest possible a sample that can be used to reproduce the crash.


As a side note, why would Doom9 of all forums not allow users to directly upload log files? Zipping them is not a big deal, but it seems strange.

Have you tried uploading your files with a .txt extension? If it still doesn't work, you probably ran into the size limit.

[Ma]

1) Use of --frame-threads 1 nearly always crashes x265 after a few percent of the file, the last log entry: av_interleaved_write_frame(): Broken pipe. I tried manually installing the most recent Avisynth with no change. Attached is a log from a failed encode of a 2-minute clip from "Captain America".

It could be ffmpeg bug. You can download current 64-bit static ffmpeg build from site
http://ffmpeg.zeranoe.com/builds/
and replace ffmpeg.exe in your "C:\StaxRip\Apps\ffmpeg\" folder.

[benwaggoner]

It could be ffmpeg bug. You can download current 64-bit static ffmpeg build from site
http://ffmpeg.zeranoe.com/builds/
and replace ffmpeg.exe in your "C:\StaxRip\Apps\ffmpeg\" folder.
I was having the exact same problem a month or so ago. I thought it was x265, but that is a ffmpeg error message, and the problems went away when I switched to a more recent ffmpeg build.

[Sivar]

Thank you for your advice. While cycle times are long, I will try to remember to report for other readers if use of the most recent FFmpeg yields consistent success.

[x265_Project]

Thank you for your advice. While cycle times are long, I will try to remember to report for other readers if use of the most recent FFmpeg yields consistent success.

You're not the first to conclude that x265 must be at fault when it's used with some application or media processing library that you know and trust. But x265 is constantly being improved, and our APIs change every now and then. If the application calling x265 doesn't update the parameters they are passing x265, you will run into problems. If x265 encoding fails in an application, a good first step towards figuring out which component is the culprit is to try the same encode in x265 directly (through the x265 command line interface). This isn't always easy, as you may have to decode and process your source video in a separate step, saving a large YUV or Y4M file, but it will usually provide the answer.

Now can we change the title of this thread?!

Tom

[shae]

Why doesn't x265 accept compressed formats as input?

[sneaker_ger]

http://forum.doom9.org/showpost.php?p=1710739&postcount=1771

[shae]

For the library itself it definitely makes sense, but it's also a commandline program. Making use of an external decoder lib/program would make it more usable, like x264.

[foxyshadis]

It's not necessary; that would be equivalent to:

ffmpeg -i file.mkv -f y4m - | x265 - --y4m ....

which can be encapsulated in a batch file if you must. (Might need -strict -1 for 10-bit and up.) x264 only included it because someone else contributed it.

[shinchiro]

^you missing some args :)
These is what basically work to pipe y4m to x265..
ffmpeg -i input.mkv -f yuv4mpegpipe -pix_fmt yuv420p - | x265 --y4m --preset medium --output output.mkv -

[Sivar]

Admittedly, I haven't tried a single-thread encode again because they take a bit of time to complete. Aside from a small probability that single-thread encodes are unrelated to the other problems I ran into, it appears so far that my x265 issues were a combination of:
1. An old version of ffmpeg
2. Two bad source videos. The sources had graphical corruption in one spot roughly midway through the video.

I've never experienced either until my first look into x265, and I've transcoded a lot of media and have spend hundreds of hours researching, programming for, and tweaking my transcoding hobby. I thought that gave me the right to commit the cardinal sin of assuming that correlation implied causation. My apologies to the x265 team.

[kuchikirukia]

For the library itself it definitely makes sense, but it's also a commandline program. Making use of an external decoder lib/program would make it more usable, like x264.

It's adding a bunch of work to add something that is merely a copy of other projects. It's like asking why they don't include an OS with the project so you can boot into x265, too. Windows exists. Why reinvent the wheel?

No decoder has achieved perfection, so adding a decoder is adding another project that will surely need some work. It's better to leave the decoder work to the decoder projects so x265 can concentrate wholly on encoding.

[MeteorRain]

Why doesn't x265 accept compressed formats as input?

It can. We have patches for that.

[shae]

Thanks.