LINUX.ORG.RU

обсуждение deadbeef

 


9

9

Данная тема посвящена обсуждению проекта deadbeef player.

Официальный сайт проекта: http://deadbeef.sf.net

Разработка, вики, багтрекер: https://github.com/Alexey-Yakovenko/deadbeef

★★★★★

Последнее исправление: waker (всего исправлений: 3)
Ответ на: комментарий от anonymous

LGPLv3, если быть точным. В чём проблема?

значит еще раз лицензию поменяли. я точно помню, что было GPL3.

версия 0.2, которую я использую, под GPL2. не LGPL.

проблема в том, что я не использую код под [L]GPL3 в своем проекте.

О каких функциях и какой стабильности идёт речь? Уже лет 8 использую mplayer. Серьёзных проблем со звуком не встречал.

функции: sample accurate seeking, gapless playback, complete tagging support, cuesheet support

стабильность: ffmpeg вылетает при попытке играть многие (кривые) файлы.

в случае с mplayer наверное не проблема — на каждый файл запускается новый процесс mplayer. в случае с ddb - это выкидывает весь плеер.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

значит еще раз лицензию поменяли. я точно помню, что было GPL3.

Не было такого. Вот официальный анонс http://wildmidi.sourceforge.net/?id=news&page=5

проблема в том, что я не использую код под [L]GPL3 в своем проекте.

Это и не требуется.

функции: sample accurate seeking, gapless playback, complete tagging support, cuesheet support

Это функции плеера, а не библиотеки с кодеком. И да, в mad, vorbis, flac этого тоже нет.

стабильность: ffmpeg вылетает при попытке играть многие (кривые) файлы.

Опять абстрактные кривые файлы.

anonymous
()
Ответ на: комментарий от anonymous

Не было такого. Вот официальный анонс http://wildmidi.sourceforge.net/?id=news&page=5

ну значит попутал. давно это было. в любом случае, LGPL3 тоже не устраивает.

Это и не требуется.

каким образом?

Это функции плеера, а не библиотеки с кодеком.

библиотека ffmpeg не позволяет реализовать данные функции.

И да, в mad, vorbis, flac этого тоже нет.

есть.

Опять абстрактные кривые файлы.

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

waker ★★★★★
() автор топика
Последнее исправление: waker (всего исправлений: 2)
Ответ на: комментарий от waker

в любом случае, LGPL3 тоже не устраивает

А почему? Неужто есть желание продаться какой-нибудь конторе?

Relan ★★★★★
()
Ответ на: комментарий от waker

ну значит попутал. давно это было. в любом случае, LGPL3 тоже не устраивает.

Это какая-то ничем не обоснованная фобия. А то сразу падает и вылетает.

каким образом?

динамической линковкой.

библиотека ffmpeg не позволяет реализовать данные функции.

4.2

есть.

Точно? Тогда что делает парсер cue в playlist.c? Велосипед?

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

А для vorbis, mad, flac есть?

anonymous
()
Ответ на: комментарий от anonymous

Это какая-то ничем не обоснованная фобия. А то сразу падает и вылетает.

щито?

динамической линковкой.

я это не люблю.

4.2

пруф в виде любого плеера, который с использованием ffmpeg умеет gapless и cue с перемоткой?

Точно? Тогда что делает парсер cue в playlist.c? Велосипед?

парсеров cue в кодеках нет. поддержка gapless/sample-accurate-seeking в кодеках есть.

А для vorbis, mad, flac есть?

эти кодеки очень качественные. мне пока не попадалось файлов, на которых они вылетают.

waker ★★★★★
() автор топика
Ответ на: комментарий от Relan

А почему?

просто не хочу примешивать в кодобазу код под [l]gpl3. хотя если бы wildmidi был стабильный (без вылетов и утечек) в виде .so во всех дистрах - я бы использовал. но ситуация другая. мне придется его патчить и распространять, как в виде бинарников, так и в виде исходников.

Неужто есть желание продаться какой-нибудь конторе?

а что, кто-то покупает?

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

щито?

Так чем LGPLv3 пугает?

я это не люблю.

Так с этого и надо начинать, а не валить на кривые библиотеки.

пруф в виде любого плеера, который с использованием ffmpeg умеет gapless и cue с перемоткой?

qmmp? audacious?

парсеров cue в кодеках нет. поддержка gapless/sample-accurate-seeking в кодеках есть.

Ну вот. -1 аргумент. Но всё-таки интересуют названия функции API того же flac, где сие реализовано.

эти кодеки очень качественные. мне пока не попадалось файлов, на которых они вылетают.

А если найду?

anonymous
()
Ответ на: комментарий от anonymous

А если найду?

Не конструктивно. Примеры в студию.

anonymous
()
Ответ на: комментарий от anonymous

Так чем LGPLv3 пугает?

кого пугает? мне он просто не нужен.

Так с этого и надо начинать, а не валить на кривые библиотеки.

зачем исключать одно ради другого?

qmmp? audacious?

они используют ffmpeg так же как ddb. для всякой экзотики. там где есть gapless - нету ffmpeg. другие пруфы будут?

Но всё-таки интересуют названия функции API того же flac, где сие реализовано.

FLAC__stream_decoder_seek_absolute

А если найду?

тогда можно будет вернуться к этому разговору.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

кого пугает? мне он просто не нужен.

Почему?

зачем исключать одно ради другого?

Ну да, необоснованно таскать с собой, конечно, лучше.

они используют ffmpeg так же как ddb. для всякой экзотики. там где есть gapless - нету ffmpeg. другие пруфы будут?

Что такое gapless? Ты уж потрудись тогда объяснить, что ты вкладываешь в это понятие.

FLAC__stream_decoder_seek_absolute

av_seek_frame? Впрочем, зачем оно, например, для wma? Неужели какой-то идиот будет использовать его вместе с cue?

anonymous
()
Ответ на: комментарий от anonymous

Почему?

иди проспись. для ненужности причины не нужны.

Что такое gapless? Ты уж потрудись тогда объяснить, что ты вкладываешь в это понятие.

http://en.wikipedia.org/wiki/Gapless_playback

av_seek_frame? Впрочем, зачем оно, например, для wma? Неужели какой-то идиот будет использовать его вместе с cue?

av_seek_frame делает совсем другое.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

иди проспись. для ненужности причины не нужны.

Хорошо, а в чём нужность LGPLv2, что ради неё столько секаса?

http://en.wikipedia.org/wiki/Gapless_playback

Вопрос не снят. Зачем для этого нужен точный поиск? Играй всё подряд и не парься.

av_seek_frame делает совсем другое.

Ты уверен? Вижу, что нет. И как там на счёт wma? Ему-то accurate seeking нафиг сдался?

anonymous
()
Ответ на: комментарий от anonymous

Хорошо, а в чём нужность LGPLv2, что ради неё столько секаса?

я уже отвечал на это. [L]GPL2 нужен, чтобы позволить другим проектам, использующим [L]GPL2, линковаться к моему коду.

также, мне просто не нравится GPL3. мне и GPL2 не нравится, но это меньшее зло.

Вопрос не снят. Зачем для этого нужен точный поиск? Играй всё подряд и не парься.

кроме проигрывания, в плеерах обычно есть перемотка. если использовать ffmpeg - невозможно узнать куда он перематывает с точностью до сэмпла, и нельзя перемотать на нужный сэмпл. всегда есть погрешность. в итоге происходит рассинхронизация. все это накладывается на разные особенности форматов, когда нужно пропустить нужное количество сэмплов в начале и конце файла. после рассинхронизации это уже невозможно, и gapless playback не работает. в случае с cue то же самое.

Ты уверен? Вижу, что нет.

я уверен. av_seek_frame делает перемотку на начало фрейма. фрейм в ffmpeg - это не сэмпл, это блок из файла, содержащий множество сэмплов.

И как там на счёт wma? Ему-то accurate seeking нафиг сдался?

я не очень понимаю, почему ты зациклился именно на wma (это одинаково для всех форматов), но вообще это нужно для cue. чтобы между треками в image+cue был gapless playback.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

я уже отвечал на это. [L]GPL2 нужен, чтобы позволить другим проектам, использующим [L]GPL2, линковаться к моему коду.

Я не про смену лицензии говорю, а про линковку. Программа под GPLv2/BSD/*любая коммерческая* спокойно линкуется с библиотекой под LGPLv3. И не надо вводить тут людей в заблуждение.

кроме проигрывания, в плеерах обычно есть перемотка. если использовать ffmpeg - невозможно узнать куда он перематывает с точностью до сэмпла, и нельзя перемотать на нужный сэмпл. всегда есть погрешность. в итоге происходит рассинхронизация. все это накладывается на разные особенности форматов, когда нужно пропустить нужное количество сэмплов в начале и конце файла. после рассинхронизации это уже невозможно, и gapless playback не работает. в случае с cue то же самое.

Перемотка, как минимум, с точностью до секунды обеспечивается практически любой библиотекой. Для форматов wma и прочих пережитков прошлого это более чем достаточно. Кроме того, из твоего поста не понятно, каким образом перемотка связанна с этим твоим gapless? Только по ушам новичкам ездить, если только. Для cue, кстати, тоже не нужно. Файл один, так что бери и играй его до конца.

я уверен. av_seek_frame делает перемотку на начало фрейма. фрейм в ffmpeg - это не сэмпл, это блок из файла, содержащий множество сэмплов.

Т.е. asf_seek по-твоему прыгает на сэмпл? Мда. А зачем тогда миллисекунды передаёшь? Сколько там в одной миллисекунде сэмплов?

я не очень понимаю, почему ты зациклился именно на wma (это одинаково для всех форматов), но вообще это нужно для cue. чтобы между треками в image+cue был gapless playback.

И я о том. Зачем пытаться прыгать в конце каждого трека, когда можно просто проиграть один файл до конца? Прикинь, даже seek дёргать не потребуется.

anonymous
()
Ответ на: комментарий от anonymous

Зачем пытаться прыгать в конце каждого трека, когда можно просто проиграть один файл до конца? Прикинь, даже seek дёргать не потребуется.

Если бы я делал плеер с поддержкой cue, я бы ввёл абстракцию над cue, которая отдавала плееру отдельные песни, ведь порядок воспроизведения может быть любой. Вместе с тем мне бы не хотелось слушать щелчки между песнями, если я заказал последовательное воспроизведение. Реализация твоей идеи возможно даже даст меньшее использование CPU, но значительно усложнит реализацию, потому что код станет более запутанным.

Если ты действительно веришь в корректность своей идеи, реализуй её, оформи в виде патча и отошли автору. С ссылкой на реализацию твои слова будут более значимы.

i-rinat ★★★★★
()
Ответ на: комментарий от Anon

А я бы не делал поддержку cue, т.к. это ненужная фича.

Знаешь, сколько людей так скажут про ИК-спектроскопию? :)

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

Я не про смену лицензии говорю, а про линковку. Программа под GPLv2/BSD/*любая коммерческая* спокойно линкуется с библиотекой под LGPLv3. И не надо вводить тут людей в заблуждение.

спасибо что просветил.

Перемотка, как минимум, с точностью до секунды обеспечивается практически любой библиотекой. Для форматов wma и прочих пережитков прошлого это более чем достаточно. Кроме того, из твоего поста не понятно, каким образом перемотка связанна с этим твоим gapless?

перечитай еще раз то на что отвечал. там подробно все написано.

Т.е. asf_seek по-твоему прыгает на сэмпл?

нет. тоже на фрейм. но я знаю на какой сэмпл он прыгает, и корректирую рассинхронизацию. через public api ffmpeg эта информация недоступна.

Мда. А зачем тогда миллисекунды передаёшь? Сколько там в одной миллисекунде сэмплов?

в одной миллисекунде samplerate/1000 сэмплов.

например, при samplerate 44100, в одной миллисекунде 44.1 сэмплов ровно. а при 22050 — 22.05 сэмплов.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

спасибо что просветил.

И что на этот раз мешает выкинуть старый wildmidi и заюзать ванильный?

перечитай еще раз то на что отвечал. там подробно все написано.

Начинается. Там не обоснована необходимость точности перемотки для всяких «экзотически» форматов внутри ffmpeg, кроме какой-то «рассинхронизации». Чего с чем рассинхронизации? Непонятно. Впрочем, для использования вместе с cue она тоже не обоснована.

нет. тоже на фрейм. но я знаю на какой сэмпл он прыгает, и корректирую рассинхронизацию. через public api ffmpeg эта информация недоступна.

Как ты можешь знать фрейм, если передаёшь миллисекунды? У тебя погрешность уже 22.05 сэмпла просто так.

через public api ffmpeg эта информация недоступна.

Точно?

например, при samplerate 44100, в одной миллисекунде 44.1 сэмплов ровно. а при 22050 — 22.05 сэмплов.

А во фрейме сколько сэмплов?

anonymous
()
Ответ на: комментарий от anonymous

И что на этот раз мешает выкинуть старый wildmidi и заюзать ванильный?

то же что и раньше — нежелание иметь [l]gpl3 код в тарболе.

насчет ванильного wildmidi я не уверен. не факт, что там исправили все баги.

Там не обоснована необходимость точности перемотки для всяких «экзотически» форматов внутри ffmpeg

такой необходимости нет. для форматов, которые играют через ffmpeg, не поддерживается gapless.

Непонятно. Впрочем, для использования вместе с cue она тоже не обоснована.

после изучения матчасти все должно встать на свои места.

Как ты можешь знать фрейм, если передаёшь миллисекунды? У тебя погрешность уже 22.05 сэмпла просто так.

да, извини, я совсем забыл, что wma плагин не умеет этого. перепутал с каким-то другим. во многих других плагинах сначала делается seek на фрейм, а потом корректировка.

Точно?

да.

А во фрейме сколько сэмплов?

сколько угодно. в случае WMA как раз поэтому и не поддерживается sample accurate seeking. для CBR файлов я смог реализовать, а для VBR не получилось. также, у меня не получилось определить VBR vs CBR. я мог реализовать gapless путем чтения файла сначала целиком при каждом seek, как в случае с sid, но будет очень тормозить. в sid просто вообще другого выбора не было.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

то же что и раньше — нежелание иметь [l]gpl3 код в тарболе.

Опять 25. Линковка динамическая. lgplv3 - внешняя библиотека. Кто тебя заставляет делать плагин под gplv3?

такой необходимости нет. для форматов, которые играют через ffmpeg, не поддерживается gapless.

Так gapless или accurate seeking? Это разные вещи вообще-то.

после изучения матчасти все должно встать на свои места.

Таки нет. Загоняю ape в ffplay и наслаждаюсь всем диском целиком. ЧЯДНТ?

да.

Про пруф я уже не смею спрашивать.

сколько угодно. в случае WMA как раз поэтому и не поддерживается sample accurate seeking. для CBR файлов я смог реализовать, а для VBR не получилось. также, у меня не получилось определить VBR vs CBR. я мог реализовать gapless путем чтения файла сначала целиком при каждом seek, как в случае с sid, но будет очень тормозить. в sid просто вообще другого выбора не было.

Какой sample ассurate, если ты миллисекунды передаёшь?

anonymous
()
Ответ на: комментарий от anonymous

Опять 25. Линковка динамическая. lgplv3 - внешняя библиотека. Кто тебя заставляет делать плагин под gplv3?

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

Так gapless или accurate seeking? Это разные вещи вообще-то.

1е не работает без 2го.

Таки нет. Загоняю ape в ffplay и наслаждаюсь всем диском целиком. ЧЯДНТ?

ffplay не разбивает файл на треки, в нем это 1 трек.

в deadbeef image+cue это несколько треков в плейлисте, работа с которыми производится как с отдельными файлами. их можно конвертировать, например, в отдельные треки в FLAC, без потери точности в позиционировании, можно смотреть per-track metadata, производить поиск, отдельные обложки на каждый трек, и прочее.

Какой sample ассurate, если ты миллисекунды передаёшь?

в случае с WMA да. в других форматах другая ситуация. везде все индивидуально.

waker ★★★★★
() автор топика
Ответ на: комментарий от punya

почему ты не хочешь юзать динамическую линковку?

а почему я должен хотеть ее юзать?

waker ★★★★★
() автор топика
Ответ на: комментарий от punya

в россии есть бабка которая принципиально не юзает толчек. ты такого же плана?

добро пожаловать к клуб.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

т.е. ты создал себе без причины принцип? хипстер или как там их называют?

punya ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.