I've added initial xine support using the dshowserver. This is the only method I will support going forward. Note that it is still experimental, but I'll get the rough edges off pretty soon. Feedback is welcome of course. There is a new Wiki page detailing installation as well.
It should work with 64-bit xine (if yu download the 32bit dshowserver)
I've tried it using QT/AVC1, MPEG2-TS/H264 and MKV/H264. The old patch had support for some other demuxers (namely demux_mpeg.c) which I haven't implemented because I don't have any example streams.
On Sat, May 17, 2008 at 5:55 AM, Alan Nisota <alannis...@gmail.com> wrote:
> I've added initial xine support using the dshowserver. This is the only > method I will support going forward. Note that it is still > experimental, but I'll get the rough edges off pretty soon. Feedback is > welcome of course. There is a new Wiki page detailing installation as well.
> It should work with 64-bit xine (if yu download the 32bit dshowserver)
> I've tried it using QT/AVC1, MPEG2-TS/H264 and MKV/H264. > The old patch had support for some other demuxers (namely demux_mpeg.c) > which I haven't implemented because I don't have any example streams.
Hi Alan,
Thanks for all your work - its appreciated.
It would be nice if your xine patch worked for us long suffering VDR users too! It gets very close, here's the output of running VDR + XINE and switching to a HD channel: -
load_plugins: plugin dshowserver will be used for video streamtype 4d. vdr: osdflush: n: 1, 9.4, timeout: 0, result: 0 audio_out: inserting 9796 0-frames to fill a gap of 18372 pts set_speed 1000000 will resample audio from 48000 to 48000 shm:/dshow_shm.43005950 sem1:/dshow_sem1.43005950 sem2:/dshow_sem2.43005950 Opening device len: 992 ProductVersion: 1.7.0 Decoder supports the following YUV formats: YUY2 UYVY YV12 I420 Decoder is capable of YUV output (flags 0x2b) Setting fmt Starting Initialization is complete vdr: osdflush: n: 1, 9.4, timeout: 0, result: 0 vdr: osdflush: n: 1, 9.5, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 9.0, timeout: 0, result: 0 xiTK received SIGSEGV signal, RIP. DirectShow filter failedGot illegal command 0 ./runxine.sh: line 5: 28367 Aborted nice -15 /usr/local/bin/xine --verbose=2 --config /root/xine-config -f -pq -V xv -A alsa --post vdr_video --post vdr_audio -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=vektor,use_progressive_f rame_flag=1 vdr://tmp/vdr-xine/stream#demux:mpeg_pes
As you can see it eventually segfaults. When switching to a HD channel it sits at a black screen for about 4 seconds and then dies.
Is there any debugging information I can send you? Let me know what to run and I'll happily do it.
Also, I had to call CoreAVC 1.7.0 /usr/lib/win32/CoreAVCDecoder.ax.1.7.0_unpacked otherwise it didn't work.
compiled ok on my 64bit ubuntu against lib-xine-1.1.12, unfortunately
i don't have an unpacked version of coreavc 1.7.0 so i'm only getting
a green screen in gxine, or maybe it should work on my 1.5.0 and i did
something wrong ?
but i was wondering if the patch would also work on the libxine-1.2
branch ?
patched files are missing in that version, coz some recent apps
require xine-1.2 to work
Igor wrote: >> I've added initial xine support using the dshowserver. This is the only >> method I will support going forward.
> why did you decide so ? does dshowserver have the better performance ? is it possible to use this method on 32-bit platform ?
Because it is much easier to maintain (no possibility of patch conflicts, keeping patches up to date for mythtv/mplayer/xine is much easier, won't impact other win32 codecs). There is no noticable performance penalty to using dshowserver (but there's no gain either). It makes it much easier to use with 64bit linux as well. I've done this for mplayer as well, so from now on the only supported use of CoreAVC will be with dshowserver.
i've patched libxine-1.2 hg and fixed the basic patch/compilation
errors but it doesn't seems to use/see the dshowserver at all, whereas
it was "working" on my libxine-1.1.12 test.
not sure i did everything properly and don't know what's different
with 1.2 branch besides the two missing get_identifier /
get_description members no longer present and possibly simply replaced
by "identifier" and "description".
On May 17, 5:38 pm, eldon <Dr.E.Tyr...@gmail.com> wrote:
> i've patched libxine-1.2 hg and fixed the basic patch/compilation
> errors but it doesn't seems to use/see the dshowserver at all, whereas
> it was "working" on my libxine-1.1.12 test.
Oh nice, could you release a patch against xine-lib-1.2.
There something I don't understand : ls src/
audio_dec audio_out combined demuxers dxr3 input libmpeg2new
libreal libw32dll Makefile.am Makefile.in post spu_dec vdr
video_dec video_out xine-engine xine-utils
which miss the directory to be patched ???
On May 17, 7:23 pm, greg <Gregoire.Fa...@gmail.com> wrote:
> Oh nice, could you release a patch against xine-lib-1.2.
my patch doesn't work as far as i can tell.. i've just modified the
original patch so it will apply and build against libxine-1.2 hg, but
the xine completely ignores the dshowserver so it's quite useless..
i had to hack two functions inside dshowserver code and it produces
warnings during make but i don't know if it has something to do with
the fact that the patch doesn't work..
I guess we'll need to wait for our guru to see if if there's a more
serious problem with that libxine-1.2 branch
On May 17, 11:22 pm, eldon <Dr.E.Tyr...@gmail.com> wrote:
> my patch doesn't work as far as i can tell.. i've just modified the
> original patch so it will apply and build against libxine-1.2 hg, but
> the xine completely ignores the dshowserver so it's quite useless..
> i had to hack two functions inside dshowserver code and it produces
> warnings during make but i don't know if it has something to do with
> the fact that the patch doesn't work..
> I guess we'll need to wait for our guru to see if if there's a more
> serious problem with that libxine-1.2 branch
