Shop OBEX P1 Docs P2 Docs Learn Events
Why is the Slingbox so slow with the propeller? — Parallax Forums

Why is the Slingbox so slow with the propeller?

Mark BramwellMark Bramwell Posts: 56
edited 2007-10-04 14:45 in Propeller 1
I realize that many here do not have a slingbox http://en.wikipedia.org/wiki/Slingbox

I connect my slingbox to the output of my satellite receiver. I connect my TV to the slingbox. I connect to the Slingbox with my laptop via tcp/ip
I can watch TV shows on my laptop with really good resolution, less than 1 second delay (remember: I am in the same room viewing live on the TV)

If I hook up the TV output of the propeller to the slingbox, I can view it live on the TV as well as remotely on the laptop. Unlike the previous test, there is about a 15 second delay between the video being viewed on the TV versus seen on the laptop (the propeller slowly changes some numbers on the screen).

The real video had lots of movement. The propeller is almost static.

Anyone have any idea why the slingbox would have such a slow update rate for the propeller? I have tried all 'fast action' versus 'high resolution' types of settings.

Any chance the output of the propeller is not exactly NTSC and the slingbox is struggling?
I am using the standard 'yellow jack' composite signal, not S-video or component.

FYI: I am using the slingbox to view the TV output of the propeller remotely with the slingbox; sending TV remote code signals and the propeller decoding them and acting upon them.

Comments

  • Harrison.Harrison. Posts: 484
    edited 2007-10-03 23:51
    Could it possibly be some sort of compression that relies on dropping frames if there is not enough pixel change on the screen? It could be that the frames only force refresh every 15 seconds, and that the small number changes on the screen are not enough to force the slingbox to waste bandwidth updating the steam.
  • RaymanRayman Posts: 14,162
    edited 2007-10-03 23:55
    That's what I'm thinking too. Are you doing the "Graphics_Demo"? That one has a decent amount of motion...
  • Mark BramwellMark Bramwell Posts: 56
    edited 2007-10-04 00:11
    No, I am running my own program. I'll give it a try this weekend to see if I was to change the background color with each number change, if that would speed up the update.

    I'll also try the color graphics demo.
  • LawsonLawson Posts: 870
    edited 2007-10-04 02:36
    Mark Bramwell said...
    Unlike the previous test, there is about a 15 second delay between the video being viewed on the TV versus seen on the laptop (the propeller slowly changes some numbers on the screen).

    The real video had lots of movement. The propeller is almost static.

    welcome to the joys of video compression. The sling-box likely uses one of microsoft's WMV compression algorithms. But, looking at the relatively old MPEG-2 codec gives all the clues needed to see why this video skip happens. ( en.wikipedia.org/wiki/MPEG-2#Video_coding_.28simplified.29 en.wikipedia.org/wiki/Video_compression should also be enlightening)

    MPEG-2 has several parts. A lossy picture compression system similar to JPEG, A motion prediction based compression, and lossless compression to pack the final data as tightly as possible. What's catching you is the motion prediction stage. The simplest form of motion prediction is to simply take the difference between successive frames of video and compress that instead of the raw data. Of course this differencing process introduces errors over time so key frames that are based only on a single frame of source data are occasionally sent. These key frames give you the "about 15 second delay" that you saw. Key frames are big and sent only when needed. (like every 15 seconds)

    Basically, the few changing numbers is such a tiny change in the image that the slingbox doesn't bother to even send data on the changes. Only when a key frame is sent will a change show. I bet the video looks like it has a really low frame rate.

    My 2 cents,
    Marty

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Lunch cures all problems! have you had lunch?
  • Mark BramwellMark Bramwell Posts: 56
    edited 2007-10-04 03:32
    I understand the compression part and I understand that only changes need to be sent. The fact is no changes are being sent except at 15 second intervals. Makes me wonder if I could introduce some sort of video event that can not be seen yet causes the compression to send a full packet. I would cause that event to occur when the numbers change. The fact is I have tried hard to cause no flicker. If I still had the flicker, my screen updates would probably be real-time. Right now it is not an interactive system; I push a button.... wait 15 seconds.... push another button..... wait 15 seconds....
  • LawsonLawson Posts: 870
    edited 2007-10-04 13:52
    try slowly changing background color a little bit each time the Prop's display is updated. That won't be distracting to a user, and should be more than enough change to get it to send data between Key-frames. Alternately overlaying some random noise on the display should also work.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Lunch cures all problems! have you had lunch?
  • CJCJ Posts: 470
    edited 2007-10-04 14:45
    have you tried using an interlaced mode? I ran into pretty much the same issue with an IPTV until I switched to interlaced, now it runs perfectly

    set the interlace bit and double the vertical expansion is all it should take

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Parallax Forums - If you're ready to learn, we're ready to help.
Sign In or Register to comment.