Jump to content

H.264: 720p mit 25 fps?


Martin K

Recommended Posts

Hallo,

 

bisher dachte ich, bei 720p wären über DVB nur 50 fps zulässig?

Bei Unitymedia gibt es einen Sender "Kino HD", das ist ein PPV-Sender.

Bisher wurde mir im DVBViewer da immer 1280x720 50 fps angezeigt (also wie bei ARD & ZDF HD).

Jetzt ist mir letztens, als ich mal wieder zufällig auf die Statusleiste schaute, aufgefallen, dass dort 25 fps steht...?

Also ich bin mir aber ziemlich sicher, dass da vorher 50 fps standen...

Dann dachte ich erst, Unitymedia hätte da etwas geändert.

Habe dann eine ältere TS Aufnahme abgespielt, und auch hier werden 25 fps angezeigt. (Bei ARD & ZDF HD jedoch nach wie vor 50 fps.)

Also kann es eigentlich nur eine Änderung im DVB Source 3.5.4.0 sein, der letztens (zusammen mit dem DVBViewer 4.6.0.1) geupdatet wurde.

Kann mir jemand genaueres dazu sagen? Leider konnte ich keinen Changelog zum DVB Source 3.5.4.0 finden...

Link to comment

Es gibt eine Angabe im H.264 Sequence Parameter Set, die mitunter von Encodern verschieden interpretiert wird - als Frames oder Fields. In einer der letzten DVBViewer Filter Versionen hatte ich die Interpretation geändert, da die vorherige in bestimmten Fällen falsche Angaben lieferte, und bereits erwartet, dass es nun eventuell in anderen Fällen schief geht :) Wenn ich ein Sample kriege, schaue ich mal rein...

Link to comment

Hallo Griga,

danke für deine Antwort!

 

Frames oder Fields - sind Fields nicht die Halbbilder? Das heißt, das betrifft doch dann nur interlaced Material, oder?

Bei progressivem Material (wie 720p) müssten Frames und Fields also identisch sein?

Korrigiere mich bitte, wenn ich falsch liege...

 

Die jetzige Angabe mit 25 fps scheint aber die richtige zu sein, da sie auch von anderen Programmen (getestet mit Nero ShowTime und SUPER©) so angezeigt wird.

Ich habe mich halt nur gewundert, weil ich dachte für DVB wären bei 720p nur 50 fps vorgesehen...

 

Ein Sample kann ich dir gerne hochladen, muss nur mal schauen, wo das geht (im TS Format, und die Dateien sind ja auch nicht gerade klein) ;)

Edited by Martin K
Link to comment

Die Bestimmung der Framerate für H.264 ist ein Problem, da die Angabe nicht direkt im Header (Sequence Parameter Set) steht, sondern aus anderen Angaben berechnet werden muss, und zwar aus folgenden:

 

Dein Sample:

 

        -------------------- Timing Info Section
           num_units_in_tick = 1000
           time_scale = 50000
           fixed_frame_rate_flag = 1 -----> frame rate 25 fps
       --------------------

 

Das Erste HD:

 

        -------------------- Timing Info Section
           num_units_in_tick = 1
           time_scale = 100
           fixed_frame_rate_flag = 1 -----> frame rate 50 fps
       --------------------

 

Klar ist jedenfalls, dass man time_scale / num_units_in_tick berechnen muss. Aber ob das die Field- oder Framerate ergibt, darüber streiten sich die Gelehrten. Madshi meinte bei Doom9:

 

'cause this is _field_ rate, not frame rate. it doesn't depend on sequence scan/coding mode - it is so for both progressive and interlaced sequences.

 

d.h. um die Framerate zu erhalten, muss man das Ergebnis durch 2 teilen. Für das Erste HD ist das offenbar richtig. Für dein Sample fraglich, denn eigentlich sollte man auch hier 50 fps annehmen. 720p mit 25 fps ist ungewöhnlich, aber ich sehe nichts, was dagegen spricht. Ich werde es meiner Sammlung von Kuriositäten hinzufügen :)

 

Ich habe jedoch auch schon (ältere) H.264-Samples gesehen, bei denen die Division eindeutig die Framerate ergab. Weiteres Material dazu liefert eine Google-Suche nach "num_units_in_tick" - darüber haben schon viele gerätselt. Angeblich soll es noch ein Flag in einem anderen Header geben, dass entscheidet, ob die obige Rechnung die Field- oder Framerate liefert, aber damit habe ich mich noch nicht befasst.

Link to comment

Ja, das ganze ist echt 'ne verzwickte Sache...

 

Angeblich soll es noch ein Flag in einem anderen Header geben, dass entscheidet, ob die obige Rechnung die Field- oder Framerate liefert, aber damit habe ich mich noch nicht befasst.

Ja, irgendetwas muss es ja noch geben, denn es wird ja korrekt abgespielt (also nicht doppelt so schnell oder in Zeitlupe), egal ob mit dem alten DVB Source (das bei "Kino HD" ja 50 fps anzeigte) oder eben mit der aktuellen Version.

 

In den Supplemental enhancement information (SEI) habe ich noch das nuit_field_based_flag gefunden.

Damit (und mit den anderen Informationen) wird dann wohl für jedes Frame der clockTimestamp individuell berechnet (Equation D-1 in den Rec. ITU-T H.264).

Wobei, egal ob dieses Flag 1 oder 0 ist, irgendwie immer durch 2 geteilt wird:

(e.g., 12.5 frames per second with time_scale equal to 50 and num_units_in_tick equal to 2 and nuit_field_based_flag equal to 0)

und

(e.g., 30000÷1001 frames per second with time_scale equal to 60000 and num_units_in_tick equal to 1 001 and nuit_field_based_flag equal to 1)

 

 

Für dein Sample fraglich, denn eigentlich sollte man auch hier 50 fps annehmen. 720p mit 25 fps ist ungewöhnlich, aber ich sehe nichts, was dagegen spricht.

Tja, aber scheint wohl richtig zu sein, da, wie oben schon geschrieben, andere Programme das auch so anzeigen.

Und bei einem reinen Spielfilm-Angebot macht das ja auch irgendwie Sinn ;)

 

Apropos Spielfilme:

Also soweit ich weiß gibt es da so eine Art Flag das anzeigt, dass das Frame einfach verdoppelt wird, also damit aus den 25 fps des Spielfilms -> 50 fps werden, ohne jedes Frame doppelt zu codieren.

Vielleicht ist es ja so bei diesem Sender, dass die theoretische Framerate zwar 50 fps sind, aber praktisch jedes Frame nur einmal codiert ist, also mit 25 fps, und dann halt über diese Flag einfach nur verdoppelt wird?

 

Etwas ähnliches gibt es übrigens auch bei diversen Kompaktkameras mit AVCHD (z.B. Panasonic).

Da steht dann beispielsweise im Datenblatt: "1.280 x 720, 50p [CCD-Ausgabe 25p]"

Meine Programme (Nero ShowTime, SUPER©) zeigen bei einem solchen Video wieder 25 fps an, DVB Source 3.5.4.0 zeigt hier jetzt aber komischerweise 50 fps an ...

Interesse an einem kurzen Sample? ;)

Link to comment
Interesse an einem kurzen Sample?

Immer :) Zur Zeit arbeite ich ohnehin an einem erweiterten Parsen von H.264 NAL Units, und dafür kann ich Testmaterial bestens gebrauchen.

 

Vielleicht ist es ja so bei diesem Sender, dass die theoretische Framerate zwar 50 fps sind, aber praktisch jedes Frame nur einmal codiert ist, also mit 25 fps, und dann halt über diese Flag einfach nur verdoppelt wird?

Wenn ich zufällig auf ein solches Flag stoßen sollte, sage ich Bescheid. H.264 mit seiner extremen Bitstream-Syntax ist ziemlich unübersichtlich ;)

 

Der Cyberlink-Decoder gibt in dem mit dem Videorenderer (VMR9) ausgehandelten Verbindungsformat allerdings auch nur 25 fps an (siehe GraphStudio).

Link to comment

Also Apple kodiert das Material zum Beispiel mit 720p bei 23.976 fps. Bei Kinomaterial verliert man da 0 an Bewegungsauflösung, spart aber enorm bei der Bandbreite. Unitymedia macht wahrscheinlich noch einen PAL Speedup. Für mich klingt das durchaus plausibel.

Link to comment

So, hier ist ein solches Sample von der Kamera:

http://www.uploadarea.de/files/18tifvhtz5dl6miuo2pjqvbzd.zip

 

 

Zur Zeit arbeite ich ohnehin an einem erweiterten Parsen von H.264 NAL Units, und dafür kann ich Testmaterial bestens gebrauchen.

Parst du dann auch die Filler Data (NAL unit type 12), so dass im DVBFilter evtl. die Bitrate ohne die Filler angezeigt werden kann oder am besten gleich bei Aufnahmen die Filler erst gar nicht mit aufgenommen werden? Das wäre natürlich super, wenn sowas später mal realisiert werden könnte :)

Link to comment
Also soweit ich weiß gibt es da so eine Art Flag das anzeigt, dass das Frame einfach verdoppelt wird, also damit aus den 25 fps des Spielfilms -> 50 fps werden, ohne jedes Frame doppelt zu codieren.

Vielleicht ist es ja so bei diesem Sender, dass die theoretische Framerate zwar 50 fps sind, aber praktisch jedes Frame nur einmal codiert ist, also mit 25 fps, und dann halt über diese Flag einfach nur verdoppelt wird?

 

Das macht ja wohl wenig sinn. Übertragen werden 25 (voll)bilder. Nimmt man 50fps an, ist man in der hälfte der zeit fertig :biggrin: Gerendert wird sowieso meist verdoppelt oder vervierfacht (200Hz) ;)

Link to comment

Also Apple kodiert das Material zum Beispiel mit 720p bei 23.976 fps. Bei Kinomaterial verliert man da 0 an Bewegungsauflösung, spart aber enorm bei der Bandbreite. Unitymedia macht wahrscheinlich noch einen PAL Speedup. Für mich klingt das durchaus plausibel.

Ja natürlich ist das besser für Kinomaterial. Aber was Apple macht ist doch erstmal nebensächlich wenn es um die Übertragung per DVB geht (also DVB-S, -C, -T). Ich dachte immer, da wären bei 720p die 50 fps vorgeschrieben...

Aber angeblich soll TNT Film HD sogar in 1080p 24p senden, also praktisch wie die Blurays. Nachvollziehen kann ich das leider nicht, da ich den Sender nicht abboniert habe (ist also für mich verschlüsselt). Wenn es aber wirklich so sein sollte, wäre das schon merkwürdig, da die 24 fps ja nicht einmal dem PAL Standard entsprechen ...

Link to comment
da die 24 fps ja nicht einmal dem PAL Standard entsprechen ...

DVD's sind auch PAL. Da wird ganz einfach das Material auf 25 fps beschleunigt. Ich könnte mir vorstellen, dass das über DVB aus Kompatibilitätsgründen so praktiziert wird.

 

Kinomaterial ist auch nicht 24 fps, sondern 23.976. Der Unterschied ist größer, als er auf den ersten Blick scheint. Spielt man 23.976 fps Material mit Originalgeschwindigkeit ab und gibt es auf ein 24 Hz Ausgabegerät aus, kommt es alle 43 Sekunden zu einem VSync überlauf, sprich Ruckler.

Link to comment

Das macht ja wohl wenig sinn. Übertragen werden 25 (voll)bilder. Nimmt man 50fps an, ist man in der hälfte der zeit fertig :biggrin: Gerendert wird sowieso meist verdoppelt oder vervierfacht (200Hz) ;)

Also ich habe das so verstanden, dass natürlich 50 fps übertragen werden (wie es bei 720p imho der Standard ist).

Bloß in jedem zweiten Frame steckt dann eben nur die Information drin "wiederhole das vorherige Frame", was sich dann sehr effizient codieren lässt und effektiv nur die halbe Bitrate (bei gleicher Qualität) benötigt als bei 50 Vollbildern.

Aber evtl. wird dies durch die Kompression mit Bewegungsvektoren usw. eh schon automatisch gemacht, wenn kein Unterschied zwischen zwei Bildern festgestellt wird. Bloß es ist dann eben so, dass in jedem zweiten Frame wirklich nur noch ein Bit oder so steht...

Edited by Martin K
Link to comment
Ich dachte immer, da wären bei 720p die 50 fps vorgeschrieben...

 

Es gibt gewisse profile und maximalwerte (was z.b. 1080p50 ausschliesst). 720p50 findet man nur noch bei den deutschen örs (und arte).

Link to comment
DVD's sind auch PAL. Da wird ganz einfach das Material auf 25 fps beschleunigt. Ich könnte mir vorstellen, dass das über DVB aus Kompatibilitätsgründen so praktiziert wird.

Das weiß ich doch alles. PAL Standard (bei uns in Europa üblich) sind nunmal 25 bzw. 50 fps.

Ob TNT Film HD wirklich in 24 fps sendet kann ich nicht bestätigen, aber wäre schon seltsam, da es nicht dem PAL entspricht...

 

Kinomaterial ist auch nicht 24 fps, sondern 23.976. Der Unterschied ist größer, als er auf den ersten Blick wirkt. Spielt man 23.976 fps Material ab und gibt es auf ein 24 Hz Ausgabegerät aus, kommt es alle 43 Sekunden zu einem VSync überlauf, sprich Ruckler.

Nö, Kino ist 24 fps.

Die werden nur für NTSC auf 23.976 fps verlangsamt, um einen 3:2 Pulldown machen zu können.

Sollte bei uns eigentlich nicht der Fall sein, da wir mit NTSC nix am Hut haben...

Ob die Blurays jetzt 24 oder 23.976 fps sind, weiß ich allerdings nicht.

Im Kino sinds jedenfalls 24!

Edited by Martin K
Link to comment

Es gibt gewisse profile und maximalwerte (was z.b. 1080p50 ausschliesst). 720p50 findet man nur noch bei den deutschen örs (und arte).

Meinst du damit jetzt H.264 allgemein oder das was bei uns so über DVB gesendet wird (also PAL)?

Imho gibt es da schon nochmal Einschränkungen, vor allem was die Framerate angeht. Da gibt es ja schon Unterschiede zwischen NTSC und PAL ...

Link to comment
Parst du dann auch die Filler Data (NAL unit type 12), so dass im DVBFilter evtl. die Bitrate ohne die Filler angezeigt werden kann

Hälst du mich für einen H.264-Decoder? :) Bislang kennt mein Code nur den Sequence Parameter Set. Zur Zeit versuche ich, mich etwas weiter vorzuarbeiten - mal schauen, wo das hinführt.

 

Das H.264 Bitstream-Format ist für Anwendungsprogrammierer äußerst anstrengend, um nicht zu sagen, eine Katastrophe. PES- und MPEG2-Header kann ich inzwischen mittels Hex-Editor sowie Papier und Bleistift parsen (teilweise sogar direkt im Hex-Editor lesen), aber H.264? Keine Chance. Da sind sogar die Header mit ExpGolomb-Codierung komprimiert. Zudem beißt sich das Format an allen Ecken und Enden mit der Intel-Prozessorarchitektur - eine Ausrichtung an Bytegrenzen gibt es praktisch nicht, sondern nur einen endlosen Bitstream - und man muss elementare Informationen wie Auflösung, Framerate oder Aspect Ratio mühsam aus anderen Angaben entschlüssseln. Das Format wurde eindeutig für eine Verarbeitung durch DSPs entwickelt, nicht für Feld-, Wald- und Wiesen-PCs.

 

Hier die Timing-Information aus deinem Kamera-Sample:

 

        -------------------- Timing Info Section
           num_units_in_tick = 1200
           time_scale = 120000
           fixed_frame_rate_flag = 1 -----> frame rate 50 fps
       --------------------

 

Was sagt uns das?

Link to comment

..da ich das doch nicht zu fuss parsen kann, bevorzuge in solchen fällen eine majority decision. Gucken, was Grigas parser sagt und dann mit mediainfo (oder was man sonst so hat) vergleichen. Mediainfo hat für die camera auch ne interessante meinung ;)

 

General
ID                               : 0 (0x0)
Complete name                    : G:\DVBViewer\TransEdit\00000.MTS
Format                           : BDAV
Format/Info                      : Blu-ray Video
File size                        : 8.47 MiB
Duration                         : 4s 654ms
Overall bit rate                 : 15.3 Mbps
Maximum Overall bit rate         : 18.0 Mbps

Video
ID                               : 4113 (0x1011)
Menu ID                          : 1 (0x1)
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.0
Format settings, CABAC           : No
Format settings, ReFrames        : 1 frame
Frame mode                       : Frame doubling
Codec ID                         : 27
Duration                         : 4s 640ms
Bit rate mode                    : Variable
Bit rate                         : 14.5 Mbps
Maximum bit rate                 : 16.6 Mbps
Width                            : 1 280 pixels
Height                           : 720 pixels
Display aspect ratio             : 16:9
Frame rate                       : 25.000 fps
Standard                         : NTSC
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.627
Stream size                      : 7.99 MiB (94%)

Audio
ID                               : 4352 (0x1100)
Menu ID                          : 1 (0x1)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Codec ID                         : 129
Duration                         : 4s 704ms
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Channel positions                : Front: L R
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Compression mode                 : Lossy
Stream size                      : 110 KiB (1%)

 

Frame doubling aber 25fps und NTSC?

Link to comment

Vielen Dank für eure Antworten!

 

Ich habe mich übrigens im Rahmen meiner Bachelorarbeit mit H.264 befasst. Da habe ich auch verschiedene Samples geparst und erstmal eine Übersicht gemacht, mit den verschiedenen NAL Unit Typen.

So sieht man dann auch ganz leicht, wie viele Filler Data z.B. Das Erste HD sendet.

Konkret ging es übrigens um die SVC Erweiterung. Das Parsen der SVC extension war eigentlich recht einfach, aber das Sequence Parameter Set zu parsen war mir auch zu aufwändig. Für die Informationen wie Auflösung und Framerate habe ich dann ein externes Programm verwendet.

 

 

Frame doubling

Das ist das selbe, was mir SUPER© auch ausspuckt. Intern verwendet der wahrscheinlich auch MediaInfo um an diese Informationen zu gelangen.

Interessant, die Angabe "Frame doubling", fällt mir jetzt erst auf. Wahrscheinlich ist es das was ich meinte, das Flag, das einfach die tatsächliche Framerate von 25 fps durch Verdopplung auf 50 fps bringt.

Jetzt müsste man nur noch wissen, wo diese Angabe steckt (auch im Sequence Parameter Set?)

Komischerweise wird bei "Kino HD" kein "Frame doubling" angezeigt (es taucht in der Ausgabe einfach nicht auf), obwohl ja auch hier 25 fps angezeigt werden...

Oder es ist bei "Kino HD" doch so wie von mir in einem vorigen Beitrag vermutet, dass zwar 50 Frames gespeichert werden, aber jedes zweite eben die Information hat, dass das vorherige verdoppelt wird.

Und bei der Kamera werden dann wirklich nur 25 Frames gespeichert und es gibt diese allgemeine Angabe "Frame doubling" im Header.

Aber das wäre auch wieder merkwürdig, da Griga mit seiner Methode bei dem "Kino HD" Sample ja auf 25 fps und bei der Kamera auf 50 fps gekommen ist... Es müsste dann ja genau umgekehrt sein...

 

Was sagt uns das?

Das wir mit der zusätzlichen Angabe "frame doubling" wieder auf 25 fps kommen? Ich weiß es nicht...

Aber letztenendes ist es ja auch nicht so wichtig was angezeigt wird, solange es nicht in Zeitlupe oder -raffer abgespeilt wird. Ist es mit der Angabe "Frames verdoppeln" so wie ich vermute, so kann man sich darüber streiten, was die "wirkliche Framerate" ist, 25 fps oder 50 fps ist dann irgendwie beides richtig ....?!?

 

aber 25fps und NTSC?

Ja, ist mir auch aufgefallen. Da haben die beim europäischen Modell wohl vergessen dieses Flag auf 'PAL' zu setzen. In den NTSC-Ländern wird die Kamera ja mit 30 bzw. 60 fps verkauft...

Link to comment

Wie Mediainfo darauf kommt? Dazu müsste man time_scale / num_units_in_tick durch 4 teilen.

MediaInfo ist unter GPL-Lizenz veröffentlicht, somit sollte es auch kein Problem sein, sich den Quellcode davon etwas näher anzuschauen.

Du kannst ihn hier herunterladen: http://mediainfo.sourceforge.net/de/Download

 

Folgendes hab ich auf die Schnelle in der Klasse File_Avc.cpp unter 'MediaInfoLib\Source\MediaInfo\Video' gefunden:

 

   if (timing_info_present_flag)
   {
       if (!fixed_frame_rate_flag)
           Fill(Stream_Video, StreamPos_Last, Video_FrameRate_Mode, "VFR");
       else if (time_scale && num_units_in_tick)
           Fill(Stream_Video, StreamPos_Last, Video_FrameRate, (float)time_scale/num_units_in_tick/(frame_mbs_only_flag?2:(pic_order_cnt_type==2?1:2))/FrameRate_Divider);
   }

 

Na, was hältst du davon?

 

Ich denke mal, für dich sollte sich ein Blick in den Quellcode auf jeden Fall lohnen ;)

Link to comment

Die letzte Codezeile kannst du mal in etwas Verständliches übersetzen. Da fehlen mir Fremdsprachenkenntnisse. Und die Interpretation sowie weiteres Forschen im Code überlasse ich auch gerne dir :)

 

Die Variablen frame_mbs_only_flag und pic_order_cnt_type tauchen beide im Sequence Parameter Set auf:

 

Kamera-Sample:

frame_mbs_only_flag = 1 (nur coded frames, also keine fields -> progressive).

pic_order_cnt_type = 2

 

Kino HD-Sample

frame_mbs_only_flag = 1

pic_order_cnt_type = 0

 

Das Erste HD

frame_mbs_only_flag = 1

pic_order_cnt_type = 0

 

Die Erläuterungen zu pic_order_cnt_type in den Spezifikationen sind so lang und kompliziert, dass ich einfach mal kapituliere... die H.264-Semantik möchte ich nicht bis ins letzte Detail ergründen, das würde Monate dauern. Ein Parser muss im Grunde nur die Syntax beherrschen.

 

Ich nehme an, dass die Ermittlung der Framerate im DVBViewer bei der Wiedergabe via DirectShow keine praktische Bedeutung hat, da der Videorenderer den Zeitpunkt der Darstellung anhand der vom Decoder gelieferten Zeitstempel bestimmt. Ich kann z.B. die Framerate im TSPlayer mit 10 oder 200 fps hardcoden, worauf der DVBViewer Filter diese Information beim Verbinden dem Cyberlink Decoder übergibt, und dieser wiederum dem Videorenderer, wie GraphStudio zeigt. Die Auswirkungen auf die Wiedergabe sind hier = 0. Eigentlich schade - wäre es anders, hätte man ein einfaches Mittel in der Hand, um verschiedene Wiedergabegeschwindigkeiten zu inszenieren.

 

Eine korrekte Angabe der Framerate im UI ist natürlich ein "nice to have", aber offenbar nicht mehr.

Link to comment
Die letzte Codezeile kannst du mal in etwas Verständliches übersetzen. Da fehlen mir Fremdsprachenkenntnisse. Und die Interpretation sowie weiteres Forschen im Code überlasse ich auch gerne dir

Hmm, C ist doch eigentlich gar nicht so schwer...

Also erstmal allgemein:

Ein boolscher Ausdruck (also eine if-Bedingung) kann in C auch einfach ein Zahlenwert (z.B. ein Integer) sein, der Ausdruck ist einfach dann true, wenn er ungleich 0 ist.

Das heißt, die Framerate wird nur dann nach dieser Formel berechnet, wenn "timing_info_present_flag", "fixed_frame_rate_flag", "time_scale" und "num_units_in_tick" alle ungleich 0 sind.

"Fill(...)" befüllt wohl das Datenkonstrukt, das dann bei der Ausgabe ausgegeben wird, mit den entsprechenden Werten.

Im ersten Fall wird also der "Video_FrameRate_Mode" auf "VFR" gesetzt.

 

Für uns interessant, ist ja nur die Berechnung der Framerate.

"(float)" castet den Wert auf einen float (32 Bit Gleitkommazahl), da sonst eine Ganzzahldivision (mit abgeschnittenen Nachkommastellen) durchgeführt werden würde (weil sowohl time_scale als auch num_units_in_tick und alle anderen Werte Ganzzahlen sind).

Das Konstrukt (<boolscher Ausdruck>?<wert1>:<wert2>) ist nur ein vereinfachtes if:

<wenn dieser Ausdruck wahr ist>?<dann verwende diesen Wert>:<ansonsten diesen>

 

Im obigen Fall haben wir dieses Konstrukt verschachtelt ineinander, also im else-Fall des ersten vereinfachten if-Konstruktes befindet sich nochmal ein vereinfachte if-Konstrukt.

 

Lange Rede, kurzer Sinn, was du konkret wissen willst:

time_scale/num_units_in_tick/(frame_mbs_only_flag?2:(pic_order_cnt_type==2?1:2))/FrameRate_Divider

"time_scale/num_units_in_tick" sollte ja klar sein.

Wenn das "frame_mbs_only_flag" ungleich 0 ist, wird das ganze durch 2 geteilt.

"pic_order_cnt_type" ist also nur relevant, wenn "frame_mbs_only_flag" 0 ist. In diesem Fall wird das ganze durch 1 (pic_order_cnt_type = 2) bzw. durch 2 (für allen anderen Werte von pic_order_cnt_type) geteilt.

Dann wird das ganze noch durch FrameRate_Divider geteilt.

 

FrameRate_Divider ist übrigens das, was in der Ausgabe als "Frame mode" ausgegeben wird.

Standardmäßig wird dieser Wert mit 1 initialisiert.

 

Ansonsten kann er noch die Werte 2 (Frame doubling) und 3 (Frame tripling) annehmen.

Siehe dazu im Code:

    if (FrameRate_Divider==2)
   {
       Fill(Stream_Video, StreamPos_Last, Video_Format_Settings_FrameMode, "Frame doubling");
       Fill(Stream_Video, StreamPos_Last, Video_Format_Settings, "Frame doubling");
   }
   if (FrameRate_Divider==3)
   {
       Fill(Stream_Video, StreamPos_Last, Video_Format_Settings_FrameMode, "Frame tripling");
       Fill(Stream_Video, StreamPos_Last, Video_Format_Settings, "Frame tripling");
   }

Frame doubling bzw. tripling wird folgendermaßen ermittelt:

    if (pic_struct_present_flag)
   {
       Get_S1 (4, pic_struct,                                  "pic_struct");
       switch (pic_struct)
       {
           case  0 :
           case  1 :
           case  2 :
           case  3 :
           case  4 :
           case  5 :
           case  6 : break;
           case  7 : FrameRate_Divider=2; break;
           case  8 : FrameRate_Divider=3; break;
           default : Param_Info("Reserved"); return; //NumClockTS is unknown
       }
       ...

Das "pic_struct" ist im SEI payload (also nicht mehr im Sequence Parameter Set) zu finden, siehe 'Rec. ITU-T H.264' Annex D.

Der switch-case Block ist übrigens auch eine Art vereinfachtes if, das die verschiendenen Werte, die in desem Fall "pic_struct" annehmen kann, einzeln durch geht.

Also wenn pic_struct = 7 ist, wird FrameRate_Divider auf 2 gesetzt, wenn pic_struct = 8 ist, auf 3.

 

 

Mal vom dem FrameRate_Divider abgesehen, sollte deine aktuelle Implementierung doch nicht großartig von dieser abweichen? Zumindest kommen die selben Frameraten dabei raus...

Bei dem Kamera-Sample müsste dann FrameRate_Divider 2 sein (siehe Derricks Beitrag).

 

 

Übrigens, du kannst auch einfach die MediaInfo DLL verwenden, um die Framerate auszulesen ;)

 

 

 

Ich nehme an, dass die Ermittlung der Framerate im DVBViewer bei der Wiedergabe via DirectShow keine praktische Bedeutung hat, da der Videorenderer den Zeitpunkt der Darstellung anhand der vom Decoder gelieferten Zeitstempel bestimmt. Ich kann z.B. die Framerate im TSPlayer mit 10 oder 200 fps hardcoden, worauf der DVBViewer Filter diese Information beim Verbinden dem Cyberlink Decoder übergibt, und dieser wiederum dem Videorenderer, wie GraphStudio zeigt. Die Auswirkungen auf die Wiedergabe sind hier = 0. Eigentlich schade - wäre es anders, hätte man ein einfaches Mittel in der Hand, um verschiedene Wiedergabegeschwindigkeiten zu inszenieren.

Da habe ich auch mal etwas erlebt:

Ich wollte ein Video von der Kamera (mit dieser Angabe: "1.280 x 720, 50p [CCD-Ausgabe 25p]") mal bei YouTube hochladen. Vorher hatte ich es aber noch in den MKV Container verpackt. Da muss man dann als Parameter noch die Framerate angeben (anscheinend haben die sich auch das entsprechende Parsen im H.264 Stream gespart). Also habe ich 50 fps angegeben und meine Programme spielten das MKV File auch alle korrekt ab.

Also dachte ich mir nix dabei und habe es so bei YouTube hochgeladen. Doch da wurde es dann plötzlich im Zeitraffer (also doppelt so schnell) abgespielt...

Das heißt, meine Programme haben auch alle die Framerate-Angabe im MKV Container ignoriert.

Link to comment
Da habe ich auch mal etwas erlebt:

Ich wollte ein Video von der Kamera (mit dieser Angabe: "1.280 x 720, 50p [CCD-Ausgabe 25p]") mal bei YouTube hochladen. Vorher hatte ich es aber noch in den MKV Container verpackt. Da muss man dann als Parameter noch die Framerate angeben (anscheinend haben die sich auch das entsprechende Parsen im H.264 Stream gespart). Also habe ich 50 fps angegeben und meine Programme spielten das MKV File auch alle korrekt ab.

Also dachte ich mir nix dabei und habe es so bei YouTube hochgeladen. Doch da wurde es dann plötzlich im Zeitraffer (also doppelt so schnell) abgespielt...

Das heißt, meine Programme haben auch alle die Framerate-Angabe im MKV Container ignoriert.

 

Der kunde ist könig. Du wolltest, dass es mit 50fps (nach rekodierung) abgespielt wird. Damit hast du genau den fall, den ich weiter oben beschrieben hatte :D

Link to comment

Kinomaterial ist auch nicht 24 fps, sondern 23.976. Der Unterschied ist größer, als er auf den ersten Blick scheint. Spielt man 23.976 fps Material mit Originalgeschwindigkeit ab und gibt es auf ein 24 Hz Ausgabegerät aus, kommt es alle 43 Sekunden zu einem VSync überlauf, sprich Ruckler.

 

Da widerspreche ich einfach mal. Filme, die für die Verwertung im Kino gedreht werden, werden unverändert in 24fps gefilmt. Erst bei der Digitalisierung und dem Transfer auf eine Bluray wird meistens jedes 1001. Frame weggelassen, um auf 23,97602... fps zu kommen. Dieser Frame-Drop ist aber auch nur dann zwingend erforderlich, wenn der Film auf der BD in einem NTSC Land wie den USA vermarktet werden soll. Bei BDs, die nur in Europa vermarktet werden sollen, wird der Frame-Drop teilweise nicht vegenommen; diese Filme sind dann tatsächlich mit 24fps auf der BD. Ein Beispiel hierfür ist diese Version von "Dune" http://www.bluray-disc.de/blu-ray-filme/dune-der-wuestenplanet-blu-ray-disc, dort ist der Film in 24fps auf der BD.

 

Edit: Jetzt sehe ich gerade, daß Martin K. schneller war und schon auf den Irrtum von Cinch hingewiesen hatte.

 

C.U NanoBot

Edited by NanoBot
Link to comment

Da widerspreche ich einfach mal. Filme, die für die Verwertung im Kino gedreht werden, werden unverändert in 24fps gefilmt. Erst bei der Digitalisierung und dem Transfer auf eine Bluray wird meistens jedes 1001. Frame weggelassen, um auf 23,97602... fps zu kommen. Dieser Frame-Drop ist aber auch nur dann zwingend erforderlich, wenn der Film auf der BD in einem NTSC Land wie den USA vermarktet werden soll. Bei BDs, die nur in Europa vermarktet werden sollen, wird der Frame-Drop teilweise nicht vegenommen; diese Filme sind dann tatsächlich mit 24fps auf der BD. Ein Beispiel hierfür ist diese Version von "Dune" http://www.bluray-disc.de/blu-ray-filme/dune-der-wuestenplanet-blu-ray-disc, dort ist der Film in 24fps auf der BD.

 

Edit: Jetzt sehe ich gerade, daß Martin K. schneller war und schon auf den Irrtum von Cinch hingewiesen hatte.

 

C.U NanoBot

Trotzdem danke für deinen Beitrag!

Mit Blurays bin ich (noch) nicht so bewandert...

Heißt das dann, dass alle Blurays, die auch in den USA verkauft werden, hier 23,976 fps haben?

 

Und ist es wirklich so, dass jedes 1001. Frame weggelassen (hmm, müsste es nicht eher verdoppelt werden?) wird, oder wird das - ähnlich wie beim PAL Speedup - einfach nur entsprechend verlangsamt?

Edited by Martin K
Link to comment

Hi,

 

wenn der gleiche Transfer als Grundlage für eine BD genutzt werden soll, die in PAL-Land und NTSC-Land verkauft werden soll, dann muß dieser Transfer mit der Korrektur auf 23,97602... gemacht werden. Wird dagegen für die "PAL" Bluray und die "NTSC" Bluray jeweils ein seperater Transfer vorgenommen, dann kann der erste wahlweise 24fps oder 23,97602... fps sein, wäre die Version für NTSC-Land 23,97602 fps haben muß. Es ist also durchaus denkbar, daß es den gleichen Filmtitel in Europa vom Publisher "A" in 24fps gibt, während die Version in den USA vom Publisher "B" in 23,97602fps ist. In der Praxis gibt es in Europa leider noch eine dritte Transfermethode, welche ich hauptsächlich bei französischen Publishern gesehen habe: Die machen doch tatsächlich während des Transfers einen Speedup von 24fps auf 25fps und encoden es dann als 1080i50 in "pseudo-interlace", bevor sie es auf die BD packen. Diese Methode finde ich fürchterlich.

 

Der Grund für die Anpassung von 24fps auf 23,97602fps liegt an einer Besonderheit des US TV-Systems bei der Umstellung von s/w auf Farbe. Ein US-TV für s/w hatte eine Framerate von 30fps, während ein europäisches s/w TV-Gerät 25fps hatte. Bei der Umstellung auf Farb-TV brauchte man nun am Anfang jeder Zeile hinter dem Synchronimpuls und der Schwarzschulter etwas "Platz" um dort den Farbburst als Referenzsignal unterbringen zu können. Dies konnte auf zwei Arten realisiert werden: Entweder wird die horizontale Auflösung pro Zeile verringert, in dem man den Bereich der Zeile, in dem die eigentliche Bildinformation liegt, zeitlich etwas verkürzt. In dem freiwerdenen Bereich hinter dem H-Sync und der Schwarzschulter plaziert man dann den Farbburst, wie es beim PAL-System gemacht wurde. Bei dieser Methode bleibt die Framerate unverändert, allerdings kann es theoretisch passieren, daß der Farbburst am ganz linken Rand des Bildes eines s/w-Gerätes als Störung sichtbar wird. Nun waren aber die meisten TV-Geräte ohnehin so eingestellt, daß der ganz linke und ganz rechte Rand des Bildes sowieso nicht zu sehen war ( overscan ), so daß man auf älteren TV-Geräten den Farbburst meistens nicht gesehen hat. Bei neueren s/w-Geräten wurde dann während der Übergangszeit ein Sperrfilter für 4,43MHz, also die Frequenz des PAL-Farbbursts, eingebaut, so daß die Abwärtskompatibilität gewährleistet war.

 

Beim NTSC-System war dieser Weg aber nicht gangbar, weil Interferenzen zwischen den Oberwellen der Zeilenfrequenz, des Farbhilfsträger und des Tonträger zu befürchten waren. Stattdessen hat man die Bild- und Zeilenwiederholfrequenz im Verhältnis 1001/1000 verringert, was die bekannte Framerate von 29,9700.. fps ergibt. Durch die geringere Frequenz ist eine Zeile zeitlich gesehen jetzt etwas länger als bei 30fps, und der gewonnene Platz wurde für den Farbburst verwendet. Genaueres findet sich hier: http://de.wikipedia.org/wiki/National_Television_Systems_Committee#Bildwiederholrate

 

Um nun den Inhalt einer BD ( oder HD-DVD ) auf einem herkömmlichen US Röhren-TV abspielen zu können, wurde für die BD/HD-DVD die Rate von 23,97602...fps gewählt, welche bei Bedarf, wie du schon selber geschrieben hast, per 3:2 Pulldown auf 29,9700...fps telecined wird. In Europa hätte dies aber keinen Sinn gemacht, da ein Pulldown von 24fps auf 25fps, um eine BD/HD-DVD auf einem Röhren-TV abspielen zu können, absolut keinen Sinn machen wurde. Die hierbei entstehenden Ruckler wären ja unübersehbar. Daher wurde für den Markt in PAL-Ländern von Anfang an vorrausgesetzt, daß ein BD- oder HD-DVD Player nur zusammen mit einem HD-tauglichen Flachbild-TV genutzt werden würde. Und da diese Geräte bezüglich der Framerate viel flexibler als ein Röhrengerät sind, können sie unter anderem auch 23,97602fps, als auch 24fps abspielen, wenn man mal von den Geräten der ersten Generation absieht, die noch nicht 24p tauglich waren.

 

Der Wechsel von 24fps auf 23,97602fps wird so realisiert, daß der Film tatsächlich um ca. 1 Promille langsamer, nämlich mit 23,97602fps, abgespielt wird. Hierdurch käme es einerseits natürlich zu einer anwachsenden Asynchronität zwischen Bild und Ton, und andererseits wird die Laufzeit des Filmes gegenüber der Kinofassung etwas länger. Um die Synchronität zu erhalten, könnte man entweder den Ton seinerseits entsprechend resamplen, so daß er wieder zur fps-Rate des Bildes passt. Dies war aber zum Zeitpunkt der Einführung des NTSC-Farbsystemes nicht so einfach möglich, weil es ja noch keine Computer gab, die hierfür schnell genug gewesen wären. Natürlich hätte man auch die Laufzeit des Tons anpassen können, indem man ihn von einem Tonbandgerät auf ein zweites mit entsprechend angepasster Geschwindigkeit umkopiert hätte. Eine analoge Kopie des Tons hätte aber zwangsläufig eine Qualitätsverschlechterung bedeutet, denn Rauschunterdrückungssysteme wie Dolby gab es damals auch noch nicht.

 

Daher hat man die Alternative genutzt, nämlich einfach jedes 1001. Frame wegzulassen. Hierdurch werden ca. alle 41 Sekunden das Bild und der Ton neu synchronisiert, denn 1001 Frames bei 24fps haben die gleiche Laufzeit wie 1000 Frames bei 23,97602fps. Da ein Frame bei 23,97602fps eine Dauer von 41,7083..mS hat, wird man die zwischenzeitlich enstehende maximale Asynchronität in der Praxis nicht bemerken.

 

C.U. NanoBot

Link to comment

Vielen Dank für deine ausführliche Erklärung, NanoBot!

 

In der Praxis gibt es in Europa leider noch eine dritte Transfermethode, welche ich hauptsächlich bei französischen Publishern gesehen habe: Die machen doch tatsächlich während des Transfers einen Speedup von 24fps auf 25fps und encoden es dann als 1080i50 in "pseudo-interlace", bevor sie es auf die BD packen. Diese Methode finde ich fürchterlich.

Das wäre doch aber die einzig korrekte Methode mit einer PAL-Framerate. Für die HDTV-Sender gibt es imho nur diese Methode, bei SD ist es ja genauso.

 

Um die Synchronität zu erhalten, könnte man entweder den Ton seinerseits entsprechend resamplen, so daß er wieder zur fps-Rate des Bildes passt. Dies war aber zum Zeitpunkt der Einführung des NTSC-Farbsystemes nicht so einfach möglich, weil es ja noch keine Computer gab, die hierfür schnell genug gewesen wären. Natürlich hätte man auch die Laufzeit des Tons anpassen können, indem man ihn von einem Tonbandgerät auf ein zweites mit entsprechend angepasster Geschwindigkeit umkopiert hätte. Eine analoge Kopie des Tons hätte aber zwangsläufig eine Qualitätsverschlechterung bedeutet, denn Rauschunterdrückungssysteme wie Dolby gab es damals auch noch nicht.

Aber in Europa wurde das doch schon immer so gemacht (PAL-Speedup). Deshalb ist die Tonhöhe hier auch etwas höher.

Edited by Martin K
Link to comment
Das Konstrukt (<boolscher Ausdruck>?<wert1>:<wert2>) ist nur ein vereinfachtes if:

<wenn dieser Ausdruck wahr ist>?<dann verwende diesen Wert>:<ansonsten diesen>

Danke für die Erläuterung und sonstige Recherchen. Das hilft weiter. C kann ich einigermaßen lesen, aber wenn dann plötzlich Fragezeichen mitten im Code auftauchen, erscheint mir das fragwürdig :)

 

BTW: Hättest du Lust, hier noch weitere Aufgaben zu übernehmen? o:)

 

Übrigens, du kannst auch einfach die MediaInfo DLL verwenden, um die Framerate auszulesen

Wie bitte? Die ganze DLL laden und sich in eine solche Abhängigkeit begeben, nur um einen relativ bedeutungslosen Wert zu ermitteln?

 

Jedenfalls muss ich meinen Ansatz noch mal neu überdenken. Bei MPEG2 liest man den Sequence Header, und dann hat man alles, was man braucht. Bei H.264 verteilt es sich dagegen über verschiedene NAL Units, zwischen denen diverse Abhängigkeiten bestehen. Sie isoliert lesen und dann vergessen funktioniert nicht ;)

Link to comment
BTW: Hättest du Lust, hier noch weitere Aufgaben zu übernehmen? o:)

Na klar! Also ein grundsätzliches Interesse an dem Thema habe ich immer :)

Zur Zeit bin ich zwar schon etwas ausgelastet und im Sommer werde ich vorrausichtlich mit der Masterarbeit beginnen, aber wie gesagt Lust hätte ich immer und es finden sich ja auch immer wieder freie Stunden zwischendurch...

 

Wie bitte? Die ganze DLL laden und sich in eine solche Abhängigkeit begeben, nur um einen relativ bedeutungslosen Wert zu ermitteln?

Ich meine, ich hätte die DLL schonmal im DVBViewer Verzeichnis gesehen, habe aber jetzt grade keinen Zugriff auf meinen Heimrechner und kann auch nicht sagen, von welchem Plugin sie evtl. dort gelandet ist.

Vom DVBSource war sie dann wohl nicht...

Aber hast schon recht, man sollte sich immer unabhängig machen :D

Link to comment

Heißt das dann, dass alle Blurays, die auch in den USA verkauft werden, hier 23,976 fps haben?

Wie die genaue Verteilung zwischen 23,976 und 24,000 Blurays ist weiss ich auch nicht genau, aber 23,976 ist auch auf hier erhältichen blurays stark verbreitet.

Die Unterscheidung halt ich daher für nicht unwichtig, da z.B. Plugins für die richtige framerate ( http://www.DVBViewer.tv/forum/topic/31401-video-frame-rate-switcher/ ) hier ansetzen können.

Aktuelle Grakas (Ati 5er Serie) bieten deshalb auch die 23,976hz Ausgabe an.

 

MPC-HC kann das z.B. und gleich automatisch die richtige Framerate setzen: http://www.DVBViewer.tv/forum/topic/31401-video-frame-rate-switcher/page__st__40

Ab vista ist auch 23,976 möglich. :)

 

P.S. Danke an NanoBot für die ausführliche Erklärung.

Edited by nuts
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...