Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Announcements and Chat > General Discussion
Register FAQ Calendar Today's Posts Search

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th August 2018, 15:56   #1  |  Link
thecoreyburton
Guest
 
Posts: n/a
VFR MKV timecodes / estimated rate

I currently have a series of batches set up to detect how many files are in an input folder, process them separately and then eventually merge the resulting clips into a single file. The collection source files can have different frame rates rates and all undergo duplicate frame removal via ExactDedup in AVISynth, so the resulting clips are VFR.

My current processing consists of encoding the audio of each segment to numbered .wav files, and then merging these into a single output file via sox. This file eventually gets transcoded to a variety of formats with varying delays (and therefore varying compensation for delays) and so it's much better to have it as a single item.

After this, I create the timecodes and dupinfo in a first pass for each segment and then encode each segment with x264 (and timecode input). I currently use mkvmerge to merge each segment with it's appropriate timecodes, and then once all segments have been encoded this way, I use mkvmerge to append the video tracks together and add the audio.

The process itself produces files which play back as intended on my machine, but I've noticed a discrepancy in the output file. In this example, I have only two segments of footage and that the share the same frame rate. The first is only two seconds long and features a still image; it's heavily dedupped because of this. In MPC-HC, the output clip is listed as being 1.002fps. The second features a lot of motion and is much less dedupped. In MPC-HC, the output clip is listed as being 60.1fps. When I mux them together, I get a clip that states it is 1.002fps (the first clip's rate). In contrast, if I extract the timecodes of this clip and reapply them to the video track, I get 58.242fps, which is what I'd get if I processed the two segments as a single file and is what I expected. I think this is related to the time base calculation, but my knowledge here is minimal. I did note down the following values, however:

The clip's FPS before deduplication: 1008307711/16777215
The timebase for the first clip: 986895/988537
The timebase for the second clip: 1/1000000000

The process needs to be more or less automatic and clips of different rates are common, so processing them as a single clip isn't a viable solution. Every output is guaranteed to have a single audio track and a minimum of two video segments (along with a corresponding set of timecodes v2 for each segment). I have a few questions regarding my options, as whilst I'm familiar with vfr, multi-segment vfr is relatively new to me.

1 - Does the rate MPC-HC is stating matter? In all cases MediaInfo reports the same frame rate (~47.5) and the files all play back on my machine in the same way. They're going to be released for digital distribution however, and so I need to know if this will affect legacy devices or machines at all.

2 - What's the best way to treat this value:

A - If I know the most common frame rate throughout the clip, is there a way I can change this value manually to inform users of the mode? If so, are there any ill consequences of doing so?

B - Is it best to set this value to the "optimal" value as calculated by MKVMerge if it were to be muxed all at once? If so, what's the best way to do this automatically in my circumstances? Should I extract the timecodes and remux them, or is there a way to predict the value beforehand and set it manually (keeping in mind the clips could be of different starting frame rates)?

C - As an alternative suggestion for B, is there a command line way to append timecodes together? If perhaps instead of applying the timecodes to each clip and then later appending those clips together, I could instead apply a single timecodes file to the clips as they're appended. It would both save time and give the correct calculation during muxing in this case.

I'm sorry for the length of my question, for any incorrect assumptions I've made in my statements and for if I've put this in the wrong forum. As is evident from the rest of this post, I'm more than a bit lost. Any help would be greatly appreciated.
  Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.