Another CasparCG Replay/Slow-mo/EVS replacement

#1
Hi all!

I want to share with you my current project, it's another take on creating a CasparCG Replay/Slow-mo/EVS replacement. I've been following the other thread (http://casparcg.com/forum/viewtopic.php?t=1310) for a while, but I wanted to try a different solution.

My approach is to record to h264-coded video-files, and then later read from the files, at a different time. The obvious problem with using h264-files is that you can't read from them at the same time as you're writing to them, so I've solved that problem by keeping track of which files (time-periods) that are currently in writing, and when we need to access one of these, we abort the recording to that specific file and begin recording on a new file. Now the first file is free to be read, and all is well.

I'm able to record 4 channels and play back 1, in 720p25, using only a good cpu-powered PC and a mechanical hard-disk (not an SSD!).

Please read my blog-post about it (http://nytamin.se/?p=349) and tell me what you think. I'm planning on releasing the controller (it's programmed in Flash) as open-source later on.
Independent Consultant at SuperFly.tv

Re: Another CasparCG Replay/Slow-mo/EVS replacement

#5
jespers wrote:Is your SEEK-method working smoothly? Can you provide a videoclip of a slowed clip? My experience is (tried this before) that the network calls stack up and reduces your respons on controlling the clip.
My experience is that this problem is highly dependent on how good your system is. Today I tried to use an SSD for storage and that further increased the responsiveness of Caspar.

I made a short recording of the program in use here: http://nytamin.se/?p=359
Independent Consultant at SuperFly.tv

Re: Another CasparCG Replay/Slow-mo/EVS replacement

#8
jespers wrote:I guess most of your CPU usage comes from the screen consumers. Hardware monitors on inputs, and decklink consmer as the only output would probably decrease the CPU usage by a lot.
emisiona wrote:He's also capturing the screen for the video. That's also CPU consuming.
I made a test just now, to see how much the different functions in caspar impacts the cpu load: http://nytamin.se/?p=365.

It seems that the screen consumers does indeed affect the cpu load quite a lot, just by closing the actual windows the cpu load goes down:

With windows (screen consumers) open:
idle: 20% cpu
play input video on 4 channels : 44% cpu
record on 4 channels + playback on 1 channel: 55% cpu
play slowmo (continously seeking): 65% cpu


Without windows (screen consumers):
idle: 12% cpu
play input video on 4 channels: 19% cpu
record on 4 channels + playback on 1 channel: 31% cpu
play slowmo (continously seeking): 49% cpu
Independent Consultant at SuperFly.tv

Re: Another CasparCG Replay/Slow-mo/EVS replacement

#10
Hi Johan

I love this EVS / Replay function.. Brilliant! I've been playing around with it since being able to download it (the link on your wordpress site doesnt work by the way).

I've set my system up to record from your fake.mp4 file, and that seems to work, however as you encountered whatever it is doing seems to crash Caspar, even with two consumers (one input, one output). I am only running this on my laptop, i7 8Gb so i don't think it was a performance issue.

Additionally when it did crash, it was looking for 'ffmpeg_input[media\\CREPLAY\fake.mp4)] Seeking: 0' with 2 x \\ in the URL, is that correct?

Does anyone have any ideas why it would crash more often when trying to use the slow mo function?

Re: Another CasparCG Replay/Slow-mo/EVS replacement

#11
gray1st wrote:Does anyone have any ideas why it would crash more often when trying to use the slow mo function?
I would guess it takes a lot of demand to the Server, it is not really made for this. So it's cool, that it works at least part time :)
Didi Kunz
CasparCG Client-Programmer, Template Maker & Live CG-Operator
Media Support, CH-5722 Gränichen, Switzerland http://mediasupport.ch/
Problems? Guide to posting Bug reports & Feature requests

Re: Another CasparCG Replay/Slow-mo/EVS replacement

#12
gray1st wrote:[...] however as you encountered whatever it is doing seems to crash Caspar, even with two consumers (one input, one output). I am only running this on my laptop, i7 8Gb so i don't think it was a performance issue.

Additionally when it did crash, it was looking for 'ffmpeg_input[media\\CREPLAY\fake.mp4)] Seeking: 0' with 2 x \\ in the URL, is that correct?

Does anyone have any ideas why it would crash more often when trying to use the slow mo function?
I think that "media\\CREPLAY\fake.mp4" is correct, the actual command sent from the client is "PLAY 2-10 "CREPLAY/fake" LOOP" which is correct.

When I'm running it, Caspar typically crashes about 1 time/hour during intense use.
Caspar isn't really meant to be able to handle 25 SEEK commands/second I guess..
Independent Consultant at SuperFly.tv