local - the analog output (3.5mm jack).Output (optional): The audio output, if left blank will default to 'local', can be one of: If left blank, the player will initialise and wait for a source to be added later with the newSource method. Source (optional): The playback source, any audio or video file (or stream) that omxplayer is capable of playing. The constructor method, used to launch omxplayer with a source. On the default version of Raspbian it is installed by default, but on the Lite version you will have to install it: sudo apt-get install omxplayerĪPI Omx(, ,, ) This module does not require any third party Node.js libraries, but does rely on omxplayer being installed. Not that I am asking much :) But if things could move in this direction, it would be easier to have an abstracted OOP class structure for layering on functionality that would support upgrading the base while supporting custom applications.Warning: If you quit node before quitting the player, there is a chance of a zombie process being created, which will persist until the current audio/video track ends. There may be already, but I have not found that noted anywhere yet. As per above, there should be one that is designed to be manipulated for media management as a master timeline. Or more descriptive names playerTS, dvdTS, audioTS, videoTS, mediaTS, etc. Oh, and some better documentation regarding PTS, DTS, TS, etc. There is more that can be done, but this is the short list of issues that I have run into when dealing with chapter based playback. While OK for non-chapter based implementations, it would be ideal if there was a Loop Chapter feature, which when you were in Chapter Playback Mode would Loop on chapters start and end times and not time offsets. The m_loop feature uses time variables for managing looping. I have increased it to 512 in my version. The default for the app is 64 chapters max. My projects regularly have more than 100 chapters, some of the times 300 chapters. I added a capture point after the m_loop IF block where a chapter end could be trapped, but it is probably not the best implementation. More in line with the MPEG4 container specification.Īdd a location for capturing time based events in the main loop. When working in the Reader or Player code, we should be dealing with one time value set (milliseconds) where the underlying time calculations and adjustments for the various media atoms are normalized to the master timeline. The current variants are mixed through the system and make it difficult to get a reliable time value. Refactor the Time calculations, in general, need to be cleaned up and managed better. Having a discreet and absolute chapter management system (where you manage the time via chapter start and end) should solve this. The current assumption would not support that model. The Matroska specification supports multiple chapters with sub chapters that overlap time. It also assumes that chapters are contiguous and only one chapter would cover any one moment in the time stream. GetChapter does not reliably return the current chapter. I have come across a couple of issues in the base code that would need to be addressed in order to support that feature set. In my spare time I have been modifying a version of the player to do that.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |