forum.opennet.ru

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

Оглавление

Сравнение видеокодеков Ogg Theora и H.264, opennews (??), 26-Фев-10, (0) [смотреть все]

Т е разработчики Theora могут починить свой кодек Ну и сколько лет им на это , add (??), 16:44 , 26-Фев-10, (1) –5 //

чего починить сказали же что при НАРМАЛЬНЫХ битрейдах а не маленьких -- кажес, polymorphm1 (ok), 19:17 , 26-Фев-10, (17) –1 //

При большом битрейте любой вменяемый алгоритм дает почти неотличимое от оригинал, User294 (ok), 19:55 , 26-Фев-10, (19) //

вот и фиг поэтому предлагаю прекратить эти войны за 10 и задуматься о других , polymorphm1 (ok), 20:10 , 26-Фев-10, (21) –2

Что - фиг Эти 10 на графиках и отличают смотрябельную картинку от блевотины из , User294 (ok), 20:24 , 26-Фев-10, (25) +2

вот как раз и нет эти 10 отличают две картинки -- если задасться целью их прист, polymorphm1 (ok), 20:30 , 26-Фев-10, (27) –2

Да, только разница в том что картинку где 10 левизны смотреть очень неприятно , User294 (ok), 20:43 , 26-Фев-10, (34) +1

в погоне за созданием самых лучших программ -- зачастую люди начинают игнориро, polymorphm1 (ok), 20:28 , 26-Фев-10, (26) +1

У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем , User294 (ok), 20:50 , 26-Фев-10, (35)

Убило и разорвало То есть существуют алгоритмы сжатия, которые не ищут повторны, anonymous (??), 00:32 , 27-Фев-10, (44) +1

Вот что значит знание - сила DСуществуют Вы прикиньте Тогда дайте ее плиз гос, User294 (ok), 18:14 , 27-Фев-10, (61)

gt оверквотинг удален Ха не надо ля-ля данными может быть и байт позже он може, Аноним (-), 18:13 , 01-Мрт-10, (83)

Хреново удален Хаффман грубо говоря пытается кодировать более часто встречающиес, User294 (ok), 03:40 , 02-Мрт-10, (89)

gt оверквотинг удален Алгоритм Лемпеля-зива не 171 ищет повторные данные в п, PereresusNeVlezaetBuggy (ok), 01:18 , 27-Фев-10, (47)

А английская вика например пишет именно так Хоть я и взял из головы, но перепро, User294 (ok), 20:07 , 27-Фев-10, (65)

Ну, перепиши PNGImageReader java и PNGImageWriter java на сях, посмотрим, за ско, iZEN (ok), 20:19 , 27-Фев-10, (67) –2

А что, libpng - уже отменили Или почему вам можно взять готовое а мне - нет Дв, User294 (ok), 20:40 , 27-Фев-10, (71)

Я хочу сказать, что библиотеки для обработки изображения есть не только на C C , iZEN (ok), 01:30 , 28-Фев-10, (77) –1

По-моему вы хотели сказать что вы не умно потролили и при этом забавно обломалис, User294 (ok), 05:02 , 28-Фев-10, (78)
Притом, что в PNG используется СЖАТИЕ без потерь Такие же кодеки на Java есть, iZEN (ok), 13:19 , 28-Фев-10, (79) –1
Круто А почему вообще каким-то супербогам должно быть можно загонять меня в фик, User294 (ok), 21:55 , 01-Мрт-10, (85)
Это доказывает то, что можно делать почти всё Оптимизация и ускорение на J2ME с, iZEN (ok), 14:11 , 02-Мрт-10, (91)
Да хрен там System-wide кодеки - нельзя А standalone плееры, смотрелки и т п , User294 (ok), 14:47 , 02-Мрт-10, (92)

если перед использованием кодека мне еще надо где то там подкрутить параметры-на, sluge (ok), 11:57 , 27-Фев-10, (54) //

Битрейт-то Подкрутить Нет, _тебе_ не надо Пользуйся просто , не мучаяйся таа, Andrey Mitrofanov (?), 13:24 , 27-Фев-10, (55)
У любой прогрммы как правило есть настройки по умолчанию Так что если впадлу кр, User294 (ok), 20:19 , 27-Фев-10, (66)

Зато аудиокодек у OGG получился лучше, чем у MPEG овцев Для меня он важнее виде, Zenitur (?), 16:52 , 26-Фев-10, (2) –3 //

OGG нужно сравнивать не с mpeg, а с тем же FLAC или Monkeys Audio , Rhino (?), 17:29 , 26-Фев-10, (5) –5 //

OGG - это контейнер Звук - это vorbis Аудиокодек у OGG - вообще безграмотный, аноним (?), 18:10 , 26-Фев-10, (10) +6
Извините конечно, но вы сравнили жопу с пальцем FLAC и Monkeys Audio - это форма, Cykooz (?), 18:13 , 26-Фев-10, (12) +3 //

Честно говоря, не понимаю двух вещей 1 Зачем нужен FLAC, если кодек в него код, Zenitur (?), 18:30 , 26-Фев-10, (15) –3

1 Остальные кодеры тоже кодируют только из WAV А ZIP, да и другие неспециализи, h31 (ok), 19:15 , 26-Фев-10, (16) +1

И это с винтами по 2 Терабаба , pavlinux (ok), 20:05 , 26-Фев-10, (20)

Павлин, 1 А ты цены на винты на 2Тб видел 2 Если ты думаешь что 2Тб нельзя зас, User294 (ok), 20:36 , 26-Фев-10, (30) +1

Не надо лохматить бабушку винт на 500 Гб стоит 90 в моем городе по-крайней м, Анон (?), 22:58 , 27-Фев-10, (76)

а вы в курсе что вероятность выхода из строя такого массива из 4-х винчестеров , аноним (?), 07:10 , 01-Мрт-10, (82)
Хороший рецепт как сделать дорого, жруче и ненадежно D Вот только вы представл, User294 (ok), 03:51 , 02-Мрт-10, (90)

8212 Известно, 8212 ответил Швондер, 8212 но общее собрание, рассмо, iav (ok), 20:43 , 26-Фев-10, (33) +4

Да, ушел в нирвану, купил SSD на 64 Гб и радуюсь как пионер пилотке Остальное сб, pavlinux (ok), 20:51 , 26-Фев-10, (36)

Попобуй сгрузить радужные таблицы например Да, Павлин, мы его видели Вот пер, User294 (ok), 20:24 , 27-Фев-10, (68)

Меня только дети и пенсионеры любят , pavlinux (ok), 21:13 , 27-Фев-10, (75)

У кого винты на 2 терабаба, а у кого SSD на 32 GB, ну или самые большие винчесте, фвфвм (?), 18:17 , 27-Фев-10, (62)

А чего это у меня 2 5 хитач на полтерабайта на столе лежит oO, User294 (ok), 20:28 , 27-Фев-10, (69)

Ну так FLAC жмет аудио примерно как и ZIP, тоже сжатие без потерь т е распаков, User294 (ok), 20:14 , 26-Фев-10, (23)

Слухай это мысля Надо замутить новый формат WZP WGZ WBZ WRR И к нему , pavlinux (ok), 21:26 , 26-Фев-10, (38) –2

Ну так FLAC нечто такое и делает, все хорошее уже придумано до вас Некоторые пл, User294 (ok), 21:55 , 26-Фев-10, (40)

Да ну Музыку давно слушал 1 канал Тыц-тыц-тыц-тыц - 4 такта по 180 раз 2 , pavlinux (ok), 22:23 , 26-Фев-10, (41) +3

Павлин, не тормози Ты вообще видел когда-нибудь что с ADC валится Несколько мл, User294 (ok), 00:39 , 27-Фев-10, (45)

а есть ли примеры песен в неком MIDI с downloadable samples по идее ничего н, JL2001 (ok), 02:45 , 27-Фев-10, (49)

Ага, щам музыканты так тебе и выложили Это же самое дорого что у них есть, хр, pavlinux (ok), 05:07 , 27-Фев-10, (51) +1
У MIDI с downloadable samples есть много проблем В частности единого популярног, User294 (ok), 20:37 , 27-Фев-10, (70)

Если быть ещё точнее, контейнер не WAV, а RIFF , x0r (??), 04:31 , 27-Фев-10, (50)

Факт WAV один из его подвидов AVI тоже , User294 (ok), 20:56 , 27-Фев-10, (73)

MPEG1 это и есть звук MP3 это есть MPEG1 ver 3 , pavlinux (ok), 21:34 , 26-Фев-10, (39)

MPEG 1 и видео тоже было me вспомнил любимый в детстве C C и потерял мысль, PereresusNeVlezaetBuggy (ok), 01:26 , 27-Фев-10, (48)

ложь du -b tmp Шопен track01 cdda 29389743 tmp Шопен track01 cdda fl, edo (ok), 09:17 , 27-Фев-10, (53)

А есть возможность потестить ace Когда-то конкурировал с rar ом давно и вро, фвфвм (?), 18:25 , 27-Фев-10, (63)

Бред Сравнивать кодек сжатия с потерями с кодеками сжатия без потерь , Аноним (-), 18:13 , 26-Фев-10, (13) +1

Какой из четырёх , iZEN (ok), 17:38 , 26-Фев-10, (6) //

все , аноним (?), 18:13 , 26-Фев-10, (14)

Жаль, что Dirac показал такой низкий результат - , RedRat (ok), 17:14 , 26-Фев-10, (3) +2 //

А кто его улучшением занимался то Wavelet-ы - это новое, малоизученное направле, User294 (ok), 20:21 , 26-Фев-10, (24) //

вейвлеты хороши масштабированием грубо говоря, из одного потока можно сразу выдр, аноним (?), 21:18 , 26-Фев-10, (37)

Зато свободный А вот было бы еще неплохо получить побольше сравнительной информ, azure (ok), 17:21 , 26-Фев-10, (4) //

Так Ogg Theora и основана на VP3 от On2 Technologies http x264dev multimedia c, Rhino (?), 17:46 , 26-Фев-10, (8) //

Чудная статейка, почитал и много понял , Хоменко (ok), 01:11 , 27-Фев-10, (46) +1

И что я выдал о_О Речь шла про аудио кодек, насколько я понял Сравнивался, Rhino (?), 17:50 , 26-Фев-10, (9) //

FLAC это тоже кодек от проекта Ogg Если хотите с чем-то сравнивать Vorbis, сравн, pkunk (ok), 19:19 , 26-Фев-10, (18) //

Конвертирую Audio CD с помощью GRIP в M4A и не испытываю трудности с прослушиван, iZEN (ok), 20:11 , 26-Фев-10, (22) –3

Ну вы купили телефон от одной из наиболее копирастичных контор в мире которая к, User294 (ok), 20:32 , 26-Фев-10, (28) +2

Мне это не о чё не говорит Я заплатил деньги 8212 я купил вещь Как говоритс, iZEN (ok), 13:29 , 27-Фев-10, (56)

Зато мне это кой-что говорит Что перед нами безмозглый хомячок который не особо, User294 (ok), 17:31 , 27-Фев-10, (59) –1

верной дорогой идёшь индустрия consumer-электроники не забудит твоих трудов , polymorphm1 (ok), 20:35 , 26-Фев-10, (29)

И скажет спасибо за его бабло Правильно, пусть садится на иглу покрепче, чтобы , User294 (ok), 20:39 , 26-Фев-10, (32) +1

Какая игла с M4A Ты о чём Если вороне говорят Голубушка, как хороша , то ест, iZEN (ok), 13:44 , 27-Фев-10, (57) –1

Ну, обычно реализуют все семейство мпегов И роялти платят И уж не думаете ли в, User294 (ok), 17:38 , 27-Фев-10, (60)

gt оверквотинг удален Мне и тебе никто не запрещает использовать купленные вещ, iZEN (ok), 18:31 , 27-Фев-10, (64)

Что-то слишком дорогой и неудобный молоток, однако P , User294 (ok), 20:53 , 27-Фев-10, (72)

к слову сказать мой телефон поддерживает форматы WAV ADPCM32 и WAV ADPCM64 не , polymorphm1 (ok), 20:38 , 26-Фев-10, (31)

А мой даже midi играть умеет , XoRe (ok), 00:20 , 27-Фев-10, (43)

Интересно, Nokia N900 может нормально воспроизвести MIDI без проприетарных блобо, iZEN (ok), 14:01 , 27-Фев-10, (58)

Не заморачивался вопросом Верите ли, я не пробовал проиграть штатным плеером ни, User294 (ok), 21:09 , 27-Фев-10, (74)

Я таких расширений-то не знаю На J2ME-девайсах MIDI, как и другие медиаформаты , iZEN (ok), 13:25 , 28-Фев-10, (80)

Ключевая фраза ЕСЛИ СОИЗВОЛИЛ То есть де-факто производитель УЖЕ включил поддер, kvark (??), 02:01 , 01-Мрт-10, (81)

Зачем включать заведомо убогие кодеки, когда доступны более качественные Ни оди, iZEN (ok), 21:12 , 01-Мрт-10, (84) –1

Я и смотрю, ворбис такой убогий что заруливает большую часть остальных при слепы, User294 (ok), 22:10 , 01-Мрт-10, (87)

И что дальше Ну да, по мнению леммингов круто когда можно выбрать из полутора н, User294 (ok), 22:05 , 01-Мрт-10, (86)

А кто сказал, что у меня N900 , XoRe (ok), 01:48 , 02-Мрт-10, (88)

У меня плееру 4 года Ogg как играл так и играет Просто все раньше грабили диск, devlink (?), 22:57 , 26-Фев-10, (42)

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

1. "Сравнение видеокодеков Ogg Theora и H.264" –5 +/–

Сообщение от add (??), 26-Фев-10, 16:44

Т.е. разработчики Theora могут "починить" свой кодек?
Ну и сколько лет им на это потребуется?Или они специально тормозят?

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

17. "Сравнение видеокодеков Ogg Theora и H.264" –1 +/–

Сообщение от polymorphm1 (ok), 26-Фев-10, 19:17

> Т.е. разработчики Theora могут "починить" свой кодек?
> Ну и сколько лет им на это потребуется?Или они специально тормозят?
чего починить? сказали же что при НАРМАЛЬНЫХ битрейдах (а не маленьких) -- кажество почти неотличимо . зато выиграшь при нагрузке на процессор .

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

19. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 26-Фев-10, 19:55

При большом битрейте любой вменяемый алгоритм дает почти неотличимое от оригинала качество. А при очень большом (ака несжатом) потоке и вовсе нам валится оригинал :)

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

21. "Сравнение видеокодеков Ogg Theora и H.264" –2 +/–

Сообщение от polymorphm1 (ok), 26-Фев-10, 20:10

вот и фиг!
поэтому предлагаю прекратить эти "войны за 10%" и задуматься о других аспектах (разницца которых не в 10%)

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

25. "Сравнение видеокодеков Ogg Theora и H.264" +2 +/–

Сообщение от User294 (ok), 26-Фев-10, 20:24

>вот и фиг!
Что - фиг?
>поэтому предлагаю прекратить эти "войны за 10%" и задуматься о других аспектах
>(разницца которых не в 10%)
Эти 10% на графиках и отличают смотрябельную картинку от блевотины из квадратиков и т.п. артефактов если что. А чтобы картинку того же качества с теорой пропхать - надо сильно задрать битрейт. А вот платить за вагон лишнего траффа всем лениво, как и больше хардов покупать, etc. Улавливаете в чем проблема? Миру нужен кодек не хуже или не сильно хуже H.264 но без всяких вымогателей роялти за воздух и прочее размешение роликов на серверах. Потому то и наблюдается данная возня.

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

27. "Сравнение видеокодеков Ogg Theora и H.264" –2 +/–

Сообщение от polymorphm1 (ok), 26-Фев-10, 20:30

>Эти 10% на графиках и отличают смотрябельную картинку от блевотины из квадратиков
>и т.п. артефактов если что.
вот как раз и нет.
эти 10% отличают две картинки -- если задасться целью их пристально сравнивать...

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

34. "Сравнение видеокодеков Ogg Theora и H.264" +1 +/–

Сообщение от User294 (ok), 26-Фев-10, 20:43

Да, только разница в том что картинку где 10% левизны смотреть очень неприятно. Ну, конечно, цвет и контуры предметов в этой мазне из квадратиков будут иметь что-то общее с оригиналом, совпадая на 90%, так что на графике разница будет 10%. Но вот смотреть глазами на это без рвотных позывов будет ой как нелегко. А если на стопкадр посмотреть - тут уж наверняка стошнит т.к. вы увидите не картинку а набор квадратиков и т.п. артефактов сжатия.

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

26. "Сравнение видеокодеков Ogg Theora и H.264" +1 +/–

Сообщение от polymorphm1 (ok), 26-Фев-10, 20:28

>вот и фиг!
>
>поэтому предлагаю прекратить эти "войны за 10%" и задуматься о других аспектах
>(разницца которых не в 10%)
в погоне за созданием "самых лучших программ" -- зачастую люди начинают игнорировать все остальные характеристики своего ПО, кроме как "основной" характеристики...
(а все "НЕосновные" характеристики в итоге создают в таких случаях -- не слабую савакупность общего говна)
есть даже такая пословица "лучший -- враг хорошего!"...
давайте напимер отвлечёмся от ["самого лучшего"] Mkv/H.264 и ["НЕсамого лучшего"] Ogg/Theora... и рассмотрим другие примеры:
gzip -- как вполне хороший ["НЕсамый лкчший"] архиватор .. и lzma который сжимает сущетвенно дольше (в 50~100 раз) чем разжимает (а чащще бывает что нужно чтобы это было примерно одинакого . а иногда наоборот лучше чтобы подольше сжать и побыстрее разжать, в этом случае lzma более оправдан)
apache2 -- как "самый лучший" www-сервер -- но оказывается он не реализует концепцию-конечного-автомата (в отличии от nginx и lighttpd) и совсем базово реализует fcgi (а какже unix-way ?) . и то что apache2 разбух -- это не даёт ему красоты.
... да куча примеров, и во всех них -- оптимальным выбором будет использование чегото хорошего, но "НЕсамого лучшего".. :-)

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

35. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 26-Фев-10, 20:50

>сжимает сущетвенно дольше (в 50~100 раз) чем разжимает (а чащще бывает
>что нужно чтобы это было примерно одинакого .
У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем распаковка. У gzip сие тоже выражено, жмет медленнее чем распаковывает, особенно с -9 заметно. Чисто техническая заморочка. Дело в том что LZ ищет повторные данные в потоке. Поиск достаточно длинных совпадений - куда более ресурсоемко чем копирование кусков совпадений при распаковке. Тем не менее, фрукты с quicklz.com умудрились приблизить скорость сжатия к скорости распаковки. За это воздается достаточно скромным по степени сжатием, разумеется (если вы торопитесь, у вас нет времени поискать максимально возможное совпадение в огромном словаре на много мегов + применить добавочные техники - степень сжатия резонно страдает).

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

44. "Сравнение видеокодеков Ogg Theora и H.264" +1 +/–

Сообщение от anonymous (??), 27-Фев-10, 00:32

>Дело в том что LZ ищет повторные данные в потоке
Убило и разорвало. То есть существуют алгоритмы сжатия, которые не ищут повторные данные в потоке ? Нобелевка!

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

61. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 27-Фев-10, 18:14

>Убило и разорвало.
Вот что значит знание - сила! :D
>То есть существуют алгоритмы сжатия, которые не ищут повторные данные в потоке ?
Существуют. Вы прикиньте?
>Нобелевка!
Тогда дайте ее плиз господину Хаффману :).И еще некоторым.

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

83. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от Аноним (-), 01-Мрт-10, 18:13

>[оверквотинг удален]
>
>Вот что значит знание - сила! :D
>
>>То есть существуют алгоритмы сжатия, которые не ищут повторные данные в потоке ?
>
>Существуют. Вы прикиньте?
>
>>Нобелевка!
>
>Тогда дайте ее плиз господину Хаффману :).И еще некоторым.
Ха не надо ля-ля данными может быть и байт позже он может шифроваться и 2 битами.
Хотя да существуют и другие алгоритмы сжатия: вроде хранения не данных, а изменения их.

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

89. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 02-Мрт-10, 03:40

>>[оверквотинг удален]
Хреново удален.
>>>Нобелевка!
>>Тогда дайте ее плиз господину Хаффману :).И еще некоторым.
>Ха не надо ля-ля данными может быть и байт позже он может
>шифроваться и 2 битами.
Хаффман грубо говоря пытается кодировать более часто встречающиеся байты более короткими последовательностями чем редко встречающиеся (до похожей идеи допер еще дедушка Морзе, сделав коды часто встречающихся букв более короткими). Ежу понятно что если в потоке все значения байтов встречаются одинаково, выиграть не получится ничего. Но если в потоке неких байтов больше а неких меньше, хаффман выиграет за счет более экономного кодирования частых байтов. Заметьте что повторы хаффмана вообще не интересуют. Его интересует сугубо статистические свойства потока. Если распределение частот возникновения байтов в потоке неравномерное, хаффман выигрывает на этом. Так что нобеля ему :).Да и прочим кто клепает компрессоры оперируюзщие вероятностными делами.
>Хотя да существуют и другие алгоритмы сжатия: вроде хранения не данных, а
>изменения их.
Ну т.е. слили вы спор :P.Имейте силы признаться что погорячились. Алгоритмы сжатия не могут сжать случайные данные. Но отсюда не следует что они кодируют только повторы и никак иначе.

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

47. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 27-Фев-10, 01:18

>[оверквотинг удален]
>У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем
>распаковка. У gzip сие тоже выражено, жмет медленнее чем распаковывает, особенно
>с -9 заметно. Чисто техническая заморочка. Дело в том что LZ
>ищет повторные данные в потоке. Поиск достаточно длинных совпадений - куда
>более ресурсоемко чем копирование кусков совпадений при распаковке. Тем не менее,
>фрукты с quicklz.com умудрились приблизить скорость сжатия к скорости распаковки. За
>это воздается достаточно скромным по степени сжатием, разумеется (если вы торопитесь,
>у вас нет времени поискать максимально возможное совпадение в огромном словаре
>на много мегов + применить добавочные техники - степень сжатия резонно
>страдает).
Алгоритм Лемпеля-зива не «ищет повторные данные в потоке», по крайней мере, в базовой реализации. Там используется другая схема работы: по мере чтения _битового_ потока ищется самый длинный совпадающий с текущим читаемым куском элемент словаря, записывается его код, затем «хвост», а новый элемент (найденный + хвост) попадает в словарь. Это сильно упрощённо, конечно. :)
Не изучал детально сорцы современных архиваторов, но, насколько я себе представляю возможность LZ* - используются разные настройки словаря, плюс возможно использование уже готового словаря ("мультимедийное сжатие RAR"). А так, простенький LZ-архиватор пишется на голом Си за два часа: час курения алгоритма, полчаса кодинг, полчаса дебаг. :)

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

65. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 27-Фев-10, 20:07

>Алгоритм Лемпеля-зива не «ищет повторные данные в потоке»,
А английская вика например пишет именно так. Хоть я и взял из головы, но перепроверился по вике. Цитирую http://en.wikipedia.org/wiki/LZ77_and_LZ78
LZ77 algorithms achieve compression by replacing portions of the data with references to matching data that have already passed through both encoder and decoder. A match is encoded by a pair of numbers called a length-distance pair.
В общем то это было грубое описание смысла деятельности таких схем. Общий смысл такой схемы - найти совпадения в потоке данных и закодировать длинные совпадения более короткими ссылками на совпадения. Ежу понятно что есть over 9000 способов это сделать, но это уже детали. Чем более длинное совпадение нашлось - тем лучше сжатие. Разные степени сжатия делаются достаточно просто - компрессор на малых степенях сжатия не ищет лучшее из возможных совпадение а кодирует "уже достаточное", забив в некоторый момент на попытки улучшить длину совпадения для экономии времени. Сколько именно считается за "уже достаточно" и есть параметр степени сжатия (всякие -1 и -9 крутят у LZ-based вот этот вот параметр как правило). Ну и ессно чем больше словарь - тем больше шансов наловить совпадений текущих данных с предыдущими.
>по крайней мере, в базовой реализации.
А базовый - это у вас который? LZ77? LZ78? LZSS? Что-то не припоминаю так сходу кто именно из LZ* на биты входной поток раскладывает. И что за код? Позиция в словаре?
>Это сильно упрощённо, конечно. :)
Спасибо за рассказы про LZ-based, ага. Правда вот насчет битового потока - интересно что за LZ это был? Который именно при чтении битами оперирует.То что есть стратегии записи выходного потока как bit stream без выравнивания на байты (так компактнее) и с выравнианием на оные (как првило для скорости, - LZO и подобные).
Но все (?) LZ-образные компрессоры которые я видел, читали со входа именно байты и совпадения искались побайтово. Да и логично в общем то - для удобства обычно real-world данные выровнены на байты, на оперирование битовыми потоками идут только в крайних случаях (для максимальной компактности и ессно в ущерб скорости обработки потока).
>LZ* - используются разные настройки словаря,
А также можно крутить как параметр сжатия то что считается за достаточную длину совпадения после которой компрессор кладет на попытки удлинить совпадение.
>плюс возможно использование уже готового словаря ("мультимедийное сжатие RAR").
Для звука насколько я знаю есть еще техники типа кодирования не абсолютных значений (которые всегда разные) а разницы с предыдущим отсчетом (дельты относительно небольшие и могут повторяться, после такого препроцессинга можно отдать сие даже обычному LZ и он уже не стушуется на таком потоке а из него можно перестроить без потерь и оригинал). Правда это только одна из техник. Бывает и еще два вагона. Как правило поток преобразуется или расщепляется на несколько потоков дабы получить более-менее совпадающие данные которые можно сжать.
>А так, простенький LZ-архиватор пишется на голом Си за два часа:
Да я в курсе - писал несколько декомпрессоров LZ-подобных алгоритмов.На сях и асме.Правда предпочитал подвиды которые не требуют для декомпрессии словарь. Кто же так не развлекается?Разве что те кто для этого слишком тупы, типа жабистов :)

>час курения алгоритма, полчаса кодинг, полчаса дебаг. :)
С 1 поправочкой. Качественные полные тесты что связка компрессор+декомпрессор никогда не лажается могут занимать намного больше времени чем полчаса. Более того - немало движков обнаруживали проблемы в редких ситуациях аж через годы.

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

67. "Сравнение видеокодеков Ogg Theora и H.264" –2 +/–

Сообщение от iZEN (ok), 27-Фев-10, 20:19

>>А так, простенький LZ-архиватор пишется на голом Си за два часа:
>
>Да я в курсе - писал несколько декомпрессоров LZ-подобных алгоритмов.На сях и
>асме.Правда предпочитал подвиды которые не требуют для декомпрессии словарь. Кто же
>так не развлекается?Разве что те кто для этого слишком тупы, типа
>жабистов :)
Ну, перепиши PNGImageReader.java и PNGImageWriter.java на сях, посмотрим, за сколько недель осилишь. :))

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

71. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 27-Фев-10, 20:40

А что, libpng - уже отменили? Или почему вам можно взять готовое а мне - нет? Двойные стандарты то - не рулят. Или вы хотите сказать что вон те файлы вы сами с нуля написали, реализовв чтение и запись пнгх во всех позах самолично с нуля? Ох уж эти двойные стандарты :)

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

77. "Сравнение видеокодеков Ogg Theora и H.264" –1 +/–

Сообщение от iZEN (ok), 28-Фев-10, 01:30

>А что, libpng - уже отменили? Или почему вам можно взять готовое
>а мне - нет? Двойные стандарты то - не рулят.
Я хочу сказать, что библиотеки для обработки изображения есть не только на C/C++. Вот и всё.

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

78. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 28-Фев-10, 05:02

По-моему вы хотели сказать что вы не умно потролили и при этом забавно обломались. Поскольку я не вдупляю при чем тут изображения. А то я например с LZ возился в областях никак не касающихся изображений (более того, я бы дорого дал чтобы посмотреть как вы изобразите на яве то где я юзал LZ, ибо это даже теоретически невозможно :D). Видимо вы хотели, привести пример того что проще делается на яве но при этом лоханулись забыв про общеизвестный libpng. Epic fail :P

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

79. "Сравнение видеокодеков Ogg Theora и H.264" –1 +/–

Сообщение от iZEN (ok), 28-Фев-10, 13:19

>По-моему вы хотели сказать что вы не умно потролили и при этом
>забавно обломались. Поскольку я не вдупляю при чем тут изображения.
Притом, что в PNG используется СЖАТИЕ (без потерь). Такие же кодеки на Java есть и для GIF, JPEG и BMP.
Некоторые разработчки на J2ME портировали код для работы со сжатыми изображениями (чтение есть, нужна запись) из Java SE в J2ME-приложения практически без потери основного функционала.
>А то я например с LZ возился в областях никак не касающихся
>изображений (более того, я бы дорого дал чтобы посмотреть как вы
>изобразите на яве то где я юзал LZ, ибо это даже
>теоретически невозможно :D).
Работу с байтовыми потоками в java/javame никто не отменял.
>Видимо вы хотели, привести пример того что проще
>делается на яве но при этом лоханулись забыв про общеизвестный libpng.
>Epic fail :P
Никакой библиотекой libpng на J2ME-девайсах не пахнет, по очевидным причинам — не тот уровень встраиваемости.

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

85. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 01-Мрт-10, 21:55

>Притом, что в PNG используется СЖАТИЕ (без потерь). Такие же кодеки на
>Java есть и для GIF, JPEG и BMP.
Круто. А почему вообще каким-то супербогам должно быть можно загонять меня в фиксированные рамки "вы юзаете только эти и эти форматы, а остальное - ни-ни"? А то парсер/декодер на яве если и получается то куда как более тормозной. Ну а если вам просадили (и без того хилый) проц в 3 раза галимой виртуалочкой, значит в сможете в 3 раза меньше чем "божки". А уж system-wide кодек на яве и вовсе хрен напишешь. Так чтобы поставил его и системный плеер, рингтоны, системные сигналы и прочая стали бы понимать желаемый формат.
>Некоторые разработчки на J2ME портировали код для работы со сжатыми
>изображениями (чтение есть, нужна запись) из Java SE в J2ME-приложения
>практически без потери основного функционала.
Я рад за них, но не догоняю что это доказывает.
>Работу с байтовыми потоками в java/javame никто не отменял.
Строго говоря, для LZ оптимальнее работать с битовыми потоками зачастую.
>Никакой библиотекой libpng на J2ME-девайсах не пахнет,
Отлично, а на девайсах с libpng никакой J2ME не пахнет. Квиты? :)
>по очевидным причинам — не тот уровень встраиваемости.
Да бросьте вы. Пнгэхи даже мой роутер генерить пнгхи на лету умеет. Там нет никакой явы, а вот PNGхи графиков траффа и загрузки проца вполне уместны. Это так, о встраиваемости :P.

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

91. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от iZEN (ok), 02-Мрт-10, 14:11

>>Некоторые разработчки на J2ME портировали код для работы со сжатыми
>>изображениями (чтение есть, нужна запись) из Java SE в J2ME-приложения
>>практически без потери основного функционала.
>
>Я рад за них, но не догоняю что это доказывает.
Это доказывает то, что можно делать почти всё. Оптимизация и ускорение на J2ME существенно важнее, чем в нативном коде. в последнем, зачастую, забивают на оптимизацию совсем — добились приемлемой производительности, значит можно больше ничего не делать.
>>Работу с байтовыми потоками в java/javame никто не отменял.
>
>Строго говоря, для LZ оптимальнее работать с битовыми потоками зачастую.
Работа на уровне битов и битовые операции в Java тоже доступны.
>>Никакой библиотекой libpng на J2ME-девайсах не пахнет,
>
>Отлично, а на девайсах с libpng никакой J2ME не пахнет. Квиты? :)
J2ME эмулируется даже в Android, не говоря уже о WinCE. Я на iPAQ hx4700 использовал Opera Mini на IBM J9 WEME вместо того нативного убожества под названием IE, что туда встроили.

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

92. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 02-Мрт-10, 14:47

>Это доказывает то, что можно делать почти всё.
Да хрен там. System-wide кодеки - нельзя. А standalone плееры, смотрелки и т.п. ... простите, но мне как-то удобнее когда формат начинает пониматься всей системой вообще. Запускать плеер для того, а потом плеер для сего, а потом плеер для этакого - неудобно нифига, знаете ли. Да и не хватает зачастую скорострельности яве на дохлом проце для реалтаймного декодирования. Даже звука, про видео вообще помолчу.
>Оптимизация и ускорение на J2ME существенно важнее, чем в нативном коде.
Хоть раком встаньте, но в тугих циклах оно сливает нативному коду раза в три. За счет рантайм проверок и прочая. А это серьезно. Ждать вместо 3 секунд 9 при открытии картинки - мучительно. А если кодек вместо 20% проца сожрет 60 - это будет номер. Впрочем такой кодек скорее всего будет жесточайше икать потому что не будет периодически укладываться в реалтайм. А если яве приспичит мусор собрать или там чего еще - ну, весь мир подождет.
>в последнем, зачастую, забивают на оптимизацию совсем — добились
>приемлемой производительности, значит можно больше ничего не делать.
Я и смотрю - в mplayer так забили на оптимизацию что аж на ARMовском асме выписали критичные кусочки. Так что оно на 3-м омапе ухитряется программно декодить H.264 с разрешением до размера экрана и непохабным битрейтом, не особо сливая DSP-based декодеру и куда менее привиредливо к формату файла чем DSP-based деколер :).Попробуйте такое на яве, ага. На ней программно даже дивиксину вида "3 фильма на сидюк" фиг задекодируешь в реалтайме.Ну а форматов файлов в природе как бы больше чем производители реализуют.Лично меня не очень радует конвертировать все и вся в 2-3 формата.А накукуй мне конвертить какоенить FLV с ютуба с битрейтом 400 кбит? Только потому что особо-убогий девайс не имеет парсера потока и декодера формата в системе и хрен с два сие на яве напишешь? Да впрочем и декодировать софтварно на яве сие врядли в реалтайме выйдет :P.
>Работа на уровне битов и битовые операции в Java тоже доступны.
Только заметно тормознее. Ну и вообще я не видел ни 1 J2ME приблуды которая бы работала с файлами не через задницу.
>J2ME эмулируется даже в Android, не говоря уже о WinCE.
Спекки тоже эмулируется много где.
>Я на iPAQ hx4700 использовал Opera Mini на IBM J9 WEME вместо того
>нативного убожества под названием IE, что туда встроили.
А я вот юзаю нативный MicroB. И он дает фору этой опере с отрывом. Потому что умеет флеш. Умеет авторизежку сертификатами. И юзает системную клаву и настройки, блин. Во всяком случае, обладатели этой йеперы мини на сенсорных смартах открывают для себя очень клевую проблему. Поюзать системную клаву этот крап не может (как минимум в симбиане - точно) и потому браво рисует свою. Гламурную, все дела. Все бы круто, но вот только системная клава в курсах настроек девайса, системной локали, etc. А вот самопальная наэкранная клава еперовцев - разумеется не в курсах всей этой "фигни". А дальше... дальше юзер пытается ввести русиш. И ... получает волшебный фиг. И вообще клава ведет себя иначе чем системная. В итоге браузер вроде бы есть но нормальном им пользоваться - жестокое обломинго.

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

54. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от sluge (ok), 27-Фев-10, 11:57

если перед использованием кодека мне еще надо где то там подкрутить параметры-нафиг такой кодек нужен

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

55. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от Andrey Mitrofanov (?), 27-Фев-10, 13:24

Битрейт-то? Подкрутить? Нет, _тебе_ не надо. Пользуйся "просто", не мучаяйся тааак!

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

66. "Сравнение видеокодеков Ogg Theora и H.264" +/–

Сообщение от User294 (ok), 27-Фев-10, 20:19

>если перед использованием кодека мне еще надо где то там подкрутить параметры
У любой прогрммы как правило есть настройки по умолчанию. Так что если впадлу крутить настройки, используйте дефолты :D. А вот настройки быть должны. Потому что кодеки - немного не та область где ВСЕ будут довольны 1 волшебной кнопкой "сделайте мне зашибись!". Потому что понятия о "зашибись" - бывают разные. У Васи карманный плеер с недостатком места и ему "зашибись" - это когда файлы мелкие. А то что там ватный звук - Вася в китайских наушниках китайского плеера на привычном бубухании особо не замечает. Зато замечает когда музон перестает умещаться. А у Пети - качественная аудиосистема, приличная звуковуха, и место на диске его не так жмет. И "вату" на назких битрейтах Петя в итоге слышит. Вопрос: как кодек без параметров может угодить обоим? Ну вот и получается что как минимум несколько рукояток - надо. Или сфера применеия сильно сузится. При том настройки есть у почти любого кодека кроме совсем уж нишевых (которые сугубо для VoIP например).

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Сравнение видеокодеков Ogg Theora и H.264"	–5 +/–
Сообщение от add (??), 26-Фев-10, 16:44
Т.е. разработчики Theora могут "починить" свой кодек? Ну и сколько лет им на это потребуется?Или они специально тормозят?
Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Сравнение видеокодеков Ogg Theora и H.264"	–1 +/–
	Сообщение от polymorphm1 (ok), 26-Фев-10, 19:17
	> Т.е. разработчики Theora могут "починить" свой кодек? > Ну и сколько лет им на это потребуется?Или они специально тормозят? чего починить? сказали же что при НАРМАЛЬНЫХ битрейдах (а не маленьких) -- кажество почти неотличимо . зато выиграшь при нагрузке на процессор .
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 26-Фев-10, 19:55
	При большом битрейте любой вменяемый алгоритм дает почти неотличимое от оригинала качество. А при очень большом (ака несжатом) потоке и вовсе нам валится оригинал :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Сравнение видеокодеков Ogg Theora и H.264"	–2 +/–
	Сообщение от polymorphm1 (ok), 26-Фев-10, 20:10
	вот и фиг! поэтому предлагаю прекратить эти "войны за 10%" и задуматься о других аспектах (разницца которых не в 10%)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Сравнение видеокодеков Ogg Theora и H.264"	+2 +/–
	Сообщение от User294 (ok), 26-Фев-10, 20:24
	>вот и фиг! Что - фиг? >поэтому предлагаю прекратить эти "войны за 10%" и задуматься о других аспектах >(разницца которых не в 10%) Эти 10% на графиках и отличают смотрябельную картинку от блевотины из квадратиков и т.п. артефактов если что. А чтобы картинку того же качества с теорой пропхать - надо сильно задрать битрейт. А вот платить за вагон лишнего траффа всем лениво, как и больше хардов покупать, etc. Улавливаете в чем проблема? Миру нужен кодек не хуже или не сильно хуже H.264 но без всяких вымогателей роялти за воздух и прочее размешение роликов на серверах. Потому то и наблюдается данная возня.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Сравнение видеокодеков Ogg Theora и H.264"	–2 +/–
	Сообщение от polymorphm1 (ok), 26-Фев-10, 20:30
	>Эти 10% на графиках и отличают смотрябельную картинку от блевотины из квадратиков >и т.п. артефактов если что. вот как раз и нет. эти 10% отличают две картинки -- если задасться целью их пристально сравнивать...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Сравнение видеокодеков Ogg Theora и H.264"	+1 +/–
	Сообщение от User294 (ok), 26-Фев-10, 20:43
	Да, только разница в том что картинку где 10% левизны смотреть очень неприятно. Ну, конечно, цвет и контуры предметов в этой мазне из квадратиков будут иметь что-то общее с оригиналом, совпадая на 90%, так что на графике разница будет 10%. Но вот смотреть глазами на это без рвотных позывов будет ой как нелегко. А если на стопкадр посмотреть - тут уж наверняка стошнит т.к. вы увидите не картинку а набор квадратиков и т.п. артефактов сжатия.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Сравнение видеокодеков Ogg Theora и H.264"	+1 +/–
	Сообщение от polymorphm1 (ok), 26-Фев-10, 20:28
	>вот и фиг! > >поэтому предлагаю прекратить эти "войны за 10%" и задуматься о других аспектах >(разницца которых не в 10%) в погоне за созданием "самых лучших программ" -- зачастую люди начинают игнорировать все остальные характеристики своего ПО, кроме как "основной" характеристики... (а все "НЕосновные" характеристики в итоге создают в таких случаях -- не слабую савакупность общего говна) есть даже такая пословица "лучший -- враг хорошего!"... давайте напимер отвлечёмся от ["самого лучшего"] Mkv/H.264 и ["НЕсамого лучшего"] Ogg/Theora... и рассмотрим другие примеры: gzip -- как вполне хороший ["НЕсамый лкчший"] архиватор .. и lzma который сжимает сущетвенно дольше (в 50~100 раз) чем разжимает (а чащще бывает что нужно чтобы это было примерно одинакого . а иногда наоборот лучше чтобы подольше сжать и побыстрее разжать, в этом случае lzma более оправдан) apache2 -- как "самый лучший" www-сервер -- но оказывается он не реализует концепцию-конечного-автомата (в отличии от nginx и lighttpd) и совсем базово реализует fcgi (а какже unix-way ?) . и то что apache2 разбух -- это не даёт ему красоты. ... да куча примеров, и во всех них -- оптимальным выбором будет использование чегото хорошего, но "НЕсамого лучшего".. :-)
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	35. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 26-Фев-10, 20:50
	>сжимает сущетвенно дольше (в 50~100 раз) чем разжимает (а чащще бывает >что нужно чтобы это было примерно одинакого . У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем распаковка. У gzip сие тоже выражено, жмет медленнее чем распаковывает, особенно с -9 заметно. Чисто техническая заморочка. Дело в том что LZ ищет повторные данные в потоке. Поиск достаточно длинных совпадений - куда более ресурсоемко чем копирование кусков совпадений при распаковке. Тем не менее, фрукты с quicklz.com умудрились приблизить скорость сжатия к скорости распаковки. За это воздается достаточно скромным по степени сжатием, разумеется (если вы торопитесь, у вас нет времени поискать максимально возможное совпадение в огромном словаре на много мегов + применить добавочные техники - степень сжатия резонно страдает).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Сравнение видеокодеков Ogg Theora и H.264"	+1 +/–
	Сообщение от anonymous (??), 27-Фев-10, 00:32
	>Дело в том что LZ ищет повторные данные в потоке Убило и разорвало. То есть существуют алгоритмы сжатия, которые не ищут повторные данные в потоке ? Нобелевка!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 27-Фев-10, 18:14
	>Убило и разорвало. Вот что значит знание - сила! :D >То есть существуют алгоритмы сжатия, которые не ищут повторные данные в потоке ? Существуют. Вы прикиньте? >Нобелевка! Тогда дайте ее плиз господину Хаффману :).И еще некоторым.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от Аноним (-), 01-Мрт-10, 18:13
	>[оверквотинг удален] > >Вот что значит знание - сила! :D > >>То есть существуют алгоритмы сжатия, которые не ищут повторные данные в потоке ? > >Существуют. Вы прикиньте? > >>Нобелевка! > >Тогда дайте ее плиз господину Хаффману :).И еще некоторым. Ха не надо ля-ля данными может быть и байт позже он может шифроваться и 2 битами. Хотя да существуют и другие алгоритмы сжатия: вроде хранения не данных, а изменения их.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 02-Мрт-10, 03:40
	>>[оверквотинг удален] Хреново удален. >>>Нобелевка! >>Тогда дайте ее плиз господину Хаффману :).И еще некоторым. >Ха не надо ля-ля данными может быть и байт позже он может >шифроваться и 2 битами. Хаффман грубо говоря пытается кодировать более часто встречающиеся байты более короткими последовательностями чем редко встречающиеся (до похожей идеи допер еще дедушка Морзе, сделав коды часто встречающихся букв более короткими). Ежу понятно что если в потоке все значения байтов встречаются одинаково, выиграть не получится ничего. Но если в потоке неких байтов больше а неких меньше, хаффман выиграет за счет более экономного кодирования частых байтов. Заметьте что повторы хаффмана вообще не интересуют. Его интересует сугубо статистические свойства потока. Если распределение частот возникновения байтов в потоке неравномерное, хаффман выигрывает на этом. Так что нобеля ему :).Да и прочим кто клепает компрессоры оперируюзщие вероятностными делами. >Хотя да существуют и другие алгоритмы сжатия: вроде хранения не данных, а >изменения их. Ну т.е. слили вы спор :P.Имейте силы признаться что погорячились. Алгоритмы сжатия не могут сжать случайные данные. Но отсюда не следует что они кодируют только повторы и никак иначе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 27-Фев-10, 01:18
	>[оверквотинг удален] >У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем >распаковка. У gzip сие тоже выражено, жмет медленнее чем распаковывает, особенно >с -9 заметно. Чисто техническая заморочка. Дело в том что LZ >ищет повторные данные в потоке. Поиск достаточно длинных совпадений - куда >более ресурсоемко чем копирование кусков совпадений при распаковке. Тем не менее, >фрукты с quicklz.com умудрились приблизить скорость сжатия к скорости распаковки. За >это воздается достаточно скромным по степени сжатием, разумеется (если вы торопитесь, >у вас нет времени поискать максимально возможное совпадение в огромном словаре >на много мегов + применить добавочные техники - степень сжатия резонно >страдает). Алгоритм Лемпеля-зива не «ищет повторные данные в потоке», по крайней мере, в базовой реализации. Там используется другая схема работы: по мере чтения _битового_ потока ищется самый длинный совпадающий с текущим читаемым куском элемент словаря, записывается его код, затем «хвост», а новый элемент (найденный + хвост) попадает в словарь. Это сильно упрощённо, конечно. :) Не изучал детально сорцы современных архиваторов, но, насколько я себе представляю возможность LZ* - используются разные настройки словаря, плюс возможно использование уже готового словаря ("мультимедийное сжатие RAR"). А так, простенький LZ-архиватор пишется на голом Си за два часа: час курения алгоритма, полчаса кодинг, полчаса дебаг. :)
	Ответить \| Правка \| К родителю #35 \| Наверх \| Cообщить модератору


	65. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 27-Фев-10, 20:07
	>Алгоритм Лемпеля-зива не «ищет повторные данные в потоке», А английская вика например пишет именно так. Хоть я и взял из головы, но перепроверился по вике. Цитирую http://en.wikipedia.org/wiki/LZ77_and_LZ78 LZ77 algorithms achieve compression by replacing portions of the data with references to matching data that have already passed through both encoder and decoder. A match is encoded by a pair of numbers called a length-distance pair. В общем то это было грубое описание смысла деятельности таких схем. Общий смысл такой схемы - найти совпадения в потоке данных и закодировать длинные совпадения более короткими ссылками на совпадения. Ежу понятно что есть over 9000 способов это сделать, но это уже детали. Чем более длинное совпадение нашлось - тем лучше сжатие. Разные степени сжатия делаются достаточно просто - компрессор на малых степенях сжатия не ищет лучшее из возможных совпадение а кодирует "уже достаточное", забив в некоторый момент на попытки улучшить длину совпадения для экономии времени. Сколько именно считается за "уже достаточно" и есть параметр степени сжатия (всякие -1 и -9 крутят у LZ-based вот этот вот параметр как правило). Ну и ессно чем больше словарь - тем больше шансов наловить совпадений текущих данных с предыдущими. >по крайней мере, в базовой реализации. А базовый - это у вас который? LZ77? LZ78? LZSS? Что-то не припоминаю так сходу кто именно из LZ* на биты входной поток раскладывает. И что за код? Позиция в словаре? >Это сильно упрощённо, конечно. :) Спасибо за рассказы про LZ-based, ага. Правда вот насчет битового потока - интересно что за LZ это был? Который именно при чтении битами оперирует.То что есть стратегии записи выходного потока как bit stream без выравнивания на байты (так компактнее) и с выравнианием на оные (как првило для скорости, - LZO и подобные). Но все (?) LZ-образные компрессоры которые я видел, читали со входа именно байты и совпадения искались побайтово. Да и логично в общем то - для удобства обычно real-world данные выровнены на байты, на оперирование битовыми потоками идут только в крайних случаях (для максимальной компактности и ессно в ущерб скорости обработки потока). >LZ* - используются разные настройки словаря, А также можно крутить как параметр сжатия то что считается за достаточную длину совпадения после которой компрессор кладет на попытки удлинить совпадение. >плюс возможно использование уже готового словаря ("мультимедийное сжатие RAR"). Для звука насколько я знаю есть еще техники типа кодирования не абсолютных значений (которые всегда разные) а разницы с предыдущим отсчетом (дельты относительно небольшие и могут повторяться, после такого препроцессинга можно отдать сие даже обычному LZ и он уже не стушуется на таком потоке а из него можно перестроить без потерь и оригинал). Правда это только одна из техник. Бывает и еще два вагона. Как правило поток преобразуется или расщепляется на несколько потоков дабы получить более-менее совпадающие данные которые можно сжать. >А так, простенький LZ-архиватор пишется на голом Си за два часа: Да я в курсе - писал несколько декомпрессоров LZ-подобных алгоритмов.На сях и асме.Правда предпочитал подвиды которые не требуют для декомпрессии словарь. Кто же так не развлекается?Разве что те кто для этого слишком тупы, типа жабистов :) >час курения алгоритма, полчаса кодинг, полчаса дебаг. :) С 1 поправочкой. Качественные полные тесты что связка компрессор+декомпрессор никогда не лажается могут занимать намного больше времени чем полчаса. Более того - немало движков обнаруживали проблемы в редких ситуациях аж через годы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Сравнение видеокодеков Ogg Theora и H.264"	–2 +/–
	Сообщение от iZEN (ok), 27-Фев-10, 20:19
	>>А так, простенький LZ-архиватор пишется на голом Си за два часа: > >Да я в курсе - писал несколько декомпрессоров LZ-подобных алгоритмов.На сях и >асме.Правда предпочитал подвиды которые не требуют для декомпрессии словарь. Кто же >так не развлекается?Разве что те кто для этого слишком тупы, типа >жабистов :) Ну, перепиши PNGImageReader.java и PNGImageWriter.java на сях, посмотрим, за сколько недель осилишь. :))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 27-Фев-10, 20:40
	А что, libpng - уже отменили? Или почему вам можно взять готовое а мне - нет? Двойные стандарты то - не рулят. Или вы хотите сказать что вон те файлы вы сами с нуля написали, реализовв чтение и запись пнгх во всех позах самолично с нуля? Ох уж эти двойные стандарты :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Сравнение видеокодеков Ogg Theora и H.264"	–1 +/–
	Сообщение от iZEN (ok), 28-Фев-10, 01:30
	>А что, libpng - уже отменили? Или почему вам можно взять готовое >а мне - нет? Двойные стандарты то - не рулят. Я хочу сказать, что библиотеки для обработки изображения есть не только на C/C++. Вот и всё.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 28-Фев-10, 05:02
	По-моему вы хотели сказать что вы не умно потролили и при этом забавно обломались. Поскольку я не вдупляю при чем тут изображения. А то я например с LZ возился в областях никак не касающихся изображений (более того, я бы дорого дал чтобы посмотреть как вы изобразите на яве то где я юзал LZ, ибо это даже теоретически невозможно :D). Видимо вы хотели, привести пример того что проще делается на яве но при этом лоханулись забыв про общеизвестный libpng. Epic fail :P
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "Сравнение видеокодеков Ogg Theora и H.264"	–1 +/–
	Сообщение от iZEN (ok), 28-Фев-10, 13:19
	>По-моему вы хотели сказать что вы не умно потролили и при этом >забавно обломались. Поскольку я не вдупляю при чем тут изображения. Притом, что в PNG используется СЖАТИЕ (без потерь). Такие же кодеки на Java есть и для GIF, JPEG и BMP. Некоторые разработчки на J2ME портировали код для работы со сжатыми изображениями (чтение есть, нужна запись) из Java SE в J2ME-приложения практически без потери основного функционала. >А то я например с LZ возился в областях никак не касающихся >изображений (более того, я бы дорого дал чтобы посмотреть как вы >изобразите на яве то где я юзал LZ, ибо это даже >теоретически невозможно :D). Работу с байтовыми потоками в java/javame никто не отменял. >Видимо вы хотели, привести пример того что проще >делается на яве но при этом лоханулись забыв про общеизвестный libpng. >Epic fail :P Никакой библиотекой libpng на J2ME-девайсах не пахнет, по очевидным причинам — не тот уровень встраиваемости.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 01-Мрт-10, 21:55
	>Притом, что в PNG используется СЖАТИЕ (без потерь). Такие же кодеки на >Java есть и для GIF, JPEG и BMP. Круто. А почему вообще каким-то супербогам должно быть можно загонять меня в фиксированные рамки "вы юзаете только эти и эти форматы, а остальное - ни-ни"? А то парсер/декодер на яве если и получается то куда как более тормозной. Ну а если вам просадили (и без того хилый) проц в 3 раза галимой виртуалочкой, значит в сможете в 3 раза меньше чем "божки". А уж system-wide кодек на яве и вовсе хрен напишешь. Так чтобы поставил его и системный плеер, рингтоны, системные сигналы и прочая стали бы понимать желаемый формат. >Некоторые разработчки на J2ME портировали код для работы со сжатыми >изображениями (чтение есть, нужна запись) из Java SE в J2ME-приложения >практически без потери основного функционала. Я рад за них, но не догоняю что это доказывает. >Работу с байтовыми потоками в java/javame никто не отменял. Строго говоря, для LZ оптимальнее работать с битовыми потоками зачастую. >Никакой библиотекой libpng на J2ME-девайсах не пахнет, Отлично, а на девайсах с libpng никакой J2ME не пахнет. Квиты? :) >по очевидным причинам — не тот уровень встраиваемости. Да бросьте вы. Пнгэхи даже мой роутер генерить пнгхи на лету умеет. Там нет никакой явы, а вот PNGхи графиков траффа и загрузки проца вполне уместны. Это так, о встраиваемости :P.
	Ответить \| Правка \| К родителю #79 \| Наверх \| Cообщить модератору


	91. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от iZEN (ok), 02-Мрт-10, 14:11
	>>Некоторые разработчки на J2ME портировали код для работы со сжатыми >>изображениями (чтение есть, нужна запись) из Java SE в J2ME-приложения >>практически без потери основного функционала. > >Я рад за них, но не догоняю что это доказывает. Это доказывает то, что можно делать почти всё. Оптимизация и ускорение на J2ME существенно важнее, чем в нативном коде. в последнем, зачастую, забивают на оптимизацию совсем — добились приемлемой производительности, значит можно больше ничего не делать. >>Работу с байтовыми потоками в java/javame никто не отменял. > >Строго говоря, для LZ оптимальнее работать с битовыми потоками зачастую. Работа на уровне битов и битовые операции в Java тоже доступны. >>Никакой библиотекой libpng на J2ME-девайсах не пахнет, > >Отлично, а на девайсах с libpng никакой J2ME не пахнет. Квиты? :) J2ME эмулируется даже в Android, не говоря уже о WinCE. Я на iPAQ hx4700 использовал Opera Mini на IBM J9 WEME вместо того нативного убожества под названием IE, что туда встроили.
	Ответить \| Правка \| К родителю #85 \| Наверх \| Cообщить модератору


	92. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 02-Мрт-10, 14:47
	>Это доказывает то, что можно делать почти всё. Да хрен там. System-wide кодеки - нельзя. А standalone плееры, смотрелки и т.п. ... простите, но мне как-то удобнее когда формат начинает пониматься всей системой вообще. Запускать плеер для того, а потом плеер для сего, а потом плеер для этакого - неудобно нифига, знаете ли. Да и не хватает зачастую скорострельности яве на дохлом проце для реалтаймного декодирования. Даже звука, про видео вообще помолчу. >Оптимизация и ускорение на J2ME существенно важнее, чем в нативном коде. Хоть раком встаньте, но в тугих циклах оно сливает нативному коду раза в три. За счет рантайм проверок и прочая. А это серьезно. Ждать вместо 3 секунд 9 при открытии картинки - мучительно. А если кодек вместо 20% проца сожрет 60 - это будет номер. Впрочем такой кодек скорее всего будет жесточайше икать потому что не будет периодически укладываться в реалтайм. А если яве приспичит мусор собрать или там чего еще - ну, весь мир подождет. >в последнем, зачастую, забивают на оптимизацию совсем — добились >приемлемой производительности, значит можно больше ничего не делать. Я и смотрю - в mplayer так забили на оптимизацию что аж на ARMовском асме выписали критичные кусочки. Так что оно на 3-м омапе ухитряется программно декодить H.264 с разрешением до размера экрана и непохабным битрейтом, не особо сливая DSP-based декодеру и куда менее привиредливо к формату файла чем DSP-based деколер :).Попробуйте такое на яве, ага. На ней программно даже дивиксину вида "3 фильма на сидюк" фиг задекодируешь в реалтайме.Ну а форматов файлов в природе как бы больше чем производители реализуют.Лично меня не очень радует конвертировать все и вся в 2-3 формата.А накукуй мне конвертить какоенить FLV с ютуба с битрейтом 400 кбит? Только потому что особо-убогий девайс не имеет парсера потока и декодера формата в системе и хрен с два сие на яве напишешь? Да впрочем и декодировать софтварно на яве сие врядли в реалтайме выйдет :P. >Работа на уровне битов и битовые операции в Java тоже доступны. Только заметно тормознее. Ну и вообще я не видел ни 1 J2ME приблуды которая бы работала с файлами не через задницу. >J2ME эмулируется даже в Android, не говоря уже о WinCE. Спекки тоже эмулируется много где. >Я на iPAQ hx4700 использовал Opera Mini на IBM J9 WEME вместо того >нативного убожества под названием IE, что туда встроили. А я вот юзаю нативный MicroB. И он дает фору этой опере с отрывом. Потому что умеет флеш. Умеет авторизежку сертификатами. И юзает системную клаву и настройки, блин. Во всяком случае, обладатели этой йеперы мини на сенсорных смартах открывают для себя очень клевую проблему. Поюзать системную клаву этот крап не может (как минимум в симбиане - точно) и потому браво рисует свою. Гламурную, все дела. Все бы круто, но вот только системная клава в курсах настроек девайса, системной локали, etc. А вот самопальная наэкранная клава еперовцев - разумеется не в курсах всей этой "фигни". А дальше... дальше юзер пытается ввести русиш. И ... получает волшебный фиг. И вообще клава ведет себя иначе чем системная. В итоге браузер вроде бы есть но нормальном им пользоваться - жестокое обломинго.
	Ответить \| Правка \| К родителю #91 \| Наверх \| Cообщить модератору


	54. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от sluge (ok), 27-Фев-10, 11:57
	если перед использованием кодека мне еще надо где то там подкрутить параметры-нафиг такой кодек нужен
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	55. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от Andrey Mitrofanov (?), 27-Фев-10, 13:24
	Битрейт-то? Подкрутить? Нет, _тебе_ не надо. Пользуйся "просто", не мучаяйся тааак!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Сравнение видеокодеков Ogg Theora и H.264"	+/–
	Сообщение от User294 (ok), 27-Фев-10, 20:19
	>если перед использованием кодека мне еще надо где то там подкрутить параметры У любой прогрммы как правило есть настройки по умолчанию. Так что если впадлу крутить настройки, используйте дефолты :D. А вот настройки быть должны. Потому что кодеки - немного не та область где ВСЕ будут довольны 1 волшебной кнопкой "сделайте мне зашибись!". Потому что понятия о "зашибись" - бывают разные. У Васи карманный плеер с недостатком места и ему "зашибись" - это когда файлы мелкие. А то что там ватный звук - Вася в китайских наушниках китайского плеера на привычном бубухании особо не замечает. Зато замечает когда музон перестает умещаться. А у Пети - качественная аудиосистема, приличная звуковуха, и место на диске его не так жмет. И "вату" на назких битрейтах Петя в итоге слышит. Вопрос: как кодек без параметров может угодить обоим? Ну вот и получается что как минимум несколько рукояток - надо. Или сфера применеия сильно сузится. При том настройки есть у почти любого кодека кроме совсем уж нишевых (которые сугубо для VoIP например).
	Ответить \| Правка \| К родителю #54 \| Наверх \| Cообщить модератору