Announcement

Collapse
No announcement yet.

Edius Pro 4.51C and smart render?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GrassValley_BH
    replied
    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.

    Leave a comment:


  • Neftv
    replied
    Originally posted by GrassValley_BH View Post
    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!

    Leave a comment:


  • GrassValley_BH
    replied
    Originally posted by GrassValley_KH View Post
    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.

    Leave a comment:


  • GrassValley_KH
    replied
    I tested a 5 second trim operation.

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

    Leave a comment:


  • GrassValley_KH
    replied
    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.

    Leave a comment:


  • Neftv
    replied
    Originally posted by GrassValley_KH View Post
    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?
    Last edited by Neftv; 01-31-2008, 08:39 PM. Reason: Added a question.

    Leave a comment:


  • GrassValley_KH
    replied
    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.

    Leave a comment:


  • Neftv
    replied
    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.

    Leave a comment:


  • GrassValley_KH
    replied
    Originally posted by Neftv View Post
    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.

    Leave a comment:


  • Neftv
    replied
    Originally posted by GrassValley_KH View Post
    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?

    Leave a comment:


  • GrassValley_KH
    replied
    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.

    Leave a comment:


  • Neftv
    replied
    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?

    Leave a comment:


  • GrassValley_BH
    replied
    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.

    Leave a comment:


  • GrassValley_KH
    replied
    Originally posted by Neftv View Post
    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.


    Originally posted by Neftv View Post
    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).


    Originally posted by Neftv View Post
    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)


    Originally posted by Neftv View Post
    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.

    Leave a comment:


  • Neftv
    replied
    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.

    Leave a comment:

Working...
X