Re: [xine-devel] xine-lib 1-rc6 soon ?

[Stephen torri <storri@to...>]

On Fri, 2004-08-27 at 18:50, Siggi Langauf wrote:
> Hi Miguel,
> Hi Thibaut,
> 
> On Fri, 27 Aug 2004, Miguel Freitas wrote:
> 
> [...]
> > But we should officially announce the testsuite so users would be
> > aware of this effort.
> 
> Sure but this announdement doesn't have to be connected to a release...
> 
> > > Siggi and Miguel, do you have some time soon ?
> >
> > Actually I'm moving, and i have no internet access yet on the new
> > apartment. Siggi, can you coordinate this release?
> 
> Well, I'm preparing an exam and renovating my appartment, but if it's just
> coordination, I can probably do that, this time...
> 
> Cheers,
> 	Siggi

Well I am unemployed and putting up insulation in my parent's new house.
I could do it. Besides seeking funding for a doctorate I cannot see a
reason not to.

The questions I have are:

1) Where are the nightly build logs posted?

2) Do we use the tests that are posted at this site as a guide?
http://www.xinehq.de/~tmattern/report/

3) Is there a way to freeze the CVS repo so that a nightly build can be
done without interferrence?

Perhaps this could be a training of a young padawan master Siggi.

Stephen
-- 
Email: storri@...

Re: [xine-devel] Several bugs

[Miguel Freitas <mfreitas@gm...>]

Hi James,

On Fri, 27 Aug 2004 23:01:31 +0100, James Courtier-Dutton
<james@...> wrote:
> 
> xine-lib already supports cropping.
> It is used for the zoom-x, zoom-y controls.

really? funny you mention this, because i wrote this code. ;-)

regards,

Miguel

Re: [xine-devel] xine-lib 1-rc6 soon ?

[Siggi Langauf <siggi@us...>]

Hi Miguel,
Hi Thibaut,

On Fri, 27 Aug 2004, Miguel Freitas wrote:

[...]
> But we should officially announce the testsuite so users would be
> aware of this effort.

Sure but this announdement doesn't have to be connected to a release...

> > Siggi and Miguel, do you have some time soon ?
>
> Actually I'm moving, and i have no internet access yet on the new
> apartment. Siggi, can you coordinate this release?

Well, I'm preparing an exam and renovating my appartment, but if it's just
coordination, I can probably do that, this time...

Cheers,
	Siggi

Re: [xine-devel] Several bugs

[James Courtier-Dutton <James@su...>]

Miguel Freitas wrote:
> 
>>Also, Xine doesn't seem to support manual cropping either. Such basic
>>feature shouldn't be missing.
> 
> 
> exactly.
> i guess we need to extend vo_frame_s to include cropping information,
> such as display_width, display_height, display_offsetx,
> display_offsety. opinions?
> 
> we would try to handle this in vo_scale.c, for video drivers with
> support_zoom=1. the problem is what to do when driver cannot do crop
> by itself. how to proceed?
> 
> (we better have separated thread for discussing this problem. this is
> post rc6 stuff but most likely a requisite for 1.0, imho)
> 

xine-lib already supports cropping.
It is used for the zoom-x, zoom-y controls.

Re: [xine-devel] Several bugs

[Miguel Freitas <mfreitas@gm...>]

Hi,

On Tue, 24 Aug 2004 09:32:16 +0300, Lasse K=E4rkk=E4inen / Tronic
<tronic@...> wrote:
> 1. HDTV cropping
>=20
> HDTV 1080i (which is 1920x1080) is encoded at
> 1920x1088, because 1088 is MOD16 and 1080 isn't. The
> extra lines are usually filled with grey, and they
> should be cropped off before playback. This same bug
> appears in nearly all open-source MPEG-2 decoding apps,
> so it's probably upstream bug (libmpeg2 or whatever).
> Anyway, it should be easy to fix, if someone actually
> ever did even examine it.

old libmpeg2 (used in xine) did not exported this information. new
libmpeg2 does (display_height). i remember that i tested a mpeg2 file
that was incorrectly cropped at xine but cropped correctly by mplayer
(which uses a new libmpeg2).

however, exporting the display dimensions is the easy part, the problem is.=
..
=20
> Also, Xine doesn't seem to support manual cropping either. Such basic
> feature shouldn't be missing.

exactly.
i guess we need to extend vo_frame_s to include cropping information,
such as display_width, display_height, display_offsetx,
display_offsety. opinions?

we would try to handle this in vo_scale.c, for video drivers with
support_zoom=3D1. the problem is what to do when driver cannot do crop
by itself. how to proceed?

(we better have separated thread for discussing this problem. this is
post rc6 stuff but most likely a requisite for 1.0, imho)


> 2. XVMC not working
>=20
> Playing 1080i MPEG-2 TS or PAL DVD:
> libmpeg2: output port has XvMC capability
> abort: video_out_xvmc.c:664: xvmc_set_context: Aborting.
> Killed

no idea. it works fine here (GeForce4 MX 440)
=20
> Playing MPEG-4 AVI: black video window, Xine complains that the machine
> is too slow, audio plays fine.

xvmc driver does not currently fallback to xv for non-mpeg2. nobody
has implemented this feature yet.
=20
> 3. Deinterlace performance is horrible

buy a better computer ;-)
=20
> Playing 1080i HDTV on xv takes about 40 % CPU. With tvtime filter in pp
> chain the CPU usage jumps to (over) 100 %. The method selected has no
> effect on this (I'd expect Weave to cause no extra CPU usage, but it
> does 100 % too). use_vo_driver is the only exception - it doesn't cause
> any extra CPU usage, but it also doesn't seem to deinterlace at all.
> Framerate mode, pulldown algorithm and other settings also don't seem to
> make any difference.

1080i material has quite some pixels to work upon, most desktop
systems don't even have horsepower to decode it...  have you tried
cheap_mode=3D1? scalerbob method?

actually weave _is_ an algorithm like others, that will do pixel
comparison between lines and stuff.
=20
> Looks to me as if it was doing expensive colorspace conversions, even
> though deinterlace filters shouldn't require such thing...

all tvtime and dscaler algorithms were coded for yuy2 images.
libmpeg2 outputs yv12. so, yes, an expensive colorspace conversion is
needed (unless of course, somebody rewrites all deinterlace algorithms
to work on yv12 colorspace).

if you want to skip this (using the algorithms in a rather hacky way)
set cheap_mode=3D1.
=20
> 4. Boxblur filter radius can be set negative, causing segfault.

note taken.
[Daniel: xine-ui is not respecting parameters limits]

regards,

Miguel

Re: [xine-devel] fix for non iso-8859 subtitles for Matroska - try 3

[Miguel Freitas <mfreitas@gm...>]

Andrei,

I took your patch as a base and created a more general mechanism for
setting subtitle charset encoding at demuxer level. besides, your
patch only handled the subtitle width calculation for rendering, user
would still have to change misc.spu_src_encoding.

please give it a try to the current cvs and let me know.

regards,

Miguel


On Wed, 11 Aug 2004 07:59:05 -0700 (PDT), ANDREI LAHUN
<zhirnyi@...> wrote:
> Ok now use buf->decoder_info
> instead of buf->type.
> I am still searching for OGM with UTF8 subtitles.
> 
> Andrei.
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
> 
>

Re: [xine-devel] win32 compile

[<valtri@us...>]

Hi Stephane,

V P=C3=A1, 27. 08. 2004 v 15:08, Stephane Konstantaropoulos p=C3=AD=C5=A1=
e:
> Hi Frantisek,
>=20
> I am trying to compile now, so far it is getting somewhere, few
> conditionnal compilation changes to use different headers but not that =
much.
>=20
> How are you getting on?
>=20
> libltdl seems like a good approach as the code would then be portable,
> with very little changes.
>=20

Today I've almost finished MINGW compilation. :-)=20
(before I had problems with creating shared libraries and with bad
generated xine-config).

It still requires some work, but xine engine is built. It needs more
testing - how works self-compiled included pthreads, how works video
output with mingw's w32api...=20

And there is certainly room for improvements - your libltdl for example
- which would work on the most of platforms.

Cheers,
  Frantisek

Re: [xine-devel] MinGW port - patches for commit, shared libraries

[<valtri@us...>]

Hi all,

V P=C3=A1, 30. 07. 2004 v 21:33, Franti=C5=A1ek Dvo=C5=99=C3=A1k p=C3=AD=C5=
=A1e:
> Hi team,
>=20
> attached are patches I'm going to commit - MinGW port.
> There is also something for external projects.
>=20
> First of all, I would have a question. I cared about building, but fina=
l
> linking isn't ideal, yet. Does anybody know what this error message
> means? (displayed for each plugin):
>=20
> *** Warning: This system can not link to static lib archive
> ../../src/xine-engine/libxine.la.
> *** I have the capability to make that library automatically link in
> when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
> *** But as you try to build a module library, libtool will still create=
=20
> *** a static module, that should work as long as the dlopening
> application
> *** is linked with the -dlopen flag to resolve symbols at runtime.
> libtool-nofpic: link: warning: undefined symbols not allowed in
> i686-pc-mingw32 shared libraries
>=20
> src/xine-engine/.libs/libxine.a was made, but no dynamic library
> (configure automatically used --disable-shared option). libtool should
> care about linking on various platforms, but maybe we should try it
> manually under MinGW...?
>=20

Heureka! Shared libs compiled fine now under MINGW. :-)

(added AC_LIBTOOL_WIN32, -no-undefined into LDLFAGS, removed -static
=66rom intl and maybe other changes)

>=20
> So building of xine is almost OK, now I'll describe, what the patches
> contains, if somebody will want to read the patches:
>=20
>  - changes for external projects DVDNAV, VCD, nosefart and libfaad!
>=20
>  - build win32 contrib directory via standard autotools,
>    use included zlib, pthreads and other for win32,
>    one hack in src/xine-engine/Makefile.am is dirty:
>=20
> 	@cd $(top_srcdir)/win32/contrib/pthreads && $(MAKE) GC
> 	@cd $(top_srcdir)/win32/contrib/zlib && $(MAKE)
>=20

This is done better now. Clean way with Makefile.am in pthread and zlib
directories.

The patch is really big and it maybe breaks something. But build under
linux and under MINGW works fine, so I hope there won't too much
problems. I commit it.

Attached are patches for external projects: DVDNAV and VCD.

Cheers,
  Frantisek

Re: [xine-devel] FourCC Patch

[Miguel Freitas <mfreitas@gm...>]

On Wed, 25 Aug 2004 23:57:51 -0400, Drew 'dantealiegri' Ogle
<dantealiegri@...> wrote:
> I have a AVI/RIFF file that has mpeg1 data in it with the fourCC 'mpg1'.
> 
> This patch allows it to be played back.

committed.

thanks,

Miguel

Re: [xine-devel] [PATCH] xine-lib/src/input/libreal/asmrp.c syntax extension

[Miguel Freitas <mfreitas@gm...>]

Hi,

On Sun, 08 Aug 2004 20:27:33 +0200, Reimar D=F6ffinger
<reimar.doeffinger@...> wrote:
> Hi,
> rtsp://193.64.153.172:554/broadcast/split-real/broadcast/assembly/asm04.r=
m
> uses a weird syntax with a rule starting with comma. The attached patch
> should fix this by allowing "empty assignments".
> I tested it to work with MPlayer, but as that code is from you it would
> be better if you could apply (after testing of course, that isn't one of
> my strengths lately ;-) ).

ok, i won't test it either ;-)
but your patch looks good and safe so i'm committing it now.

regards,

Miguel

Re: [xine-devel] xine-lib 1-rc6 soon ?

[Miguel Freitas <mfreitas@gm...>]

Hi Thibaut,

On Fri, 27 Aug 2004 16:23:55 MEST, tmattern@... <tmattern@...> wrote:
> I think a new release of the lib would be a good idea, 1-rc5 was released on June, 21.

Agreed.
 
> The testsuite produces a list of some "known bugs", and a HTML link could be added to the release notes or the website :
> http://www.xinehq.de/~tmattern/report/

there are several errors due a missing win32 file (msms001.vwp). I
have it on my computer, can you add it to the test machine?

-rw-r--r--  1 root root 424960 Apr 15  1999 msms001.vwp


> I don't think that everything must be fixed before the release, some of them are very old bugs.

Ok.
But we should officially announce the testsuite so users would be
aware of this effort.

> Siggi and Miguel, do you have some time soon ?

Actually I'm moving, and i have no internet access yet on the new
apartment. Siggi, can you coordinate this release?

regards,

Miguel

[xine-devel] xine-lib 1-rc6 soon ?

[<tmattern@no...>]

Hi

I think a new release of the lib would be a good idea, 1-rc5 was released =
on June, 21.

The testsuite produces a list of some =22known bugs=22, and a HTML link co=
uld be added to the release notes or the website :
http://www.xinehq.de/=7Etmattern/report/
I don't think that everything must be fixed before the release, some of th=
em are very old bugs.

current changelog:
http://cvs.sourceforge.net/viewcvs.py/xine/xine-lib/ChangeLog?rev=3D1.488&=
view=3Dmarkup

Siggi and Miguel, do you have some time soon ?

Thibaut  =

Re: [xine-devel] strange crash in xine-lib

[<tmattern@no...>]

Hi,

>De: Matt Jarvis <matt=40rolec.ltd.uk>
>A: xine-devel=40lists.sourceforge.net
>Sujet: =5Bxine-devel=5D strange crash in xine-lib
>Date: Fri, 27 Aug 2004 12:45:42 +0100
>
>Hi
>
>We are seeing some strange crashes in our xine-lib based player, when we =

>are switching from video track to an audio track with goom =

>visualisations, and we have an OSD displayed ( with track artist/title =

>information ) ie creating a new stream and a new OSD. Our programming =

>team think the problem might be a bad pointer in video=5Fout.c, but to be=
 =

>honest we are a bit out of our depth with this bit of the code. The gdb =

>output is :
>
>=5BThread 147466 (LWP 1314) exited=5D
>=5BThread 98311 (LWP 1295) exited=5D
>=5BThread 81926 (LWP 1294) exited=5D
>=5BThread 114696 (LWP 1296) exited=5D
>=5BNew Thread 163851 (LWP 1315)=5D
>=5BNew Thread 180236 (LWP 1316)=5D
>=5BNew Thread 196621 (LWP 1317)=5D
>=5BNew Thread 213006 (LWP 1318)=5D
>
>Program received signal SIGSEGV, Segmentation fault.
>=5BSwitching to Thread 32771 (LWP 1291)=5D
>0x400329de in overlay=5Fand=5Fdisplay=5Fframe (this=3D0x8098798, img=3D0x=
84a4080,
>     vpts=3D8499428) at video=5Fout.c:868
>868     video=5Fout.c: No such file or directory.
>         in video=5Fout.c
>Current language:  auto; currently c
>(gdb) p img
>=241 =3D (vo=5Fframe=5Ft *) 0x84a4080
>(gdb) p img->stream
>=242 =3D (xine=5Fstream=5Ft *) 0x863cba0
>(gdb) p img->stream->current=5Fextra=5Finfo
>=243 =3D (extra=5Finfo=5Ft *) 0x0
>(gdb)

wow, stream->current=5Fextra=5Finfo is NULL, this looks very suspicious, s=
tream->current=5Fextra=5Finfo is allocated when creating the stream and i =
do not see where it might be set to NULL.
We need more info to fix this bug:
  Is it 100% reproducible ?
  Have you tested with different type of streams (mp3, ogg, wma) ?
  Have you tested with different video ouput plugins (xv, xshm) ?
  =

Or better, can you provide the source of your frontend or a  way to reprod=
uce the problem ?

>Does anyone have any idea what we might be doing wrong, or if this is a =

>bug in xine-lib ? We are using CVS xine-lib as of this morning, although =

>this problem was also there in the previous CVS pull of xine-lib we were =

>using, which was about three weeks ago I think.
>
>Thanks for your help
>
>Matt
>-- =

>Matt Jarvis
>Technical Development Manager
>Rolec Music Ltd
>210 Belgravia Works, Marlborough Road, London, UK N19 4NF
>Tel: +44 207 281 4776 Fax : +44 207 281 4565
>mailto: matt=40rolec.ltd.uk
>web: http://www.rolecmusic.com
=5B...=5D


Thibaut

Re: [xine-devel] win32 compile

[Stephane Konstantaropoulos <stephanek@br...>]

Hi Frantisek,

I am trying to compile now, so far it is getting somewhere, few
conditionnal compilation changes to use different headers but not that much.

How are you getting on?

libltdl seems like a good approach as the code would then be portable,
with very little changes.

Stephane

František Dvořák a écrit :

>Hi Stephane,
>  
>
>I did some patches, but it isn't in CVS yet - there are bigger changes
>in configure/Makefiles and I found some problems yet.
>  
>
>The solution in deprecated MSVC win32 port is using LoadLibrary and
>FreeLibrary and this works also for MINGW32. Using just libltdl is
>interresting idea.
>
>And DirectX is needed in win32 port - it's only working audio and video
>output. With DirectX SDK headers it will maybe successfuly cross
>compile.
>  
>

[xine-devel] strange crash in xine-lib

[Matt Jarvis <matt@ro...>]

Hi

We are seeing some strange crashes in our xine-lib based player, when we 
are switching from video track to an audio track with goom 
visualisations, and we have an OSD displayed ( with track artist/title 
information ) ie creating a new stream and a new OSD. Our programming 
team think the problem might be a bad pointer in video_out.c, but to be 
honest we are a bit out of our depth with this bit of the code. The gdb 
output is :

[Thread 147466 (LWP 1314) exited]
[Thread 98311 (LWP 1295) exited]
[Thread 81926 (LWP 1294) exited]
[Thread 114696 (LWP 1296) exited]
[New Thread 163851 (LWP 1315)]
[New Thread 180236 (LWP 1316)]
[New Thread 196621 (LWP 1317)]
[New Thread 213006 (LWP 1318)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 1291)]
0x400329de in overlay_and_display_frame (this=0x8098798, img=0x84a4080,
     vpts=8499428) at video_out.c:868
868     video_out.c: No such file or directory.
         in video_out.c
Current language:  auto; currently c
(gdb) p img
$1 = (vo_frame_t *) 0x84a4080
(gdb) p img->stream
$2 = (xine_stream_t *) 0x863cba0
(gdb) p img->stream->current_extra_info
$3 = (extra_info_t *) 0x0
(gdb)

Does anyone have any idea what we might be doing wrong, or if this is a 
bug in xine-lib ? We are using CVS xine-lib as of this morning, although 
this problem was also there in the previous CVS pull of xine-lib we were 
using, which was about three weeks ago I think.

Thanks for your help

Matt
-- 
Matt Jarvis
Technical Development Manager
Rolec Music Ltd
210 Belgravia Works, Marlborough Road, London, UK N19 4NF
Tel: +44 207 281 4776 Fax : +44 207 281 4565
mailto: matt@...
web: http://www.rolecmusic.com

This email is strictly confidential and intended solely for the
addressee(s). It may contain personal and confidential information and
as such may be protected by the Data Protection Act 1998. If this email
has come to you in error you must take no action based on it, nor must
you copy or show it to anyone; please reply to this email and highlight
the error.

Any views or opinions expressed within this email are those of the
author, and do not necessarily represent those of the company.

Although we have taken steps to ensure that this email and attachments
are free from any virus, we advise that in keeping with good computer
practice the recipient should ensure they are actually virus free.

Re: [xine-devel] Re: VIA Enhanced Xine Player

[<unichrome@sh...>]

Dermot McGahon wrote:

> On Thu, 26 Aug 2004 17:04:39 +0200 (CEST), Thomas Hellstr=C3=B6m =20
> <unichrome@...> wrote:
>
> Hello Thomas,
>
>> With mpeg support the situation is the following: In order to work, VE=
XP
>> needs
>>
>> 1. A closed-source linux kernel addition via_v4l_drv that are only
>> provided for certain kernel versions.
>
>
> From:
>
> http://cvs.sourceforge.net/viewcvs.py/unichrome/via/src/ReleaseNote.txt=
?rev=3D1.5=20
>
>
> "(1) OS: Red Hat Linux 8.0/9.0, Mandrake 9.0/9.1, and SuSE 8.1."
>
> No mention in these instructions of kernel versions. Does this mean
> that via_v4l_drv will only work with the versions of kernel as released
> with these distributions? From a quick glance this looks like no 2.6
> support at all. Is that correct?
>
 From what I know, yes. There is a partially reversed engineered version=20
of this driver as well, which is
usable also with 2.6 kernels ,but I'm not sure about the legal status.=20
Also no CN400 support.

>
>> 2. A closed-source library libddmpeg.so provided in binary form. This
>> library accesses the hardware directly and one is obliged to run it as
>> root. At least this was the case with VeXP 2.X. It has no means of =20
>> sharing hardware engine resources, like frame blitting etc. with the=20
>> X  server.
>> This library, at least the CLE266 version has an open API, similar to=20
>> the
>> XvMC API but much more restricted with respect to surface handling.
>
>
> Is this likely to cause problems switching between VeXP and other
> X applications?

I'm not totally sure about this. In the XFree86 via driver, Alan Cox=20
considered the via_v4l_drv <-> Xv glue as "racy" and discarded it. I=20
haven't looked as much into VIA's X server driver to be sure whether=20
things have improved.

>
> There also seems to be a reserve-engineered open-source version
> of libddmpeg:
>
> http://www.ivor.it/cle266/guide.html
>
> Is it usable?
>
>
Yes, but not with VeXP 3.0, AFAIK.

>> 3. The drm module which is available Open-source at dri.sourceforge.ne=
t.
>>
>> It is also based on an old version of Xine-lib and will require some
>> porting to be up-to-date with xine CVS.
>>
>> The unichrome project has chosen a different approach with a nonstanda=
rd
>> extension of XvMC that implements a VLD acceleration level. This libra=
ry
>> is based on the direct rendering infrastructure and, as such, can
>> communicate and share resources with the X server. The XvMC standard=20
>> also
>> provides means for hardware surface duplication, which is required=20
>> for  DVD menu support, and is, of course, fully open source under the=20
>> old  style
>> XFree86 license, which should be GPL compatible. The drm kernel module
>> from dri.sourceforge.net is needed for X server interoperability.
>
>
> These efforts are very much appreciated.
>
>
>> The newer version of the Xine code in VeXP is much more well written a=
nd
>> easier to understand than that of the older version. I have "stolen"=20
>> some
>> ideas for the unichrome plugin, in particular parts of the ia44 / ai44
>> blending surface rendering, while most has been implemented in a quite
>> different way, following xine's Xv and XvMC plugins. Almost all of=20
>> the Xv
>> plugin code in the unichrome XxMC plugin remains intact.
>>
>> Contrary to VeXP, the unichrome plugin can be run as an unprivileged=20
>> user
>> and it is up to date with current Xine-CVS which means people are=20
>> testing
>> it with additions such as VDR-xine.
>>
>> The largest drawback with the unichrome plugin is that it, due to=20
>> lack of
>> documentation, (CN400 docs are not ready) lacks bleeding edge features
>> such as CN400 mpeg4 support, and it will probably lag behind VIAs code=
s
>> with respect to this also in the future, and since it is a
>> spare-time-people project there is no guarantee that development will
>> continue forever.
>
>
> Ok, but I think that people would be more than happy to have accelerate=
d
> MPEG-2 for the moment. For that, there seems to be only one game in
> town, VeXP. With xine/XxMC about to also give equivalent functionality?
>
Yes, except for CN400 mpeg4 support.

I have not tried VeXP so I cannot give a fair comparison with regard to=20
CPU usage
and stability.

The XxMC driver should be totally equivalent to the Xv driver, with the=20
exception that it
accelerates mpeg2 and mpeg1 that are decoded by libmpeg2. Some people=20
are using it
for DVB watching with reportedly very low cpu-usage.

> My personal problem is that I need a player that can support the
> following:
>
>  - multicast mpeg-2 stream reception (for IPtv)
>  - rtsp/udp mpeg-2 stream reception (for VOD)
>  - support for sap/sdp (for listing available streams)
>  - h/w mpeg-2 decode (to give breathing room)
>
> When I was evaluating players five months ago:
>
>  - xine had a poor rtsp implementation (sorry!)
>  - mplayer had no support for multicast
>  - vlc was only starting work on rtsp/rtp
>
> *None* of these players had support for CLE266 h/w mpeg decoding.
>
> VeXP was supposedly of poor quality and had all the dependencies
> that you have described above. Plus, I was very unsure that it
> would continue to be developed. Nice to see that it is being
> actively developed.
>
> So, what I did was to pick the one that seemed (at the time)
> easiest to extend. MPlayer using the LIVE.COM code had a decent
> rtsp implementation so I extended it to support Kasenna's variant
> of rtsp and to support raw udp streams instead of udp encapsulated
> in rtp.
>
> The next step was to implement a new MRL scheme and multicast
> support for mplayer.
>
> I've done all of that. There are bugs. But now I'm at the stage
> where I would really like to have h/w mpeg decoding!
>
> The MPlayer developers were initially approached by VIA but
> between one thing and another ... communication stalled.
>
> It seems a shame to me that xine, mplayer and vlc can't all
> have support for the mpeg-2 decoding via h/w.
>
> I actually like all three players very much .. each has their
> good and bad points. None of them are perfect at doing everything
> and each has some particular strengths.
>
> What would it take to make this happen? A miracle?
>
> Would you have interest in talking to vlc and mplayer about
> using XxMC. As a friendly warning - and I wish it weren't this
> way - there is a little resistance in the mplayer project to
> using XxMC. But some discussion shouldn't hurt. Not hurt much
> anyway :)
>
Well, first the name XxMC is a little misleading since this was only a=20
name I chose
for the xine plugin. It is actually just a proposal of adding an extra=20
acceleration level to
XvMC, and that name was already "occupied" by the XvMC plugin :-).
I chose not to extend the XvMC xine plugin, just because it was not up=20
to date with X11OSD, and I wasn't too sure about software fallback either=
.

Could you point me to some links about what's being discussed so far?

I don't really like to push things, rather that people found out for=20
themselves what is the best choice weighing pros and cons, but I could=20
give it a try.  At least make sure people have the facts. Some people=20
tend not to like video players that needs running an X server.
Also, I must say, extending a well  coded standard XvMC implementation=20
to include also the proposed VLD level is a rather small task. Also=20
today it's the only truly OS API to the decoder. It may well be that the=20
VLD level is incomplete when it comes to other decoders, but it is very=20
easy to modify when / if a standard is agreed upon.

>
> Dermot.
> --=20

Regards
Thomas

Re: [xine-devel] Re: VIA Enhanced Xine Player

[Dermot McGahon <dermot@ds...>]

On Thu, 26 Aug 2004 17:04:39 +0200 (CEST), Thomas Hellström  
<unichrome@...> wrote:

Hello Thomas,

> With mpeg support the situation is the following: In order to work, VEXP
> needs
>
> 1. A closed-source linux kernel addition via_v4l_drv that are only
> provided for certain kernel versions.

From:

http://cvs.sourceforge.net/viewcvs.py/unichrome/via/src/ReleaseNote.txt?rev=1.5

"(1) OS: Red Hat Linux 8.0/9.0, Mandrake 9.0/9.1, and SuSE 8.1."

No mention in these instructions of kernel versions. Does this mean
that via_v4l_drv will only work with the versions of kernel as released
with these distributions? From a quick glance this looks like no 2.6
support at all. Is that correct?


> 2. A closed-source library libddmpeg.so provided in binary form. This
> library accesses the hardware directly and one is obliged to run it as
> root. At least this was the case with VeXP 2.X. It has no means of  
> sharing hardware engine resources, like frame blitting etc. with the X  
> server.
> This library, at least the CLE266 version has an open API, similar to the
> XvMC API but much more restricted with respect to surface handling.

Is this likely to cause problems switching between VeXP and other
X applications?

There also seems to be a reserve-engineered open-source version
of libddmpeg:

http://www.ivor.it/cle266/guide.html

Is it usable?


> 3. The drm module which is available Open-source at dri.sourceforge.net.
>
> It is also based on an old version of Xine-lib and will require some
> porting to be up-to-date with xine CVS.
>
> The unichrome project has chosen a different approach with a nonstandard
> extension of XvMC that implements a VLD acceleration level. This library
> is based on the direct rendering infrastructure and, as such, can
> communicate and share resources with the X server. The XvMC standard also
> provides means for hardware surface duplication, which is required for  
> DVD menu support, and is, of course, fully open source under the old  
> style
> XFree86 license, which should be GPL compatible. The drm kernel module
> from dri.sourceforge.net is needed for X server interoperability.

These efforts are very much appreciated.


> The newer version of the Xine code in VeXP is much more well written and
> easier to understand than that of the older version. I have "stolen" some
> ideas for the unichrome plugin, in particular parts of the ia44 / ai44
> blending surface rendering, while most has been implemented in a quite
> different way, following xine's Xv and XvMC plugins. Almost all of the Xv
> plugin code in the unichrome XxMC plugin remains intact.
>
> Contrary to VeXP, the unichrome plugin can be run as an unprivileged user
> and it is up to date with current Xine-CVS which means people are testing
> it with additions such as VDR-xine.
>
> The largest drawback with the unichrome plugin is that it, due to lack of
> documentation, (CN400 docs are not ready) lacks bleeding edge features
> such as CN400 mpeg4 support, and it will probably lag behind VIAs codes
> with respect to this also in the future, and since it is a
> spare-time-people project there is no guarantee that development will
> continue forever.

Ok, but I think that people would be more than happy to have accelerated
MPEG-2 for the moment. For that, there seems to be only one game in
town, VeXP. With xine/XxMC about to also give equivalent functionality?

My personal problem is that I need a player that can support the
following:

  - multicast mpeg-2 stream reception (for IPtv)
  - rtsp/udp mpeg-2 stream reception (for VOD)
  - support for sap/sdp (for listing available streams)
  - h/w mpeg-2 decode (to give breathing room)

When I was evaluating players five months ago:

  - xine had a poor rtsp implementation (sorry!)
  - mplayer had no support for multicast
  - vlc was only starting work on rtsp/rtp

*None* of these players had support for CLE266 h/w mpeg decoding.

VeXP was supposedly of poor quality and had all the dependencies
that you have described above. Plus, I was very unsure that it
would continue to be developed. Nice to see that it is being
actively developed.

So, what I did was to pick the one that seemed (at the time)
easiest to extend. MPlayer using the LIVE.COM code had a decent
rtsp implementation so I extended it to support Kasenna's variant
of rtsp and to support raw udp streams instead of udp encapsulated
in rtp.

The next step was to implement a new MRL scheme and multicast
support for mplayer.

I've done all of that. There are bugs. But now I'm at the stage
where I would really like to have h/w mpeg decoding!

The MPlayer developers were initially approached by VIA but
between one thing and another ... communication stalled.

It seems a shame to me that xine, mplayer and vlc can't all
have support for the mpeg-2 decoding via h/w.

I actually like all three players very much .. each has their
good and bad points. None of them are perfect at doing everything
and each has some particular strengths.

What would it take to make this happen? A miracle?

Would you have interest in talking to vlc and mplayer about
using XxMC. As a friendly warning - and I wish it weren't this
way - there is a little resistance in the mplayer project to
using XxMC. But some discussion shouldn't hurt. Not hurt much
anyway :)



Dermot.
--

Re: [xine-devel] Re: VIA Enhanced Xine Player

[Thomas <unichrome@sh...>]

Hi, Tim and Miguel.

Since this message was copied to me I'd also like to clarify the Unichrom=
e
projects role and relation to VIA in this.

> Hi Tim,
>

> I'd like to get a better picture of the free software available for
> VIA hardware so we could decide how to best proceed. I'm copying this
> message to Thomas Hellstr=F6m from the unichrome project. The first
> thing I'd like to understand is the relationship between VeXP and
> unichrome project and how their approaches differ.

The unichrome project sprung from one of the first versions of the X
server driver VIA handed over to the XFree86 projects. After it was
cleaned up by the XFree86 development team and Alan Cox, A team of
interested developers started the unichrome project to be able to do more
rapid development than the XFree86 development model allowed for our
hardware that lacked proper linux drivers. We keep every effort to
maintain compatibility with dri.sourceforge.net, X.org, and XFree86.

VIA has continued developing their own Xfree86 drivers and, although thei=
r
sourcecode is availble, it is not backported to and adapted to the
advancing development of XFree86 and X.org, and they have not adapted any
of the cleanups that the XFree86 team or the Unichrome project has
provided.

With mpeg support the situation is the following: In order to work, VEXP
needs

1. A closed-source linux kernel addition via_v4l_drv that are only
provided for certain kernel versions.
2. A closed-source library libddmpeg.so provided in binary form. This
library accesses the hardware directly and one is obliged to run it as
root. At least this was the case with VeXP 2.X. It has no means of sharin=
g
hardware engine resources, like frame blitting etc. with the X server.
This library, at least the CLE266 version has an open API, similar to the
XvMC API but much more restricted with respect to surface handling.
3. The drm module which is available Open-source at dri.sourceforge.net.

It is also based on an old version of Xine-lib and will require some
porting to be up-to-date with xine CVS.

The unichrome project has chosen a different approach with a nonstandard
extension of XvMC that implements a VLD acceleration level. This library
is based on the direct rendering infrastructure and, as such, can
communicate and share resources with the X server. The XvMC standard also
provides means for hardware surface duplication, which is required for DV=
D
menu support, and is, of course, fully open source under the old style
XFree86 license, which should be GPL compatible. The drm kernel module
from dri.sourceforge.net is needed for X server interoperability.

The newer version of the Xine code in VeXP is much more well written and
easier to understand than that of the older version. I have "stolen" some
ideas for the unichrome plugin, in particular parts of the ia44 / ai44
blending surface rendering, while most has been implemented in a quite
different way, following xine's Xv and XvMC plugins. Almost all of the Xv
plugin code in the unichrome XxMC plugin remains intact.

Contrary to VeXP, the unichrome plugin can be run as an unprivileged user
and it is up to date with current Xine-CVS which means people are testing
it with additions such as VDR-xine.

The largest drawback with the unichrome plugin is that it, due to lack of
documentation, (CN400 docs are not ready) lacks bleeding edge features
such as CN400 mpeg4 support, and it will probably lag behind VIAs codes
with respect to this also in the future, and since it is a
spare-time-people project there is no guarantee that development will
continue forever.

The development at unichrome.sourceforge.net is not in any way sponsored
or supported by VIA, but so far there has been a healty coexistence. And
the simultaneous release of the unichrome XxMC plugin and VeXP 3.0 was, i=
n
fact, a pure coincidence.

Regards
Thomas



>
> I remember I checked the source code of the first VeXP release and it
> was not much promising from the perspective of trying to merge the
> patches back. I have nothing against binary drivers myself* (actually
> I'm using a nvidia binary driver here) and if your company, by
> whatever reason, cannot provide the full source code for programming
> hardware acceleration it doesn't matter. However, xine is free
> software and may not be linked to GPL-incompatible libraries. I
> believe the first VeXP release was linked to a proprietary library,
> therefore these changes would not be accepted back to our codebase.
> Fortunately this should not be a difficult issue to solve (note I have
> not seen VeXP 3.0 sources yet), you just need to put all your
> proprietary stuff accessible through some documented API (like XvMC)
> and have a clear separation from GPL'ed software like xine (eg.
> providing a kernel or xfree86 driver).
>
> I look forward hearing your comments. I hope we can merge VeXP,
> unichrome, or even both drivers to xine provided they are not too much
> intrusive or hacky and, of course, legal.
>
> regards,
>
> Miguel
>
> * ok, I personally prefer to use open source drivers/software whenever
> possible. But if the binary driver works well and it is 100% legal
> (speaking in terms of license and copyrights) it is fine for me.
>
> On Wed, 18 Aug 2004 16:03:38 +0200, Guenter Bartsch
> <bartscgr@...> wrote:
>> hallo tim,
>>
>> personally i am no longer very active in xine developement that's why
>> i'm forwarding your mail to the xine developer's mailing list.
>>
>> thanks for your great effort and keep up the good work!
>>
>>   guenter
>>
>> On Wed, 2004-08-18 at 09:18, TimHandley@... wrote:
>> > Hi Gunter
>> >
>> > VIA has added some code to the Xine player to enable support for the
>> > hardware based MPEG2 decoding in the VIA CLE266 chipset and the MPEG=
4
>> > and MPEG2 acceleration in the VIA CN400 chipset. This is available o=
n
>> > sourceforge.net and more info is available from this URL:
>> > http://www.viaarena.com/?PageID=3D325#cle266.
>> >
>> > We now want to send out a press release to announce that this progra=
m
>> > (that we call VeXP 3.0 - VIA enhanced Xine Player, version 3.0) and
>> > the free source code is available and would like to give the Xine
>> > project group all the credit that they deserve in this announcement.
>> > Are you the right person to contact in this regard?
>> >
>> > VIA has four EPIA Mini-ITX mainboards with various configurations
>> > based on the CLE266 chipset and we are about to launch the VIA EPIA =
SP
>> > Mini-ITX
>> > <http://www.viaembedded.com/product/epia_sp_spec.jsp?motherboardId=3D=
261>
>> and VIA EPIA N Nano-ITX
>> <http://www.viaembedded.com/product/epia_N_spec.jsp?motherboardId=3D22=
1>
>> mainboards that are based on the CN400 chipset. These boards target
>> 'Personal Electronics' devices for the living room. Basically, the
>> work that we did on the VeXP 3.0 will enable a reduction in the
>> workload of the VIA C3 or VIA Eden processor of more than 50% while
>> helping to improve overall system performance. We believe that the
>> Linux operating system is the right kind of OS for the x86 consumer
>> electronics market because of its customizable nature as well as fast
>> boot-up times and the ability to achieve consumer electronics type
>> price points. By using low power VIA processor platforms that include
>> the VIA CN400 or VIA CLE266 chipsets, many VIA customers are building
>> small, low profile and even mobile digital entertainment devices that
>> are attractive and quiet enough to qualify for the living room and
>> other personal environments.
>> >
>> > In order to provide the right kind of exposure to the Xine project, =
we
>> > are considering how best to talk about our work on the player and
>> > would like to include a quote from someone involved in the Xine
>> > project as part of our good intentions with this project.
>> >
>> > I look forward to your reply.
>> >
>> > Best Regards
>> >
>> > Tim Handley
>> > Processor Platform Marketing Manager
>> > VIA Technologies, Inc.
>> >
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>> _______________________________________________
>> xine-devel mailing list
>> xine-devel@...
>> https://lists.sourceforge.net/lists/listinfo/xine-devel
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> xine-devel mailing list
> xine-devel@...
> https://lists.sourceforge.net/lists/listinfo/xine-devel
>

Re: [xine-devel] Re: VIA Enhanced Xine Player

[Miguel Freitas <mfreitas@gm...>]

Hi Tim,

I'm one xine maintainers and I must say that VIA efforts to improving
xine are certainly appreciated. It is quite rewarding to see that your
company has chosen to work with the free software community and
specifically our project is being used, we are always interested in
adding support for new hardware.

AFAIK, the lead xine developers have no access to these accelerated
VIA hardware themselves so it's somewhat difficult to us to maintain
support for it, fixing bugs and stuff. Still, it would be nice to
merge those new drivers that are being developed back to our main cvs
tree. It would also be easier for VIA's engineers to maintain your
product as the VeXP and xine code bases get closer, porting bug fixes
from other xine modules would be quite simple.

I'd like to get a better picture of the free software available for
VIA hardware so we could decide how to best proceed. I'm copying this
message to Thomas Hellstr=F6m from the unichrome project. The first
thing I'd like to understand is the relationship between VeXP and
unichrome project and how their approaches differ.

I remember I checked the source code of the first VeXP release and it
was not much promising from the perspective of trying to merge the
patches back. I have nothing against binary drivers myself* (actually
I'm using a nvidia binary driver here) and if your company, by
whatever reason, cannot provide the full source code for programming
hardware acceleration it doesn't matter. However, xine is free
software and may not be linked to GPL-incompatible libraries. I
believe the first VeXP release was linked to a proprietary library,
therefore these changes would not be accepted back to our codebase.
Fortunately this should not be a difficult issue to solve (note I have
not seen VeXP 3.0 sources yet), you just need to put all your
proprietary stuff accessible through some documented API (like XvMC)
and have a clear separation from GPL'ed software like xine (eg.
providing a kernel or xfree86 driver).

I look forward hearing your comments. I hope we can merge VeXP,
unichrome, or even both drivers to xine provided they are not too much
intrusive or hacky and, of course, legal.

regards,

Miguel

* ok, I personally prefer to use open source drivers/software whenever
possible. But if the binary driver works well and it is 100% legal
(speaking in terms of license and copyrights) it is fine for me.

On Wed, 18 Aug 2004 16:03:38 +0200, Guenter Bartsch
<bartscgr@...> wrote:
> hallo tim,
>=20
> personally i am no longer very active in xine developement that's why
> i'm forwarding your mail to the xine developer's mailing list.
>=20
> thanks for your great effort and keep up the good work!
>=20
>   guenter
>=20
> On Wed, 2004-08-18 at 09:18, TimHandley@... wrote:
> > Hi Gunter
> >
> > VIA has added some code to the Xine player to enable support for the
> > hardware based MPEG2 decoding in the VIA CLE266 chipset and the MPEG4
> > and MPEG2 acceleration in the VIA CN400 chipset. This is available on
> > sourceforge.net and more info is available from this URL:
> > http://www.viaarena.com/?PageID=3D325#cle266.
> >
> > We now want to send out a press release to announce that this program
> > (that we call VeXP 3.0 - VIA enhanced Xine Player, version 3.0) and
> > the free source code is available and would like to give the Xine
> > project group all the credit that they deserve in this announcement.
> > Are you the right person to contact in this regard?
> >
> > VIA has four EPIA Mini-ITX mainboards with various configurations
> > based on the CLE266 chipset and we are about to launch the VIA EPIA SP
> > Mini-ITX
> > <http://www.viaembedded.com/product/epia_sp_spec.jsp?motherboardId=3D26=
1> and VIA EPIA N Nano-ITX <http://www.viaembedded.com/product/epia_N_spec.=
jsp?motherboardId=3D221> mainboards that are based on the CN400 chipset. Th=
ese boards target 'Personal Electronics' devices for the living room. Basic=
ally, the work that we did on the VeXP 3.0 will enable a reduction in the w=
orkload of the VIA C3 or VIA Eden processor of more than 50% while helping =
to improve overall system performance. We believe that the Linux operating =
system is the right kind of OS for the x86 consumer electronics market beca=
use of its customizable nature as well as fast boot-up times and the abilit=
y to achieve consumer electronics type price points. By using low power VIA=
 processor platforms that include the VIA CN400 or VIA CLE266 chipsets, man=
y VIA customers are building small, low profile and even mobile digital ent=
ertainment devices that are attractive and quiet enough to qualify for the =
living room and other personal environments.
> >
> > In order to provide the right kind of exposure to the Xine project, we
> > are considering how best to talk about our work on the player and
> > would like to include a quote from someone involved in the Xine
> > project as part of our good intentions with this project.
> >
> > I look forward to your reply.
> >
> > Best Regards
> >
> > Tim Handley
> > Processor Platform Marketing Manager
> > VIA Technologies, Inc.
> >
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> xine-devel mailing list
> xine-devel@...
> https://lists.sourceforge.net/lists/listinfo/xine-devel
>

[xine-devel] In the news

[James Stembridge <jstembridge@us...>]

"Via improves Open Source media player"

http://www.theinquirer.net/?article=18100

[xine-devel] FourCC Patch

[Drew 'dantealiegri' Ogle <dantealiegri@um...>]

I have a AVI/RIFF file that has mpeg1 data in it with the fourCC 'mpg1'.

This patch allows it to be played back.

-dante

Re: PATCH: Xxmc plugin WAS [xine-devel] New XxMC xine plugin.

[<unichrome@sh...>]

Hi!

Following your recommendations I post the latest version of the XxMC plugin.
This one will hopefully stay reasonably static for a while.

Regards
Thomas

Re: [xine-devel] win32 compile

[<valtri@us...>]

Hi Stephane,

V St, 11. 08. 2004 v 16:18, Stephane Konstantaropoulos p=C3=AD=C5=A1e:
> Hello Everybody,
>=20
> Did anybody ever manage to compile xine-lib with mingw32?

I did some patches, but it isn't in CVS yet - there are bigger changes
in configure/Makefiles and I found some problems yet.

>=20
> The first error that occured was dlopen was not found, I then modified
> configure to use libltdl instead of libdl, it goes ok, it still says it
> cannot find directX which is normal as I do not have directX sdk
> installed and I am cross-compiling.
>=20

The solution in deprecated MSVC win32 port is using LoadLibrary and
FreeLibrary and this works also for MINGW32. Using just libltdl is
interresting idea.

And DirectX is needed in win32 port - it's only working audio and video
output. With DirectX SDK headers it will maybe successfuly cross
compile.

> Has somebody been playing with this ever (lately -- I know there was an
> old port)?
>=20

Cheers,
  Frantisek

Re: [xine-devel] wmvdmod.dll not working

[<valtri@us...>]

Hi James,

V St, 18. 08. 2004 v 00:21, James Stembridge p=C3=AD=C5=A1e:=20
> Hi,
>=20
> I've just had a look at this bug:
> http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D987852&gro=
up_id=3D9655&atid=3D109655
>=20
> >From my testing here it would appear that loading wmvdmod.dll (which i=
s used=20
> if wmvds32.ax isn't available) causes a segfault. I think there have be=
en=20
> some changes in this loader recently that might have caused this?
>=20

I had this segfault also before these changes.

> Anyway, perhaps someone more knowledgable about this win32 stuff would =
like to=20
> take a look at it.
>=20

The problem is inside wine loader. There are two independend conditions
which cause segfault:

  1) nptl threads
  2) execshield

Running xine with following command is "double-workaround":

  LD_ASSUME_KERNEL=3D2.4.19 setarch i386 xine

Note, there is some change in execshield in 2.6.8 Fedora kernel, so one
workaround is different. Update notes speak something about newer
setarch application and about command 'setarch -L <application>'.

Cheers,
  Frantisek

Re: [xine-devel] fix for non iso-8859 subtitles for Matroska

[Michael Roitzsch <mroi@us...>]

Hi Miguel,

> > buf->decoder_info[0] = BE_FOURCC('U', 'T', 'F', '8');
>
> wow, i should have read your message first, i just wrote almost the
> same idea! ;-)

I guess that increases the probability that it is a good idea. ;)

Michael

-- 
panic ("No CPUs found.  System halted.\n");
	2.4.3 linux/arch/parisc/kernel/setup.c