VideoHelp Forum
+ Reply to Thread
Results 1 to 14 of 14
Thread
  1. I would think that such an option would be possible. It would be like a save state in an emulator, a memory dump.
    I would love it if handbrake would do this as it is my favorite x.264 encoder.
    Quote Quote  
  2. Do you mean a pause, and then resume? If so, Handbrake already does this.
    Quote Quote  
  3. Well I mean save progress to a file then it is ok to exit the program and when you start back up the encode will pick up where it left off.
    Quote Quote  
  4. Easier said than done
    Esp since things could get corrupted if the temp folders are wiped/changed during a paused operation.
    It is better to let the program clean up after a certain job..
    Last edited by teodz1984; 11th Dec 2017 at 09:14.
    Quote Quote  
  5. Originally Posted by BirdDaddie View Post
    I would think that such an option would be possible. It would be like a save state in an emulator, a memory dump.
    I would love it if handbrake would do this as it is my favorite x.264 encoder.
    It's not possible for the same reason that you can't just suspend a zip archive in mid operation. Think about what you are saying and you will hopefully realize how silly it is.
    Quote Quote  
  6. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    It could be possible for video. Unlike zip file, there is a fundamental atomicity to video: frames (if intraframe codec/setting) or independent GOPs (if interframe).

    Would have to cut existing job at last known good/completed frame (or independent GOP), and have a job log file that took note of that point. Then resume could append from that point on. Not easy, but there are already $$ encoding solutions that have this capability.

    Scott
    Quote Quote  
  7. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    Originally Posted by sophisticles View Post
    Originally Posted by BirdDaddie View Post
    I would think that such an option would be possible. It would be like a save state in an emulator, a memory dump.
    I would love it if handbrake would do this as it is my favorite x.264 encoder.
    It's not possible for the same reason that you can't just suspend a zip archive in mid operation. Think about what you are saying and you will hopefully realize how silly it is.
    7zip lets you suspend operation forever, by just using the "Pause" button. CPU usage goes to zero until unpaused. I don't use Winzip or Winrar so can't comment on those. Obviously pausing 7zip and then closing it will lose everything.

    Sometimes when encoding with x264/x265 the power may go out for a second and shut everything down, or I just need to use the computer for something else so I cancel the encoding. If my encoding was many hours in and I don't care to have to re-encode already encoded material I'll mux the partially encoded video file into MKV with MKVToolNix, and mux it again but split it so that the last 500-1000frames are not included (depending on the GOPs). MKVToolNix is really good at cutting cleanly but you can't cut frame accurate usually which is fine. Then I just figure out how many frames the split video had (how many have already been encoded) then add one to trim for the second encoding. #trim(Video A Frames +1, 0)

    Then just use MKVToolNix to append the two separately encoded videos together. Obviously you need to use the same encoder and same settings for the appending to go well. I use Megui for x264/x265 encoding, which just uses the external x264/5 .exe. I'm not sure if my method would be possible with Handbrake.
    Quote Quote  
  8. Originally Posted by Cornucopia View Post
    It could be possible for video. Unlike zip file, there is a fundamental atomicity to video: frames (if intraframe codec/setting) or independent GOPs (if interframe).

    Would have to cut existing job at last known good/completed frame (or independent GOP), and have a job log file that took note of that point. Then resume could append from that point on. Not easy, but there are already $$ encoding solutions that have this capability.

    Scott
    I take it you are not aware that the final step in the encoding process with H264 is entropy coding, which is very similar to the compression done during a zip archive.
    Quote Quote  
  9. I reallize that I could do it in a vm but what a perfomance hit that would b.
    Quote Quote  
  10. should I be tell it to do chapter 1-2
    2-3
    3-4
    and mux the segments together?
    I would think that it would make file sizes larger then if it was a true encode with all the chapters
    Quote Quote  
  11. MKV can append files, it might be doable and perhaps it works well. If not, after those years, that function would be removed, just make sure you encode always with the same parameters, and not sure if --stitchable would help in x264 command line. Not sure if that is meant for MP4box or even for mkvmerge.

    Actually this is my thinking, nowadays, why a videofile has to be one long thing, technology is here, it could be encoded by chapters. Going into this territory myself, not because of movies, but home videos, videographer's point of view. Encoding shorter clips for one event rather than one long video. So you do not need to encode it as a whole. Or just leaving them in separate clips as they come from our recording devices.

    Downsides :
    1. Some Hardware players (TV's etc.) tend to stop after one clip, have no playlist functions or settings to play files continuously
    2. Even if support playlists or accept more files at a time there are gaps between clips.

    For PC (windows and linux), I found mpv player that has virtually gapless playback. God send, I like that player, you just drop bunch of clips from a directory and watch clips virtually with gapless playback.

    You can also embed metadata, just jpg, for example using MP3tag, into those clips (if it is movie or your edited version of video) where browsers show that jpg in the clip. If having MP4 container, did not try MKV. So it is super-duper menu, Real menu as it can be. But again, only in PC, not hardware players. Because those players do not bother with a basic stuff like granting metadata embeded in MP4 file. Meaning software writers do not bother to implement it. It is not realized that if they did, you get menus on screen for any device playing video not only in text form but with images , that represent that clip. Not software generated, but showing jpg from metadata sector if there is.

    So you sort it out for your needs. Perhaps most likely, you need to join those files, if deciding encode chapters or clips, but anyway, bringing this issue up here.
    Quote Quote  
  12. Member Bernix's Avatar
    Join Date
    Apr 2016
    Location
    Europe
    Search Comp PM
    Hi _Al_
    potplayer has same function but disabled default. To enable it go to preference(F5) then playback - advanced tab And here choose one of 2 methods. Default it is disabled (recommended)
    Image
    [Attachment 43988 - Click to enlarge]


    Bernix
    Quote Quote  
  13. thanks for the tip!
    Quote Quote  
  14. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Originally Posted by sophisticles View Post
    Originally Posted by Cornucopia View Post
    It could be possible for video. Unlike zip file, there is a fundamental atomicity to video: frames (if intraframe codec/setting) or independent GOPs (if interframe).

    Would have to cut existing job at last known good/completed frame (or independent GOP), and have a job log file that took note of that point. Then resume could append from that point on. Not easy, but there are already $$ encoding solutions that have this capability.

    Scott
    I take it you are not aware that the final step in the encoding process with H264 is entropy coding, which is very similar to the compression done during a zip archive.
    Entropy coding, whether CABAC or CAVLC, works on block or macro-block segments, NOT on the whole file. Not even on whole GOPs. So it wouldn't affect my aforementioned suggested process, with the possible minor exception of probability binning becoming less than optimized at the cutoff, leading to a slight decrease in compression efficiency (depending on where the probabilities get refreshed).
    I take it that you are not aware that your presumption makes you seem a bit asinine.

    Scott
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!