einen neuen Rechner wollte ich aufsetzen und frage mich, ob ich auf Win10 verzichten kann und stattdessen mit Linux ([x]ubuntu) arbeiten kann. Hat jemand Erfahrungen? Oder Links zu Threads?
Das kann man mit Gewalt zwar irgendwie hinbiegen (wenn man viel Ahnung von Linux hat) aber damit tust du dir keinen Gefallen.
Nimm die Linux version von BM, die ist auf Resolve abgestimmt.
Aber was versprichst du dir überhaupt von de Nummer?
Das kann man mit Gewalt zwar irgendwie hinbiegen (wenn man viel Ahnung von Linux hat) aber damit tust du dir keinen Gefallen.
Nimm die Linux version von BM, die ist auf Resolve abgestimmt.
Danke, welche "Linuxversion von Blackmagic" meinst Du. Ich finde: " If you’re running Red Hat or CentOS Linux, you can even build your own workstation using low cost motherboards, extremely fast processors, massive amounts of RAM and up to 8 GPUs. Imagine building your own super computer for incredible real time performance!" (hier]
Aber was versprichst du dir überhaupt von de Nummer?
Weil sie eine Linux-Version anbieten, dachte ich, es wäre viell. "kein Problem". Was habe ich von Win10? Außer 40,00EUR Kosten, so dachte ich. Wenn ich da ewig rumbasteln muss, dann lieber Win10.
frankx hat geschrieben: ↑Fr 10 Jan, 2020 18:18Was habe ich von Win10? Außer 40,00EUR Kosten, so dachte ich.
Wenn du ein aktiviertes Win7 oder Win8 hast ist das Upgrade nach wie vor kostenlos möglich. Auch wenn du beides nicht hast kannst du Win10 erstmal installieren und austesten - anders als bisher sagt Microsoft nicht wann sie einen das Licht ausknipsen wenn man es nicht aktiviert. Nicht das ich dich von Linux abbringen wollen würde aber die Frage ist eher will ich Resolve lernen oder erstmal Linux (was nicht falsch ist ;-D).
Offiziell unterstützt Blackmagic für Resolve nur CentOS (also RedHat).
von den blackmagic CentOS DVDs würde ich wirklich ganz dringend abraten!
ganz abgesehen davon, dass sie auf neuerer hardware ohnehin nicht funktionieren bzw. relativ komplizierte updates erforden, sind sie einfach für alles andere als diese eine anwendung praktisch nicht zu gebrauchen.
wenn schon linux, dann gleich irgendwas vernünftiges, mit dem man tatsächlich arbeiten kann und wo auch brauchbare unterstützung in einer größeren benutzergemeinde findet.
am ehesten also wohl: debian/ubuntu/mint od. wenn man unbedingt das letzte an performance rausholen will: intels clear linux. natürlich gibt's auch noch ein paar andere alternativen, aber die sind für einsteiger nicht unbedingt optimal.
prinzipiell bringt man resolve natürlich auch unter debian/ubuntu/mint zum laufen. die unterscheide zwischen den einzelnen distributionen sind ja nicht derart unüberwindbar groß. es ist eher die unheimlich trotzige haltung einiger BMD entwickler bzw. support-mitarbeiter, die offenbar um jeden preis verhindern wollen, dass resolve reibungslos mit diesen am weitesten verbreiteten linux distributionen funktioniert. technisch wären die betreffenden probleme bzw. notwendigen adaptionen mit ein paar ganz trivialen patches in einem nachmittag gelöst.
leider muss man auch festhalten, dass ganz speziell die freie version von resolve deutlich weniger formate unterstützt als betreffende windows od. mac variante. auch ein paar ganz grobe bugs, die nur auf diesem system auftreten, werden seit ewigkeiten nicht gefixt...
wenn es also wirklich nur um resolve geht, würde ich dir vermutlich eher zu windows raten.
es gibt aber andere anwendungen, wo linux natürlich durchaus sinn macht. (baselight, mistika, nuke, flame/lustre)
ich persönlich arbeite seit jahrzehnten praktisch durchgängig nur mehr mit linux und komm damit ganz gut über die runden...
mash_gh4 hat geschrieben: ↑Fr 10 Jan, 2020 21:57
es ist eher die unheimlich trotzige haltung einiger BMD entwickler bzw. support-mitarbeiter, die offenbar um jeden preis verhindern wollen, dass resolve reibungslos mit diesen am weitesten verbreiteten linux distributionen funktioniert. technisch wären die betreffenden probleme bzw. notwendigen adaptionen mit ein paar ganz trivialen patches in einem nachmittag gelöst.
Es ist glaube ich wie mit allen anderen solchen Anwendungen, zu großer Aufwand für eine zu kleines und extrem zersplittertes und obendrein undankbares Klientel.
Linux Nutzer: Programm XY gibt es nicht für Linux.
Hersteller produziert Linux Version.
Linux Nutzer: argg warum nur deb und nicht rpm Pakete.
Hersteller erzeugt deb und rpm.
Linux Nutzer: arggh ist mit libxyz verlinkt, was unter super-niche-linux nicht vorhanden ist... Kein Quellcode, proprietäre Software ist Müll...
Hersteller: ...
Und das sag ich mit multiplen Debian (alles andere wäre doch eh Quatsch) Systemen im Einsatz seit mehr als 10 Jahren.
Wenn Mash Gh4 das schon seit 10 Jahren so macht und bei ihm das mit der benötigten Software so geht, dann finde ich das schon gut. Aber jetzt anfangen mit Linux dann noch zusammen mit dem eher labilen Resolve, mit den dauernden Updates (mit immer wieder kleinen neuen Buggs) ??
Das ist doch eher mühsam, stelle ich mir vor, das würde ich mir ersparen.
Es gibt doch inzwischen Apple und Windows Rechner in jeder Preisklasse für jeden Geschmack, gebraucht oder neu....
Was ist denn wirklich der Grund, warum Linux und Resolve ? Doch nicht wirklich wegen einem lächerlichem 40 € Windows Update...
Gruss Boris
Alles vor und rund herum um die Kamera ist für einen guten Film viel, viel wichtiger als die Kamera selber.
Also ich finde wenn schon, dann schon besser gleich zurück aufs richtige System...
Ich habe noch einen, aber freezer hat (zum Glück) empfohlen, die Kiste besser nicht einzuschalten, nicht vor einem grossen Service...;)
Gruss Boris
Alles vor und rund herum um die Kamera ist für einen guten Film viel, viel wichtiger als die Kamera selber.
Wenn ich mir das so anschaue - da bleib ich lieber bei Win.
Falls du es trotzdem probieren willst:
I have DaVinci Resolve Studio 16.0 up and running on CentOS 8.0 with the NVIDIA 430.50 driver for a single GTX 1080 Ti card.
For now, until ELRepo can get the NVIDIA driver packaged for CentOS 8, the NVIDIA driver can only be installed with the .run file, which is even more convoluted than previously, because CentOS 8 defaults to Wayland. Wayland must be disabled because NVIDIA doesn't yet have a driver compatible with Wayland.
N.B. using NVIDIA's .run file requires the use of a virtual console and perhaps even SSHing in from a different machine on your LAN at times. You should be comfortable with the CLI to attempt this.
I keep these notes hosted on GitHub, because software constantly changes. If and when ELRepo does package the NVIDIA driver for CentOS 8, I'll modify the instructions to take advantage of that, because that's much easier. Also, I had to temporarily remove my optional instructions for installing PostgreSQL on CentOS 8, just because I haven't yet done it, but I still have instructions available that should work for CentOS 7.7. When I do upgrade my PostgreSQL server from 7.7 to 8.0, I'll add instructions for how to do it back into my main document.
Create a bootable USB drive
On Windows:
Download DVD ISO
Verify the download
Download and use Rufus to create the bootable USB drive
On Mac or Linux:
Download DVD ISO
Verify the download
Use dd to create the bootable USB drive
UEFI settings
Set to boot to a USB drive first
Disable Secure Boot and disable Legacy BIOS mode
Install CentOS from USB
Software selection should be Workstation with only GNOME Applications checked.
Set up DHCP
Set password for root account and create just one administrator account
CentOS's installation interacts with HP's UEFI in such a way as to change the boot order, so reboot, and you'll boot to the M.2 SSD with the fresh installation
Reboot and you'll boot into the M.2 SSD with the fresh installation
Accept the CentOS license
You can then safely eject the USB installation disk
Install CentOS updates and reboot
Take note of the IP address on the LAN, because you might need to SSH into the machine later.
Install the kernel source:
$ sudo yum install "kernel-devel-uname-r == $(uname -r)"
Install EPEL
$ sudo yum install https://dl.fedoraproject.org/pub/epel/e ... noarch.rpm
Install DKMS
$ sudo yum install dkms
Prepare for the NVIDIA driver
Download the .run file for 430.50 from NVIDIA's site.
Become the root user:
$ su -
Make the file executable:
# chmod +x NVIDIA-Linux-x86_64-430.50.run
Blacklist the nouveau module:
# echo 'blacklist nouveau' >> /etc/modprobe.d/blacklist.conf
Install dependencies:
# dnf groupinstall "Workstation" "base-x" "Legacy X Window System Compatibility" "Development Tools"
# dnf install elfutils-libelf-devel "kernel-devel-uname-r == $(uname -r)"
Back up and rebuild your initramfs:
# mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img
# dracut -f
Change the default runlevel:
# systemctl set-default multi-user.target
Reboot the system:
# reboot
From the command-line, log into root, navigate to wherever you put the .run file, and then install the NVIDA driver:
# ./NVIDIA-Linux-x86_64-430.50.run
Be sure to install to DKMS
Test the new driver:
# systemctl isolate graphical.target
If the test is successful, correct your default runlevel:
# systemctl set-default graphical.target
Reboot:
# reboot
Confirm that you're running the NVIDIA driver at any time by running $ nvidia-smi
Download and install the latest DeckLink driver
Download the latest driver from the Blackmagic Design website
Become the root user:
$ su -
When prompted, enter your root user's password.
If you already have an older DeckLink driver installed, uninstall it:
# rpm -qa | grep desktopvideo | xargs rpm -e
If GNOME didn't uncompress it for you already, uncompress the downloaded driver package:
# tar xvfz /path/to/downloaded/driver/location/Blackmagic_Desktop_Video_Linux_<driver_version>.tar.gz
cd into the rpm folder, since this is CentOS
# cd /Blackmagic_Desktop_Video_Linux_<driver_version>/rpm/<yourarchitecture>
Install the latest Desktop Video driver, GUI, and Media Express. Type:
# rpm -ivh desktopvideo-<driver_version>.x86_64.rpm
# rpm -ivh desktopvideo-gui-<driver_version>.x86_64.rpm
# rpm -ivh mediaexpress-<version>.x86_64.rpm
The installer for Media Express might fail and tell you that you mediaexpress needs libGLU.so.1, so install libGLU and try again:
# dnf install mesa-libGLU
After the installation completes, you should see the terminal prompt. Reboot.
After the machine has rebooted, open a Terminal shell again
Become the root user again:
$ su -
When prompted, please enter your root user's password
You might need to update the firmware on your DeckLink card. Type:
# BlackmagicFirmwareUpdater update 0
If a firmware update was applied, reboot the machine after it completes. If no firmware update was required, a reboot is not necessary.
At this point, installing Desktop Video to DKMS will probably have "broken" the grub configuration again. If you try to log into the GUI, the screen will just go black. So we'll need to go rebuild the grub configuration again.
If you can get to a virtual console, log in. Otherwise, SSH into the root account from a different machine on the network.
vim into /etc/default/grub
For the GRUB_CMDLINE_LINUX line, remove rhgb and add rd.driver.blacklist=nouveau", so that the whole line is:
GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap quiet rd.driver.blacklist=nouveau"
Write and close: :wq
Rebuild the grub configuration again:
# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Reboot:
# reboot
Now we should be totally ready for DaVinci Resolve.
Install DaVinci Resolve
Download and extract DaVinci_Resolve_Studio_16.0_Linux.zip (if you have a DaVinci Resolve license dongle or key) or DaVinci_Resolve_16.0_Linux.zip from the Blackmagic Design website.
Double-click the .run file to use the GUI installer
Resolve might not launch after the installation--if you run it via the command-line from /opt/resolve/bin/, you can look for clues as to why it might not be able to launch. If some program is missing, try figuring out what Resolve needs and install via dnf.
Frank Glencairn hat geschrieben: ↑Sa 11 Jan, 2020 10:01
Falls du es trotzdem probieren willst: ...
das was du da heraushebst, sind wirklich nur die begleiterscheinungen dieser völlig unbrauchbaren CentOS images, die BMD immer wieder empfiehlt. die sind wirklich derart schlecht und ungenügend zusammengebastelt, dass es fast schon eine kunst ist. ich bin zwar keinen gorßer van von 'richtigem' CentOS, aber selbst dieser distribution würde man wirklich unrecht tun, wenn man sie voreilig mit diesem BMD-müll gleichsetzt...
wie gesagt, unter debian sind die notwenigen nvidia-treiber mit einem einzigen apt-get/apt/aptitude befehl installiert oder auf den aktuellen stand gebracht -- obwohl es ja unfreie software ist, die in diesem umfeld sonst eher weniger kollektive unterstützung erfährt.
das einzige, was man u.u. zusätzlich noch beachten muss, ist der umstand, dass die debian nvidia-treiber im gegensatz zur herstellerseitigen auslieferung in mehrer teile aufgespalten sind, damit man nicht immer alles installieren muss. im falle von resolve ist dem zusammenhang datauf zu achten, dass eben auch die nvidia-opencl-unterstützung mitinstalliert wird.
im grunde ließe sich aber natürlich auch diese praktische abhängikeit ganz einfach mit einem entsprechenden vermerk im .deb-packer völlig automatisiert und ohne langes rätseln und stöbern in fehlerberichten in formen recht benutzerfreundlich auf debian/ubuntu/mint systemen abwickelen. und da diese distributionen in der praxis mit großem abstand von den meisten realen anwendern genutzt werden, wäre damit schon sehr viel erreicht.
motiongroup hat geschrieben:...es muss nicht resolve sein, ein lwks14,5 tut's sehr sehr gut...
lightworks halte ich leider wirklich für eine derart veraltete und hoffnungslose software, dass ich es wirklich niemandem ernsthaft empfehlen würde. ganz ähnlich denke ich übrigens auch über cinelerra.
ich sehe zwar durchaus die paar vorzüge, die lwks auf grund seiner hohen spezialisierung und nähe zur analogen filmproduktion noch immer in sich trägt. trotzdem wiegt das die realen nachteile und probleme in keiner weise auf.
wenn man sich davon etwas abschauen kann, dann wohl eher in der hinsicht, dass man fürs eigentliche schneiden eben oft wirklich mit einfachen leichtegwichtigen und zuverlässigen sdimplen programmen besser bedient ist als mit irgendwelchen ganz komplexen geschichten, die eigentlich ursprünglich eher fürs color graden, video FX od. compositing gedacht waren.
lange zeit war das mit freien mitteln nur sehr bedingt möglich, weil die unterstützung für den austausch von schnittlisten bzw. projektfiles gefehlt hat od. unzumutbar schlecht abgedeckt war. dank OpenTimelineIO ändert sich das aber gerade ganz einschneidend, und man kann plötzlich durchaus auch relativ einfache freie tools in konventionelleren workflows vernünftig nutzen.
überhaupt habe ich im lauf der jahre immer wieder die erfahrung gemacht, dass es zwar oft sehr lang dauert, bis auch im umfeld der freien software wirklich guter ersatz für die paar aufgaben geschaffen wird, wo man noch immer von windows-lösungen abhängig ist. aber wann immer das dann tatsächlich in angriff genommen wurde, sind regelmäßig lösungen herausgekommen, die alles, was vorher genutzt wurde, völlig in den schatten stellen.
derartiges hab ich ganz praktisch bspw. mit vmware->kvm od. auch bitbucket->git und ein paar ähnlichen fällen im lauf der zeit immer wieder miterlebt.
ich bin daher noch immer ziemlich zuversichtlich, dass ähnliches früher od. später auch leistungsfähigere frei videobearbeitungstools betreffen wird. Natron war ja meines erachtens nach ohnehin bereits ein recht ermutigened signal, das zumindest aufgezeigt hat, dass dass das prinzipiell möglich ist.
Ich versteh das schon, und gebe dir auch teilweise Recht.
Das Problem der meisten Leute hier ist aber, daß sie eben keine IT-Cracks sind - der OT traut sich ja nicht mal zu einen einfachen Rechner zusammen zu stecken - und mit allem was mehr oder weniger über das Anklicken einer exe hinaus geht überfordert sind (ich inklusive).
Ehrlich gesagt hab ich auch wenig Appetit mich in irgendwelche comand line Sachen reinzufuxen, das ist einfach nicht meine Welt, und ich schätze mal so geht's vielen.
mash_gh4 hat geschrieben: ↑Fr 10 Jan, 2020 21:57
wenn es also wirklich nur um resolve geht, würde ich dir vermutlich eher zu windows raten.
... schade ;-)
mash_gh4 hat geschrieben: ↑Fr 10 Jan, 2020 21:57
ich persönlich arbeite seit jahrzehnten praktisch durchgängig nur mehr mit linux und komm damit ganz gut über die runden...
;-) mit welcher distribution? ich würde ja gerne mit (x)ubuntu ...;
prime hat geschrieben: ↑Fr 10 Jan, 2020 22:23
Und das sag ich mit multiplen Debian (alles andere wäre doch eh Quatsch) Systemen im Einsatz seit mehr als 10 Jahren.
Darth Schneider hat geschrieben: ↑Sa 11 Jan, 2020 07:25
Was ist denn wirklich der Grund, warum Linux und Resolve ? Doch nicht wirklich wegen einem lächerlichem 40 € Windows Update...
Gruss Boris
Danke Darth Schneider. Ich wollte eigentlich schon immer mal "weg von Windows". Irgendwie "aus Prinzip". Bei jedem neuen Rechner habe ich dann aber doch "mit Windows" gemacht. Die 40EUR sind es nicht. Eher das Interesse, ob es ohne Windows geht. Bei einem leistungsstarken Rechner würde ich dann für eine speziellen VBA(Excel)-Anwedung das mit Wine laufen lassen vermutlich.
Aber ich wolle jetzt nicht "Stunden" und vielleicht fortlaufend mich mit Linux-Bugs beschäftigen. Deshalb die Frage nach Erfahrungen hier. Auch zögere ich, mich mit CentOS zu beschäftigen, kenne die Konsolenbefehle nicht, kenne das Paketmanagement nicht etc.pp.. Und wenn mans nicht kennt, weiß man nicht, ob nicht plötzlich doch irgendwo unerwartete Überraschungen lauern ;-).
Frank Glencairn hat geschrieben: ↑Sa 11 Jan, 2020 13:08
Ehrlich gesagt hab ich auch wenig Appetit mich in irgendwelche comand line Sachen reinzufuxen, das ist einfach nicht meine Welt, und ich schätze mal so geht's vielen.
Frank Glencairn hat geschrieben: ↑Sa 11 Jan, 2020 13:08
Ich versteh das schon, und gebe dir auch teilweise Recht.
ich versteh deinen ansatz auch sehr gut und will deshalb auch niemanden mehr zur irgendeiner wahren lehre bekehren...
allerdings hab ich das gefühl, dass man in wahrheit ganz genau gleich viel wissen, erfahrung und tricks auch im windows und mac lager benötigt, um sein system tatsächlich souverän zu beherrschen bzw. an seine spezifischen erfordernisse anzupassen. ich wirklichkeit ist das also gar nicht so wesentlich anders als im linux umfeld. der unterschied besteht eher in der art und weise, wie man mit problemen auf den jeweiligen platformen umgeht -- und gerade da ist halt mir persönlich diese variante lieber, bei der man den fehlern tatsächlich rationell auf den grund gehen kann bzw. gemeinsam mit gleichgesinnten immer wieder einmaöl faktische verbesserungen mitbewirken kann, statt auf gedeih und verderb der willkür irgendwelchen kommerziellen akteueren ausgeliefert zu sein.
da ich aber in der praxis auch ein paar ganz normalen endanwendern immer wieder helfe, linux für ihre privaten alltäglichen zwecke zu nutzen -- darunter ein paar wirklich herausfordernde kandidaten, wie meine eltern ;) --, habe ich es im laufe der zeit durchaus auch zu schätzen gelernt, dass linux bzw. unix eben aus dem umfeld der großrechner und professioneller wartungsmannschaften stammt bzw. eine vernünftiges rechte- und sicherheitskonzept mitbringt, das es gänzlich unbedarften endanwendern deutlich schwerer macht, dass system in ähnlich einfacher weise zu zerstören od. mit schädlingen aller art zu bevölkern, wie man das aus dem umfeld der verbreiteteren alternativen her kennt.
natürlich kann man sich auch mit den mächtigen werkzeugen im unix-umfeld ins eigene knie schießen, wenn man man damit genauso sorglos und ohne jedes benötigte hintergrundwissen herangeht, wie es ja die allmacht über den eingenen personal computer immer schon so verführerisch nahegelegt bzw. zu versprechen schien.
aber, wie gesagt, man muss das nicht unbedingt so handhaben. mit ein bisserl hilfe von erfahreneren kollegen bzw. lernwilligkeit und geduld, kann man das auch in deutlich befriedigender und arbeitsteiliger weise vorbildlicher hinbekommen.
Zuletzt geändert von mash_gh4 am Sa 11 Jan, 2020 13:40, insgesamt 1-mal geändert.
Frank Glencairn hat geschrieben: ↑Sa 11 Jan, 2020 13:37
Ja schaumermal - ich hab nen Laptop geschenkt bekommen auf den ich interessehalber mal ein Linux drauf ziehen will.
Ich werde dich dann wahrscheinlich mit Fragen löchern :D
Um mal ein bisschen mehr Praxisnähe in die Diskussion zu bringen:
Resolve unter Ubuntu/Debian ist überhaupt kein Problem - und hier spreche ich aus eigener, täglicher Erfahrung.
Seit der Version 16 unterstützt die Linux-Version von Resolve endlich auch die System-Soundkarte (statt bloß Audioausgabe per Decklink-Karte). Das, und die Tatsache, dass nach einem Windows-Update DisplayCal nicht mehr lief, war für mich der Grund, nach vielen Jahren auch mein Videoschnitt-System auf Linux umzustellen.
Für Ubuntu/Debian gibt es ein prima funktionierendes und an neue Resolve-Versionen laufend angepasstes Skript, dass die Resolve für Linux-Installationsdatei in ein Debian-/Ubuntu-Paket konvertiert: https://www.danieltufvesson.com/makeresolvedeb
Auf der letztjährigen IBC habe ich die beiden Hauptentwickler von Resolve auf das Fehlen eines offiziellen Debian- oder rpm-Pakets angesprochen, und sie verwiesen mich auf das obige Skript (das ich bereits kannte). Mit anderen Worten: Die Lösung ist den Entwicklern bekannt und auch in ihren Augen gut.
Debian-/Ubuntu-seitig muss man nur darauf achten, dass der nichtfreie Nvidia-Treiber einschliesslich der nvidia-opencl-Pakete installiert ist. Resolve verhält sich unter Linux genauso wie unter Windows, nur dass kein Export nach h264/h265 möglich ist. (Aber dafür bein ich auch unter Windows - wie viele hier - aus Qualitätsgründen immer den Weg Resolve -> DNxHR + Handbrake/ffmpeg DNxHR -> h264/h265 gegangen.)
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
cantsin hat geschrieben: ↑Sa 11 Jan, 2020 13:39
Debian-/Ubuntu-seitig muss man nur darauf achten, dass der nichtfreie Nvidia-Treiber einschliesslich der nvidia-opencl-Pakete installiert ist.
Vermutlich nicht bei einer SAPPHIRE Radeon RX 580 ...
cantsin hat geschrieben: ↑Sa 11 Jan, 2020 13:39
Resolve verhält sich unter Linux genauso wie unter Windows, nur dass kein Export nach h264/h265 möglich ist. (Aber dafür bein ich auch unter Windows - wie viele hier - aus Qualitätsgründen immer den Weg Resolve -> DNxHR + Handbrake/ffmpeg DNxHR -> h264/h265 gegangen.)
Weißt Du warum? Du exportierst dann von Resolve nach DNxHR (was ist "+ Handbrake"???) und dann mit ffmpeg nach h264 (hast Du da den Konsolenbefehl mit den entsprechenden Parametern oder nimmst Du Voreinstellungen von ffmpeg, falls es die gibt?) Wann nutzt du h264?
Frank Glencairn hat geschrieben: ↑Sa 11 Jan, 2020 13:37
Ja schaumermal - ich hab nen Laptop geschenkt bekommen auf den ich interessehalber mal ein Linux drauf ziehen will.
da resolve für linux praktisch nur nur mit nvida-karten od. sehr großen mühen und viel glück auch vereinzelt mit AMD hardware läuft -- jedenfalls im gegensatz zur mac- und windows-ausgabe sich leider nicht mit integrierter intel-grafik begnügt --, schaut es auf laptops diesbezüglich eher schlecht aus -- obwohl es natürlich keine technischen grund gibt, warum das so sein muss...
das sind leider genau diese probleme bzw. folgen einer völlig indiskutablen stiefmütterlichen behandlung dieses systems, die gerne übersehen werden bzw. über die man sich mit sprüchen wie: "Resolve verhält sich unter Linux genauso wie unter Windows" leichtfertig hinwegtäuscht. :(
ähnliches muss man leider auch bzgl. dieser, durchaus bewundernswert engagierten, bemühungen, benutzerfreundliche workarrounds für das debian/ubuntu/mint-repacking zu entwicklen, anmerken. auch dort gibt es einfach ganz grundsätzliche problem mit der art und weise, wie libraries bzw. pfade im system vorausgesetzt bzw. abgändert werden, die mit den debian standards einfach unvereinbar sind bzw. ungute beleiterscheinungen nach sich ziehen.
dem entwickler der betreffenden scripts ist das ohnehin völlig klar. es sind eher die völlig unkritischen nutzer bzw. lamers, denen dadurch verborgen bleibt, wie problematisch diese trotzige weigerung auf seiten von BMD tatsächlich ist, irgendwelche nachhaltigen verbesserungen bzw. die elementarsten kompatibilitätserfordernisse in die upstream packages zu übernehmen.
Zuletzt geändert von mash_gh4 am Sa 11 Jan, 2020 14:39, insgesamt 2-mal geändert.
Frank Glencairn hat geschrieben: ↑Sa 11 Jan, 2020 14:14
Ich hab nicht vor Resolve drauf laufen zu lassen. Nur normal Surfen, Netflixplayer, Mail, und als Backup Station am Set.
das geht natürlich völlig ohne probleme!
da braucht man dann auch keine Wine od. andere formen der virtualisiung anderer systeme, weil es für die meisten alltäglichen aufgaben mittlerweile ohnehin auch unter linux ganz passable anwendungen gibt.
wenn man was nicht mit LibreOffice unter linux in gleicher weise wie am mac od. windows öffnen oder bearbeiten kann, dann sollte man sich eher überlegen, ob man es nicht auch auf diesen anderen systemen grundsätzlich anders handhaben sollte? es erscheint mir einfach deutlich vernünftiger, derartige frei verfügbare software als kleinsten gemeinsamen nenner vorauszusetzten, die sich wirklich ohne große mühen auf jedem betriebsystem in der gerade aktuellsten version installieren lässt, statt unbedingt an irgendwelche proprietären od. kostenpflichtigen lösungen gebunden zu bleiben.
lightworks halte ich leider wirklich für eine derart veraltete und hoffnungslose software, dass ich es wirklich niemandem ernsthaft empfehlen würde. ganz ähnlich denke ich übrigens auch über cinelerra.
so unterschiedlich sind die Ansprüche an einen NLE, ich sehe es eher umgekehrt und mit cinelerra lässt sich das sch mal wegen der Verfügbarkeit auf allen Plattformen überhaupt nicht vergleichen zumal zumal die in der Sendelandschaften und bei Film recht gut vertreten sind.. https://www.editshare.com/
es ist ne infrastrukturfrage und witziger weise hatte ich mit lwks ab der 12 keine probleme und wenn einer rein unter linux resp ubuntu bspw arbeiten ein funktionierendes system.
Frank Glencairn hat geschrieben: ↑Sa 11 Jan, 2020 13:08
Ehrlich gesagt hab ich auch wenig Appetit mich in irgendwelche comand line Sachen reinzufuxen, das ist einfach nicht meine Welt, und ich schätze mal so geht's vielen.
ich verwende Resolve bereits seit Version 15.3 unter Linux, wohlgemerkt die debian bzw. ubuntu-Schiene. Sowohl mit Mint 18.x als auch dem aktuellen 19.x ist das kein Problem.
Einziger Schritt, um die Sache etwas sauberer und stabiler installieren zu können, ist das "umpacken" der originalen Linux-Version von BMD in ein .deb-Paket. Dafür gibt es immer frische Versionen von "makeresolvedeb", einem Programm, das nichts anderes tut, als ein passendes .deb-Paket zu bauen. Das kann dann recht problemlos unter allen ubuntu-Derivaten und damit auch Mint installiert werden.
Ich kann bestätigen, dass mit NVidia-Karten und dem Herstellertreiber dann die Performance ganz beachtlich ist, teils sogar besser als unter einem parallelen Win 8.1 auf demselben Rechner.
Allerdings stimmt auch, was die Einschränkungen angeht - mit der freien Version sind die Möglichkeiten eingeschränkter als unter Windows, was die Import- und Exportformate angeht, kommt halt drauf an, was Du brauchst.
Ein Laptop sollte mehr oder weniger zwingend mindestens 4 Kerne und eine neuere NVidia mitbringen, wenn Du mehr als nur Full HD bearbeiten willst.
Aber - Du kannst natürlich sowohl die freien als auch die Pro-Versionen jederzeit mit BEIDEN Betriebssystem testen. Ein Linux-Test kostet Dich höchstens Zeit und ist mit ein wenig Anleitung auch für den Linux-Laien durchaus möglich.
Und das geht sogar fast ganz ohne die Konsole ;-)
Von den CentOS-Versionen würde ich auch eher abraten, für den Laien sind die jedenfalls eher wenig hilfreich.
roki100 hat geschrieben: ↑Sa 11 Jan, 2020 15:04
Warum nich pacman bzw. archlinux? Rolling Release und dennoch benutzerfreundlich, schnell usw. ;)
grundsätzlich spricht natürlich nichts gegen Arch -- ist sicher ein tolles system, mit einer bemerkenswert lebendigen benutzercommunity und guten dokus. auch NixOS und clear linux haben unbestrittenermaßen ihre vorzüge. ich denke trotzdem, dass sich die meisten einsteiger mit den populärsten distros und der unmenge an dafür verfügbaren hilfestellungen vermutlich leichter tun dürften.
allerdings würde ich zumindest im falle von debian auch unbedingt zur "testing" ausgabe raten -- also auch rolling release mode fahren --, was ja dank der absolut ausgereiften paketverwaltung in der praxis ohnehin wunderbar funktioniert.
prime hat geschrieben: ↑Fr 10 Jan, 2020 22:23
Und das sag ich mit multiplen Debian (alles andere wäre doch eh Quatsch) Systemen im Einsatz seit mehr als 10 Jahren.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
