11 ответов в этой теме

[prostovova]

Сразу прошу прощения - возможно не в той ветке вопрос, но здесь самые свежие посещения

 

Коллеги, я же правильно понимаю, что:

размер файла(Mb)=битрейт(Mb/Sec)*хронометраж(Sec)  ???

 

Тогда почему имею:

2 ролика 35 секунд (1280*720, 16:9)

№1 (16.5 MiB) 17 353 158 байт

Video: MPEG4, CBR 4000 kb/s, Звук: VBR 126kb/s, 44.1 kHz

#2 (15.8 MiB) 16 559 587 байт

Video: Windows Media, CBR 6000 kb/s, Звук: VBR 314kb/s, 44.1 kHz

 

То есть с меньшим битретом, даже больше, а по сути равны, хотя должны отличаться в полтора раза

при этом:

(4000+126)*35/8=18 051

(6000+314)*35/8=27 624

[Malcev]

Различие размеров наверняка связано из-за муксинга.
Можно проверить посмотрев через медиаинфо размеры потоков.

[prostovova]

Ну вообще то я и говорю, что размеры должны быть разными, причем существенно.

 

Про размеры потоков медиаинфо говорит, еще более интересные вещи:

 

Video: MPEG4

Stream size                 : 15.9 MiB (96%)

 

Video: Windows Media

Stream size                 : 25.4 MiB

 

Это, кстати ровно ложиться на мое представление о разнице в полтора раза

Но файлы то практически одинакового размера! Почему?

[Malcev]

А у wmv как я понял, вообще не может быть постоянного битрейта.
Поэтому и результат такой.
 

Constant Bit Rate Encoding

The bit rate for any stream encoded by one of the Windows Media Audio and Video codecs is not constant. Constant bit rate (CBR) encoding is, therefore, a somewhat misleading term. The distinguishing feature of a CBR-encoded stream is a small buffer window, which limits the variation of sample sizes. CBR encoding is used primarily for content that is streamed over a network to its destination. In such a scenario, it is important to be able to rely on consistent bandwidth usage.

From a configuration point of view, CBR encoding differs from the other modes in that before starting to encode, you set both the average bit rate of the output content, and the buffer window that applies to that bit rate. In other modes, one or both of those values is unknown when you configure the encoder, and is computed by the codec while it encodes. CBR is the standard encoding mode used by the Windows Media Encoder DMOs.

https://msdn.microso...5(v=vs.85).aspx
И то, что вы указываете у wmv CBR 6000 kb/s - означает, что максимальный битрейт потока не будет превышать 6000 kb/s.

Сообщение отредактировано Malcev: 05 Oct 2017 - 17:21

[prostovova]

То есть получается, что CBR в применении к WMV, это тот же VBR только с жестко заданным потолком?

Ну предположим, что когда я задаю этот параметр кодировщику он именно  так это и поймет

А при вытягивании этой инфы из уже готового файла при помощи медиаинфо подозрительно  ровная цифра получается, или она где то в заголовке файла прячется?

[Malcev]

То есть получается, что CBR в применении к WMV, это тот же VBR только с жестко заданным потолком?

По ссылке, что я привел всё расписано с примером модели как и что происходит.
Инфа берется из тагов в хедере.

[iliuxa]

постоянный битрейт не гарантирует постоянный размер - две разные картинки с одним битрейтом будут занимать разное место.

все зависит от количества деталей, количества цветов и их насыщенности

[Malcev]

illuxa, почему же?
Например на ffmpeg будет одинаковый размер вот так:

ffmpeg -i <input> -r 25 -c:v libx264 -x264opts nal-hrd=cbr:force-cfr=1 -b:v 2500k -minrate 2500k -maxrate 2500k -bufsize 100k output.ts

[iliuxa]

 

illuxa, почему же?
Например на ffmpeg будет одинаковый размер вот так:

ffmpeg -i <input> -r 25 -c:v libx264 -x264opts nal-hrd=cbr:force-cfr=1 -b:v 2500k -minrate 2500k -maxrate 2500k -bufsize 100k output.ts

то есть ты хочешь сказать что если по такой команде я зажму 1 минуту черного поля и 1 минуту ряби вол на море на выходе будет одинаковый размер?, что то сомневаюсь - в h264 не только макроблоками жмется картинка, но еще и учитываются векторы движения и пространственная избыточность, а так же цветовая. В первом случае между опорными кадрами будет практически отсутствовать инфа из за ее одинаковости, а во втором и в самих опорных кадрах и между ними будет поболее инфы

[Malcev]

Чтобы в этом убедиться ты можешь сам попробовать.
В премьере такое же добиться можно выбрав формат mpeg2 и выставить cbr в мультиплексере, либо h.264-blu-ray и выбрать в мультиплексере TS.

Вот тут можно почитать:

http://slhck.info/vi...te-control.html

Сообщение отредактировано Malcev: 06 Oct 2017 - 02:20

[prostovova]

"выбрав формат mpeg2 и выставить cbr в мультиплексере"

Вот и я про то

При кодировании для DVD, будущий размер файла можно было прекрасно рассчитать и тогда CBR был CBR, и арифметика сходилась.

А по поводу черного поля и морской ряби с одинаковым битрейтом ... ну что же значит такая рябь получится на выходе. Аразмер итогового файла должен быть одинаковым, иначе это не CBR.

 

"между опорными кадрами будет практически отсутствовать инфа из за ее одинаковости, а во втором и в самих опорных кадрах и между ними будет поболее инфы"

означает только, что опорные кадры будут меньше жаться, Черный квадрат в TIFF, то же будет весить больше чем в JPG/ Опорные кадры ведь то же жмутся и вот будет он JPG с максимfльным сжатием или TIFF и определит итоговые и качество и размер файла

 

Что касается исходного посыла про WMV и MPEG4 ролики разного размера (WMV меньше), могу предположить, что кодированный файл дополнительно "дожимается" каким ни будь "архиватором"

Поэтому то размер потока видео в WMV больше размера того же потока в MPEG4 при почти одинаковых размерах файлов.

Но это уже  моя кофейная гуща

 

А ссылка http://slhck.info/vi...te-control.html вижу, что интересная...надо будет в транслятор закинуть 

В чем еще проблема.

Рассматриваемые варианты кодирования подразумевают в итоге муки выбора между качеством, скоростью кодирования и скоростью потока (для он лайн сервисов и потоковой передачи).

К сожалению все как то позабыли еще о возможностях железа и софта по обратному разворачиванию сжатой информации.

Например для компьютеров типа Intel Pentium (а то и ION/ATOM) под управлением Windows XP ( типа: HP Dx 7300 MT PD 945 80G 1.0G 4 PC) это важно.

Кстати в указанной статье такой сценарий не рассматривается.

Просто у меня парк из около 500 таких машин, которые занимаются этим. А файлики к ним прилетают, в том числе, по проблемным мобильным каналам.

То есть тут и размер и качество и нагрузка на железо 

 

Пробежался еще раз по статье. Именно, что по каждому примеру кодирования даются оценки (хорошо для: / плохо для: ) и в этих оценках нет чего нибудь типа: "хорошо для уменьшения нагрузки на вычислитель"

Сообщение отредактировано prostovova: 06 Oct 2017 - 11:24

[Malcev]

Посмотрите реальный размер потока у wmv и mp4 с помощью bitrateviewer, тогда уже можно будет делать какие-либо выводы.

Если хотите чтобы Черный квадрат в TIFF весил почти как jpg, то можно в виндовсе нажать пропертис и исправить дату съёмки - виндовс автоматом подотрет всю лишнюю информацию.

Сомневаюсь, что сейчас вообще разработчиков волнует, как будет что-либо работать на Pentium Windows XP.

Но вы можете обратиться с подобным вопросом к автору статьи - как я понял, он не против поделиться знаниями.

Сообщение отредактировано Malcev: 06 Oct 2017 - 13:03