[Larry Little]

I agree that this difference shouldn’t be noticeable, but there is something about the way that Sorenson is removing frames that adds a slight jitter to the video.

Ah — now THAT I can understand seeing! I totally misunderstood what you were saying. I thought you were saying that it’s simply playing the same number of frames at a slightly slower speed — i.e. that the entire movie takes just a tad longer to complete. You’re saying, however, that it’s actually DROPPING frames in order to “convert” the original framerate to 23.952fps.

Yes — that’s definitely something you could see since missing frames can be quite noticeable.

If Sorenson needs a better test to demonstrate what’s happening, just give them something with timecode burn-in, or perhaps some sort of leader with even movement in it, so they can actually see the number sequence skipping over frames.

Please keep us posted on what happens,

Larry

[Larry Little]

One question I have is if the Avid DV codec has the option of adding 7.5% setup or keeping it at 0? Some DV codecs work in the 0-255 range, meaning black is 0% black. If you’re working in NTSC land, a codec might change that to the NTSC equivalent, which I believe is 15-235 or something thereabout.

Basically, you have the option of outputting 601 (16-235) or RGB (0-255) levels regardless of whether or not you use the Avid DV codec. In other words, there is no specific ‘setup’ setting connected to the Avid DV codec — it’s simply a setting in the Quicktime Reference output options when you export from Avid. You select RGB or 601, and you ALSO have the option of checking the “Use Avid DV codec” box. If you don’t check this box, my understanding is that it uses the Apple DV codec.

Regarding the issue of VLC being unaffected by the monitor calibration (and therefore creating VASTLY different color than other players), it looks like I’ll have to disregard the VLC player for now because of this issue. I don’t really have the time to try and track this one down, but I did do some quick searching and found another reference to this on the videolan (maker of VLC) forum. Here is the link if anyone is interested:

https://forum.videolan.org/viewtopic.php?f=7&t=64718

Since QT and WMP don’t exhibit this issue, it looks like I’ll just have to use them instead.

Following up on my earlier post, I did get a chance to test the non-Avid DV codec. I output a QTRef file from Avid WITHOUT checking the “use Avid DV codec” box, and I got the same basic issue with Squeeze — i.e. when creating an mp4 using the MainConcept h.264 encoder in Squeeze, the resulting file was darker by what I would call a “significant” amount.

I also did tests with bars (both color and black and white) and can confirm that the results I get with Squeeze are definitely “wrong” if I don’t do any correction in Squeeze. By this I mean that when I view the encoded file using the same monitor I used to create the content, the resulting mp4 has blacks that are completely clipped. The bottom line is that there is definitely SOMETHING going on with the Squeeze implementation of the MainConcept mp4 encoder. You can work around it, but it’s definitely there.

One other note: When I use Quicktime Pro to encode the same QTRef file as an mov and play it back with Quicktime, the result is VERY close to the original in terms of color and luminance. In other words, the Apple encoding engine does NOT exhibit the shift that the Squeeze MainConcept encoder does.

Thanks again for the help here,

Larry

[Larry Little]

Again…it comes down to how you’re comparing the QTref file with the encoded file. Are you playing the original file and the encoded file on the same media player on the same monitor?

I’m comparing it both to what I see in Avid, as well as to the QTRef file (output as RGB for computer playback) that I create with Avid and play back using Quicktime (which looks like what I see in Avid.) Yes — every comparison I’ve referred to is on the same system and monitor.

If so, then I cannot explain the differences you’re seeing with the Main Concept codec. Maybe it’s something specific to squeeze? Also, what codec does the original file use?

The original codec I use in Avid is the Avid DV codec (i.e. I check the “Use Avid DV codec” box.) I’m going to try outputting a QTRef without checking this box just to see what happens, but I’ve read and been told by multiple sources that the “user Avid DV codec” box should be used due to potential gamma issues when it’s not used. I’ll report back if this makes a difference to Squeeze.

The bottom line is that there is absolutely a shift when using Squeeze’s MainConcept h.264 encoder to create mp4 files when starting with an Avid QTRef file that used the Avid DV codec. The output is expanded (i.e. as if it’s doing something similar to a 601 to RGB shift) and the gamma is off as well. As I mentioned, others have reported this, but the only “solutions” I’ve seen are to manually adjust the output using the Squeeze controls in order to compensate for the shift.

There is a thread on this forum that talks about this, including a few posts of mine that discuss the specific differences needed to create output that gives the desired result (i.e. that matches the original):

https://forums.creativecow.net/readpost/20/865046

We see differences in our files from media player to media player and from monitor to monitor, but not as significant as you’re reporting.

I’m definitely not talking about monitor to monitor differences. I’m talking about differences from one player to another, such as the QT player vs the VLC player. In this particular case, however, I traced at least a good portion of the problem to the fact that the VLC player is NOT effected by my monitor calibration. I use a Huey Pro to calibrate my monitor. When I turn the correction on and off, I can see the color on the screen shift, but the actual VLC screen is exempt from the shift. In other words, the QT and WMP screens both apply the Huey Pro correction, but the VLC screen does not. Only the actual border of the VLC player is effected by the calibration — the video playback remains unchanged. Apparently, the VLC screen is “outside” of the Huey Pro correction for some reason. I’ve never seen this before — I always thought that the entire screen was effected by the calibration regardless of what was being displayed.

The end result is that since QT (and WMP) are both effected by the monitor calibration but VLC is not, the VLC screen is showing me the image without the monitor calibration, which causes a significant color shift. If I turn off the Huey Pro monitor calibration, the shift is far less significant.

The new question is what to do about this. Why is VLC “outside” of the Huey Pro correction, and is there any way to get it to be effected by the color changes made by the monitor calibration?

Thanks again,

Larry

[Larry Little]

Glad you got it solved (or are at least on the right path.)

I’m NOT downplaying the importance of getting this issue fixed, but I’m curious — can you REALLY “see” the difference in speed, which is only .1%? It’s only a .024fps difference, which is exactly the same fps difference as 24fps vs 23.976fps, which most people consider utterly undetectable. That’s only a single frame slow after 41.7 seconds. Again, I fully agree that this needs to be fixed — I’m simply astonished that anyone could actually SEE the difference visually.

By the way, it may be significant that the difference you’re seeing IS exactly the same as 24 to 23.976 (i.e. a .024fps difference.) I thought that this might help point to the issue — i.e. maybe Squeeze is automatically applying some sort .024fps “correction” thinking that this is needed to create a 23.976fps output instead of 24fps. It just seemed interesting that the fps difference was exactly the same as 24 vs 23.976.

Larry

[Larry Little]

It’s not clear from your post what specific codec you’re using.

I use the MainConcept codec in Squeeze, but just to troubleshoot I also did tests with the Apple and Sorenson h.264 codecs and saw the same issue with the file looking significantly different with different players.

So if you’re using Main Concept (or another codec besides Apple’s) to encode your files, you shouldn’t make any adjustments to your final output.

I can’t say that it’s specifically the MainConcept encoder, but I CAN say that when used in Squeeze, there is absolutely a significant shift that requires adjustment in order to make the image match the original QTRef file. In other words, when using Squeeze to encode h.264 mp4s using the MainConcept h.264 encoder, I have to make significant adjustments in order to get the output to match the input. There are actually other posts talking about this issue both on Cow and other forums.

That, however, is actually a separate issue than what I’m talking about in this thread, which is that there is ALSO a significant difference in the resulting image when played with different players, and that this is regardless of what codec I use. I tried using the Apple codec, the MainConcept codec, and the Sorenson codec. In every case, the file looks substantially different depending on the player I use. The difference is not just with luminance, but with color as well. VLC, for example, looks a lot darker and more green than when the same file is played in Quicktime. For bright scenes the difference is annoying, but for particularly dark scenes it can be a real problem due to details getting lost.

I guess this comes down to the fact that I’m surprised at just how MUCH variation I’m seeing here. I always thought that monitor calibration differences — along with many aspects of the NTSC system in general — were bad enough in this regard, but those differences pale in comparison to the differences I’m seeing just from one mp4 player to the next on the SAME monitor and system. In other words, regardless of how careful you are to calibrate the computer monitor, a different player can completely change the look anyway. Doesn’t this just throw the whole concept of “calibration” right out the window?

Is there something fundamental I’m missing here, or is the whole system of playing back videos on a computer pretty much an utter mess at this time?

I guess the question comes down to which player is the most common one to view mp4 files. Is it QT? You said you used a flash player, but does this include mp4 files, or are you talking about using h.264 with flv files?

Thanks again for the feedback,

Larry

[Larry Little]

I should also add that this is using Quicktime to view the files, and comparing the original QTRef to the output.

Larry

[Larry Little]

Did you even find out anything further on this?

Just to make sure I understand, it’s playing “normally,” just at a slightly slower framerate, correct? (i.e. it’s not actually dropping frames or showing any sort of visible playback issue, correct?)

Out of curiosity, did you try any other framerates just as a troubleshooting step to see if OTHER encoded framerates are effected by a similar bug, or if it’s just the ones around 24fps? It may help point to a where the glitch is actually happening.

When I’m faced with this sort of issue, I start trying other settings just to see if I can isolate the issue. For example, you might want to try an encode without audio, or perhaps with audio set to 44.1 instead of 48 just to see what happens. Sometimes a seemingly disconnected setting can end up being the culprit.

Larry

[Larry Little]

Just to clarify, the -11 gamma setting I mentioned above is in addition to the fact that I’m using a 601 (16-235) QTRef source file, which expands when it’s encoded due to the Squeeze MC encoder issue. The effect of the luminance expansion AND the Gamma setting result in a “ballpark” correct result.

Larry

[Larry Little]

I’ve been struggling with the exact same issue using the MainConcept h.264 encoder in Squeeze 6 — the resulting image is substantially darker than the input source. I’m not sure if it’s a Squeeze issue, a MainConcept issue, or an issue with the QTRef files from Avid MC that I’m using, but I do find other people talking about this on the web, so it’s not unique to me (or Stephen, who started this thread.) It’s not subtle — it’s a VERY obvious shift.

In order to do the least correction inside of Squeeze, I found that I had to start with QTRefs that have 601 levels (16-235.) These end up being shifted closer to RGB levels on the encoded file. In other words, the input source is 16-235 (QTRef file output from Avid Media Composer), but the encoded output ends up much closer to 0-255.

Unfortunately, it’s far from an exact 601-to-RGB level shift, so I find that I still have to do some extra correction in Squeeze. If I drop gamma to -11, it’s “relatively” close, but it would be nice to get it closer (which is what led me to search for other people’s solutions to this, and in turn to find this thread.) I’ve tried all sorts of combinations of corrections in Squeeze using varying levels of Gamma, Brightness, Contrast, Black Restore, and White Restore. Any given combination of settings will look better with certain scenes vs others (i.e. dark vs light scenes, etc.), but in the end, it seems like simply using -11 Gamma in Squeeze looks generally pretty good overall across a variety of scenes. It’s just a tad more contrasty and just a bit lighter overall compared to the original, but my other more complicated setting combinations come with other drawbacks, so for the moment I’m just using -11 gamma.

On another unfortunate note, none of other reports of this offer any solid solution other than to fix it via trial and error. This includes at least one post on the Sorenson forum reporting this same issue. I’d be very interested in hearing any other information on this issue, or other setting combinations that people have used to resolve this.

Thanks,

Larry

PS. Note that you cannot use the “Preview” window in Squeeze 6 to dial in the correction settings because the preview image is VASTLY different than the encoded output — it’s not even close. For any sort of color or luminance correction, the preview window in Squeeze is quite literally useless. This has also been reported on the Squeeze forum, and I reported it via the phone support as well.