From: Frantisek D. <va...@us...> - 2004-01-26 14:36:07
|
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. >=20 >=20 > 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. >=20 I already commit version which should be universal (for little and big endian), attached. > 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. >=20 But still would be nice good working with all versions libiconv. :-) >=20 > > Many thanks for reporting and testing. >=20 >=20 > No problem. I have ambitions for xine, with something like oxine (thoug= h=20 > that is still quite immature and I think not in active development) for= =20 > a UI running on a system with hardware MPEG2 decoding, so I'm starting=20 > to delve into the architecture. >=20 > 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= s=20 > to be configured with stream IDs or PIDs as appropriate, and demuxes=20 > directly. >=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. >=20 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. > Cheers, >=20 > Rene >=20 >=20 >=20 Cheers, Frantisek |