@From_Paris : Désolé à cause d'un bug Vimeo je ne peux pas répondre à ton message (pour le moment) ++

@ Swiss_Boy Je suis d'accord avec toi. Converting 24p to 25p is not so simple to deal with. It may be a solution for short format or no audio sync shot.

Maybe we must found "a Pal" Nick Driftwood".

Google Trad give me "Bois flotté" for Driftwood Y'a t il un Nico BoisFlotté sur le forum??? ;-) Herbycamer

@mozes What is the resulting file's purpose? "on-line" doesn't mean online, does it. Then 25mbs might be a bit much. Otherwise 25 might be a bit of a waste of time before, filming, transcoding and editing in higher bitrates. (Sorry to enlarge that OT but it seems a problem related to the high bitrate settings here.)

Yep, sorry, @liquidify , it was just some open question what to do with those hight quality pictures that touch the edges of 4:2:0 on all sides.

@Braamokiev That was excellent man!

@Tobsen Thank you. Yes.

@Swiss_Boy The method of conversion you describe is the most primitive and least effective. Research it. I'd need to write an essay on it to respond properly -- there are different methods for different objectives.

@itimjim "5DtoRGB" is the longest running April Fools joke in this community. Perhaps it works for the old Final Cut, but for Premiere you can accomplish EVERYTHING it does in about two seconds on the native clips. The performance issue suggested only relates to ancient computers. Anything modern, and certainly anything with a certified NVIDIA card will be indistinguishable from old fashioned Prores. There is absolutely no up-sampling of anything with "5DtoRGB." Anything you stick in Premiere Pro is being corrected in 12 bit 4:4:4.

@YOSS This is exactly the correct way to handle clips without audio. If you've got a voiceover or whatever -- this is what you'd do -- and it takes about 2 seconds.

@mozes

I haven't used MainConcept in years -- everything I do is direct export from Premiere Pro CS5.5.

But -- your first screengrab of settings raises a number of flags. First, you're encoding out to mpeg-2 -- and half of the magic of your hacked GH2 is mpeg-4 -- there's a HUGE difference between the two.

Next, assuming you've filmed in 25p on the GH2 -- you've not actually filmed in 25p -- you've filmed in 50i, and the progressive frames aren't flagged -- and that means MainConcept can't extract progressive frames from your interlaced stream.

These two issues alone create a chain of other problems.

So -- again -- I haven't used MainConcept in years and perhaps you know that you're doing everything properly -- but -- those are the flags that were raised when I looked at your first screen.

No problem @onionbrain it's something I'll have a good look into it when I have the time. I trust your opinion, so thanks for the honesty.

Here's a test that shows the difference in image detail with sharpening cranked in post. This test shows how poorly the stock firmware can repesent finer detail (larger macroblocks). This also shows that Mysteron (original not burst) is close to Sedna A AQ1, but falls just a tad short in detail.

The test was done in controlled indoor lighting 5K (color temp)

24H

ISO 160

5K WB set in camera

Smooth (all -2 settings)

160 SS

2 Stops Under exposed

14-140MM Lens @ 33MM

Fucked up the framing for stock, but it's close.

Stock GH2 v1.0 (never hacked) (17Mbps)

Mysteron (Standard) (117Mbps)

Sedna A AQ1 (143Mbps)

@bwhitz

Respectfully, you're either reading their marketing materials or hopeful bloggers. It's entirely possible "5DtoRGB" did something useful for the old Final Cut -- I haven't touched the old FCP in over five years and I don't know.

For Premiere -- the absolute kindest characterization I can come up with is "hoax." Re-assigning values is different from up-sampling -- and it's not up-sampling. Again, everything it does can be done in seconds with the RGB Color Corrector in Premiere. Furthermore, almost any transcoding process has some element of destructiveness to it -- and this is especially cruel when you're dealing with footage as nice as you're getting with a Driftwood patch from the GH2. Additionally, the true benefit that most unsuspecting users are reporting relates to dynamic range -- and that can also be accomplished in two seconds or less with a levels adjustment.

For people who love "5DtoRGB" -- great -- do your thing. But for those who are truly looking for a meaningful workflow -- I'm telling you -- it's a hoax. Spend your money on something useful like Neat Video and learn how magnificent this Driftwood footage is when you do a curves/levels adjustment or use the RGB Color Corrector in Premiere (it's almost like a reversed Technicolor Cinestyle). Yes, you can pull two or more stops of usable detail out of midtones and shadows.

@mozes I've had some outstanding results in the past up-scaling 720/60p to 1080 in Premiere. I expected it to be awful or mediocre at best -- and it was outstanding.

I'm just troubled by the mpeg-2 thing -- I'm at the point where I can simply look at a video and tell the difference between mpeg-2 and mpeg-4.

I agree with @onionbrain, I have used 5DtoRGB more than a fair bit, I used it because I was looking for a quick alternative to getting my footage into Nuke (without going through my normal approach of taking a sequence of TIFF files out of Premiere). It definitely is not upsampling in anything approaching a useful way. In fact I found it to be a destructive process with very high bitrate footage. Once I had built a script in Nuke and then taken in a TIFF sequence to replace the mov file I got from 5DtoRGB the difference in quality was more than noticeable (dramatic in some cases, and not in a good way). I tried it many, many times, it would have been very useful to me. Albeit I only tried with with the DNxHD codecs, no point me trying Prores as I'm on a PC but I can't imagine it would be that (or any) different.

I think the easiest way to see what damage 5DtoRGB can do is to see what effect it has on any shot with any kind of posterisation (banding), it will always look much worse coming out of 5DtoRGB than the native file (hence my claim that its not upsampling in any useful way). I found that an ffmpeg script that just rewrapped the footage in a quicktime DNxHD YUV format was a lot less destructive. Still, I'm back to TIFF exports, framecycler, big caches, and DJView and whatever I shoot maintains its quality. Also as onionbrain says, everything it does you can do in your NLE anyhow (if you'ld ever need to start with a 1.8 gamma, god knows why you would want to convert to that anyway).

@proaudio4 thanks for that comparison. I'm still using old Ptools and Quantum 9b. Are there any comparisons with the older settings like 9b. I've noticed a drop in data rate on the newer patches, are they really better in any way other than spanning on more cards?

@onionbrain @shian

So, with FCPX it's better to use 5DtoRGB?

I recently read that it was not necessary to use with 5DtoRGB FCPX!

@onionbrain even when selected the mpeg2, when setting the settings to high, it will render to a .m2t file.
But i am with you, even i didn't like mpeg2, thats why i am surprised with the results, when the codec is set correct.
Attached a screenshot from vlc player with the orginal mts file, and the m2t file
I render in sony vegas...

M2T file info
Bitrate-modus : Variabel
Bitrate : 15,5 Mbps
Maximale bitrate : 15,8 Mbps
Breedte : 1 280 pixels
Hoogte : 720 pixels
Beeldverhouding : 16:9
Framerate : 50,000 fps
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scansoort : Progressief

MTS file info
Bitrate-modus : Variabel
Bitrate : 58,9 Mbps
Maximale bitrate : 94,2 Mbps
Breedte : 1 280 pixels
Hoogte : 720 pixels
Beeldverhouding : 16:9
Framerate : 50,000 fps
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scansoort : Progressief

You can see the bitrate is way lower then the mts file, but the quality is practicly the same.
Maby @driftwood can say something about this?