Anyone noticed that files flagged as rec hd709 (8bit 16/235 - 10bit 0/1063- 64/960 and photo 6k) show with expanded levels crashing blacks in premiere and ae?? i tested it recording the colours bar in camera and then importing it in premier adobe where these files show up with more contrast and looking at the histogram the blacks get darker!!
@Vitaliy "I do not see any issue with 8K production. Capture 8K 420 video, frame it as you wish and export 4K. With small proper editors adjustment it can be fully realtime for H.264 and HEVC already."
In theory, yes. In practice, no. If all the major software still struggles with multi-stream 4k, then doing any serious work with 8k is still a long way off.
Today we’re releasing an update for Premiere Pro CC 2017. The 11.1.2 update contains important bug fixes as well as performance improvements. It also adds support for the 10 bit formats of the Panasonic GH-5.
@sebolla, can you tell us if this update fixes your issues with the GH5's 10-bit full range video files and 6k photo files?
4k is only barely starting to be used for delivery and we are still a long way from full 4k acceptance in acquisition, simply because nobody really cares. Any more than 4k is a wank-fest. 8k will be a giant bottleneck in post production, and not because of technical decoding issues.
4K just show regressive nature of capitalist productions. As profit and sales are the only goals.
Any more than 4k is a wank-fest. 8k will be a giant bottleneck in post production, and not because of technical decoding issues.
I do not see any issue with 8K production. Capture 8K 420 video, frame it as you wish and export 4K. With small proper editors adjustment it can be fully realtime for H.264 and HEVC already.
In the real world, nobody cares at all about 8k. Fuck, we barely have full HD for broadcast and most corporate jobs are still HD. 4k is only barely starting to be used for delivery and we are still a long way from full 4k acceptance in acquisition, simply because nobody really cares. Any more than 4k is a wank-fest. 8k will be a giant bottleneck in post production, and not because of technical decoding issues.
True, but 8k will not work without GPU acceleration, even with best CPUs. (As CPUs are now all multicore- they are not getting faster) so I am guessing there will be "super new amazing feature" very soon.
Only hardware GPU decoders will work, all this general GPU acceleration does not work good.
In reality we have strange situation.
During editing you have decoding and simple effects / transitions / titles, if done right they do not require any hefty hardware. Even with raw realtime debayer, color correction, adjustments and playback can be done on 1060.
Yet we have BM proposing 1080Ti (1070 at least) and guys doing measurements using 20 heavy blur nodes and such.
This next [Premiere Pro] update will also include a number of performance improvements and bug fixes in other areas, and it will include support for the 10 bit formats of the Panasonic GH-5.
whatever that means
True, but 8k will not work without GPU acceleration, even with best CPUs. (As CPUs are now all multicore- they are not getting faster) so I am guessing there will be "super new amazing feature" very soon.
Not sure. As situation is shit for years and years.
Adobe is like behemoth stuck in the shit hole. Black Magic is upgrading their battle elephant to allow you to drive three elephants while sitting in the basket full of cobras.
I think that NLE's are going to have to get with program soon, as 8k is just around the corner, and CPU's are not getting that much faster.
Don't worry, it will be "new revolutionary" feature!
Btw with Nvidia 1000x cards it must be almost zero CPU load while editing 6K 10bit HEVC, as they support up to 8K 10bit 420 decoding. Just editing software sucks.
@balazer remember that 6k HVEC is also 10 bit, just not 422, (420).
I don't have AE so I don't know what you're talking about. But I don't think you're right. The pattern I observed in Premiere is clear: in 8-bit H.264 files, Premiere obeys the Video Usability Information video_full_range_flag, and in 10-bit H.264 files, it doesn't. Either way, it's an issue with Premiere for the 10-bit files. You can take it up with Adobe.
The 6k photo mode is different: that's H.265. Premiere might be wrong there too. I've never tested an H.265 file in Premiere.
I think standards are a bit hit and miss these days @balazer. Look at RAW images, lots of different 'standards'. Companies simply make it up instead of using something standard like DNG. (Which has its own limitations- at least in the few cameras that do support it).
If there are problems one can always transcode I suppose, treat the footage like a RAW format. Just have to work out if those extra couple of values are worth the time.
Oh yeah, Premiere reads the full range flag in 8-bit files, but not in 10-bit files.
Call it a bug or a limitation. The truth is that the flag is not a required part of any standard. Most video apps don't read the flag at all. Stick to the standard video levels (16-235 in 8 bits and 64-940 in 10 bits) and everything works fine. When you use non-standard levels you will find inconsistent support in video apps.
As @balazer said, they should all 'look' the same. They just have different amounts of luminance information. It looks like an issue with premier. Send a bug report, Adobe are probably very busy fixing lots of GH5 stuff right now.
thanks balazer for the info...like you said i did a test with real life footage and in 10 bit 0-1023 luminance and photo 6k blacks get crashed and!! So this is my conclusion: 8 bit 0-255 8 bit 16-235 10bit 64-960 they all look the same in timeline
10bit 0-1023 and photo 6k they look more contrasty with crashed blacks Maybe they shouldn't be flagged as hd rec 709??
Hopefully this will be fixed soon in Premiere...
Premiere isn't wrong. It's decoding the levels according to the full range flag set in the H.264 stream, which depends on the luminance level setting in the camera. The inconsistency is due to the fact that the test pattern is only defined for video levels, because that's how the test pattern is specified in the SMPTE standard. Effectively, the test pattern is wrong when the camera is set to 0-255 because the camera writes a video stream with a flag that doesn't match the encoding.
Just forget the test pattern. It doesn't matter unless you understand exactly what the camera is doing to generate it, how your video application decodes video, and how the test pattern should be interpreted.
If you record an actual video image in the camera, you'll see that everything works right in Premiere: you get the same image with the same levels after decoding, regardless of whether you select 16-235 or 0-255 in the camera. Well, almost everything works right. Don't choose 0-255 when you record to MP4, because Premiere uses the incorrect BT.601 YCbCr to RGB decoding matrix instead of the BT.709 matrix. Stick to 16-235 or 16-255 and everything will be fine.
No,the clip should look the same,no matter if you you choose to record at 0/255 or 16/235 or 0/1064...what's wrong is the interpretation of levels from premiere or ae... well,i can fix this issue in ae setting the project at 32bit and applying a level filter but i can't fix it in premiere because this filter works different in premiere...
Different luminance modes should change the colour bars for every picture style. If rec 709 is crushed, can you correct it in premier? Or is there information lost? (ie: are blacks / shadows really noisy - more than usual?)
Premiere histogram or waveform...if you record the smpte colours bar in camera with different luminance settings they all look the same when viewed in camera,but if you import them in premiere or ae you will see that those flagged as hd rec709 get darker crashing 2 of the 3 black colours bar on the bottom right...it's probably how to premiere and ae interpretate hd rec 709..
It looks like you're new here. If you want to get involved, click one of these buttons!