Results 1 to 4 of 4

Thread: improve slightly fuzzy default HD TCXD streaming when using 1080-60i project settings

  1. #1
    Registered User
    Join Date
    Jul 2009
    Location
    Nampa, ID
    Posts
    78

    Lightbulb improve slightly fuzzy default HD TCXD streaming when using 1080-60i project settings

    Note: If you are using a progressive project setting like 24p or 30p this information is not relevant. If you are using a 720 project setting this information is not relevant. If you stream from an external device this information MIGHT still be relevant to you as well but most likely is not. This information pertains to those using a 60i project setting with any internal TCXD streaming setting (HD or SD).

    We recently went from streaming all our programs at 360p to 720p. (Our TCXD project settings are 60i for smooth recordings of action.) While doing thorough testing we noticed that something was just "not right". Every single HD 720p setting was a bit fuzzy or blurry and it just seemed that they should be sharper. We did not base our results on watching the stream itself, but directly reviewing the f4v files created when you save a stream archive. After taking a look at the default TCXD 720 stream xml profiles we discovered the problem.

    When used with a 60i project, the FMLE xml stream profile settings in the TCXD's seem to have a procedural bug.

    The problem is that the xml stream profiles are resizing and capturing the incoming 1080i video as if its 720i THEN applying the deinterlacing and then encoding. This is an incorrect procedure and results in improper deinterlacing which results in a slightly fuzzy stream and archive. You cannot directly convert or capture interlaced video to another size without first properly deinterlacing it. This is because after a direct 1080i to 720i resize/capture, your first 1080i interlace lines are now a percentage of a line in 720, which of course becomes fuzzy and can't ever be deinterlaced properly after the fact.

    Looking at the default 60i project to 720p stream workflow sequence map:
    TCXD capture device @ 1080i -> direct resize/capture to 720i -> deinterlace (too late) -> resize and encode to 720p (that last resize is redundant but technically that's what it's doing)

    The correct sequence for a 60i project to 720p stream should be:
    TCXD capture device @ 1080i -> 1080i capture (no resize yet) -> deinterlace -> resize and encode to 720p (no partial interlace lines lost and no redundant resize)

    Ok, so how to fix it you ask? It's easy. How much will it sharpen my video? Well take a look at the following samples and decide for yourself. It made the difference for us. Fine details become a bit more clear, and after all that's why we went HD in the first place right? Streaming is lossy enough without adding extra blur as well.

    Screenshot Before (default 1280x720 1536k.xml):


    Screenshot After:


    The web site appears to be resizing the photos, you may need to enlarge your browser or open the photos and view them full size in separate tabs or compare the video clips for more clarity.
    Things to compare between photos:
    • Compare the sharpness of the text on the small warning sticker above the meter.
    • Compare the sharpness of the tiny hole at the top left of the ring around the meter.
    • Compare the sharpness of the dust on the face of the meter.
    • Compare the fine details of the wood grains.
    • Compare the sharpness of the "ISO2A99101" text inside the meter.
    • Compare the sharpness of the text in general.
    • If you look at the surface of the metal in the first photo close enough there is some "blotchy" looking discoloration (possibly caused by the incorrect attempt at deinterlacing at the wrong time). This blotchy discoloration is gone or is much smoother in the second still photo.

    Original f4v
    After f4v

    Uncompressed avi's from the f4v's are also available.

    Ok, so if you convinced, here's the fix:

    1. Go to Administration Mode on your TCXD
    2. Exit to Windows
    3. Browse to: C:\TriCaster\Streaming Profiles\FlashProfiles\NTSC\HD (you may need to modify the settings in more than one folder or another folder if you are not using NTSC etc)
    4. Make a copy of all files in any folder you are going to "fix" for safety. (We copied the files within the same folder and renamed them like this "1280x720 2048k.xml" -> "1280x720 2048k - 1080 capture.xml"
    5. Simply edit (right click -> edit) your new copied "1080 capture" xml streaming profiles and change this part:
      Code:
          <capture>
              <video>
              <device>NewTek TriCaster Video</device>
              <crossbar_input>0</crossbar_input>
              <frame_rate>29.97</frame_rate>
              <size>
                  <width>1280</width>
                  <height>720</height>
              </size>
              </video>
      to this, in each of the xml streaming profiles:
      Code:
          <capture>
              <video>
              <device>NewTek TriCaster Video</device>
              <crossbar_input>0</crossbar_input>
              <frame_rate>29.97</frame_rate>
              <size>
                  <width>1920</width>
                  <height>1080</height>
              </size>
              </video>
      DO NOT EDIT THE ENCODER SETTINGS BELOW THE CODE LISTED ABOVE AS YOU COULD OVERLOAD YOUR TCXD AND CAUSE STABILITY ISSUES.
    6. Save your work.
    7. Repeat on any other xml streaming profile that is relevant to your workflow.
    8. Open the TriCaster interface and go to your stream settings.
    9. Select the new fixed stream settings. You may get an error at this point. This is NOT a TriCaster issue, FMLE tends to crash at times when you change the capture resolution which is exactly what you are doing here. If you get the error just click through it. You may need to reopen your stream settings once more and select your new settings again. It should "take" the second time and you should be good to go.
    10. Test your stream.
    11. Test everything again for stability and performance.


    Final note 1: If you switch your project from 60i to 24p/30p make sure to change your stream profile settings back to the default settings, deinterlacing is not necessary with progressive projects. (Just select the original applicable stream profile.)

    Final note 2: The camera used was a Canon HF G30. You may notice even more improvement with higher end cameras. Clips were taken back to back with only enough time between to flip the TCXD stream setting from the default HD 720 1536k to the new modified one.

    Final note 3: Steve and Andrew is there any way that there might be a way to include this change into the TCXD code and split the stream profile settings so that the default 60i project to 720p streaming procedure is correct and sharp by default?
    Last edited by spotduster; 06-02-2014 at 11:59 PM.

  2. #2
    Registered User
    Join Date
    Oct 2012
    Location
    Munich, Germany
    Posts
    80
    Hello,

    could it be, that after this changes the TC has over double the workload to deinterlace the content, than it had before ?

    I'am always a little bit concerned about the load on the tricaster even when not streaming.

    For stream encoding we have built our own computer configuration using good components like workstation mainboard, 6 core i7 processor, fast SSD, plenty of ram, but still could get this machine over 80% load on all cores during encoding of mutliple streams (eg. 3 streams, one 720p, one 430p and one 150p) at a 720P60 input signal.

    So i always wonder how a tricaster is able to handle all this load additonally to recording, playback, UI, macro handling, network....

    Especially since the last updates i recognized a lot short glitches on our TC8000 during normal usage, things like not responsive CS, mouse movements not constant, audio drop outs, stucking DDR playback, recordings with hickups ....
    For me this looks like as if newtek is driving the workload to the limit of this machines. (or maybe this are simple bugs, hopefully)
    Anyway i would be very careful when applying changes to the system that could cause even more workload.


    best regards,
    Walter
    TC8000 / TW850
    Cables: Belden 1694/Canara Connectors
    Cams: Sony PWM-EX3, Sony HDR-CX430/BMD HDMI2SDI

  3. #3
    Registered User
    Join Date
    Jul 2009
    Location
    Nampa, ID
    Posts
    78
    Perhaps you missed step 4. No permanent changes are made to the TC. You are simply creating a copy of a xml streaming profile. (Unless you don't follow directions.)
    Steps 10 and 11 will tell you if there is any negligible effect to your TCXD. If there is, the beauty of this is it's just a copy of a streaming profile, if it doesn't work for you either don't use it or delete it.

    If you are experiencing the issues you mentioned under normal operations with your TCXD you may have separate issues to take up with NT.

    Our TCXD and UI is running perfectly... after we addressed the heat issue anyway, but that is another discussion.

    Although not related to this thread, why would you send up three streams when you could do a server side transcode? The way you are going at it you have much higher location bandwidth requirements, and more chances for the keyframes of the various streams to get out of alignment during transit (assuming you are auto bitrate switching in your players) and higher locale machine loads, both physical and heat loads (which means more AC too), then you also now require more physical space for a streaming system (and screens, etc) too. We send up one, nice clear 720p stream (thanks to this tutorial) and transcode (technically transrate) to 5 keyframe aligned levels on the server side, the stream is then pushed to Youtube, Justin.tv, livestream, ustream, Roku, in addition to our own web site viewers. 25-30% Server CPU load (16 core Wowza virtual machine with all settings maxed out) (load includes OS, streaming control panel, Wowza and viewers). I could understand if you were doing 1080, then you'd need a local encoder with more power, but we've done the 3 stream thing and it was always a hassle. Server side transcoding makes it much simpler on location, more reliable and a lighter footprint for gear, and in our case less AC required for the truck too.
    Last edited by spotduster; 06-03-2014 at 08:14 AM.

  4. #4
    Registered User
    Join Date
    Oct 2012
    Location
    Munich, Germany
    Posts
    80
    Quote Originally Posted by spotduster View Post
    Perhaps you missed step 4. No permanent changes are made to the TC. You are simply creating a copy of a xml streaming profile. (Unless you don't follow directions.)
    Steps 10 and 11 will tell you if there is any negligible effect to your TCXD. If there is, the beauty of this is it's just a copy of a streaming profile, if it doesn't work for you either don't use it or delete it.

    If you are experiencing the issues you mentioned under normal operations with your TCXD you may have separate issues to take up with NT.

    Our TCXD and UI is running perfectly... after we addressed the heat issue anyway, but that is another discussion.
    Yes, this is discussion on it's own that might fill hundert of forum posts.

    Although not related to this thread, why would you send up three streams when you could do a server side transcode? The way you are going at it you have much higher location bandwidth requirements, and more chances for the keyframes of the various streams to get out of alignment during transit (assuming you are auto bitrate switching in your players) and higher locale machine loads, both physical and heat loads (which means more AC too), then you also now require more physical space for a streaming system (and screens, etc) too. We send up one, nice clear 720p stream (thanks to this tutorial) and transcode (technically transrate) to 5 keyframe aligned levels on the server side, the stream is then pushed to Youtube, Justin.tv, livestream, ustream, Roku, in addition to our own web site viewers. 25-30% Server CPU load (16 core Wowza virtual machine with all settings maxed out) (load includes OS, streaming control panel, Wowza and viewers). I could understand if you were doing 1080, then you'd need a local encoder with more power, but we've done the 3 stream thing and it was always a hassle. Server side transcoding makes it much simpler on location, more reliable and a lighter footprint for gear, and in our case less AC required for the truck too.
    Server side transcoding or using an in between service doing transcoding is number one topic on my wishlist :-) but unfortunately the CDN that we are using, does not offer such service, nor does he makes it easy for others to offer such.
    We use new.livestream.com with a basic package. For multibitrate streaming you have to use their own application to deliver content.
    So the only chance i see is, to setup a own capable windows machine at a server colocation place where we deliver our single stream, where it then gets feed into the livestream application, that itself does the single stream encoding and delivering then.

    And yes, this is a money issue. As most of our streams are not get payed directly we have to get the cost for monthly payment down as possible and so new.livestream.com was/is the only available option for us right now.

    best regards,
    Walter




    best regards,
    Walter
    Last edited by Labmaster; 06-03-2014 at 06:49 PM.
    TC8000 / TW850
    Cables: Belden 1694/Canara Connectors
    Cams: Sony PWM-EX3, Sony HDR-CX430/BMD HDMI2SDI

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •