<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>70062</bug_id>
          
          <creation_ts>2004-11-04 08:54 0000</creation_ts>
          <short_desc>[PATCH] Kino using ffmpeg optionally instead of libdv</short_desc>
          <delta_ts>2005-01-26 02:36:42 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Applications</component>
          <version>unspecified</version>
          <rep_platform>AMD64</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>enhancement</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>neil@digimed.co.uk</reporter>
          <assigned_to>media-video@gentoo.org</assigned_to>
          <cc>kugelfang@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>neil@digimed.co.uk</who>
            <bug_when>2004-11-04 08:54:42 0000</bug_when>
            <thetext>libdv doesn&apos;t work consistently well on amd64. This manifests itself as extremely slow playback rates in Kino. The recommended fix is to compile Kino with --with-avcodec to use the ffmpeg avcodec instead of libdv. This patch to the ebuild adds an avcodev USE flag to compile with --with-avcodec.

Reproducible: Always
Steps to Reproduce:
1. Load any DV file into Kino
2. Try to play it.
3.

Actual Results:  
Video plays at &lt;5fps with 100% CPU usage. 

Expected Results:  
Played normally. 

Portage 2.0.51-r2 (default-linux/amd64/2004.3, gcc-3.4.2, 
glibc-2.3.4.20041021-r0, 2.6.9-gentoo-r2 x86_64) 
================================================================= 
System uname: 2.6.9-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3200+ 
Gentoo Base System version 1.6.5 
distcc 2.18 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) 
[disabled] 
ccache version 2.3 [enabled] 
Autoconf: sys-devel/autoconf-2.59-r5 
Automake: sys-devel/automake-1.8.5-r1 
Binutils: sys-devel/binutils-2.15.92.0.2-r1 
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1 
Libtools: sys-devel/libtool-1.5.2-r5 
ACCEPT_KEYWORDS=&quot;amd64 ~amd64&quot; 
AUTOCLEAN=&quot;yes&quot; 
CFLAGS=&quot;-march=athlon64 -O2 -pipe -fomit-frame-pointer -funit-at-a-time&quot; 
CHOST=&quot;x86_64-pc-linux-gnu&quot; 
COMPILER=&quot;&quot; 
CONFIG_PROTECT=&quot;/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control&quot; 
CONFIG_PROTECT_MASK=&quot;/etc/gconf /etc/terminfo /etc/env.d&quot; 
CXXFLAGS=&quot;-march=athlon64 -O2 -pipe -fomit-frame-pointer -funit-at-a-time&quot; 
DISTDIR=&quot;/mnt/portage/distfiles&quot; 
FEATURES=&quot;autoaddcvs buildpkg ccache distlocks sandbox&quot; 
GENTOO_MIRRORS=&quot;ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ 
ftp://ftp.heanet.ie/pub/gentoo/ 
ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ 
ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo/ 
ftp://ftp.easynet.nl/mirror/gentoo/&quot; 
MAKEOPTS=&quot;-j2&quot; 
PKGDIR=&quot;/mnt/portage/packages/hactar&quot; 
PORTAGE_TMPDIR=&quot;/mnt/scratch&quot; 
PORTDIR=&quot;/usr/portage&quot; 
PORTDIR_OVERLAY=&quot;/mnt/portage/local /mnt/portage/bmg-main&quot; 
SYNC=&quot;rsync://desatio/gentoo&quot; 
USE=&quot;amd64 X aalib acpi alsa apache2 arts artswrappersuid berkdb bitmap-fonts 
bonobo cdr crypt cups directfb dv dvd dvdr encode esd f77 fam flac foomaticdb 
gdbm gif gimpprint gphoto2 gpm gstreamer gtk gtkhtml guile imagemagick imlib 
ipv6 jabber java jbig jp2 jpeg junit kde ldap lesstif libwww lzw lzw-tiff mad 
mailwrapper mikmod mozilla mpeg multilib mysql ncurses nls nptl oggvorbis 
opengl oss pam perl png ppds python qt readline samba scanner sdl slang slp ssl 
tcltk tcpd tiff truetype usb userlocales xml xml2 xmms xpm xprint xrandr xv 
xvid zlib video_cards_nvidia linguas_en_GB&quot;</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>neil@digimed.co.uk</who>
            <bug_when>2004-11-04 08:55:49 0000</bug_when>
            <thetext>Created an attachment (id=43290)
Patches kino.0.7.5.ebuild to handle avcode USE flag
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>neil@digimed.co.uk</who>
            <bug_when>2004-11-04 08:57:11 0000</bug_when>
            <thetext>Sorry, the USE flag is avcodec.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>adrian@basicsedv.de</who>
            <bug_when>2004-12-31 04:22:42 0000</bug_when>
            <thetext>This ebuild works very well for me but the real enhancment is not obvius to me. Maybe you can explain this a little clearer.

Adrian</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>neil@digimed.co.uk</who>
            <bug_when>2005-01-01 08:43:10 0000</bug_when>
            <thetext>As i the original report, using libdv instead of avcodec results in extremely slow performance on amd64. The ebuild modification simply changes the compilation options to use avcodec instead of the default libdv. From some of the posts I&apos;ve seen, it would appear that this does not affect everyone.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2005-01-02 09:56:47 0000</bug_when>
            <thetext>Reassigning to video herd... This is no amd64 business.

Guys, this patch works nicely. The only change I propose is to use &quot;ffmpeg&quot; USE-Flag instead avcodec.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2005-01-02 10:00:50 0000</bug_when>
            <thetext>Created an attachment (id=47388)
New patch against kino-0.7.5.ebuild

Here a cleaned version of above patch using ffmpeg USE-Flag and correct
dependencies.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>malc@gentoo.org</who>
            <bug_when>2005-01-10 18:49:46 0000</bug_when>
            <thetext>Concerned parties... I just committed libdv-0.104 to the tree - it contains x86_64 asm which should solve all your slow Kino playback problems. I&apos;m leaving this bug open for now as the option to use ffmpeg is still useful... 

Neil, Please test libdv-0.104 and see if it resolves the issue on your system.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>neil@digimed.co.uk</who>
            <bug_when>2005-01-11 07:14:22 0000</bug_when>
            <thetext>Yes thanks, that&apos;s done the trick. Kino now plays back at normal speed, with the same CPU load whether it is compiled with libdv or ffmpeg.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2005-01-25 14:21:30 0000</bug_when>
            <thetext>Ping? ;-) Zypher, would you commit and close plz ? TIA</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>zypher@gentoo.org</who>
            <bug_when>2005-01-26 02:36:42 0000</bug_when>
            <thetext>I changed the optional libdv back to a normal dep because otherwise kino won&apos;t build.
Apart from that the changes are in cvs. 
Please test.
Marc.</thetext>
          </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>43290</attachid>
            <date>2004-11-04 08:55 0000</date>
            <desc>Patches kino.0.7.5.ebuild to handle avcodec USE flag</desc>
            <filename>kino-0.7.5.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGtpbm8tMC43LjUuZWJ1aWxkLm9yaWcJMjAwNC0xMS0wMyAwOTozODoyNi4wMDAwMDAwMDAg
KzAwMDAKKysrIGtpbm8tMC43LjUuZWJ1aWxkCTIwMDQtMTEtMDQgMTY6NDY6NDkuNzcxODYwMDAw
ICswMDAwCkBAIC04LDcgKzgsNyBAQAogSE9NRVBBR0U9Imh0dHA6Ly9raW5vLnNjaGlybWFjaGVy
LmRlLyIKIFNSQ19VUkk9Im1pcnJvcjovL3NvdXJjZWZvcmdlL2tpbm8vJHtQfS50YXIuZ3oiCiBS
RVNUUklDVD0ibm9taXJyb3IiCi1JVVNFPSJxdWlja3RpbWUgZHZkciIKK0lVU0U9ImF2Y29kZWMg
cXVpY2t0aW1lIGR2ZHIiCiBMSUNFTlNFPSJHUEwtMiIKIFNMT1Q9IjAiCiBLRVlXT1JEUz0ifng4
NiB+c3BhcmMgfmFtZDY0IH5wcGMiCkBAIC0yNywxMyArMjcsMTYgQEAKIAltZWRpYS1saWJzL2xp
YnNhbXBsZXJhdGUKIAltZWRpYS12aWRlby9tanBlZ3Rvb2xzCiAJbWVkaWEtc291bmQvcmF3cmVj
CisJYXZjb2RlYz8gKCBtZWRpYS12aWRlby9mZm1wZWcgKQogCXF1aWNrdGltZT8gKCB2aXJ0dWFs
L3F1aWNrdGltZSApCiAJZHZkcj8gKCBtZWRpYS12aWRlby9kdmRhdXRob3IgKSIKIAorCiBzcmNf
Y29tcGlsZSgpIHsKIAllY29uZiBcCiAJCS0tZGlzYWJsZS1kZXBlbmRlbmN5LXRyYWNraW5nIFwK
IAkJLS1kaXNhYmxlLWRlYnVnIFwKKwkJYHVzZV93aXRoIGF2Y29kZWNgIFwKIAkJYHVzZV93aXRo
IHF1aWNrdGltZWAgfHwgZGllCiAKIAllbWFrZSB8fCBkaWUK
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>47388</attachid>
            <date>2005-01-02 10:00 0000</date>
            <desc>New patch against kino-0.7.5.ebuild</desc>
            <filename>kino-ffmpeg.diff</filename>
            <type>text/plain</type>
            <data encoding="base64">SW5kZXg6IGtpbm8tMC43LjUuZWJ1aWxkCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC92YXIvY3Zzcm9v
dC9nZW50b28teDg2L21lZGlhLXZpZGVvL2tpbm8va2luby0wLjcuNS5lYnVpbGQsdgpyZXRyaWV2
aW5nIHJldmlzaW9uIDEuMQpkaWZmIC11IC1iIC1CIC1yMS4xIGtpbm8tMC43LjUuZWJ1aWxkCi0t
LSBraW5vLTAuNy41LmVidWlsZAkzIE5vdiAyMDA0IDA5OjM4OjI2IC0wMDAwCTEuMQorKysga2lu
by0wLjcuNS5lYnVpbGQJMiBKYW4gMjAwNSAxNzo0NzowMiAtMDAwMApAQCAtOCw3ICs4LDcgQEAK
IEhPTUVQQUdFPSJodHRwOi8va2luby5zY2hpcm1hY2hlci5kZS8iCiBTUkNfVVJJPSJtaXJyb3I6
Ly9zb3VyY2Vmb3JnZS9raW5vLyR7UH0udGFyLmd6IgogUkVTVFJJQ1Q9Im5vbWlycm9yIgotSVVT
RT0icXVpY2t0aW1lIGR2ZHIiCitJVVNFPSJxdWlja3RpbWUgZHZkciBmZm1wZWciCiBMSUNFTlNF
PSJHUEwtMiIKIFNMT1Q9IjAiCiBLRVlXT1JEUz0ifng4NiB+c3BhcmMgfmFtZDY0IH5wcGMiCkBA
IC0yMyw3ICsyMyw4IEBACiAJbWVkaWEtc291bmQvZXNvdW5kCiAJc3lzLWxpYnMvbGlicmF3MTM5
NAogCXN5cy1saWJzL2xpYmF2YzEzOTQKLQk+PW1lZGlhLWxpYnMvbGliZHYtMC4xMDIKKwlmZm1w
ZWcgKCBtZWRpYS12aWRlby9mZm1wZWcgKQorCSFmZm1wZWc/ICggPj1tZWRpYS1saWJzL2xpYmR2
LTAuMTAyICkKIAltZWRpYS1saWJzL2xpYnNhbXBsZXJhdGUKIAltZWRpYS12aWRlby9tanBlZ3Rv
b2xzCiAJbWVkaWEtc291bmQvcmF3cmVjCkBAIC0zNCw3ICszNSw4IEBACiAJZWNvbmYgXAogCQkt
LWRpc2FibGUtZGVwZW5kZW5jeS10cmFja2luZyBcCiAJCS0tZGlzYWJsZS1kZWJ1ZyBcCi0JCWB1
c2Vfd2l0aCBxdWlja3RpbWVgIHx8IGRpZQorCQlgdXNlX3dpdGggcXVpY2t0aW1lYFwKKwkJYHVz
ZV93aXRoIGZmbXBlZyBhdmNvZGVjYCB8fCBkaWUKIAogCWVtYWtlIHx8IGRpZQogfQo=
</data>        

          </attachment>
    </bug>

</bugzilla>