Announcement

Collapse
No announcement yet.

Orbital: A New Shell For Wayland's Weston

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by TheOne View Post
    mmm, this is disturbing, if this demo was recorded using a native wayland utility and laggued, things are not so superior as they have been sold to us.
    Screencasting is a heavy process, whatever the utility you use. You have to ask the graphics card for the framebuffer every frame and dump it to the hdd. Transferring data from the graphics card to the main RAM is slow, and that's because how the PCI-X slot works. Then if the HDD can't keep up it starts dropping frames and you'll get lag in the final video.

    Anyway, I've done another one (with no lag this time ): http://www.youtube.com/watch?v=bd1hguj2bPE

    Comment


    • #17
      Originally posted by giucam View Post
      Screencasting is a heavy process, whatever the utility you use. You have to ask the graphics card for the framebuffer every frame and dump it to the hdd. Transferring data from the graphics card to the main RAM is slow, and that's because how the PCI-X slot works. Then if the HDD can't keep up it starts dropping frames and you'll get lag in the final video.
      Sorry if that question may sound stupid, but couldn't the lag be avoided/minimized with large enough buffers (modern RAM should be able to hold way more than one frame while the HDD is busy) and when using the timestamps (IIRC Wayland timestamps each frame) ?

      Comment


      • #18
        Sure, there are various ways to optimize the process, but it remains a heavy job.

        Comment


        • #19
          Originally posted by TAXI View Post
          Sorry if that question may sound stupid, but couldn't the lag be avoided/minimized with large enough buffers (modern RAM should be able to hold way more than one frame while the HDD is busy) and when using the timestamps (IIRC Wayland timestamps each frame) ?
          You still forgot a) the cost of VRAM->RAM transfers (as was already mentioned) and b) the computational cost of encoding high resolution video in real time.

          Comment


          • #20
            Originally posted by Ancurio View Post
            You still forgot a) the cost of VRAM->RAM transfers (as was already mentioned) and b) the computational cost of encoding high resolution video in real time.
            Maybe some video cards can encode video directly from buffers?
            I also suppose the issues are mostly the same when doing remote display?

            Comment


            • #21
              Originally posted by erendorn View Post
              Maybe some video cards can encode video directly from buffers?
              I also suppose the issues are mostly the same when doing remote display?
              I haven't heard of any recent video cards supporting vp8 natively, so you'd have to implement it in OpenCL,
              assuming your driver supports cl_khr_gl_sharing for CL GL interop.

              Comment


              • #22
                Originally posted by Ancurio View Post
                You still forgot a) the cost of VRAM->RAM transfers (as was already mentioned)
                No, that's why I was talking about the timestamps: Use them to re-arrange the frames after they all landed on the HDD (the recording is over).
                and b) the computational cost of encoding high resolution video in real time.
                So why do it in real time? First record all frames, then encode them to a video.

                Anyway, it was just a question.

                Comment


                • #23
                  Originally posted by TAXI View Post
                  No, that's why I was talking about the timestamps: Use them to re-arrange the frames after they all landed on the HDD (the recording is over).

                  So why do it in real time? First record all frames, then encode them to a video.

                  Anyway, it was just a question.
                  As raw frame data? At 30fps 1080p, that's 237MB per second. Almost 100GB in just 7 minutes.

                  Not many people have that much hard drive space, and you're going to really be saturating your IO just to save it all which could add performance problems of it's own. It's definitely too large to just store in RAM.
                  Last edited by smitty3268; 08-24-2013, 10:47 PM.

                  Comment


                  • #24
                    There's something I don't quite get here. Why is a simple task of screen recording so difficult on linux and everyday simple and effortless task on osx/windows?

                    Comment


                    • #25
                      Originally posted by ACiD View Post
                      There's something I don't quite get here. Why is a simple task of screen recording so difficult on linux and everyday simple and effortless task on osx/windows?
                      Because nobody cares enough about making that easy.

                      Comment


                      • #26
                        Originally posted by Ancurio View Post
                        I haven't heard of any recent video cards supporting vp8 natively, so you'd have to implement it in OpenCL,
                        assuming your driver supports cl_khr_gl_sharing for CL GL interop.
                        You don't have to record it to vp8 directly. Use whatever is native to the GPU, then re-encode to vp8 for distribution.

                        As for saving all frames, it should be possible to only get damaged zones for each frame, greatly reducing the volume of data.

                        Comment

                        Working...
                        X