V Po, 26. 01. 2004 v 14:07, Rene S. Hollan p=C3=AD=C5=A1e:
> > It's good the patch works - all what is needed is using UCS-2LE or
> > UCS-2BE encoding according to "current" endian.
> And filling a uint16 and checking the lowerst order byte can tell us=20
> that. Perhaps I'll wrap that code around your patch and see if it works.
I already commit version which should be universal (for little and big
> Yup, though if it is a problem with an older release of a conversion=20
> table, it's a conversion bug and not a xine-lib big. I was sure I had=20
> updated libiconv, though.
But still would be nice good working with all versions libiconv. :-)
> > Many thanks for reporting and testing.
> No problem. I have ambitions for xine, with something like oxine (thoug=
> that is still quite immature and I think not in active development) for=
> a UI running on a system with hardware MPEG2 decoding, so I'm starting=20
> to delve into the architecture.
> The main gotcha is the demuxing of audio and video from program or=20
> transport streams: the hardware I have accepts MPEG2 streams and expect=
> to be configured with stream IDs or PIDs as appropriate, and demuxes=20
> I was thinking of using a custom demux that sent all to the video=20
> module, and a custom video module that passed that on to hardware,=20
> rather like the support for the DXR3.
I don't know too much about HW decoding, there already is some support
in xine (and not only DXR3). I'm CCing also to xine-devel.