[vlc-devel] Re: Problem compiing vlc SVN on Fedora Core 2
gbazin at altern.org
Sun Aug 22 19:40:32 CEST 2004
On Sunday 22 August 2004 18:31, R. Bernstein wrote:
> Gildas Bazin writes (out of order):
> [release readiiness]
> > I think the only other broken plugins are the vcdx and cddax ones
> Actually, what got me onto this was trying to fix the breakage in the
> ogt and cvd subtitles. So add those two the list.
Ok I should have fixed them now.
The subpictures infrastructure has changed a lot recently. We did keep
backward compatibility with the old architecture but an api call was
changed nonetheless and I forgot to update the ogt/cvd decoders.
If you feel like it, you can update the ogt/cvd to the new architecture. The
main change is that the subpicture decoders don't do the rendering
themselves now (we have an alphablend plugin which takes care of this),
they just return a decoded subpicture in YUVP (palettized I444). That
allows us to avoid code duplication but as well allows things like
subpictures transcoding for the streaming output.
You can have a look at the spudec decoder for an example.
Ah another thing to fix is the SCR problem with your ogt stream.
The work-around that you implement in the old mpeg demuxer wasn't ported to
the new one.
I guess the work-around will have to be implemented in modules/demux/ps.c
around line 183.
> The test example I
> tried was one mentioned in the past:
> The above link is down, and it is unclear whether it will be
> reinstated soon. So I've put it temporarily in
> I hope someone can copy it to a videolan-centric test area if there is
I'm uploading them to http://download.videolan.org/pub/videolan/streams/svcd
> A small thing I've noticed is that although I can start svlc and wxvlc
> okay, if I start wxvlc and then try to switch to the skinned version I
> get a core dump. Here is a traceback.
> (gdb) where
> #0 0x045389a5 in wxObject::UnRef () from /usr/lib/libwx_gtk-2.4.so.0
> #1 0x0443430a in wxColour::~wxColour () from /usr/lib/libwx_gtk-2.4.so.0
> #2 0x04584a5d in wxWindowBase::InitBase ()
> #3 0x0458959e in wxWindowBase::wxWindowBase ()
> from /usr/lib/libwx_gtk-2.4.so.0
> #4 0x04482dcb in wxWindow::wxWindow () from /usr/lib/libwx_gtk-2.4.so.0
> #5 0x04437932 in wxControl::wxControl () from /usr/lib/libwx_gtk-2.4.so.0
> #6 0x01427707 in Messages (this=0x8508840, _p_intf=0xffffff9b,
> at button.h:47
> #7 0x013ee9d3 in DialogsProvider (this=0x8506fa8, _p_intf=0x85279e0,
> p_parent=0x0) at dialogs.cpp:154
> #8 0x013ee3d0 in CreateDialogsProvider (p_intf=0xbb, p_parent=0xbb)
> at dialogs.cpp:129
> #9 0x013dcc29 in Instance::OnInit (this=0x84cbd58) at wxwindows.cpp:308
> #10 0x04429828 in wxEntry () from /usr/lib/libwx_gtk-2.4.so.0
> #11 0x013dc926 in Init (p_intf=0xbb) at wxwindows.cpp:253
> #12 0x006c898c in start_thread () from /lib/tls/libpthread.so.0
> #13 0x001cc16a in clone () from /lib/tls/libc.so.6
> For me this is not critical -- I just won't do the switching.
This one is actually a bug in wxWindows itself.
I sent them a patch for it a long time ago but apparently they didn't apply
it to the stable branch.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel