Forum Replies Created

  • Rupert Howe

    November 12, 2014 at 11:46 pm in reply to: Media Cache on Shared Network

    Hi Alex,
    Our experience with Io4K too.
    We’ve ended up taking the audio out via line out instead of via card, pending a fix.

    – – –
    Rupert Howe
    Production Workflow Lead
    Support Partners (UK) Ltd at BBC Bristol Digital Village
    https://support-partners.com/

  • Rupert Howe

    November 7, 2014 at 12:59 pm in reply to: Media Cache on Shared Network

    Hi Peter,

    What work did you do? It would be great to know what the optimisations were in technical terms so we can work out if they address the blockers for us keeping media cache db and files on share storage.

    The problem with media cache files on shared storage is often about the shared storage’s ability to deliver the tiny files to the machine. Particularly if optimised for streaming big media files.

    Rupert

    – – –
    Rupert Howe
    Production Workflow Lead
    Support Partners (UK) Ltd at BBC Bristol Digital Village
    https://support-partners.com/

  • Rupert Howe

    September 25, 2013 at 10:47 am in reply to: Adobe CC for a television series!? Workflow thoughts..

    Hi Michael,

    While we’re still mostly using FCP7 in-house here in BBC Bristol, we’re cutting a few things on Premiere CC. We’ve just started cutting a major natural history series with approx 1800 hours of native Red Raw 4K & 5K (approx 250TB). It’s still early days, and we’ll be going for months over several edits – but in week 3, so far so good. The edits are using top spec Mac Pros with 48GB RAM, Quadro 5000 cards and Red Rocket cards, connected to an XSAN via 8Gb fibre.

    With this amount of media, even with proxies, FCP7 would really groan.

    We’ve had other shows that have always used FCP who have used Premiere CC successfully, some in combination with After Effects. These have been using slightly lower spec Mac Pros, and their media is generally mostly Sony XDCAM and Canon XF.

    We had another series that tested with Premiere CC, but had their OB & FCP workflow down so tight that it was hard to see the advantages of switching at the moment. This was complicated by a multicam cutting issue in version 7.0.0 and 7.0.1 that I think will be fixed in 7.1, which affected some editors but not others.

    All these shows have had their media managed carefully before going into Premiere – generally by rewrapping P2 and XDCAM and XF media to native Quicktimes and renaming them. Most of this is still done in FCP Log & Transfer or Sony tools because Prelude & Media Encoder do not have any tools for rewrapping. Native rewrapping to Quicktimes makes each clip into a single, uniquely named file without transcoding – which is easier to manage than a cluster of files locked inside a full complex card structure. This helps subsequent media movement, relinking, consolidation, finishing and archive requests, and because you’re not transcoding there’s no generational quality loss from the native card media.

    Theoretically you take a performance hit with Quicktimes, but we’ve not seen it. If anything, the Long GOP codecs inside Quicktimes seem to work better than in their original card structures.

    Last year we cut a natural history show on CS6 – The Great Bear Stakeout – 2 x 60 mins, with 10 file/camera formats, 5 framerates, mix of 1080 and 720, a total of 800 hours of footage and 25TB of storage. With very little time for preparation, we cut successfully for 90 days, sharing on an XSAN to 5 Mac Pros.

    All the major software issues and feature requests we had in CS6 were fixed in CC.
    Notable issues were: large project sizes (2GB) & related crashing, audio sync issues via external video, long save & load times, autosave failing a couple of times, Long GOP media playback stuttering, project indexing, 3 way colour corrector black input slider not working properly with CUDA.
    Notable feature requests were: lack of track mixer, dupe detection, through edit markers and timecode overlay.
    The only big thing not addressed so far is the lack of GPU acceleration for 3rd party plugins/effects.

    The major workflow things to watch out for, which you should still look out for in CC, were:

    1) Ingest & naming
    We couldn’t rewrap & rename, as described above. They only decided to come in-house to cut on Premiere 2 weeks before the edit. The native media had been logged on drives, and wasn’t named and organised the way we’d have liked. We had to take camera card folders (without rewrapping as described above) and so folders and clips didn’t have unique names. CS6 relinking was so bad that if clips went offline, it would prompt you for “C0001.mxf” without any clue to which of a thousand C0001.mxfs it was, or where the original path was. This is much better in CC. Duplicate card folder names led to a relink & consolidation & export problem at the end – see below.

    On the other hand, doing it this way meant that we imported/ingested all the 25TB/800 hours in a day, after copying it to our XSAN. They’d spent 4+ months transcoding to ProRes Quicktimes for FCP. So that’s a big theoretical saving from FCP. Rewrapping to native Quicktimes and renaming, when we do that, takes a little longer, but is massively quicker than transcoding.

    2) Clip IDs
    We used a master import project to share out projects to all your editors, producers & users. That gives all the clips one unique clip ID, which Premiere will recognise when sharing sequences. Otherwise, you can end up sharing sequences which bring along all their master clips alongside them, making your projects messy and full of duplicate master clips.
    Another tip – also useful for FCP – is to keep your Rushes folders at the top of your bin structure, above the sequences. This helps Premiere check the Rushes for matching master clips in sequences. It’s more useful when importing XMLs, or fixing master/affiliate clip links in FCP.

    3) Frame rate interpreting
    We had 5 different frame rates, all of which have to be manually interpreted to 25fps for our 25fps sequences, using Modify > Interpret Footage. However, this frame rate interpretation seems to get lost at various points – eg by exporting XMLs or sharing Projects. You have to watch out for it – what happened was that editors would sometimes use 24 or 30 or 50 or 60 media in a 25fps sequence, which then had to be fixed by reinterpreting and eyematching. Given that natural history is full of crazy framerates, we have to stay on top of this all the time.

    4) Getting the native media out
    In this case, taking it to Baselight at an external facility was tricky in CS6 because after you consolidate the project, relinking the media at the other end in CS6 was too hard – the relinking is much improved in CC. Another thing that hurt was duplicate naming of the containing folder for camera cards. If you have cards from an XF305 and P2 in this folder structure, for instance:
    20120612 > P2 > 20120612_CARD1 > CONTENTS
    20120612 > XF305 > 20120612_CARD1 > CONTENTS
    Then when Project Manager consolidates your final sequence and copies out the media, Premiere will copy both the P2 and the XF305 clips (and other formats if there are any) into the same folder called 20120612_CARD1, creating a hybrid card folder structure all jammed together inside the CONTENTS folder!

    This is generally not a problem for us, as every file and folder we use is is carefully individually named, but in this case it was a pain.

    As mentioned above, generically named files in native card folder structures are going to be a pain for us too, given the amount of media we manage in the edit and the archive – we’re working on solutions for that.

    5) Audio track export to OMF
    For Great Bear Stakeout in CS6, this was fine – the single unencapsulated OMF with separate audio went into Pro Tools fine.
    For other productions in CC we have had issues with exporting OMFs when stereo and mono files are mixed in standard tracks and crossfades are added between them. Pro Tools wants to make everything mono, and doesn’t like the transitions between these files.
    We tried just using Mono tracks – but unfortunately this means that you have to change levels and effects separately on the left and right channels – you can’t link them.
    We have had other issues with unencapsulated OMFs not linking properly in Pro Tools. But other times when it’s been fine. The solution to this is to export multiple encapsulated OMFs below 2GB, as you have to do in FCP.
    Finally, there’s a weirdness with multicam audio, when preparing for the OMF – when you enable it, the audio can disappear – when you flatten it, it reappears, but sometimes from the wrong camera. We suspect this is to do with the way the multicam source sequence is made in the first place, but have been unable to recreate it reliably.

    6) USB Microphone for Voiceover
    This is a silly ongoing saga. You have to create your own Aggregate Device in Audio/MIDI Setup. Premiere will create its own, but you cannot set the sample rate or drift control in it, and you can get some weirdness. Also, you should set a keyboard shortcut for recording voiceover, so you can press one key instead of clicking 2 buttons.

    I could go on with a list of minor things, but those are the main ones and I’ve already banged on too long. Editors have picked it up with little or no training. We’ve got to the point where the main things they complain about there being no picture of the keyboard in Keyboard Shortcuts, and there being no way to set duplicate keys for the same command, and occasionally losing a key they’ve mapped. So it’s doing its job as a broadcast edit tool.

    There’ll no doubt be things specific to your media and processes which you’ll have to troubleshoot, since they work differently from FCP or Avid. We are testing import, sequences and exports all the time.

    We’ll be testing more with FCPX too – the editors who use it say it makes editing fun again, and we need to do more work on how it fits with our requirements – but once you know what to look out for, we have already shown that Premiere CC can work well as a replacement for FCP7.

    Rupert

    – – –
    Rupert Howe
    Production Workflow Lead
    Support Partners (UK) Ltd at BBC Bristol Digital Village
    https://support-partners.com/

  • Rupert Howe

    May 10, 2013 at 8:31 am in reply to: Adobe Premiere Pro CC for Broadcasters

    Magic Bullet and MB Looks are not GPU accelerated, nor are any third party plugins – so having a CUDA card won’t help. We’ve been using them in CS6 on a top spec Mac Pro (new 3.06 12 Core) with a Quadro 4000 and 48GB RAM and they still need rendering to playback in full res. I believe Adobe have opened up their engine for 3rd party developers to enable acceleration if they want to – but whether they do is up to them. Until then, you have to use the built in Premiere accelerated effects to get real time playback.

    In Premiere CC, though, Adobe have included Speedgrade Lumetri looks built into the effects panel, which basically do what MB Looks does – give you a panel of presets that you can drop on. And they’re all GPU accelerated.

    Talking more generally about CC for broadcasters…
    We cut our first major show on Premiere CS6 – Great Bear Stakeout, which has already been on the BBC and is on Discovery in the US this weekend (the US 2 hour recut was done on Avid, though) – and pretty much everything we learnt that didn’t work has been fixed in CC, because Adobe liaised with us the whole way. Properly amazing support.

    We’re now trialling HD factual formats and 4K natural history shows on CC, and so far the editors and support team have nothing to complain about. People like it more than FCP.

    There are some gotchas to look out for in the workflow when using multiple native formats, sending to grade on another system. Great Bear Stakeout had about 10 different codecs/formats, 5 different frame rates, 25TB/800 hours of media on an XSAN, 2GB projects in three suites. It was a beast.

    So as easy and tempting as it is to throw all those native cards and files into a project and just start cutting, it’s still very important to take the time to think about how you want to ingest and name the media and manage the project sharing. This will make a huge difference to media management in a shared environment, tracking that media in an archive, and avoiding problems with frame rates, interlacing, etc at the end. And stop you getting into a pickle when you share sequences back and forth – if you don’t have a master project, you’ll end up with a lot of duplicate clips.

    For ingest in broadcast environments, it’s still hard to beat FCP log and transfer’s rewrapping of single clips from messy card structures to individual native Quicktime files, with its great naming convention tool. Quicktimes are not Premiere’s file of choice (it has to invoke a 32bit helper app), but they work very well and provide a lot of long term media management and workflow benefits. So I hope Prelude/AME will enable native rewrapping at some point, not just transcoding.

    – – –
    Rupert Howe
    Production Workflow Lead
    Support Partners (UK) Ltd at BBC Bristol Digital Village
    https://support-partners.com/

  • Rupert Howe

    March 30, 2013 at 11:21 pm in reply to: Audio drifting within Premiere

    Does this happen when you create a sequence from a clip – selecting the clip and right click and choose “New Sequence from clip” – if not, that would indicate some kind of problem with your sequence settings. Looking in the Sequence Settings window, you say they’re the same, so they show 1920×1080 29.97fps Progressive?

    I wonder if it’s a problem with the Long GOP codec? We have seen some dropped frames and stuck frames and audio drift with Long GOP codecs in CS6, particularly when intercut with other types of video. (Seems like it might be better in CS7).

    If you tick Show Dropped Frame Indicator in the Program Monitor’s flyout menu, it pops up a little green light, which turns yellow when you drop frames, and shows how many frames are dropped. If it’s dropping frames, that might account for your drifting.

    One way we improve playback with Long GOP codecs when this happens is to create a new Transparent Video clip (File > New > Transparent Video) and stretch that transparent video clip over the top of your timeline on a top video layer. It seems to trick it into playing back better.

    Another way of doing the same kind of thing it is to put an adjustment layer over the top with a small effect applied – like Timecode.

    – – –
    Rupert Howe
    Production Workflow Lead
    Support Partners (UK) Ltd at BBC Bristol Digital Village
    https://support-partners.com/

  • Rupert Howe

    September 30, 2011 at 3:33 pm in reply to: DigiBeta Output has Audio Distortion

    Hi Chris,
    No, ours was just a straight 1080i50 playout, via LHe and Videohub.
    Looking back at the support tickets, we never pinpointed the problem. But after we powered everything down completely (Mac, Deck, Videohub and Legaliser), reset everything (fcp & kona prefs, pram, permissions, etc) and replaced the SDI cables, our client hasn’t seen it again. Not very helpful in pinpointing what fixed it, but it did. That was a year ago. Prior to that it had been regular but intermittent over the summer.
    Best,
    Rupert


    Rupert Howe
    Production Workflow Consultant
    Support Partners (UK) Ltd
    https://support-partners.com/

  • Rupert Howe

    September 3, 2011 at 10:50 pm in reply to: Sorting order in Icon view

    Hi Jim,

    I just replied to Alex in the “Icon view out of order” thread, so I won’t repeat it all here.
    https://forums.creativecow.net/thread/3/913330

    But briefly it seems the only way to control initial order in Icon View is to have the Bin in Icon View before importing – ie putting the files into the desired order before dragging them in.

    Hope that helps,

    Rupert


    Rupert Howe
    Production Workflow Consultant
    Support Partners (UK) Ltd
    https://support-partners.com/

  • Rupert Howe

    September 3, 2011 at 10:42 pm in reply to: Icon view out of order

    Hi Alex,

    Seems that the only way to sort the initial order is to import the clips into the Bin in Icon View.

    ie arrange the clips in whatever order you want them in Finder (or Explorer I guess, though have only tried on Mac) , then set the Bin to Icon View and drag them in.

    Then you can go back to List View and sort them there in whatever order you want, as it works completely independently. When you go back to Icon View, it will keep the order from time of Import.

    As you noted, if you import them in List View, Premiere will weirdly jumble them up when you switch to Icon View – I’m sure there’s some kind of order to them, but I haven’t looked hard enough to see what it is.

    Bit annoying that there isn’t a manual override, and that if you’ve already started using clips that you’ve imported to a Bin in List View, you’d have to reimport them all to make use of the Icon View properly.

    But this is the workaround, I guess. Hope it helps a little!

    Best,

    Rupert


    Rupert Howe
    Production Workflow Consultant
    Support Partners (UK) Ltd
    https://support-partners.com/

  • Rupert Howe

    September 3, 2010 at 2:50 pm in reply to: DigiBeta Output has Audio Distortion

    Ah – as these things do. Thanks!

  • Rupert Howe

    September 3, 2010 at 10:21 am in reply to: DigiBeta Output has Audio Distortion

    Did you ever find a solution or cause for this problem? Having a similar problem with edit to tape on an HDCAM-SR deck at the moment.

    Thanks

    – Rupert Howe

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy