Wrong frame rate reported in Windows Explorer

WGF_Bean

Member
I've recently upgraded from version 5 to 6.

In Windows Explorer you can add a column for "Frame Rate". When I save a MKV file from VRD version 6, Windows Explorer shows "1000" as the frame rate for the file, which is incorrect. The file plays correctly and if I use another tool like "MediaInfo" this same file shows as "59.940 (60000/1001)" which is correct.

Do I have something configured wrong in VRD version 6? My current version is "6.60.4.806 - Oct 10 2019". I've tried this for many files and all of them report "1000". Note that I only output as MKV.

In the meantime I'm continuing to use Version 5 since I need it to correctly show the frame rate in Windows Explorer.
 

Dan203

Senior Developer
Staff member
It's probably a windows problem. It's probably not reading the right tag for the framerate in MKV files. MKV uses millisecond time codes, which means that the time codes are in 1/1000th of a second, so that might be where it's getting the 1000, but as you've seen other tools read it correctly so Windows is doing something wrong.
 

WGF_Bean

Member
But VRD version 5 works fine. Only version 6 has this issue so I think something isn't being written correctly to the header. Please check it out. I doubt this is a Windows issue.
 

WGF_Bean

Member
I loaded the files written by VRD 5, and VRD 6 into MKVToolNix GUI. Using the Info tool tab, please look here:

Segment -> Tracks -> Track -> Default duration.

For the VRD 5 MKV file it reports: 00:00:00.016683350 (59.940 frames/fields per second for a video track)
For the VRD 6 MKV file it reports: 00:00:00.001000000 (1000.000 frames/fields per second for a video track)

So VRD version 6 is indeed writing incorrect information into the headers.

Edit:
Also note the value reported for VRD 5 is slightly off. The correct value should be 00:00:00.016683333. This is because the frame rate for N/ATSC broadcast (which was the source for this video, i.e. WTV) is not 59.940 but rather 60/1.001 which is slightly different: N/ATSC broadcast: 1000000000ns/(60/1.001) = 16683333ns
 
Last edited:

WGF_Bean

Member
Hello Dan,

Have you had a chance to look into this issue? I realize you are very busy but there was no response to my last post. Did you read it?
 

Otter

Member
I can duplicate the issue - wouldn't call it a problem.

I do wonder how WGF_Bean is even seeing the Explorer "Framerate" listing for a MKV file. Native Windows 10 Explorer doesn't know how to show that. Explorer can read other types like MP4 and TS, but not MKV. I have to install something like Icaros Shell Extension to populate info like Frame Height, Frame Width and Framerate in the Explorer columns.
If Icaros is turned off, those columns show for other files types, but blank for MKV files.

If I browse MKV files in Windows 10 v1903 Explorer/Icaros enabled window, the framerate for files created with VRD v6 DO show "1000.00 frames/second"
Seems to be full encodes only - fast recodes seem to read correct fps. Other files created with other products or ones created with VRD5 show the correct fps in Explorer

Reading VRD6 encoded files with latest MediaInfo v19.09 or the older version baked into last build of MPC-HC will show correct fps - ie something like "29.970 (30000/1001) FPS" or "25.00 FPS"

MKVToolNix info for the VRD6 encoded file will be "(1000.000 frames/fields per second for a video track)"
Reading a non-VRD6 files will be correct "(25.000 frames/fields per second for a video track)"

MKVToolNix Timestamp Scale reads "1000000" with both good and erroneous files, so not part of the problem.

Whatever is being read header of the VRD6 files, it is fooling both Explorer with Icaros Shell and MKVToolNix, but not MediaInfo which seems to be reading some other MKV header area.
 

cp2

Member
I have an interest in this because there is a slight possiblility that it could explain why my LG tv will play files created in V5 buy not V6. One can hope, I suppose.
 

Otter

Member
Played around with a file showing "1000.000 fps" - used MKVToolNix to edit the header.
"Video Track 1" listing for "default duration" had been set by VRD v6 to "1000000"
Changed it to "33370000" and saved with new info in header, and it now showed "29.97" in Explorer
Of course this would be different for any other FPS like 25 or 30

Seems like VRD is writting the wrong number in that info field.
 

WGF_Bean

Member
I do wonder how WGF_Bean is even seeing the Explorer "Framerate" listing for a MKV file.
In Windows File Explorer choose view by "Details". Next right click the column header area and select "More...". Scroll down to "Frame rate" and enable it. You will now have a column in Detail view which has the frame rate.

Whatever is being read header of the VRD6 files, it is fooling both Explorer with Icaros Shell and MKVToolNix, but not MediaInfo which seems to be reading some other MKV header area.
This is because there's redundant information in the MKV files. The Frame Rate I'm referring to is in a summary area before the video data. There is another entry for frame rate embedded in the video stream. Most players ignore the summary value and only use the video stream itself.

Some programs that report the frame rate use the summary value while others use the video stream data, hence the discrepancy you see. MediaInfo looks at the video stream, while Windows Explorer and some other programs look at the summary. Either way the files created by VRD6 are erroneously writing a time of 1000000ns in the summary which translates to 1000 frames per second. VRD5 did not have this issue.

Changed it to "33370000" and saved with new info in header, and it now showed "29.97" in Explorer
Yes! :) However technically the correct value is 33366667. Why? Because it's 1000000000/(30/1.001)), not 1000000000/29.97.
30/1.001 = 29.97002997002997..... repeating. not 29.97. The origin of 30/1.001 comes from years ago when American broadcast TV added color. Using exactly 30 didn't work because it would end up with a color burst frequency interfering with the audio subcarrier. The exact rate they decided on was 30/1.001. For 25 Hz TV broadcast they got lucky and didn't have this problem and so there was no need for something like 25/1.001.

I have an interest in this because there is a slight possiblility that it could explain why my LG tv will play files created in V5 buy not V6. One can hope, I suppose.
Yes, there's a chance this is the culprit. If I had an LG tv I could test it for you, but unfortunately I don't.

I have the utmost confidence the VideoRedo Team will eventually recognize and fix this.
 

Otter

Member
You will now have a column in Detail view which has the frame rate.
Yes....I do know that, but while native Windows 10 Explorer will show the column and many video file types will show info in the column, MKVs will show blank in the Framerate, Frame Width and Frame Height column.
If I install an addon like Icaros, the MKV info for Framerate and the others also show up. Remove Icaros, and those columns no longer show values for MKV - only other file types like MP4.

However technically the correct value is 33366667.
Again...yes. In my research to find the problem that you had no answer for, I only did quick math in my head to test.
Didn't bother with all the other possible framerate adjustments either.
I'll leave it to you to carry the math out to the precision you seem to want and post.
But then, I don't see this is a real problem. Having the wrong value in display in a file list doesn't effect any playback I've tried, so seems to be a cosmetic defect.

I have an interest in this because there is a slight possibility that it could explain why my LG tv will play files created in V5 buy not V6.
cp2: Download freeware MKVToolNix and try the Header Editor on one of the VRD6 files that display "1000 fps". Field is in the Video Track 1 section.
Honestly, I've tried 6 different software players under Win7 & Win10 and none had an issue with the "1000" files. Only have various Toshiba, Samsung and Sony tvs, No LG.
Don't use the "Smart TV" interface on any of them anyway. TV interfaces are too slow, clunky and "dumb" for me. All playback in our house is either via tvs hooked to full-blown Win 10 pcs as 2nd monitors or via small HTPCs running Win10 and the MPC-HC software player driving various big screens.
 

cp2

Member
My fix is to create a TS file in VRD6 and then remux it into an mkv (my preferred format) using MKVToolnix.
After creating an mkv file in VRD6 (and confirming that LG wouldn't play it) as suggested I compared the header information using MKVToolNix and there were disparities in values on both the video and audio tracks.
I did try altering these values to see whether I could get it to play but I have decided to be pragmatic: if I found the values to change it will take longer and be more cumbersome than the fix I already have. Better to wait for the VRD lads to check it out at their end.
Incidentally, just about all of my files are stored on NAS drives and my LG TV will interface with them directly. The wonders of HDMI handshaking means that my PC upscales just about everything (resolution, frame rate) to interface with my 4K TV and it outputs PCM. I really don't want to keep fiddlling with that to suit the source material.
My NAS passes the original resolution and sound codec to the LG TV and it just handles it. It only has a problem with lossless audio: i use a 4K blu-ray player as a media player to sort that out.
 

WGF_Bean

Member
But then, I don't see this is a real problem. Having the wrong value in display in a file list doesn't effect any playback I've tried, so seems to be a cosmetic defect.
In my case it's more than cosmetic because I really use the information in this column. By using detail mode in Windows Explorer I can look at all of the files in a folder and quickly see the frame rate for all of them at once. This saves me the trouble of opening them one at a time. For what I do, this information is useful for me. I also display several other items like video and audio codec, frame width and height, subtitle track info, etc. Having it all display at once for all files saves me a lot of time.

I did try altering these values to see whether I could get it to play but I have decided to be pragmatic: if I found the values to change it will take longer and be more cumbersome than the fix I already have. Better to wait for the VRD lads to check it out at their end.
I completely agree.
 

cp2

Member
Have installed the latest beta, 809, and did a quick test by creating an mkv file in V6. It played fine on my LG tv. However, I will have to carry out further tests just to make sure. Subject to that, it looks like it is now sorted.

Great!
 

cp2

Member
Have installed the latest beta, 809, and did a quick test by creating an mkv file in V6. It played fine on my LG tv. However, I will have to carry out further tests just to make sure. Subject to that, it looks like it is now sorted.

Great!
There's always a but...
I have carried out a further test and yes the mkv will play except the LG OS has a resume function (no option displayed, it just does it). I decided to flip back to the mkv file and the TV tried to resume but the LG equivalent to the blinking cursor just kept spinning and playback didn't resume. The ability to jump to a different point in the video by clicking on the timeline seemed broken too. In fact the ts version I created at the same time seems similarly "broken" in repect of resume and jumping through the timeline. In fairness I did not explicitly look at that on previous betas.
You can break the curse of the resume hang by renaming the file, which presumably breaks the link to a buffer of some type.
Happily enough (?) my fix continues to work - create a ts file in VRD, and convert it to mkv by remuxing it using MKVToolnix. This file resumes and jumps in the timeline without a problem.
I have attached a file of the MediaInfo data of both the VRD mkv output and the remuxed ts file in case they are of use.
So, I'm going to carry on applying my fix for now.
 

Attachments

WGF_Bean

Member
I had fallen back to using VDR5 since VRD6 didn't correctly report frame rate. That was several months ago so I thought I'd see if a VRD6 update has fixed the bug. The good news is it's fixed! I'm not sure which update fixed it but now it is correctly reporting the frame rate.

Thank you VRD Team! :)
 
Top Bottom