Auflösung von Bildern nicht mehr begrenzt | Image resolution no longer limited
Auflösung von Bildern nicht mehr begrenzt | Image resolution no longer limited
Bilder können jetzt ohne Einschränkung der Auflösung hochgeladen werden. Es verbleibt weiterhin die Beschränkung auf 10MiB pro Bild.
Images can now be uploaded without restrictions on image resolution. The limit of 10MiB per image remains.
You're viewing a single thread.
Was für Begrenzungen gibt es für Video, außer 900 Frames? In Lemmy-Quellcode sehe ich manche (ziemlich hohe) Defaultwerte, aber wie ist es mit Codecs? Ich bekomme immer Fehler
ffmpeg timed outmit Videos über ca. 800 kiB.Das entspricht z. B. dreiste Qualität 22 Sekunden 360p-Video mit H265:
Also für nichts außer Reaktion-GIFs, schätze ich.
Edit: Das Video ist ins WebM ohne Ton verenkodiert geworden, hier ist MediaInfo:
General Complete name : https://feddit.org/pictrs/image/6d221a38-8b01-45a8-b152-ba4f27839d9d.webm Format : WebM Format version : Version 2 File size : 1.25 MiB Duration : 21 s 0 ms Overall bit rate : 498 kb/s Frame rate : 25.000 FPS Writing application : Lavf60.16.100 Writing library : Lavf60.16.100 Video ID : 1 Format : VP9 Format profile : 0 Codec ID : V_VP9 Duration : 21 s 0 ms Bit rate : 471 kb/s Width : 480 pixels Height : 360 pixels Display aspect ratio : 4:3 Frame rate mode : Constant Frame rate : 25.000 FPS Chroma subsampling : 4:2:0 Bit depth : 8 bits Bits/(Pixel*Frame) : 0.109 Stream size : 1.18 MiB (95%) Writing library : Lavc60.31.102 libvpx-vp9 Default : Yes Forced : No Color range : LimitedOhne Enkodierung (und deswegen Timeout) mit über 1 MB geht es, wenn man diese Eigenschaften imitiert (4 Minuten, 1080p immer aber nur 899 Frames):
In der Quellcode sehe ich nichts, was Audio verbieten würde, man könnte die Defaultwerte aber geändert haben
Man kann Videos hochladen?
Ja, Tonspur wird aber entfernt und Video ins VP9 (WebM) enkodiert, was verwendet CPU-Zeit und nach ca. 10 s wird der Prozess storniert ("ffmpeg times out"). In diesen Zeit schafft der Prozessor nur etwa 800 kiB Video bearbeiten. Die ganze 10 MiB zu verwenden, muss man also das Video ins VP9 selber kodieren, dem Server Mühe zu sparen. Wenn es nicht um hohe Auflösung handelt, wird man aber früher mit 900 Frames (bis zu 37,5 s mit fließendem Bewegung) begrenzt.
Und für Kommentare und Pfosten kann man natürlich Video/Bilder von außen embedieren (Syntax
), sofern es sich um direkten Link zur Datei handelt. Hier ist eins von Pixelfed, da ist Ton erlaubt, 15 MiB und keine Frameanzahlbegrenzung:Oder ganzer Panzerkreuzer Potemkin von Wikimedia:
Oder
Manche Clients spielen aber solche Videos nicht automatisch und wiederholt im Vergleich zu den oberen. Wie geht es bei deinem?
Ich lade oft Videos auf Pixelfed hoch aber immer nur den Link zum Post.
Ich finde es schade das Videos so stiefmütterlich behandelt werden, würde da gerne mehr posten und sehen.
tritt das Problem immer noch auf?
wenn ja schreib bitte mal wann du das versucht hast, und wenn möglich auch die ursprüngliche Datei zum reproduzieren z.b. auf https://litterbox.catbox.moe/ (min. 12h auswählen)
Ja, ist etwas geändert geworden?
Genau nun habe ich frühere unerfolgreiche Encodes von mir wieder hochzuladen probiert, und sie sind wieder fehlgeschlagen.
Beispiele:
- Über 10 MiB: AGhalf_toolarge_H264.mp4
too large(wie erwartet, die Grenze 10 MiB finde ich sinvoll)
- 901 Frames: AG_901frames_H265.mp4
too many frames(die Begrenzung ist meiner Meinung nach zu niedrig)
- Größer als cca. 800 kiB und nicht WebM: AGshort_timeout_H265_480.mp4
ffmpeg timed out(ich weiß, man soll den intensiven Prozess nicht lang laufen lassen, aber warum müssen übliche Codecs wie H264 und H265 mit viel Mühe verenkodiert werden? Im Quellcode sind verschiedene Codecs genannt)
- H264 kleiner als cca. 800 kiB: AGshort_erfolg_H264_360p_starkkomprimiert.mp4
- zufällig (von Belastung abhängig?) entweder
ffmpeg timed outoder erfolgreich enkodiert
- zufällig (von Belastung abhängig?) entweder
- VP9-WebM mit 899 Frames und Opus Tonspur: AG_success_VP9+opus.webm
- Erfolg
- Tonspur wird aber entfernt (im Quellcode sehe ich aber Audiocodecs erwähnt, ist hier Ton explizit verboten?)
- Genau das oben (VP9 mit 899 Frames und Opus Tonspur) aber in MP4-Container: AG_oserror2_VP9+opus.mp4
No such file or directory (os error 2)???
- AV1-MP4 mit AAC Tonspur: AG_timeout_AV1.mp4 oder AV1-WebM ohne Tonspur: AG_timeout_AV1.webm
- beide
ffmpeg timed out(in Quellcode sehe ich aber, AV1 sollte vielleicht nicht enkodiert sein...?)
- beide
danke, gucke ich mir nachher mal an.
die limits die wir für videos hatten wurden auch entfernt, aber evtl sind da noch standardwerte die da stören.
Okay, ich glaube nichts ist mit dem Server schiefgegangen, es gibt nur Configwerte, Änderung denen du wiegen sollst (z. B.
max_frame_count = 9000, statt Standardwert 900, was gelten wird, wenn nicht anders spezifiziert, oderenable_audio=true). Ich weiß nicht, ob diverse Codecs (durch etwas wievideo_codec = "vp9, h264, h265, av1") erlaubt sind.Außer CLI-Parameter gibt es Environment-Varibles, die in diesem Dokument beschrieben werden, pass aber auch auf Namenänderungen in manche neuere Versionen.
ich habe den frame count jetzt erst mal auf 3600 erhöht und audio aktiviert.
die timeouts müssen wir uns die tage mal in ruhe angucken.
bei dem video mit os error scheint der header nicht ganz zu stimmen, da fällt sowas raus.
[matroska,webm @ 0x7f996a31a600] 0x00 at pos 0 (0x0) invalid as first byte of an EBML number [matroska,webm @ 0x7f996a31a600] EBML header parsing failed [in#0 @ 0x7f996a4108c0] Error opening input: Invalid data found when processing input Error opening input file /tmp/pict-rs/.../.... Error opening input files: Invalid data found when processing inputDie Timeouts sind wegen Konversion ins VP9-Codec, die CPU-intensiv ist und Dauer ist von viele Faktoren abhängig. Zum Beispiel Videokodierung H265→VP9 dauert cca 4 s pro 100 kiB Eingabedatei, Timeout passiert nach 30 s (da ist der Prozess storniert mit
ffmpeg timed out). Es macht Sinn, dass es ein kurzer Timeoutzeit gibt, oder könnte man DoS-Angriffe einfach betrieben. Mit diverse erlaubte Codecs würde Konversion nicht nützlich - ich weiß nicht, ob daspict-rsunterstützt, dafür verstehe ich den Quellcode nicht genug.Danke.
Die Timeouts sind wegen Konversion ins VP9-Codec, die CPU-intensiv ist und Dauer ist auf viele Faktoren abhängig. Wenn Videokodierung H264→VP9 dauert cca 4 s pro 100 kiB Eingabedatei, Timeout passiert nach 30 s (da ist der Prozess storniert mit
ffmpeg timed out). Es macht Sinn, dass es ein kurzer Timeoutzeit gibt, oder könnte man DoS-Angriffe einfach betrieben. Mit diverse erlaubte Codecs würde Konversion nicht nützlich - ich weiß nicht, ob daspict-rsunterstützt, dafür verstehe ich den Quellcode nicht genug.ich glaube ich sehe doppelt
Entschuldigung, die Nachricht ist (wegen WLAN-Ausfall?) nicht aus Konzepte im App gelöscht geworden, nach sie gesendet war, also habe ich gedacht, sie ist noch zu senden.
- Über 10 MiB: AGhalf_toolarge_H264.mp4
das würde mich auch sehr interessieren.
