Â鶹¹ÙÍøÊ×Ò³Èë¿Ú

IMDA released their , baselining what an Internet Radio device is, they have been working in parallel on some metadata guidelines.

" />
« Previous | Main | Next »

Identifying your Internet Radio services

Post categories: ,Ìý,Ìý

Alan Ogilvie Alan Ogilvie | 15:00 UK time, Monday, 16 November 2009

A quick posting about our involvement with the (IMDA). The organisation began in late 2008 and the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú is a .

We are seeing many devices that have been associated with traditional broadcasting methods starting to capitalise in the IP world to give listeners new experiences either not provided by, or that improve on, traditional broadcasting methods. We've seen a lot of activity recently around Internet Radio devices and the IMDA has released their setting out the functional features of these devices. The IMDA has also been working, in parallel, on some metadata guidelines.

I chair the IMDA's Metadata Working Group (MWG). We've been hard at work trying to specify how broadcasters, big or small, can expose their Internet Radio services in an agreed way - quite a challenge. Members include device manufacturers, aggregators of internet radio streams and broadcasters. It has been great to see the views from the different angles of the industry and see them working together for a shared purpose: to make the internet radio experience better for listeners.

Working for a broadcaster, I understand that in order to maximise the potential of our media we need to be able to support its delivery by exposing appropriate metadata - ranging from a completely low-level functional aspect, through to services experienced directly by the listener. Through the MWG we have been able to begin specifying how the industry could do this. Initially we've been focussing on how to identify a broadcaster's live internet streams. For example, how does the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú properly expose the various formats, transports and metadata of our live internet streams that would allow device manufacturers and aggregators to consistantly give our listeners the best experience through their Internet Radio device? It requires all those involved in the chain to be aligned to certain working practices, and perhaps standards.

It's early days yet, and the IMDA is reviewing existing standards to see if anything is suitable or could be extended - no point in re-inventing the wheel. They want to make sure that any hurdles to adoption for broadcasters are small or non-existent, so that broadcasters across the world are able to follow these guidelines and make their media available in the same way.

I should have an update in January about this.

Comments

  • Comment number 1.

    Great to see the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú actively involved in the development of Internet Radio standards. Particularly because it is in collaboration with manufacturers and aggregators. I for one hope this quickly translates into higher quality, more reliable internet radio services. I also hope that the initial focus is on stream reliability, minimal lag and phenomenal sound quality through international standards instead of proprietary technology like Flash and WMA. Without those aspects being rock solid, few will have the appetite to bother with the interactive potential the internet has to offer. Standardised metadata should make a significant contribution toward that.

  • Comment number 2.

    All fine words. But wrapping up the 192kpbs AAC feeds in Adobe's obscure, proprietary RTMP protocol for Flash clients hardly allows the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú to claim the moral high ground.

  • Comment number 3.

    "RTMP is now available as an to create products and technology that enable delivery of video, audio, and data in the open AMF, SWF, FLV, and F4V formats compatible with Adobe Flash Player."

  • Comment number 4.

    @3

    I'm sure that the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú faces all sorts of difficult trade offs when making decisions about which technologies to select for internet output. Why did you choose WMA for the live direct feeds when AAC is obviously available since you use it for the flash player streams?

    I'm don't particularly want to criticise the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú. I just know that AAC format streams start to play more quickly than WMA ones particularly at high bit rates and would like to get them on my internet radios.

  • Comment number 5.

    I'm going to summarise the question:

    Q: Why can't the simulcast Flash streams, which are encoded in AAC Family codecs, be reused for different clients? (note: we aren't talking about listen again, file-based clipping here)

    A: As with any streaming solution - the encoder isn't often the primary issue, it's the distribution servers. In order for a stream to playback in Flash it must be 'wrapped' in the appropriate transport methods that Flash clients understand. Flash Media Server distributes using RTMP family protocols - and the way that Flash Media Server consumes data from the encoder is via RTMP protocols too. Therefore the encoder must wrap it's output to the server in RTMP. Our current encoders follow the specifications of delivering to Flash for this and, despite the underlying streaming being in AAC Family, is unusable for other clients that do not understand RTMP. Compare with our 3GPP-compliant streaming for mobile (which is available on mobile iPlayer) - this is delivered in 3GP compliant streams and means that the underlying codec which other devices could play is restricted to only players that are capable of consuming 3GP streams.

    Hopefully you feel this is an answer to your question?

    From a public service position, and has been stated in other locations, we evaluate all services using our four measures of public value - Reach, Value, Quality and Impact. Which means that all our services are evaluated against these during selection, implementation and review. In turn this means we are always interested in the appropriateness of our streaming solutions and evaluate new or undeserved audiences (by looking at 'clients').

  • Comment number 6.


    @JJ
    Agree. While RTMP is now 'open' this is because it is old and has been widely reverse engineered. Adobe's new RTMPE is not open/standardized and hence adopting Flash means buying into a proprietary approach. It would be better to broadcast the audio streams using a standards-based content-type (e.g. audio/mpeg or audio/aac) that allows many different clients to be developed.

    [also See my comment on another thread for this (comment 59 in /blogs/radiolabs/2009/10/realmedia_an_update.shtml%29%5D

    @Alan
    I commend the IMDA initiative and look forward to the release of the technical specifications. At the risk of over-simplification for the metadata solution, a simple XML list with each entry having a media stream URL (to keep machines happy) and a title (to keep humans happy) would seem adequate at first glance, but no doubt the problem is more complex than that...

  • Comment number 7.

    This comment was removed because the moderators found it broke the house rules. Explain.

Ìý

Â鶹¹ÙÍøÊ×Ò³Èë¿Ú iD

Â鶹¹ÙÍøÊ×Ò³Èë¿Ú navigation

Copyright © 2015 Â鶹¹ÙÍøÊ×Ò³Èë¿Ú. The Â鶹¹ÙÍøÊ×Ò³Èë¿Ú is not responsible for the content of external sites. Read more.

This page is best viewed in an up-to-date web browser with style sheets (CSS) enabled. While you will be able to view the content of this page in your current browser, you will not be able to get the full visual experience. Please consider upgrading your browser software or enabling style sheets (CSS) if you are able to do so.