Kleine Ruckler bei Aufnahme direkt auf NFS (Ubuntu)

[Felias]

Hallo zusammen,

nachdem ich nun erfolgreich das NFS unter Ubuntu und auf der dbox eingerichtet haben, funktioniert die Aufnahme auch grundsätzlich. Allerdings ist mir aufgefallen, dass die Streams in regelmässigen kurzen Abständen (ca. jede Sekunde) einen kleinen Miniruckler haben. Dieser ist nur bei Kameraschwenks auffallend, stört aber dennoch den Sehspaß.

Bei einer Aufnahme in der Vergangenheit mit Windows und JtG (selbiges Image nutze ich auch) auf Basis derselben Infrastruktur war von diesen Ruckler keine Spur. Das Netz ist ein 100Mbit (auch wenn die dbox nur 10Mbit kann), daher sollte hier eigentlich kein Flaschenhals sein. Die Festplatte ist eine interne SATA-Platte.

Hättet Ihr eine Idee, woran es liegen könnte?

Besten Dank schonmal + Grüße,
Felias

[jmittelst]

Wie siehst Du Dir die Aufnahme an?

Wenn es im Movieplayer der Dbox ruckelt: Performance-Problem! Sicherheitshalber Aufnahme mit ProjectX demuxen, ggf. Log hier posten.

Wenn es im Player auf dem PC ruckelt: Welcher Player? Welche CPU-Last? Beschreib mal die Ruckler genauer...

cu
Jens

[Felias]

Hallo Jens und danke schonmal für die Antwort.

Ich schaue mir die Datei am PC an. Das Ruckeln tritt sowohl beim Abspielen der .ts-Datei auf, als auch nach der Konvertierung in ein beliebiges Filmformat. Generell werden eh alle Aufnahmen demuxed, Audio- und Videostream kodiert (Video in h264 und Audio in Ogg), und dann per mkvmerge in einen Container zusammengefügt. Spätestens da sollte es aufgrund von der Rechnerperformance nicht mehr ruckeln (Athlon X2 2,5Ghz, 3 GB Ram). CPU-Last ist unter 20%.

Ich werde heute Abend mal einen kleinen Schnipsel aufnehmen, konvertieren, und hier verlinken, dann kannst Du Dir ein besseres Bild davon machen. Stell es Dir bis dahin so vor: Wenn ein Kameraschwenk kommt, dann "hängt" das Bild für einen Sekundenbruchteil fest, und springt dann an die aktuelle Position. Genau das passiert auch ca. jede Sekunde einmal. Es ist aber so minimal, dass es nur bei Schwenks richtig auffällt.

Einen Test des LAN-NFS-Durchsatzes werde ich heute Abend anhand eines hier geposteten Skriptes durchführen, vielleicht liegt es ja doch am LAN.

Grüße,
Felias

[wolgade]

Demux die TS-Datei mal mit ProjectX! Wenn du da einen Sack voller Fehlermeldungen im Log bekommst, dann läuft bereits bei der Aufnahme etwas schief.

[Felias]

Am Netz kann es wohl nicht liegen:

Code: Alles auswählen

udp, sync
7876
7529
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

udp, async
7876
7529
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

tcp, sync
7757
7641
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

tcp, async
7876
7641
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

@wolgade: Gute Idee, werde ich heute noch testen.

[wolgade]

Am Netz kann es wohl nicht liegen:

Doch. Die Werte sind guter Durchschnitt. Bei Sendern mit hoher Bitrate dürftest du Probleme kriegen. Die äußern sich dann allerdings in Streamabbrüchen mit dem Ergebnis, daß du viele kleine Dateien statt einer großen bekommst.

[Felias]

Am Netz kann es wohl nicht liegen:

Doch. Die Werte sind guter Durchschnitt. Bei Sendern mit hoher Bitrate dürftest du Probleme kriegen. Die äußern sich dann allerdings in Streamabbrüchen mit dem Ergebnis, daß du viele kleine Dateien statt einer großen bekommst.

Hm, dann hab ich die Aussagen der Leute in dem Thread irgendwie mißverstanden... Aber wie auch immer: Ich bekomme nur eine einzelne große Datei.

[wolgade]

Ich wollte nicht sagen, daß ich bei deinem speziellen Problem die Ursache im Netzwerk sehe, sondern lediglich andeuten, daß die NFS-Performance deines Systems keinesfalls rekordverdächtig ist. Bei ZDF-Aufnahmen wirst du damit vermutlich Ärger bekommen.

Schau dir aber erst mal an, was ProjectX zu deiner Datei sagt!

[rhabarber1848]

192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

Kannst Du die blocksize auf 32768 erhöhen?

[wolgade]

Kannst Du die blocksize auf 32768 erhöhen?

Das hab ich doch glatt übersehen. Hat mit deinem gegenwärtigen Problem, wie ich schon sagte, vermutlich nichts zu tun, ist aber auf jeden Fall empfehlenswert, um den NFS-Durchsatz zu erhöhen.

[Felias]

super, dann danke schonmal für diesen Tipp.

Das ist der Output von ProjectX beim demuxen:

Code: Alles auswählen

<<< session infos >>>

Donnerstag, 11. September 2008  19:30 Uhr MESZ
ProjectX 0.90.4.00 (30.03.2006)

-> working with collection 0
 
-> save normal log file
-> write all video data
-> write all other data
-> patch c.d.flagged infos of pictures
-> add sequence end code
-> set resolution in SDE 
-> PVA: strictly specs. for audio streams
-> VOB: determine diff. Cell timelines
-> TS: ignore scrambled packets
-> TS: enhanced search for open packets
-> TS: join file segments (of Dreambox®)
-> TS: generate PMT stream dependent
-> get only enclosed PES/TS packets
-> concatenate different recordings
-> ensure 1st PES-packet start with video
-> generate PCR/SCR from PTS
 
-> write output files to: '/home/Aufnahm'

-> Input File 0:  '/home/Aufnahm/ZDFdokukanal_Labor_mit_Aussicht_-_Astronauten_forschen_im_All_2008-09-11_060004.ts' (713.023.276 bytes)
-> Filetype is TS (generic PES Container)
-> demux
-> Service ID 0x6D66
-> PMT 0xFFF refers to these usable streams:
Video:
PID: 0x294
Audio:
PID: 0x29E
Teletext:
n/a
Subpict.:
n/a

!> PID 0x1F (SIT) (0 #1) -> ignored
!> PID 0x0 (PAT) (188 #2) -> ignored
!> PID 0xFFF (PMT) (376 #3) -> ignored
ok> PID 0x294 has PES-ID 0xE0 (MPEG Video) (2632 #15) 
ok> PID 0x29E has PES-ID 0xC0 (MPEG Audio) (63732 #340) 
-> video basics: 720*576 @ 25fps @ 0.7031 (16:9) @ 15000000bps, vbvBuffer 112
-> starting export of video data @ GOP# 0
!> dropping useless B-Frames @ GOP# 0 / new Timecode 00:00:00.000
!> PID 0x294 -> packet 3792446 @ pos. 712979660 out of sequence (0/15) (shifting..) (~00:14:55.960)
!> PID 0x29E -> packet 3792468 @ pos. 712983796 out of sequence (7/4) (shifting..) (~00:14:55.960)
!> packet writing: length index out of bounds, shortened.. (29e / c0 / c0 / 5335 -- 4850 / 14 / 5376) @ PTS 06:07:18.201
packs: 3792674 100% 713023276

-> Video: fr/ ct/ 1p/ cg/ og/ dg -> 22399/ 1/ 0/ 1844/ 0/ 0
-> Video length: 22399 frames @ 00:14:55.960
-> GOP summary: min. 18, max. 36 fields; contains interlaced frames
-> avg. nom. bitrate 5951343bps (min/max: 2965600/8286000)
-> set first sequenceheader bitrate to 8286000bps
---> new File: /home/dada/Datenlager2/Aufnahm/ZDFdokukanal_Labor_mit_Aussicht_-_Astronauten_forschen_im_All_2008-09-11_060004.m2v

--> MPEG Audio (0xC0) on PID 0x29E
-> check CRC of AC-3 / MPEG-Audio L1,2
-> delete CRC in MPEG-Audio Layer1,2
-> add frames
Audio PTS: first packet 05:52:21.921, last packet 06:07:18.201
Video PTS: start 1.GOP 05:52:22.397, end last GOP 06:07:18.357
-> adjusting audio at video-timeline
-> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 256kbps, CRC @ 00:00:00.000
!> missing syncword @  28684801, @ 00:14:55.920
!> 2 frame(s) (48ms) added @ 00:14:55.920
audio frames: wri/pre/skip/ins/add 37332/0/0/0/2 @ 00:14:55.968 done...
---> new File: '/home/dada/Datenlager2/Aufnahm/ZDFdokukanal_Labor_mit_Aussicht_-_Astronauten_forschen_im_All_2008-09-11_060004.mp2'

summary of created media files:
.Video (m2v):	22399 Frames	00:14:55.960		'/home/dada/Datenlager2/Aufnahm/ZDFdokukanal_Labor_mit_Aussicht_-_Astronauten_forschen_im_All_2008-09-11_060004.m2v'
Audio 0 (mp2):	37332 Frames	00:14:55.968	0/0/0/2	'/home/dada/Datenlager2/Aufnahm/ZDFdokukanal_Labor_mit_Aussicht_-_Astronauten_forschen_im_All_2008-09-11_060004.mp2'
=> 695.191.679 bytes written...
-> we have 9 warnings/errors.

Ich bin mir bezüglich der Aussagekraft desselben nicht so recht sicher... könnt ihr daraus etwas lesen?

[wolgade]

Na klar.

Code: Alles auswählen

!> PID 0x1F (SIT) (0 #1) -> ignored
!> PID 0x0 (PAT) (188 #2) -> ignored
!> PID 0xFFF (PMT) (376 #3) -> ignored

Wurscht.

Code: Alles auswählen

!> dropping useless B-Frames @ GOP# 0 / new Timecode 00:00:00.000

Normal am Anfang einer Aufnahme, da die ja irgendwo im MPEG-Stream anfängt. Decodierbar ist die erst ab der nächsten GOP (Group of pictures).

Code: Alles auswählen

!> PID 0x294 -> packet 3792446 @ pos. 712979660 out of sequence (0/15) (shifting..) (~00:14:55.960)
!> PID 0x29E -> packet 3792468 @ pos. 712983796 out of sequence (7/4) (shifting..) (~00:14:55.960)

An der Stelle wird es ruckeln.

An der gleichen Timecodeposition in der Audiodatei:

Code: Alles auswählen

!> missing syncword @  28684801, @ 00:14:55.920
!> 2 frame(s) (48ms) added @ 00:14:55.920

Dem Log nach zu urteilen, gibt es beim Abspielen der TS-Datei exakt einen Ruckler. Ich hab dieses Phänomen mal vor geraumer Zeit während der Aufnahme geloggt. An genau den Stellen, wo hinterher die TS-Datei diese Macke hatte, war eine Fehlermeldung des GTX aufgetreten, dem der Demuxpuffer übergelaufen war.

[Felias]

@wolgade:

danke für die Analyse Das würde dann 2 Ruckler im Film erklären, aber nicht die konstanten "Mini-Ruckler", die ja das eigentlich Problem darstellen...

[wolgade]

Das würde dann 2 Ruckler im Film erklären,

Nö, einen.

aber nicht die konstanten "Mini-Ruckler"

Richtig, das scheint eine komplett andere Baustelle zu sein.

Um das mal einzugrenzen: Du guckst dir die Aufnahmen auf dem PC an? Welches Betriebssytem? Welcher Player?

Ich hab im Moment sehr ähnliche und lästige Probleme unter openSuse. Das liegt aber an einem halbgaren X-Server und dem verbugten proprietären ATI-Treiber.

[NASeweiss]

-> avg. nom. bitrate 5951343bps (min/max: 2965600/8286000)

udp, async
7876
7529
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

...und das erklärt (mit hoher Wahrscheinlichkeit) die weiteren Ruckler; die Leseleistung von deutlich unter 8Mbit reicht halt für Peaks bis ~8,3 nicht wirklich. Wabbel-Queue eingeschaltet? Sinds nur kurze Spitzen dürfte das reichen. Ansonsten das übliche: Mit rsize = 32k testen, Wabbel-Buffer erhöhen......

[Tommy]

..Waber Queue hat doch nix mit Aufnahme zu tun. Die Ruckler hat er doch am PC ;-) Wenn PX da keine Auffälligkeiten zeigt ist der Stream denke ich mal OK und der Fehler auf dem PC zu suchen. Ist denn die Wiedergabe auf der Dbox auch ruckelig? Was passiert wenn Du Dir den rohen TS Stream auf dem PC mit VLC oder Mediaplayer Classic anschaust?

[NASeweiss]

..Waber Queue hat doch nix mit Aufnahme zu tun. Die Ruckler hat er doch am PC ;-)

Klar hat die Wabbel nichts mit der Aufnahme zu tun - aber Recht hast Du! Ich hatte überlesen, dass er die Ruckler auf dem Rechner hatte......bin reflexartig von der Wiedergabe des TS-Files auf der DBox ausgegangen .

Einfachster Test: Wiedergabe des TS-Files mit dem MPC auf dem Rechner....mehr als den einen, von wolgade angesprochenen, Ruckler sollte es damit nicht geben.

[Felias]

Danke für Eure Beiträge.

Der PC, auf dem die Aufnahmen landen, ist ein Ubuntu-Server. Auf ihm demuxxe und kodiere ich die Filme, schaue sie mir aber nicht an. Per Samba-Freigabe streamt er zu mein HTPC (Athlon x2 5000+, 2 GB Ram, WinXP) die Filme über das LAN. Hier kann ich aber meines Ermessens ein Problem aussschließen, denn selbst das Streamen von 1080p-kodiertem Material erfolgt ruckelfrei.

Den TS-Stream kann ich mir auch nur hier anschauen, da es auf dem Server unter Ubuntu nicht sauber abspielt (Player nicht eingerichtet). Der Server ist aber eher noch stärker als der HTPC.

Mit rsize = 32k testen, Wabbel-Buffer erhöhen......

Sagt mir leider nichts, aber ich werde die Information sicher hier im Forum finden.

Ich schaue mir die TS-Datei heute mal auf dem HTPC an und berichte dann.

[rhabarber1848]

Mit rsize = 32k testen

Sagt mir leider nichts

In den Dbox-Mount-Optionen "rsize=8192" auf "rsize=32768" ändern und neu
mounten. Du kannst dann den Geschwindigkeitstest wiederholen.

Zur Wiedergabe würde ich mal probieren, die Datei per Samba auf die lokale
HDD des PCs zu kopieren und zu schauen, ob das einen Unterschied macht.

[Felias]

Danke für den Tipp! Hier die neuen Werte:

Code: Alles auswählen

udp, sync
7876
8393
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

udp, async
8000
8533
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

tcp, sync
7876
8533
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

tcp, async
7876
8393
192.168.178.34:/home/Aufnahm on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.178.34)

Was mir aufgefallen ist: Wenn ich den reinen TS-Track am HTPC abspielen, dann ruckelt dieser nicht. Ich vermute die Ursache daher bei der Konvertierung, bin aber sehr unsicher, wo der Hund hier begraben liegen könnte Ich kodiere mit avidemux.

[wolgade]

Hier die neuen Werte:

Das sieht doch schon besser aus.

Wenn ich den reinen TS-Track am HTPC abspielen, dann ruckelt dieser nicht.

Was bedeutet, daß die Aufnahme erst mal so weit in Ordnung ist, abgesehen von der einen Macke, die ProjectX offenbart hat.

Ich vermute die Ursache daher bei der Konvertierung,

Ich auch. Wo sollte das Problem sonst entstehen? Darf ich mal blöd fragen, warum du die TS-Dateien konvertierst? Die Bildqualität wird doch davon nicht besser und Plattenplatz ist spottbillig. Was mir noch spontan einfällt: H264 braucht wesentlich mehr Rechenleistung als MPEG2. Hier kann nicht zufällig das Problem liegen?

Ansonsten muß ich an dieser Stelle passen. Da ich keinen Sinn darin sehe, Videomaterial, das bereits einmal verlustbehaftet komprimiert wurde, ein zweites Mal durch diesen Wolf zu drehen, habe ich mich damit nie ernsthaft befaßt. Deine Kombination aus H264 und OGG ist auf jeden Fall recht eigenwillig. Kann gut sein, daß der Player damit nicht gut klarkommt.

[Felias]

Was bedeutet, daß die Aufnahme erst mal so weit in Ordnung ist, abgesehen von der einen Macke, die ProjectX offenbart hat.

Als ich eben einen zweiten Clip aufgenommen habe, so hat dieser in abgeschwächte Form doch Ruckler zu erkennen. Es ist ein kurzer Mitschnitt von einer Sendung mit Laufbalken, daher sieht man es hier gut.

Ist es okay, wenn ich hier einen Link zu dem Clip poste, damit Du bzw. andere hier das Problem ev. besser analysieren können?

Ich auch. Wo sollte das Problem sonst entstehen? Darf ich mal blöd fragen, warum du die TS-Dateien konvertierst? Die Bildqualität wird doch davon nicht besser und Plattenplatz ist spottbillig.

Och, die Clips in H264 haben einen kaum sichtbaren qualitativen Unterschied zum Orginalstream, und die Dateien nehmen nur noch 30% von der ursprünglichen Größe ein. Außerdem sind sie so besser zu archivieren.

Was mir noch spontan einfällt: H264 braucht wesentlich mehr Rechenleistung als MPEG2. Hier kann nicht zufällig das Problem liegen?

Nein, definitiv nicht. Andere entsprechen kodierte Videosignale mit viel höherer Bitrate laufen problemlos.

Ansonsten muß ich an dieser Stelle passen. Da ich keinen Sinn darin sehe, Videomaterial, das bereits einmal verlustbehaftet komprimiert wurde, ein zweites Mal durch diesen Wolf zu drehen, habe ich mich damit nie ernsthaft befaßt. Deine Kombination aus H264 und OGG ist auf jeden Fall recht eigenwillig. Kann gut sein, daß der Player damit nicht gut klarkommt.

Am Player liegt es definitiv nicht, das kann ich wirklich ausschließen. Bei allem anderen genauso kodierten Material (selbst in 1080p) funktioniert wunderbar. H264 und OGG sind einfach aktuell die besten Audio- bzw. Videocodecs, daher bieten sich diese an.

[wolgade]

Ist es okay, wenn ich hier einen Link zu dem Clip poste, damit Du bzw. andere hier das Problem ev. besser analysieren können?

Vermutlich nicht, da es sich wohl um urheberechtlich geschütztes Zeug handeln dürfte. Das kann Ärger geben und da steht Die Made nicht so drauf. Ich schreib dir mal eine PN.

Och, die Clips in H264 haben einen kaum sichtbaren qualitativen Unterschied zum Orginalstream,

Okay, müssen wir auch nicht diskutieren. Ich bin halt Qualitätsjunkie. Mir wäre es lieber, Double-Layer-Rohlinge für Filme von 30 min. Länge zu benutzen, statt Artefakte zu sehen. Von letzterem krieg ich Hautausschlag.

[Felias]

Okay, müssen wir auch nicht diskutieren. Ich bin halt Qualitätsjunkie. Mir wäre es lieber, Double-Layer-Rohlinge für Filme von 30 min. Länge zu benutzen, statt Artefakte zu sehen. Von letzterem krieg ich Hautausschlag.

Kein Thema, habe für die Einstellung vollstes Verständnis, ich selbst lege auch Wert auf Qualität. Allerdings ist es immer eine Frage von Qualität/Festplattenplatz, und da sehe ich nach vielen Tests aktuell H264 an der Spitze.

Ich hoffe die Datei hilft weiter (siehe PM)

[jmittelst]

Ja, H.264 ist ja schon OK, aber nur, wenn es als Quellmaterial so oder unkodiert an kommt. Mpeg2 so noch weiter zu komprimieren, geht nicht ohne Qualitätsverlust. Nicht, das man den unbedingt sehen muß, aber die nächste Glotze oder Brille könnte da durchaus die Meinung ändern.

Außerdem würde ich bei der These, das Vorbis als Tonspur für Video eine gute Wahl ist, einen Einspruch setzen. Da hat AAC eher die Nase vorn und ist im MP4-Container mit H.264 sogar Standard. Außerdem bietet AAC 5.1. Und es gibt diverse Player (NeroMP abspielbar), die einen MP4-Container mit AAC abspielen können. Vorbis mag als MP3-Ersatz noch nett sein, aber nicht als Videoton.

Zusätzlich kann bei der Neu-Encodierung einiges schief gehen, da die Enkoder recht komplex sein können, wenn man denn Qualität und Größe "ausreizen" will und sich nicht mit z.B. "Nero-Standards" o.ä. zufrieden geben will.

cu
Jens