Is the ffmpeg command line from --dry-run the actual internal command used to produce the compression?

[muesic]

I just wanted to confirm something I think is true, but I'm not 100% sure. If I run a given other-transcode command line to yield a final product, would I get the identical result if I added --dry-run to the original command line and then ran ffmpeg with those arguments?

[lisamelton]

@muesic The --dry-run option will indeed give you the exact command that other-transcode uses for ffmpeg. However, for the case of output in MKV format, a post-processing step with mkvpropedit is run after that to add track statistics information. That step easy to run yourself though.

Does that answer your question?

[muesic]

Thanks. The reason I'm asking is because I believe my final compression will need to be done on a DVD VOB structure and not the MKV mandated by other-transcode. To explain, here is a copy/pasted paragraph from another thread:

Several of my ripped DVDs likely had a couple scratches etc. Those VOB file structures still play just fine in VLC (and there might be some visible glitch where the scratch was) but when converted to MKV using tools like MakeMKV (or MKVToolnix or AVIDemux) they often yield an MKV that has very noticeable audio/video sync issues. When that is subsequently input to a compression tool those AV sync issues carry forward. Using a tool like HandBrake to directly take the VOB structure and compress it to MKV means that wherever those scratches were there might be a small glitch in the output but audio/video sync is maintained. I infer from this that HandBrake isn't first converting to MKV and then compressing, it's doing both simultaneously. That's why I want to operate directly on the VOB files - to avoid the audio sync issue that comes from making this a two step process.

So given that there is NOTHING out there that can robustly convert my VOBs to MKVs without the significant risk of sync issues (for admittedly problematic DVD rips, but they are what I have), I'm going to try to make other-transcode's ffmpeg command line operate on a VOB structure instead of the MKV you're starting with. I'll have to do the (unreliable) VOB->MKV conversion only to get an ffmpeg argument from --dry-run, but I can't risk doing the compression itself on the potentially messed up MKV.

This does kind of raise an interesting follow up question. I have previously taken other-transcode's ffmpeg command line and simply changed the input file to be a vob instead of mkv and (as near as I can tell) it worked just fine. It appears ffmpeg just knows what to do. It there a fundamental reason why other-transcode couldn't accept a VOB structure as an input if ffmpeg can natively accept it?

[lisamelton]

@muesic You're lucky that your VOB file contained your entire video. DVDs are not always organized that way. Also, VOB files can have track organizations that will confuse ffmpeg. So, it doesn't always work. That's one reason that I don't support it.

[muesic]

Yea -the vast majority of them are made up of multiple 1GB VOB files inside a VIDEO_TS folder. HandBrake is able to natively accept a folder full and just know what to do so I was going to rummage around to see if ffmpeg also has this capability. Given how prevalent DVDs have been over the years I'd have to think that hurdle has been crossed a while ago. When other-transcode complains if I give it a single VOB file, is it because you're categorically rejecting non-mkv's or is it because something else breaks?

[lisamelton]

@muesic If I'm rejecting the VOB as input it's because supporting the format is a pain in the ass due to the limitations.

BTW, AFAIK, ffmpeg does not understand the VIDEO_TS folder format. It can, however, handle individual files within that format, as you've discovered.