Loading ...
Sorry, an error occurred while loading the content.

Using RSS / Media RSS to publicise continuous streams of audio/video content rather than clips?

Expand Messages
  • Brendan Quinn
    Hi all, We re thinking of using RSS (and therefore the Media RSS extension) to publicise our audio and video streams, partly to ensure everyone uses the
    Message 1 of 2 , Dec 15, 2006
    View Source
    • 0 Attachment
      Using RSS / Media RSS to publicise continuous streams of audio/video content rather than clips?

      Hi all,

      We're thinking of using RSS (and therefore the Media RSS extension) to publicise our audio and video streams, partly to ensure everyone uses the correct addresses (for example make sure that users link to the .ram file which stays constant rather than directly to the .ra file which can change when we move servers) and partly to make sure everyone is aware of the full range of streams that we offer.

      Media RSS seems to have anticipated this use case through the 'expression="nonstop"' attribute, which is a good start.

      A few questions:

      - Does anyone else use Media RSS to promote continuous streams as opposed to podcasts or other downloadable content?

      - Does anyone think it's a bad idea to use RSS in this way, and that we should choose another mechanism? I admit that it's a bit of a bastardisation of the idea behind RSS, in that it's not really announcing new content, it's just a way of linking to content that always exists. Having said that, we would add new streams to this file as new stations come on the air, new formats are added, etc. (if you think we should use another mechanism, please suggest one ;-)

      - Has anyone seen other media providers do this, are there examples we could follow or people we could work with to define a best practice?

      - Do any RSS readers / podcast "catchers" support audio and video streams, either using the "media:player" element or "media:content" with the "url" attribute pointing to the stream?

      - Client authors, do you have any suggestions for how we should do this to work with your players in the most effective way?

      - And now a more specififc Media RSS related question: we are offering multicast video streams right now, as a trial. We would like to inform people of this fact in the RSS feed, as not all ISPs support multicast video… but where should we say it, and how? In a way it could be called a "restriction" but we would prefer to say that multicast is a feature rather than a limitation!

      Thanks for any feedback you can provide! Feel free to respond privately if you don't feel your answer would be useful to the wider community.

      Regards,

      Brendan.
      --
      Brendan Quinn | Technical Architect | bbc.co.uk
      Broadcast Centre BC5 B6, Media Village, 201 Wood Lane London W12 7TP
      Brendan.Quinn@... | +44 (0)20 800 85097 | +44 (0)7900 847 358


      http://www.bbc.co.uk
      This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
      If you have received it in error, please delete it from your system.
      Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
      Please note that the BBC monitors e-mails sent or received.
      Further communication will signify your consent to this.
    • Rik Sagar
      If you do use an rss to point to a stream I wonder what the policy should be for the tag of the item? I use the guid to prevent re-downloading the same
      Message 2 of 2 , Jan 4, 2007
      View Source
      • 0 Attachment
        If you do use an rss to point to a stream I wonder what the policy
        should be for the <guid> tag of the item?

        I use the guid to prevent re-downloading the same content more than
        once, so I think the risk would be that I only download your .ram file
        once - even if you update the .ram file to point to a new server. I
        wouldn't see the update unless you change the guid of the feed item.
        Don't know if I'm doing the right thing or not.

        Is it OK to have a rtsp: protocol in the <enclosure>? and/or
        <media:content>? I would think so, but I don't know for sure.

        Rik.

        p.s., I love the content that the BBC is making available through
        podcasts! Keep it up.


        --- In rss-media@yahoogroups.com, "Brendan Quinn" <Brendan.Quinn@...>
        wrote:
        >
        > Hi all,
        >
        > We're thinking of using RSS (and therefore the Media RSS extension) to
        > publicise our audio and video streams, partly to ensure everyone uses
        > the correct addresses (for example make sure that users link to the .ram
        > file which stays constant rather than directly to the .ra file which can
        > change when we move servers) and partly to make sure everyone is aware
        > of the full range of streams that we offer.
        >
        > Media RSS seems to have anticipated this use case through the
        > 'expression="nonstop"' attribute, which is a good start.
        >
        > A few questions:
        >
        > - Does anyone else use Media RSS to promote continuous streams as
        > opposed to podcasts or other downloadable content?
        >
        > - Does anyone think it's a bad idea to use RSS in this way, and that we
        > should choose another mechanism? I admit that it's a bit of a
        > bastardisation of the idea behind RSS, in that it's not really
        > announcing new content, it's just a way of linking to content that
        > always exists. Having said that, we would add new streams to this file
        > as new stations come on the air, new formats are added, etc. (if you
        > think we should use another mechanism, please suggest one ;-)
        >
        > - Has anyone seen other media providers do this, are there examples we
        > could follow or people we could work with to define a best practice?
        >
        > - Do any RSS readers / podcast "catchers" support audio and video
        > streams, either using the "media:player" element or "media:content" with
        > the "url" attribute pointing to the stream?
        >
        > - Client authors, do you have any suggestions for how we should do this
        > to work with your players in the most effective way?
        >
        > - And now a more specififc Media RSS related question: we are offering
        > multicast video streams right now, as a trial. We would like to inform
        > people of this fact in the RSS feed, as not all ISPs support multicast
        > video... but where should we say it, and how? In a way it could be
        > called a "restriction" but we would prefer to say that multicast is a
        > feature rather than a limitation!
        >
        > Thanks for any feedback you can provide! Feel free to respond privately
        > if you don't feel your answer would be useful to the wider community.
        >
        > Regards,
        >
        > Brendan.
        > --
        > Brendan Quinn | Technical Architect | bbc.co.uk
        > Broadcast Centre BC5 B6, Media Village, 201 Wood Lane London W12 7TP
        > Brendan.Quinn@... | +44 (0)20 800 85097 | +44 (0)7900 847 358
        >
        > http://www.bbc.co.uk/
        > This e-mail (and any attachments) is confidential and may contain
        personal views which are not the views of the BBC unless specifically
        stated.
        > If you have received it in error, please delete it from your system.
        > Do not use, copy or disclose the information in any way nor act in
        reliance on it and notify the sender immediately.
        > Please note that the BBC monitors e-mails sent or received.
        > Further communication will signify your consent to this.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.