CasparCG / server

CasparCG Server is a Windows and Linux software used to play out professional graphics, audio and video to multiple outputs. It has been in 24/7 broadcast production since 2006. Ready-to-use downloads are available under the Releases tab https://casparcg.com.
GNU General Public License v3.0
912 stars 268 forks source link

Layer Producer for Layer Preview #125

Closed cambell-prince closed 11 years ago

cambell-prince commented 11 years ago

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 commented 11 years ago

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

cambell-prince commented 11 years ago

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 commented 11 years ago

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:

ronag commented 11 years ago

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

cambell-prince commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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

tjenkinson commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

cambell-prince commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

Implemented in #135