The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"Выпуск мультимедиа-пакета FFmpeg 3.1"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от opennews (ok) on 27-Июн-16, 11:44 
После четырёх месяцев разработки представлен (http://ffmpeg.org/download.html#release_3.1) мультимедиа-пакет FFmpeg 3.1 (http://ffmpeg.org/download.html#releases), включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Кроме изменений, созданных внутри проекта, в новую версию также включены все последние наработки, развиваемые в ветках ffmpeg-mt (http://gitorious.org/ffmpeg/ffmpeg-mt) (многопоточное декодирование) и libav (http://libav.org/) (форк FFmpeg). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer (http://www.mplayerhq.hu/).


Из изменений (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES...), добавленных (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;hb=...) в FFmpeg 3.1, можно выделить:


-  Возможность применения VAAPI и libnpp/CUDA для аппаратного ускорения преобразования форматов и масштабирования видео;

-  Поддержка декодирования HEVC Main10 с задействованием средств аппаратного ускорения DXVA2;
-  Поддержка ускорения кодирования H.264, HEVC и MJPEG при помощи VAAPI;
-  Поддержка ускорения декодирования H264 и HEVC при помощи CUDA;


-  Новые фильтры (https://ffmpeg.org/ffmpeg-filters.html):


-  fieldhint (https://ffmpeg.org/ffmpeg-filters.html#fieldhint) - создания новых кадров путём копирования верхнего и нижнего полей из окружающих кадров;


-  loop и aloop (https://ffmpeg.org/ffmpeg-filters.html#loop_002c-aloop) - фильтры для зацикливания кадров видео и образцов звука;

-  bwdif (https://ffmpeg.org/ffmpeg-filters.html#bwdif)  (Bob Weaver deinterlacing filter) - адаптивный алгоритм устранения чересстрочности в видео, использующий интерполяцию;
-  firequalizer (https://ffmpeg.org/ffmpeg-filters.html#firequalizer) - выравнивание частотных характеристик звука;

-  datascope (https://ffmpeg.org/ffmpeg-filters.html#datascope) - анализатор видеоданных;

-  bench и abench (https://ffmpeg.org/ffmpeg-filters.html#bench_002c-abench) - измерение скорости работы произвольных видео и аудио фильтров;

-  ciescope (https://ffmpeg.org/ffmpeg-filters.html#ciescope) - показывает диаграмму цветов CIE, отражающую распределение цветов пикселей;

-  colorspace (https://ffmpeg.org/ffmpeg-filters.html#colorspace) - преобразование параметров цветов и трансформация из одного цветового пространства в другое;

-  hdcd (https://ffmpeg.org/ffmpeg-filters.html#hdcd) - декодирует со звукового CD 16-разрядные PCM-данные c hdcd флагами в 20 разрядный PCM-поток;

-  readvitc (https://ffmpeg.org/ffmpeg-filters.html#readvitc) - чтение информации об  интервале кадрового гасящего импульса (VITC) из верхних строк видеокадра;

-  loudnorm (https://ffmpeg.org/ffmpeg-filters.html#loudnorm) - фильтр для линейной и динамической нормализации громкости;
-  coreimage (https://ffmpeg.org/ffmpeg-filters.html#coreimage-1) - задействование аппаратного ускорения с привлечением GPU для обработки изображений и видео на платформе  OS X (используется Apple CoreImage API);
-  remap (https://ffmpeg.org/ffmpeg-filters.html#remap) - переназначение пикселей  в видеопотоке;
-  bitstream - применение системы автоматической фильтрации битового потока для извлечения данных DTS.


-  Добавлены екодировщики для DST (Direct Stream Transfer), MediaCodec H264, MTAF, BitJazz SheerVideo, YUY2 Lossless Codec, MagicYUV, IFF ANIM, Duck TrueMotion 2.0 Real Time, DTS Express (LBR) и ADPCM IMA DAT4;
-  Добавлены распаковщики медиа-контейнеров (demuxer) для форматов musx, aix, WSD (Wideband Single-bit Data), MTAF и IFF ANIM;

-  Реализован API для ведения чёрного списка протоколов;
-  Добавлены распаковщики и упаковщики payload-данных (depacketizer и packetizer) для формата  VC-2 HQ RTP. Упаковщик для формата VP9 RTP;

-  В декодировщик utvideo добавлена поддержка 10-разрядной глубины цвета;
-  Добавлены упаковщики медиа-контейнеров (muxer) для форматов hash и framehash;
-  Добавлен кодировщик Generic OpenMAX IL  с поддержкой Raspberry Pi;

-  Обеспечена поддержка декодировщиков и кодировщиков фреймворка AudioToolbox;
-  Из поставки удалена библиотека libdcadec и прослойка libutvideo.

URL: http://ffmpeg.org/download.html#release_3.1
Новость: http://www.opennet.ru/opennews/art.shtml?num=44674

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по ответам | RSS]

1. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +4 +/
Сообщение от Mihail Zenkov (ok) on 27-Июн-16, 11:44 
> hdcd - декодирует со звукового CD 16-разрядные PCM-данные c hdcd флагами в 20 разрядный PCM-поток;

Декодировщик добавили спустя двадцать лет. Кодировщика, очевидно, не будет. Слава патентам! Еще одна интересная технология была благополучна ими похоронена ...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от robux (ok) on 27-Июн-16, 11:44 
Есть какая-нибудь годная кроссплатформенная обёртка для использования FFmpeg (только не Gstreamer) в виде библиотеки, чтобы просто подавать на вход сырые медиа данные и получать закодированные, не погружаться в адовый API FFmpeg'а?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +2 +/
Сообщение от Аноним (??) on 27-Июн-16, 11:56 
обертка на каком языке (вообще, их как грязи на любом)? И чем плохо запускать его просто из командной строки?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Аноним (??) on 27-Июн-16, 12:11 
Вероятно, он хочет на Ruby для своего проекта Pandoranet. Там впрочем, довольно странная архитектура. Лучше бы разделить на модули, сделать основу да отдать остальные модули (типа видеосвязи, бухгалтерия и прочее) на откуп обществу.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +1 +/
Сообщение от robux (ok) on 27-Июн-16, 12:12 
В идеале на ruby. Уже сижу покуриваю:
https://github.com/petems/mplayer-ruby
http://www.rubygemsearch.com/ruby-gems/search?q=mplayer
https://www.mplayerhq.hu/DOCS/HTML/ru/MPlayer.html#streaming

И да, для Пандоры.
Gstreamer, который я использовал, поломали вместе с переходом Gtk2->Gtk3.
Он и раньше-то только в лине работал (в винде нет), а щас и в лине перестал.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +5 +/
Сообщение от Аноним (??) on 27-Июн-16, 12:18 
Зачем тратить время на кодировщик который уже не актуален по всем техническим параметрам? Сейчас более актуален декодировщик, чтобы хотя бы раскодировать то что накодировали.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

8. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +11 +/
Сообщение от Аноним (??) on 27-Июн-16, 12:22 
команды ffmpeg и man ffmpeg - самые переносимые и самые гибкие.
перекодировка сначала отрабатывается на куске файла (опции -ss и -t, использовать перед -i), команда корректируется в какомнить .sh-файле, после чего -ss и -t убираются и перекодировывается вся вещь.
в качестве краткого ликбеза вот пример команды:
ffmpeg -i входнойфайл -map 0:v -map 0:a:1 -map 0:s:0 -f matroska -s 720x406 -c:v libx264 -threads:v 2 -c:a:0 libmp3lame -threads:a:0 1 -c:s:0 copy out.mkv
это значит:
1. -map: из файла "входнойфайл" (первый файл - индекс 0 в -map) взять видеопоток (0:v), второй аудиопоток (0:a:1) и первый поток субтитров (0:s:0);
2. -f: закодировать це всё в матрёшку (mkv);
3. -s: разрешение итогового видео;
4. -c: кодировщики: закодировать видеопоток кодеком libx264, выполнять двумя потоками (-threads:v 2), закодировать первый аудиопоток выходного файла (он был вторым во входном файле, но -map 0:a:1 было первым аудиопотоком, поэтому в выходном файле он первый) кодеком libmp3lame, выполнять в один поток; субтитры - скопировать;
5. результат записать в out.mkv.
как-то так.
интерфейс понятен как интеллектуально - через ман, - так и интуитивно - интуиция подсказывает, что команды надо как-то ввести. скорее всего с клавиатуры.
лучше всяких визивигов и прочих мелкомягких плюшек.
поэтому как-то так...
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

9. "Выпуск мультимедиа-пакета FFmpeg 3.1"  –1 +/
Сообщение от Аноним (??) on 27-Июн-16, 12:23 
handbrake.fr
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

10. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Аноним (??) on 27-Июн-16, 13:45 
> CUDA

5 лет ждал. И хоть бы один Closed Source дал бы это за деньги в 2011!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Аноним (??) on 27-Июн-16, 13:50 
>2. -f: закодировать це всё в матрёшку (mkv);

зачем это нужно, если формат контейнера и так определится по расширению?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +3 +/
Сообщение от ipony on 27-Июн-16, 14:14 
Теперь я успею перегнать все свои мультики с пони.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +3 +/
Сообщение от Mihail Zenkov (ok) on 27-Июн-16, 14:18 
Так я о том и говорю - нет смысла писать кодировщик, когда cd-audio фактически умер.

> Сейчас более актуален декодировщик, чтобы хотя бы раскодировать то что накодировали.

Даже он не особо актуален, так как сам формат не получил широкого распространения.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

14. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от 5kbps (ok) on 27-Июн-16, 14:24 
На случай, если расширение другое.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +5 +/
Сообщение от Аноним (??) on 27-Июн-16, 14:24 
на практике это можно не использовать, но в христоматийном примере оно должно фигурировать - ради пущей определённости.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

16. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от anonymous (??) on 27-Июн-16, 14:27 
API серьёзно перелопатили.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +5 +/
Сообщение от Stax (ok) on 27-Июн-16, 14:59 
Это как сказать.
Иногда внезапно при проигрывании очередного диска можно увидеть, как загорается индикатор "hdcd". Даже когда на самом диске ничего не указано. Это я к тому, что их определенно больше, чем кажется, я совершенно случайно натыкался на hdcd диски, узнавая об этом уже при проигрывании.

А еще это важно, потому что без понимания, что это hdcd он воспроизводится не так хорошо (уровни громкости фрагментов друг относительно друга могут быть неправильные, возможен клиппинг и прочие неприятности). Формат "совместим" с не-HDCD проигрыванием только в том смысле, что звучать будет, но не совсем то, что записывали.

И т.к. все это переносится при любом loseless рипе и кодировании - flac, рипнутый с таких дисков тоже требует hdcd-aware декодера, чтобы звучать корректно. Без этого - звучит с огрехами. Так что либо надо во все проигрыватели поддержку hdcd при проигрывании, либо при рипе расшифровывать hdcd и превращать его в 24-х битный flac уже без этих странных технологий (там, конечно, 20 бит, но так не выйдет). В принципе, сейчас, когда есть декодер, можно пройтись по библиотеке и расшифровать найденные hdcd, перекодируя их в 24-х битные записи без hdcd.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

19. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от 5kbps (ok) on 27-Июн-16, 15:45 
>  Реализован API для ведения чёрного списка протоколов;

Эта самое нужное нововведение во всём релизе. Теперь при вскрытии очередной дыры пересборка не потребуется.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от robux (ok) on 27-Июн-16, 19:21 
> команды ffmpeg и man ffmpeg - самые переносимые и самые гибкие.

Я уже пытался использовать "голый" ffmpeg.

Если в лине ещё можно поток (pipe) выдёргивать прямо из консоли и в ruby его читать, то винде такое невозможно (ведь я прав, да?). Т.е. первая проблема при съёме данных с камеры и микрофона в винде и передачи их в Пандору.

Вторая грабля - это то, что полученные с другой стороны медиа-данные (видео, аудио, либо оба сразу в "матрёшке") можно раздемуксить и декодировать, но нельзя вывалить видео в нужное мне окошко (аудио поток можно пулять сразу на устройство).

Я эту проблему пытался решить пару лет назад (https://www.linux.org.ru/forum/development/10645570), в итоге родилось костыльное решение:
1) медиа-поток(и) с камеры и микрофона из ffmpeg'а вываливать на локальный udp-порт
2) снимать с локального udp Пандорой и посылать другой строне
3) другая сторона принимает поток, запускает свой mplayer и говорит ему в какое окно пулять видео (xid одного из окон Пандоры).

Костыльно, но по идее должно работать, я эксперименты в лине проводил, но так и не проверил в винде - может ли виндовый mplayer выводить в указанное виндовое окошко).

Мне не нравится, что придётся плодить udp-потоки. Всё-таки хотелось бы как-то напрямую:
1) брать в винде данные;
2) выводить видео во внутреннее окно.
Но такого фреймворка (кроме сговнявшегося Гстримера) я пока найти не могу.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

22. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok) on 27-Июн-16, 19:23 
Хотел проверить сколько же реально hdcd у меня в коллекции.
Написал скрипт:
ffmpeg -v error -i "$1" -f wav - | md5sum
ffmpeg -v error -i "$1" -af hdcd -f wav - | md5sum

При декодировании с фильтром hdcd сумма всегда другая. Вероятно фильтр работает некорректно и вносит изменения даже там, где они не нужны :(

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Выпуск мультимедиа-пакета FFmpeg 3.1"  –1 +/
Сообщение от iPony on 27-Июн-16, 20:53 
А зачем их перегонять? Не самогон же.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

25. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +2 +/
Сообщение от Stax (ok) on 27-Июн-16, 21:03 
Эээ не совсем. Это фильтр, если его активировали, он всегда работает. Выходной формат фильтра заявлен как 24 бита (смысл фильтра же в распаковке 16 bit -> 20 bit). Ну а дальше.. просто ffmpeg так работает. Если HDCD-меток нет, получаем преобразование 16->24 бита без какого-либо преобразования. Но сумма, конечно, не сойдется.

В текущем виде это более пригодно для проигрывателя. Преобразование 16->24 будет всегда (ну и что такого), но если были HDCD-метки, будет преобразование.

Насчет выяснить. Надо понимать, что фильтр пригоден только для 44100 файлов, не надо через него гнать 48khz записи. По ссылке https://trac.ffmpeg.org/ticket/4441#comment:13 предлагают старый конвертер (на 64-х битной системе сделать замены типа, как описано в тикете). Он после конвертации пишет что-то типа "Total = 0  A = 0    B = 0     C= 0". Вот если Total отличен от нуля, было преобразование.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

26. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +2 +/
Сообщение от VJLink on 27-Июн-16, 21:29 
FIXED
Теперь я успею погонять на все свои мультики с пони.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

27. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok) on 27-Июн-16, 22:02 
В первом моем варианте оба выходных формата были s16le.

При варианте s24le сумма все равно разная.
ffmpeg  -i "$1" -f s24le - | md5sum
ffmpeg  -i "$1" -af hdcd -f s24le - | md5sum

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

28. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok) on 27-Июн-16, 22:18 
Ну ээ результат hdcd-декодирования в 16 бит положить невозможно :) Искажения будут.. лучше уж тогда вообще не трогать. Ну то есть даже пытаться не надо такое делать, смысл обработки же именно в представлении 20-битного сигнала.

По поводу суммы - ну хз, может заголовки разные выходят? А cmp -l на оба полученных файлов много различий пишет?

Вообще там есть логирование в фильтре, если в verbose-режиме запускать.
        av_log(ctx, AV_LOG_VERBOSE, "Channel %d: counter A: %d, B: %d, C: %d\n", i, state->code_counterA,
                state->code_counterB, state->code_counterC);

Отличный от нуля счетчик и говорит о сработавшем фильтре. Лучше через это проверять. А то контрольные суммы.. что-то не то.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "Выпуск мультимедиа-пакета FFmpeg 3.1"  –3 +/
Сообщение от Аноним (??) on 27-Июн-16, 23:03 
> Если в лине ещё можно поток (pipe) выдёргивать прямо из консоли и в ruby его читать, то винде такое невозможно (ведь я прав, да?).

Пайпы и возможность гонять произвольные данные через стандартные потоки ввода-вывода в винде есть. Умеют ли это виндовые сборки Ruby и ffmpeg -- вопрос отдельный.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

30. "Выпуск мультимедиа-пакета FFmpeg 3.1"  –1 +/
Сообщение от Mihail Zenkov (ok) on 28-Июн-16, 00:27 
> Ну ээ результат hdcd-декодирования в 16 бит положить невозможно :)

Очень даже возможно :)

> Искажения будут..

Не будет.

> лучше уж тогда вообще не трогать. Ну то есть даже пытаться
> не надо такое делать, смысл обработки же именно в представлении 20-битного
> сигнала.

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

24 бита (как и 88-192 kHz) нужны для студии дабы не накапливать ошибки округления при многократной обработке и не получать артефакты при возникновении ультразвука во время записи.  

Что же касается hdcd, то если я правильно понял идею hdcd причина его возникновения была в плохом качестве дешевых DAC того времени - вместо полноценных 16 бит они выдавали честных 14-12. Самый простой способ исправить ситуацию - динамическая регулировка громкости (примерно тоже что и динамическая контрастность в мониторах). Тихие фрагменты пишутся существенно громче дабы они были выше 14 бит и ослабляются дополнительным хаком в аналоговой части DAC. На самом деле вполне неплохое решение проблемы. Похожие приемы применяются в психоаккустической модели кодеков с потерями.

На сегодняшний день полноценные 15-16 бит можно сказать норма, даже для весьма дешевых решений. Смысл в подобных ухищрениях пропал. Тем более используя современный алгоритмы (нойз шейпинг) можно получить диапазон более 18 бит на 16 битной записи. При этом будет 100% совместимость с любым плеером/устройством.

> По поводу суммы - ну хз, может заголовки разные выходят?

У -f s24le нет заголовков, это чистый (raw) pcm поток.

> А cmp  -l на оба полученных файлов много различий пишет?

Много - весь файл.

> Вообще там есть логирование в фильтре, если в verbose-режиме запускать.
>         av_log(ctx, AV_LOG_VERBOSE, "Channel %d:
> counter A: %d, B: %d, C: %d\n", i, state->code_counterA,
>            
>     state->code_counterB, state->code_counterC);
> Отличный от нуля счетчик и говорит о сработавшем фильтре. Лучше через это
> проверять. А то контрольные суммы.. что-то не то.

Проверил - пишит 0. Открыл в аудиоредакторе - с фильтром он делает весь файл в два раза тише. Наверное оставляет место для расширения пиков. Но ИМХО это неправильно - сперва следовало бы убедиться, что поток hdcd и только тогда его преобразовывать.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

31. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok) on 28-Июн-16, 12:04 
Проверил свою коллекцию (metal/rock/classic/jazz) flac - нашел семь альбомов. Это 2.5% от общего количества.

Было много ложных срабатываний с результатом "counter A: 0, B: 0, C: 1" на отдельных треках.

Как работает пока толком не проверил. Но уже ясно, что файл получается в итоге в два раза тише, даже если в нем нет расширения пиков. Соответственно теряем старший бит, что существенно снижает качество. Так что или алгоритм патчить или проводить нормализацию после этого фильтра.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

32. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok) on 28-Июн-16, 15:01 
> Не будет.

Будут элементарно. Проще показать на примере, вместо вместо 24 бит - 8, вместо 16 бит - старшие 4.

Исходный 8-битный сигнал: 0011 0100
HDCD-кодирование в 4 бита: 1101 + пометка, что у блока сдвиг на 2 бита. Обычный CD играет "1101".
Декодировали HDCD: 0011 0100. При преобразовании в 16-ти битный формат записали старшие 4 бита: 0110.

> Начнем с того, что 16 бит (с дитерингом) вполне достаточно для воспроизведения практически в любых реальных условиях. Даже на высококачественной аппаратуре в специально подготовленном помещении на классической музыке с минимальным использованием компрессора.

<далее поскипано>

Но практически на дисках бывает клиппинг и прочие проблемы. Мастеринг CD шел в большей глубине (float/48 обычно), финальное преобразование было в 16/44. Это можно сделать по разному. По простому - нормализовать запись, выполнить компрессию, убедиться, что в итоге нет звуков громче, чем -3 dB, закодировать в 16 бит. Практически.. ну известно, что вышло из loudness war, звуки до 0 db и т.д.
А при нормализации может вылезти другая проблема, понизим громкость, слишком тихие звуки уйдут из диапазона. Как на одном диске записать и тихую, и громкую композицию без потерь, если выравнивать весь диск к одной громкости? Это нам сейчас хорошо, у нас есть replaygain. А тогда вот не было. И придумали HDCD, эдакий поблочный replaygain.,

HDCD предлагает такое решение: для каждого блока данных найдем тот диапазон 16 бит, где максимум данных, запишем его, и ставим на блок тэг, что нужно так-то сдвинуть эти биты влево или вправо перед воспроизведением. Проблема решена - громкие композиции без клиппинга, тихие используют полный динамический диапазон, звук нормализован по всему CD. При этом с практической точки зрения оказалось, что чаще записывается тэг, усиливающий громкость. Тогда для чуть лучшей совместимости с CD решили писать на HDCD-диски +6 dB сигнал, так основной тэг блока стал "без изменений", а при прослушивании CD получили громкость чуть ближе к референсной (но все равно звук хуже, чем если бы мы писали честный CD).

Понятно, что грамотной обработкой и кодированием можно было это обойти. И что 16 бит при правильном мастеринге хватит. Просто практически, с тем, как это стали использовать - стало не хватать. HDCD предложил хак, как то, что намастерили максимально без потерь записать на диск.

> Проверил - пишит 0. Открыл в аудиоредакторе - с фильтром он делает весь файл в два раза тише. Наверное оставляет место для расширения пиков. Но ИМХО это неправильно - сперва следовало бы убедиться, что поток hdcd и только тогда его преобразовывать.

Это он делает обратное (-6 dB) преобразование, как положено по стандарту, потому что HDCD кодируют с +6 dB. Это как раз правильно для HDCD дисков (там на самом деле чуть хитрее, чем просто 6dB, тут хорошая иллюстрация и объяснение: http://www.audiomisc.co.uk/HFN/HDCD/Enigma.html). Аппаратный проигрыватель тоже это делает, если находит на диске тэги HDCD. А вот то, что он это делает безусловно даже там, где HDCD не пахнет, конечно, грустно...

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

33. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok) on 28-Июн-16, 15:09 
> Проверил свою коллекцию (metal/rock/classic/jazz) flac - нашел семь альбомов. Это 2.5%
> от общего количества.

Ну кое-что :)

> Было много ложных срабатываний с результатом "counter A: 0, B: 0, C:
> 1" на отдельных треках.

Ясненько. Вообще реальный проигрыватель по-моему смотрит на тэги только в начале трэка, если их нет с первых блоков, то HDCD не включается.

> Как работает пока толком не проверил. Но уже ясно, что файл получается
> в итоге в два раза тише, даже если в нем нет
> расширения пиков. Соответственно теряем старший бит, что существенно снижает качество.
> Так что или алгоритм патчить или проводить нормализацию после этого фильтра.

См. http://www.opennet.ru/openforum/vsluhforumID3/108380.html#32
Вообще в приличном HDCD-фильтре должна быть опция по отключению -6dB нормализации. Не говоря уж о том, что активироваться там, где тэгов нет он просто не должен. Но там, где HDCD есть, результат корректен. Эти диски и должны быть в два раза тише, чем сигнал, который на них реально записан; просто особенность мастеринга HDCD.

По итогам - фильтр написали явно рабочий, но он недоработан. Не хватает во-первых принудительного отключения -6 dB преобразования, во-вторых логики, которая отключает фильтр, если тэги hdcd не найдены... Без этого в плеере использовать проблематично (впрочем, есть ли удобные плееры, умеющие фильтры ffmpeg вообще? Обычно там только gstreamer-фильтры...) Но найти в коллекции файлы и перегнать их в 24 бит, пропустив через этот фильтр можно уже сейчас.

С точки зрения результата - может уйти раздражающий клиппинг, который был при проигрывании HDCD-записи как обычного CD. После преобразования звук станет без искажений.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok) on 28-Июн-16, 16:49 
> При преобразовании в 16-ти битный формат записали старшие 4 бита: 0110.

Вы наверное отпечатались: в вашем примере будет 0011.

Вы не учитываете два факта:
1. Просто откинуть младшие биты нельзя - получим ошибку округления и существенные искажения. Те биты которые мы откидываем должны использоваться при формировании дитеринга. Как я уже говорил их частично можно сохранить использую нойз шейпинг и получить эквивалент 18 бит.
2. В каких условиях реальных условиях не хватает 16 бит? Вы вообще слышите последние 2 бита при прослушивании 16 битных записей при комфортной громкости? Вот тестовый файл на котором я проверяю цифровой аудиотракт на отсутствие ошибки округления: http://knk.square7.ch/dithering_test_2bit.flac Вы должны услышать музыку и равномерный/однородный шум на фоне. Если шум не однородный - где-то есть проблема с воспроизведением младших бит.

> По простому - нормализовать запись, выполнить компрессию, убедиться, что в итоге нет звуков громче, чем -3 dB, закодировать в 16 бит. Практически.. ну известно, что вышло из loudness war, звуки до 0 db и т.д.

Почему вы считаете, что нормализация по 0 dB это плохо?

> Как на одном диске записать и тихую, и громкую композицию без потерь, если выравнивать весь диск к одной громкости?

Никак. Это работа звукорежиссера. Если он не выронил - значит такова была его задумка. Если бы он хотел выровнять - то выровнял бы при мастеринге без всякого replaygain.

> Это нам сейчас хорошо, у нас есть replaygain.

Replaygain нужен для устранения клипинга после сжатия. Ранее подобной проблемы не было в принципе, так как поток (PCM) был не сжат.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok) on 28-Июн-16, 16:55 
> По итогам - фильтр написали явно рабочий, но он недоработан. Не хватает
> во-первых принудительного отключения -6 dB преобразования, во-вторых логики, которая
> отключает фильтр, если тэги hdcd не найдены... Без этого в плеере
> использовать проблематично (впрочем, есть ли удобные плееры, умеющие фильтры ffmpeg вообще?

mpv? Но он больше для видео. Возможно есть удобный frontend.

> С точки зрения результата - может уйти раздражающий клиппинг, который был при
> проигрывании HDCD-записи как обычного CD. После преобразования звук станет без искажений.

Я пока не все проверил, но похоже расширение пиков мало кто включал. Наверное из тех же соображений - что бы на обычном cd нормально звучало.

Лично я больше склоняюсь к тому, что по возможности лучше поискать варианты мастеринга без hdcd - как-то оно надежнее :)

В любом случае фильтр оказался полезным для выявления проблемных дисков.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

36. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok) on 28-Июн-16, 18:20 
> В каких условиях реальных условиях не хватает 16 бит

Это просто был пример, почему после hdcd-декодирования в 16 бит без дальнейших преобразований без сильных потерь не положить.

Дело не в том, что 16 бит не хватает, а что после hdcd-декодирования нужно делать компрессию, чтобы положить это снова в 16 бит. Которую в данном примере никто не делает.

> Почему вы считаете, что нормализация по 0 dB это плохо?

Потому, что там в итоге выходит "полочка". Несколько сэмплов максимальной амплитуды подряд. Потому что обрезали.. а 0 dB это просто потому, что громче не выходит (ну то есть выходит, в небольшой плюс можно даже выйти на аналоговом сигнале, но не на нескольких сэмплах подряд). И слышится такой жесткий клиппинг очень противно. Так-то я ничего не имею против максимального пика на 0 dB, но в реальности это не так. 3dB запаса придумали не просто так

> Replaygain нужен для устранения клипинга после сжатия

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

37. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok) on 28-Июн-16, 20:22 
> Дело не в том, что 16 бит не хватает, а что после hdcd-декодирования нужно делать компрессию, чтобы положить это снова в 16 бит.

При преобразовании HDCD в 16 бит мы по сути делаем тоже самое, что и звукорежиссер переводящий float в 16 бит - откидываем ту часть, которую все равно никто не слышит.

> Потому, что там в итоге выходит "полочка". Несколько сэмплов максимальной амплитуды подряд. Потому что обрезали..

У нас разное понимание термина нормализация: обычно в аудиоредакторах под этим понимают выставление самого большого пика на заданный уровень dB. То есть полочка в принципе не может образоваться от нормализации 0 dB. Она возможна только если попытаться дальше обрабатывать файл. Поэтому на промежуточных стадиях и используют нормализацию -3dB или -6dB, дабы не влезть в клипинг. Но для финальной стадии это не имеет смысла.

> Ну, вообще говоря клиппинг вообще невозможно устранить или обратить.

Верно для обычного (несжатого или сжатого без потерь) потока.
Проблема в том, что при кодировании с потерями, кодируется не просто сам сигнал, но его математическое описание. Поэтому возможна ситуация когда исходный сигнал был близок к 0dB, а декодируемый сигнал получится немного больше.

https://ru.wikipedia.org/wiki/ReplayGain

> Replaygain нужен для выравнивания громкости альбомов друг относительно друга при проигрывании

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

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от dq0s4y71 (??) on 29-Июн-16, 16:38 
> Если в лине ещё можно поток (pipe) выдёргивать прямо из консоли и
> в ruby его читать, то винде такое невозможно (ведь я прав,
> да?). Т.е. первая проблема при съёме данных с камеры и микрофона
> в винде и передачи их в Пандору.

А что, в винде  "ffmpeg ... -" не работает?

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру