[Jus]

Hi Mike

Thanks for the reply

Do you mean that by doing so, I won’t be adding to the compression already there, or that you feel that two compressions are an acceptable limit prior to the final compression at TX?

Cheers

Justin

[Jus]

Hi there

unfortunately that’s not an option! Not sure who it is most unfortunate for…
…as everyone seems to hate blobbing in equal measure!

Especially given that the nature of this load is all handheld_camera_wobbly_as_sin_reality_tv take on crime on the streets stuff. And it would take the editors (or journos) much longer than the gfx bods.

Anyway, we bit the biscuit and did an impromptu house clearance to make space and it’s all done and dusted.

Thanks

Jus

[Jus]

I’m sure it is the culprit. But you’ve given me an idea…

…I will not render a qt.mov, but a targa seq, and take a look at how it imports them.
And then I will also try rendering to the avid codec, and “dragging over” a file, rather than importing.

Thanks

Justin

[Jus]

Hi there

[David Jones] “Are you running the Avid uncompressed or at 5.1 DV compression?”

Well, according to our import options on the unity we’re importing at dv 25 420 PAL. Whatever compression ratio that is – it’s significant(ly crudulous). Everybody’s footage gets ingested thus. I believe I’m correct in thinking I cant place an uncompressed file onto the Unity. Unity, by nature of the dv pipeline, compresses all the media ingested in the same fashion. I am however, rendering an uncompressed file to another “storage area” prior to importing into Unity and the editors assigning a video id for tx.

It’s not as if I haven’t placed some hard, fast, colourful gfx into Unity before, but this particular combination of sat/desat composition has really yeilded some nasty drawbacks to dv compression that have forced me to rethink the design. Now that is a real limitation.

Sulk