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

Re: [rss-media] Re: playerUrl explained

Expand Messages
  • Suzan Foster
    ... Isn t that what you already get from the mime-type in the type attribute? grtz, su.
    Message 1 of 9 , Dec 17, 2004
    • 0 Attachment
      On Dec 18, 2004, at 12:52 AM, daviddhall@... wrote:

      > It would be interesting if we could tie in the notion of
      > "transport"
      > that I saw in Vadim's Enhanced Enclosures support document.
      > The "transport" would be the method in which to view/get the
      > media
      > object. Whether it be bitTorrent, our playerUrl (html), or some other
      > alternative client or method.

      Isn't that what you already get from the mime-type in the type
      attribute?

      grtz, su.
    • ecomputerd
      You don t quite get transport from mime type. It s close though. The mime type should specify the final content type. This is unable to convey the method of
      Message 2 of 9 , Dec 17, 2004
      • 0 Attachment
        You don't quite get "transport" from mime type. It's close though.
        The mime type should specify the final content type. This is unable
        to convey the method of transport such as BitTorrent, HTTP, FTP, or
        other method. I agree that the suggested use is close to "transport"
        except that the file is not downloaded. playerUrl and
        playerHeight/Width are bad names, but I'm beginning to get the
        purpose of them.

        It's currently sounding like a "big media" concept, where the "HTML
        markup" will be suggested as "enhancments for the user" while in
        reality it is likely to be "pushing content and advertising from the
        producer to the consumer". It won't get many accolades from the
        community, but if you can position it somehow as a generic
        link/pointer to content, you might get it accepted. It doesn't sound
        like a "background" delivery model such as enclosures. Using
        playerUrl within an item now sounds like the item is "a description
        of what you'll see when you click on this (playerUrl) link".

        I think I understand the concept, and it sounds like it's diverging
        from the "enclosure" model when playerUrl is used. Not necessarily
        bad, just different uses.


        --- In rss-media@yahoogroups.com, Suzan Foster <su@i...> wrote:
        >
        > On Dec 18, 2004, at 12:52 AM, daviddhall@y... wrote:
        >
        > > It would be interesting if we could tie in the notion of
        > > "transport"
        > > that I saw in Vadim's Enhanced Enclosures support document.
        > > The "transport" would be the method in which to view/get the
        > > media
        > > object. Whether it be bitTorrent, our playerUrl (html), or some
        other
        > > alternative client or method.
        >
        > Isn't that what you already get from the mime-type in the type
        > attribute?
        >
        > grtz, su.
      • lord@crocodile.org
        ... other ... No. For example for a video file downloaded over bittorent, the URL will point to .torrent file with content-type app lication/x-bittorent .
        Message 3 of 9 , Dec 17, 2004
        • 0 Attachment
          --- In rss-media@yahoogroups.com, Suzan Foster <su@i...> wrote:
          >
          > On Dec 18, 2004, at 12:52 AM, daviddhall@y... wrote:
          >
          > > It would be interesting if we could tie in the notion of
          > > "transport"
          > > that I saw in Vadim's Enhanced Enclosures support document.
          > > The "transport" would be the method in which to view/get the
          > > media
          > > object. Whether it be bitTorrent, our playerUrl (html), or some
          other
          > > alternative client or method.
          >
          > Isn't that what you already get from the mime-type in the type
          > attribute?

          No. For example for a video file downloaded over bittorent, the URL
          will point to .torrent file with content-type "app
          lication/x-bittorent".
          Meanwhile, resulting file downloaded using BitTorrent will have
          content type "video/quicktime". So we have 2 content types here.
          Before trying to download file you need to know both, because you
          need to support both to ultimately being able to show the video.

          In our proposal we store "video/quicktime" as enclosure "type" and
          "application/x-bittorent" as "transport" type.

          Vadim
        • daviddhall@yahoo.com
          At it s core, it is definitely mostly a big[ger] media concept. I m guessing that few independent, small time publishers really care about the end
          Message 4 of 9 , Dec 20, 2004
          • 0 Attachment
            At it's core, it is definitely mostly a "big[ger] media" concept.
            I'm guessing that few independent, small time publishers really care
            about the end presentation of their video/audio content - however,
            larger sites often do. You'd be surprised at the number of sites who
            really don't like revealing a direct link, regardless of the size of
            their site. And while it's certainly the case that "pushing content
            and advertising" happens in these sorts of views, there are some user
            beneficial reasons behind them:

            1. Better control of the user playback experience, allowing
            bandwidth/media type selection, etc.

            2. Pushing additional content isn't always bad for the user. It's
            sometimes great to see additional videos relating to the specific
            content. For instance, if you are playing a trailer for the latest "2
            Fast 2 Furious" film (god, help you), you might want to also check
            out "Behind The Scenes" footage.

            3. Licensing requirements sometimes require this sort of restricted
            access.

            4. And as said before, as baffling as it sounds, often the larger
            media publishers do not *know* the direct link to the media object at
            the stage where most RSS feeds are generated.

            I think we are on the same page, however, that a direct link to the
            media object is preferred (which also allows for the background
            delivery model). It's just sometimes not an option for consideration
            for the RSS feed provider. Which is where the bigger question occurs:
            Is it preferable to never know about this sort of content, or to get
            it in its less desirable form?

            The intention of this attribute isn't to pull people away from the
            general nature of enclosures. We were just attempting to solve one of
            the problems we've heard repeatedly from publishers. Frankly, without
            it, they'll never reveal this content in RSS.

            We'll definitely have to ponder on how to make the information
            desired out of "playerUrl" to perhaps be both more generic and easier
            to understand. That way it could be a powerful option for controlling
            how you'd prefer to have your media content rendered to the end user.
            And that's why there might be a good tie to the
            "transport" notion.
            It's just not exactly clear at the moment.

            Any ideas on a way we could do this better?

            David Hall
            Yahoo! Search


            --- In rss-media@yahoogroups.com, "ecomputerd" <ecomputerd@y...>
            wrote:
            >
            > You don't quite get "transport" from mime type. It's close though.
            > The mime type should specify the final content type. This is unable
            > to convey the method of transport such as BitTorrent, HTTP, FTP, or
            > other method. I agree that the suggested use is close
            to "transport"
            > except that the file is not downloaded. playerUrl and
            > playerHeight/Width are bad names, but I'm beginning to get the
            > purpose of them.
            >
            > It's currently sounding like a "big media" concept, where the "HTML
            > markup" will be suggested as "enhancments for the user" while in
            > reality it is likely to be "pushing content and advertising from
            the
            > producer to the consumer". It won't get many accolades from the
            > community, but if you can position it somehow as a generic
            > link/pointer to content, you might get it accepted. It doesn't
            sound
            > like a "background" delivery model such as enclosures. Using
            > playerUrl within an item now sounds like the item is "a description
            > of what you'll see when you click on this (playerUrl) link".
            >
            > I think I understand the concept, and it sounds like it's diverging
            > from the "enclosure" model when playerUrl is used. Not necessarily
            > bad, just different uses.
            >
            >
            > --- In rss-media@yahoogroups.com, Suzan Foster <su@i...> wrote:
            > >
            > > On Dec 18, 2004, at 12:52 AM, daviddhall@y... wrote:
            > >
            > > > It would be interesting if we could tie in the notion of
            > > > "transport"
            > > > that I saw in Vadim's Enhanced Enclosures support document.
            > > > The "transport" would be the method in which to view/get the
            > > > media
            > > > object. Whether it be bitTorrent, our playerUrl (html), or some
            > other
            > > > alternative client or method.
            > >
            > > Isn't that what you already get from the mime-type in the type
            > > attribute?
            > >
            > > grtz, su.
          • ecomputerd
            I appreciate your conversation about this. My intention was to point out that the delivery models were different. But I also fully realize that integrating the
            Message 5 of 9 , Dec 20, 2004
            • 0 Attachment
              I appreciate your conversation about this. My intention was to point
              out that the delivery models were different. But I also fully
              realize that integrating the two (background and foreground
              delivery) will provide, presumably, an overall better delivery
              experience.

              When it comes down to it, it may be the case that any given RSS feed
              will provide either one or the other type, but I can easily imagine
              a blogger wanting to point to media, regardless of its presentation.
              In this use, it makes sense to provide an individual RSS "feed"
              containing one item that describes the media object. Interesting,
              but useful?

              In general, providing the type of metadata discussed here is equally
              useful to all media, whether delivered foreground or background.
              This is why I presume the desire to provide the information in a
              unified way and let the clients/users decide if they want to
              subscribe.

              I'd have to think more about the specific needs of both deliveries
              and see where their elements intersect and where there are different
              or parallel needs. (Although I won't be doing this unless you prod
              me with another post).

              Currently, this sounds to me like a parallel to mime type. I can't
              recall if I disagreed with this earlier (I might be flip-flopping).
              In the sense of mime type tells the client what to do with the file
              after downloaded. For this use, I can envision "HTML" and "Flash"
              types as well as whatever formats/files are loaded into Windows
              Media Player that provide all the additional "User Experience". I
              think the critical thing here will be whether the "User Experience"
              can be specified by one file or if it requires more than one file.

              Not sure. If you want more musings, keep posting!

              Thanks!

              --- In rss-media@yahoogroups.com, daviddhall@y... wrote:
              >
              > At it's core, it is definitely mostly a "big[ger] media" concept.
              > I'm guessing that few independent, small time publishers really
              care
              > about the end presentation of their video/audio content - however,
              > larger sites often do. You'd be surprised at the number of sites
              who
              > really don't like revealing a direct link, regardless of the size
              of
              > their site. And while it's certainly the case that "pushing
              content
              > and advertising" happens in these sorts of views, there are some
              user
              > beneficial reasons behind them:
              >
              > 1. Better control of the user playback experience, allowing
              > bandwidth/media type selection, etc.
              >
              > 2. Pushing additional content isn't always bad for the user. It's
              > sometimes great to see additional videos relating to the specific
              > content. For instance, if you are playing a trailer for the
              latest "2
              > Fast 2 Furious" film (god, help you), you might want to also check
              > out "Behind The Scenes" footage.
              >
              > 3. Licensing requirements sometimes require this sort of
              restricted
              > access.
              >
              > 4. And as said before, as baffling as it sounds, often the larger
              > media publishers do not *know* the direct link to the media object
              at
              > the stage where most RSS feeds are generated.
              >
              > I think we are on the same page, however, that a direct link to
              the
              > media object is preferred (which also allows for the background
              > delivery model). It's just sometimes not an option for
              consideration
              > for the RSS feed provider. Which is where the bigger question
              occurs:
              > Is it preferable to never know about this sort of content, or to
              get
              > it in its less desirable form?
              >
              > The intention of this attribute isn't to pull people away from the
              > general nature of enclosures. We were just attempting to solve one
              of
              > the problems we've heard repeatedly from publishers. Frankly,
              without
              > it, they'll never reveal this content in RSS.
              >
              > We'll definitely have to ponder on how to make the information
              > desired out of "playerUrl" to perhaps be both more generic and
              easier
              > to understand. That way it could be a powerful option for
              controlling
              > how you'd prefer to have your media content rendered to the end
              user.
              > And that's why there might be a good tie to the
              > "transport" notion.
              > It's just not exactly clear at the moment.
              >
              > Any ideas on a way we could do this better?
              >
              > David Hall
              > Yahoo! Search
              >
              >
              > --- In rss-media@yahoogroups.com, "ecomputerd" <ecomputerd@y...>
              > wrote:
              > >
              > > You don't quite get "transport" from mime type. It's close
              though.
              > > The mime type should specify the final content type. This is
              unable
              > > to convey the method of transport such as BitTorrent, HTTP, FTP,
              or
              > > other method. I agree that the suggested use is close
              > to "transport"
              > > except that the file is not downloaded. playerUrl and
              > > playerHeight/Width are bad names, but I'm beginning to get the
              > > purpose of them.
              > >
              > > It's currently sounding like a "big media" concept, where
              the "HTML
              > > markup" will be suggested as "enhancments for the user" while in
              > > reality it is likely to be "pushing content and advertising from
              > the
              > > producer to the consumer". It won't get many accolades from the
              > > community, but if you can position it somehow as a generic
              > > link/pointer to content, you might get it accepted. It doesn't
              > sound
              > > like a "background" delivery model such as enclosures. Using
              > > playerUrl within an item now sounds like the item is "a
              description
              > > of what you'll see when you click on this (playerUrl) link".
              > >
              > > I think I understand the concept, and it sounds like it's
              diverging
              > > from the "enclosure" model when playerUrl is used. Not
              necessarily
              > > bad, just different uses.
              > >
              > >
              > > --- In rss-media@yahoogroups.com, Suzan Foster <su@i...> wrote:
              > > >
              > > > On Dec 18, 2004, at 12:52 AM, daviddhall@y... wrote:
              > > >
              > > > > It would be interesting if we could tie in the notion of
              > > > > "transport"
              > > > > that I saw in Vadim's Enhanced Enclosures support document.
              > > > > The "transport" would be the method in which to view/get the
              > > > > media
              > > > > object. Whether it be bitTorrent, our playerUrl (html), or
              some
              > > other
              > > > > alternative client or method.
              > > >
              > > > Isn't that what you already get from the mime-type in the type
              > > > attribute?
              > > >
              > > > grtz, su.
            • Lucas Gonze
              On Mon, 20 Dec 2004 18:32:39 -0000, daviddhall@yahoo.com ... I have found that this is a huge problem. It does have to be addressed. A real world example is
              Message 6 of 9 , Dec 20, 2004
              • 0 Attachment
                On Mon, 20 Dec 2004 18:32:39 -0000, daviddhall@...
                <daviddhall@...> wrote:
                > You'd be surprised at the number of sites who
                > really don't like revealing a direct link, regardless of the size of
                > their site

                I have found that this is a huge problem. It does have to be
                addressed. A real world example is that webjay.org (my own project)
                gets a steady stream of complaints about deep linking.

                With XSPF, the equivalent functionality for playerUrl is the
                /trackList/track/info element.

                The drawback to the MRSS design is that presentation info is mixed in
                with other metadata. I can see why you did it this way -- before
                opening a window on playerUrl you need the window size. Still, I
                suspect there's a much tidier way to approach that requirement.

                - Lucas Gonze
              Your message has been successfully submitted and would be delivered to recipients shortly.