(red channel) pumping after framerate change

megabit wrote on 7/8/2008, 9:30 AM
I have trans-coded some EX1 1080/25p clip to 720/24p, as required by Vimeo:

http://www.vimeo.com/1302793

In order to avoid re-compression due to framerate change, I used Bob's method of stretching the event on Vegas timeline so that it occupies the exactly same number of frames as the original, 25p source.

However - I don't seem to be able to get rid of the picture red channel "pumping" (particularly visible on the red brick wall, some secs into the clip). This is of course not present in the original 1080/25p video; neither is it visible when playing back from Vegas timeline, after changing properties to 720/24p...

What do you think is the reason?
editSorry for dirty montage

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

Comments

farss wrote on 7/8/2008, 11:32 PM
If it looks OK before Vimeo did it's thing to it the logical conclusion is that's where it went wrong. It might have something to do with the lighting on the bricks however as you're in a 50Hz country shooting 25p would be your best way to avoid any beating between the lights and the shutter, something I've seen happen down here trying to shoot 24p.


Bob.
megabit wrote on 7/9/2008, 12:48 AM
Thanks Bob for your reply, but actually the conversion Video did makes the phenomenon LESS pronounced. I can see it at its ugliest before posting, when I play back the 720/24p version from my HDD. Have no idea what's happening, but since I have sort of mastered my own way of downscaling to SD (for DVD delivery purposes), I guess it's not so much the resolution change but the framerate change that's causing it...

Since it seems Vimeo is not the best way to show this particular conversion shortcoming, would you take a look if I sent you a link to a several seconds clip straight from my HDD?

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

farss wrote on 7/9/2008, 4:01 AM
Sure, I'll take a look for you.

Bob.
megabit wrote on 7/9/2008, 4:44 AM
OK Bob, here you go:

http://megabit.diinoweb.com/files/pumping.mp4

- it's a very short (2MB) clip, but the problem is visible.

Looking forward to your comment!

Piotr

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

farss wrote on 7/9/2008, 5:51 AM
Got it, might have to wait for a few hours for me to look at it frame by frame. I've got a couple of systems in pieces at the moment.

Bob.
farss wrote on 7/9/2008, 7:13 AM
That's very strange. There seems to be a loss of detail in the frame rather than a a shift in level. Have you carefully checked the source frame by frame, the change if frame rate could have made something that wasn't noticeable before noticeable.

I find it very hard to see actually. What are your lighting conditions where you're viewing this. All my lighting is HF fluro, that can have an impact as well I think.

Bob.
megabit wrote on 7/9/2008, 10:47 AM
Bob,
Yes I did examine my 1080/25p source - no trace of it.
In the 720/24p version, I can see it clearly in daylight and tungsten light (small lamp on my desk); on both the LCD monitor and the 50" plasma...

I agree it is more a cyclic change in detail, than the red level - it is most evident in red-dominated areas, though. Strange.

PS. It just occurred to me it never happened when I converted HDV in Vegas execatly the same way. It so happens it's 1440x1080, as opposed to 1920x1080 of my mxf source file this time. Now, 1440 is exactly 2x720, while 1920 is not such a nice multiplicity...

Could it be some Vegas / Mainconcept codec bug? If so, just what does Vimeo "conforming" does to get rid of it almost entirely?

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

megabit wrote on 7/10/2008, 6:28 AM
Has anyone (Bob?) come to a conclusion regarding a possible reason of this ugly phenomenon?

Even if Vimeo can iron it out (as it obviously does), it's important to be aware of Vegas limitations (if any) when down-scaling or changing framerate (e.g. for full Bluray compatibility)...

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

farss wrote on 7/10/2008, 6:47 AM
Sorry been flat out wrangling a stage show and code written by idiots, well maybe the code wasn't but whoever wrote the documentation is.

Without the source file to permit repeating exactly what your pipeline was it's very difficult to diagnose this problem.
My suggestion would be to eliminate the variables one at a time.
I guess start at the beginning, grab a still of one frame of the source and render that to a file and run that through the same process.
If you get the same result that clears anything the camera did, if you don't them start looking at what the camera did when it shot the footage.

Probably the reason it doesn't showup on Vimeo is because the resolution has dropped or else their encoding has smoothed it out over several frames.

Bob.