Edius Pro 4.51C and smart render?

[GrassValley_KH]

Because, as I explained earlier, the Project Settings you are using, is based on bottom-field first for field interlacing - this will always be factored in when rendering out the timeline. This is a separate issue from being able to control any individual clip's interlacing. When you render, it's the Project's settings that become the source properties. Not the clip. This is a facet of being able to edit multiple frame sizes, frame rates and formats together on one single timeline. If we rendered on a clip level, such a multi-format mixed editing concept would be lost.

This again, is why a single-format editor for MPEG (Womble, MPEG Streamclip, Cuttermaran) will champion GOP-based editing over EDIUS.

Did you also confirm the GOP structure as Brandon pointed out above?

EDIUS MPEG encoding GOP structure = IBBPBBPBBPBBPBB

PSG (apparent) MPEG encoding GOP structure = IPPBPPBPPBPPBPP

It may just be a GUI typo. But if that's genuinely what the PSG encoder produces, it too will be a determining factor in why the EDIUS MPEG encoder will force a reencode.

[Neftv]

Because, as I explained earlier, the Project Settings you are using, is based on bottom-field first for field interlacing - this will always be factored in when rendering out the timeline. This is a separate issue from being able to control any individual clip's interlacing. When you render, it's the Project's settings that become the source properties. Not the clip. This is a facet of being able to edit multiple frame sizes, frame rates and formats together on one single timeline. If we rendered on a clip level, such a multi-format mixed editing concept would be lost.

This again, is why a single-format editor for MPEG (Womble, MPEG Streamclip, Cuttermaran) will champion GOP-based editing over EDIUS.

Did you also confirm the GOP structure as Brandon pointed out above?

EDIUS MPEG encoding GOP structure = IBBPBBPBBPBBPBB

PSG (apparent) MPEG encoding GOP structure = IPPBPPBPPBPPBPP

It may just be a GUI typo. But if that's genuinely what the PSG encoder produces, it too will be a determining factor in why the EDIUS MPEG encoder will force a reencode.

Thanks for clarifing.
The GOP structure is correct the GUI interface is reporting it wrong. PSG realizes it's a gui mistake but the the actual file is being recorded properly.
We actually used Womble since we started in the digital world two some years ago. However, issues with womble is when you let Womble re-encode the video degrades so we tried to keep the bit levels the same so we were just using it for clip edits. Even still with Womble there was a duration issue with the final file of always being 2 seconds less. With Edius its more accurate with in one frame to the true time as far is how our Broadcast server reports times. So in otherwords we have a 5min gap in programming in Edius we must edit the program to 4:59:29, in womble we had to edit 4:58:29 in order to get the correct time (5:00) as reported by our PSG broadcast server. So Edius is more accurate to edit especially since some of our interstitials use the very last second for audio.
It's a big plus being able to edit multiformat because that is the other function we use it for. Production makes Quicktime DV files from Final Cut and Edius can take these files in timeline so we can slate them and MPEG them.
Maybe the next handy thing is to allow a Flash 8 plug in that will allow batching so that when the batching is done for MPEG files it can do the batching for Flash files too.
I am still waiting for response back on the field order on the C500. If they are able to change it I wll try it again. Will this have any bad effects to the video itself if the field order on an analog captured source is bottom field first?

[GrassValley_KH]

Will this have any bad effects to the video itself if the field order on an analog captured source is bottom field first?

It shouldn't. Field order issues are typically only a problem when a source is set incorrectly prior to conversion. Since analog is already predetermined (as TFF), there's no possible way you can tell it to be anything otherwise.

[Neftv]

Hi again,
Can I get you guys to look at another file. Its at DRsample.mpg
Please tell me why Edius wants to re-encode that file too? Field order is the same, other specs are the same when I do the print to file. I would expect a 2 min clip to be done in like 20 seconds but its takes about 1.5 mins on a 2 min clip.
I not heard back from PSG on getting Field order corrected on the C500 but this might be moot if an output file from Digital Rapids is the same kind of issue.
Thanks again.

[GrassValley_KH]

That file works ok for me (v4.54) - segment encoder had no problems recognising the file and simply duplicating it.

What I did:

- put the clip onto a fresh new timeline
- Print to file - MPEG (Generic)
- Copied all the settings of the source file, w/ standard quality (unchanged) and Closed GOP
- took maybe 10-12 seconds to export the entire clip

Did the same thing, only with segment encoding deselected - it took 40 seconds to encode the file.

Now, to be extra scientific, I put a new track above the source clip on the timeline, and stuck the segment encoded file above it. Lined them up in sync, and then used the layout tool to zoom both clips up to 1000% - lets you see the telltale artifacts of an MPEG-to-MPEG encode. No sign of any change to the stream at all when toggling the show/hide video switch.

Did the same with the non-segment encoded file and did see a noticable change.

[Neftv]

That file works ok for me (v4.54) - segment encoder had no problems recognising the file and simply duplicating it.

What I did:

- put the clip onto a fresh new timeline
- Print to file - MPEG (Generic)
- Copied all the settings of the source file, w/ standard quality (unchanged) and Closed GOP
- took maybe 10-12 seconds to export the entire clip

Did the same thing, only with segment encoding deselected - it took 40 seconds to encode the file.

Added part....
Did you trim like 5 seconds off the clip then try all that you did?

Now, to be extra scientific, I put a new track above the source clip on the timeline, and stuck the segment encoded file above it. Lined them up in sync, and then used the layout tool to zoom both clips up to 1000% - lets you see the telltale artifacts of an MPEG-to-MPEG encode. No sign of any change to the stream at all when toggling the show/hide video switch.

Did the same with the non-segment encoded file and did see a noticable change.

I'm going to have to digest what you just told me but my initial question is where is version 4.54? We just purchased from B&H and they gave us 4.51C. hmm is that was why the price was so low. Anyway, should we have the lastest version and how?



Added part..
Did you try trimming like 5 secs off the end and then outputing? Same results?

[GrassValley_KH]

There's no cost to upgrade to 4.54, and I definitely recommend you upgrade.

Head over to the GV News forum here and read up on how to get yourself the EDIUS update.

[GrassValley_KH]

I tested a 5 second trim operation.

Same results - Segment Encode = fast (12 seconds), No Segment Encode = slower (45 seconds)

[GrassValley_BH]

Now, to be extra scientific, I put a new track above the source clip on the timeline, and stuck the segment encoded file above it. Lined them up in sync, and then used the layout tool to zoom both clips up to 1000% - lets you see the telltale artifacts of an MPEG-to-MPEG encode. No sign of any change to the stream at all when toggling the show/hide video switch.

Difference Blend keyer is your friend.

[Neftv]

Difference Blend keyer is your friend.

Being new to the software I not familair with that and I was wondering if there was a more detailed explaination in the Reference manual for this. If so what page? Thanks!

[GrassValley_BH]

One of the Keyer types that you can drag onto the Keyer or Mix line (most people use Chroma Key and Picture-in-Picture, forgetting there are others) is the Blend keyers. They work very much like the different layer-blending options in Photoshop.

The Difference blend keyer will show the difference between the current video and what's below it.

For example, if you have NTSC and PAL clips of the same footage, you can see how they differ by putting one on a track above the other, and putting the Difference keyer on the upper track's keyer line.