| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

play

Page history last edited by Vasile 14 years, 12 months ago

 

Media Dispatcher

The media dispatcher (play) is a program to identify URL and filename extensions and mime types, and locate and execute the appropriate player.

Version: 1.00

Status: Done

 

 



 

Description

 

Whenever the user selects a media file in the TV interface, dvdplayer will either play/display the file itself or use an external player to do that. We can replace all the original external players with the new dispatcher, in order to have more control over the file types without patching too much the original dvdplayer.

 

The dispatcher will call a specific player based on the file extension (in the simple mode) or on the first argument (in the fileplayer emulation mode). The real players are /bin/player/XXX, where XXX is the usual extension of the respective format, as shown in the table below:

 

Extensions Player Notes
avi avi original fileplayer.bin
mp3 mp3 the new mp3play
mp4, m4v, m4a mp4  
mpeg, mpg, dat, m2v mpeg  
mkv mkv not yet implemented
ogg ogg original fileplayer.bin
wav, pcm, au pcm original fileplayer.bin
ac3, dts thx original fileplayer.bin
wma wma original fileplayer.bin
jpeg, jpg jpeg not yet implemented
sh, app, ext - directly executed
url - processed by the dispatcher and the url is passed to the mp3 player

 

As you can see, the dispatcher also handles some new extensions. Files with .ext, .sh or .app extension are shell scripts, and the dispatcher will directly execute them. This is useful to launch other MG35 applications through the on-screen UI, e.g. for rescanning the network, resetting the network interface, etc.

 

Also new are the files with .url extension, which are used to specify internet streams. The dispatcher will parse the content of the file to get the real URL of the stream, and pass it to the MP3 player application (/bin/player/mp3). This is how internet radio streams are played in our new firmware versions. .url files are plain text files containing the URL of the stream, but we also support standard .url files created by Internet Explorer (which are in fact .ini files).

 

 

Usage

 

 

   play <media_file> - calls the real player for the file, based on its extension

   fileplayer.bin <file_type> <media_file> - calls the player for the file, based on <file_type>
   mpegplayer.bin <file_type> <media_file>
   mp4play        <file_type> <media_file>

 

Build procedure

 

License

 

 

    Media Dispatcher
    Copyright (C) 2008 gardez <gardez@users.sf.net>

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License along
    with this program; if not, write to the Free Software Foundation, Inc.,
    51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

 

Todo

 

History

Version 1.00 - [John, 2008-07-09]

  • Initial version

 

Comments

 

  • John: So, that's tested working now. As for IconFile, how many different ways of specifying metadata are standard (for us)? How do we handle conflicts between the metadata in the .URL file and the ID3v1/v2 metadata of the stream?. Also, just to warn you in advance, this conversation is a rabbit hole, and will need its own page.
    • VB: we can leave the IconFile on the todo list, together with album cover display. I guess we may also have issues with color palettes.
      • John: I skipped over INI as a media metadata format since it doesn't handle multiple line content for (eg) descriptive text; thus we have msgtable

 

  • VB: extending .url files for other stream types (e.g. aac) will ask to open the stream twice: first in the dispatcher to get the stream format and secondly in the player itself. We can avoid that by integrating the dispatcher with the player(s), but then we're back to the original monolithic fileplayer.bin :-(. Or we can create an external /bin/players/url, accepting some code duplication/sharing with mp3play and aacplay. The only downside I can see is that the url player will increase the firmware size. Are shared libraries supported?

 

  • VB: do you think we can extend the url mechanism to other types of files? For example, if the resource specified is a jpg file, MG35 could eventually pass the file jpegplayer. Possible use: a weather app working on an external server could get info from an rss feed or webpage and assemble a jpg file, which can then be displayed by MG35 (kind of a quick-and-dirty browser replacement). More generally, "play" should probably just parse the url file and pass the resource to the respective player, based on file extension (instead of automatically assuming it's an audio stream). To extend it even more, the URL file can contain 2 parameters inside: the first is the resource URL, and the second the filetype (for resources which cannot be dispatched by the extension, e.g. an image which does not have the .jpg extension). One can even think at an application to view Flickr albums.

 

  • John: Assuming an HTTP transport, streams should be identified by the Content-Type header, not the file extension. If we want the dispatcher to dispatch based on the actual URL content type, we could open the URL and check the headers and then run the appropriate player. File extensions have largely become MIME associations too, so perhaps we need an integrated mime system for the MG.

 

  • VB: as always, you have a better solution :-) since the bulk of the content is probably sent over HTTP. It still needs to open the URL twice (once in dispatcher, and once by the player) but it shouldn't be a big penalty. OTOH, it solves the issue of dispatching AAC streams to a different program than mp3s. For other transport protocols (if ever needed), we can use the second argument in the url file to indicate the type.

 

  • John: What do you think about opening the stream in the dispatcher, reading the headers, and passing them to the player via stdin, along beside the already open content stream?
    • VB: this will break the compatibility with existing players, isn't it? I'm not too concerned about opening the stream twice...
    • VB: In my dreams I would like to have URL file parsing, opening the stream and buffering all done in the dispatcher, since they are common for all streams. But it can also be done in a lib, albeit at some price (space for the duplicated code). Do you know any way to pipe the stream content from the dispatcher to a "virtual" file, which will then be passed to the the player? Kind of a FIFO buffer, but external to the player. Then we can also play other files, using the already-existent players. Named pipes?

 

  • VB: suggestion: prior to launching the player, the dispatcher should save the global volume, then set it to a preset value (e.g. one from the MG35 configuration file). This is to compensate for the difference in volume between different media players (e.g. mp3 vs dvd vs mpeg). When the player exits, the dispatcher should restore the original volume.

Note that the volume for playing DVDs cannot be changed, since it's under dvdplayer's control, so this can be the reference.

 

  • John: The volume for all modes is controlled by dvdplayer.
    • VB: can we set it from outside dvdplayer?
  • John: Yes, but unless the dvdplayer reads the value before writing it, the volume will jump suddenly when the user attempts to change it.
    • VB: I think that's acceptable, since this will fix the issue for external amplifiers, where the MG35 volume is probably left untouched by the user.
  • John: That's a good point. It's optional so users can simply not use it. Do you know if the digital output suffers from the distortion issue (for which this is a fix)?
    • VB: did some tests today. I get no distortions using the optical output. I also checked the balance between dvd/mp3player and seems OK. I noticed that the global volume is saved on box start/stop. Where is this stored? We don't know about it being saved in NVRAM.
  • John: The volume, and a couple of other things, are stored in the on-chip EEPROM inside the EM85xx.

 

Comments (0)

You don't have permission to comment on this page.