| 1.1, Mihail Zenkov (ok), 11:44, 27/06/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 > hdcd - декодирует со звукового CD 16-разрядные PCM-данные c hdcd флагами в 20 разрядный PCM-поток;
Декодировщик добавили спустя двадцать лет. Кодировщика, очевидно, не будет. Слава патентам! Еще одна интересная технология была благополучна ими похоронена ...
| | |
| |
| 2.7, Аноним (-), 12:18, 27/06/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
Зачем тратить время на кодировщик который уже не актуален по всем техническим параметрам? Сейчас более актуален декодировщик, чтобы хотя бы раскодировать то что накодировали.
| | |
| |
| 3.13, Mihail Zenkov (ok), 14:18, 27/06/2016 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Так я о том и говорю - нет смысла писать кодировщик, когда cd-audio фактически умер.
> Сейчас более актуален декодировщик, чтобы хотя бы раскодировать то что накодировали.
Даже он не особо актуален, так как сам формат не получил широкого распространения.
| | |
| |
| 4.18, Stax (ok), 14:59, 27/06/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Это как сказать.
Иногда внезапно при проигрывании очередного диска можно увидеть, как загорается индикатор "hdcd". Даже когда на самом диске ничего не указано. Это я к тому, что их определенно больше, чем кажется, я совершенно случайно натыкался на hdcd диски, узнавая об этом уже при проигрывании.
А еще это важно, потому что без понимания, что это hdcd он воспроизводится не так хорошо (уровни громкости фрагментов друг относительно друга могут быть неправильные, возможен клиппинг и прочие неприятности). Формат "совместим" с не-HDCD проигрыванием только в том смысле, что звучать будет, но не совсем то, что записывали.
И т.к. все это переносится при любом loseless рипе и кодировании - flac, рипнутый с таких дисков тоже требует hdcd-aware декодера, чтобы звучать корректно. Без этого - звучит с огрехами. Так что либо надо во все проигрыватели поддержку hdcd при проигрывании, либо при рипе расшифровывать hdcd и превращать его в 24-х битный flac уже без этих странных технологий (там, конечно, 20 бит, но так не выйдет). В принципе, сейчас, когда есть декодер, можно пройтись по библиотеке и расшифровать найденные hdcd, перекодируя их в 24-х битные записи без hdcd.
| | |
| |
| 5.22, Mihail Zenkov (ok), 19:23, 27/06/2016 [^] [^^] [^^^] [ответить]
| +/– |
Хотел проверить сколько же реально hdcd у меня в коллекции.
Написал скрипт:
ffmpeg -v error -i "$1" -f wav - | md5sum
ffmpeg -v error -i "$1" -af hdcd -f wav - | md5sum
При декодировании с фильтром hdcd сумма всегда другая. Вероятно фильтр работает некорректно и вносит изменения даже там, где они не нужны :(
| | |
| |
| 6.25, Stax (ok), 21:03, 27/06/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Эээ не совсем. Это фильтр, если его активировали, он всегда работает. Выходной формат фильтра заявлен как 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 отличен от нуля, было преобразование.
| | |
| |
| 7.27, Mihail Zenkov (ok), 22:02, 27/06/2016 [^] [^^] [^^^] [ответить]
| +/– | |
В первом моем варианте оба выходных формата были s16le.
При варианте s24le сумма все равно разная.
ffmpeg -i "$1" -f s24le - | md5sum
ffmpeg -i "$1" -af hdcd -f s24le - | md5sum
| | |
| |
| 8.28, Stax (ok), 22:18, 27/06/2016 [^] [^^] [^^^] [ответить] | +/– | Ну ээ результат hdcd-декодирования в 16 бит положить невозможно Искажения буд... текст свёрнут, показать | | |
| |
| |
| 10.32, Stax (ok), 15:01, 28/06/2016 [^] [^^] [^^^] [ответить] | +/– | Будут элементарно Проще показать на примере, вместо вместо 24 бит - 8, вместо 1... большой текст свёрнут, показать | | |
| |
| |
| 12.36, Stax (ok), 18:20, 28/06/2016 [^] [^^] [^^^] [ответить] | +/– | Это просто был пример, почему после hdcd-декодирования в 16 бит без дальнейших п... текст свёрнут, показать | | |
|
|
|
| |
| 10.33, Stax (ok), 15:09, 28/06/2016 [^] [^^] [^^^] [ответить] | +/– | Ну кое-что Ясненько Вообще реальный проигрыватель по-моему смотрит на тэги т... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| 1.2, robux (ok), 11:44, 27/06/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Есть какая-нибудь годная кроссплатформенная обёртка для использования FFmpeg (только не Gstreamer) в виде библиотеки, чтобы просто подавать на вход сырые медиа данные и получать закодированные, не погружаться в адовый API FFmpeg'а?
| | |
| |
| 2.4, Аноним (-), 11:56, 27/06/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
обертка на каком языке (вообще, их как грязи на любом)? И чем плохо запускать его просто из командной строки?
| | |
| |
| 3.5, Аноним (-), 12:11, 27/06/2016 [^] [^^] [^^^] [ответить]
| +/– |
Вероятно, он хочет на Ruby для своего проекта Pandoranet. Там впрочем, довольно странная архитектура. Лучше бы разделить на модули, сделать основу да отдать остальные модули (типа видеосвязи, бухгалтерия и прочее) на откуп обществу.
| | |
|
| 2.8, Аноним (-), 12:22, 27/06/2016 [^] [^^] [^^^] [ответить]
| +11 +/– |
команды 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.
как-то так.
интерфейс понятен как интеллектуально - через ман, - так и интуитивно - интуиция подсказывает, что команды надо как-то ввести. скорее всего с клавиатуры.
лучше всяких визивигов и прочих мелкомягких плюшек.
поэтому как-то так...
| | |
| |
| 3.11, Аноним (-), 13:50, 27/06/2016 [^] [^^] [^^^] [ответить]
| +/– | |
>2. -f: закодировать це всё в матрёшку (mkv);
зачем это нужно, если формат контейнера и так определится по расширению?
| | |
| |
| 4.15, Аноним (-), 14:24, 27/06/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
на практике это можно не использовать, но в христоматийном примере оно должно фигурировать - ради пущей определённости.
| | |
|
| 3.21, robux (ok), 19:21, 27/06/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> команды 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) выводить видео во внутреннее окно.
Но такого фреймворка (кроме сговнявшегося Гстримера) я пока найти не могу.
| | |
| |
| 4.29, Аноним (-), 23:03, 27/06/2016 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Если в лине ещё можно поток (pipe) выдёргивать прямо из консоли и в ruby его читать, то винде такое невозможно (ведь я прав, да?).
Пайпы и возможность гонять произвольные данные через стандартные потоки ввода-вывода в винде есть. Умеют ли это виндовые сборки Ruby и ffmpeg -- вопрос отдельный.
| | |
| 4.38, dq0s4y71 (??), 16:38, 29/06/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Если в лине ещё можно поток (pipe) выдёргивать прямо из консоли и
> в ruby его читать, то винде такое невозможно (ведь я прав,
> да?). Т.е. первая проблема при съёме данных с камеры и микрофона
> в винде и передачи их в Пандору.
А что, в винде "ffmpeg ... -" не работает?
| | |
|
|
|
| 1.10, Аноним (-), 13:45, 27/06/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> CUDA
5 лет ждал. И хоть бы один Closed Source дал бы это за деньги в 2011!
| | |
| 1.19, 5kbps (ok), 15:45, 27/06/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Реализован API для ведения чёрного списка протоколов;
Эта самое нужное нововведение во всём релизе. Теперь при вскрытии очередной дыры пересборка не потребуется.
| | |
|
