Resume a title conversion - Even feasible?

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Post Reply
ITgreybeard
Experienced
Posts: 89
Joined: Tue Feb 11, 2014 3:47 pm

Resume a title conversion - Even feasible?

Post by ITgreybeard »

Description of problem or question:
On an all-too-frequent occasion, my Handbrake-ing computer experiences a shutdown, either unexpected or, perversely, found necessary by me. In particular it seems that MS updates of late can cause the computer to be less stable even if more secure. Regardless of that, once in awhile software or hardware changes require work cessation, even if Handbrake is 5 hrs through an estimated 7 hr single-title conversion. It would be "lovely" if Handbrake could be modded to duplicate as little work effort as possible by "checkpointing" work during a title conversion, so that a resumption of work can start at the last-checkpoint position within the title that was unfinished at shutdown. Inasmuchas Handbrake knows what was in queue at last processing, it would seem that a natural checkpoint file exists already. But is such a request even feasible? Does it depend on the type of output file to be produced? This can hardly be the first time the subject has arisen, so In any case, thanks for the consideration.

Steps to reproduce the problem (If Applicable):
Not applicable

HandBrake version (e.g., 1.0.0):
1.2.2

Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):
MS Windows 10-64 Pro, Version 1903, OS build 18362.388

HandBrake Activity Log ***required*** (see How-to get an activity log)

Code: Select all

Not applicable
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Resume a title conversion - Even feasible?

Post by mduell »

Feature requests go on github, although I think this is likely to be rejected.

The queue contains almost none of the information you'd need in a checkpoint. Literally thousands of bytes vs billions of bytes.
Woodstock
Veteran User
Posts: 4614
Joined: Tue Aug 27, 2013 6:39 am

Re: Resume a title conversion - Even feasible?

Post by Woodstock »

Using the GUI, can PAUSE an encode, and handbrake will save the information to resume, but doing so often enough to deal with random shutdowns is going to seriously delay your encode - There's a lot of information to write. And I do not remember if such a pause can span a program shutdown; I've never used it, personally.

A better solution is to deal with the actual problem, rather than constructing a bandaid to hide its effects. Figure out why the encodes are being interrupted.

First thing I'd do is disable automatic updates. Don't let Windows install updates without asking you first. WinUpdate doesn't care what you're doing on the computer, and Microsoft has no qualms about delivering unstable updates. And plan hardware updates a bit better.

It is possible to run handbrake continuously for long periods of time (last big encode queue I did took over three weeks), without Windows blowing up in the middle.
Deleted User 11865

Re: Resume a title conversion - Even feasible?

Post by Deleted User 11865 »

Nope, the GUI cannot pause across reboots -- once the RAM is cleared, you cannot resume an encode, period.
ITgreybeard
Experienced
Posts: 89
Joined: Tue Feb 11, 2014 3:47 pm

Re: Resume a title conversion - Even feasible?

Post by ITgreybeard »

Thanks for the informative replies! Regards.
ITgreybeard
Experienced
Posts: 89
Joined: Tue Feb 11, 2014 3:47 pm

Re: Resume a title conversion - Even feasible?

Post by ITgreybeard »

Your answers above are accepted in their entirety, but could you, in the pursuit of widened distribution of knowledge (i.e. to me), point me to a treatise that provides an architectural overview of an encoding operation or of an encoded file? I am curious as to what information is carried forward into subsequent frames’ and chapters’ encoding, and if that varies in various parts of the file. The encodes that I happen to be creating at present are h.265/x265 in an .mp4 streaming container, if that is relevant. For instance, is there any provision for error bypass at time of playback, such that a resumption of play could be attained at some streaming/file position subsequent to an error or streaming dropout detected? Or is every frame or frame group innately reliant on the contents of the encoding up to that frame or frame group? (To this greybeard, that appears out of step with the ability during playback to skip ahead or back to other positions and chapters of an encoded file.)
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Resume a title conversion - Even feasible?

Post by mduell »

For encoding, there are a number of raw frames in flight between decode, filtering, and the encoder (lookahead buffer in particular). The bulk of the information here would be covered by the encoder's documentation. With typical settings and HD or 4K frame sizes, that adds up to about a gigabyte.

For playback, you only need the current GOP.
ITgreybeard
Experienced
Posts: 89
Joined: Tue Feb 11, 2014 3:47 pm

Re: Resume a title conversion - Even feasible?

Post by ITgreybeard »

Thank you for that. Belaboring the issue, I understand that, within an .mp4 container, multiple objects can be held. Is there any sequence indicator, and possibly a flag, that would signal that playback is to continue from one to another in the sequence, with the same effect as sequenced chapters?
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Resume a title conversion - Even feasible?

Post by mduell »

Yes, see ISO/IEC 14496-14:2003 for the documentation of the MP4 container.
ITgreybeard
Experienced
Posts: 89
Joined: Tue Feb 11, 2014 3:47 pm

Re: Resume a title conversion - Even feasible?

Post by ITgreybeard »

Marvelous. Thank you for the reference to GOP and this latest.
Post Reply