It is currently 28 Jun 2017, 20:01



Another CasparCG Replay/Slow-mo/EVS replacement

CasparCG Server, Client and development

Moderators: Macey, Jonas Hummelstrand, didikunz

Another CasparCG Replay/Slow-mo/EVS replacement

Postby johan_zhe » 06 Nov 2014, 21:56

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
User avatar
johan_zhe
 
Posts: 14
Joined: 30 Jan 2014, 21:06
Location: Hudiksvall, Sweden

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

Postby didikunz » 06 Nov 2014, 23:53

Very cool project.
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
User avatar
didikunz
 
Posts: 3480
Joined: 10 May 2010, 09:08
Location: Aarau, Switzerland

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

Postby Jesper Stærkær » 08 Nov 2014, 09:23

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.
Jesper Stærkær
Independent Consultant at SuperFly.tv
User avatar
Jesper Stærkær
 
Posts: 853
Joined: 13 Apr 2010, 18:06
Location: Trondheim, Norway

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

Postby emisiona » 11 Nov 2014, 10:59

Subscribed! Keep us posted!
User avatar
emisiona
 
Posts: 137
Joined: 27 Jun 2014, 09:45
Location: Barcelona

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

Postby johan_zhe » 15 Nov 2014, 17:38

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
User avatar
johan_zhe
 
Posts: 14
Joined: 30 Jan 2014, 21:06
Location: Hudiksvall, Sweden

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

Postby Jesper Stærkær » 15 Nov 2014, 19:43

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.
Jesper Stærkær
Independent Consultant at SuperFly.tv
User avatar
Jesper Stærkær
 
Posts: 853
Joined: 13 Apr 2010, 18:06
Location: Trondheim, Norway

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

Postby emisiona » 15 Nov 2014, 21:12

He's also capturing the screen for the video. That's also CPU consuming.
User avatar
emisiona
 
Posts: 137
Joined: 27 Jun 2014, 09:45
Location: Barcelona

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

Postby johan_zhe » 16 Nov 2014, 07:37

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
User avatar
johan_zhe
 
Posts: 14
Joined: 30 Jan 2014, 21:06
Location: Hudiksvall, Sweden

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

Postby johan_zhe » 07 Feb 2015, 20:38

I have now released the replay client as open source here: http://nytamin.se/2015/02/07/caspar-replay-download/

Feel free to try it out! :-)
Independent Consultant at SuperFly.tv
User avatar
johan_zhe
 
Posts: 14
Joined: 30 Jan 2014, 21:06
Location: Hudiksvall, Sweden

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

Postby gray1st » 08 Feb 2015, 13:11

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?
gray1st
 
Posts: 69
Joined: 16 Mar 2011, 17:47

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

Postby didikunz » 08 Feb 2015, 14:53

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
User avatar
didikunz
 
Posts: 3480
Joined: 10 May 2010, 09:08
Location: Aarau, Switzerland

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

Postby johan_zhe » 08 Feb 2015, 17:40

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
User avatar
johan_zhe
 
Posts: 14
Joined: 30 Jan 2014, 21:06
Location: Hudiksvall, Sweden

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

Postby aircooled76 » 24 Aug 2015, 05:58

You should be able to read from a .ts h264 file while it is recording...
User avatar
aircooled76
 
Posts: 175
Joined: 14 May 2012, 02:12

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

Postby premultiply » 25 Aug 2015, 16:04

The read-while-write is not a problem of the H.264 (or any other) codec but of the container (.mp4) in this case.
If you use a file format which is designed for such "timeshift" usage like MXF-OP1A, MPEG2 Program Stream or even MPEG2-Transport Stream there should be no problem to read growing files...
premultiply
 
Posts: 69
Joined: 11 Jun 2013, 19:00


Return to Tech and Development

Who is online

Users browsing this forum: No registered users and 7 guests