DVB-S2 Streams von der Dreambox encoden (Linux only)

morlix

Ich kann es auch nicht erklären, aber so ist es. Was mir aufgefallen ist, ist das mediainfo bei dem TS 25 fps und 89989 Frames anzeigt. Bei dem aus dem mkv encodierten h264 zeigt er VFR an und keine FrameCount, ich habe aber beim encoding gesehen, das er nicht 89989 frames sondern 180020 frames encodiert.

Code

time x264 --crf 25 --vbv-maxrate 40000 --vbv-bufsize 30000 --profile high --level 41 --tune film --preset superfast -o del.x264 CSI_NY.mkv ffms [info]: 1920x1080i 1:1 @ 50045/1001 fps (vfr)
x264 [warning]: input appears to be interlaced, enabling tff interlaced mode.
                If you want otherwise, use --no-interlaced or --bff
x264 [warning]: interlace + weightp is not implemented
x264 [info]: using SAR=1/1
x264 [warning]: MB rate (407959) > level limit (245760)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile High, level 4.1
x264 [info]: frame I:21    Avg QP:24.50  size:164033                             
x264 [info]: frame P:700   Avg QP:27.03  size: 54598

Außerdem zeigt die ffms Zeile 50045/1001 fps was ja 49,99fps entspricht. Wenn ich das daraus erstellte x264 ohne timecodes muxe, geht die Aufnahme auf einmal 2h anstatt wie mit timecode nur 1h was auch richtig ist.
Das timecode file hat außerdem genau 180021 Zeilen, was abzüglich der ersten Header Zeile genau diesen Frames entspricht.

Ich frage mich nun (wahrscheinlich du auch) warum mediainfo hier nicht 50fps anzeigt.

Selur

Zitat

Das timecode file hat außerdem genau 180021 Zeilen, was abzüglich der ersten Header Zeile genau diesen Frames entspricht.

Achtung dabei, man hat pro Matroska-Block einen Timecode. Wenn man z.B. gemischten Content (interlaced/progressive) hat, hat man für jedes interlaced field und für jedes progressive frame einen Timecode.
-> bei reinem interlactem Content hat sollte man also pro field einen TimeCode haben, aber 2*Frameanzahl

Cu Selur

morlix

Laut mediainfo ist die Aufnahme nur "interlaced", zumindest steht bei scan type nichts von progressive.
Woher kommen den die restliches Frames her? Den 2*89989 ist 179978 und nicht 180020. Woher kommen also die anderen 42 frames?

LigH

Vielleicht eine angeschnittene GOP am Anfang, die nicht decodierbar ist. Kann ja sein, dass eine Aufzeichnung nicht mit einem I-Frame beginnt; aber nur an I-Frames kann die Decodierung beginnen.

morlix

WIe könnte ich das den prüfen?

Ich mach gerne alles was zur Klärung dieses Themas führt, aber um ehrlich zu sein bin ich jetzt erstmal richtig happy, dass das Encoding fehlerfrei und synchron funktioniert.

Selur

Zitat

Laut mediainfo ist die Aufnahme nur "interlaced", zumindest steht bei scan type nichts von progressive.

MediaInfo liest nur die ersten Header aus und analysiert nicht das File, sprich es wird nur angezeigt was das erste Frame ist.
-> Gerade bei Fernsehausstrahlungen die einfach gecaptured wurden, kann man sich deshalb nicht 100%ig auf die MediaInfo anzeige verlassen, da die Header da nicht immer stimmen.

Zitat

dass das Encoding fehlerfrei und synchron funktioniert.

Dann ignoriere das Phänomen erst mal und beschäftige Dich damit, wenn das aktuelle Verfahren nicht mehr klappt.

Zitat

WIe könnte ich das den prüfen?

Code

ffprobe -show_frames -pretty "path to input" | grep 'pict_type\|coded_picture_number'

sollte die Frames ausgeben (hab ich zumindest mal behauptet :D), siehe: http://forum.doom9.org/showthread.php?t=163553

Cu Selur

monarc99

Zitat von morlix

Laut mediainfo ist die Aufnahme nur "interlaced", zumindest steht bei scan type nichts von progressive.
Woher kommen den die restliches Frames her? Den 2*89989 ist 179978 und nicht 180020. Woher kommen also die anderen 42 frames?

Zum einen ist der Stream denn im traditionellen Sinne "interlaced"? Es kann z.B. auch sowas wie "Progressive segmented frame" sein, was mediainfo vielleicht als interlaced erkennt.

Zum anderen musst du bedenken, dass du mit TV Streams arbeitest, die nicht unbedingt fehlerfrei digital übertragen werden.
Es kann also vorkommen, dass an einer Stelle paar Videopakete verloren gegangen sind, während Audio noch vorhanden ist. Oder umgekehrt. Und wenn der Stream neu kodiert wird, muss das Encoder Programm entscheiden, was es macht. Nicht fehlerfrei dekodierbare Stellen wegschneiden? oder mit Dupes auffüllen? oder Nix tun? und die Timecodes richten es - was dann variable Framerate (VFR) bedeuten dürfte - usw...
Du brauchst also nicht erwarten, dass genau die gleiche Frameanzahl wieder rauskommt.

Wobei ich bei TV Aufnahmen nicht unbedingt auf VFR zusteuern würde. Da gibt es zu viele TV- / HW-Player die solche Dateien nicht abspielen.
Auch beim Audio wäre ich vorsichtig, zeitlich versetzte Streams oder Lücken im Stream würden mir selbst nicht gefallen. Zumal ich nach 1 Monat wieder vergessen habe, dass die Dateien nur durch die Timecodes sync gehalten werden und ich nicht einfach die Streams extrahieren darf.

Aber kommt halt ganz drauf an, was man mit seinen TV Aufnahmen machen will.

mfg
monarc

morlix

Zitat von monarc99

Aber kommt halt ganz drauf an, was man mit seinen TV Aufnahmen machen will.

Gibt es etwas das du jetzt anderst machen würdest oder wie soll ich das verstehen?

Selur ich hab leider nur avprobe wo es kein -show_frames gibt. Aber ich konnte es aus dem verlinkten Post mit mkvinfo herausfinden.

Code

Track 1: Video, Codec-ID: V_MPEG4/ISO/AVC (h.264-Profil: High @L4.0), Standarddauer: 40.000ms (25.000 Bilder pro Sekunde im Falle eines Video-Tracks), Sprache: und, Pixelbreite: 1920, Pixelhöhe: 1080, Anzeigebreite: 1920, Anzeigehöhe: 1080
Track 2: Audio, Codec-ID: A_AC3, Standarddauer: 32.000ms (31.250 Bilder pro Sekunde im Falle eines Video-Tracks), Sprache: ger, Abtastfrequenz: 48000, Kanäle: 6
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0x0bf6df0c
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0xceffd557
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0x0bdde29e
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0x255cce4f
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0x4b6de4c2
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0xe73cd103
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0x181edad9
I Frame, Track 2, Zeitstempel 0 (00:00:00.000), Größe 1534, Adler 0x16a6e894
I Frame, Track 1, Zeitstempel 229 (00:00:00.229), Dauer 180.000, Größe 71472, Adler 0x564f07fb
I Frame, Track 2, Zeitstempel 256 (00:00:00.256), Größe 1534, Adler 0xb60fd2b6
I Frame, Track 2, Zeitstempel 256 (00:00:00.256), Größe 1534, Adler 0x5df1f600

Alles anzeigen

Der Stream startet also schon mit einem I-Frame.

sneaker2

Zitat von morlix

Ich kann es auch nicht erklären, aber so ist es. Was mir aufgefallen ist, ist das mediainfo bei dem TS 25 fps und 89989 Frames anzeigt. Bei dem aus dem mkv encodierten h264 zeigt er VFR an und keine FrameCount, ich habe aber beim encoding gesehen, das er nicht 89989 frames sondern 180020 frames encodiert.

Dann würde es mit den 20ms Timecodes hinkommen, allerdings müßte dann jeder Frame doppelt vorhanden sein.

Zitat von morlix

Der Stream startet also schon mit einem I-Frame.

Könnte sein, daß mkvmerge alles zu Beginn bis zum ersten I-Frame schon weggeschnitten hat. Bin mir da gerade nicht ganz sicher.

Was monarc99 erklärt, würde meinem Tip aus #33 entsprechen. Frames werden verworfen/dupliziert, um am Ende auf konstante 25 fps zu kommen. Für den Ton könnte man analog vorgehen. Unter Linux meinte hier ja irgendjemand evtl. mit HandBrake, falls man eine Neukodierung vermeiden will.

morlix

Hier nochmal eine Variante mit avconv informationen zu den Frames zu bekommen. Da avprobe leider kein -show_frames bietet habe ich diese Lösung gesucht und gefunden.

Code

avconv -i [COLOR=#66CC66]<[/COLOR]input [B]file[/B][COLOR=#66CC66]>[/COLOR] -filter:v [COLOR=#0000FF]showinfo[/COLOR]=n:pts:pts_time:pos:sar:s:i:iskey:[COLOR=#000066]type[/COLOR]:checksum:plane_checksum -f matroska - [COLOR=#CC66CC]1[/COLOR][COLOR=#66CC66]>/[/COLOR]dev[COLOR=#66CC66]/[/COLOR]null

Erklärung dazu findet man unter http://libav.org/avconv.html#showinfo.

sneaker2: Ich versuche gerade mal deinen Tipp aus #33 und melde mich dann wieder.

Gruß morlix und danke allen die mir soweit geholfen haben!

sneaker2

Der Tip aus #33 müßte analog auch für avconv gelten:
avconv -i input -r 25 etc.

Gibt sicherlich auch eine Variante für mencoder und mplayer, bin aber gerade zu faul zum Nachschauen...

morlix

Das habe ich mir schon angeschaut und wie folgt gemacht.

Code

avconv -i csi_ny_20110912\ 2105\ -\ VOX\ HD\ -\ CSI_NY.ts -r 25 -f yuv4mpegpipe - | x264 - --crf 25 --vbv-maxrate 40000 --vbv-bufsize 30000 --profile high --level 41 --tune film --preset superfast --demuxer y4m -o video_yuv4.264

Herausgekommen ist dabei folgendes:

Code

GeneralComplete name                            : video_yuv4.264
Format                                   : AVC
Format/Info                              : Advanced Video Codec
File size                                : 3.84 GiB




Video
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : MBAFF
Writing library                          : x264 core 123 r2189 35cf912
Encoding settings                        : cabac=1 / ref=1 / deblock=1:-1:-1 / analyse=0x3:0x3 / me=dia / subme=1 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=tff / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=0 / rc=crf / mbtree=0 / crf=25.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=none / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

Alles anzeigen

Wenn ich dieses Video inkl. den timecodes muxen will, bricht / stürzt mkvmerge ab, da die Anzahl frames in diesem Video nicht der Anzahl aus dem video_yuv4.264 Track entsprechen.

Das muxen ohne timecode hingegen funktioniert problemlos. Allerdings zeigt VLC kein Bild an und die Dauer ist anscheinen 10h obwohl die Aufnahme nur 1h ist.

Was hab ich hier falsch gemacht?

Wenn ich das richtig verstanden habe, sollte ich meine Aufnahmen nicht mit einer VFR speichern. Aber ich hab leider nicht wirklich verstanden was dies für technische Probleme bringt.

Habt ihr noch irgendwelche Anmerkungen, was ich an meinem Prozess aus #37 ändern soll?
Wenn nicht, mache ich mich jetzt mal daran irgendwie das croppen und rausschneiden von 5min am Anfang und x Minuten am Ende zu beschäftigen.

Danke und Gruß morlix

sneaker2

Zitat von morlix

Was hab ich hier falsch gemacht?

Bis auf den Versuch mit den Timecodes zu muxen: vermutlich nichts.
Das scheint einfach ein Problem von avconv zu sein. TS ist immer eine Sache für sich.
Außer das alles noch mal mit den aktuellen Versionen von ffmpeg/mencoder/mplayer zu testen, kann man nicht wirklich viel machen. Dazu noch die bekannten Tricks, wie z.B. erst zu mkv muxen.

Ein andere hatte hier ja noch handbrake vorgeschlagen. Hat das zum Erfolg geführt?

Selur

Basierend auf Beitrag #37 solltest Du:
1. das Schneiden am sinnigsten direkt nach dem Multiplexen nach mkv mit mkvmerge (siehe: https://www.bunkus.org/videotools/mkv…scription.split ) machen. (Vorteil: Audio&Video&Timecodes werden geschnitten)
2. croppen im x264 Aufruf machen:

Zitat

--vf, --video-filter <filter0>/<filter1>/... Apply video filtering to the input file

Filter options may be specified in <filter>:<option>=<value> format.

Available filters:

crop:left,top,right,bottom

removes pixels from the edges of the frame

Zitat

Habt ihr noch irgendwelche Anmerkungen, was ich an meinem Prozess aus #37 ändern soll?

davon ausgegangen, dass x264 mit lav Unterstützung compiliert ist kann man sich das demuxen des Streams vorher eigentlich sparen,...

Cu Selur

morlix

Zitat von sneaker2

Ein andere hatte hier ja noch handbrake vorgeschlagen. Hat das zum Erfolg geführt?

Ja hat es. Einen CLI test habe ich noch nicht gemacht.

Zitat von Selur

Basierend auf Beitrag #37 solltest Du:
1. das Schneiden am sinnigsten direkt nach dem Multiplexen nach mkv mit mkvmerge (siehe: https://www.bunkus.org/videotools/mkv…scription.split ) machen. (Vorteil: Audio&Video&Timecodes werden geschnitten)
2. croppen im x264 Aufruf machen:

davon ausgegangen, dass x264 mit lav Unterstützung compiliert ist kann man sich das demuxen des Streams vorher eigentlich sparen,...

Alles klar, das werde ich probieren und mich dann nochmal melden.
Kann ich das Schneiden nicht gleich beim muxen des ts machen?

sneaker2

Zitat von morlix

Kann ich das Schneiden nicht gleich beim muxen des ts machen?

Ja, sollte gehen.
Mkvmerge schneidet allerdings nur an Keyframes.

morlix

Kann mir einer von euch kurz sagen wie ich die cropdetect Ausgabe von avconv schnell auf x264 umwandle?

Original resolution: 1920x1080

Code

[cropdetect @ 0x1c5c9e0] x1:1 x2:1919 y1:2 y2:1079 w:1904 h:1072 x:10 y:6 pos:0 pts:600120000 t:600.120000 crop=1904:1072:10:6

Ich habe jetzt mal testweise folgende crop Werte für x264 angewendet.

crop:8,4,8,4

Wenn ich allerdings die man page avconv richtig verstehe, sollte es eher so sein.

crop:10,6,6,2

sneaker2

10,6,6,2 sieht auf den ersten Blick richtig aus, aber das müßtest Du ja am Ergebnis sehen.

morlix

Ok danke.

Wenn ich ein jpeg aus dem Video extrahiere, frage ich mich was das cropdetect da überhaupt erkannt hat.
Ich sehe nicht wirklich einen schwarzen Rand in diesem Bild.

Jetzt mitmachen!