Gesplittete DVB-Aufnahmen mit ffmpeg reparieren

Caramon2

Lieutenant
Registriert
Jan. 2004
Beiträge
723
Uridium schrieb:
Ich habe SmartCut einmal verwendet, das hat funktioniert (h264).

TS würde ich vorher manuell mit ffmpeg in PS umwandeln/joinen. Wahrscheinlich geht es dann auch besser in LC.
Code:
$ ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -map 0 -c copy output.mkv
'-map 0' kopiert alle Streams, davon unterstützt MKV deutlich mehr. MP4 kann man aber auch versuchen, wenn man unbedingt will.
Das funktioniert nicht.

Diese Nacht hatte ich eine länger SD-DVB-Aufnahme:

DVB.png

Um das zusammenzukopieren hatte ich mir ein kleine Skript geschrieben, das "pv" nutzt, damit ich eine Fortschrittsanzeige bekomme.

Hier inkl. Ausführung (zur Sicherung bevor ffmpeg es durch Fehlbedienung vielleicht löscht/überschreibt):
Bash:
$ cat ~/.local/bin/tscp
#!/bin/bash
if [ $# == 0 ];then echo "tspc Zielname in '/tmph/'";exit;fi
pv *.ts > "/tmph/$1.ts"

$ tscp DVB
8,71GiB 0:00:25 [ 350MiB/s] [====================================================>] 100%

Dann mit ffmpeg und nur der ersten Datei, da mir dein "concat:intermediate1.ts|intermediate2.ts" nichts sagt und es "concat" in der ffmpeg-Manpage *) nicht gibt:
*) die ist grauenhaft: da blicke ich überhaupt nicht durch
Bash:
$ ffmpeg -i 000.ts -map 0 -c copy /tmph/output.mkv
ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13.2.1 (GCC) 20230801
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
  libavutil      58. 29.100 / 58. 29.100
  libavcodec     60. 31.102 / 60. 31.102
  libavformat    60. 16.100 / 60. 16.100
  libavdevice    60.  3.100 / 60.  3.100
  libavfilter     9. 12.100 /  9. 12.100
  libswscale      7.  5.100 /  7.  5.100
  libswresample   4. 12.100 /  4. 12.100
  libpostproc    57.  3.100 / 57.  3.100
[mp3float @ 0x566104213ec0] Header missing
[mpeg2video @ 0x566104214940] Invalid frame dimensions 0x0.
[mpegts @ 0x5661041e4580] start time for stream 0 is not set in estimate_timings_from_pts
[mpegts @ 0x5661041e4580] start time for stream 3 is not set in estimate_timings_from_pts
[mpegts @ 0x5661041e4580] start time for stream 7 is not set in estimate_timings_from_pts
[mpegts @ 0x5661041e4580] PES packet size mismatch
[mpegts @ 0x5661041e4580] Packet corrupt (stream = 1, dts = 1323486976).
[mpegts @ 0x5661041e4580] PES packet size mismatch
[mpegts @ 0x5661041e4580] Packet corrupt (stream = 4, dts = 1323485316).
[mpegts @ 0x5661041e4580] Could not find codec parameters for stream 2 (Unknown: none ([5][0][0][0] / 0x0005)): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[mpegts @ 0x5661041e4580] Could not find codec parameters for stream 6 (Unknown: none ([12][0][0][0] / 0x000C)): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, mpegts, from '000.ts':
  Duration: 02:11:55.75, start: 6790.264400, bitrate: 4139 kb/s
  Program 12003
    Metadata:
      service_name    : RTL Television
      service_provider: RTL Deutschland
  Program 12004
    Metadata:
      service_name    : RTL Regional NRW
      service_provider: RTL Deutschland
  Program 12005
    Metadata:
      service_name    : RTL HB NDS
      service_provider: RTL Deutschland
  Program 12006
    Metadata:
      service_name    : RTL Bayern
      service_provider: RTL Deutschland
  Program 12009
    Metadata:
      service_name    : RTL HH SH
      service_provider: RTL Deutschland
  Program 12020
    Metadata:
      service_name    : RTLZWEI
      service_provider: RTL Deutschland
  Program 12030
    Metadata:
      service_name    : TOGGO plus
      service_provider: RTL Deutschland
  Program 12040
    Metadata:
      service_name    : SUPER RTL
      service_provider: RTL Deutschland
  Program 12060
    Metadata:
      service_name    : VOX
      service_provider: RTL Deutschland
  Stream #0:1[0x47](deu): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006)
  Stream #0:2[0x48]: Unknown: none ([5][0][0][0] / 0x0005)
  Stream #0:3[0x4a](deu): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006) (hearing impaired)
  Stream #0:4[0x88](deu): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
  Stream #0:5[0xa7]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bt470bg, top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn
    Side data:
      cpb: bitrate max/min/avg: 15000000/0/0 buffer size: 1835008 vbv_delay: N/A
  Stream #0:6[0xfc]: Unknown: none ([12][0][0][0] / 0x000C)
  Stream #0:7[0xfd]: Data: bin_data ([6][0][0][0] / 0x0006)
  Program 12061
    Metadata:
      service_name    : NITRO
      service_provider: RTL Deutschland
  Program 12080
    Metadata:
      service_name    : RTLup
      service_provider: RTL Deutschland
  Program 12090
    Metadata:
      service_name    : ntv
      service_provider: RTL Deutschland
  Program 12091
    Metadata:
      service_name    : TOGGO Radio
      service_provider: RTL Deutschland
  No Program
  Stream #0:0[0x12]: Data: epg
[out#0/matroska @ 0x566104440440] Cannot map stream #0:2 - unsupported type.
[out#0/matroska @ 0x566104440440] If you want unsupported types ignored instead of failing, please use the -ignore_unknown option
If you want them copied, please use -copy_unknown
Error opening output file /tmph/output.mkv.
Error opening output files: Invalid argument
Es wird nicht mal eine leere Datei erstellt.

Das gleiche passiert, wenn ich es als .ts ausgeben lasse.

Ich möchte doch nur die Dateien der Aufnahme zu einer Datei zusammenkopiert und dabei alles außer dem Video- und dem ersten Audiostream entfernt haben.
 
Zuletzt bearbeitet: (Hinweis entfernt, da jetzt eigener Thread.)
$ ffmpeg -hide_banner -i "input.ts" -ignore_unknown -map v:0 -map a:0 -c copy output.mkv

Wenn Du es mit .ts Zieldatei versuchen willst, ändere 'output.mkv' nach 'output.ts'.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Caramon2
Uridium schrieb:
$ ffmpeg -hide_banner -i "input.ts" -ignore_unknown -map v:0 -map a:0 -c copy output.mkv
Auseinanderklamüser verstehe ich das so:

-hide_banner = schaltet nur die obige Zusammenfassung ab, hat aber keinen Einfluss auf das encoden/kopieren

-ignore_unknown = bezieht sich auf die anderen Streams wie EPG, Videotext und was da sonst noch so außer Audio und Video drin steckt

-map v:0 -map a:0 = Video+Audio und von beiden alle vorhandenen Spuren

-c copy = streamcopy

Ist das soweit richtig?

Uridium schrieb:
Wenn Du es mit .ts Zieldatei versuchen willst, ändere 'output.mkv' nach 'output.ts'.
Wie bei GIMP wird automatisch das zur Endung passende Ausgabeformat gewählt.

Funktioniert tut es jetzt (von den 3,8 GiB bleiben nur 2,8 GiB übrig = über 1/4 war unnötiger Kram!) und die Ausgabedatei lässt sich problemlos abspielen und mit AVIdemux öffnen.

Auch das mit "concat" um mehrere Dateien zusammenzukopieren funktioniert *) (statt 8,7 GiB sind es dann nur noch 6,3 GiB), aber damit habe ich beim Wechsel der 4 GB Datei wieder eine Störung, egal ob ich in .ts oder in .mkv kopieren lasse. Bei .mkv ist der Ton sogar leicht mehr "kaputt".

Allerdings ist die Stelle auch beim direkten zusammenkopieren mit pv (wie mit "copy /b" bei DOS) nicht ganz sauber, wie mir dabei aufgefallen ist.

Ich hänge die betreffenden Schnipsel und die ffmpeg-Ausgabe an. - Da das vermutlich am Satreceiver liegt (Xoro 8590), kann man wohl nichts machen.

Nachtrag: Der Upload blieb plötzlich hängen und CB hakte wie Sau. Also 2nd Try … Check! :)



) ist gegenüber ".ts" aber ziemlich umständlich, da man jede Datei einzelnen aufführen muss, aber die offenbar einzig Alternative ist noch viel umständlicher, da man dafür sogar erst noch eine spezielle formatierte Steuerdatei erstellen muss: ffmpeg-Dokumentation
 

Anhänge

  • ffmpeg.txt
    5,8 KB · Aufrufe: 25
  • ffmpeg-mkv.mp4
    200,5 KB
  • ffmpeg-ts.mp4
    201,8 KB
  • pv.mp4
    190,8 KB
Zuletzt bearbeitet: (Internetprobleme)
Offenbar sind die Dateien nicht hart geschnitten. Die überschüssigen Pakete (Header?) werden beim prozessieren auch bemängelt. Bevor wir schauen, ob man diese verwerfen kann, anstatt sie zu korrigieren (was passiert ist), probiere erst mal das (hier wird nicht blind zusammengeklebt):
$ ffmpeg -hide_banner -f concat -safe 0 -i <(for f in ./*.ts; do echo "file '$PWD/$f'"; done) -map v:0 -map a:0 -c copy output.mkv

Poste das auch mal:
$ xxd -c16 -s-4096 file1.ts
$ xxd -c16 -l4096 file2.ts
 
  • Gefällt mir
Reaktionen: Caramon2
Uridium schrieb:
$ ffmpeg -hide_banner -f concat -safe 0 -i <(for f in ./*.ts; do echo "file '$PWD/$f'"; done) -map v:0 -map a:0 -c copy output.mkv
Das mit der eingebunden Schleife gefällt mir! Das ist wesentlich eleganter, als die Beispiele bei der ffmpeg-Dokumenattion.

Danke. :)

Uridium schrieb:
Poste das auch mal:
$ xxd -c16 -s-4096 file1.ts
$ xxd -c16 -l4096 file2.ts
Das muss ich auf später verschieben, da ich momentan keine Aufnahme habe *). - Diese Nacht nehme ich "The Suicide Squad" auf. Das wird lang genug sein.

*) Da ich nicht dachte, dass man das vermeiden kann, es, habe ich sie gelöscht, nachdem ich es recodet hatte.
 
Nicht dass 4KB zu wenig sind. Lass uns auf 256KB hoch gehen.
$ xxd -c16 -s-262144 file1.ts |curl -F 'file=@-' 0x0.st
$ xxd -c16 -l262144 file2.ts |curl -F 'file=@-' 0x0.st

Wenn Du von der "Schnittstelle" noch mal so einen Videoschnipsel wie oben mit 'cp' oder 'pv' erstellen könntest, wäre das klasse. Anhand der Hexdumps werde ich die Stelle finden können.
 
Zuletzt bearbeitet:
Caramon2 schrieb:
Ich habe das testweise für die HD-Aufnahme gemacht (in file1+2 umbenannt), da ich die Manpage so verstenden habe, dass "-F 'file=@-'" das nach stdout ausgibt, aber stattdessen wurde das irgendwohin hochgeladen:
Bash:
$ xxd -c16 -s-262144 file1.ts |curl -F 'file=@-' 0x0.st
http://0x0.st/XPUO.txt
$ xxd -c16 -l262144 file2.ts |curl -F 'file=@-' 0x0.st
http://0x0.st/XPUV.txt
In erster Linie war das gedacht, damit ich das auch auf dem Handy sofort als Hex sehen kann. Unglücklicherweise sieht man nichts am Schnitt, bzw. nur random data. Erwartet hatte ich irgendeinen offensichtlichen Header, den man hätte abschneiden können.

Caramon2 schrieb:
Da ich insgesamt 4 Aufnahmen (SD+HD von beiden Receivern), also 8 Dateien habe und mir der xxd-Export zu ineffizient ist (über 4* so groß und starre Formatierung), habe ich mir überlegt, dass ich einfach Anfang und Ende jeder der 8 Dateien mit "dd" kopiere:

Dann hast du nicht nur die Unterbrechung, sondern kannst das auch mit dem regulären Aufnahmestart/-ende vergleichen und kannst es mit beliebigen Programmen analysieren.

Soll ich bei 256k/Teilstück bleiben, oder besser auf 1M (oder noch mehr) erhöhen?
Gute Idee. Circa 2 Sekunden pro Datei wären gut.
Hochladen kannst Du mit $ curl -F'file=@file01.ts' https://0x0.st. Die Datei ordentlich benennen kann man, indem man einfach einen neuen Namen via Slash hinten an die URL klebt, also z.B. http://0x0.st/XPUO.txt/HexDump01.txt.
 
Ich habe mir erst mal die Limits von 0x0.st angesehen:
Maximum file size: 512.0 MiB

File URLs are valid for at least 30 days and up to a year:

retention = min_age + (-max_age + min_age) * pow((file_size / max_size - 1), 3)

Not allowed: application/x-dosexec, application/x-executable, application/x-sharedlib, application/x-hdf5, application/java-archive, application/vnd.android.package-archive, application/x-rar, application/vnd.microsoft.portable-executable
Das wird dicke reichen, da nur ausführbares (und natürlich illegales) nicht erlaubt ist und wir hoffentlich kein ganzes Jahr dafür brauchen werden. :)

Ich habe einen Rundumschlag vor:

Von den 8 Dateien (zwei Receiver, je SD+HD und 2 Dateien) werde ich je Anfang und Ende "abschneiden". - Wobei "dd" nur nach Größe schneiden kann: Wie viel Spielzeit das dann ist, kann ich nur raten.

Außerdem werde ich alle 4 Aufnahmen auf die drei bisher ermittelten Arten zusammenkopieren (=12 Dateien), davon die Szenen mit der Unterbrechung per AVIdemux ausschneiden (da ich es damit ja auf sonst bearbeite) und als .ts (streamcopy) + x264-Vorbis-mkv (das ich immer nutze, da der Satreceiver damit am besten klar kommt) spreichern.

Das werde ich dann alles in ein 7z packen (vernünftig benannt) und dort hochladen.

Ach ja: Die jeweilige Befehlszeile und ffmpeg-Ausgabe der 12 Versuche packe ich natürlich auch noch mit dazu.

Ist das soweit OK?

Tipp:

Beim cc2 hat der Sohn vom Rudolph vor einiger Zeit den "wxHexEditor" genutzt und ich hatte ihn mir gleich installiert, da man sowas ja immer mal brauchen kann:

wxHexEditor.png
 
Mach erst mal nur zwei SD Fragmente (2x10MB, 10485760 Bytes), überprüfe den korrekten Schnitt via Hexeditor und benenne die Dateien mit dem Gerätenamen.

Wie werden die Dateien vom Gerät kopiert? Welches Format hat die HDD (fat32?) Auf dem Gerät selbst sind die Störungen beim Abspielen nicht?
Versuche mal die Filme via LAN zu kopieren/streamen (sofern die Geschwindigkeit passabel ist).
 
Zuletzt bearbeitet:
Die Receiver haben normale USB2-Ports und ich nehme auch ntfs-16k-formatierten SSDs auf, da ntfs damit am leistungsfähigsten ist und die Receiver keine vernünftigen Dateisysteme unterstützen. Also am PC kann ich die Aufnahmen einfach runter kopieren.

Beide Receiver zeigen bei der Wiedergabe keine Störungen. Einzig ganz früher beim 8500 und einem lahmen 16 GB Stick mit fat32-8k (ntfs-Unterstützung wurde bei dem erst später per neuer Firmware nachgerüstet) konnte es passieren, dass er sich "verschluckt" und die Wiedergabe abbrach: Mit fat32-64k passierte das beim selben Stick nicht mehr und später mit ntfs (egal welche Clustergröße) auch nicht.

Ich habe kein Festnetz. Mit dem PC gehe ich nur bei Bedarf per WLAN-Stick übers Handy online.

Grund: Ich hatte heute vor genau 20 Jahren um 17:02 Uhr (also gleich) einen schweren, unverschuldeten Verkehrsunfall und bin seit dem leicht behindert und arbeitslos. Festnetz habe ich schon 2010 gekündigt und dadurch nicht die 30€ gespart, sondern mein Stromverbrauch sank in Folge von 52€ auf 35€.

Du kannst dir ja mal ausrechnen, was ich unte Berücksichtigung von Inflation und steigenden Preisen inzwischen gespart habe: Das würde mir die Haare vom Kopf fressen.

Der aktuelle Zwischenstand:

Dieses habe ich ausprobiert:
Code:
cat *.ts > /tmph/cat.ts

ffmpeg -hide_banner -i "concat:000.ts|001.ts" -map v:0 -map a:0 -c copy /tmph/ffmpeg-concat.ts

ffmpeg -hide_banner -f concat -safe 0 -i <(for f in ./*.ts; do echo "file '$PWD/$f'"; done) -map v:0 -map a:0 -c copy /tmph/ffmpeg-demux.ts

cat *.ts | ffmpeg -hide_banner -i pipe: -map v:0 -map a:0 -c copy /tmph/ffmpeg-pipe.ts

Mit diesem Ergebnis:
Code:
5445827584 22. Mai 16:04 cat.ts
3651954520 22. Mai 16:01 ffmpeg-concat.ts
3651987420 22. Mai 15:57 ffmpeg-demux.ts
3651954520 22. Mai 16:02 ffmpeg-pipe.ts

Vor allem:
Code:
$ diff -s ffmpeg-concat.ts ffmpeg-pipe.ts 
Dateien ffmpeg-concat.ts und ffmpeg-pipe.ts sind identisch.

"concat" kann man also vergessen, da "pipe" viel einfacher umzusetzen ist.

"-ignore_unknown" braucht man übrigens nicht, wenn man mit "-map v:0 -map a:0" sowieso nur v+a kopiert.

Das andere muss ich mir erst noch in Ruhe ansehen.
 
Hat sich mit ffmpeg-demux.ts was geändert? Immer noch Störungen? Poste mal das FFmpeg Log.
 
Eine Störung an der Schnittstelle gab es immer und bei ffmpeg-demux war sie wieder etwas gravierender.

Ich habe dann trotzdem erst mal die anderen Aufnahmen getestet (nur mit der pipe-Methode) und wurde überrascht:

Beim alten Receiver (Xoro 8500 von 2010: meinen ersten HDTV-fähigen) gabe es keine Störung:

Weder bei HD noch SD, weder beim Abspielen, noch im AVIdemux und nicht mal, wenn ich im Player (MPV mit aktiviertem va-api Hardware-Decoding), oder in AVIdemux einzelbildweise rückwärts die Schnittstelle überquerte. Auch recoden lies es sich sauber.

Ich frage mich, was und wie ich das damals (noch unter XP - Linux nutze ich erst seit 2015) getestet habe, dass das nur mit VideoReDo sauber funktioniert hat…

Aber auch bei der HD-Aufnahme des 8590 gab es in MPV und AD unten nur ein paar kaputte Blöcke ca. 1/4 über dem unteren Rand (rückwärts dagegen in gleicher Höhe dieses typische grün-kaputte über die ganze Bildbreite) und wenn ich es mit AD recodet habe, war es vollkommen in Ordnung, auch rückwärts.

Um zu testen, ob das nur Zufall war, oder es bei anderen Sendern anders ist, habe ich über Nacht bei beiden Receivern weitere Testaufnahmen programmiert: Die laufen noch, da es bei SD, je nach Bandbreite des Senders, 2-3h dauert, bevor die 4 GB überschritten werden und ich etwas Auswahl haben möchte.

Protokoll usw. bekommst du, wenn ich weiß was überhaupt relevant ist.
 
Die letzten Testaufnahmen wurden heute morgen abgeschlossen, aber mit der Auswertung kann ich noch nicht beginnen, da es ab heute Nachmittag bis Abend immer wieder gewittern soll: Der PC bleibt aus und die Stecker (bis auf den Kühlschrank) habe ich schon gezogen.

Hier im Haus ist schon mal der Blitz eingeschlagen und im Jahr davor in einem Nachbarhaus, ca. 200 m Luftlinie entfernt.
 
Aktueller Zwischenstand:

Die Aufnahmedateien vom 8500 lassen sich ohne Störung zusammenkopieren, egal ob HD oder SD, oder von welchem Sender: Mit cat, ffmpeg-pipe und -concat (die liefern identische Ergebnisse), aber nicht mit ffmpeg-demux: Das verursacht an der übergangsstelle einen Haker und Tonaussetzer.

Auch beim 8590 produziert ffmpeg-demux die größte Störung und cat die geringste, wobei ffmpeg-pipe/concat deutlich näher an cat als an ffmpeg-demux liegt.

Außerdem hatte ich die Idee, zur Platzersparnis die jeweils 2. Datei auf 100 MiB zu kürzen *), da ja nur der Übergang 1. -> 2. interssiert, aber dann liefert ffmpeg-concat (die anderen habe ich noch nicht getestet) sofort eine zusätzliche Meldung, also schon bevor er anfängt zu kopieren. - Also sind die Teildateien, obwohl Transportstreams, trotzdem irgendwie in sich abgeschlossen. Ich bleibe also bei den vollständigen Originaldateien.

Das muss ich noch berücksichtigen, aber ich denke, dass ich das heute fertigstellen und hochladen kann.

Bis später. :)
 
Oh Mann, das artet ganz schön in Arbeit aus, da ich mir das alles erst mal vorbereiten muss: So viel Gehirnakrobatik (bei 26°C in der Dachwohnung) bin ich gar nicht mehr gewohnt…

Deshalb habe ich das erst mal nur für DMax gemacht: SD und nur eine Tonspur (mp2). Das dürfte mit das einfachste sein.

Mit beiden Receivern hatte ich das selbe aufgenommen, wobei es aber nicht identisch wurde, da beide Receiver mit unterschiedlichen Versatz die Aufnahme starten, die Teildateien unterschiedlich groß werden und die Aufnahme beim 8590 sogar etwas länger wird. - Der Vorteil: Der hat daraus sogar 3 Teildateien gemacht.

Die Aufnahme des 8500 ist dabei eher als Referenz gedacht, da sich das ja (bis auf ffmpeg-demux) nahtlos zusammenkopieren lässt. Nur bei den Aufnahmen des 8590 bekomme ich das nicht hin: Mit keiner jemals getesteten Software.

Der 8590 spielt seine eigenen Aufnahmen dagegen sauber ab (ich habe extra nochmal bei die entsprechenden Zeitpunkt genau kontrolliert).

Da es bei Streamcopy immer die gleichen Daten sind (nur unteschiedlich multiplext), ließ es sich sogar gut komprimieren:
Bash:
$ 7z t DVB-Test_1.7z

7-Zip 24.05 (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-05-14
 64-bit locale=de_DE.UTF-8 Threads:8 OPEN_MAX:1024, ASM

Scanning the drive for archives:
1 file, 34211323 bytes (33 MiB)

Testing archive: DVB-Test_1.7z
--
Path = DVB-Test_1.7z
Type = 7z
Physical Size = 34211323
Headers Size = 852
Method = LZMA:73m
Solid = +
Blocks = 1

Everything is Ok                         

Folders: 4
Files: 33
Size:       76327355
Compressed: 34211323

Aber das benennen hat nicht funktioniert:
Uridium schrieb:
Hochladen kannst Du mit $ curl -F'file=@file01.ts' https://0x0.st. Die Datei ordentlich benennen kann man, indem man einfach einen neuen Namen via Slash hinten an die URL klebt, also z.B. http://0x0.st/XPUO.txt/HexDump01.txt.
Auch auf deren Seite steht nicht mehr:
HTTP POST files here:
curl -F'file=@yourfile.png' https://0x0.st

It is possible to append your own file name to the URL:
https://0x0.st/aaa.jpg/image.jpeg

Was habe ich dabei falsch verstanden:
Bash:
$ curl -F'file=@DVB-Test_1.7z' http://0x0.st/DVB-Test.7z/DVB-Test_1.7z

<pre>Process 55 stopped
* thread #1: tid = 55, 0x00007efd6c113e90, name = 'fhost'
    frame #0:
Process 55 stopped
* thread #8: tid = 55, 0x00007efde6b5bc70 fhost`get(path='/DVB-Test.7z/DVB-Test_1.7z') + 27 at fhost.c:139, name = 'fhost/responder', stop reason = invalid address (fault address: 0x30)
    frame #0: {3:#018x} fhost`get(path='/DVB-Test.7z/DVB-Test_1.7z') + 27 at fhost.c:139
   136   get(SrvContext *ctx, const char *path)
   137   {
   138       StoredObj *obj = ctx->store->query(shurl_debase(path));
-> 139       switch (obj->type) {
   140           case ObjTypeFile:
   141               ctx->serve_file_id(obj->id);
   142               break;
Ist das dort jetzt noch als Dateileiche dort (es wurde lt. Traffficanzeige die gesamte Datei gesendet) und kann ich die irgendwie löschen?

Ohne Namen hat es funktioniert:
Bash:
$ curl -F'file=@DVB-Test_1.7z' https://0x0.st
https://0x0.st/XZ05.7z

Diese Beschreibung habe ich mit ins Archiv gepackt:
Die Verzeichnisnahmen enthalten die jeweilige Spielzeit, be der die Unterbrechung war: h-mm-ss

Ich kopiere ins RAM (/etc/fstab-Eintrag):

memory /tmph tmpfs huge=always,size=90% 0 0

Das führe ich bei jeder Aufnahme aus:

-----
ls *.ts -1s --block-size=k > /tmph/Dateigröße.txt

cat *.ts > /tmph/cat.ts

cat *.ts | ffmpeg -hide_banner -nostats -i pipe: -map v:0 -map a:0 -c copy /tmph/ffmpeg-pipe.ts 2> /tmph/ffmpeg-pipe.txt

ffmpeg -hide_banner -nostats -f concat -safe 0 -i <(for f in ./*.ts; do echo "file '$PWD/$f'"; done) -map v:0 -map a:0 -c copy /tmph/ffmpeg-demux.ts 2> /tmph/ffmpeg-demux.txt
-----

Dann kopiere ich mit dd die ersten und letzten ca. 4M (HD: 8M) der originalen Teilstücke, was je nach Sender auch ungefähr 5 Sek. entspricht:

---
dd if=1.ts of=/tmph/1a.ts bs=1M count=4
dd if=2.ts of=/tmph/2a.ts bs=1M count=4

# Beim Ende ist es etwas komplizierter (es bleibt identisch mit dem Ende der Originaldatei):
ls *.ts -1s --block-size=M
3890M 1.ts
3158M 2.ts

dd if=1.ts of=/tmph/1e.ts bs=1M skip=$((3890-4))
dd if=2.ts of=/tmph/2e.ts bs=1M skip=$((3158-4))
---

Anschließend kopiere ich den Punkt mit AVIdemux (streamcopy) und je ca. 5 Sek. Vor-/Nachlauf (ich muss mich ja an die I-Frames halten) in entsprechend benannte .ts

Da bei den Aufnahmen des 8590 dabei Fehler auftreten (s. Screenshots), recode ich es 1:1 (also ohne Skalierung und ggfs. Deinterlace) in ein x264-Vorbis-mkv - Wobei das aber auch zu Fehlern kommen kann!?

Hmm, beim recoden hatte ich das noch nie…

Auch mit anderen Konfigurationen funktioniert es nicht.

Ich hoffe, du kannst etwas damit anfangen.

Auf jeden Fall vielen Dank für deine Mühe. Das hat mich jetzt schon deutlich weitergebracht.
 
Den Dateinamen erst anhängen nachdem die Datei hochgeladen wurde. Geht also jederzeit. Löschen kann man, wenn man mit curl -v hochlädt. Dann bekommt man einen x-token.
 
Also zuerst hochladen:
Bash:
$ curl -F'file=@DVB-Test_1.7z' https://0x0.st
https://0x0.st/XZ05.7z

Und dann wieder mit curl umbenennen:
Bash:
curl -F'file=@DVB-Test_1.7z' https://0x0.st/[alter Name]/[neuer Name]"

"[alter Name]" wäre in dem Fall also "XZ05.7z" und [neuer Name] "DVB-Test_1.7z"?

Ist das wirklich richtig?

Das erscheint mit nicht gerade schlüssig und ich wüsste nicht, wie man aufgrund der minimalistischen Beschreibung auf deren Seite darauf kommen soll.

Kann man es dann unter beiden Namen laden?

Ausprobieren kann ich es nicht, da der PC aus ist und ich ihn nur dafür nicht extra wieder hochfahre.
 
Der 8500 Stream ist in Ordnung.
Der 8590 übernimmt beim Split Reste vom vorigen Buffer. Im Fragment 1e.ts sind die hinteren 47KiB mit den ersten 47KiB von 2a.ts identisch.
Code:
$ truncate -s-48128 1e.ts
$ cat *.ts | ffmpeg -hide_banner -i pipe: -map v:0 -map a:0 -c copy ffmpeg-pipe.ts

Man kann die überschüssigen Daten auch per ffmpeg verwerfen. Perfekt ist das aber offenbar nicht. Zumindest beim Ton ist noch was zu hören.
Code:
$ cat *.ts | ffmpeg -hide_banner -fflags +discardcorrupt -i pipe: -map v:0 -map a:0 -c copy ffmpeg-out.ts
 
  • Gefällt mir
Reaktionen: Caramon2
Uridium schrieb:
Viel einfacher... deine ursprüngliche URL lautet https://0x0.st/XZ05.7z.
Daraus macht man:
https://0x0.st/XZ05.7z/DVB-Test_1.7z
Also könnte das jeder umbenennen, der den (hier öffentlich geposteten) Link hat?

Oder auch löschen usw., also alles was auf https://0x0.st beschrieben ist? - Es gibt ja keine Legitimation, oder so.

Eine kleine Gedankenspielerei:

Jemand lädt sich das Archiv, baut Schadcode ein (z. B. in den Videos, die nicht gepatchte Sicherheitslücken von geläufigen Player nutzen), lädt es dort hoch, löscht meins und benennt seins so um, dass man es mit meinem Link bekommt.

Und ich bekomme dann den Ärger…

Ist das noch blauäugig, oder schon fahrlässig?

Also wichtig:

Wer das Archiv lädt, testet es als erstes und vergleicht die Daten mit meinen Ergebnis oben:
Bash:
Folders: 4
Files: 33
Size:       76327355
Compressed: 34211323
Alles muss identisch sein:

Anzahl und Größe könnte man zwar leicht beibehalten, aber das es trotz eingeschleusten Code auf Byte genau identisch komprimiert wird, dürfte ziemlich unwahrscheinlich sein.

Uridium schrieb:
Der 8500 Stream ist in Ordnung.
Der 8590 übernimmt beim Split Reste vom vorigen Buffer. Im Fragment 1e.ts sind die hinteren 47KiB mit den ersten 47KiB von 2a.ts identisch.
Code:
$ truncate -s-48128 1e.ts
$ cat *.ts | ffmpeg -hide_banner -i pipe: -map v:0 -map a:0 -c copy ffmpeg-pipe.ts

Man kann die überschüssigen Daten auch per ffmpeg verwerfen. Perfekt ist das aber offenbar nicht. Zumindest beim Ton ist noch was zu hören.
Code:
$ cat *.ts | ffmpeg -hide_banner -fflags +discardcorrupt -i pipe: -map v:0 -map a:0 -c copy ffmpeg-out.ts
Danke!

Ich werde noch mit den anderen Aufnahmen testen, ob es auch da genau 47K sind: Wäre klasse, wenn das wirklich so einfach ist.

Btw: Ich hatte übrigens auch getestet, zuerst jede Teildatei durch ffmpeg zu jagen und dann erst zusammenzukopieren, aber das hatte es noch schlimmer gemacht: Das werde ich nochmal mit "+discardcorrupt" testen.

An Wunder glaube ich zwar nicht, aber den Versuch ist es definitiv wert. :)
 
Zurück
Oben