Support forum for DG Tools

Would it be possible to have DGIndexNV warn if the container framerate differs from the video track framerate? I've sometimes come across Matroska files where this happens, and eac3to shows a little warning message. I guess the video framerate is the one to trust so it would also be good to allow using that in the DGI file. This deviation probably also affects the chapters2qp functionality.

Boulder wrote: ↑

Sun Apr 17, 2022 4:12 am

Would it be possible to have DGIndexNV warn if the container framerate differs from the video track framerate?

It is much easier to use MediaInfo than to introduce complexity. JM2C

Guest 2 wrote: ↑

Sun Apr 17, 2022 5:34 am

Boulder wrote: ↑

Sun Apr 17, 2022 4:12 am

Would it be possible to have DGIndexNV warn if the container framerate differs from the video track framerate?

It is much easier to use MediaInfo than to introduce complexity. JM2C

I can use an external tool like MediaInfo or eac3to, but since I don't use them for other purposes, it's an extra step. Besides, there is the need to fix the DGI file manually regardless.

Boulder wrote: ↑

Sun Apr 17, 2022 4:12 am

Would it be possible to have DGIndexNV warn if the container framerate differs from the video track framerate? I've sometimes come across Matroska files where this happens, and eac3to shows a little warning message. I guess the video framerate is the one to trust so it would also be good to allow using that in the DGI file. This deviation probably also affects the chapters2qp functionality.

We can have a popup on open that notifies the mismatch and allows to select which frame rate to use. Then of course someone will ask for an option to disable the popup.

Bullwinkle wrote: ↑

Sun Apr 17, 2022 8:50 am

Boulder wrote: ↑

Sun Apr 17, 2022 4:12 am

Would it be possible to have DGIndexNV warn if the container framerate differs from the video track framerate? I've sometimes come across Matroska files where this happens, and eac3to shows a little warning message. I guess the video framerate is the one to trust so it would also be good to allow using that in the DGI file. This deviation probably also affects the chapters2qp functionality.

We can have a popup on open that notifies the mismatch and allows to select which frame rate to use. Then of course someone will ask for an option to disable the popup.

I was thinking along the lines of the d2v file correction DGIndex had. A popup and a question to fix the index file. By default, fix applied (also for CLI).

Please test this and advise if it does what you need. It checks for a mismatch on open. There is a new controlling option in settings that lets you choose what to do when a mismatch is detected:

Prompt
Use ES FPS
Use Container FPS

Please open DGIndexNV and then close it once before testing to get the INI file updated.

https://rationalqm.us/misc/DGIndexNV_test.zip

Rocky wrote: ↑

Fri May 06, 2022 12:17 pm

Please test this and advise if it does what you need. It checks for a mismatch on open. There is a new controlling option in settings that lets you choose what to do when a mismatch is detected:

Prompt
Use ES FPS
Use Container FPS

Please open DGIndexNV and then close it once before testing to get the INI file updated.

https://rationalqm.us/misc/DGIndexNV_test.zip

Thank you for the test version. It will take a longer time to get to test it as my house is under a bigger renovation job and I'm living in a temporary flat for the next three weeks or so. All the computer stuff had to be left behind Nevertheless, the proposed method sounds good to me

Ooh, computer withdrawal. I feel for you. Good luck with the renovation.

One question: should I suppress the popup on CLI operation, and if so, use the container or ES frame rate?

Rocky wrote: ↑

Sun May 08, 2022 7:37 am

Ooh, computer withdrawal. I feel for you. Good luck with the renovation.

One question: should I suppress the popup on CLI operation, and if so, use the container or ES frame rate?

Hehe, must be the longest time without a (personal) computer since my C64 broke down some time in the late 80s. "Fortunately" I work in IT, so it's still pretty much a 8/5 thing all week anyway.

I vote for suppressing the popup and using the ES frame rate. I'd say that works correctly in 99,5% of the cases.

OK then, so be it.

"since my C64 broke down"

You made me choke on my acorn!

Released in build 243.

This wiki page from mkvtoolnix appears to suggest that there isn't such a thing as container FPS for MKV: https://gitlab.com/mbunkus/mkvtoolnix/- ... -displayed. Should video stream FPS always be used at least for MKV even in GUI? i.e. yes, I'm asking to disable the popup but this is more based of the MKV spec than user preference.

Welcome to the forum, cnzqy2.

Be careful, you'll upset the frog, and the frog is lethal.

I would estimate that 90+% or even 95+% of MKV streams are fixed frame rate. And it's easy to allow for field-based streams when calculating frame rate. Nobody bothers because they are so rare.

For me, it's insane to have a container format that cannot signal FPS. Lot's of processing goes on that does not involve a player, and for such processing knowing the frame rate is often important. People demand it! That's why they use the default duration to signal and calculate it (e.g., MediaInfo, eac3to, and many other important applications). It will be this way, and we're going to support people's actual usage.

Rocky, thanks a lot for the explanation! I'm trying to understand this issue better so pardon me for asking a question for a specific file:

This is a sample MKV with a progressive video stream encoded as field-based (i.e. "1080i25" AVC Blu-ray for standard compliance): https://send.cm/d/Bref. Using mkvinfo I can see that: "Default duration: 00:00:00.020000000 (50.000 frames/fields per second for a video track)", and since it's encoded as interlaced, it should indicate 25 FPS as expected. However, DGDecNV, MediaInfo, and eac3to all think the MKV container tells them that the FPS is 50. Any clues for why this might be the case?

MediaInfo:

If the world was ideal, then the apps could say, hey, it's interlaced so divide the calculated frame rate by 2. But as with many aspects of MKV their purist mentality leaves us in a pickle. While there is an MKV header field called FlagInterlaced, it is more often than not simply left unset and so it defaults to false. You have to jump through hoops to get it set correctly. You can use the mkvtoolnix header editor to set it. But the reality is that it is more often than not unreliable.

OK, you may be thinking, use an interlaced flag from the ES. Could be done but when trying to report a container frame rate, it seems silly to have to query ES data for an app like DGIndexNV. Again, ideally, all the MKV multiplexers (mkvtoolnix, MakeMKV, etc.) could read the ES flag and then set it at container level during muxing. But they don't!

Always open to suggestions.

That's fair. Querying the ES is probably the best solution in this case I think, but indeed it's kind of a conundrum if we want a separation between the container info and the ES info.

I'll look into doing that but no promises.

Alternatively I suppose is to file bug reports and ask mkvtoolnix, MakeMKV, etc. to properly set the FlagInterlaced flag.