In Office Communications Server 2007 and Lync Server 2010 the usage of high definition video was straightforward. The Real-Time Video (RTV) codec used primarily throughout those client and server versions provides for only a single HD resolution at 720p and was utilized in very specific scenarios, as documented in this previous article.
But with the inclusion of H.264 SVC as the default video codec for Lync 2013 this story changes quite drastically. Foremost there are additional resolutions available in this new codec which provide more options then RTV did, which can actually help soften the importance of high definition video in terms of the user experience anyway, especially in multi-party conference calls. The way that the Lync 2013 user interface was designed provides for high quality, face-to-face video conferencing experience which does not always need to scale up to true ‘high’ resolutions to get the job done.
Throughout this article the term ‘SVC’ will be used to describe behavior related specifically to the implementation of H.264 SVC in Lync 2013 and these concepts and rules do not necessarily apply to the Scalable Video Coding standard.
There is some gray-area in the industry in terms of clarifying exactly what high definition actually means in relation to video. Although there is no actual definition, generally throughout North America it is understood as “any video image with more than 480 horizontal lines”. Throughout the television industry this means resolutions with a height of 720 pixels or higher and this was reflected in RTV when moving between the only standard resolution choice (640×480) and high definition choice (1280×720). But SVC introduces a number of new resolutions including one that falls right between these others: 540p (960×540). By definition this resolution could be considered to be high definition, except for in the television industry. So what is important to understand is that the resolution itself is much less important in SVC due to the variety of supported resolutions (15) versus what RTV provided in the past (5). If a caller looks clear on video and the experience is good then what does it really matter if the resolution in use is 540p or 720p? The point is that the larger list of resolutions available in SVC provides a more granular experience when different resolutions are requested, which is much improved over the older experience of bad/good/great seen in RTV.
Hardware Requirements
The Lync 2013 client contains some hard-coded behavior when using H.264 SVC which determines the maximum video resolutions and frame rates that a given workstation can send and receive. Unlike with RTV this criteria is more complex due to additional features provided by the new SVC codec’s implementation.
Microsoft has also provided much more detail in on how this actually works in Lync 2013. With RTV there was a generic guideline that ‘4 process cores’ were required for OCS or Lync clients to send and receive RTV at 720p resolution. But because SVC in Lync 2013 leverages hardware acceleration then the workstation incapable of utilizing HD with RTV may be capable of sending and/or receiving higher resolutions with SVC.
The Lync Client Video Requirements page in TechNet outlines how SVC leverages different hardware capabilities for video encoding and decoding. There are four primary categories which are used to decide the maximum capabilities of a given workstation:
- Hardware accelerated decoding (DXVA)
- Hardware accelerated encoding (GPU, Camera)
- Physical CPU cores
- Windows Experience Index (WEI) score
Hardware acceleration is a new concept to Lync 2013 as previous releases did not support any type of hardware offloading or assistance for either encoding or decoding of video streams. Be aware that this new capability is specific to the H.264 AVC standard, meaning that it only applies to SVC video sessions in Lync 2013. Video encoding and decoding in RTV is performed completely by the CPU and never leverages a GPU or camera for help. This is true regardless of the client version, even for a Lync 2013 client sending or receiving RTV in an interoperability scenario.
There are two potential options to assist in encoding SVC video and one possibility to assist with decoding SVC video. The most common capability today would be the ability to offload SVC decoding to a workstation’s graphics chipset which supports DirectX Video Acceleration (DXVA).
Less common would be the ability to offload encoding of the video to either the graphics chipset or the camera itself. Currently there are a limited number of graphics chipsets which can be leveraged by the Lync 2013 client as well as a single USB camera on the market today which can provide hardware offloading for video encoding in SVC.
DXVA Decoding
Most modern workstations should be able to utilize their graphics chipset to assist in decoding inbound video streams in SVC. These could be either integrated chipsets commonly found on laptops or lower-end workstation or dedicated video cards typically used in higher-end workstations. The requirements are that at least DirectX 9.0 is available and that the chipset exposes the DXVA2_ModeH264_VLD_NoFGT decoding mode. The complex GUID for this decoding mode simply means that the chipset supports H.264 Variable Length Decoding (VLD) without Film Grain Technology (FGT). The specifications for DXVA can be found in this article published by Microsoft.
To determine if a workstation supports both of these requirements the DirectX Diagnostic Tool provided in Windows operating systems can be used. Two example workstations are used throughout this article: ‘A’ is an older Lenovo T410 laptop equipped with a dual-core Intel Core i5 mobile processor and ‘B’ is a newer desktop workstation equipped with a quad-core Intel Core i7 desktop processor.
- Run dxdiag.exe and wait for the tool to complete the automatic data gathering process. If this is the first time the tool has been run then it may prompt to check for new WHQL certificates from the Internet, which is recommended.
When finished the System tab will display some basic information about the current workstation including the DirectX version number. In example workstation ‘A’ shown below DirectX 11 is installed which meets the first requirement of at least version 9.0.
- Click the Save All Information button and then save the dxdiag.txt output file.
- Open the saved file in Notepad and search for the string DVXA which should advance the file directly to the DXVA2 Modes header.
The various DVXA2 modes supported by the workstation will be listed. If the ‘DXVA2_ModeH264_VLD_NoFGT’ mode is included in the list then the second requirement has also been met. If this string is not included then the workstation cannot utilize the graphics processor for video decoding for SVC video in Lync 2013.
As shown above the example workstation does support both DXVA requirements thus when the Lync 2013 client needs to decode incoming SVC video it can leverage the graphics chipset.
Graphics Chipset Encoding
A graphical processing unit (GPU) can also be used for performing video encoding tasks but Lync 2013 currently supports only a limited set of chipsets which can provide this. The TechNet documentation lists individual chipset models as well specific driver versions for Intel and AMD graphics chipsets, but identifying which products contain these chipsets can be a bit difficult.
Certain models of Intel’s second generation Sandy Bridge and third generation Ivy Bridge processors include the integrated Intel HD Graphics chipsets. These can support a feature called Quick Sync Video which Lync 2013 utilizes for hardware encoding. The second generation CPUs include either the Intel HD Graphics 2000 or 3000 chipsets while the third generation CPUs leverage newer 2500 or 4000 chipsets. This means that some, but not all of the Intel Core i3, i5, i7, and i7 Extreme processors may be able to handle SVC video encoding tasks. Also understand that while some workstations may contain a supported processor core, if a unsupported secondary graphics card is installed and active then the integrated graphics chipset is not available and cannot be used for hardware acceleration. This is common in laptop platforms with dedicated GPUs.
Lync 2013 also supports encoding with some AMD products utilizing their Video Codec Engine (VCE) feature. This feature, like Intel’s Quick Sync Video, provides for hardware encoding of H.264 video in Lync 2013 and is part of their Unified Video Decoder (UVD) solution. AMD integrates VCE features in their Radeon 7000 Series graphics cards as well as in some of their Trinity A Series CPUs.
To find out if a workstation contains one of the supported chipsets the DirectX Diagnostic Tool can be used to start the process of identifying the processor core and active graphics chipset.
- Return to the System tab of dxdiag.exe or open the dxdiag.txt file and search for ‘Processor’ to identify the CPU type in the workstation. (Note that Windows does often not correctly report physical core count as it will reflect the total thread count.)
Example Workstation ‘A’
Processor: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz (4 CPUs), ~2.5GHz
Example Workstation ‘B’
Processor: Intel(R) Core(TM) i7-2715QE CPU @ 2.10GHz (8 CPUs), ~2.1GHz
- Simply search the Internet using specific keywords from the processor description to locate the product documentation to help determine the processor generation and specifications.
The first result on Bing for example workstation ‘A’ is the product specification page for the Intel Core i5-540M processor which lists the integrated Processor Graphics as Intel HD Graphics. That name is how Intel refers to its first generation integrated chipset, so this is not one of the compatible chipsets available for hardware acceleration as the CPU is an older first-generation Arrandale chipset.
Example Workstation ‘A’
Next is an excerpt from the product specification page for the second-generation Intel Core i7-2715QE processor used in example workstation ‘B’. This second-generation Sandy Bridge processor contains the 3000 series integrated graphics chipset which includes the Quick Sync Video feature.
Example Workstation ‘B’
Example workstation ‘A’ does not include a hardware acceleration supported graphics chipset, while workstation ‘B’ does. But even though the processor in workstation ‘B’ contains the supported chipset it is still possible that a secondary graphics chipset is installed in the workstation, so to verify that the DirectX Diagnostic Tool can be used yet again.
- Switch to the Display tab of dxdiag.exe and check the name and manufacturer of the enabled video device.
Example Workstation ‘A’
Example Workstation ‘B’
In example workstation ‘A’ the Intel HD Graphics chipset is even not being used as a separate Nvidia chipset is included in the laptop, so even if it did include a supported integrated graphics chipset it would even matter. Yet example workstation ‘B’ not only includes a supported chipset, but it is also actively utilized in the system.
Thus workstation ‘A’ does not meet the requirements to support video encoding via the graphics processor while workstation ‘B’ does.
USB Camera Encoding
The final option is that Lync 2013 can leverage compatible USB cameras to perform hardware acceleration for encoding of SVC video as well. This is a interesting option as although on cannot simply upgrade the type of processor or graphics chipset in a laptop it is certainly easy to purchase a supported USB device and connect it to the workstation for an instant upgrade in video encoding capabilities.
Although some of the USB webcams currently Optimized for Lync do support encoding up to 1080p resolution there is currently only a single camera on the market today which actually handles hardware offloading of the encoding: the Logitech C930e. This is the first device to support USB Video Class (UVC) 1.5 leveraged by Windows 8 and Lync 2013. This means that as long as the workstation is running Windows 8 and Lync 2013 this camera can perform the video encoding itself to minimize the load on the workstation’s CPU during SVC video calls.
CPU Cores
This is a simple concept and still plays a part in video decoding and encoding capabilities in Lync 2013 for SVC, similar to RTV although not as simple. With RTV four physical processor cores were required to encode high definition video (at up to 30fps), while two cores was sufficient to decode high definition video (at a maximum of 15fps). In reality though Lync-to-Lync video calls required quad-core systems on both ends as the Lync 2010 client application is hardcoded to send and receive the same resolutions. (For example a Quad-core to Dual-core Lync RTV video session would be VGA in both directions, not HD in one and VGA in the other, as the Lync client prefers to send VGA at 30fps instead of 720p at 15fps. Microsoft hardcoded a client preference for motion over sharpness in this scenario.)
But in Lync 2013 with SVC the capabilities are much more granular, and with the help of hardware acceleration it is possible for systems with less than 4 cores to send and/or receive HD video.
- The same chipset specification documents found in the previous step also show the number of physical cores for each example workstation.
Example Workstation ‘A’
Example Workstation ‘B’
Example workstation ‘A’ is a dual-core processor, yet capable of up to four threads. This is why the information shown earlier in the DirectX Diagnostic Tool reported a total of ‘4 CPUs’. A true quad-core system with hyper-threading would typically be reported as having 8 CPUs, as evident in example workstation ‘B’.
Windows Experience Index
The final piece of criteria used in calculating a workstation’s video encoding and decoding capabilities is the Windows Experience Index (WEI) score; specifically the Video Encoding Score. The maximum value for this score in Windows 7 is limited to 7.9 while a Windows 8 workstation can be as high as 9.9. These values will be important in the next section of this article when looking at the different maximum capabilities charts.
- To identify the applicable WEI score launch the Windows System Control Panel (tip: use the handy Windows Key + Pause/Break keyboard shortcut) and then verify that the assessment test has previously been run and a score is shown.
- If the assessment has never been run on the workstation or if the hardware configuration has changed since the last test then it is recommended to re-run the test by advancing to the Performance and Information Tools control panel and selecting Re-run the assessment.
- One a test run has been completed then using Windows Explorer open the following system directory where the assessment results files are stored and locate the most recent Formal.Assessment file.
%Windir%\Performance\WinSAT\DataStore
- Open the file (e.g. 2013-05-04 11.13.41.699 Formal.Assessment (Recent).WinSAT.xml) and search for the string VideoEncodeScore.
Example Workstation ‘A’
Example Workstation ‘B’
Note that the VideoEncodeScore values are reported as 7.1 for workstation ‘A’ and 7.6 for workstation ‘B’.
Video Capabilities
The previous article HD Video in Lync included a peek into identifying the receive capabilities of a Lync 2010 client using RTV for video. RTV exposes these options in the Session Description Protocol (SDP) portion of messages SIP messages so it is easy to find these by capturing a SIP trace of the call negotiation. RTV is still negotiated in the same manner with Lync 2013 exposing some new capabilities as well. But SVC calls in Lync 2013 are handled in a completely different manner so it is not possible to identify either endpoint’s receive capabilities as these are not advertised in SDP.
Real-Time Video
Starting with RTV there is an interesting discovery when looking at the same SDP information which was described in the previous article. In all previous OCS and Lync clients the RTV video capabilities were limited to the following possible resolutions and frame rate options. (Based on hardware capabilities clients would advertise support to receive a subset of this these, not the entire list.)
- QCIF (176×144) [4:3] 15fps
- CIF (352×288) [4:3] 15fps
- VGA (640×480) [4:3] 15fps (single core) or 30fps (dual/quad core)
- HD (1280×720) [16:9] 13fps (dual core) or 30fps (quad core)
But when looking at the SIP trace of a video call between Lync 2013 clients there is a change in capabilities advertised by RTV. Even though a Lync 2013 to 2013 client video call will utilize H.264/SVC for video the two clients will still share information about each codec they support.
As explained in the previous article the a=x-caps:121 declaration in SDP is used to advertise the client’s receiving capabilities for RTV. This has nothing to do with SVC as that codec does not utilize the a=x-caps parameter. The MSDN documentation for x-caps has been updated for version 2.0 of SDP in Lync 2013 and last paragraph in the article states that “a=x-caps attribute is not supported for the H.264UC…media formats…if present in a received SDP message, MUST be ignored”.
The following RTV declaration was captured from a Lync 2010 client:
a=x-caps:121
263:1280:720:30.0:1500000:1;
4359:640:480:30.0:600000:1;
8455:352:288:15.0:250000:1;
12551:176:144:15.0:180000:1
Yet this RTV declaration was captured from a Lync 2013 client:
a=x-caps:121
263:1920:1080:30.0:2000000:1;
4359:1280:720:30.0:1500000:1;
8455:640:480:30.0:600000:1;
12551:640:360:30.0:600000:1;
16647:352:288:15.0:250000:1;
20743:424:240:15.0:250000:1;
24839:176:144:15.0:180000:1
Notice that the 2013 client advertises three additional resolutions for RTV, including 1080p.
That MSDN documentation includes a (partially accurate) list of supported resolutions for RTV, including the addition of 1080p. What is missing from that list currently are the additional 640×360 and 424×240 options identified above. Yet the a=x-caps example at the end of that article does show the exact same list shown here, which both comes directly from a SIP trace.
It appears that RTV has been improved to support three additional widescreen aspect ratios (16:9) across low, standard, and high definition. By default the only time RTV would be used for video streams in Lync 2013 for either peer-to-peer or conference calls is when an older RTV-only client is involved. A Lync 2013 to 2013 video session would always utilize H.264 SVC for video, yet a Lync 2010 to Lync 2013 video session would have to use RTV. But the Lync 2010 client does not currently support these additional resolutions, so when negotiating a video session with a 2013 client it would never advertise these new options as receiving capabilities anyway. In turn the 2013 client would only be able to send video in one of the earlier four formats, as well as receive video in one of these same four formats as those are all the 2010 client is aware of.
Where these new resolution could be seen in action is if the H.264/SVC codec was disabled on the Lync 2013 AVMCU, which would revert the AVMCU to using only RTV for all video streams.
H.264 SVC
As previously mentioned there is no simple way to identify the supported receive capabilities when SVC is used for video as it is not advertised in SDP like RTV does. A deeper dive into this topic is planned for a later article as the capabilities provided by SVC in Lync is much more complex than RTV.
In the article Video Interoperability in Lync 2013 the specifications of the complete H.264 SVC codec adopted by Microsoft were covered in great detail, yet was written prior to the actual release of Lync Server 2013. The implementation of SVC in the 2013 product release does not actually utilize every possible feature and capability defined in the codec specification though. That article identified up to 18 different resolutions defined in the specification, but according to the table included on this TechNet page only 15 are in use in the product. The following table captures the different resolutions, aspect ratios, and maximum supported frame rates for each.
Common Name Resolution Aspect Ratio Max Frame Rate 212×160 4:3 15 fps 180p 320×180 16:9 15 fps CIF 320×240 4:3 15 fps 240p 424×240 16:9 15 fps 424×320 4:3 15 fps 270p 480×270 16:9 15 fps 360p 640×360 16:9 30 fps VGA (SD) 640×480 4:3 30 fps 480p 848×480 16:9 30 fps 540p 960×540 16:9 30 fps 720p (HD) 1280×720 16:9 30 fps 1080p (HD) 1920×1024 16:9 30 fps 144p (Panorama) 960×144 20:3 30 fps 192p (Panorama) 1280×192 20:3 30 fps 288p (Panorama) 1920×288 20:3 30 fps
Note that there are two options for the same vertical size in a few cases (e.g. 640×480 & 640×360) which still provide native 4:3 resolution for older non-HD cameras. In most cases the optical resolution of the camera will drive the choice as to best match the field of view captured by the camera. Older standard definition cameras are often only capable of capturing a 4:3 field of view as 16:9 widescreen images typically require a high-definition camera.
Also be aware that after extensive testing not all of these resolutions appear to be usable in Lync video calls, and there are even some undocumented resolutions (e.g. 352×288) which can appear when dealing with some mobile devices (e.g. iPhone) using different native screen or camera resolutions. A later article will cover this topic in more depth.
Verifying HD Resolution Support
In previous versions it was required to manually enable high definition video as an option as OCS and Lync 2010 were set to limit the maximum RTV resolution to VGA by default.
In Lync Server 2013 manual configuration is still required to enable high definition resolution for RTV sessions by setting the MaxVideoRateAllowed parameter is set to Hd720p15M.
Set-CsMediaConfiguration –Identity Global -MaxVideoRateAllowed Hd720p15M
On the other hand SVC is already allowed to scale all the way up to 1080p resolution without any modification as the VideoBitRateKb and TotalRecevieVideoBitRateKb parameters are both set to 50000 by default.
Get-CsConferencingPolicy | Select-Object *Video*
Determining Client Capabilities
In the previous article this section walked through validating the actual resolutions and frame rates that the Lync client would advertise during RTV negotiation, but as mentioned numerous times in this article that process is not applicable to SVC. But using the information gathered from the two example workstations the SVC encoding and decoding capabilities can be determined using the tables at the end of the following TechNet documentation.
Before looking at the data in the table it would be helpful to summarize the basic categories and then compare them to past behavior with RTV. Basically there are three different general categories a workstation may fall into: (1) no hardware acceleration, (2) hardware accelerated decoding, (3) both hardware accelerated decoding and encoding.
For systems which do not support any type of hardware decoding or encoding then it is not possible to encode HD video unless the processor contains at least 4 cores. It is possible to decode HD video with only 2 processor cores available, but only if the WEI VideoEncodeScore is 4.5 or higher. This is similar behavior to RTV which requires a quad-core processor to encode HD video but a dual-core system is capable of decoding HD video. Workstations lacking any hardware acceleration capabilities will never be able to encode video at 1080p regardless of the number of processor cores or the WEI score.
The second category includes most modern workstations which will have the ability to leverage hardware acceleration for decoding video. This provides even the least powerful workstations with a single processor core the ability to decode up to 1080p, given that the WEI score is at least a paltry value of 3.0. Yet the ability to encode HD video still requires at least a quad-core processor since there is still no hardware assistance on the encoding side, placing the entire encoding burden on the CPU.
The third category includes systems which are able to leverage hardware acceleration for both encoding and decoding video and these workstations can decode and encode every possible resolution provided in H.264 SVC all the way up to 1080p regardless of the number of processors. The encoding score still is a factor here, so older systems with a score less than 5.0 can still achieve HD send and receive by adding a UVC 1.5 compatible camera, for example but would be limited to encoding 720p video while receiving 1080p. Systems with a score higher than 5.0 would be able to send and receive 1080p.
The information previously gathered from the example workstations is summarized below and then cross-referenced with the TechNet documentation.
Feature Workstation ‘A’ Workstation ‘B’ Hardware accelerated decoding Yes Yes Hardware accelerated encoding No Yes Physical CPU cores 2 4 WEI Video Encode Score 7.1 7.6
Example workstation ‘A’ falls into the second category of hardware accelerated decoding only, and with a dual core processor and an encoding score of at least 6.0 that system is capable of sending resolutions up to 960×540 and receiving and decoding all resolutions all the way up to 1920×1080.
Meanwhile the more powerful workstation ‘B’ which includes 4 processors and can utilize hardware acceleration for both decoding and encoding video is capable of sending and receiving a maximum resolution of 1920×1080.
Summary
After all these calculations and reference cross-checking the resulting information is simply ‘what is possible’. Keep in mind that for any resolution to be sent to another endpoint in a call that endpoint first much request that specific resolution or something close to it. So if the receiver’s display resolution is not even large enough then it does not matter if the other system can support sending a much higher resolution than the requestor is capable of asking for. For these reasons utilizing something like 1080p video is going to require a fair amount of hardware in both workstations with the receiving end connected to a decent-sized monitor set to at least 1920×1280 screen resolution and viewing the video stream in full screen. In retrospect the real value of Lync 2013 in terms of an improved video conferencing experience is not necessarily due to the increased high definition capabilities, but is a result of the additional standard definition resolutions and improved video quality provided by H.264/SVC.
An upcoming article will put all this theory to test by reviewing the results of various calls among different endpoints, leveraging the Lync Monitoring and Reporting components.
Excellent article, as always!!!
Great article. Sums it up perfectly.
Fantastic detail! Thank you!
Great article! Thanks!
Can I do multipoint calls without a special license with a HDX 8000 (B)?
Are multipoint calls still in CIF or can I use SVC without using a RMX?
Thanks,
Wolfgang
No, the RTV Options Key is required for any interaction with the Lync AVMCU as both RTV and CCCP are needed. Alternatively the HDX internal MCU is a different license key but you cannot host multi-point calls on the HDX with Lync client, regardless of the video codec used. The internal MCU on the HDX is for non-Lync endpoints.
Hmm… thanks.
Right now I don't have any RTV Options Key installed and I am able to use the HDX to initiate a multipoint call with Lync with 2 attendes.. The only downsinde is that the codec is only CIF and quality is really bad.
If I use the RTV Options Key I do have the problem that only that active speaker is shown in the conference. Unlike without the RTV Options Key. There I can see all attendees on the HDX and in the Lync client without using a RMX.
I've heard that you need to use a RMX to have the same experience (see multiple parties video in the conference) when you use the RTV Options Key.
So I can't use SVC in a multipoint call without using the RTV Options Key?
Do I need a RMX to see the video all attendes within Lync client and on the HDX then?
Thanks,
Wolfgang
Hosting multi-party Lync video calls on the HDX's internal MCU is unsupported regardless of the codec used (H.263 or RTV). When the RTV Options Key is enabled then the HDX will join the Lync AVMCU for any multiparty calls. And RMX is required to host a mixed video conference with H.263, H.264, and RTV endpoints along with Continuous Presence.
Great article as always!!
We however have problems with getting 1080p video(getting only 720p on both sides), where I think it *should* give me just that on the following hardware on both sides(due to "Hardware Accelerated encoder"):
– Windows 7 SP1
– Lync 2013 CU1(server+clients)
– i5-2500(4CPU, 3,3Ghz)
– AMD 7750 GPU(should be able to do AMD VCE right? Thus, but don't know how to confirm this)
– Logitech 930e FullHD webcam(I know it won't help me on Windows 7)
2 things I'm not sure about:
1) the DxDiag.txt states "DXVA-HD: Not Supported"(as far as google knows, this is normal for recent AMD video cards), and there are no further mentions of DXVA2 supported modes like in the article there. Not sure how the AMD VCE fits in.
2) In the "Peer-to-Peer Session Detail Report" in the Lync reports, under Media Quality report, subsection "Media Line (Main Video)" there is a "Applied bandwidth limit" of 2500 Kbps. I have no bandwith limits specified, other then the "50000" default limit.
Thanks in advance!
Are you using a camera that is 1080p capable on both ends of the call? I'm confused by your mentioning of the Logitech C930e as it's not available yet so I assume you are using a different camera for this test. I don't know exactly what the DxDiag statement means, but if DXVA2 is not listed then you may not have a compatible GPU. And that bandwidth value you see in the Monitoring Server reports is just an estimation of the available bandwidth for that endpoint; I'm not sure how Lync calculates it but I've seen values all over the place.
Hey Jeff, Thanks for the reply and thanks clearing up the bandwidth value concern!
We do have Logitech 930e camera's, so they are available. Image quality seems excellent.
We received 3 of them this week(ordered them a week ago). Unfortunately the hardware encoding (SVC) only works on Windows 8 it seems.
Now i'm still wondering why our AMD HD7750 GPU's won't be recognized/used for encoding by Lync 2013, as they should also provide for 1080p due to AMD's VCE. But can't find any information about this, except the statement on technet that it *should* work since CU1.
Good to know that the Logitech cameras are shipping now and yes Windows 8 is required for UVC 1.5 support. I haven't tested any of the AMD chipsets myself, so it's possible that the TechNet doc has some inaccuracies in it. Please post back here if you get it working.
Waiting for your new article regarding how we can verify SVC usage at endpoints. For now, its very unclear what's the actual codec in use. Thanks for great article. Nguyen
Just check the Codec value reported in the Media Quality Reports for each video stream. It will either be reported as 'H264' or 'x-rtvc1'.
Dxdiag gave me different result than DXVA checker (http://bluesky23.yu-nagi.com/en/DXVAChecker.html). While according to your guidance, I dont see DXVA2 was supported, but DXVAChecker gave all res ModeH264_VLD_NoFGT: DXVA2, 720×480 / 1280×720 / 1920×1080.
I am sure that my laptop hardware is qualified for H264 SVC, since it used Intel HD 3000 graphic, and with all latest driver per Microsoft recommendations.
Can you have a look at DXVAChecker and verify whats the correct util.
Thanks. Nguyen
I haven't used this tool before so I can't say what it reports is applicable.
We ordered 2 new core i7 computers just for HD video conferencing en few days ago…they will arrive shortly, but in the meantime I found something that worries me…
I don't think DXVA2_ModeH264_VLD_NoFGT even/ever "shows up" in Windows 7 dxdiag…
I've got a (not to old quadcore i5) workstation here with an Intel HD graphics 3000: no DXVA2_ModeH264_VLD_NoFGT in dxdiag.
Installed the latest Intel drivers, still no DXVA2_ModeH264_VLD_NoFGT. Same on workstations with a recent AMD radeon(7750) graphics cards.
Then i found out that DXVA2 is actually supported on all those cards, 3rd party tools(like the one Nguyen posted) show these modes as fully supported.
If I google for "DXVA2_ModeH264_VLD_NoFGT dxdiag" all of the results that come back are dxdiag results from Windows 8.
So…if Lync 2013 used dxdiag to check if DXVA2_ModeH264_VLD_NoFGT is present, and it never is on Windows 7, the conclusion is that a 1080p video conference/session is in fact totally impossible on Windows 7, right? That also means the only information from Microsoft on this topic is just wrong.
Fact is that can never get it to work, always end up with 720p resolution. I really hope that i'm wrong, and we dind't spend 2000 euro's for nothing.
Lync does not utilize dxdiag, I simply used that tool for demonstration purposes. If their are third-party apps which report DXVA information differently then maybe dxdiag is not the best option to use for all platforms. Please let me know the results of your testing as this topic is very much a work in progress in that I'm still gathering details of real-world results. I don't see any documentation from Microsoft that states Windows 8 is a requirement to support 1080p video, so I'm assuming you should be fine with the new equipment.
Jeff,
1st great article. I'm digging into lync video more and its great helpful.
I'm curious: Does adding a UVC 1.5 camera to any Windows8 PC enable 1980×1080 encoding regardless of graphicsscore? or does graphicsscore still come into play even if UVC1.5+Win8?
Once again thanks
According to the TechNet documentation the system will still need to have a GraphicsScore of at least 5.0 in order to encode 1080p even with hardware-assisted encoding. But thus far I've been unable to get my C930e to encode in 1080p (nor 720p/30fps for that matter). The best that camera will produce is 720p@15fps, while my LifeCam Studio works fine at 720p/30fps all day long, and this on a PC with a score of 7.1 (and Windows 8).
I've been doing video testing over last couple of days and I'm noticing several things:
-as noted above, dxdiag does not always show when "DXVA2_ModeH264_VLD_NoFGT" mode is present. I've tested machines that dxdiag says doesn't support NoFGT mode and they can do resolutions that indicate they do support it. When I run the other suggested tool it indicates correctly. So with this cross check I am guessing that dxdiag is reporting incorrectly.
-I am also noticing on windows7 and windows8 the c930e does no higher than 15fps which surprised me.
Today I received our 2 new "videoconferencing PC's". They are HP 8300 USDT's with quadcore Core i7 processor and onboard Intel HD4000 GPU.
I'm happy to say that they do 1080p video(~28fps) without problems using Logitech 930e webcam on Windows 7 SP1.
Image quality seems a bit better then 720p on the same camera does. so that's nice.
FYI: There are still no DXVA2 modes listed in dxdiag.
This seems to indicate that a quad-core system is still more important than the documentation indicates. Those PCs would encode 1080p with Lync using even an older LifeCam Studio, so the C930e may only be providing for processing offloading and not actually increasing the actual encoding capabilities with Lync.
Yes indeed. But it also indicates that AMD's VCE does not (noticeably)function in Lync 2013 CU1(on a Quadcore Core i5 with AMD 7750 GPU).
I thought the 930e was to blame, but it does 1080p just fine on the Intel HD4000.
[…] A question users might ask: What video resolution is my my capable of? For technical people, Jeff Schertz has written an excellent article on how to determine the video capability of a […]
[…] More on c930e (see comments)http://blog.schertz.name/2013/05/hd-video-lync-2013/ […]
Just one minor correction.
" Throughout the television industry this means resolutions with a width of 720 pixels or higher…."
In the broadcast television business 720 x 480 is SD video. ATSC standards define what is considered "High Definition" as 720p or better.
That does leave a considerable gap between 720×576 and 1280×720, where some VC systems implement resolutions that are natural multiples of CIF, SIF, QHD, etc.
Michael, good catch. That statement should be 'height' and not 'width' as clearly there is a considerable difference between 1280×720 and 720×480 resolutions. I've fixed the typo; thanks for the feedback.
Hello Jeff, I remember once seeing a slide deck showing many different scenarios of multipoint calls using Lync 2013 SVC, could you please share that ?
I'm not sure which deck you are referring to as there are a few of them. I do plan to post a new article covering that topic in the near future.
Are there any USB 3.0 to hdmi devices that allow a user to plug in a roamable video camera that is recognizable by Lync?
No, only Lync Optimized USB video cameras are supported.
This is just a joke microsoft should have a great livemeeting software but still doesnt with capture utilities but still hasnt, all of the current video conference systems are sub par at best there are a few really decent ones but in general they just dont exist. Better have a high end computer otherwise that pos dell with built in video card isnt going to cut it.
[…] 2013 clients and the AV Conferencing service utilize both SVC and RTV for video sessions which provide multiple resolutions and frame rates for the panoramic […]
Hi Jeff,
Thank you for this usefull article.
Can we expect support for the H 264 SVC with the Lync 2013 Web App client when using compatible Browser and Hardware?
Regard
Francois
H.264/SVC is already supported in Lync Web App. The first time you connect and are requested to download the browser plugin this is the code that adds media support for Lync audio and video in LWA meetings.
Thanks Jeff for the fast answer
Is the Lync 2013 Web App capable of decoding and encoding 1080P if the hardware (e.g., QuickSync or Logitech C930e with UVC 1.5) supports it?
Yes, I've tested this (with a Logitiech C930e) and confirmed that a workstations capable of encoding 1080p video in Lync can also send 1080p video when using Lync Web App.
Excellent. I guess Intel QuickSync and AMD's GPU acceleration is supported as well? Did the CPU remain low while transmitting 1080P?
Excellent articles all around. I wonder if you could offer any advice on an issue that one of our customers is experiencing with the video quality when running a VC session to/from Polycom HDX7000 to Lync 2013. They have turned to us for assistance and advice but we seem to be drawing a blank on potential resolutions. We have not supplied the solution but do provide their Microsoft and hardware infrastructure support so are working with the customer to try and find a resolution.
Their original installation was just the Polycom solution to which they have added Lync recently.
So far we have confirmed that Lync to Lync sessions work perfectly and that Polycom to Polycom sessions work perfectly. The issues only appear when running Lync to Polycom sessions. The main issue is one of video quality in that the video freezes, gets very blocky and is generally unusable.
We have confirmed the Polycom units are running:
Software Version – Release – 3.1.3-38278, Software Version – Release – 3.1.4-43132, and Software Version – HF – 3.1.3_03-38296 with all the HDX7000s being Hardware Rev C.
Can you offer any advice or guidance as to what the issue could be or confirm required settings for Microsoft Lync Servers, Clients and Polycom HDX 7000 units??
Dave, are the video quality issues seen during peer-to-peer HDX-to-Lync calls, during multiparty conference calls (AVMCU), or both?
Hi Jeff,
We are facing same issue with Polycom group500 devices, when involved the Lync AVMCU we are losing the 1080P and get the 640×360 or 640×368.
Kindly guide in this regard.
The Lync AVMCU will not send 1080p video in multiparty conference calls with more than a single participant when Gallery View is in use. Lower resolutions are transmitted by all clients.
Thanks for the article Jeff
I have question here.
Are higher frame rates possible at any resolution in any scenario in Lync? and if not, are they expected in the future? I'm talking about 60 fps to be specific.
Not currently as 7.5, 15, and 30 fps are the only supported frame rates in Lync 2013 video codec. I cannot comment on any future capabilities in Lync that Microsoft has not already publically released
For newer Windows 8.1 computers the Windows Experience scores can be generated by issuing “winsat prepop” and then “winsat formal” at a Windows command prompt as this behavior is now hidden from the System control panel.
HI Champs,
We are in the process of migrating to Lync 2013, we moved users to Lync 2013 pools and still users are with Lync 2010 client. When start video calls some times video freezing.
Any guess what could be the cause ? Is there any problem with video codecs or something else. Much appreciated response. Thanks
Regards
Vijendhar
First – thanks for the excellent contributions to the community.
Question – all this information is in regards to Video in a Video Conversation. My question is in regards to an application/desktop share. Can i limit the desktop share resolution via the set-csconferenencingpolicy -MaxVideoConferenceResolution to a vga resolution versus an HD resolution? In the lync2013 network bandwidth calculator there is a question in the definition tab to define the Application Sharing Resolution. How do we limit that to the minimum 1280×800?
Thanks
Those parameters are only applicable to the video stream, not desktop sharing. To control desktop sharing you can either limit the maximum bandwidth available (lookup ‘AppSharingBitRateKb’) or the frame rate (see this article).
Hi Jeff,
Is it possible to call a VMR with a profile only SVC from a lync client ? All the Polycom Lync integration is done and work perfectly with CP but what about SVC ? Thanks in advance for your help
No, it is not yet supported to mix standard H.264 SVC endpoints (like Group Series or RealPresence Desktop) with Microsoft SVC clients (like Lync 2013 and SfB 2015). H.323 and SIP interoperability with Lync still requires the use of ‘AVC Only’ conference profiles to support transcoding (on the RMX) of all the different incompatible video codecs.
Jeff,
Have you ever seen a way to estimate the amount of video usage within conferences? There is a report for P2P video usage but we haven’t found a way to help business units to understand video utilization within conferences.
I suggest watching my session from Lync Conference 2014 which covers this topic: http://blog.schertz.name/2014/05/planning-for-video-in-lync
Jeff,
Great stuff here. I’m wondering how the Lync resolutions settings effect the RMX in RealConnect. We have our Lync 2013 servers set to VGA do to network capacity requirements. When we cascade with RMX in RealConnect the video rooms have black letterbox in the Lync Gallery, but in the rooms Lync is 16:9. This is very confusing to me because when we uncheck our web camera setting to crop and center the video we will get a wide 16:9 looking camera view.
Is there any way to remove the letterbox from the RMX video?
David, starting in recent RMX releases 8.5.4 and 8.6 a new system flag was introduced to force 16:9 video in RealConnect. Create a new RMX system flag called “FORCE_LYNC2013_ENCODER_ASPECT_RATIO_16_9” and set the value to “YES”. This works with both Lync 2013 or SfB 2015. Also the VGA setting you’ve mentioned on your Lync 2013 servers only impacts RTV video sessions from legacy clients (Lync 2010 and older) and does not affect the SVC video streams that are being used by all Lync 2013 clients and up. The RMX supports both SVC and RTV so it’ll relay whatever streams are active in the meeting.
I’m running RMX 8.5.4 and when trying to add FORCE_LYNC2013_ENCODER_ASPECT_RATIO_16_9 to the MCMS_parameters_user ; and error occurs. “The new flag cannot be added. Flag is not recognized by the system”.
I believe there’s a small typo right below the H.264 SVC chart where it says: (e.g. 640×480 & 640×320)
The 320 should be 360.
No need to post this note – I only took the time because I appreciate your articles very much.
Best regards,
Eki Spinelli
Thanks for the sharp eye, it’s fixed now.
Dear Jeff,
Please we do have a customer that would be rolling a couple of group series devices in their Lync 2013 environment.
My question is how to enable HD video in SFB for the Polycom Endpoints as these would be deployed using larger HD grade displays and i am already sure there video would be fuzzy when used with Larger screen,
Normally this would have been possible using Set-CsMediaConfiguration –Identity Global -MaxVideoRateAllowed Hd720p15M
but i see that has no effect in lync 2013
we need to enable resolution up to 1080. Just to add that we would also be enable the 1080p option key for all the Polycom devices.
That parameter only controls RTV and has no impact on the SVC video streams used in most SfB meetings. The GS will attempt to request the highest resolution available from the active speaker, but these automatic Video Source Requests are all managed by the SfB AVMCU and ultimately it’s on the remote attendees’ endpoints to accept or deny those requests (based on bandwidth and processing availabilty). In short, you can’t really control this and the SVC video resolutions coming into the Group Series will vary between the different remote participants. Note that in order to receive a 1080p stream the the 1080p Video software license is required on the Group Series, bvut you’ll never receive 1080p in a meeting anyways unless there is only a single video participant in the meeting, and even then often it’ll only be 720p.