Marks to @3pointedit for likely getting close to the answer. The rest appears to be a stream of complificationingeering.
In all likelihood what you are seeing as “saturation” is actually a byproduct of an incorrect curve. The source of the problem is likely that your “source” reference analysis was being decoded incorrectly. Where that is entering the chain is going to be tricky as heck to diagnose.
Any codec is transformed to the YCbCr domain. In doing so, the RGB values should remain (quantization errors aside) very close to your source file RGB.
I can see that the “Source” file looks much more contrasty, which suggests to me that your player you are evaluating the material in is likely not decoding your footage correctly.
Any transform from RGB to YCbCr is typically done to the specification, which stipulates a broadcast range scaling. This scaling changes the 0-255 RGB values to 16-235 and 16-240 range on the YCbCr planes respectively. Those scaled values are, assuming players behave correctly, scaled back to their proper positions on decode.
What I suspect is happening is that the original “source” decoder is likely assuming, absolutely incorrectly, that your Nikon footage is broadcast scaled and chopping off a significant range of values and scaling the remaining values. This ends up making your image much more contrasted, as well as being incorrect.
DSLRs and some pocket cameras introduced a nonstandard “full range” YCbCr encoding which uses the full 0..255 range of the YCbCr stream. Sadly, many decoders decode it incorrectly, and you end up seeing hyper-contrasted images. See that “Range” tag in the data dump? Frequently too, the decoder will use the wrong set of luminance coefficients to decode the footage, which results in colour skew.
There are also a plethora of other areas where an encode to decode chain might go wrong. I outlined some of those tricky steps in another answer here.
Best advice is to check your source footage decode in a few different players. I suspect that, while potentially not perfect, the FFMPEG libraries Blender is using are trying to give you the full range of your shot’s data, as it is decoded from the raw YCbCr values. The result will be a slightly flatter image with much more dense data, which ends up being much more optimal for grading and a better resultant image.
All of that said, how to match a look?
Creative grading is most optimally achieved using a nodal system, frequently non-realtime. Assuming the guess above is correct, you can figure out what portions of your footage you intend to use and grade them in the compositor. It will be a little tricky because of some colour things that are beyond the scope of this answer, but should be achievable. Try an ASC CDL node with a slight increase in Power, and possibly a very slight decrease in Slope.
Bottom line is that there is a better than average chance the decode you are seeing in Blender is closer to the intention of your source stream than what you are seeing in Random Video Player. Test against VLC, FFPlay, or even the free version of DaVinci Resolve.
Your curve is not delivering the result you appear to desire because you have applied a simple arc to it. What it sounds like you are wanting is a subtle ‘S’ shaped curve that rounds off the lower left to a hump towards the upper right.