FS#19818 - [libvpx] libvpx.so.0 fails to load - disable psnr

Attached to Project: Arch Linux
Opened by Eric (zebulon) - Wednesday, 16 June 2010, 08:25 GMT
Last edited by Ionut Biru (wonder) - Wednesday, 16 June 2010, 12:56 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
libvpx-0.9.0-0.20100615 is broken for low-memory machines due to oversized .bss, breaking ffmpeg and mplayer at the same time. This bug has been reported upstream (see http://code.google.com/p/webm/issues/detail?id=78) and has been corrected by VP8 developers (commit available at https://review.webmproject.org/gitweb?p=libvpx.git;a=commitdiff;h=9099fc0d69a69525656b4bfeeb1e7aabec04897b).
Thanks for rebuilding libvpx package (and possibly ffmpeg and mplayer).
This task depends upon

Closed by  Ionut Biru (wonder)
Wednesday, 16 June 2010, 12:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  in 0.9.0-1
--enable-psnr has been removed from the PKGBUILD and should not be enabled by distributions, as this is a codec developement option and PSNR info is still available without it
Comment by Eric (zebulon) - Wednesday, 16 June 2010, 09:47 GMT
  • Field changed: Percent Complete (100% → 0%)
I apology, I made a mistake with the date.
I have exactly the same problem as the one reported there: https://bugzilla.redhat.com/show_bug.cgi?id=600663 which was supposedly corrected with the 11-06 patch. It does not seem to be the case. According to the git log, this is related to the --enable-psnr option. Is it possible to disable it until this is fixed ?
Comment by Eric (zebulon) - Wednesday, 16 June 2010, 09:50 GMT
Thanks for reopening. My suggestion of disabling psnr may not be the good one though, because it seems the patch was activating it. I'll try on my machine anyway and will report.
Comment by Ionut Biru (wonder) - Wednesday, 16 June 2010, 09:50 GMT
can you please reopen that upstream bug?
Comment by Eric (zebulon) - Wednesday, 16 June 2010, 09:59 GMT
Yes, I'll do it.
Comment by Ionut Biru (wonder) - Wednesday, 16 June 2010, 10:03 GMT
let me know if removing --enable-psnr is fixing that problem for now.
Comment by Eric (zebulon) - Wednesday, 16 June 2010, 10:09 GMT
I just tested it, removing the '--enable-psnr \' line does indeed fix the issue. I don't know if that functionality is required for other people though, so it may be a problem to disable PSNR (which is to my knowledge a good measurement of compression quality).
I am trying to find the correct mailing list to report it upstream, I guess that would be WebM 'codec-devel' list.
Comment by Eric (zebulon) - Wednesday, 16 June 2010, 10:12 GMT
After more considerations, it might be wise to disable PSNR for the time being, it is also known to interfere with prelinking (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583765). I shall let you know the progression after I submit the issue to the devs.
Comment by Eric (zebulon) - Wednesday, 16 June 2010, 12:40 GMT
After further research, it seems to me that the 11/06 patch does not really fix the issue, as shown at http://review.webmproject.org/#change,136. It only conditions the building of ssim.c when using --enable-psnr, so it is only a mere workaround. As the patch author comments, the huge amount of memory that is allocated by ssim.c (512MB) should be done in the heap, whereas currently it is static. I don't know if that patch was only intended to be temporary or a workaround, but at the moment it does not fix the issue. My suggestion is to disable psnr, until VP8 authors redesign the ssim memory management in their encoder.
Comment by Eric (zebulon) - Wednesday, 16 June 2010, 12:49 GMT
I just got an answer from a VP8 developer:

"--enable-psnr should never be set by distributions. its purpose is to
enable creation of a file 'opsnr.stt' which has some psnr and ssim
numbers in it. This file will be dropped in the current directory
unconditionally, which is not the behavior you want from a lib
installed system-wide. Users interested in getting PSNR information
from the encoder should use the PNSR packet interface (enabled with
the VPX_CODEC_USE_PSNR flag) which does not depend on --enable-psnr
being set."
https://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread/thread/abd9c540b3cb04ca#

I think this settles the issue and shall request closure.

Loading...