Handbrake 1.2.2-1.16: No Sound on Tumbleweed

Hinweis: In dem Thema Handbrake 1.2.2-1.16: No Sound on Tumbleweed gibt es 10 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Moinsen an die Gemeinde,


    System: openSUSE Tumbleweed mit KDE (2019-08-14 = up to date)
    Hardware: Gigabyte Z370 HD3P-CF mit genuine Intel


    seit dem Upate von HandBrake auf Version 1.2.2-1.16
    wird die Soundquelle zwar richtig erkannt, aber nicht mehr codiert.
    Es funktioniert nur 'pass-through'.


    Wie bekomme ich das wieder zum 'laufen'?

    Für den Inhalt des Beitrages 135133 haftet ausdrücklich der jeweilige Autor: leofisch

  • Mit Tumbledingsdabumsda habe ich nichts am Hut.
    Es ist aber wichtig, daß es User testen.


    Ich würde im Yast unter Versionen versuchen die alte Version zu installieren.

    Für den Inhalt des Beitrages 135135 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • Zitat von leofisch

    seit dem Upate von HandBrake auf Version 1.2.2-1.16
    wird die Soundquelle zwar richtig erkannt, aber nicht mehr codiert.

    Welches sind denn Quell- bzw Zielformat? Dann kann ich versuchen das hier zu reproduzieren.
    Das genaue Quellformat kannst mit mediainfo bzw mediainfo-gui ermitteln.


    Was sagen denn
    zypper lr -uP
    zypper ve
    zypper se -si handbrake
    als root ausgeführt


    Bei mir installiert unter Tumbleweed :

    Code
    zypper se -si handbrake
    Repository-Daten werden geladen...
    Installierte Pakete werden gelesen...
    S | Name | Typ | Version | Arch | Repository
    ---+--------------------+-------+------------+--------+-------------------
    i+ | handbrake-gtk | Paket | 1.2.2-1.17 | x86_64 | Packman Repository
    i+ | handbrake-gtk-lang | Paket | 1.2.2-1.17 | noarch | Packman Repository
  • Danke erst einmal, dass sich ein 'mitfühlend Herz' der Sache annimmt.


    zypper lr -uP:

    Code
    # | Alias | Name | Aktiviert | GPG-Überprüfung | Aktualisierung | Priorität | URI
    --+----------------------------------------+-------------------------------+-----------+-----------------+----------------+-----------+----------------------------------------------------------------------------------
    1 | openSUSE-20190408-0 | openSUSE-20190408-0 | Nein | ---- | ---- | 99 | hd:/?device=/dev/disk/by-id/usb-Intenso_Ultra_Line_15082500000909-0:0-part2
    2 | openSUSE_Tumbleweed | KDE_Extra_openSUSE_Tumbleweed | Ja | (r ) Ja | Ja | 99 | http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/
    3 | openSUSE_Tumbleweed_1 | openjfx (Mediathekview) | Ja | (r ) Ja | Ja | 99 | http://download.opensuse.org/repositories/home:/Herbster0815/openSUSE_Tumbleweed/
    4 | opensuse-guide.org-openSUSE_Tumbleweed | libdvdcss repository | Ja | (r ) Ja | Ja | 99 | http://opensuse-guide.org/repo/openSUSE_Tumbleweed/
    5 | packman.inode.at-openSUSE_Tumbleweed | Packman Repository | Ja | (r ) Ja | Ja | 99 | http://packman.inode.at/suse/openSUSE_Tumbleweed/
    6 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Ja | (r ) Ja | Ja | 99 | http://download.opensuse.org/tumbleweed/repo/non-oss/
    7 | repo-oss | openSUSE-Tumbleweed-Oss | Ja | (r ) Ja | Ja | 99 | http://download.opensuse.org/tumbleweed/repo/oss/
    8 | repo-update | openSUSE-Tumbleweed-Update | Ja | (r ) Ja | Ja | 99 | http://download.opensuse.org/update/tumbleweed/



    zypper ve:
    Repository-Daten werden geladen...
    Installierte Pakete werden gelesen...
    Die Abhängigkeiten aller installierten Pakete sind berücksichtigt.


    zypper se -si hanbrake:
    Repository-Daten werden geladen...
    Installierte Pakete werden gelesen...

    Code
    Repository-Daten werden geladen...
    Installierte Pakete werden gelesen...
    S | Name | Typ | Version | Arch | Repository
    ---+--------------------+-------+------------+--------+-------------------
    i+ | handbrake-cli | Paket | 1.2.2-1.18 | x86_64 | Packman Repository
    i+ | handbrake-gtk | Paket | 1.2.2-1.18 | x86_64 | Packman Repository
    i+ | handbrake-gtk-lang | Paket | 1.2.2-1.18 | noarch | Packman Repository

    Quellformat:
    Container:

    Code
    Format : Matroska
    Format version : Version 4
    File size : 728 MiB
    Duration : 1 h 47 min
    Overall bit rate : 948 kb/s
    Encoded date : UTC 2019-08-28 12:44:29
    Writing application : mkvmerge v7.9.0 ('Birds') 64bit
    Writing library : libebml v1.3.1 + libmatroska v1.4.2

    Quellformat Audio:


    Audio Quellformat wird richtig erkannt und auch zur codierung angeboten.


    Zielformat: mp4, orginal audio (AAC | AC-3 | mp3 | etc) wird beibehalten,
    jedoch auf mono 64 kbps 'eingedampft' (ich persönlich brauche keine 6 Kanäle je 448 kbps um einer Unterhaltung zu folgen :D )
    Das hat bis zur Version 1.2.2-1.16 (oder bis vor dem 13.08.2019) auch funktioniert.


    Jetzt wird allerdings folgendes im activity-log protokolliert und meeeehrfach wiederholt:
    [SWR @ 0x7f6dd800cec0] Requested input sample rate 0 is invalid
    [22:26:24] decavcodec: hb_audio_resample_update() failed


    Als Work-Around benutze ich AVI-Demux, erledige den Audio Anteil,
    die so entstandene Datei bearbeite ich dann mit Handbrake mit Audio Pass-Through
    Funktioniert zwar, ist aber leider ein zusätzlicher Schritt.


    Bin gespannt ob es hier eine Lösung gibt...


    Gruss

    Für den Inhalt des Beitrages 135457 haftet ausdrücklich der jeweilige Autor: leofisch

  • Eventuell hilft es auch schon das Packman Repository passend zu priorisieren und dann nach der Anleitung hier im Forum die Installation korrekt darauf umzustellen. Da AC-3 ein lizensiertes/patentiertes Format ist, könnte es durchaus sein, dass die Version aus dem OSS Repository (falls diese installiert ist) in dieser Hinsicht eingeschränkt ist. Ich bin leider noch nicht dazu gekommen das nachzustellen.
    Auszug von zypper se -s ffmpeg auf meinem System :

    Code
    i | ffmpeg-4 | Paket | 4.2-6.2 | x86_64 | Packman Repository
    v | ffmpeg-4 | Paket | 4.2-6.2 | i586 | Packman Repository
    v | ffmpeg-4 | Paket | 4.2-3.1 | x86_64 | openSUSE-Tumbleweed-Oss
    v | ffmpeg-4 | Paket | 4.2-3.1 | i586 | openSUSE-Tumbleweed-Oss
    v | ffmpeg-4 | Paket | 4.2-95.4 | x86_64 | Multimedia Libs
    v | ffmpeg-4 | Paket | 4.2-95.4 | i586 | Multimedia Libs
    | ffmpeg-4 | Quellpaket | 4.2-6.2 | noarch | Packman Repository
    | ffmpeg-4 | Quellpaket | 4.2-3.1 | noarch | openSUSE-Tumbleweed-Source
    | ffmpeg-4 | Quellpaket | 4.2-95.4 | noarch | Multimedia Libs
  • Ich habe das jetzt mal mit einem kleinen Democlip getestet.
    Ausgangsvideo :


    Mit Handbrake funktioniert das offensichtlich tatsächlich nicht.
    Dann habe ich den Clip mit FFmpegYAG recodiert. Da funktioniert das problemlos.


    Hier die Daten :

    Eventuell wäre das für dich eine Alternative, bis das mit Handbrake funktioniert. Die Bedienung ist eigentlich selbsterklärend.



    Aber trotzdem solltest du Packman richtig priorisieren und darauf umstellen.

  • Hallo Trekkie00,


    danke für den Hinweis auf FFmpegYAG.
    Das ist wirklich ein schönes Tool.


    Das mit der Priorisierung habe ich nicht wirklich begriffen,
    daher überprüfe ich regelmässig mit 'System auf Packman umstellen' um Konsistenz herzustellen.
    Nehme aber gerne einen Vorschlag zur Priorisierung an.


    Im handbrake Forum war ich schon und hab die Situation geschildert.
    Dort bekommt man aber nur eine vernünftige Antwort/Support wenn man *buntu benutzt.


    Was ist jetzt zu tun, damit ghb wieder komplett funktioniert?


    Gruß an alle Helfenden





    Für den Inhalt des Beitrages 135488 haftet ausdrücklich der jeweilige Autor: leofisch

  • daher überprüfe ich regelmässig mit 'System auf Packman umstellen' um Konsistenz herzustellen.
    Nehme aber gerne einen Vorschlag zur Priorisierung an.

    Einfach ausgedrückt:
    Wenn ein Repo höher priorisiert ist (kleinere Zahl), wird bei einer Installation eines noch nicht installierten Paketes zuerst die Priorität benutzt, danach die Version. Dann wird das Paket aus dem Repo mit der höheren Priorität installiert. Deswegen sollte man Packman höher priorisieren.....
    Ebenso wenn das Paket schon installiert ist, aber ein zypper install --force xxxx abgesetzt wird.
    Das gilt natürlich nur für Pakete gleichen Namens, z.B. vlc usw.