Signal loss from RF cameras causing recording stop/start on 3P1

B

Bill Farrant

New member
One of our locations last year upgraded from the 425 to 3P1. We run our program into 1 input, 2 SDI cameras into inputs 2 & 3, and an RF SDI camera into the 4th input.

We have never had any problems with the 425 but the 3P1 has a problem with accepting the input from the RF camera. When there is signal break up on the RF the 3Play unit will stop and start recording - and when the signal gets really intermittent the unit will stop/start repeatedly until the signal improves. I have found a bit of a workaround by running the SDI signal from the RF camera into our switcher and feeding the signal out of an AUX output to the 3P1. The switcher substitutes black when signal loss occurs keeping the 3P1 happy most of the time but not reliably enough to completely rid us of the problem.

Recently we installed a 3P1 in another of our locations and have the exact same problem.

This didn't happen with the 3Play 425 units, they happily recorded whatever they were being sent. I have tried multiple software versions on the 3P1 with no difference in their performance.

Has anyone else experienced anything like this, and do you have any suggestions?

Thanks
 
Something to check. On the 3P1 the video inputs are set to 'auto detect' by default. Perhaps try forcing them to the video format being used to see if that helps.
 
This Post is very timely, as we have had similar issues with wireless cameras switching off to change batteries and/or loss of signal on the 3Play 4800 last weekend.

The 3Play 4800 appears to record Black with timecode for approximately one frame in each second. We performed tests today to understand what was happening with those 3Play channels with wireless cameras as the input, and switching off the camera (simulating a battery change or loss of signal reception).

The outcome is that the eight iso recordings (removable drive packs) cannot be placed on an external editing software timeline for synchronized post production editing. This is a disastrous situation.

The 3Play operator also noted that on those channels where the wireless cameras were being used, and the signal lost, that marking the IN or OUT points to create a Cliplist clip, did not always accurately reflect the timecodes on the 3Play Cliplist IN/OUT columns. The only way to accurately create wireless camera clips was to take the erroneous clip into a new Playlist and adjust the IN/OUT points accordingly, and export the Playlist clip to the Cliplist. I saw this problem whilst on air, and the 3Play operator correcting the clip/s manually in the Playlist. Puzzling behaviour by the 3Play.

Furthermore, if the A and B channels are linked, and one of those channels is a wireless camera source which has lost signal, the synchronous playback cannot be guaranteed. The operator must manually resync the playback channels.

Surely the 3Play mutes the video input and inserts black and continuous timecode for the duration, when no video signal is present at the inputs while the device is recording?

Another clue to the above issue, is that when the new session was created on the 3Play, using re-formatted 4 x 2TB drives, there were no files present on those drives prior to starting the session. The overall duration of the telecast was approximately twelve hours. One would have expected the eight 3Play media files to be the same data size. They were not, indicating a problem with those 3Play channels with the wireless cameras whose video signals were occasionally lost.

The bottom line: If there is no video signal at an input, the 3Play shall record continuous black, and continuous timecode for the duration of loss of signal.
 
kanep said:
Something to check. On the 3P1 the video inputs are set to 'auto detect' by default. Perhaps try forcing them to the video format being used to see if that helps.
Click to expand...
I've been discussing this issue with Engineering and QA, and would like to hear back whether this suggestion was effective or not.
 
SBowie said:
I've been discussing this issue with Engineering and QA, and would like to hear back whether this suggestion was effective or not.
Click to expand...

Thank you Steve. No, I have tried that long ago and it makes no difference.

We are sending it 1080i59.94, and I have tried auto, selecting the appropriate video format, turning frame sync on and off, sending it a genlock. Nothing seems to result in any apparent difference. As I mentioned in my original post the only luck I have had is sending the RF signal through our switcher and taking it off an Aux feed. The switcher substitutes black during a signal loss - but not reliably to totally satisfy the 3P1. However, it helps enough that we can at times get through a whole 4 hour production with no problems without an incident - if we feed the signal directly into the 3P1 we will have the stop/start issue dozens of times.

As I said, it was never an issue with our 425's. As much as I love these 3P1's I'm starting to wish we hadn't upgraded.

Thanks for you time.
 
kanep said:
Something to check. On the 3P1 the video inputs are set to 'auto detect' by default. Perhaps try forcing them to the video format being used to see if that helps.
Click to expand...

Thanks Ken, I replied regarding this to a post from Steve - I'm too lousy at typing to do it here too.
 
Thanks to Ken for the suggestion on the 3P1. I tried a similar idea with the Processing On/Off switch amongst other things to see if I could solve the problem with the 4800, but with no success. Though the 4800 does not stop the recording overall, the issue remains with those 4800 channels that have wireless cameras attached and the loss of RX signal or are powered down to change batteries.

The question remains, does the 425 and 4800 have a frame synchronizer at the input of each channel, and does it mute to video black with continuous timecode until a valid SDI signal is received? If so, then the 3Play recordings for each channel should be equal in duration and file size, irrespective of the each channel’s SDI signal state.

I was always under the impression that the Tricaster had this facility for Iso Recording, but perhaps this is incorrect.

Thanks to Steve for raising this issue with Newtek Engineering. Look forward to their response.
 
Bill Farrant said:
Thank you Steve. No, I have tried that long ago and it makes no difference.
Click to expand...
Well, thanks for trying. The reason it seemed worth the effort is that part of the problem you're having with unstable signals devolves from the fact that when a source reconnects, the system doesn't really 'know' that it's the same one that was connected previously. This being so, a re-negotiation has to happen (since it can't be safely assumed that the ostensibly 'new' source has the same characteristics as its predecessor).

Bill Farrant said:
As I mentioned in my original post the only luck I have had is sending the RF signal through our switcher and taking it off an Aux feed. The switcher substitutes black during a signal loss - but not reliably to totally satisfy the 3P1.
Click to expand...
Yeah, you can see why this would make a difference since, despite dropouts, the consistency of the switcher output would make the source seem uninterrupted to the 3Play.

Editec said:
The question remains, does the 425 and 4800 have a frame synchronizer at the input of each channel, and does it mute to video black with continuous timecode until a valid SDI signal is received? If so, then the 3Play recordings for each channel should be equal in duration and file size, irrespective of the each channel’s SDI signal state.
Click to expand...
I'm not sure whether these units employ per input frame sync, but I assume they do. The rest does not necessarily follow though, because the system cannot assume that an interruption is accidental. There are, I'm sure, additional complexities to be considered, including things like handling timecode breaks, the possibility of source format changes, and more.

(Just as a niggle, if we were to posit a system where hitting record ensured a perfectly synced 'matched set' of recordings that could not be interrupted individually come hades or high water until they were all deliberately stopped at one time, it would still be unlikely that they would all have the identical file size ... duration yes, size no (MPEG2 being what it is).

Editec said:
I was always under the impression that the Tricaster had this facility for Iso Recording, but perhaps this is incorrect.
Click to expand...
Like so much these days, it's somewhat correct. Without getting into minute detail, recordings captured downstream of the switcher are pretty much guaranteed to match - even if the sources captured start or stop, change, or are of different formats. However, ISO recordings are captured immediately upon input, ahead of the Switcher - effectively 'raw' (small r) and unprocessed - and thus an interruption or format change will cause the file to be 'chopped'.

I wish I could stay with this until we drill down to the most minute level of detail and fulfill any part of improving these matters that is practical, but I really can't. The best approach, then, is to file exquisitely detailed Fogbugz cases. The key to productive bug reports, imho, often relates to clearly explaining the problem and why it's important, rather than spending much effort on hypothetical causes or solutions. Very often it takes massive amounts of time for engineers to explain the complexities involved in a matter, where what is really needed is for them to clearly understand why it matters.
 
Appreciate the prompt reply Steve.

Could you ask the engineers if the recordings on the 3Play 435/4800 are constant or variable bit rate MPEGII i-Frame.

And also confirmation from the engineers whether these units employ per input frame sync, or sometimes referred to as field synchronizers.

I would expect and have observed that once the User sets the input format (ie. SDI 1080i50), changing that input’s source signal format will not yield any video pictures. This is a fixed 3Play preset and must be done prior to the commencement of recording. That said, if the input video is lost and an input frame sync is in use on that channel, then the resulting recorded video would/should be either video black (ie. SDI 1080i50) or the last valid video frame of the source input (as a freeze frame). Then the recording would continue as it should, uninterrupted with black or freeze frame and with uninterrupted timecode. Once a valid digital signal is returned, the video muting would be disabled automatically. This is typical behaviour of most computer based and hardware based digital video recording systems.
 
Editec said:
Appreciate the prompt reply Steve.
Click to expand...
I should probably mention something that seems to bear repeating now and again, which is that no-one should really view these forums as "NewTek Support". Without getting into it too much, the forums comprise our effort to support 'community'. he forums often provide a valuable resource that includes a large body of experience, but official product support is largely done elsewhere. A few staffers lurk in here for various reasons, but as such mostly consider ourselves just part of the community while in here (in fact most of us were just that long before joining the company).

I mention this because we would not want anyone to imagine that asking about an issue here comprised a bug report, or guaranteed that anyone at NewTek even saw it.

Editec said:
Could you ask the engineers if the recordings on the 3Play 435/4800 are constant or variable bit rate MPEGII i-Frame.

And also confirmation from the engineers whether these units employ per input frame sync, or sometimes referred to as field synchronizers.
Click to expand...
So, to build on what I wrote previously, in here as elsewhere in life, I try to avoid becoming becoming 'the string between two tin cans' (this reference may be lost on millenials?). While engineers don't respond directly in here much, they live and breath Fogbug cases, and it's best to take anything complex there, in order that they can ask detailed questions, and (more occasionally) offer detailed replies.

This said, TriCaster's files are VBR, and I suspect that's true for 3Play, but in any case it would be very easy to confirm by looking at one with MediaInfo.

Editec said:
I would expect and have observed that once the User sets the input format (ie. SDI 1080i50), changing that input’s source signal format will not yield any video pictures. This is a fixed 3Play preset and must be done prior to the commencement of recording.
Click to expand...
To be a bit pedantic, while session format is established in the Session (admin) screen on startup, I do not think you are locked out of the input setup options while 'live'. That said, I spend a lot less time with 3Play than I do with TC, and you may be correct that this can't be modified on the fly, I'm not 100% sure. Either way, a case could be made for locking this down once capture begins, and there may well be other ways to go. Again, I'd recommend a Fogbugz case.
 
I'm going to post some feedback I got from the 3Play devs re: items discussed in this thread, as general info:

  • Engineering is working on a release that will prevent recording chops that result from losing then re-acquiring an SDI source ... not quite there yet, but almost.
  • Regarding the notion that you can drop eight 3Play recordings into a NLE and all of them will be synchronized: this would be true only when all 8 cameras are genlocked (it seems very unlikely that wireless cameras are genlocked).
  • If you need to write black to disk when an SDI signal is lost, selecting an analog audio source for each input can do this (I am not really sure, but this may require the upcoming release).
 
You must log in or register to reply here.
Back
Top