Edius Pro 4.51C and smart render?

[SRsupport]

works fine I see :)

[GrassValley_KH]

Ok - something I want to try, but I need a sample clip.

Can you try uploading a clip to a file hosting place like http://www.yousendit.com/ or similar? (there's plenty of free file hosting sites online)

Incidentally, you're not able to change the encoder's settings on the C500 system are you? (I'm thinking field ordering)

[Neftv]

Ok - something I want to try, but I need a sample clip.

Can you try uploading a clip to a file hosting place like http://www.yousendit.com/ or similar? (there's plenty of free file hosting sites online)

Incidentally, you're not able to change the encoder's settings on the C500 system are you? (I'm thinking field ordering)

Ok I finally figured out a upload place c500test.mpg
This is a 60 sec test clip recorded from C500 with nothing done to it.
I can only change bit rates and constant or variable and audio sample rate in web interface.

[GrassValley_KH]

Darn. After testing, the discrepancy between source, project and target field ordering is a key. I did a test of just switching the field order and got much faster results (even when not using segment encoding).

It'd be handy to know what (if anything) is done to the GOP structure, during the encode on the C500.

I might pass this on to engineering and they can at least give a definite answer. (although I suspect the likely cause is the field ordering)

[Neftv]

Darn. After testing, the discrepancy between source, project and target field ordering is a key. I did a test of just switching the field order and got much faster results (even when not using segment encoding).

It'd be handy to know what (if anything) is done to the GOP structure, during the encode on the C500.

I might pass this on to engineering and they can at least give a definite answer. (although I suspect the likely cause is the field ordering)

I found out the following
Frames Per GOP: 15
GOP Structure: IPPBPPBPPBPPBPP
GOP Closure: Closed GOP

The reason for Closed GOP and they wont changed it is it suppose to be better for editing.

[GrassValley_KH]

They're correct - Closed GOP is preferred.

Come to think of it, I didn't have that option checked...

EDIT: No, no good. It still reencodes the video.

So, so far the only thing I can do to make it at least operate faster, is to change the field order in the clip's properties.

With that said, doing this can cause adverse effects with some video streams (reversed fields are easy to spot, since they look awful).

Presently, there are no EDIUS project presets that feature top-field first at 720 x 480 (the EDIUS NX D1 profile is 720 x 486 TFF - I tried that and it too, will reencode because of the frame size). I'm reckoning that adding such a preset would solve the issue here. I wish I could be of more help, but it seems that you've caught EDIUS out in this case. :(

[Neftv]

They're correct - Closed GOP is preferred.

Come to think of it, I didn't have that option checked...

EDIT: No, no good. It still reencodes the video.

So, so far the only thing I can do to make it at least operate faster, is to change the field order in the clip's properties.

With that said, doing this can cause adverse effects with some video streams (reversed fields are easy to spot, since they look awful).

Presently, there are no EDIUS project presets that feature top-field first at 720 x 480 (the EDIUS NX D1 profile is 720 x 486 TFF - I tried that and it too, will reencode because of the frame size). I'm reckoning that adding such a preset would solve the issue here. I wish I could be of more help, but it seems that you've caught EDIUS out in this case. :(

Explain to me about Field order.. DV is bottom but when injesting analog audio video its top but that is all I know about it.
Does the right person know about the issue at hand? Do I need to call this in? Maybe the developers can make a preset that I can import? Well that could be useful to others too!!

Does the program mux value difference have anything to do with this too?

Edit...
Why cant there be just a check box for smart encode and basically it just copies the original parameters to the output file? I dont know if that would be good in all instances but for us I think it would be ok.

[GrassValley_BH]

Is the GOP structure really
IPPBPPBPPBPPBPP

and not
IBBPBBPBBPBBPBB

?

[Neftv]

Is the GOP structure really
IPPBPPBPPBPPBPP

and not
IBBPBBPBBPBBPBB

?

Here is how it looks on web interface.

[SRsupport]

Is the mpeg stream encoded at absolute 30fps or it 29.974 marked as 30 fps?

Because I see that it is marked30fps

Steve

[Neftv]

Is the mpeg stream encoded at absolute 30fps or it 29.974 marked as 30 fps?

Because I see that it is marked30fps

Steve

It's definately 29.97. Media info software shows it like that and I had that check by PSG from the beginning.
I have your question inquired to PSG about the gop structure. Sometimes they answer quickly sometimes not on informational things.

[Neftv]

Just an update.
I talked with PSG. It was missed but the program mux rate should be 10.08mbps not pgmMuxRate = 10124800 on the C500. They going to figure out how to change that and get back to me. She was certain that the Mux rate being to high is the issue here not field or gop structure. She seen a simulair problem with ULEAD and smart rendering if the original is to high a mux the software calculates the mux rate. Well we will see and I will get back to you.

[GrassValley_KH]

Explain to me about Field order.. DV is bottom but when injesting analog audio video its top but that is all I know about it.

That's essentially it. In fact, virtually all recording formats use Top field first, with DV being the exception to the rule. In the world of HD, it's all TFF.

Does the right person know about the issue at hand? Do I need to call this in? Maybe the developers can make a preset that I can import? Well that could be useful to others too!!

No need to call in - this is basically an unfortunate limitation of EDIUS - EDIUS project presets must be bound to a hardware-based output format (IEEE 1394, analog, SDI). This has been the methodology behind EDIUS' design from the beginning, mainly because, once upon a time, ingest formats (although moving to digital) were only coming from tape-based devices. In the current world, video streams can literally come from anywhere in all different shapes and sizes.

So, the short answer is 'yes, we're aware of these sorts of limitations and we too, are trying to point this out to the engineers for consideration in future versions' (there's a request thread for free-form project preset control in the appropriate forum).

Does the program mux value difference have anything to do with this too?

Unsure, but I'm still pinning this solely on the field ordering. I'd expect a similar situation to occur if I had used a clip made with the EDIUS MPEG encoder, instructed to use Top Field First. (and then try and reencode it with Segment Encode)

Edit...
Why cant there be just a check box for smart encode and basically it just copies the original parameters to the output file? I dont know if that would be good in all instances but for us I think it would be ok.

Because of the way in which EDIUS exports - it takes whatever it sees on the timeline according to the project preset, when encoding any 'new' material that was modified (say you added a colour correction on a small section of that MPEG file, which will always need encoding).

For Segment Encoding to work, there needs to be a match of source+project+target. Any variation and EDIUS will force a reencode for stream integrity. You don't want a broken GOP structure coming off a mashing of original+new+original MPEG data.

As to why Segment Encoding is 'optional' and not automatically factored in: some applications and mediums are very strict on GOP structure of MPEG streams, and streams that have been constructed with 'smart rendering' type concepts can be reported as illegal MPEG streams. Thus, there must always be a choice.

[GrassValley_BH]

I just don't think EDIUS's MPEG encoders will encode to that GOP structure. It's good for editing, but I've never seen that structure before.

[Neftv]

Yesterday PSG tried to see if mux rate could be changed but apparently it can not. That figure only changes with some ratio to video bite rate. Even still if I made the video on C500 7.7mbps Edius will still re-render the file. If I select top field in Edius the file still gets re-encoded. Today PSG wanted to me try that again setting for top field in Edius and output that way but still it re-renders out. They going to see if they can change to bottom field on the C500. But it sound like it is set correctly since it is taking from an analog source but the files just don't play nice with Edius on the render aspect.
But the question from PSG is why when I set to top field in MPEG preset (in Edius) that it still wants to re-render?