cretindesalpes
25th September 2013, 14:40
Background
Now we have the --stitchable option in x264, it becomes much easier to encode a video in multiple segments. There are multiple uses for this: mix different settings that cannot be set in --zones, redo only specific parts where global parameters or bitrate are unsatisfactory, make simultaneous encode to take a better advantage of a large number of cores, etc. Cutting (at GOP boundaries) and joining segments together can be achieved without much effort with ordinary muxing tools.
The problem is that x264 is not very handy when you need to encode just a part of a file. --seek and --frames could help but their behaviour with --qpfile, --zones and --tcfile-in is inconsistent. Plus, --seek often requires reading the source from the beginning. I looked for tools to overcome these problems but found nothing. Maybe I haven’t searched hard enough? Anyway, I finally came with my own (and modest) solution.
What is it?
trimx264opt is a Windows command line tool. It takes qpfile, zones and timecodes information and “shifts” a specified frame range to index 0. Therefore x264 can use directly these parameters to encode the source cut to this range, without the need of --seek or --frames. This can be done with Avisynth frameserving for example, with a Trim(beg, beg-end) after source loading.
As trimx264opt itself does only the basic things and is not very convenient, I added encode-part.bat which provides a template for encoding a segment (it requires to set some environment variables to locate trimx264opt, x264 and possibly avs2pipemod). Ideally we would need some kind of wrapper over x264 but at the moment this tool does the job and really helps.
Download
r3: >>>> trimx264opt-r3.zip <<<< (https://ldesoras.fr/src/trimx264opt-r3.zip)
Note: I’m pretty sure this kind of segmented encoding can break the VBV constraints on segment boundaries, and I’m not sure if there is a solution and how to make it work. If anybody knows something, shoot!
Now we have the --stitchable option in x264, it becomes much easier to encode a video in multiple segments. There are multiple uses for this: mix different settings that cannot be set in --zones, redo only specific parts where global parameters or bitrate are unsatisfactory, make simultaneous encode to take a better advantage of a large number of cores, etc. Cutting (at GOP boundaries) and joining segments together can be achieved without much effort with ordinary muxing tools.
The problem is that x264 is not very handy when you need to encode just a part of a file. --seek and --frames could help but their behaviour with --qpfile, --zones and --tcfile-in is inconsistent. Plus, --seek often requires reading the source from the beginning. I looked for tools to overcome these problems but found nothing. Maybe I haven’t searched hard enough? Anyway, I finally came with my own (and modest) solution.
What is it?
trimx264opt is a Windows command line tool. It takes qpfile, zones and timecodes information and “shifts” a specified frame range to index 0. Therefore x264 can use directly these parameters to encode the source cut to this range, without the need of --seek or --frames. This can be done with Avisynth frameserving for example, with a Trim(beg, beg-end) after source loading.
As trimx264opt itself does only the basic things and is not very convenient, I added encode-part.bat which provides a template for encoding a segment (it requires to set some environment variables to locate trimx264opt, x264 and possibly avs2pipemod). Ideally we would need some kind of wrapper over x264 but at the moment this tool does the job and really helps.
Download
r3: >>>> trimx264opt-r3.zip <<<< (https://ldesoras.fr/src/trimx264opt-r3.zip)
Note: I’m pretty sure this kind of segmented encoding can break the VBV constraints on segment boundaries, and I’m not sure if there is a solution and how to make it work. If anybody knows something, shoot!