4 Replies Latest reply on Nov 16, 2010 8:28 AM by madshi

    ADL feature request: modifying pixel clock on the fly

    madshi
      for smooth video playback without dropped/repeated frames

      When doing high quality video rendering with a PC, one sooner or later runs into problems with mismatching video and audio hardware clocks, resulting in the necessity to drop or repeat video frames at specific intervals. This might not be a problem for YouTube watching, but for high quality (e.g. Blu-Ray) playback, if we want to rival hardware Blu-Ray player quality, it's very important to have a perfectly smooth experience without any video frame drops or repeats.

      I'd like to see a new ADL API for changing the pixel clock dynamically, without invoking a full output mode reset. This would be used to adjust the video clock dynamically during video playback to match the audio hardware clock.

      If you AMD guys are willing to add such an API, it would be great if you could allow very small step changes. The steps should be smaller than what e.g. ADLDetailedTiming.sPixelClock allows. The smaller the steps, the better...

      Thanks!

       

      Edit: Found the following undocumented ADL APIs:
      - ADL_Display_CurrentPixelClock_Get
      - ADL_Display_PixelClockCaps_Get
      - ADL_Display_PixelClockAllowableRange_Set

      Maybe they already do what I need? Does anybody have the documentation for these APIs?

        • ADL feature request: modifying pixel clock on the fly
          BSMGT

          Hi,

           

          we are in the need of exactly the same thing. Did you get or find any news about this topic?

           

            • ADL feature request: modifying pixel clock on the fly
              madshi

              I haven't heard *anything* from AMD about this, nor about the 2 bug reports in posted in separate threads. I wonder if anybody at AMD is supporting ADL at all.

              FYI: I've looked into those 3 undocumented APIs I've mentioned in my original post. They seem to expect a 0x40 sized structure, and I can actually call one of them with success result. However, the structure is unchanged. And one other of those APIs returns "not implemented". So I think these 3 new APIs are not working/implemented yet in the current driver version.

                • ADL feature request: modifying pixel clock on the fly
                  Byron

                  Video timings conform to VESA standards.

                  There are CE timing standards which match Blue Ray playback naturally (720p, 1080p CE modes have 59.94 Hz refresh rate instead of 60Hz for PC modes).

                  If someone is trying to play video while PC mode is set on display, the side effects like frame drops/repeats are known.

                  Just set CE mode on your display (if it supports CE mode), is that possible?

                  We need more details;

                  OS (In general, it is not allowed to change timing without full mode set in Vista/Win7. XP is Ok. )

                  ASIC (Different ASIC families have different precision in setting pixel clocks.)

                  Output (Are we talking about HDMI audio here? Note that external digital displays are in general quite sensitive for timing. Besides the fact that it is against OS's rules in case of Vista/Win7, there is no guarantee you will see anything on display if you change the timing. Though it is Vista/Win7 logo requirement to support certain CE modes on DVI/HDMI output even when EDID of display does not report such modes, and our driver complies with these requirement, plus we also provide interface in CCC to force certain CE (HDTV) modes on DVI/HDMI outputs, however we know that some panels black out when we drive forced CE timings.)

                   

                   

                  The ADL functions mentioned

                  Edit: Found the following undocumented ADL APIs:
                  - ADL_Display_CurrentPixelClock_Get
                  - ADL_Display_PixelClockCaps_Get
                  - ADL_Display_PixelClockAllowableRange_Set 

                  below were for notebook LCD only and special to OEM request only on particular platforms.

                    • ADL feature request: modifying pixel clock on the fly
                      madshi

                      @Byron, first of all many thanks for replying to my threads. For whatever reason I didn't get email notification about your posts, because of that my replies are late.

                       

                      Originally posted by: Byron Video timings conform to VESA standards.

                      There are CE timing standards which match Blue Ray playback naturally (720p, 1080p CE modes have 59.94 Hz refresh rate instead of 60Hz for PC modes).

                      If someone is trying to play video while PC mode is set on display, the side effects like frame drops/repeats are known.

                      Just set CE mode on your display (if it supports CE mode), is that possible?



                      I'm talking about the following situation here:

                      - CE mode is set
                      - Playback of a 1080p 23.976fps movie
                      - GPU set to 1080p with 23.976Hz

                      So in theory playback should be perfectly smooth, with no dropped/repeated frames ever, right?

                      Actually *no*. The problem is that audio and video hardware clocks can drift ever so slightly. Over the runtime of a full movie this can lead to a couple of (not many, but some) dropped/repeated frames. E.g. imagine if the video clock runs 0.01% faster than the audio clock. A typical movie is about 2 hours long. So at the end of the movie the video clock is 120 minutes * 0.01% = 720 milliseconds ahead. With 23.976fps that means 17 repeated frames throughout the runtime of the movie. Ok, usually the audio/video clock drift is smaller than 0.01%, but it's rarely an exact match, because video and audio usually have different hardware clock generators.

                      I'm not sure if you've ever heard of "ReClock"? ReClock is a free software which resamples audio to achieve a perfect match between audio and video hardware clocks. However, resampling audio costs quality. Because of that I believe the better solution would be to apply very very small changes to the GPU pixel clock on the fly, to fight these small audio/video clock drifts. I've tested this (with PowerStrip) with several displays/projectors, and if I do only very small changes to the pixel clock, the displays are not bothered by that at all. No mode change, no display resync.

                       

                      Originally posted by: Byron We need more details;

                      OS (In general, it is not allowed to change timing without full mode set in Vista/Win7. XP is Ok. )

                      ASIC (Different ASIC families have different precision in setting pixel clocks.)

                      Output (Are we talking about HDMI audio here? Note that external digital displays are in general quite sensitive for timing. Besides the fact that it is against OS's rules in case of Vista/Win7, there is no guarantee you will see anything on display if you change the timing. Though it is Vista/Win7 logo requirement to support certain CE modes on DVI/HDMI output even when EDID of display does not report such modes, and our driver complies with these requirement, plus we also provide interface in CCC to force certain CE (HDTV) modes on DVI/HDMI outputs, however we know that some panels black out when we drive forced CE timings.)



                      I'm not an end user. I'm developing a freeware HTPC renderer (see "madVR") which is used by many end users with all kinds of GPUs on all kinds of OSs. So basically I need support for all OSs (XP and newer) and all GPUs (DX9 and newer).

                      I didn't know that Vista/Windows 7 don't allow timing changes without a full mode set. It does make some sense because Aero has its own "composition rate", so if the GPU refresh rate changes behind the back of Aero, probably Aero would start to stutter.

                      However, please understand that I do not want/need to do *big* changes. All I want is to do very VERY small changes to the pixel clock. Like changing refresh rate from 23.976000 to 23.976001 or something like that. Basically if my video renderer detects that a frame drop will be necessary soon (because the video clock is running ever so slightly slower than the audio clock), I'd like to ever so slightly increase the GPU pixel clock / refresh rate, so that I don't have to drop a frame. I don't think such a miniscule change to the pixel clock could bring the OS into any trouble.

                      Would offering an optional ADL API to do such small GPU pixel clock changes without a full mode set violate WHQL rules? That would be bad, of course.

                      FWIW, currently I'm looking into writing a small windows driver which invokes AtomBIOS calls to modify the pixel clock on the fly. I expect that to work, but of course it would be *much* nicer and cleaner if there was an official ADL API instead.