форумы  помощь  поиск  регистрация  вход/выход  слежка

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

"Выпуск мультимедиа-пакета 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.dev/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ообщить модератору

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

	13. "Выпуск мультимедиа-пакета FFmpeg 3.1"	+3 +/–
	Сообщение от Mihail Zenkov (ok) on 27-Июн-16, 14:18
	Так я о том и говорю - нет смысла писать кодировщик, когда cd-audio фактически умер. > Сейчас более актуален декодировщик, чтобы хотя бы раскодировать то что накодировали. Даже он не особо актуален, так как сам формат не получил широкого распространения.
	Ответить | Правка | ^ к родителю #7 | Наверх | 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ообщить модератору

	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ообщить модератору

	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ообщить модератору

	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ообщить модератору

	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ообщить модератору

	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ообщить модератору

	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ообщить модератору

	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ообщить модератору

	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ообщить модератору

	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.dev/openforum/vsluhforumID3/108380.html#32 Вообще в приличном HDCD-фильтре должна быть опция по отключению -6dB нормализации. Не говоря уж о том, что активироваться там, где тэгов нет он просто не должен. Но там, где HDCD есть, результат корректен. Эти диски и должны быть в два раза тише, чем сигнал, который на них реально записан; просто особенность мастеринга HDCD. По итогам - фильтр написали явно рабочий, но он недоработан. Не хватает во-первых принудительного отключения -6 dB преобразования, во-вторых логики, которая отключает фильтр, если тэги hdcd не найдены... Без этого в плеере использовать проблематично (впрочем, есть ли удобные плееры, умеющие фильтры ffmpeg вообще? Обычно там только gstreamer-фильтры...) Но найти в коллекции файлы и перегнать их в 24 бит, пропустив через этот фильтр можно уже сейчас. С точки зрения результата - может уйти раздражающий клиппинг, который был при проигрывании HDCD-записи как обычного CD. После преобразования звук станет без искажений.
	Ответить | Правка | ^ к родителю #31 | Наверх | 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ообщить модератору

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ообщить модератору

	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ообщить модератору

	11. "Выпуск мультимедиа-пакета FFmpeg 3.1"	+/–
	Сообщение от Аноним (??) on 27-Июн-16, 13:50
	>2. -f: закодировать це всё в матрёшку (mkv); зачем это нужно, если формат контейнера и так определится по расширению?
	Ответить | Правка | ^ к родителю #8 | Наверх | 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ообщить модератору

	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ообщить модератору

	29. "Выпуск мультимедиа-пакета FFmpeg 3.1"	–3 +/–
	Сообщение от Аноним (??) on 27-Июн-16, 23:03
	> Если в лине ещё можно поток (pipe) выдёргивать прямо из консоли и в ruby его читать, то винде такое невозможно (ведь я прав, да?). Пайпы и возможность гонять произвольные данные через стандартные потоки ввода-вывода в винде есть. Умеют ли это виндовые сборки Ruby и ffmpeg -- вопрос отдельный.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	38. "Выпуск мультимедиа-пакета FFmpeg 3.1"	+/–
	Сообщение от dq0s4y71 (??) on 29-Июн-16, 16:38
	> Если в лине ещё можно поток (pipe) выдёргивать прямо из консоли и > в ruby его читать, то винде такое невозможно (ведь я прав, > да?). Т.е. первая проблема при съёме данных с камеры и микрофона > в винде и передачи их в Пандору. А что, в винде  "ffmpeg ... -" не работает?
	Ответить | Правка | ^ к родителю #21 | Наверх | 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ообщить модератору

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

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

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

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

19. "Выпуск мультимедиа-пакета FFmpeg 3.1"	+/–
Сообщение от 5kbps (ok) on 27-Июн-16, 15:45
>  Реализован API для ведения чёрного списка протоколов; Эта самое нужное нововведение во всём релизе. Теперь при вскрытии очередной дыры пересборка не потребуется.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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