Problems with Canopus HQ and After effects...

H

hvx_germanboy

Well-known member
Ok, i got a editing PC with an SP card and Edius Broadcast 4.1, so all codecs should be installed...

1st Problem: i did encode Canopus HQ clips(not lossless) from 720pn(pal) footage and AE(v.6.5) is not able to read it(error message: reading from video streak..bla bla..sorry, this one is in german, dont know what it would say exactly in english..!).

2nd: AE does import fine when i encode the clips in Edius efore to Canopus lossless, first thing here is: if i open it in AE it says that there are 50 frames(judges it as that and sets the same when i try to export from AE)

-when i have finished post-work in AE, i cant encode to Canopus HQ, unless it is Canopus lossless.....that works, but i see that the quality is much less(mostly the sharpness of HD is gone when i reopen it in Edius...!) then the Canopus clips i re-encoded from the .mxf-files in Edius before...so is this due to AE, or just due to the fact that this is going to the next level of compression?(actually it shouldnt as it is Lossless...well at least not too much..!?)

I could post frames too..i am really curious to know wat happens here at the different points, maybe i should get AE 7.0 and see if this solves the problem as there are some other bugs occuring in AE too..( AE crashes while rendering when try to switch to a different window or program....)

:( :dankk2:
 
I too have problems with Canopus HQ, in my case with Procoder Express for Edius.

If I export a sequence using the Canopus HQ codec to a Procoder Express for Edius watch folder, I get no error message, but the resulting output files are completely black and contain no audio. If I export to Canopus Lossless, the output is correct.

Similarly, I can play the exported Canopus Lossless AVI files in Windows Media Player, but not the Canopus HQ ones. Thumbnails can be created in Windows Explorer for the former, but not the latter.

I don't know what it is, but Canopus HQ doesn't seem to work at all for me outside Edius itself.
 
THoff said:
I too have problems with Canopus HQ, in my case with Procoder Express for Edius.

If I export a sequence using the Canopus HQ codec to a Procoder Express for Edius watch folder, I get no error message, but the resulting output files are completely black and contain no audio. If I export to Canopus Lossless, the output is correct.

Similarly, I can play the exported Canopus Lossless AVI files in Windows Media Player, but not the Canopus HQ ones. Thumbnails can be created in Windows Explorer for the former, but not the latter.

I don't know what it is, but Canopus HQ doesn't seem to work at all for me outside Edius itself.
Click to expand...

I could have mentioned it, no way i export an Canopus HQ and it will work in the ediaplayer..same here....i still have an aspect ratio when i open a lossless file, but i guess this is due to the square pixel-issue of windows media player...Bhiga, any hepl on our codec issues here?

I thought i would love the Canopus HQ(as long as it does from Edius i do...), but it definitly has to work from AE as well without a big quality loss...whats wrong here?
 
Sorry guys, not sure on this. Make sure you haven't loaded the Canopus HQ pack, as that can mess things up by replacing the codec files.

As long as the EDIUS dongle is present, both HQ and Lossless files should decode properly and play back in Windows Media Player (though it will play it assuming square pixels, so the aspect ratio will be incorrect).

What version of EDIUS is everyone running?

Brandon
PS: I'm on vacation, so I won't be popping in regularly.
 
Hey Brandon,

good/bad to hear you are on vacation, ill write anyway how the setting is:
I am using the SP-card with Edius broadcast v.4.1!

Dongle is inside all the time, no extra pack installed, just what came with the SP/Broadcast...thats really an important quetion, as my whole workflow(finally) in post is based on that, well i could use Lossless in exeptions, but mostly i am working with documentary stuff and uncompressed comes up a little heavy...!

What makes me really wonder is the (visible) quality loss when i am exporting a Canopus lossless from After effects....the loss of quality wouldnt be visible like that for generations when i do the same from Edius broadcast.....am i missing somethng here..?
 
I'm using Edius 4 Broadcast V4.13, software-only, with the dongle present at all times. I did not install the decode-only version of the Canopus HQ codec.
 
Hey I'm also having trouble with the HQ codec and After Effects.

If I export Canopus HQ from Edius Broadcast (with dongle) in a project that is DVCPRO HD 720/25p over 50p and then try and import into after effects I get:

"After Effects error: retrieving frame from video stream. (3) (53::34)"

If I use the project template in Edius HDV 720/25p it imports fine into AE with HQ codec.

What's the deal? If I shoot 720PN all the time what project template should I use in edius?

Thanks for your time!
 
Hvx Deutschland, you reminded me of something that I find very annoying with Edius: that one needs the dongle even to playback video rendered with the canopus format. I think that's really rather pesky. I rendered an edit to show some people at work, moved it onto my laptop and did not dream for a second I would need the dongle just to play it back. It was a bit of a slap in the face, and it just multiplies the risk of losing the damned antiquated thing: having to bring it along to play footage remotely.

I'll just stop using the codec.

M.
 
Hey Malcolm,

well it is a specific codec, but thats a problem with quite all the different codecs, and in this case, it is important to me that the codec supports a good quality, thats definitly what Canopus HQ and Canopus lossless do...!

I think you shouldnt quit the codec, its much easyer to solve your problem:
yes you need the canopus playback codec, but not the dongle at all!
So you can download the Playback version on the canopus.com site and bring it with you, or if you forget it, just acces to the internet and download it..!

Try it, itll work...!
 
Just don't install the playback-only version of the codec on your Edius system, or you'll be hosed...
 
..whope..good one THoff...forgot to mention that!
Thanks

Do you guys run AE?
And if yes, 7.0 or lower?
I am just curious if my canopus HQ problem is related to AE 6.5, i will update "soon" anyway..but dont know if this is the key in this case..!
 
What colorspace and colordepth are you rendering to? Some smarter apps ask the codec what it supports, and will only show you want is compatible with your current rendering choices.

For example, if a codec doesn't support RGB, it won't show up if you're trying to render RGB.

Canopus HQ should be Y/Cb/Cr, 24-bit or 32-bit.
 
Well, obviously i have to go into that in detail again..i cant check it here right now, but i dint remember that i changed anything for the colourspace...i am coming from P2/MXF in 720 and SD(dvcpro50) and i receive the same error message in AE as posted from someone here earlyer...so i dont really know where the problem is, but ill try to see it in detail with thte colorspace..!

So Brandon, if i use Y/Cb/Cr, 24-bit or 32-bit in the Canopus HQ settings i should be fine in AE?
Is this what you are saying?
 
hvx_germanboy said:
Hey Malcolm,

well it is a specific codec, but thats a problem with quite all the different codecs, and in this case, it is important to me that the codec supports a good quality, thats definitly what Canopus HQ and Canopus lossless do...!

I think you shouldnt quit the codec, its much easyer to solve your problem:
yes you need the canopus playback codec, but not the dongle at all!
So you can download the Playback version on the canopus.com site and bring it with you, or if you forget it, just acces to the internet and download it..!

Try it, itll work...!
Click to expand...

Thanks!
I'll give that a go, and Thoff, thanks for the warning.

M
 
hvx_germanboy said:
So Brandon, if i use Y/Cb/Cr, 24-bit or 32-bit in the Canopus HQ settings i should be fine in AE?
Is this what you are saying?
Click to expand...
Yes, but it's been a long time since I played in AE...
 
Hmm....so play this baby again...!

I guess there are a lot of people uding it as addition to Edius, specially those who combine it with the NX/SP...so it would be great to get some solution for the Canopus HQ-codec-miracle...ill try my part too and update to AE 7 and see what happens, but i fear that woulnt be the total solution..ill see into the colour settings....!

Apropo Brandon...maybe this is an old hat (1:1 translation from german, couldnt resist..sorry), but what about the "wrong" black-handling of Edius?

Is this due to the fact that the RGB-colour room has to be limited to (13/235) for broadcast colours, or is this something totally different..i am really curious about that one too...!

Sorry for asking so much, but Forum over at canopus.com is closed..and i had a big coffe this morning...geeeesus!
 
Hehehe, "wrong" depends on how you look at it.
The problem lies in the fact that there were two defined methods of converting between RGB and YCbCr.

Remember that this conversion has nothing to do with IRE Setup level. IRE Setup level exists in the analog world and shouldn't affect the digital world (although it sometimes does).

One method assumes RGB values for legal ranges are 16-235, translated to lega YCbCr values (16-240). This method allows for YCbCr values that stray below 16 and above 240, as often happens with digital camcorders. This is the method EDIUS uses, and it provides a more accurate representation of the input because those "superblack" and "superwhite" levels are preserved.

The other method assumes RGB values are from 0-255, and must be translated to legal YCbCr values (16-240). This method allows less thinking on the part of the content creator (they don't have to worry about RGB levels being between 16-235), but it doesn't allow for YCbCr values outside of the 16-240 range.

So, technically either everybody's right, or everybody's wrong.

You can think of it sort of like different dialects in a language. Sometimes different words mean different things. If you know what "dialect" the other person is speaking, you can translate to the proper term in your language. However, if you don't know the other person is speaking a different dialect, you can have misinterpretation.

For example, I speak American English. A friend of mine speaks UK English. In American English, "pants" are trousers, or jeans. In UK English, "pants" means underwear. So, me telling my friend "I really like your pants" means a different thing if he's assuming I'm speaking UK English, than if he remembers that I mean it as American English.

Of course, before I knew the difference, I got a funny look from him.

Likewise, I was on the other end once... A relative of mine grew up in Australia and was visiting doing her homework. She asked me if I had a "rubber." Apparently in Australian English, a "rubber" is an eraser. In American English, a "rubber" is slang for a condom! Needless to say, I was a bit surprised until I figured it out.

Brandon
 
Hey Bhiga,

thanks for taking your time to explain, i really liked the panty-rubber-way to explain it..!

I guess i got it, just asking myself if Edius/PCE is limiting the Ranges when exporting/encoding a clip in the end, or can i pass it and use the levels outside?

I do understand that you wouldnt want to have colours that are outside of the Broadcast values, but sometimes you might want it for streaming video for example, or preserve the whole range to work in a 3rd party app like AE and output the final result the right way in the end...!

How do other programs handle this?

Thanks..like always..!
 
Hey there,

EDIUS works in YCbCr space internally. However, if you render to an RGB format, or you use assets that are RGB, then EDIUS will translate the RGB to YCbCr assuming RGB 0,0,0 = YCbCr 0,0,0, a "straight through" conversion.

Now, two problems creep up:
1) If you have grays that are between RGB 0,0,0 and RGB 16,16,16 when put out to video, they will be "superblack" and can cause problems in broadcast transmission as well as display.
Forcing the 0-16 range to "safe" video values usually simply makes everything <16, 16, so you lose those gray values.

2) If you have whites that are between RGB 235,235,235 and RGB 255,255,255, when put out to video, they will be "superwhite" and can also cause problems in broadcast transmission as well as display. Often times this causes the picture to roll, "bloom" (like a bulging effect), cause colors to smear, and/or causes audio buzzing.


So, how do you handle the "overblack" and "overwhite" ranges, if you want to maintain the perceived differences between black and not-quite black, and white and not-quite-white?

Remember that EDIUS translates RGB to YUV "straight" meaning that RGB 0,0,0 comes in as YUV 0,0,0, so while they're technically not quite the same, for the sake of this explanation we can ignore the difference between RGB and YUV values and look at the numbers alone.

The easiest way to visualize it is to look at the YUV Curve filter in EDIUS.
Click on the Y tab and look at the graph. Normally it's a straight line from lower-left to upper-right.

Now, the X (left-to-right) axis represents the Input Y value. The Y (bottom-to-top) axis represents the Output Y value.

Normally, the Input and Output values are equal, thus you get a line from 0,0 to 255,255.

To clamp 0-16 to 16, we want every input value between 0 and 16 to be output as 16. We do this by first adding a node at 16,16 on the graph (click the 16,16 point). Then we drag the 0,0 node straight up to 0,16.
Now we have a graph that looks like
_/

Notice how the slope (angle) of the line is still the same, except for the flat area. This means that the luma (Y) value of things that aren't Y 0-16, are unchanged. This is important.

The same can be done to clamp white to 235. Add a node at 235,235, then drag the 255,255 node down to 255, 235 so your graph now has a flat part at the top that is a mirror of the bottom.

The "flat" parts show that the difference between "pure black" and "not quite black" is no longer preserved. Anything coming in between 0-15 now goes out as just 16.


The other method is to scale values from the original 0-255 range to the target 0-235 range.

To do this, we start off with the default Y curve again, and simply move the 0,0 node up to 0,16 to adjust black, and move the 255,255 node down to 255,235 to adjust white.

Now instead of having flat areas, we have simply "tilted" the slope (angle) of the line. This means that the difference between what came in as "pure black" and "not quite black" is preserved, but the overall dynamic range is reduced. This means that we're losing some of the difference between adjacent color values.


That as all for the video world. Now going to the RGB world, because EDIUS still translates "straight through" for YUV to RGB conversion, if we output something that's been video-corrected to 16-235 (or originated as safe video) as RGB, we end up with black being RGB 16,16,16, and our black doesn't look pure black.

To handle this, we can scale the input Y range of 16-235 to 0-255 so we get the intended range in RGB.
Take the default Y curve, and drag the 0,0 point right to 16,0, and drag the 255,255 point left to 235,255. This will make all incoming Y values from 0-16 output as RGB 0, and incoming Y values from 235-255 output as RGB 255.


Fun huh? Knowing when to expand/scale the range gets tricky, so a good strategy is to create a straight black-to-white gradient in Photoshop or something else and render it from each of your applications and see what happens in the black and white ranges.
If the ends go "flat" (same color) but don't end up pure-white and pure-black, then your application is clamping the values.
If the ends go "flat" (same color) early but are pure white and pure-black, then your application is scaling the values.
If the entire range is output without change, then your application isn't restricting to safe range by scaling or clamping.

I hope that helps and hasn't utterly confused you...
...and with my luck they're going to change the behavior of EDIUS without telling me so I'm completely wrong...

Brandon
 
You must log in or register to reply here.
Back
Top