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

Re: indexing into media files? (resend)

Expand Messages
  • David Hall
    ... I wrote Rich off list, but isn t there a way for some of the various media types to directly specify where you want the content to start playing? I thought
    Message 1 of 9 , Oct 25, 2005
    • 0 Attachment
      --- In rss-media@yahoogroups.com, "Patrick Schmitz" <cogit@l...> wrote:
      >
      > I think SMIL is much too heavyweight for what Rich (and many others) is
      > after. We should be able to describe temporal extents within MediaRSS,
      > IMO.
      >
      > See also http://www.id3.org/drafts/id3v2_chapters-2005101201.txt for
      > some related work at the ID3 header level.
      >
      > Patrick

      I wrote Rich off list, but isn't there a way for some of the various
      media types to directly specify where you want the content to start
      playing? I thought both Real and MS had such capabilities. Either url
      or playlist based? Then you'd treat the various segments just like any
      other media type within Media RSS.

      My fear is the opposite of yours - turning Media RSS into something
      much too heavyweight for the majority of users and needs.
    • Andreas Haugstrup Pedersen
      On Tue, 25 Oct 2005 18:47:28 +0200, David Hall ... With Quicktime you can do it both with attributes on the embed element (or params on
      Message 2 of 9 , Oct 25, 2005
      • 0 Attachment
        On Tue, 25 Oct 2005 18:47:28 +0200, David Hall <daviddhall@...>
        wrote:

        > I wrote Rich off list, but isn't there a way for some of the various
        > media types to directly specify where you want the content to start
        > playing? I thought both Real and MS had such capabilities. Either url
        > or playlist based? Then you'd treat the various segments just like any
        > other media type within Media RSS.

        With Quicktime you can do it both with attributes on the embed element (or
        params on the object element) and with a very simple SMIL wrapper. I
        imagine you can do something along those lines in Windows Media as well.

        > My fear is the opposite of yours - turning Media RSS into something
        > much too heavyweight for the majority of users and needs.

        +1; I don't see why this should be a part of a syndication format.

        - Andreas
        --
        <URL:http://www.solitude.dk/>
        Commentary on media, communication, culture and technology.
      • Brian Williams
        Just wanted to point out that MRSS 1.1.0 includes the text element, which is designed for describing the transcript, lyrics, closed captioning, etc. of the
        Message 3 of 9 , Oct 25, 2005
        • 0 Attachment
          Just wanted to point out that MRSS 1.1.0 includes the text element, which is
          designed for describing the transcript, lyrics, closed captioning, etc. of
          the media object, synched with timestamps.

          I think there are advantages to syndicating metadata, and MRSS already
          includes a fair amount of what might be thought of as "non-essential"
          metadata (for example, keywords). Not sure how the proposal was any
          different. On the other hand, simplicity in a specification is key to
          adoption...

          --Brian
        • Brendan Quinn
          I contacted Chris Newell, the BBC R&D guy who wrote that ID3 spec proposal (which looks like it s becoming reality according to the ID3 site...?) and he
          Message 4 of 9 , Oct 25, 2005
          • 0 Attachment
            I contacted Chris Newell, the BBC R&D guy who wrote that ID3 spec
            proposal (which looks like it's becoming reality according to the ID3
            site...?) and he pointed me towards some work his group has been doing
            with the TV Anytime format (which we have discussed here before).

            After rummaging around their specs, I eventually found this example in
            the "SP004v12 Content Referencing" spec:

            <Result CRID="crid://broadcaster.com/ajcnd" status="resolved"
            complete="true" acquire="all">
            <LocationsResult>
            <Locator
            instanceMetadataId="imi:1">dvb://1.4ee2.3f4;4f5@2001-03-27T18:00:00.00+0
            1:00</Locator>
            <DecomposedLocator instanceMetadataId="imi:metadataProv.com/2"
            start="2001-03-29T18:00:00.00">ftp://myserver.example.com/directory12/he
            llo.mp3</DecomposedLocator>
            <DecomposedLocator start="2001-03-29T18:00:00.00"
            end="2001-04-03T18:00:00.00">ftp://myserver.example.com/directory12-back
            up/hello.mp3</DecomposedLocator>
            </LocationsResult>
            </Result>

            So they have two versions of the "locator" element; one for things that
            inherently handle timed sections such as DVB locators, and a
            "DecomposedLocator" element which provides the data that the format
            itself lacks.

            So perhaps it comes down to two options:
            - the need for timing information in a feed is so urgent that we can't
            wait for the formats themselves to catch up, and we need to do it in the
            Media RSS feed (which is the decision that TV Anytime took)
            - or it's not so urgent, we can wait for the feeds to catch up (eg, for
            the ID3 chapter tag so be standardised and implemented)

            Does that help to focus the discussion?

            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

            > -----Original Message-----
            > From: rss-media@yahoogroups.com
            > [mailto:rss-media@yahoogroups.com] On Behalf Of David Hall
            > Sent: 25 October 2005 17:47
            > To: rss-media@yahoogroups.com
            > Subject: [rss-media] Re: indexing into media files? (resend)
            >
            >
            > --- In rss-media@yahoogroups.com, "Patrick Schmitz"
            > <cogit@l...> wrote:
            > >
            > > I think SMIL is much too heavyweight for what Rich (and
            > many others)
            > > is after. We should be able to describe temporal extents within
            > > MediaRSS, IMO.
            > >
            > > See also
            > http://www.id3.org/drafts/id3v2_chapters-> 2005101201.txt for
            >
            > > some related work at the ID3 header level.
            > >
            > > Patrick
            >
            > I wrote Rich off list, but isn't there a way for some of the
            > various media types to directly specify where you want the
            > content to start playing? I thought both Real and MS had such
            > capabilities. Either url or playlist based? Then you'd treat
            > the various segments just like any other media type within Media RSS.
            >
            > My fear is the opposite of yours - turning Media RSS into
            > something much too heavyweight for the majority of users and needs.
            >
            >
            >
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            > --------------------~-->
            > Fair play? Video games influencing politics. Click and talk
            > back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/2U_rlB/TM
            > --------------------------------------------------------------
            > ------~->
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >

            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.
          • George T.S. John
            Message ... From: Patrick Schmitz To: rss-media@yahoogroups.com Sent: Tuesday, October 25, 2005 12:22 PM Subject: RE: [rss-media] indexing into media files?
            Message 5 of 9 , Oct 25, 2005
            • 0 Attachment
              Message
               
              ----- Original Message -----
              Sent: Tuesday, October 25, 2005 12:22 PM
              Subject: RE: [rss-media] indexing into media files? (resend)

              I think SMIL is much too heavyweight for what Rich (and many others) is after. We should be able to describe temporal extents within MediaRSS, IMO. 
               
              See also http://www.id3.org/drafts/id3v2_chapters-2005101201.txt for some related work at the ID3 header level.
               
              Patrick
              -----Original Message-----
              From: rss-media@yahoogroups.com [mailto:rss-media@yahoogroups.com] On Behalf Of Gareth Andrew
              Sent: Tuesday, October 25, 2005 6:08 AM
              To: rss-media@yahoogroups.com
              Subject: Re: [rss-media] indexing into media files? (resend)

              Rich,

              It sounds like SMIL [1] is what you're after.

              [1] http://www.w3.org/AudioVideo/

              On Mon, 2005-10-24 at 13:10 -0700, Rich Morin wrote:
              > [Dunno if this got lost somewhere or simply seemed too lame to merit
              >   a response.  Anyway, trying again...  -r]
              >
              > Looking at the spec, I don't see any obvious way to index into
              > a media file.  For example, let's say that I want to tie "jump"
              > to specified points in the material.  Please let me know what,
              > if any, facilities exist to support this.
              >
              > -r

            • Patrick Schmitz
              There are clipbegin and end mechanisms in many players, but I do not think you want to have player or media specific parameters in a general interchange format
              Message 6 of 9 , Oct 26, 2005
              • 0 Attachment
                Message
                There are clipbegin and end mechanisms in many players, but I do not think you want to have player or media specific parameters in a general interchange format like this if you can avoid it. I think we can specify something quite simple that does the job. We're working on a proposal right now.
                 
                Patrick
                -----Original Message-----
                From: rss-media@yahoogroups.com [mailto:rss-media@yahoogroups.com] On Behalf Of David Hall
                Sent: Tuesday, October 25, 2005 9:47 AM
                To: rss-media@yahoogroups.com
                Subject: [rss-media] Re: indexing into media files? (resend)

                --- In rss-media@yahoogroups.com, "Patrick Schmitz" <cogit@l...> wrote:
                >
                > I think SMIL is much too heavyweight for what Rich (and many others) is
                > after. We should be able to describe temporal extents within MediaRSS,
                > IMO. 

                > See also http://www.id3.org/drafts/id3v2_chapters-2005101201.txt for
                > some related work at the ID3 header level.

                > Patrick

                I wrote Rich off list, but isn't there a way for some of the various
                media types to directly specify where you want the content to start
                playing? I thought both Real and MS had such capabilities. Either url
                or playlist based? Then you'd treat the various segments just like any
                other media type within Media RSS.

                My fear is the opposite of yours - turning Media RSS into something
                much too heavyweight for the majority of users and needs.



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