Facebook Live stream Thursday 26th March 4pm GMT/UTC on how to stream to Facebook and YouTube with the Sony PXW-FS5 (also applies to many other Sony cameras with similar streaming options).
I will show you how to connect the camera to a network via Wi-Fi, how to send the stream from the camera to a computer. I will show you how to set up VLC to receive the stream from the camera and then how to use OBS to convert the FS5’s stream (via VLC) and send it to YouTube.
The “How To” live stream will be on my Facebook page: https://www.facebook.com/alister.chapman.9. But if you also have YouTube you will be able to see the stream from the FS5 once it is connected and setup. Links will be shared during the presentation.
Do you have an FS5 and want to stream to Facebook or YouTube? It’s actually fairly straight forward and you don’t even need to buy anything extra! You can even connect a couple of FS5’s to a single computer and switch between them.
How do you do it?
First you will need to download and install two pieces of free software on your computer. The first is VLC. VLC is an open source video player but it also has the ability to act as a media server that can receive the UDP video streams that the FS5 sends and convert them into a live video clip on the computer. The computer and the camera will both need to be connected to the same wifi network and you will need to enter the IP address of the computer into the streaming server settings in the FS5. By connecting the FS5 to your computer via the network you can use VLC to decode the UDP stream . Go to “file” “open network” and click on “open RTP/UDP stream” and enter the computers IP address and the stream port, you should then save the FS5 stream as a playlist in VLC.
OBS is a clever open source streaming application that can convert any video feed connected to a computer into a web stream. From within OBS you can set the signal source to VLC and then the stream from the FS5 will become one of the “scenes” or inputs that OBS can stream to Facebook, YouTube etc.
For multi-camera use a different port for each of the UDP streams and then in VLC save each stream as a different playlist. Then each playlist can be attached to a different scene in OBS so that you can switch. cut and mix between them.
As noted in my previous post there can be some issues with the way ProRes is recorded on many external monitors as a legal range files rather than Data Range.
Another side effect of this is that LUT’s designed for post production as well as most camera LUT’s don’t work correctly in the monitor. So even when you apply the same LUT in the camera as in the monitor the images look different.
To address this I am providing here 2 sets of LUTs for S-Log3 and SGamut3.cine designed to match the built in s709 and 709(800) Luts included in many Sony cameras. These LUTs are specifically for external recorders and should not be used in camera. When you use these LUT’s the pictures on the monitor should now match the the images in the cameras viewfinder when the built in LUT has been applied.
You will find 3 LUTs of each type. One for the base exposure, one for footage exposed 1 stop brighter (minus1) and one for footage exposed 2 stops brighter than base (minus2).
As always (to date at least) I offer these as a free download available by clicking on the links below. Try them before you decide then pay what you feel is fair. All contributions are greatly appreciated and it really does help keep this website up and running. If you can’t afford to pay, then just download the LUT’s and enjoy using them, tell your friends and send them here. If in the future you should choose to use them on a paying project, please remember where you got them and come back and make a contribution. More contributions means more LUT offerings in the future.
I have written about this many times before, but I’ll try to be a bit more concise here.
So – You have recorded S-Log2 or S-Log3 on your Sony camera and at the same time recorded on an external ProRes Recorder such as an Atomos, Blackmagic or other ProRes recorder. But the pictures look different and they don’t grade in the same way. It’s a common problem. Often the external recording will look more contrasty and when you add a LUT the blacks and shadow areas come out very differently.
Video signals can be recorded using a several different data ranges. S-Log2 and S-Log3 signals are always Data Range. When you record in the camera the cameras adds information to the recording called metadata that tells your editing or grading software that the material is Data Range. This way the edit and grading software knows how to correctly handle the footage and how to apply any LUT’s.
However when you record to an external recorder the external recorder doesn’t have this extra metadata. So the recorder will record the Data Range signal that comes from the camera but it doesn’t add the metadata. The ProRes codec is normally used for Legal Range video and by default, unless there is metadata that says otherwise, edit and grading software will assume any ProRes recordings to be Legal Range.
So what happens is that your edit software takes the file, assumes it’s Legal Range and handles it as a Legal Range file when in fact the data in the file is Data Range. This results in the recording levels being transposed into incorrect levels for processing. So when you add a LUT it will look wrong, perhaps with very dark shadows or very bright over exposed looking highlights. It can also limit how much you can grade the footage.
What Can We Do About It?Premiere CC.
You don’t need to do anything in Premiere for the internal .mp4 or MXF recordings. They are handled correctly but Premiere isn’t handling the ProRes files correctly.
My approach for this has always been to use the legacy fast color corrector filter to transform the input range to the required output range. If you apply the fast color corrector filter to a clip you can use the input and output level sliders to set the input and output range. In this case we need to set the output black level to CV16 (as that is legal range black) and we need to set output white to CV235 to match legal range white. If you do this you will then see that the external recording appears to have almost exactly the same values as the internal recording. However there is some non-linearity in the transform, it’s not quite perfect.
Using the legacy “fast color corrector” filter to transform the external recording to the correct range within Premiere.
Now when you apply a LUT the picture and the levels are more or less what you would expect and almost identical to the internal recordings. I say almost because there is a slight hue shift. I don’t know where the hue shift comes from. In Resolve the internal and external recordings look pretty much identical and there is no hue shift. In Premiere they are not quite the same. The hue is slightly different and I don’t know why. My recommendation – use Resolve, it’s so much better for anything that needs any form of grading or color correction.
DaVinci Resolve:
It’s very easy to tell Resolve to treat the clips as Data Range recordings. In the media bin, right click on the clip and under “clip attributes” change the input range from “auto” to “full”. If you don’t do this DaVinci Resolve will assume the ProRes file to be legal range and it will scale the clip incorrectly in the same way as Premiere does. But if you tell Resolve the clip is full range then it is handled correctly.
This comes up again and again, hence why I am writing about it once again.
Raw should never be converted to log before recording if you want any benefit from the raw. You may as well just record the 10 bit log that most cameras are capable of internally. Or take log and output it via the cameras 10 bit output (if it has one) and record that directly on the ProRes recorder. It doesn’t matter how you do it but if you convert between different recording types you will always reduce the image quality and this is as bad a way to do it as you can get. This mainly relates to cameras like the PXW-FS7. The FS5 is different because it’s internal UHD recordings are only 8 bit, so even though the raw is still compromised by converting it to ProRes log, this can still be better than the internal 8 bit log.
S-Log like any other log is a compromise recording format. Log was developed to squash a big dynamic range into the same sized recording bucket as would normally be used for conventional low dynamic range gammas. It does this by discarding a lot of tonal and textural information from everything brighter than 1 stop above middle grey, instead of the amount of data doubling for each stop up you go in exposure, it’s held at a constant amount. Normally this is largely transparent as human vision is less acute in the highlight range, but it is still a compromise.
The idea behind Linear raw is that it should give nothing away, each stop SHOULD contain double the data as the one below. But if you only have 12 bit data that would only allow you to record 11 stops of dynamic range as you would quickly run out of code values. So Sony have to use floating point math or something very similar to reduce the size of each stop by diving down the number of code values each stop has. This has almost no impact on highlights where you start off with 100’s or 1000’s values but in the shadows where a stop may only have 8 or 16 values dividing by 4 means you now only have 2 or 4 tonal levels. So once again this is a compromise recording format. To record a big dynamic range using linear what you really need is 16 bit data.
In summary so far:
S-Log reduces the number of highlight tonal values to fit it a big DR in a normal sized bucket.
Sony’s FSRaw, 12 Bit Linear reduces the number of tonal Values across the entire range to fit it in a compact 12 bit recording bucket, but the assumption is that the recording will be at least 12 bit. The greatest impact of the reduction is in the shadows.
Convert 12 bit linear to 10 bit S-Log and now you are compromising both the highlight range and the shadow range. You have the worst of both, you have 10 bit S-Log but with much less shadow data than the S-log straight from the camera. It’s really not a good thing to do and the internally generated S-Log won’t have shadows compromised in the same way.
If you have even the tiniest bit of under exposure or you attempt to lift the shadows in any way this will accentuate the reduced shadow data and banding is highly likely as the values become stretched even further apart as you bring them up the output gamma range.
If you expose brightly and then reduce the shadows this has the effect of compressing the values closer together or pushing them further down the output curve, closing them together as they go down the output gamma range, this reduces banding. This is one of the reasons why exposing more brightly can often help both log and raw recordings. So a bit of over exposure might help, but any under exposure is really, really going to hurt. Again, you would probably be better off using the internally generated S-Log.
To make matters worse there is also often an issue with S-Log in a ProRes file.
If all that is not enough there is also a big problem in the way ProRes files record S-Log. S-Log should always be recorded as full range data. When you record an internal XAVC file the metadata in the clips tells the edit or grading software that the file is full range. Then when you apply a LUT or do your grading the correct transforms occur and all shadow textures are preserved. But ProRes files are by default treated as legal range files. So when you record full range S-Log inside a ProRes file there is a high likelihood that your edit or grading software will handle the data in the clip incorrectly and this too can lead to problems in the shadows including truncated data, clipping and banding, even though the actual recorded data may be OK. This is purely a metadata issue, grading software such as DaVinci resolve can be forced to treat the ProRes files as full range.
It’s a common problem. You are shooting a performance or event where LED lighting has been used to create dramatic coloured lighting effects. The intense blue from many types of LED stage lights can easily overload the sensor and instead of looking like a nice lighting effect the blue light becomes an ugly splodge of intense blue that spoils the footage.
Well there is a tool hidden away in the paint settings of many recent Sony cameras that can help. It’s called “adaptive matrix”.
When adaptive matrix is enabled, when the camera sees intense blue light such as the light from a blue LED light, the matrix adapts to this and reduces the saturation of the blue colour channel in the problem areas of the image. This can greatly improve the way such lights and lighting look. But be aware that if trying to shoot objects with very bright blue colours, perhaps even a bright blue sky, if you have the adaptive matrix turned on it may desaturate them. Because of this the adaptive matrix is normally turned off by default.
If you want to turn it on, it’s normally found in the cameras paint and matrix settings and it’s simply a case of setting adaptive matrix to on. I recommend that when you don’t actually need it you turn it back off again.
Most of Sony’s broadcast quality cameras produced in the last 5 years have the adaptive matrix function, that includes the FS7, FX9, Z280, Z450, Z750 and many others.
Sony have just released the latest version of their free viewing, copying and transcoding software Catalyst Browse and the more fully featured paid software Catalyst Prepare. These new versions includes support for the PXW-FX9’s metadata based image stabilisation. Hopefully the new Mac versions are also optimised for Catalina.
Sony’s XLR-K3M kit includes an MI Shoe relocation cable.
This is something a lot of people have been asking for. An extension or relocation cable that allows you to place devices that will be connected to a camera via the MI Shoe away from the shoe itself.
But in order to get the MI Shoe relocation cable you have to buy the whole XLR-K3M XLR adapter kit, you can’t get the cable on it’s own. This is a shame as I would like to use the cable with my UWP-D series radio mics. I’m not a fan of having the radio mic receiver right on top of the handle as it tends to stick out and get in the way when you put the camera into most camera bags. But, I don’t really need the XLR adapter.
Anyway, here’s a link to the XLR-K3M for those that really need that cable (or the new XLR adapter).
A completely useless bit of trivia for you is that the “E” in E-mount stands for eighteen. 18mm is the E-mount flange back distance. That’s the distance between the sensor and the face of the lens mount. The fact the e-mount is only 18mm while most other DSLR systems have a flange back distance of around 40mm means thare are 20mm or more in hand that can be used for adapters to go between the camera body and 3rd party lenses with different mounts.
Here’s a little table of some common flange back distances:
This topic comes up a lot. Whenever I have been in discussion with those that should know within Sony they have made it clear that the FS-Raw system is designed around S-Log2 for monitoring and post production etc. This stems from the fact that FS-Raw, the 12 bit linear raw from the FS700, FS7 and FS5 was first developed for the FS700 and that camera only had SGamut and S-Log2. S-Log3 didn’t come until a little later.
The idea is that if the camera is set to SGamut + S-Log2 it is optimised for the best possible performance. The raw signal is then passed to the raw recorder where it will be recorded. For a raw recorder that is going to convert the raw to ProRes or DNxHD the recorder converts the raw to S-SGamut + Log2 so that it will match any internal recordings.
Finally in post the grading software would take the FS-Raw and convert it to SGamut + S-Log2 for further grading. By keeping everything as SGamut and S-Log2 throughout the workflow your brightness levels, the look of the image and any LUT’s that you might use will be the same. Internal and external recordings will look the same. And this has been my experience. Use PP7 with SGamut and S-Log2 and the workflow works as expected.
What about the other Gamuts?
However: The FS5 also has SGamut3, SGamut3.cine and S-Log3 available in the picture profiles. When shooting Log many people prefer S-Log3 and SGamut3.cine. Some people find it easier to grade S-Log3 and there are more LUT’s available for S-Log3/SGamut3.cine than for SGamut and S-Log2. So there are many people that like to use PP8 or PP9 for internal S-Log.
However, switching the FS5’s gamma from S-log2 to S-log3 makes no difference to the raw output. And it won’t make your recorder convert the raw to ProRes/DNxHD as S-Log3 if that’s what you are hoping for. But changing the gamut does have an effect on the colors in the image.
But shouldn’t raw be just raw sensor data?
For me this is interesting, because if the camera is recording the raw sensor output, changing the Gamut shouldn’t really change what’s in the raw recording. So the fact that the image changes when you change the Gamut tells me that the camera is doing some form of processing or gain/gamma adjustment to the signal coming from the sensor. So to try and figure out what is happening and whether you should still always stick to SGamut I decided to do a little bit of testing. The testing was only done on an FS5 so the results are only applicable to the FS5. I can’t recall seeing these same changes with the FS7.
DSC Labs Chroma Tru Test Chart.
For the tests I used a DSC Labs Chroma-tru chart as this allows you to see how the colors and contrast in what you record changes both visually and with a vectorscope/waveform. As well as the chart that you shoot, you download a matching reference overlay file that you can superimpose over the clip in post to visually see any differences between the reference overlay and the way the shot has been captured and decoded. It is also possible to place another small reference chart directly in front of the monitor screen if you need to evaluate the monitor or any other aspects of your full end to end production system. It’s a very clever system and I like it because as well as being able to measure differences with scopes you can also see any differences quite clearly without any sophisticated measuring equipment.
Test workflow:
The chart was illuminated with a mix of mostly real daylight and a bit of 5600K daylight balanced light from a Stella LED lamp. I wanted a lot of real daylight to minimise any errors that could creep in from the spectrum of the LED light (The Stellas are very good but you can’t beat real daylight). The camera was set to 2000 ISO. The raw signal was passed from the camera to an Atomos Shogun Inferno where the clips were recorded as both ProRes Raw and also by using the recorders built in conversion to S-Log2 for internal recording as ProRes HQ. I did one pass of correctly exposed clips and a second pass where the clips were under exposed by 1 stop to asses noise levels. The lens was the 18-105mm kit lens, which without the cameras built in lens compensation does show a fair bit of barrel distortion as you will see!
The ProRes clips were evaluated in DaVinci Resolve using the DaVinci Color Managed workflow with the input colorspace set to S-Log2/Sgamut for every clip and output colorspace set to 709. I also had to set the input range of the ProRes clips to Full Range as this is what S-Log2 files always are. If I didn’t change the input range to Full Range the clips exhibited clipped and crushed black after conversion to 709, this confirms that the clips recorded by the Shogun were Full Range – which follows the S-Log specifications.
I did also take a look at the clips in Adobe Premiere and saw very similar results to Resolve.
I will do a separate report on my findings with the ProRes Raw in FCP as soon as I get time to check out the ProRes raw files properly.
So, what did I find?
In the images below the reference file has been overlaid on the very center of the clip. It can be a little hard to see. In a perfect system it would be impossible to see. But you can never capture the full contrast of the chart 1:1 and all cameras exhibit some color response imperfections. But the closer the center overlay is to the captured chart, the more accurate the system is. Note you can click on any of the capture examples to view a larger version.
This is the reference file (by the time it gets posted on my website as a jpeg I would no longer guarantee the colors etc. But when you look at the images below you will see this superimposed over the center of the clips.
Below is Picture Profile 6 (PP6) SGamut with S-Log2. It’s pretty good match. The camera didn’t quite capture the full contrast of the chart and that’s to be expected, reflections etc make it very difficult to get perfect blacks and shadow areas. But color wise it looks quite reasonable although the light blue’s are a little weak/pink.
SGamut and S-Log2
Below is Picture Profile 7 (PP7) SGamut3 with S-Log3. Straight away we can see that even though the camera was set to S-log3, the contrast is the same in the S-Log2 color managed workflow proving that the gamma of the recording is actually ProRes recording from the Shogun is S-log2, confirming what we already know which is that changing the log curve in the camera makes no difference to the raw recording and no difference to the raw to ProRes conversion in the recorder.
Note the extra noise in the greens. The greens appear to have more color, but they also appear a little darker. If you reduce the brightness of a color without altering the saturation the color appears to be deeper and I think that is what is happening here, it is a lightness change rather than just a saturation change. There is also more noise in the darker bars, grey and black really are quite noisy. Light blues have the same weak/pink appearance and there is a distinct green tint to the white, grey and black bars.
SGamut3 with S-Log3
Below is when the camera was set to SGamut3.cine with S-Log3. Again we can see that the recording gamma is obviously S-Log2. The greens are still a touch stronger looking but now there is less noise in the greens. Cyan and reds are slightly lighter than SGamut and yellows appear a bit darker. This is also a little more noisy overall than SGamut, but not as bad as SGamut3. When you play the 3 clips, overall SGamut has the least noise, SGamut3.cine is next and then SGamut3 is clearly the noisiest. As with SGamut there is a distinct green tint to the white, grey and black bars.
SGamut3.cine with S-Log3
So that’s what the images look like, what do the scopes tell us. Again I will start with SGamut and we can see that the color response is pretty accurate. This suggests that Atomos do a good job of converting the raw to S-Log2/SGamut before it’s recorded and confirms what we already know which is this is that this is clearly how the system is designed to work. Note how the Red strip falls very close to the R box on the 2x vectorscope, yello almost in Y, green very close to G, Blue almost in B. Magenta isn’t so clever and this probably explains why the pinky blues at the top of the chart are not quite right. Do remember that all these test were done with the preset white balance so it’s not surprising to see some small offsets as the white balance won’t have been absolutely perfect. But that imperfection will be the same across all of my test examples.
SGamut + S-Log2
Below is SGamut3. The first thing I noticed was all the extra noise on the right side of the waveform where the greens are. The waveform also shows the difference in lightness compared to SGamut with different colors being reproduced at different brightness levels. The greens are being reproduced at a slightly lower luma level and this is probably why the greens appear more saturated. Also notice how much more fuzzy the vectorscope is, this is due to some extra chroma noise. There is a bit more red and magenta is closer to it’s target box, but all the other key colors are further from their boxes. Yellow and Green and Cyan are all a long way from their target boxes. Overall the color is much less accurate than SGamut and there is more chroma noise.
And finally below is SGamut3.cine. There is less noise on the green side of the waveform than SGamut and SGamut3 but we still have a slightly lower luma level for green, making green appear more saturated. Again overall color accuracy is not as good as SGamut. But the vector scope is still quite fuzzy due to chroma noise.
Under Exposure:
I just want to show you a couple of under exposed examples. These have had the under exposure corrected in post. Below is SGamut and as you can see it is a bit noisy when under exposed. That shouldn’t be a surprise, under expose and you will get noisy pictures.
SGamut with S-Log2 1 stop under (exposure corrected in post)
Below is SGamut3 and you can really see how much noisier this is than SGamut. I recommend clicking on the images to see a full screen version. You will see that as well as the noise in the greens there is more chroma noise in the blacks and greys. There also seems to be a stronger shift towards blue/green in the whites/greys in the under exposed SGamut3.
SGamut3 with S-Log3 1 stop under (exposure corrected in post)
Conclusions:
Clearly changing the gamut makes a difference to the raw output signal. In theory this shouldn’t really happen. Raw is supposed to be the unprocessed sensor output. But these test show that there is a fair bit of processing going on in the FS5 before the raw is output. It’s already known that the white balance is baked in. This is quite easy to do as changing the white balance is largely just a matter of changing the gain on the pixels that represent red and blue relative to green. This can be done before the image is converted to a color image.
What I believe I am seeing in this test is something more complex than that. I’m seeing changes in the luminance and gain levels of different colors relative to each other. So what I suspect is happening is that the camera is making some independent adjustments to the gamma of the Red, Blue and Green pixels before the raw signal is output. This is probably a hang over from adjustments that need to be made when recording S-Log2 and S-Log3 internally rather than something being done to deliberately adjust the raw output. But I didn’t design the camera so I can’t be sure that this is really the case. Only Sony would know the truth.
Does it matter?
Yes and no. If you have been using SGamut3.cine and have been getting the results you want, then, no it doesn’t really matter. I would probably avoid SGamut3. It really is very noisy in the greens and shadows compared to the other two. I would be a little concerned by the green tint in the parts of the image that should be colour free in both SGamut3 and SGamut3.cine. That would make grading a little tougher than it should be.
So my advice remains unchanged and continues to match Sony’s recommendation. This is that you should use PP7 with SGamut and S-Log2 when outputting raw. That doesn’t mean you can’t use the other Gamuts and your milage may vary, but these tests do for me at least confirm my reasons for sticking with PP7.
Both Premiere and Resolve show the same behaviour. Next I want to take a look at what happens in FCP with the ProRes Raw clips. This could prove interesting as FCP decodes and converts the FS-Raw to S-Log3 and SGamut3.cine rather than S-Log2/Sgamut by default. Whether this will make any difference I don’t know. What I do know is that having a recorder that’s converting to S-Log2 for display and software that converts to S-Log3 is very confusing as you need different LUT’s for post and the recorder if you want to use LUT’s for your monitoring. But FCP will have to wait for another day. I have paying work to do first.
Camera setup, reviews, tutorials and information for pro camcorder users from Alister Chapman.
