Layer Producer for Layer Preview

[cambell-prince]

Hi,

I'd like to be able to view a preview of each layer before the mix is applied. Is this possible? It doesn't appear so at the moment.

Once way to do this would be to add a 'layer producer' along the lines of the channel producer which is used for the channel grid. The stage would sent the frame off to registered layout consumers which would add to the queue of the layout producer. Then you could do a MIX ... GRID ... on the channel that has the layout producer and see the input layers pre mix.

Is this an ok technical solution? Or are there problems with this approach? Is there a better way that you would recommend? I'm interested in architectural thoughts before implementing.

Regards, Cambell

[tjenkinson]

Sounds really useful. I think it's quite similar to an issue I already opened a few weeks ago: #103

[cambell-prince]

I've got two commits that implement a layer_producer here:

https://github.com/cambell-prince/Server/commits/layer_producer

Its working, but it does the copy in the same thread as the stage. Not sure if that's necessary or not. In some way its related to the freeing of the host buffer which is used in write_frame::commit(). Any devs may want to see the changesets for details.

[cambell-prince]

Well, turns out that's not actually copying the frame. It is the same texture binding. How can we make a copy of the frame after the host buffer is committed?

Some ideas:

• Keep the image data around in the write_frame.
• Copy the ogl texture elsewhere in a write_frame copy so that we can really copy write_frames.

[ronag]

Why copy it? Just reuse the same texture reference...

[cambell-prince]

@ronag What I've got at the moment shares exactly the same frame. This results in the frame on the other channel being scaled / having blends / geometry applied as if it where the source channel. So, if I take your meaning correctly, you're saying I can make another frame, but reference the original texture rather than copy.

[ronag]

Yes, extract the inner most frame (without transformation) or the device_buffer and just use that. No need to round trip to the cpu.

[cambell-prince]

@ronag Thanks! That's working fine now.

Anyone have an opinion on AMCP syntax? Currently I've got something like this:

COPY 1-2 3-4

This copies to channel 1, layer 2, from channel 3 layer 4.

[ronag]

I've called this feature "REROUTE" in other implementations. I think Thomas had a good name for it though.

[tjenkinson]

Could it be "3-4" or "COPY 3-4" so it would be used like:

LOADBG 1-2 3-4 auto or LOADBG 1-2 COPY 3-4 auto

Also would it be possible to copy all layers on a channel like LOADBG 1-2 COPY 3 auto

Really glad someone's had time to implement this because I think it will come in incredibly useful. Thanks!

[TomKaltz]

@ronag I think ROUTE or REROUTE are good names but how does a client keep track of all this? What sort of status is given in OSC to denote a duplicate layer?

Thomas R. Kaltz III

(586) 214-7150 cell (866) 855-6350 fax

On Mon, May 20, 2013 at 11:26 AM, Tom Jenkinson notifications@github.comwrote:

Could it be "3-4" or "COPY 3-4" so it would be used like:

LOADBG 1-2 3-4 auto or LOADBG 1-2 COPY 3-4 auto

Also would it be possible to copy a while channel like LOADBG 1-2 COPY 3 ?

Really glad someone's had time to implement this because I think it will come in incredibly useful. Thanks!

— Reply to this email directly or view it on GitHubhttps://github.com/CasparCG/Server/issues/125#issuecomment-18153563 .

[czechtech]

Would an alpha channel be separately route-able? It would address ideas like this: http://casparcg.com/forum/viewtopic.php?f=3&t=1473

[TomKaltz]

Currently no. Although you can use the MIXER KEYER function with a white texture to imitate what you need.

http://casparcg.com/wiki/CasparCG_2.0_AMCP_Protocol

Search "MIXER KEYER"

it would be something like...

PLAY 1-0 CLIPNAME PLAY 2-0 1-0 (route layer 1-0 to layer 2-0) PLAY 2-1 WHITE (white texture) MIXER 2-0 KEYER 1 (use alpha of rerouted channel to shape white texture)

[TomKaltz]

Also I propose to simplify AMCP syntax for this feature as recommended by @ronag

PLAY 2-0 1-0 LOADBG 2-0 1-0

Unless everyone thinks that a verbose token is needed for this feature?

[hummelstrand]

I'm always in favor of being verbose over having to have a definition that explains the syntax. But I also like capital letters in the beginning of name, and other such un-Unix-like, human, conventions. :)

[ronag]

hummelstrand: I think "PLAY 2-0 1-1" is something someone who didn't read the docs would try :).

[cambell-prince]

With a syntax like PLAY 2-0 1-1 there is nothing that actually indicates what will be played. That has to be inferred from the resource name, in this case 1-1. Now I do understand that its not that ambiguous, but for example you cannot load a file called 1-1 for example. In the usb camera feature I introduced uri like syntax dshow://somecamera or file://some file or rdp://some stream. I propose layer://1-1 (and I'll infer 1-1 to also be a layer if you like).

[tjenkinson]

I like this idea. Maybe the others should be changed as well to make everything consistent so playing a file would be file://video, colour would be color://#ffffff etc. Not sure how this would work with backwards compatibility though.

[ronag]

I don't think layer://1-1 is a good idea, what about rerouting a channel? channel://1? Seems a bit more complicated than it has to. layer://1, ambiguous and confusing. What about route://1-1, route://1, or clone:// or pipe:// or something else that would work for both layer and channel.

[cambell-prince]

Sounds good to me. I really must remember to stick to verbs for this sort of thing. I'll go for route as it is consistent with what was advised above.

[cambell-prince]

Implemented in #135