From: Felix D. <tm...@el...> - 2006-11-28 02:49:03
|
Hi, I'm currently evaluating the use of libxine in a product which employs a hardware MPEG2 decoder. (I've made some experiments some years ago with an older libxine version which went pretty well, but never perfect. I'm currently using gstreamer, but for several reasons I might want to switch to libxine.) My ultimate goal is to play .MPG (Program) Streams, DVDs and maybe MP3 (using a software decoder). The hardware decoder can do MPEG2 MP@ML and MP@HL. Audio-wise it can do Layer-I and Layer-II as well as passing a AC3- and DTS-bitstream to SPDIF without decoding. It consists of two (Linuxdvb-compliant) devices, one for video, one for audio, and accepts seperated MPEG PES data streams. The device blocks after the internal ratebuffers are filled. No further interaction other than an initial "PLAY"-IOCTL (and maybe "FLUSH BUFFER") and of course writing the data are required for operation. My current approach is to a PLUGIN_VIDEO_DECODER and a PLUGIN_AUDIO_DECODER with a higher priority than the software decoders. My "decode_data" function then packs the received ES data into a PES stream, using the provided PTS information, and directly writes it into the (blocking) hardware decoder device . Audio is handled in a very similar way. I am not producing video frames, but see below. Now, is this the right way to handle things? I've tried to look at the dxr3 stuff, but my decoder is a bit differently in the way that it handles things more automatically, and there doesn't seem to be generic hardware decoder support in libxine. Is there something where I can look at, possibly base my work on? While working "a bit", it is way from perfect. a.) responsiveness As my "decode_data" function is blocking, some functions block a lot. When i'm starting a playback with xine_play, play_internal executes a "wait_first_frame (stream);". I've so far commented out that, but what's the solution for this? Are the xine functions supposed to be blocking? I currently call them from my UI thread. Is this a bad idea? Should i encapsulate xine into a thread? b.) xine_get_pos_length As I'm not producing video frames, xine_get_pos_length doesn't produce meaningful results. Should I produce video frames? I've experimented with sending dummy vo frames, which at least updates the xine_get_pos_length data. Still i'm not convinced that i'm doing the right thing. c.) Layer 3 issue As mentioned, my hardware decoder can not do Layer 3 playback. That's quite common for hardware decoders, as mpeg streams usually use layer II. however, the only defined type is BUF_AUDIO_MPEG. Is there a way to seperate Layer I/II from Layer 3? My idea was to introduce a BUF_AUDIO_MPEG_LAYER12. Most streams are known to either use Layer I/II or Layer 3. This way, my decoder could handle Layer I/II but not Layer 3, which should be handled with a software decoder. d.) SCR Do i need to provide a SCR device? My hardware decoder maintains its System Clock (STC), and synchronizes audio/video with that clock. It can do either self-syncing (re-set of the STC on first frame), or manual syncing (pre-setting a STC). e.) Overlay A standard ARGB 8888 linux framebuffer lies on top of the decoded mpeg picture buffer. I want to use this for displaying (dvd-)subtitles. Using the alpha channel, (hardware) mixing with the video is possible. My approach was to hack a version of video_out_fb.c to just display overlay. Does this sound right? f.) Handling of stream events When playing back, my "video decoder" (plugin) usually keeps blocking while writing to the video device. In order to, for example, seek, i need to abort the write and issue a buffer-clear ioctl. Are there methods in libxine to interrupt the decoder? Felix |