Zur allgemeinen Klärung, da mir Leute öfter mal die Frage stellen. (nichts gegen Dich)
Ist immer wieder schön, wenn irgendjemand sagt, dass er einen cbr Videostream als Anforderung von XY erstellen muss.
'Problem' daran ist, dass ein MPEG basierter Videostream nicht cbr sein kann. (-> MPEG Grundlagen lesen und verstehen.)
=> Sie Anforderung als solche ist i.d.R. einfach unsinnig (oder zumindest sehr unglücklich formuliert) oder der Aufgabensteller ist entweder ein Schelm oder weiß nicht was er sagt.
i.d.R. wollen die Leute entweder:
a. einen video stream der für ein gewisses Endgerät kompatible ist. In diesem Fall sind die richtigen VBV Einstellungen, das was man will.
oder
b. 'bitrate stuffing', was mir sinnigerweise auch nur untergekommen ist wenn es Material geht, was an uralte (oder grottich schlechte) Hardware geschickt wird. (alte Fernseh--Satelitten und Software hatte solche Beschränkungen) -> VBV ist eigentlich das bessere Konzept.
Vermute außerdem, dass MediaInfo da nicht so ganz korrekt ist, denn bei einem Stream der mit:
(siehe 'without_stuffing')
encoded wurde und bei dem Multiplexen mit tsMuxer '--cbr --bitrate=1000.000 --vbv-len=500' verwendet wurde. (siehe: 'with_stuffing')
Zeigt MediaInfo bei mir:
Und zumindest die maxium overall bit rate erscheint mir doch etwas hoch. 
Cu Selur
Ps.: Hier was die x265 Authoren dazu meinen: https://bitbucket.org/multicoreware/x265...o-with-cbr
PPs.: Persönlich würde ich bei einer solchen Anforderung:
x265 mit '--bitrate X --strict-cbr --vbv-maxrate X --vbv-bufsize X' verwenden und sicher stellen, dass X + audio bitrate knapp unter der gewünschten Datenrate liegt.
PPPs.: wenn jemand eine Methode weiß wie man mit ffmpeg oder tsMuxeR so multiplexen kann, dass MediaInfo cbr angibt, dann kann ich dafür gerne ne Option einbauen.
PPPPs.: gerade gesehen, hab beim 'with_stuffing' als frame rate für den container 23.976 angegeben, was aber nichts am Ergebnis bzw. der Aussage ändert.
Ist immer wieder schön, wenn irgendjemand sagt, dass er einen cbr Videostream als Anforderung von XY erstellen muss.
'Problem' daran ist, dass ein MPEG basierter Videostream nicht cbr sein kann. (-> MPEG Grundlagen lesen und verstehen.)
=> Sie Anforderung als solche ist i.d.R. einfach unsinnig (oder zumindest sehr unglücklich formuliert) oder der Aufgabensteller ist entweder ein Schelm oder weiß nicht was er sagt.
i.d.R. wollen die Leute entweder:
a. einen video stream der für ein gewisses Endgerät kompatible ist. In diesem Fall sind die richtigen VBV Einstellungen, das was man will.
oder
b. 'bitrate stuffing', was mir sinnigerweise auch nur untergekommen ist wenn es Material geht, was an uralte (oder grottich schlechte) Hardware geschickt wird. (alte Fernseh--Satelitten und Software hatte solche Beschränkungen) -> VBV ist eigentlich das bessere Konzept.
Quote:Gibt es eine Möglichkeit, dies zu realisieren?In Hybrid aktuell nicht, da ich nur geringen Sinn in bitrate stuffing bis dato gesehen habe und mich deshalb nie groß damit beschäftigt habe.
Vermute außerdem, dass MediaInfo da nicht so ganz korrekt ist, denn bei einem Stream der mit:
--bitrate 500 --strict-cbr --vbv-maxrate 500 --vbv-bufsize 500encoded wurde und bei dem Multiplexen mit tsMuxer '--cbr --bitrate=1000.000 --vbv-len=500' verwendet wurde. (siehe: 'with_stuffing')
Zeigt MediaInfo bei mir:
Overall bit rate mode : Variable
Overall bit rate : 1 053 kb/s
Maximum Overall bit rate : 35.5 Mb/sCu Selur
Ps.: Hier was die x265 Authoren dazu meinen: https://bitbucket.org/multicoreware/x265...o-with-cbr
PPs.: Persönlich würde ich bei einer solchen Anforderung:
x265 mit '--bitrate X --strict-cbr --vbv-maxrate X --vbv-bufsize X' verwenden und sicher stellen, dass X + audio bitrate knapp unter der gewünschten Datenrate liegt.
PPPs.: wenn jemand eine Methode weiß wie man mit ffmpeg oder tsMuxeR so multiplexen kann, dass MediaInfo cbr angibt, dann kann ich dafür gerne ne Option einbauen.
PPPPs.: gerade gesehen, hab beim 'with_stuffing' als frame rate für den container 23.976 angegeben, was aber nichts am Ergebnis bzw. der Aussage ändert.
