VLC does not support the audio or video format "XVID".
in [Ports]
|
From: Doug Barton on 18 Apr 2010 02:48 I recently updated -current, and all of my ports, and am now getting the following message when I try to watch an avi file encoded with xvid: No suitable decoder module: VLC does not support the audio or video format "XVID". Unfortunately there is no way for you to fix this. Recompiling vlc, xvid, and numerous other things didn't help. Any suggestions? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Doug Barton on 18 Apr 2010 17:46 On 04/17/10 23:48, Doug Barton wrote: > I recently updated -current, and all of my ports, and am now getting the > following message when I try to watch an avi file encoded with xvid: > > No suitable decoder module: > VLC does not support the audio or video format "XVID". Unfortunately > there is no way for you to fix this. > > Recompiling vlc, xvid, and numerous other things didn't help. Any > suggestions? I have found the problem, it's zlib. In r206708-9 delphij updated zlib to version 1.2.4.3 and did some magic with the symbols. I just regressed my system to r206707 and now the same vlc does xvid just fine. When I booted the new -current yesterday (after the libz changes) I had to rebuild and reinstall openbox and libxml2 because the latter had some sort of unresolved symbol problem related to libz. When I regressed the system today and had to do the same thing I got this error: /usr/local/lib/libxml2.so: undefined reference to `gzopen(a)ZLIB_1.2.4.0' (Note, this libxml2 that generated this error was compiled against the NEW libz, so it's not the error that I was seeing previously.) In looking over the things in /usr/lib that may be related I see that gpac-libgpac-0.4.5_4,1 has the gzopen symbol, and I did not recompile that when I was trying to get vlc to work last night so it may be the magic bullet. My plan at this point is to re-upgrade to the latest -current, record the error I get from libxml2 when recompiling openbox, and then try recompiling stuff until I find the one that does the trick. Worst case scenario I do 'portmaster -f vlc' but that constitutes 175 ports, which would take a while. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Garrett Cooper on 18 Apr 2010 19:30 On Sun, Apr 18, 2010 at 2:46 PM, Doug Barton <dougb(a)freebsd.org> wrote: > On 04/17/10 23:48, Doug Barton wrote: >> I recently updated -current, and all of my ports, and am now getting the >> following message when I try to watch an avi file encoded with xvid: >> >> No suitable decoder module: >> VLC does not support the audio or video format "XVID". Unfortunately >> there is no way for you to fix this. >> >> Recompiling vlc, xvid, and numerous other things didn't help. Any >> suggestions? > > I have found the problem, it's zlib. In r206708-9 delphij updated zlib > to version 1.2.4.3 and did some magic with the symbols. I just regressed > my system to r206707 and now the same vlc does xvid just fine. > > When I booted the new -current yesterday (after the libz changes) I had > to rebuild and reinstall openbox and libxml2 because the latter had some > sort of unresolved symbol problem related to libz. When I regressed the > system today and had to do the same thing I got this error: > /usr/local/lib/libxml2.so: undefined reference to `gzopen(a)ZLIB_1.2.4.0' > > (Note, this libxml2 that generated this error was compiled against the > NEW libz, so it's not the error that I was seeing previously.) > > In looking over the things in /usr/lib that may be related I see that > gpac-libgpac-0.4.5_4,1 has the gzopen symbol, and I did not recompile > that when I was trying to get vlc to work last night so it may be the > magic bullet. > > My plan at this point is to re-upgrade to the latest -current, record > the error I get from libxml2 when recompiling openbox, and then try > recompiling stuff until I find the one that does the trick. Worst case > scenario I do 'portmaster -f vlc' but that constitutes 175 ports, which > would take a while. Yeah... that's what I thought it was. vlc does some interesting work initializing codecs I think where it disguises runtime linker issues, etc with pieces that tie into vlc. Not really happy about that, but after the issue with zlib was identified 2~3 weeks ago, it was easy to clean up... The other issues with zlib are pretty well known, and the overall upgrade as I and others mentioned a few weeks back is large as it's use is pervasive in 3rd party software. HTH, -Garrett _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Doug Barton on 18 Apr 2010 20:11 On 04/18/10 16:30, Garrett Cooper wrote: > On Sun, Apr 18, 2010 at 2:46 PM, Doug Barton <dougb(a)freebsd.org> wrote: > >> My plan at this point is to re-upgrade to the latest -current, record >> the error I get from libxml2 when recompiling openbox, and then try >> recompiling stuff until I find the one that does the trick. Worst case >> scenario I do 'portmaster -f vlc' but that constitutes 175 ports, which >> would take a while. > > Yeah... that's what I thought it was. So we each get a cookie. :) My plan worked, and after recompiling gpac-libgpac vlc can once again understand divx. The error I got when trying to rebuild openbox with an old libxlm2 (linked against the old libz) was: undefined reference to `gzopen(a)ZLIBprivate_1.0' Which makes sense because if I'm reading the change in r206709 right, that's exactly what happened (gzopen et al moved from the private interface to the public one). For delphij's sake I'm not sure if there is a "bug" here. For something with less subtle use of shared libs the solution would have been obvious. It's the fact that (as Garrett pointed out) vlc plays tricks that masked the real source of the problem. Regards, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Xin LI on 19 Apr 2010 01:10 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/04/18 17:11, Doug Barton wrote: > On 04/18/10 16:30, Garrett Cooper wrote: >> On Sun, Apr 18, 2010 at 2:46 PM, Doug Barton <dougb(a)freebsd.org> wrote: >> >>> My plan at this point is to re-upgrade to the latest -current, record >>> the error I get from libxml2 when recompiling openbox, and then try >>> recompiling stuff until I find the one that does the trick. Worst case >>> scenario I do 'portmaster -f vlc' but that constitutes 175 ports, which >>> would take a while. >> >> Yeah... that's what I thought it was. > > So we each get a cookie. :) My plan worked, and after recompiling > gpac-libgpac vlc can once again understand divx. The error I got when > trying to rebuild openbox with an old libxlm2 (linked against the old > libz) was: undefined reference to `gzopen(a)ZLIBprivate_1.0' > > Which makes sense because if I'm reading the change in r206709 right, > that's exactly what happened (gzopen et al moved from the private > interface to the public one). > > For delphij's sake I'm not sure if there is a "bug" here. For something > with less subtle use of shared libs the solution would have been > obvious. It's the fact that (as Garrett pointed out) vlc plays tricks > that masked the real source of the problem. Sorry for that. It looks like that the zlib author decided to drop usage of *64 functions on non-LFS64 platforms (in the past for instance gzopen() is #define'd as gzopen64()). To prevent future breakage, I think the only way to get around of this would be to move all potential "public" interfaces to the ZLIB_1.2.4.0 part. E.g. make sure that those exposed by zlib.h are always available in the same public namespace rather than only exposing the "available" ones. I'm working on an interface checker program to make sure that the "committed" interfaces won't change again. Cheers, - -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLy+XYAAoJEATO+BI/yjfBcN0IANAhfgkH0g7iwKHepAan3xGa VYDaF0r1t5SEUfcBIt0qyHYaw1+P/wBMl9MNGRQLAwUWEZmL5ZGOyOu1hhTM2RHx tdQ6q8dRgk2g1xa04YYcZ62sNmlGVVcTmOfKGINcWMkIcDFWj8w9AegYvBslopq+ LHB2rxMSBdasbooJtkUiUH03gnP1zdnide1CfoP/2PfAJzx5/F4ITFhEFoSt0+eH lXDGSPGygggI/wwy+9vEryyajFrQsiRHWhwzkwNdNZizBQP6uNNPdPjdZEa+8/59 dptJNneLMYHzqxq5Fe/J4LNm1MKMMgpKX97HmZUyswljk05fH80xIAT27hkEiTM= =lScc -----END PGP SIGNATURE----- _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
|
Pages: 1 Prev: mysql55-client + cmake = fail Next: Ynv Records Presents |