Кодирование видео в H264 (часть 3)
Вторая часть была тут. Её надо прочитать, иначе может быть непонятно всё, начиная с терминов.
Поехали про опции. Вот раздел мануала mencoder с моими комментариями для кодирования x264
x264enc (−x264encopts)
bitrate=
Sets the average bitrate to be used in kbits/second (default: off). Since local bitrate may vary, this average may be inaccurate for very short videos (see ratetol). Constant bitrate can be achieved by combining this with vbv_maxrate, at significant reduction in quality.
Битрейт это понятно что. Сколько битов надо тратить в секунду. При этом надо понимать что это ещё и зависит от frame rate, сколько кадров в секунду, так как если кадров в секунду много, то и битов будет много. Значение битрейта выявляется экспериментально или в зависимости от того сколько вообще есть места на целевом носителе.
qp=<0−51>
This selects the quantizer to use for P-frames. I- and B-frames are offset from this value by ip_factor and pb_factor, respectively. 20−40 is a useful range. Lower values result in better fidelity, but higher bitrates. 0 is lossless. Note that quantization in H.264 works differently from MPEG-1/2/4: H.264’s quantization parameter (QP) is on a logarithmic scale. The mapping is approximately H264QP = 12 + 6*log2(MPEGQP). For example, MPEG at QP=2 is equivalent to H.264 at QP=18.
Это настройка фактора квантизации. Лучше вообще не указывать. Пусть он сам найдёт правильный QP.
crf=<1.0−50.0>
Enables constant quality mode, and selects the quality. The scale is similar to QP. Like the bitrate-based modes, this allows each frame to use a different QP based on the frame’s complexity.
Очень интересный режим константного качества. Кажется он есть только в x264. Размер при этом выдержать нельзя, но зато качество как бы будет всегда постоянным. Оно оценивается наверняка по метрике PSNR, которая не всегда отражает качество для субъективного просмотра. Да и режим этот экспериментальный, на форумах у людей с ним часто бывают проблемы. Так что пользоваться не советую пока. Но вообще очень интересный режим, если не важет итоговый размер.
pass=<1−3>
Enable 2 or 3-pass mode. It is recommended to always encode in 2 or 3-pass mode as it leads to a better bit distribution and improves overall quality.
1
first pass
2
second pass (of two pass encoding)
3
Nth pass (second and third passes of three pass encoding)
Here is how it works, and how to use it:
The first pass (pass=1) collects statistics on the video and writes them to a file. You might want to deactivate some CPU-hungry options, apart from the ones that are on by default.
In two pass mode, the second pass (pass=2) reads the statistics file and bases ratecontrol decisions on it.
In three pass mode, the second pass (pass=3, that is not a typo) does both: It first reads the statistics, then overwrites them. You can use all encoding options, except very CPU-hungry options.
The third pass (pass=3) is the same as the second pass, except that it has the second pass’ statistics to work from. You can use all encoding options, including CPU-hungry ones.
The first pass may use either average bitrate or constant quantizer. ABR is recommended, since it does not require guessing a quantizer. Subsequent passes are ABR, and must specify bitrate.
Многопроходное кодирование. Вещь необходимая для создания качественного результата. Как я уже писал, в 1-проходном случае encoder не может оптимально перераспределить биты в потоке для сцен с большим движением и деталями, и для сцен, где движения мало, и деталей меньше. Поэтому он будет пытаться держать битрейт всегда одинаковым, а основной "ручкой" регулирования битрейта является фактор квантизации. Если вдруг encoder наткнётся на сцену с большим и сложным движением, он значительно "отквантизирует" её так что качество будет ниже чем в других сценах. Правда, считается что человек всё равно не заметит если в кадре всё быстро мелькает и дрыгается, но тем не менее артифакты сильного сжатия будут более заметными.
2-проходного сжатия обычно хватает, так как encoder на первом проходе просчитывает типы кадров и примерный размер кадра. Но это всё немного приблизительно так как реальное кодирование на первом проходе обычно бывает не в самом высоком качестве. Поэтому для перфекционистов есть 3-й проход, где после 2-го уже качественного прохода информация известна вся. После 3-го прохода остальные смысла не имеют.
turbo=<0−2>
Fast first pass mode. During the first pass of a two or more pass encode it is possible to gain speed by disabling some options with negligible or even no impact on the final pass output quality.
0
disabled (default)
1
Reduce subq, frameref and disable some inter-macroblock partition analysis modes.
2
Reduce subq and frameref to 1, use a diamond ME search and disable all partition analysis modes.
Level 1 can increase first pass speed up to 2x with no change in the global PSNR of the final pass compared to a full quality first pass.
Level 2 can increase first pass speed up to 4x with about +/− 0.05dB change in the global PSNR of the final pass compared to a full quality first pass.
Турбо режим для первого прохода многопроходного кодирования. В случае 1 отключается четверть-пиксельная точность, в случае 2 используется быстрый грубый режим motion estimation. Этот режим чисто оценочный, а если процессор мощный то его вообще можно не использовать.
keyint=
Sets maximum interval between IDR-frames (default: 250). Larger values save bits, thus improve quality, at the cost of seeking precision. Unlike MPEG-1/2/4, H.264 does not suffer from DCT drift with large values of keyint.
Количество кадров между ключевыми. В h264 это число ничем не ограничено, так как точность не теряется в отличие от MPEG2. IDR это I кадр, ранее которого ни один P или B не могут ссылаться. Поэтому с него можно начинать декодирование как с начала фильма. IDR кадры используются при быстрой перемотке, так как с них начинается показ кадров, которые на него ссылаются. Если перемотка не нужна, то keyint можно указать очень большим, но умолчательное значение 250 и так уже довольно большое. Больше смысла делать мало, так как в количестве битов выигрыш будет минимальным.
keyint_min=<1−keyint/2>
Sets minimum interval between IDR-frames (default: 25). If scenecuts appear within this interval, they are still encoded as I-frames, but do not start a new GOP. In H.264, I-frames do not necessarily bound a closed GOP because it is allowable for a P-frame to be predicted from more frames than just the one frame before it (also see frameref). Therefore, I-frames are not necessarily seekable. IDR-frames restrict subsequent P-frames from referring to any frame prior to the IDR-frame.
Минимальное количество кадров между IDR, то есть не ставить IDR слишком часто. Лучше не трогать, x264 вполне разумно их расставляет и так.
scenecut=<−1−100>
Controls how aggressively to insert extra I-frames (default: 40). With small values of scenecut, the codec often has to force an I-frame when it would exceed keyint. Good values of scenecut may find a better location for the I-frame. Large values use more I-frames than necessary, thus wasting bits. −1 disables scene-cut detection, so I-frames are inserted only once every other keyint frames, even if a scene-cut occurs earlier. This is not recommended and wastes bitrate as scenecuts encoded as P-frames are just as big as I-frames, but do not reset the "keyint counter".
Фактор определения того что началась новая сцена (в этом случае большая вероятность того что encoder вставит I кадр, что соответственно отнимает много бит, но повышает качество для кадров которые на него будут ссылаться). Лучше не трогать, умолчательно значение вполне разумное.
frameref=<1−16>
Number of previous frames used as predictors in B- and P-frames (default: 1). This is effective in anime, but in live-action material the improvements usually drop off very rapidly above 6 or so reference frames. This has no effect on decoding speed, but does increase the memory needed for decoding. Some decoders can only handle a maximum of 15 reference frames.
Максимальное количество кадров, на которые могут ссылаться P и B кадры. Экспериментально показано что больше чем 6 значение мало улучшает качество. В теории большое (очень большое) количество референсных кадров помогает кодированию сцен с циклическим движением (догадайтесь сами каким). Но проблема в том что декодеру надо держать в памяти все кадры, на которые могут быть ссылки, так что чем больше значение этого параметра, тем больше надо памяти. Железячные ускорители h264 типа видео карт допускают не более 6 кадров, и если их больше, то декодирование будет только на процессоре. Ну а то про что кто-то мог подумать, это повторяющееся движение часто требует больше чем 16 максимально позволяемых референсных кадров, так как 16 в случае 25 кадров в секунду это примерно 2/3 секунды.
bframes=<0−16>
maximum number of consecutive B-frames between I- and P-frames (default: 0)
Максимальное количество B кадров подряд. На B кадрах в h264 экономится основное место. По сравнению с I кадрами они могут быть до 100 раз меньше, а по сравнению с P раз в 5-10 меньше. Так что много B кадров это хорошо. Но слишком много их быть не должно, так как увеличивается расстояние до ссылочных P кадров, да и качество начинает теряться. Нормальное значение должно быть 2-5. Следующая опция в любом случае предпочтительнее.
(no)b_adapt
Automatically decides when to use B-frames and how many, up to the maximum specified above (default: on). If this option is disabled, then the maximum number of B-frames is used.
Определять автоматически сколько делать B кадров. Отменяет максимум указанный выше. Лучше пользоваться этой опцией, тем более что она и так включена по умолчанию.
b_bias=<−100−100>
Controls the decision performed by b_adapt. A higher b_bias produces more B-frames (default: 0).
Лучше не трогать.
(no)b_pyramid
Allows B-frames to be used as references for predicting other frames. For example, consider 3 consecutive B-frames: I0 B1 B2 B3 P4. Without this option, B-frames follow the same pattern as MPEG-[124]. So they are coded in the order I0 P4 B1 B2 B3, and all the B-frames are predicted from I0 and P4. With this option, they are coded as I0 P4 B2 B1 B3. B2 is the same as above, but B1 is predicted from I0 and B2, and B3 is predicted from B2 and P4. This usually results in slightly improved compression, at almost no speed cost. However, this is an experimental option: it is not fully tuned and may not always help. Requires bframes >= 2. Disadvantage: increases decoding delay to 2 frames.
Хорошая опция, которая позволяет использовать B кадры как референсные для других B. Для хорошего качества лучше включить.
(no)deblock
Use deblocking filter (default: on). As it takes very little time compared to its quality gain, it is not recommended to disable it.
В h264 стандартом предусмотрен фильтр для удаления границ макроблоков. Как правило добавляет качество восприятия. Включать надо.
deblock=<−6−6>,<−6−6>
The first parameter is AlphaC0 (default: 0). This adjusts thresholds for the H.264 in-loop deblocking filter. First, this parameter adjusts the maximum amount of change that the filter is allowed to cause on any one pixel. Secondly, this parameter affects the threshold for difference across the edge being filtered. A positive value reduces blocking artifacts more, but will also smear details.
The second parameter is Beta (default: 0). This affects the detail threshold. Very detailed blocks are not filtered, since the smoothing caused by the filter would be more noticeable than the original blocking.
The default behavior of the filter almost always achieves optimal quality, so it is best to either leave it alone, or make only small adjustments. However, if your source material already has some blocking or noise which you would like to remove, it may be a good idea to turn it up a little bit.
Пороги работы деблочного фильтра. Лучше не трогать.
(no)cabac
Use CABAC (Context-Adaptive Binary Arithmetic Coding) (default: on). Slightly slows down encoding and decoding, but should save 10−15% bitrate. Unless you are looking for decoding speed, you should not disable it.
CABAC включен по умолчанию. Отключать не стоит.
Продолжение в другой части, а то мне ЖЖ заявляет post too large.
Поехали про опции. Вот раздел мануала mencoder с моими комментариями для кодирования x264
x264enc (−x264encopts)
bitrate=
Sets the average bitrate to be used in kbits/second (default: off). Since local bitrate may vary, this average may be inaccurate for very short videos (see ratetol). Constant bitrate can be achieved by combining this with vbv_maxrate, at significant reduction in quality.
Битрейт это понятно что. Сколько битов надо тратить в секунду. При этом надо понимать что это ещё и зависит от frame rate, сколько кадров в секунду, так как если кадров в секунду много, то и битов будет много. Значение битрейта выявляется экспериментально или в зависимости от того сколько вообще есть места на целевом носителе.
qp=<0−51>
This selects the quantizer to use for P-frames. I- and B-frames are offset from this value by ip_factor and pb_factor, respectively. 20−40 is a useful range. Lower values result in better fidelity, but higher bitrates. 0 is lossless. Note that quantization in H.264 works differently from MPEG-1/2/4: H.264’s quantization parameter (QP) is on a logarithmic scale. The mapping is approximately H264QP = 12 + 6*log2(MPEGQP). For example, MPEG at QP=2 is equivalent to H.264 at QP=18.
Это настройка фактора квантизации. Лучше вообще не указывать. Пусть он сам найдёт правильный QP.
crf=<1.0−50.0>
Enables constant quality mode, and selects the quality. The scale is similar to QP. Like the bitrate-based modes, this allows each frame to use a different QP based on the frame’s complexity.
Очень интересный режим константного качества. Кажется он есть только в x264. Размер при этом выдержать нельзя, но зато качество как бы будет всегда постоянным. Оно оценивается наверняка по метрике PSNR, которая не всегда отражает качество для субъективного просмотра. Да и режим этот экспериментальный, на форумах у людей с ним часто бывают проблемы. Так что пользоваться не советую пока. Но вообще очень интересный режим, если не важет итоговый размер.
pass=<1−3>
Enable 2 or 3-pass mode. It is recommended to always encode in 2 or 3-pass mode as it leads to a better bit distribution and improves overall quality.
1
first pass
2
second pass (of two pass encoding)
3
Nth pass (second and third passes of three pass encoding)
Here is how it works, and how to use it:
The first pass (pass=1) collects statistics on the video and writes them to a file. You might want to deactivate some CPU-hungry options, apart from the ones that are on by default.
In two pass mode, the second pass (pass=2) reads the statistics file and bases ratecontrol decisions on it.
In three pass mode, the second pass (pass=3, that is not a typo) does both: It first reads the statistics, then overwrites them. You can use all encoding options, except very CPU-hungry options.
The third pass (pass=3) is the same as the second pass, except that it has the second pass’ statistics to work from. You can use all encoding options, including CPU-hungry ones.
The first pass may use either average bitrate or constant quantizer. ABR is recommended, since it does not require guessing a quantizer. Subsequent passes are ABR, and must specify bitrate.
Многопроходное кодирование. Вещь необходимая для создания качественного результата. Как я уже писал, в 1-проходном случае encoder не может оптимально перераспределить биты в потоке для сцен с большим движением и деталями, и для сцен, где движения мало, и деталей меньше. Поэтому он будет пытаться держать битрейт всегда одинаковым, а основной "ручкой" регулирования битрейта является фактор квантизации. Если вдруг encoder наткнётся на сцену с большим и сложным движением, он значительно "отквантизирует" её так что качество будет ниже чем в других сценах. Правда, считается что человек всё равно не заметит если в кадре всё быстро мелькает и дрыгается, но тем не менее артифакты сильного сжатия будут более заметными.
2-проходного сжатия обычно хватает, так как encoder на первом проходе просчитывает типы кадров и примерный размер кадра. Но это всё немного приблизительно так как реальное кодирование на первом проходе обычно бывает не в самом высоком качестве. Поэтому для перфекционистов есть 3-й проход, где после 2-го уже качественного прохода информация известна вся. После 3-го прохода остальные смысла не имеют.
turbo=<0−2>
Fast first pass mode. During the first pass of a two or more pass encode it is possible to gain speed by disabling some options with negligible or even no impact on the final pass output quality.
0
disabled (default)
1
Reduce subq, frameref and disable some inter-macroblock partition analysis modes.
2
Reduce subq and frameref to 1, use a diamond ME search and disable all partition analysis modes.
Level 1 can increase first pass speed up to 2x with no change in the global PSNR of the final pass compared to a full quality first pass.
Level 2 can increase first pass speed up to 4x with about +/− 0.05dB change in the global PSNR of the final pass compared to a full quality first pass.
Турбо режим для первого прохода многопроходного кодирования. В случае 1 отключается четверть-пиксельная точность, в случае 2 используется быстрый грубый режим motion estimation. Этот режим чисто оценочный, а если процессор мощный то его вообще можно не использовать.
keyint=
Sets maximum interval between IDR-frames (default: 250). Larger values save bits, thus improve quality, at the cost of seeking precision. Unlike MPEG-1/2/4, H.264 does not suffer from DCT drift with large values of keyint.
Количество кадров между ключевыми. В h264 это число ничем не ограничено, так как точность не теряется в отличие от MPEG2. IDR это I кадр, ранее которого ни один P или B не могут ссылаться. Поэтому с него можно начинать декодирование как с начала фильма. IDR кадры используются при быстрой перемотке, так как с них начинается показ кадров, которые на него ссылаются. Если перемотка не нужна, то keyint можно указать очень большим, но умолчательное значение 250 и так уже довольно большое. Больше смысла делать мало, так как в количестве битов выигрыш будет минимальным.
keyint_min=<1−keyint/2>
Sets minimum interval between IDR-frames (default: 25). If scenecuts appear within this interval, they are still encoded as I-frames, but do not start a new GOP. In H.264, I-frames do not necessarily bound a closed GOP because it is allowable for a P-frame to be predicted from more frames than just the one frame before it (also see frameref). Therefore, I-frames are not necessarily seekable. IDR-frames restrict subsequent P-frames from referring to any frame prior to the IDR-frame.
Минимальное количество кадров между IDR, то есть не ставить IDR слишком часто. Лучше не трогать, x264 вполне разумно их расставляет и так.
scenecut=<−1−100>
Controls how aggressively to insert extra I-frames (default: 40). With small values of scenecut, the codec often has to force an I-frame when it would exceed keyint. Good values of scenecut may find a better location for the I-frame. Large values use more I-frames than necessary, thus wasting bits. −1 disables scene-cut detection, so I-frames are inserted only once every other keyint frames, even if a scene-cut occurs earlier. This is not recommended and wastes bitrate as scenecuts encoded as P-frames are just as big as I-frames, but do not reset the "keyint counter".
Фактор определения того что началась новая сцена (в этом случае большая вероятность того что encoder вставит I кадр, что соответственно отнимает много бит, но повышает качество для кадров которые на него будут ссылаться). Лучше не трогать, умолчательно значение вполне разумное.
frameref=<1−16>
Number of previous frames used as predictors in B- and P-frames (default: 1). This is effective in anime, but in live-action material the improvements usually drop off very rapidly above 6 or so reference frames. This has no effect on decoding speed, but does increase the memory needed for decoding. Some decoders can only handle a maximum of 15 reference frames.
Максимальное количество кадров, на которые могут ссылаться P и B кадры. Экспериментально показано что больше чем 6 значение мало улучшает качество. В теории большое (очень большое) количество референсных кадров помогает кодированию сцен с циклическим движением (догадайтесь сами каким). Но проблема в том что декодеру надо держать в памяти все кадры, на которые могут быть ссылки, так что чем больше значение этого параметра, тем больше надо памяти. Железячные ускорители h264 типа видео карт допускают не более 6 кадров, и если их больше, то декодирование будет только на процессоре. Ну а то про что кто-то мог подумать, это повторяющееся движение часто требует больше чем 16 максимально позволяемых референсных кадров, так как 16 в случае 25 кадров в секунду это примерно 2/3 секунды.
bframes=<0−16>
maximum number of consecutive B-frames between I- and P-frames (default: 0)
Максимальное количество B кадров подряд. На B кадрах в h264 экономится основное место. По сравнению с I кадрами они могут быть до 100 раз меньше, а по сравнению с P раз в 5-10 меньше. Так что много B кадров это хорошо. Но слишком много их быть не должно, так как увеличивается расстояние до ссылочных P кадров, да и качество начинает теряться. Нормальное значение должно быть 2-5. Следующая опция в любом случае предпочтительнее.
(no)b_adapt
Automatically decides when to use B-frames and how many, up to the maximum specified above (default: on). If this option is disabled, then the maximum number of B-frames is used.
Определять автоматически сколько делать B кадров. Отменяет максимум указанный выше. Лучше пользоваться этой опцией, тем более что она и так включена по умолчанию.
b_bias=<−100−100>
Controls the decision performed by b_adapt. A higher b_bias produces more B-frames (default: 0).
Лучше не трогать.
(no)b_pyramid
Allows B-frames to be used as references for predicting other frames. For example, consider 3 consecutive B-frames: I0 B1 B2 B3 P4. Without this option, B-frames follow the same pattern as MPEG-[124]. So they are coded in the order I0 P4 B1 B2 B3, and all the B-frames are predicted from I0 and P4. With this option, they are coded as I0 P4 B2 B1 B3. B2 is the same as above, but B1 is predicted from I0 and B2, and B3 is predicted from B2 and P4. This usually results in slightly improved compression, at almost no speed cost. However, this is an experimental option: it is not fully tuned and may not always help. Requires bframes >= 2. Disadvantage: increases decoding delay to 2 frames.
Хорошая опция, которая позволяет использовать B кадры как референсные для других B. Для хорошего качества лучше включить.
(no)deblock
Use deblocking filter (default: on). As it takes very little time compared to its quality gain, it is not recommended to disable it.
В h264 стандартом предусмотрен фильтр для удаления границ макроблоков. Как правило добавляет качество восприятия. Включать надо.
deblock=<−6−6>,<−6−6>
The first parameter is AlphaC0 (default: 0). This adjusts thresholds for the H.264 in-loop deblocking filter. First, this parameter adjusts the maximum amount of change that the filter is allowed to cause on any one pixel. Secondly, this parameter affects the threshold for difference across the edge being filtered. A positive value reduces blocking artifacts more, but will also smear details.
The second parameter is Beta (default: 0). This affects the detail threshold. Very detailed blocks are not filtered, since the smoothing caused by the filter would be more noticeable than the original blocking.
The default behavior of the filter almost always achieves optimal quality, so it is best to either leave it alone, or make only small adjustments. However, if your source material already has some blocking or noise which you would like to remove, it may be a good idea to turn it up a little bit.
Пороги работы деблочного фильтра. Лучше не трогать.
(no)cabac
Use CABAC (Context-Adaptive Binary Arithmetic Coding) (default: on). Slightly slows down encoding and decoding, but should save 10−15% bitrate. Unless you are looking for decoding speed, you should not disable it.
CABAC включен по умолчанию. Отключать не стоит.
Продолжение в другой части, а то мне ЖЖ заявляет post too large.