X264cli feature request thread

[Revgen]

Since I couldn't find one, I guess I'll start it.

Is there a way to pause/resume x264 cli? It would be a handy feature to have during long encodes.

[stax76]

It would be possible to add a pause feature with a context menu and tray icon but console apps usually don't support such things. Some GUIs have pause features, StaxRip pauses every thread in the process, I don't know if this possibly could break things and how other GUIs do it.

[Dark Shikari]

Since I couldn't find one, I guess I'll start it.

Is there a way to pause/resume x264 cli? It would be a handy feature to have during long encodes.Use ProcessExplorer, it lets you pause arbitrary programs.

[mariush]

What's wrong with pausing using the "Pause" button on the keyboard? You can then resume using "space" for example.
If you mean suspending x264, turning off computer, restarting and resuming that's another story...

[Dark Shikari]

What's wrong with pausing using the "Pause" button on the keyboard? You can then resume using "space" for example.
If you mean suspending x264, turning off computer, restarting and resuming that's another story...No, it's not really another story. "Hibernate" works just fine.

[Revgen]

Thanks.

I searched google with "pause/resume programs" and came up with none of the methods you guys gave me.

[chipzoller]

What would be super-nice to have is an auto-resume feature for when those 2-day encodes get rendered useless in the last 5 minutes due to UPS death. I'm not even sure if something like this is even possible to implement.

[aegisofrime]

What would be super-nice to have is an auto-resume feature for when those 2-day encodes get rendered useless in the last 5 minutes due to UPS death. I'm not even sure if something like this is even possible to implement.

Personally when that happens, I try to find how many frames were rendered in the first pass that failed due to crash/whatever, adjust the AVS script to render the remaining frames, then append them together using mkvtoolnix. It works, actually. As far as I can tell.

[stax76]

What's wrong with pausing using the "Pause" button on the keyboard? You can then resume using "space" for example.

It works, never knew this.

[LoRd_MuldeR]

...StaxRip pauses every thread in the process, I don't know if this possibly could break things and how other GUIs do it.

There is no other way. In contrast to POSIX, the Win32 API doesn't offer a function to suspend/resume a process :rolleyes:

All we can do is enumerating all threads of a given process and then suspend/resume each thread of the process individually.

That's how it's implemented in my simple x264 launcher (http://forum.doom9.org/showthread.php?t=144140) too ;)

And this method doesn't break anything. If it did, that would indicate a deadlock or race-condition in the application...

[EDIT]

Actually there's another method:

If a GUI, which redirects the STDOUT, stops fetching the data from the pipe, the pipe buffer will run full, sooner or later.

Consequently the 'console' program will block when trying to write some output to STDOUT.

It will remain blocked (suspended) until the GUI starts fetching data from the pipe again. It's not a very nice method, though.

[Revgen]

Well good news and bad news.

Bad news is that if I pause/resume my encode, it appears to produce buffer underflow errors when muxing in Scenarist. Not doing so seems to avoid the underflow errors. X264 didn't report any errors though.

Good news is that it works fine if I'm just muxing to MKV, MP4, or anything else.

[LoRd_MuldeR]

Bad news is that if I pause/resume my encode, it appears to produce buffer underflow errors when muxing in Scenarist. Not doing so seems to avoid the underflow errors. X264 didn't report any errors though.

If that issue could be replicated, it would indicate a race condition :eek:

[shon3i]

Well that can maybe solove this mistery aslo http://forum.doom9.org/showthread.php?p=1380824#post1380824 we already try to catch what in x264 strem that produce TS underflows, i am now wait for verbose output from mp3dom to scan with vbv.pl.

[kieranrk]

Well that can maybe solove this mistery aslo http://forum.doom9.org/showthread.php?p=1380824#post1380824 we already try to catch what in x264 strem that produce TS underflows, i am now wait for verbose output from mp3dom to scan with vbv.pl.

How many times do I have to say that it's a problem with the muxer not schedulling packets into the transport buffer correctly?

[shon3i]

How can you explain why "other" encoders can't reproduce same thing? On same movie, and how all available muxers produce same thing only with x264 stream, only some muxer will continue muxing (tsmuxer) and other not (scenarist, bluprint) , even Revgen found possible additional way to reproduce this on easy way.

[laserfan]

What would be super-nice to have is an auto-resume feature for when those 2-day encodes get rendered useless in the last 5 minutes due to UPS death. I'm not even sure if something like this is even possible to implement.You need a UPS with a communications utility. It can safely shut-down (or in your case go to Hibernate) and your process should be saved.

Dunno tho about "auto-resume". I suppose if your PC is on a wake-timer that could work too.

[chipzoller]

The point is disasters happen and can ruin an encode in the last few minutes rendering the entire output useless. Having x264 detect where it last left off and resume the encoding process would be an extremely useful feature.

[Revgen]

How can you explain why "other" encoders can't reproduce same thing? On same movie, and how all available muxers produce same thing only with x264 stream, only some muxer will continue muxing (tsmuxer) and other not (scenarist, bluprint) , even Revgen found possible additional way to reproduce this on easy way.

I only reencoded the movie again without pausing/resuming just to see if it would mux. It just happened to do so with the 2nd encode.

Does that mean the pausing/resuming caused it? I'm not sure. It appears that way, but until somebody has the time to replicate it and really nail it down to x264 itself, it's hard to know. I don't have the time to do that.