Let's start with apologies for the late reply ... 😁 

Maybe I should start with that MovieScanner isn't a pro-tool, and my video knowledge is limited to "good enough" for what I use it for.

As for the aspect ratio, this is calculated based on width and height as provided as the video stream "width" and "height" by ffProbe.
Not to be confused with coded_with and coded_height (right click a scanned video in MovieScanner and select "Copy ffProbe output to clipboard" so you can copy it to a text editor).

So maybe see if we can learn something from that - I'd be more than happy to learn something new and improve my "calculation".

Note that you may see a sample_aspect_ratio and a display_aspect_ratio, like this example:

sample_aspect_ratio=1\:1
display_aspect_ratio=4\:3

However, often enough there is no aspect ratio defined and we will see something like this:

sample_aspect_ratio=N/A
display_aspect_ratio=N/A

So I had to make a function to calculate the aspect ratio and with the best of my abilities I came to the width:height ratio (as it should be).
This will however at times result in very weird numbers. For example: a width of 1268 and a height of 720 would result in a 317:180 ratio - which makes no sense for most users of course. Here the 16:9 ratio makes more sense for the user.

This is why I made a function that brings ratios closer to more normal or common aspect ratio's. Of course this could potentially come with aspect ratio's that a re little "off", although I would hope this is not the case in your situation. I hope that makes sense 😜 

I'm open to suggestions and improvements! 😁 

Just to clarify:

The pixels displayed is the "width" and "height" as provided by ffProbe. 

MovieScanner will try to get a useful aspect ratio, straight from ffProbe, by using display_aspect_ratio.
If that value does not exist, or is set to "N/A", or cannot be found in the list of "usual aspect ratio's", then an aspect ratio is calculated based in "width" and "height" as presented by the ffProbe output.

If you could provide an example video, then I wouldn't mind looking into this. Always room for improvements 😁 

p.s. you will not be able to upload the video in the forum. Too big, and you're not yet allowed to post attachments. You could use WeTransfer, or a share on Google Drive or something like that.

(due to a forum error message Sam wasn't able to post this message - so I'm posting it her manually)

@hans hi - thank you so much for taking the time to reply. I really appreciate that you try to wrestle with these details!

first of all, no apologies needed for it not being 'pro'- I the the interface you have so far is really really great - easy to use and very clear. It provides the key information really well, and gives access to further detail if you need. The ability to stack films* and compare is excellent.

*(although i find the 'delete file' option nerve wracking - seems to bypass the trash on my mac! Would there be a preference to turn this option off? I'm not sure I could leave an intern with it).

Thanks for the tip to see the ffProbe data - there looks to be a lot if useful info, though there will still be times that you have to find work-arounds I guess.
What is the difference between 'wdth / height' and 'coded_width / coded_height'? I can't find any examples where these values differ.
I think your approximations of aspect ratios is probably a good idea, though it may be useful to be able to highlight that which are approximations rather than exact eg, "16:9*" - that helps us spot potential issues to address

I can't see anything explicitly referring to 'PIXEL ASPECT RATIO'. The closest thing might be SAMPLE ASPECT RATIO - for instance, for my dv ntsc it is listed as: sample_aspect_ratio=10\:11 - which is equal to 0.91, so in the right ballpark as the pixel aspect ratio of NTSC footage , 0.889. 

It could be that films with n/a for Sample Aspect Ratio are simply 1:1 square pixels. I've tried opening a couple of standard h264 mp4s with square pixels that I encoded myself in Premiere + Media Encoder, and they state 'n/a' for Sample Aspect Ratio in the ffProbe data

I would still be tempted to argue that ffProbe's 'DISPLAY ASPECT RATIO' is in fact STORAGE ASPECT RATIO. Very much open to others thoughts on this! 

Finally - the '480p' that I'm seeing can be misleading - the 'p' would imply 'progressive' (full) frames, but some of the dv clips I'm testing this on are interlaced. This would relate to the 'field order' variable (field_order=bt), which for ntsc footage is likely to be interlaced, therefore 'upper' or 'lower' - so  '480i' would be more appropriate.

I'll try and sort you video samples next week. In the meantime, here is some of the info from the video I mentioned.

thanks again for your generosity

Sam
 

# ffprobe output

[streams.stream.0]
index=0
codec_name=dvvideo
codec_long_name=DV (Digital Video)
profile=unknown
codec_type=video
codec_tag_string=dvc
codec_tag=0x20637664
width=720
height=480
coded_width=720
coded_height=480
closed_captions=0
has_b_frames=0
sample_aspect_ratio=10\:11
display_aspect_ratio=15\:11
pix_fmt=yuv411p
level=-99
color_range=unknown
color_space=smpte170m
color_transfer=bt709
color_primaries=smpte170m
chroma_location=topleft
field_order=bt
refs=1
id=N/A
r_frame_rate=2997/100
avg_frame_rate=92154753/3075050
time_base=1/2997
start_pts=0
start_time=0.000000
duration_ts=3074800
duration=1025.959293
bit_rate=28769796
max_bit_rate=N/A
bits_per_raw_sample=N/A
nb_frames=30749
nb_read_frames=N/A
nb_read_packets=N/A

[streams.stream.0.disposition]
default=1
dub=0
original=0
comment=0
lyrics=0
karaoke=0
forced=0
hearing_impaired=0
visual_impaired=0
clean_effects=0
attached_pic=0
timed_thumbnails=0

[streams.stream.0.tags]
creation_time=2012-06-26T14\:01\:30.000000Z
language=eng
handler_name=Apple Video Media Handler
vendor_id=appl
encoder=DV/DVCPRO - NTSC

Posted by: @hans

↑

I the the interface you have so far is really really great - easy to use and very clear. It provides the key information really well, and gives access to further detail if you need. The ability to stack films* and compare is excellent.

Awesome! That is good to hear 😁 

Posted by: @hans

↑

*(although i find the 'delete file' option nerve wracking - seems to bypass the trash on my mac! Would there be a preference to turn this option off? I'm not sure I could leave an intern with it).

Did you enable the "use trashcan" option? 

Note: As with most other applications as well, the Trashcan usually only works on disks that support a trashcan on that disk. As far as I know this would only be your internal harddisk. So deleting a file from your NAS will not support the trashcan. To enable trashcan support, all the files that you delete would need to be copied to your local harddisk first for it to be able to get into the trashcan. Some NAS devices, I know this can be enabled on QNAP devices, allow you to enable an automatic trashcan on the NAS.

Disabling the delete function ... let me think about that. Feels like a useful setting indeed. I've taken note of this and will see if I can include this in a next release.

Posted by: @hans

↑

What is the difference between 'width / height' and 'coded_width / coded_height'

From what I understand, some encoders require width and height to be multiples of a certain number. For example multiple of 16 or something like that. The actual width may not meet those requirements, so a codec_width is used to meet those requirements. The padding pixels may be cropped out again when decoding the video. (Source)

Posted by: @hans

↑

I think your approximations of aspect ratios is probably a good idea, though it may be useful to be able to highlight that which are approximations rather than exact eg, "16:9*" - that helps us spot potential issues to address

Not a bad idea, but just looked at the code and this may be more work than I would care for. The current module that handles the approximation has no means (yet) to indicate that it was an approximation. Calculation this afterwards, even though that would be inefficient, would come with problems as well. For example, a ratio may end up with one of those fun situations where we would like to compare 0.333333333333333333 with 0.333. (just an example to indicate that division can come with hard to compare results)

To give you some "fun" ratios where rounding or size limitations will cause problems:

10:9   = 1.111111111111111
4:3    = 1.333333333333333
5:3    = 1.666666666666667
16:9   = 1.777777777777778
16:7   = 2.285714285714286
21:9   = 2.333333333333333

Taking note though - see what I can come up with. 👍 
I think I may have a trick somewhere in the middle, but have to do some digging in my code to see if this becomes an option.

As for pixel aspect ration, you have already found an example where we have to go "in the ballpark" mode 😉 

The "p" versus "i" is indeed a thing I intentionally chose to ignore the proper "i" option. For example, 1080i is not very uncommon as far as I know, and I can see interlaced to be not uncommon with lower resolution recordings (especially older ones). However ... most users do not care about that little detail, and just associate 1080p with a certain resolution instead of progressive or interlace video.

To avoid completely remodeling MovieScanner, I'd need some reliable methods to deal with some of these issue.
Suggestions are welcome of course, but they have to remain implementable. 😊 

Hi Hans, cheers for the responses!

re: deleting

Did you enable the "use trashcan" option? 

yes, but often we are working from a NAS. I was showing a colleague yesterday in fact and I almost clicked the wrong option myself! I would prefer a foolproof way to avoid accidentally deleting a file- ie, hiding it from the menu if need be. Similar to your current options in the menu, I would include 'hide options to delete file / delete directory' to give the user a fail safe. 

re: codec_width

cheers for the reference - I'll try and find out more! 

re: approximation of aspect ratio

 The current module that handles the approximation has no means (yet) to indicate that it was an approximation.

ah indeed - yes, I understand even 'standard' aspect ratios are approximations when they are expressed as 1:X ratios. Ideally I would make a distinction between a film which is 1280 x 720 (exactly 16:9) and a film which is 1268 x 720 (16:9*) with the '*' meaning 'pretty much', but I appreciate that may be tricky to code.

re: p & i frames

most users do not care about that little detail, and just associate 1080p with a certain resolution instead of progressive or interlace video.

I suspect I'm showing my age, but I'm pretty familiar with interlaced workflows. Certainly cameras like the SonyZ90 still offer interlaced resolutions and frame rates (eg 60i). In any case, the 'p' in 1080p is just in reference to the frame type rather than the resolution. '1080' would suffice if you want to keep it simple.

anyway, thanks again for your consideration. I'll work towards putting together a sample pack for testing.

cheers!

Sam

• re: deleting

You just described what I had in mind as well, having 'Delete' as an option.

Note: my QNAP has for each "share" the option to enable the Network Recycle Bin - even per share if need be.

• re: approximation of aspect ratio

I'll look into this some more. Maybe go the route: show an "*" if ffProbe did not give me aspect ratio.
Maybe add: or if the provided aspect ration from ffProbe did not fit the list of [my] standard list of nice looking aspect ratio number 😜 

• p & i frames

You are totally right the "p" not always being correct 😊 
I'm open to ideas on how to reliably determine this.
The "p" is currently without much purpose and just decorational 😉  

Just a quick update:

I've already implemented the option to prevent file deletion.
Also note that its a good idea to check the "Option: Show Warnings on Delete/Remove".

Have to tinker with a few more things before I will release a new version - but I'll keep you posted 😁 

One more update:

Also implemented showing an asterisk behind estimated aspect ratio's.

This option is default off, but can be toggled on and off.
Additionally, the word "estimated" is added in the hint window when hovering over an aspect ratio (always visible).

Estimated means:

1) ffProbe did not produce an aspect ratio value
2) ffProbe did produce an aspect ratio, but it's not in the "common" ratio's list

Note: pixel aspect etc is ignored when the estimation is done. The ratio is a basic pixel width:height ratio.

I'm implementing a few more things, like several command-line options, and a macOS Apple Silicon version.
Once that is done, a new version with these options will be released.

You may like the command-line options, since they allow starting with a specific database, adding directories or files, scanning or updating files, with or without the GUI being visible.

Just uploaded v2.2.2 (here) - hope this gets close to what you had in mind.

@hans thank you so much for implementing all of this! and apologies for taking so long to find the time to test it.

re: video aspect ratios - the 'estimated' works ok for me and seems a good compromise.

re: pixel aspect ratios - if it's not there, then yeah perhaps leave it out rather than assume 'square' / 1:1, but it would be great to flag up if it is there is that info in FFPrbe - eg : sample_aspect_ratio=10\:11

re: i / p resolution - i would leave the 'p' out if FF cannot provide info about the film being interlaced or progressive - again its better for me to know I don't know that info, than think I know and it be wrong. I can't see that info in the FFProbe info, and it doesnt seem to appear in Quicktime, though oddly MediaInfo seems to find it - not sure where but hey.  

re: file deletion / removal from list - this is so great! thankyou - I feel much calmer now sharing this tool with colleagues now that there is a safety catch!

re: hover over - I noticed the resolution (eg 1080) and format (eg HD) rollovers are switched

anyway, thanks again and keep going - its a great tool and a lovely interface!

Sam