MediaConch Policy Check "Failed"

EmCNabs commented 3 months ago

MKV files report back as "failed" using the MediaConch JPC_AV_NTSC_MKV_2023-11-21.xml policy because it is checking for a specified Title & Descripton, and an older version of Lavf. (Full MC report attached)

Using MediaConch policy JPC_AV_NTSC_MKV_2023-11-21.xml

Running command: mediaconch -p /Users/medialab/github/JPC_AV_videoQC/config/JPC_AV_NTSC_MKV_2023-11-21.xml "/Users/medialab/Desktop/JPC_AV_Tests/2012_79_2_224_1a_PM/2012_79_2_224_1a_PM.mkv" -oc /Users/medialab/Desktop/JPC_AV_Tests/2012_79_2_224_1a_PM/2012_79_2_224_1a_PM_qc_metadata/2012_79_2_224_1a_PM_mediaconch_output.csv

MediaConch policy failed:
overall: fail

General/Title is Black Film Archives, Tape 3 ❌ fail (Actual: Midnight Ramble: Oscar Micheaux Clips) Value: Title Tracktype: General Operator: = Requested: Black Film Archives, Tape 3 Actual: Midnight Ramble: Oscar Micheaux Clips Xpath: mi:MediaInfo/mi:track[@type='General'][*]/mi:Title

General/Description is A man demonstrates film winding on a film bench; a wide angle shot outside of Southern Methodist University ❌ fail Value: Description Tracktype: General Operator: exists Requested: A man demonstrates film winding on a film bench; a wide angle shot outside of Southern Methodist University Xpath: mi:MediaInfo/mi:track[@type='General'][*]/mi:Description

General/Encoded_Application is Lavf59.27.100 ❌ fail (Actual: Lavf60.3.100) Value: Encoded_Application Tracktype: General Operator: = Requested: Lavf59.27.100 Actual: Lavf60.3.100 Xpath: mi:MediaInfo/mi:track[@type='General'][*]/mi:Encoded_Application

2012_79_2_224_1a_PM.mkv_MediaConchReport_FAIL.txt

eddycolloton commented 3 months ago

This is weird. Might take some more digging. I have General/Title and General/Description set to just check to make sure they "exist". There shouldn't be a check for General/Encoded_Application at all.

Is the md5 of your xml file: 4f3c5e0a0853cef691b40b440c81d2c2 ?

eddycolloton commented 3 months ago

circling back to this, I figured out why the "Title" field is failing.

MediaConch is seeing the custom field in 2012_79_2_224_1a_PM.mkv as: General/extra[1]/title

But in JPC_AV_0500.mkv and 2012_79_2_230_1a_PM.mkv have the title in General/Title instead, this is what the mediaconch policy is looking for.

None of the other test files I have (JPC_AV_00011, JPC_AV_01663, JPC_AV_1709, and JPC_AV_1710) have either title field.

I propose we remove the Title check from the mediaconch policy all together since we now check for it using mediatrace.

Speaking of, the mediatrace check actually fails for 2012_79_2_224_1a_PM.mkv too, because it is looking for "TITLE" and not "title". I will make mediatrace checks case insensitive going forward.

eddycolloton commented 3 months ago

I've added a new mediaconch policy, JPC_AV_NTSC_MKV_2024-07-31.xml, which does not check for Title, Description or Encoded_Application/Encoded_By, and updated the command_config.yaml file to call the new file. /2012_79_2_224_1a_PM passes the new policy. Commit details here: https://github.com/JPC-AV/JPC_AV_videoQC/commit/4550364be2b7776748fd7004868696a433118115

DSohl commented 3 months ago

Hello, @eddycolloton ! I'm getting some different MediaConch (and Exiftool, and MediaInfo) failures now, which are aspect-ratio-centric. Here's the errors I get:

Running command: mediaconch -p /Users/medialab/github/jpc/videoQC/config/JPC_AV_NTSC_MKV_2024-07-31.xml "/Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155.mkv" -oc /Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155_qc_metadata/JPC_AV_04155_mediaconch_output.csv

MediaConch policy failed:
overall: fail
General/Encoded_Date Exists: fail
Video/PixelAspectRatio is 0.900: fail
Video/DisplayAspectRatio is 1.333: fail
Audio/Format is FLAC: fail
Audio/CodecID is A_FLAC: fail
Audio/BitRate_Mode is VBR: fail

Running command: exiftool "/Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155.mkv" > /Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155_qc_metadata/JPC_AV_04155_exiftool_output.txt

Some specified Exiftool fields or values are missing or don't match:
Metadata field Display Width has a value of: 400
The expected value is: 4
Metadata field Display Height has a value of: 297
The expected value is: 3

Running command: mediainfo -f "/Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155.mkv" > /Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155_qc_metadata/JPC_AV_04155_mediainfo_output.txt

Some specified MediaInfo fields or values are missing or don't match:
Metadata field Pixel aspect ratio has a value of: 0.909
The expected value is: 0.900

Creating MediaTrace XML file to check custom MKV Tag metadata fields:
Running command: mediainfo --Details=1 --Output=XML "/Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155.mkv" > /Volumes/JPC-ChicagoNAS/20240805/JPC_AV_04155/JPC_AV_04155_qc_metadata/JPC_AV_04155_mediatrace_output.xml

Some specified MediaTrace fields or values are missing or don't match:
COLLECTION metadata field not found
TITLE metadata field not found
CATALOG_NUMBER metadata field not found
DESCRIPTION metadata field not found
DATE_DIGITIZED metadata field not found
ENCODER_SETTINGS metadata field not found
ENCODED_BY metadata field not found
ORIGINAL_MEDIA_TYPE metadata field not found
DATE_TAGGED metadata field not found
TERMS_OF_USE metadata field not found
_TECHNICAL_NOTES metadata field not found
_ORIGINAL_FPS metadata field not found

An oddity that may (or may not) be related is that I've been getting this message upon finishing every transfer:

2024-07-30T12:51:32 - File did not pass vrecord policy check for FFV1 video and may not conform to digital preservation standards. Try another file?
 2024-07-30T12:51:32 - See /Users/medialab/Desktop/JPC/20240730/JPC_AV_01755/JPC_AV_01755_mediaconchreport.xml for a full MediaConch policy report.

Dave Rice says "the matroska didn't finish writing properly. Normally the muxer writes all the audiovisual data and then goes back and adds the crc's and cues and some other data when it's finalizing it, but that last step didn't happen." Based on his advice, I've been running ffmpeg -i [JPC_AV_12345.mkv] -map 0 -c copy [JPC_AV_12345.mkv] and replacing the original video file with the copy that completed those last steps before running av-spex.

eddycolloton commented 3 months ago

Thanks @DSohl . Are these PCM audio encoded? The MediaInfo and Exiftool checks accept both codecs, so that's why we're getting fails for those in MediaConch and not in the other checks.

Could be worth discussing removing those audio codec checks from the mediaconch policy if both PCM and FLAC are acceptable for JPC mkv files. @BleakleyMcD

God I hate aspect ratio math.

Could be a few different things going on here:

there is an issue w the video file
the metadata checks should be changed to these new values
the metadata checks should be made more flexible to allow for multiple values

What do you think? Would you mind sending me this file?

DSohl commented 3 months ago

@eddycolloton Yeh, they're 24-bit PCM. I sent you a dropbox link to a file I transferred yesterday, let me know if you didn't get it. Both the original transfer and the copy with Dave Rice's recommend modification are in there if you want to see them both.

eddycolloton commented 3 months ago

Thanks @DSohl , I received both versions of JPC_AV_01772 - I'll take a look later this week.

eddycolloton commented 2 months ago

The two versions of JPC_AV_01772 both have the same display aspect ratio and pixel aspect ratio, which is what is failing on our mediaconch policy. This would appear to be different than what Dave is talking about with the vrecord error message.

I'm a bit stumped on what the correct pixel aspect ratio (PAR) value should be for an NTSC file.

This is the resource I see cited on this subject most often: https://bavc.org/par-sar-and-dar-making-sense-standard-definition-sd-video-pixels/

This says that Rec 601 standardizes the PAR for NTSC as 10:11, which is 0.90 repeating. So, does that mean the PAR should be 0.900 or 0.909?

I haven't been able to find public policies that state a specific PAR, most recommendations and standards just say things like "non-square" or "Rec 601 compliant".

The display aspect ratio being 400:297 makes me think the PAR may be incorrect, and that the mediaconch policy is correctly flagging this as encoded incorrectly. But again, I find the whole aspect ratio math thing exceedingly confusing so I'm not the best judge.

eddycolloton commented 2 months ago

Hi @EmCNabs @BleakleyMcD @DSohl - I'm looking to close out this issue.

To summarize the thread so far:

New mediaconch policy, JPC_AV_NTSC_MKV_2024-07-31.xml, which does not check for title, description, encoded_application, and encoded_by.

Pending questions:

Should we also remove audio codec check from Mediaconch policy, since both PCM and FLAC are acceptable, but Mediaconch can only accept one or the other?
Should PAR/DAR values for JPC_AV_01772 be included in acceptable values?

eddycolloton commented 1 month ago

Just updated to JPC_AV_NTSC_MKV_2024-09-20.xml which makes PCM the passing audio codec value https://github.com/JPC-AV/JPC_AV_videoQC/commit/710d170d3262f33a9e3dcd4fb9b82beab1c2dbdf

JPC-AV / JPC_AV_videoQC

MediaConch Policy Check "Failed" #51