Bearbeiten via Win auf NAS - Datei nicht direkt zu starten und nicht zu speicher

[lemmi]

Hi, ich habe mich mal wieder an Windows ran gewagt.
(Benötige einige Programme dort, ergo Win und Linux(ist noch nicht fertig eingerichtet))
Ich zeichne via Youtv etliche Filme auf.
Speichere sie ab und befreie sie dann auf NAS sobald ich Zeit habe, von Werbung oder Vor und Nachgang.
Also nix dolles.

Problem:
1. Klick per Explorer Netz NAS Verzeichnis und öffnen mit AVI Demux gelingt nicht.
(Hinweis, Datei kann nicht geöffnet werden)
Ist nicht weiter schlimm, kann mich mit geöffnetem AVIDemux hin navigieren. Dann geht es seltsamer weise.
2. Speichern auf NAS schlägt fehl.
Fehlermeldung:(Keine Daten zum Muxen oder keine Ausgabedatei)
- auf interne Platte null Problem. Super schnell.
- Schreiben ansonsten auf NAS ohne Probleme. Hin kopieren, ohne Probleme.
- (Synology NAS) Gemeinsamer Ordner, alle Rechte vorhanden.

Und nun?

Hardware:

Ryzen 7 3700x
32 GB Ram
Interne M2 1TB
Nvidia Gforce GTX 970 4GB

Nicht übertaktet.
Windows frisch eingerichtet, zuerst Zugriffsfehler auf meine NAS. Beseitigt durch "Aktivierung  Unterstützung für SMB 1.0/CIFS-Dateifreigabe"
Danach voller Zugriff und Sichtbarkeit. (sind 3 NAS im Netz)



Ich muss dazu sagen, ich bin reiner Anwender und Nutzer, ergo keine große Erwartungen hinsichtlich Vorkenntnissen.

Wäre klasse, wenn hier jemand helfen könnte. Hatte mich schon gefreut, endlich mit neuer Hardware ein wenig schneller das Ganze zu bearbeiten.

[eumagga0x2a]

Zu Punkt 2: Es ist schon der dritte Thread darüber. Vermutlich hat der FFmpeg-Patch, der die Optimierung von MP4 fürs Streamen (das Verschieben des Index vom Ende der Datei zum Anfang) gefixt hat, die FFmpeg-interne Verarbeitung von UNC-Pfaden gestört, weswegen das Speichern auf Netzwerklaufwerke durch Muxer, die auf libavformat aufbauen wie MKV, MP4, WebM, MPEG-TS und MPEG-PS nicht mehr funktioniert.

Die Arbeit daran wird aufgenommen, sobald ich Zeit habe, mir ein NAS einzurichten, oder wenn jemand einen Patch schickt.

Zum Öffnen mit Avidemux aus dem Windows Explorer heraus: betrifft es wiederum nur Netzlaufwerke?

[lemmi]

Hallo, nett, dass du dich darum kümmerst.

Also:
Öffnen und schreiben auf interne Laufwerke super. Keine Probleme.
Öffnen direkt auf Netzlaufwerk via ausgesuchter App, geht nicht.
ABER...
Öffne ich zuerst Avidemux und hangel mich zum Netzlaufwerk, kann ich die Datei problemlos öffnen.
Aber
jedwedes Schreiben direkt auf Netzlaufwerk, nicht möglich. (Also zurückschreiben der gemuxten Datei)
Dabei habe ich drei NAS, auf die ich direkt schreiben kann. Also volle Rechte habe.
Erstellen und kopieren einer Datei auf den NAS problemlos.

Dennoch, eine gemuxte Datei direkt dorthin zu schreiben, geht nicht. (siehe Fehler)
Ich hatte zuerst vermutet, es liegt irgendwie an den Rechten der NAS; kann aber nicht sein, da ich ja mit allen anderen Programmen dorthin schreiben kann.
(Also auch OpenOffice, dort öffnen und zurück schreiben)

Bleibt also nur AVIDemux direkt.

(ich hoffe, ich habe das einigermaßen verständlich gemacht)

Nachtrag: ich habe noch überlegt, ob ich ggf. die Einstellungen von AVI ändern müsste.
Die Hardwareconfig ist ja oben, wie wäre denn die optimale Einstellung unter voller Ausnutzung der Hardware?
Fehlt vielleicht ein Code? (Win ist ja neu aufgelegt und ich habe bewusst noch keine universalcodec rein gepackt)

Ich werde vermutlich noch heute Mint Cinnamon weiter einrichten, sodass ich auf von dort auf die NAS direkt zugreifen kann und ebenfalls AVIDemux installieren.
Bin gespannt, ob das funktioniert.

[eumagga0x2a]

Die Frage war ob "Öffnen mit..." im Fall von Avidemux klappt bei einem lokalen Video und versagt bei einem auf einem NAS abgelegten Video. Ich würde erwarten, dass beide fehlschlagen oder beide funktionieren.

Die anderen Aspekte waren schon aus dem ersten Posting hier klar und schon vorher bekannt.

Der Patch, der im Verdacht steht, die interne Handhabung von UNC-Pfaden in den mitgelieferten FFmpeg-Bibliotheken gestört zu haben, hat keinen Einfluss (sollte keinen Einfluss haben) auf das Öffnen von Dateien, nur auf das Muxen mit FFmpeg-basierten Muxern (also nicht mit dem AVI-Muxer).

[eumagga0x2a]

Nachtrag: ich habe noch überlegt, ob ich ggf. die Einstellungen von AVI ändern müsste.
Die Hardwareconfig ist ja oben, wie wäre denn die optimale Einstellung unter voller Ausnutzung der Hardware?

DXVA2-Display + Video-Dekodierung in Hardware in den Einstellungen von Avidemux aktivieren, das ist alles.

Fehlt vielleicht ein Code? (Win ist ja neu aufgelegt und ich habe bewusst noch keine universalcodec rein gepackt)

Die einzigen externen Programme, die Avidemux nutzen könnte, sind VapourSynth und sein Vorgänger AviSynth für die, die VapourSynth- oder AviSynth-Filter und Scripte über Avidemux aufrufen möchten. Sie dienen nur als Input für Avidemux und haben mit der Ausgabe / mit den Muxern nichts zu tun.

Ich werde vermutlich noch heute Mint Cinnamon weiter einrichten, sodass ich auf von dort auf die NAS direkt zugreifen kann und ebenfalls AVIDemux installieren.
Bin gespannt, ob das funktioniert.

Hängt vermutlich davon ab, über welches Backend NAS eingebunden ist (gvfs oder über cifs / fstab).

[eumagga0x2a]

Ich werde vermutlich noch heute Mint Cinnamon weiter einrichten, sodass ich auf von dort auf die NAS direkt zugreifen kann und ebenfalls AVIDemux installieren.
Bin gespannt, ob das funktioniert.

Hängt vermutlich davon ab, über welches Backend NAS eingebunden ist (gvfs oder über cifs / fstab).

Mit gvfs erzeugt das Speichern als MP4 auf einer Samba-Freigabe eine kaputte Datei, wenn Streaming-Optimierung nicht deaktiviert ist. Speichern als MKV funktioniert ohne Einschränkungen.

Werde mir das Problem demnächst näher anschauen.

[lemmi]

Hallo,
ich habe derweil Cinnamon voll installiert und löppt.
AVIDemux als Appimage.
ABER
Hängt es damit zusammen, dass ich beim schneiden einer aufgenommenen HD Sendung und entsprechender Ausgabe als Matroska eine Binäre (so zeigt nemo es an) Datei erhalte?

Oder wieder was falsch eingestellt?

[eumagga0x2a]

Ein MKV Container ist immer eine binäre Datei. Nautilus / Nemo verlässt sich auf Dateiendungen. Fehlt ".mkv" am Ende des Dateinamens?

[lemmi]

Hallo, ich dachte zuerst ich habe mich verschaut, daher kurz eine Testdatei erstellt.

Also.
direkt auf der NAS unter Eigenschaften ist zu lesen "Binär (application/octet-stream)" OHNE mkv.
Gleiche Datei wieder auf eigenen Rechner kopiert ist es : "Video (application/x-matroska)" ohne mkv suffix.
Detailiert Dateityp: Matroska Datenstrom

Hängt es damit zusammen, dass die Ursprungsdatei eine HD Aufnahme ist? Ausgabe hatte ich mkv eingestellt. (muss ich das ändern um hd beizubehalten?)

[eumagga0x2a]

.mkv als Dateiendung anhängen, fertig.

[lemmi]

Ok, danke. Abspeichern direkt auf eigenen Rechner läuft jedoch mit mkv Suffix

[eumagga0x2a]

IMHO unwichtig, werde mir später die automatische Ergänzung der Dateiendung beim Speichern auf smb shares aber ansehen.

[lemmi]

merci

Mein Dank wird dir ewig nachschleichen. Achte auf die Schatten im Dunklen ;-)

[eumagga0x2a]

Ich konnte mit einem aktuellen Build vom git master keinen Unterschied beim automatischen Vorschlag des Dateinamens (wird mit der .mkv als Dateiendung vorgeschlagen) beim Speichern unter Linux auf eine lokale Festplatte und auf NAS feststellen, kurz: WFM.

Ich werde vermutlich noch heute Mint Cinnamon weiter einrichten, sodass ich auf von dort auf die NAS direkt zugreifen kann und ebenfalls AVIDemux installieren.
Bin gespannt, ob das funktioniert.

Hängt vermutlich davon ab, über welches Backend NAS eingebunden ist (gvfs oder über cifs / fstab).

Mit gvfs erzeugt das Speichern als MP4 auf einer Samba-Freigabe eine kaputte Datei, wenn Streaming-Optimierung nicht deaktiviert ist.

Funktioniert einwandfrei, wenn die Freigabe über CIFS gemountet ist. Muss wohl ein Bug in gvfs oder in den von gvfs verwendeten Libraries sein.

[lemmi]

Hi danke für deine Hilfe.
Unter Windows lässt sich dennnoch eine Datei nicht direkt öffnen.
Auch aufrufen des Pfades funktioniert nicht. Andere Programme wie vlc öffnen ohne Probleme.
Keine Ahnung, warum. Ist nicht schlimm, kann ja via Linux arbeiten und auf Suffix achten.