The main missing professional features in redcine.

[laguun]

I suppose that it might be a good idea to summarize the main requests everyone is getting from their customers, now that r16, sdk and the end of the beta rc shall end.

Functionality:
- EDL support
we are hearing this basically day by day.

Every NLE (be it quantel, discreet, avid, adobe, sony...), every deck (be it tape as hdcam (sr), digital betacam, dvcpro hd/dvcpro, optical as xdcam, solid state as panasonics p2) and every editor uses, understands and knows EDL - redcine doesnt.
that requires
- explaining different workflows, confusing editors
- requires additional tools & investments, which can nullify cost advantages and angers producers
- costs time and nerves, as owners of red have to re-educate every new customer and make them leave methods which are industry standard procedure since decades.

EDL support is already there - in the form of XML. A *totally* basic EDL support would solve >95% of the needs, in and out would do the trick. no speedramps, multitrack, wipes etc are necessary. in/out and dissolve/handle are the 99%.

- Sound
as of now, sound is basically non-existing in rc. synced sound is one of the main advantages digital cinematography has over mechanical cameras and rc removes that.

Quality:
- Hardware compability
As of now, many customers cant use RC as it isnt compatible with many computers. The macbook is a good example, and tons of other graphics, especially the shared memory ones cause issues or simply dont work. Customers blame red as a system for this and then tell fancy strories. If this has to remain
- a check at startup if the GPU fullfills the needs and and dialogue telling "this machine isnt worthy enough" instead of a dark screen would help less computer aware producers/editors etc
- a compatibilty list or a blacklist would help *quite* a bit.

- Software compability
Many important codecs, cineform and avid being sone of the most prominent ones, are clearly not really quality assured or not tested. Limiting is also that often no access to the codec parameters is available. OS support is also still quite limited, as mainly 64bit Houses have to reboot qute often in order to use rc.

- Stability & Bugs
rc is beta, so clearly there are bugs and crashs. However even *easy* bugs (as the redcine reset) are still there and can be solved by 3 lines of script anyone can do. We are getting non-reproducable crashes on many systems with basic functions (as burnin)


besides these basic aspects, there is one main question which remains for me:

is red interested in making rc an excellent solution for red or is it intentionally limited to generate sales for other manufacturers?

If red wants to have its own redcode lab with redcine, then enhanced functionality request would make sense. the main things users are missing in redcine we hear are: framebuffer (hd-sdi) support, more sophisticated colorcorrection (shadow midtones highlight), avi support and stores.

i would *love* to see red entering the DI market. Redcine *is* DI, and a $$$$ redcine pro could be real bestseller.

 

[Gunleik Groven]

RedCine is basically a nonworking and featurelimitited (to the ridiculous) slow (and crashing) preview of an app which I hope is fantastic, but RC isn't very good for Assimilate as a first proof of concept to potential customers.

Even Lucas stated before it was released, that we needed EDL functionality. Then something happened.

Redline/Crimson is a much more powerfull tool, but without the preview. Once Ian releases Crimson with a preview of the color data, I cannot see why anyone would use RedCine again, ever... (If you're not on a PC, that is...)

 

[Sean]

Audio would be sweet.

 

[MichaelP]

While I agree "generally" with EDL support, it is far easier for the NLE to generate the pull list without all the speed ramps, layers, etc. that might or might not appear in an EDL. The XML is pretty straight forward for the pulls then let the conform system deal with the FX metadata.

An EDL to be most useful needs to go back to a database to get all the information about the sources which is basically the pull list. This is the process that Crimson and other solutions are doing.

But.. it is far easier for the NLE to generate its sources that try to work backwards from an EDL. Not that it can't be done as proven by Crimson, just easier... epecially as the timeline gets more complex.

Michael

 

[Mark L. Pederson]

I suppose that it might be a good idea to summarize the main requests everyone is getting from their customers, now that r16, sdk and the end of the beta rc shall end.

Functionality:
- EDL support
we are hearing this basically day by day.

Every NLE (be it quantel, discreet, avid, adobe, sony...), every deck (be it tape as hdcam (sr), digital betacam, dvcpro hd/dvcpro, optical as xdcam, solid state as panasonics p2) and every editor uses, understands and knows EDL - redcine doesnt.
that requires
- explaining different workflows, confusing editors
- requires additional tools & investments, which can nullify cost advantages and angers producers
- costs time and nerves, as owners of red have to re-educate every new customer and make them leave methods which are industry standard procedure since decades.

EDL support is already there - in the form of XML. A *totally* basic EDL support would solve >95% of the needs, in and out would do the trick. no speedramps, multitrack, wipes etc are necessary. in/out and dissolve/handle are the 99%.

- Sound
as of now, sound is basically non-existing in rc. synced sound is one of the main advantages digital cinematography has over mechanical cameras and rc removes that.

Quality:
- Hardware compability
As of now, many customers cant use RC as it isnt compatible with many computers. The macbook is a good example, and tons of other graphics, especially the shared memory ones cause issues or simply dont work. Customers blame red as a system for this and then tell fancy strories. If this has to remain
- a check at startup if the GPU fullfills the needs and and dialogue telling "this machine isnt worthy enough" instead of a dark screen would help less computer aware producers/editors etc
- a compatibilty list or a blacklist would help *quite* a bit.

- Software compability
Many important codecs, cineform and avid being sone of the most prominent ones, are clearly not really quality assured or not tested. Limiting is also that often no access to the codec parameters is available. OS support is also still quite limited, as mainly 64bit Houses have to reboot qute often in order to use rc.

- Stability & Bugs
rc is beta, so clearly there are bugs and crashs. However even *easy* bugs (as the redcine reset) are still there and can be solved by 3 lines of script anyone can do. We are getting non-reproducable crashes on many systems with basic functions (as burnin)


besides these basic aspects, there is one main question which remains for me:

is red interested in making rc an excellent solution for red or is it intentionally limited to generate sales for other manufacturers?

If red wants to have its own redcode lab with redcine, then enhanced functionality request would make sense. the main things users are missing in redcine we hear are: framebuffer (hd-sdi) support, more sophisticated colorcorrection (shadow midtones highlight), avi support and stores.

i would *love* to see red entering the DI market. Redcine *is* DI, and a $$$$ redcine pro could be real bestseller.

well ... I have personally seen a demonstration of stuff Ian is working on and discussed his roadmap for CRIMSON.

REDCINE will be 100% irrelevant and unnecessary.

Red is NOT interested in being a software company.

 

[laguun]

well ... I have personally seen a demonstration of stuff Ian is working on and discussed his roadmap for CRIMSON.
REDCINE will be 100% irrelevant and unnecessary.

So, if i understand you correctly: in your opinion every buyer of red one, scarlet etc will buy a copy of crimson and reds developement of redcine is non-sense?

And crimson will work with smoke, inferno, flame, eQ, pablo, DS, baselight, clipster, nucoda filmmaster, mystika...?

And you think that all these facilities, who are the huge majority of the market will switch to crimson, including television stations?

With all due respect, i have to disagree.

People will use *audio*.
They will use *edls*. As they do with all cameras and NLEs.

Redcine is the "file-VTR" of red. And in its current state, it is a solid limitation to most users of red.

Red is NOT interested in being a software company.

Mark, again, with all due respect, red is already a software company.
And you are not a red employee, so i think its recommendable to let red speak for themself.

Their software products, among them redline, redcine, redalert and redcode quicktime codecs are being used by thousands of facilities and users worldwide.

If your opinion is that red should cancel its softwares, fine.
If you are satisfied with the current redcine, fine.

We, our customers and most of the users we speak to daily have a different POV.
There are few, but mayor, obstacles in the way to allow redcine to be a fully functional part of the workflow chain.

 

[laguun]

While I agree "generally" with EDL support, it is far easier for the NLE to generate the pull list without all the speed ramps, layers, etc. that might or might not appear in an EDL. The XML is pretty straight forward for the pulls then let the conform system deal with the FX metadata.

An EDL to be most useful needs to go back to a database to get all the information about the sources which is basically the pull list. This is the process that Crimson and other solutions are doing.

But.. it is far easier for the NLE to generate its sources that try to work backwards from an EDL. Not that it can't be done as proven by Crimson, just easier... epecially as the timeline gets more complex.

Michael

I agree.
However lets face it - this industry moves rather slow, and tons of legacy systems out there dont use XML. There are countless elder NLE, VFX and DI seats in the world, and the people on these stations are the huge majority of the market - the leading edge is a much smaller portion of the market. And these slower, conservative or even unwilling people so far have no access to reds post.

I have no problem being the "lab" for such people (even ifs a shame to downconvert all the nice red footage to hdcam/digibeta) - in fact its a source of revenue. But many customers *dont* use red as they dont have an easy post workflow. For these people, again, the majority of our industry, EDL will stay.

 

[MichaelP]

While I again "generally" agree about XML, RedCine already has a defined XML export/import schema so that is what I am referring to with the XML support.

Creating the list of selects is easier from the NLE is the main point I am making - whether it is represented as a TAB file, CSV, EDL (pick a flavor) or XML is secondary. Regardless of how complex a timeline might be, the NLE can easily extract the sources compared to an EDL. But EDL's are the line of last defense when everything else fails as long as we can accept the limitations of what they can represent.

At Avid, we have just completed the first step of the XML export from Avid FilmScribe - from there a series of transforms (XSLT files) can be used to extract whatever you need. The XML Masters come in several flavors such as "assemble", "pull", change (between two sequences), etc. One of the XSLT files is the RedCine Pull List format that will go back to RedCine for the next step in the process. The other XSLT is a CMX 3600 EDL, etc.


Michael

 

[laguun]

At Avid, we have just completed the first step of the XML export from Avid FilmScribe - from there a series of transforms (XSLT files) can be used to extract whatever you need. The XML Masters come in several flavors such as "assemble", "pull", change (between two sequences), etc. One of the XSLT files is the RedCine Pull List format that will go back to RedCine for the next step in the process. The other XSLT is a CMX 3600 EDL, etc.


Michael

Excellent news, Michael.
We have 2 fullfeatures productions starting up, editing is beginning august -and both editors want to edit on avid instead of premiere or final cut. Do you think they will be able to use this by then? And - do you have a solution for the audio outside of RC with this new functionality?

EDL support, however, i have to underline that once more - is important for the "usual" crowd - including several of the most successful editors in Germany. As i have the honor and pride to be friend with some of them: they have had several #1 in the german box office but their NLEs are pretty old and they often have the "dont change a winning team" approach regarding their systems. (many are still still using meridien or non-pc-macs).

 

[Dominic Jones]

That sounds great Michael - probably a question you wouldn't want to answer even if you could, but is there any ballpark for the timeframe in which we can expect to go direct from an Avid edit to an RC-based finish?

EDIT: Yeah, it's the obvious question, I guess!

 

[Darren Orange]

If you want EDL support get Scratch Cine, no?

 

[MichaelP]

The v3 release in June will be the first release of the XML. And don't worry, EDL's are not going away. EDL's can still be generated today with the addition of a new "non standard" CMX EDL that allows for 16 characters in the sources so that the full file name can be used to alleviate any errors that might arise from the shorter 4 character name. Any of them can be used since Avid tracks the 4 and the 16 to be used as anyone sees fit. Product design is about anticipating errors and not only "counting on a single way that it must be done or it can't" kind of process.

Of course all of this is dependent on the metadata getting into the system to start, we are tweaking the ReCine to ALE XML as well as working with RED on some other enhanced workflows while waiting for the SDK to be ready for everyone to play with in the summer.

Michael

 

[laguun]

If you want EDL support get Scratch Cine, no?

lol, ok, but the still audio is missing.
17.500 is a slight little bit to expensive for an EDL parser in 2008 - sc is a daily system, and one should add another 8-20.000 for the computer.

Joking aside, for 17.500 i would hire a programmer for an EDL->XML converter, would be cheaper.

 

[laguun]

The v3 release in June will be the first release of the XML. And don't worry, EDL's are not going away. EDL's can still be generated today with the addition of a new "non standard" CMX EDL that allows for 16 characters in the sources so that the full file name can be used to alleviate any errors that might arise from the shorter 4 character name. Any of them can be used since Avid tracks the 4 and the 16 to be used as anyone sees fit. Product design is about anticipating errors and not only "counting on a single way that it must be done or it can't" kind of process.

Of course all of this is dependent on the metadata getting into the system to start, we are tweaking the ReCine to ALE XML as well as working with RED on some other enhanced workflows while waiting for the SDK to be ready for everyone to play with in the summer.

Michael

Michael, june sounds great.

 

[Lucas Wilson]

Audio is coming very soon in SCRATCH and SCRATCH-CINE. And SCRATCH-CINE does a *little* more than "EDL parsing." Here is what one *very* large feature film and one very high-profile television episodic are doing with SCRATCH-CINE to get dailies to Avid. Hopefully, I can say soon which feature and which TV series this is... right now, I'm under NDA. : )

1) Import all R3D material from the day
2) Sort timeline by SourceTC order
3) Add 4 seconds of handles to all shots
4) Remove color metadata from R3D
5) Use a Tangent CP-200BK + K to do a realtime color session for a "one-light" look
6) Apply a 2:35 matte with variable opacity
7) Scale all 4K + 3K shots to 1920 x 1080 (Fit Height)
8) Output to HDCAM-SR (dual-link) and force SourceTC out LTC, so that the timecode on tape equals the source timecode of the R3D files.
9) Output ALE file

So this tape has timecode breaks, but is sorted in ascending order so any clip can be found. Handles are attached so that any editorial system has enough to "grab" before the inpoint. And the Timecode on tape is the source timecode of the R3D files, creating a valid edit master for any system.

At this point, the HDCAM-SR goes into "the machine" for generating all the dailies deliverables. The SR tape then goes to Avid, along with the ALE so they can do a batch digitize, preserving all timecode + ReelID metadata.

Also, the Reel ID of every clip is put into the UserBit fields of the SDI stream, so that can be extracted as well if necessary.

For occasional screener reels, an EDL comes back from editorial, is conformed in SCRATCH-CINE, then output (in realtime) to 720p for the screeners.

So, joking aside, if you can hire a programmer to do all of that for 17,500, you definitely should. Until then, SCRATCH-CINE along with the appropriate hardware is a very affordable and easy way to do RED dailies, conform, and output deliverables.

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA

 

[laguun]

Hey luki,

thats why i wrote that sc is a daily system, not only a edl parser.
17.500 + 8-20.000 for computer would slightly overpriced if edl would be the only feature.

back to topic:
redcine has many unstable and buggy elements - scratch always seemed rather stable.
Is the debugging of redcine debugging done at red or at assimilate, or a joint effort?

 

[GlennChan]

8) Output to HDCAM-SR (dual-link)

There are some nice things about the videotape workflow (e.g. it works, real-time, compatible with many systems out there)... but perhaps the eventual future goal should be a solid data-based workflow.

Not to say it isn't a bad solution right now. But a data-based workflow offers advantages to some people using Red (e.g. you don't need an expensive SR deck, **theoretically** the conform process could be easier/faster without the intermediate tape step, etc.). But the trick is getting it to work...

2- I would agree with laguun in that EDLs do most of what you usually need.

FX done in offline tend to be scratch effects and will need to be redone in online anyways. There is also the other problem in that FX, speed ramps are implemented differently on finishing systems (e.g. some don't even handle speed ramps... you gotta fake it with a number of speed changes).

2b- Just getting the basics done right would be a huge improvement. Frame accuracy on 99.9% shots is possible, but is rarely the case with tape workflows. Scene detection is also nice (which is default in the data workflow; theoretically possible with tape as in DV/firewire, but I don't see wide support for metadata over SDI).

I'd aim for basic stuff first before trying to get fancy with trying to get FX metadata right.

 

[roryhinds]

hopefully with the release of the SDK others will develop R3D processing tools and we'll see a solid workflow with consistent improvement.

 

[laguun]

I'd aim for basic stuff first before trying to get fancy with trying to get FX metadata right.

I fully agree.
General Timecode support (aka EDL) and audio are necessary and basic for most of the jobs.
Stability and compability (especially with codecs ala cineform) are also basic.
These are the standard requirements -bringing an wipe via FX metadata is the exception.

 

[laguun]

hopefully with the release of the SDK others will develop R3D processing tools and we'll see a solid workflow with consistent improvement.

yeah - its sad that over a year has passed and almost all interested players still have to be outside, especially as the existing native redcode solutions are patchworky at best (and none has 4K i/o or 4K realtime).

I really would like to know if red *wants* to improve redcine or want it to be a second class software. It would be so easy to make redcine a lovely tool (add a framebuffer, and be it a still one via aja/bm quicktime, shadows/mitone/highlights colorcorrection and everyone and his soccer mom would use it for real instead as in-between-other-softwares).

And with scarlet, a redcine pro version could become *the* raw colorcorrection starting point for thousands of users, once more underlining reds cool marketchanging paradigm which, so far, sadly, only is true for hardware.