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

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

"Размышление над проблемами формата Ogg"		+/–
Сообщение от opennews on 18-Мрт-10, 16:51
Один из разработчиков проекта FFmpeg в статье "Ogg objections (http://hardwarebug.org/2010/03/03/ogg-objections/)" подробно рассказал о недостатках мультимедиа контейнера Ogg. Вывод в статье сделан неутешительный, свободность и независимость от патентов - это конечно хорошо,  но с технической стороны формат не может конкурировать с аналогами и требует полной переработки. Изначально Ogg создан для работы с простейшими аудео-потоками, из чего следует его излишняя усложненность и нестандартность при работе с другими видами данных, например, при при инкапсуляции видео-потоков. Основные недостатки Ogg: -  Излишнее расходование ресурсов при организации хранения привязанной к потоку служебной информации. Заголовок страницы данных имеет размер 27 байт, в то время как его без проблем можно было бы ужать до 12 байт. Большой объем лишних полей в заголовке страницы данных, приводит к увеличению размера итогового файла примерно на 1%, в то время как для формата MP4 этот показатель равен 0.0... URL: Новость: http://www.opennet.dev/opennews/art.shtml?num=25852
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Размышление над проблемами формата Ogg"		+8 +/–
Сообщение от VyacheslavS on 18-Мрт-10, 16:51
mkv - наше фсё!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Размышление над проблемами формата Ogg"		–3 +/–
	Сообщение от аноним on 18-Мрт-10, 17:12
	btw для вашего всего нет нормальных редакторов
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "Размышление над проблемами формата Ogg"		–2 +/–
	Сообщение от RedRat (ok) on 18-Мрт-10, 17:23
	Вот только формат MKV настолько "развесист", что Avery Lee отказался его добавлять в свой VirtualBub. Приходится извращаться с AviSynth или DirectShow-фильтром.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "Размышление над проблемами формата Ogg"		+5 +/–
	Сообщение от аноним on 18-Мрт-10, 17:47
	Кто такой Avery Lee чтобы к его мнению прислушиваться?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Размышление над проблемами формата Ogg"		–1 +/–
	Сообщение от pavlinux (ok) on 18-Мрт-10, 17:54
	Афтор Видовской рипалки/декодера/плющилки Virtualdub, меж прочим GPL-ная
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "Размышление над проблемами формата Ogg"		–4 +/–
	Сообщение от аноним on 18-Мрт-10, 18:15
	>Кто такой Avery Lee чтобы к его мнению прислушиваться? http://sourceforge.net/projects/virtualdub/files/ Downloads virtualdub-win 48,184,752 нужны ещё доводы?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Размышление над проблемами формата Ogg"		+3 +/–
	Сообщение от gfh (??) on 18-Мрт-10, 18:35
	То что Avery Lee не осилил mkv формат - как то не очень отзывается на его репутации. PS. Для меня VD стал неактуален после появления avidemux'а
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от аноним on 18-Мрт-10, 18:44
	>Для меня VD стал неактуален после появления avidemux'а может подскажете, где в videmux задаются теги
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "Размышление над проблемами формата Ogg"		+5 +/–
	Сообщение от VyacheslavS on 18-Мрт-10, 18:49
	mkvmerge - не осилили?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	27. "Размышление над проблемами формата Ogg"		+2 +/–
	Сообщение от name (??) on 18-Мрт-10, 20:51
	а про virtualdubmod(который работает с мкв) не слышали?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Размышление над проблемами формата Ogg"		–3 +/–
Сообщение от Vitto74 (ok) on 18-Мрт-10, 16:54
OGG был сделан для аудио и в этом плане он очень хорош, а с вдео подкачал не только OGG, но и Theora. Будем надеяться, что появится свободный формат видео и контейнер для него, не уступающий H.264.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Размышление над проблемами формата Ogg"		+3 +/–
	Сообщение от аноним on 18-Мрт-10, 17:48
	> контейнер для него, не уступающий H.264. H.264 - не контейнер.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "Размышление над проблемами формата Ogg"		+1 +/–
	Сообщение от Vitto74 (ok) on 18-Мрт-10, 20:50
	>> контейнер для него, не уступающий H.264. > >H.264 - не контейнер. Я не верно выразился. Я имел в виду, что надеюсь на создание формата, не уступающего H.264
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 18-Мрт-10, 19:37
	Вместо OGG все нормальные люди пользуются AAC. Я, например, кодирую трэки Audio CD в M4A и спокойно прослушиваю их на телефоне. На настольном компьютере использую кодеки faac/faad2.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "Размышление над проблемами формата Ogg"		–1 +/–
	Сообщение от h31 (ok) on 18-Мрт-10, 20:55
	Faac просто ужасен. По качеству сравнимо с Lame. Какой тогда толк от AAC, если можно закодировать с тем же качеством в MP3, который читается везде?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	42. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 19-Мрт-10, 00:23
	FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом VBR от 150 до 320kbps и оптимизацией (ключ -s). В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого нет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	47. "Размышление над проблемами формата Ogg"		–1 +/–
	Сообщение от pavlinux (ok) on 19-Мрт-10, 03:59
	>FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом >VBR от 150 до 320kbps и оптимизацией (ключ -s). > >В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический >звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого >нет. Врубай какой нить SACD Музикал Фиделити с усилком Raysonic с пирделками Paradigm Signature и тебе скрипки Страдивари выпущенные до 1700 года покажутся говном :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	89. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Keeper (??) on 21-Мрт-10, 11:07
	FLAC - наше всё.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	30. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Tav (ok) on 18-Мрт-10, 21:21
	Вместо контейнера вы используете кодек?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	43. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 19-Мрт-10, 00:24
	OGG -> OGG/Vorbis
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	57. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от korrado on 19-Мрт-10, 11:41
	OGG и Theora -  не в одной ли корзине сидят?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Размышление над проблемами формата Ogg"		+/–
Сообщение от Антоним on 18-Мрт-10, 17:13
Зато звук можно аж 256 каналов в ogg завернуть =) Ведь был-же у Монти проект OGG2, только чего-то не пилят его больше. Сорцы в транке два года назад правились.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Размышление над проблемами формата Ogg"		+/–
Сообщение от jura12 (ok) on 18-Мрт-10, 17:17
какие проблемы? взяли да и переделали.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от аноним on 18-Мрт-10, 18:07
	>какие проблемы? взяли да и переделали а финансировать кто будет
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "Размышление над проблемами формата Ogg"		+1 +/–
	Сообщение от anonimus on 18-Мрт-10, 18:16
	тот, кто и до этого финансировал...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Размышление над проблемами формата Ogg"		+/–
Сообщение от polymorphm1 (ok) on 18-Мрт-10, 18:19
а чем ЗВУК отличается от ВИДИО? чтото так и не понял....
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Размышление над проблемами формата Ogg"		+2 +/–
	Сообщение от Аноним (??) on 18-Мрт-10, 18:22
	>а чем ЗВУК отличается от ВИДИО? > >чтото так и не понял.... Данных меньше и при видео появляются две субстанции, которые нужно синхронизировать, звук + видео.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Размышление над проблемами формата Ogg"		+8 +/–
	Сообщение от Кэп on 18-Мрт-10, 18:34
	Звук ты слушаешь ушами, видио - смотришь глазами
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	49. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от pavlinux (ok) on 19-Мрт-10, 04:11
	>Звук ты слушаешь ушами, видио - смотришь глазами Можно наоборот сделать, только долго учится придется... Хотя, звукоинженеры замечательно синусойды АЧХ слушают. Бум - Большая широкая горка, Тыц - несколько маленьких, тыц-тыц-тыц - гармошка :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	53. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от koblin (ok) on 19-Мрт-10, 09:43
	я при настройке гитары тоже синусоиды вижу =))
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	54. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от azure (ok) on 19-Мрт-10, 10:49
	У вас либо видения либо двойка по математике. Гитара не дает синусоиду.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	91. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от koblin (ok) on 21-Мрт-10, 11:40
	не нервничайте, про синусоиду было упрощение
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	87. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aesthetus Animus (??) on 21-Мрт-10, 05:21
	Более того, дирижеры порою воспринимают звук через ощущения цвета: в результате симфония видится как некоторая картина.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	48. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от pavlinux (ok) on 19-Мрт-10, 04:07
	>а чем ЗВУК отличается от ВИДИО? >чтото так и не понял.... Звук есть везде, видео как-такого вообще нет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

21. "Размышление над проблемами формата Ogg"		+/–
Сообщение от oneonfire on 18-Мрт-10, 19:05
Ничего не идеально в нашем мире, но стремиться к этому нужно)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Размышление над проблемами формата Ogg"		+/–
Сообщение от Анон on 18-Мрт-10, 19:07
Только это, ошибочка в переводе, latency - эт время ожидания и чем оно меньше, тем лучше.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Размышление над проблемами формата Ogg"		–1 +/–
Сообщение от iZEN (ok) on 18-Мрт-10, 19:33
>Задержка на стороне отправителя возникает из-за того что заголовок страницы данных в Ogg зависит от содержимого страницы, т.е. отображение и передача страниц осуществляется только блоками - пока весь блок данных не будет получен, невозможно рассчитать передаваемую в заголовке контрольную сумму и размер страницы, что приводит к задержке из-за лишней буферизации. Это напомнило мне строки в C/C++: пока не просканируешь ВСЮ строку от начала до завершающего нуля, не узнаешь её длину. Сильно, сильно. :)) То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	31. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Unixoid_потому_что_кривые_руки_писали_этот_модуль (ok) on 18-Мрт-10, 21:26
	Думаете, именно из-за этого Java быстрее, чем C/C++ ?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	41. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от XoRe (ok) on 19-Мрт-10, 00:02
	>Думаете, именно из-за этого Java быстрее, чем C/C++ ? Да он сарказмирует )
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	44. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 19-Мрт-10, 00:29
	>Думаете, именно из-за этого Java быстрее, чем C/C++ ? Java не быстрее C/C++, так как JVM написана на C/C++. Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	45. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aesthetus Animus (ok) on 19-Мрт-10, 01:03
	> Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++. Хотите сравнить? Давайте, я напишу на Си тот код по работе со строками, который у Вас, будучи реализованым на Java, работает "гораздо быстрее"? А потом посмотрим, насколько хороша Ваша Java.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	46. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 19-Мрт-10, 02:04
	"Маша" + "мыла" + "раму!" и так мульён раз. Спорим, что на Java быстрее?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	62. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от coder on 19-Мрт-10, 18:23
	Проверяйте... и больше не пишите глупостей #include <stdio.h> #include <string.h> int main (void) {     char string[0x100];     for (int cnt = 1000000; cnt > 0; cnt--)         stpcpy (stpcpy (stpcpy (string, "Маша"), "мыла"), "раму!");     printf ("%s\n", string); }
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	63. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Владимир (??) on 19-Мрт-10, 19:42
	Может, strcat() вместо strcpy()?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	64. "Размышление над проблемами формата Ogg"		–1 +/–
	Сообщение от iZEN (ok) on 19-Мрт-10, 21:06
	>[оверквотинг удален] >#include <stdio.h> >#include <string.h> >int main (void) >{ >    char string[0x100]; >    for (int cnt = 1000000; cnt > 0; cnt--) >        stpcpy (stpcpy (stpcpy (string, >"Маша"), "мыла"), "раму!"); >    printf ("%s\n", string); >} % g++ -o StrBench StrBench.c % ./StrBench Машамылараму! И это всё?! Научись сначала правильно писать программы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	65. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 19-Мрт-10, 21:51
	>> Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++. > >Хотите сравнить? Давайте, я напишу на Си тот код по работе со >строками, который у Вас, будучи реализованым на Java, работает "гораздо быстрее"? >А потом посмотрим, насколько хороша Ваша Java. Напишите хотябы для ста тысяч итераций конкатенаций строк: public class StrBench {     public static void main(String[] arg) {         String a = "Маша", b = "мыла", c = "раму!", d = "";         long begin = System.currentTimeMillis();         for (int cnt = 100000; cnt > 0; cnt--)             d += a + b + c;         long end = System.currentTimeMillis();         System.out.printf("Результат: %.80s за %d мс.", d, (end - begin));     } } Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 129634 мс. — получен на AMD Phenom || 810. Запускал несколько раз — время выполнения теста от 126 до 130 секунд.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	66. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от coder on 20-Мрт-10, 00:18
	#include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/time.h> int main (void)   {     const char *a = "Маша", *b = "мыла", *c = "раму!";     const int d = 100000;     char *string = (char*) malloc (d * (strlen (a) + strlen (b) + strlen (c)));     char *ptr = string;     struct timeval start, end;     gettimeofday(&start, NULL);     for (int cnt = d; cnt > 0; cnt--)           ptr = stpcpy (stpcpy (stpcpy (ptr, a), b), c);     gettimeofday(&end, NULL);     printf ("Результат: %.50s за %ld мс.\n", string, \         (end.tv_sec - start.tv_sec) * 1000 + (end.tv_usec - start.tv_usec) / 1000);     free (string); } $ gcc -std=gnu99 -O1 add.c && ./a.out Результат: Машамылараму!Машамылараму! за 2 мс. $ uname -p Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	67. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 20-Мрт-10, 01:56
	>[оверквотинг удален] >    printf ("Результат: %.50s за %ld мс.\n", string, \ > >        (end.tv_sec - start.tv_sec) * >1000 + (end.tv_usec - start.tv_usec) / 1000); >    free (string); >} >$ gcc -std=gnu99 -O1 add.c && ./a.out >Результат: Машамылараму!Машамылараму! за 2 мс. >$ uname -p >Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz Хитро-хитро. :) Пробовал компилировать двумя способами: 1. gcc -std=gnu99 -O1 add.c и 2. cc -std=c99 -o add add.c В первом случае пример выполняется за 3 миллисекунды, во втором — за 17 миллисекунд. Откуда такая разница? Сто миллионов итераций за две или (в зависимости от способа компиляции) шесть секунд. Круто!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	79. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aleksey Salow (ok) on 20-Мрт-10, 12:47
	> char *string = (char*) malloc (d * (strlen (a) + strlen (b) + strlen (c))); И привет buffer overflow.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	82. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от coder on 20-Мрт-10, 21:16
	Молодец! Внимателен! При редактировании "+1" случайно удалил, а исправить здесь не могу.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	94. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от qpq (ok) on 22-Мрт-10, 12:51
	как бы то ни было, наглядная демонстрация проблем языков более низкого уровня
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	90. "Размышление над проблемами формата Ogg"		+1 +/–
	Сообщение от coder on 21-Мрт-10, 11:15
	Быстрее уже не бывает... #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/time.h> int main (void) {     const char *a = "Маша", *b = "мыла", *c = "раму!";     const int count = 1e5;     const int strlength = count * (strlen (a) + strlen (b) + strlen (c));     char *string = (char*) malloc (strlength + 1);     if (!string)         return 1;     char *ptrcur = string, *ptrstop = string + strlength;     struct timeval begin, end;     gettimeofday(&begin, NULL);     while (ptrcur < ptrstop)         ptrcur = stpcpy (stpcpy (stpcpy (ptrcur, a), b), c);     gettimeofday(&end, NULL);     long elapsed_ms = (end.tv_sec - begin.tv_sec) * 1000 + (end.tv_usec - begin.tv_usec) / 1000;     printf ("Результат: %.50s за %ld мс.\n", string, elapsed_ms);     free (string);     return 0; } $ uname -p Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz $ gcc -O1 add.c && ./a.out Результат: Машамылараму!Машамылараму! за 1 мс. gcc -O0 add.c && ./a.out Результат: Машамылараму!Машамылараму! за 6 мс. При -O1 цикл компилируется в набор инструкций         movabsq $-5705910293682414384, %rdi         movabsq $-5705854223505048368, %rsi         movabsq $-8948163380102790959, %rcx .L5:    movq    %rdi, (%rax)         movq    %rsi, 8(%rax)         leaq    16(%rax), %rdx         movq    %rcx, (%rdx)         movw    $33, 8(%rdx)         addq    $25, %rax         cmpq    %rax, %rbx         ja      .L5 Быстрее уже не бывает... Отсюда вывод: чем ниже уровень ЯП, тем выше скорость программы при прочих равных условиях.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	68. "Размышление над проблемами формата Ogg"		+1 +/–
	Сообщение от qpq (ok) on 20-Мрт-10, 02:30
	не позорили бы Java что ли! вот так бы хотя бы написали: public class StrBench2 {     public static void main(String[] arg)     {         final String a = "Маша", b = "мыла", c = "раму!";         final StringBuilder sb = new StringBuilder();                  long begin = System.currentTimeMillis();                  for (int cnt = 100000; cnt > 0; cnt--) {             sb.append(a).append(b).append(c);         }                  long end = System.currentTimeMillis();         System.out.printf("Результат: %.80s за %d мс.", sb, (end - begin));     } } а еще лучше вот так: public class StrBench3 {     public static void main(String[] arg)     {         final String a = "Маша", b = "мыла", c = "раму!";         final StringBuilder sb = new StringBuilder((a.length() + b.length() + c.length()) * 100000);                  long begin = System.currentTimeMillis();                  for (int cnt = 100000; cnt > 0; cnt--) {             sb.append(a).append(b).append(c);         }                  long end = System.currentTimeMillis();         System.out.printf("Результат: %.80s за %d мс.", sb, (end - begin));     } } впрочем, я все равно за C++
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	69. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 20-Мрт-10, 02:50
	>не позорили бы Java что ли! >вот так бы хотя бы написали: Давайте Вы не будете указывать, что мне делать. Строковую конкатенацию оптимизировали на уровне компилятора ещё в Java2 1.4.x — там вместо конкатенации используется StringBuffer. А в Java 5.0 его "заменили" на StringBuilder. Если декомпилировать мой класс, то можно увидеть StringBuilder.append(...); вместо "сложения" строк. Привет!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	70. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от qpq (ok) on 20-Мрт-10, 02:53
	а Вы попробуйте откомпилировать и запустить предоставленные мной примеры, ну пожалуйста, ради интереса ;) ... я даже могу объяснить почему, но Вы ведь не спросите :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	71. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 20-Мрт-10, 02:58
	>а Вы попробуйте откомпилировать и запустить предоставленные мной примеры, ну пожалуйста, ради >интереса ;) StrBench2 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 48 мс. StrBench3 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 41 мс. >я даже могу объяснить почему, но Вы ведь не спросите :) Я сам знаю. Вы заранее выделяете память под буфер StringBuilder, а у меня она выделяется динамически во время выполнения теста.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	72. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от qpq (ok) on 20-Мрт-10, 03:02
	это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически, выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько иные, но хотя бы Java от полного позора спасли и то ладно
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	73. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 20-Мрт-10, 03:20
	>это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически, >выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько >иные, но хотя бы Java от полного позора спасли и то >ладно Что вы бабушку лохматите? И в первом и во втором ваших тестах ЗАРАНЕЕ распределяется память под StringBuilder (в первом случае "как JVM на душу положит", во втором — сразу вся необходимая). JIT-компилятор ЗАРАНЕЕ (перед тем, как проанализировать цикл for) осведомлён о распределении памяти под объекты и делает полную оптимизацию выполнения и в первом и во втором случае. В моём случае переменная d полагается ТОЛЬКО на динамическую оптимизацию вычислений. StringBuilder создаётся внутри цикла, а не вне его; в конце КАЖДОЙ итерации цикла выполняется StringBuilder.toString для строковой переменной d, чего в вашем коде нет. Отсюда и отставание моего кода от вашего в три раза.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	74. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от qpq (ok) on 20-Мрт-10, 03:40
	130 с. vs 40 мс. по Вашему всего в 3 раза? пожалуй с Вами не стоит спорить, впрочем причину Вы уже озвучили - неспособность Java компилятора (JIT, кстати, здесь вообще ни при чем) оптимизировать распределенные конкатенации строк, чего конечно же компилятор и не обязан делать на счет изначального размера StringBuilder'а, то он определяется не тем как JVM на душу положит, а (по крайней мере в случае JRE от Sun) значением буфера в констуре по умолчанию, а он там, если мне не изменяет память равен 16, пойду проверю, ну да, так и есть (все же заставили меня запустить Eclipse), и расширяется по мере надобности по алгоритму capacity = (capacity + 1) * 2
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	76. "Размышление над проблемами формата Ogg"		+2 +/–
	Сообщение от qpq (ok) on 20-Мрт-10, 04:59
	> от 6 раз и более... лучше спать идите, а то поздно уже :) 130 с. / 40 мс. ~ 3250 раз - вот такой оптимизации я добился в своем коде по сравнению с Вашим, вынеся создание StringBuilder'а за пределы цикла, а не полагаясь на оптимизацию компилятора JIT компилятор - тот что в Runtime - конечно же отличная вещь, никто не спорит, но он оптимизирует совершенно другие вещи и не может повлиять на явные просчеты в логике программы > Вы кто по профессии и роду деятельности, если не секрет? это не изменит результатов тестов и тех явных промахов в Ваших рассуждениях о Java и ее возможностях оптимизации, которые мне не особо охота обсуждать просто не хотелось, чтобы Java так сильно дескридитировали синтетическими тестами, где код на С++ выполняется за милисекунды, а программе реализованной на Java для этого якобы требуется почти 2 минуты я просто мимо проходил
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 20-Мрт-10, 05:28
	>> от 6 раз и более... > >лучше спать идите, а то поздно уже :) > >130 с. / 40 мс. ~ 3250 раз - вот такой оптимизации Да. Надо поспать. :)))
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	78. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 20-Мрт-10, 05:31
	>>это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически, >>выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько >Отсюда и отставание моего кода от вашего в три раза. В три тыщи раз.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	83. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aesthetus Animus (??) on 20-Мрт-10, 22:09
	> Напишите хотябы для ста тысяч итераций конкатенаций строк... У меня Ваш код работает несколько медленнее: Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 271690 мс. А вот код на плюсах: #include <iostream> extern "C" {   #include <sys/time.h> } int main(int argc, char** argv) {   std::string s1 = "Мама", s2 = "мыла", s3 = "раму!";   std::string cat;   int count;   int elapsed_ms;   struct timeval begin, end;   gettimeofday(&begin, NULL);   count = 1e5;   cat.reserve((s1.size() + s2.size() + s3.size()) * count);   while (count--)     cat.append(s1).append(s2).append(s3);   gettimeofday(&end, NULL);   elapsed_ms =  (end.tv_sec - begin.tv_sec) * 1000 + (end.tv_usec - begin.tv_usec) / 1000;   std::cerr << "Elapsed time: " << elapsed_ms << std::endl;   std::cout << cat << std::endl;   return 0; } Компилил без оптимизации, вот так: gcc -g -O0 -Wall -pedantic   -o main.o -c main.cpp gcc -lstdc++ -g -Wl,-Map=string-test.map    -o string-test  main.o В общем, почуствуйте разницу: $ time ./string-test > output Elapsed time: 8 real    0m0.022s user    0m0.000s sys    0m0.022s
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	84. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Интересующийся (??) on 21-Мрт-10, 00:07
	#include <iostream> #include <string> #include <sys/time.h> using namespace std; int main(int argc,char* argv[]) {   const int MAX_ITERS = 100000;   string s1("Маша"),s2("мыла"),s3("раму!");   struct timeval start,end; gettimeofday(&start,NULL);   for(size_t i = 0; i < MAX_ITERS; ++i){     string s(s1+" "+s2+" "+s3); cout << s ;   }   gettimeofday(&end,NULL); cout << (end.tv_sec - start.tv_sec) << endl;       return 0; } Собирается g++ -O1 -o sstring sstring.cpp. Выполняется за 1с. Если MAX_ITERS увеличить на порядок, то за 7. Длина строка получается одной командой s1. Система  Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz ,6 Gb Ram. Сейчас буду гонять Ваш код.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	85. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aleksey Salow (ok) on 21-Мрт-10, 01:40
	>  for(size_t i = 0; i < MAX_ITERS; ++i){ >    string s(s1+" "+s2+" "+s3); >cout << s ; ^^^^^^^^^^^^^^^^^^^^ >  } > >Собирается g++ -O1 -o sstring sstring.cpp. Выполняется за 1с. Если MAX_ITERS увеличить >на порядок, то за 7. Длина строка получается одной командой s1. Патамуша вывод в цикле делают только идиоты. Если убрать cout << s то на C2D E6300 получается ~280ms ловите .net/c# :) using System; using System.Diagnostics ; using System.Text; namespace StringPerformanceTest {     class Program     {         const int Iter = 100000 ;         const string s1 = "Маша" ;         const string s2 = "мыла" ;         const string s3 = "раму!" ;                  static void Main ()         {             var result = new StringBuilder ((s1.Length + s2.Length + s3.Length) * Iter) ;                          var watch = Stopwatch.StartNew () ;             for (var i = 0; i < Iter; i++)                 result.Append (s1).Append (s2).Append (s3) ;             watch.Stop () ;             Console.WriteLine ("String length: {0}; Elapsed time: {1}ms", result.Length, watch.ElapsedMilliseconds) ;         }     } } C2Q Q6600/Windows: String length: 1300000; Elapsed time: 10ms C2D E6300/FreeBSD/Mono JIT compiler version 2.4.2.3: String length: 1300000; Elapsed time: 63ms
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	86. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aleksey Salow (ok) on 21-Мрт-10, 01:46
	>C2Q Q6600/Windows: String length: 1300000; Elapsed time: 10ms >C2D E6300/FreeBSD/Mono JIT compiler version 2.4.2.3: String length: 1300000; Elapsed time: 63ms Кстати, если сделать динамическое выделение буфера, то получаются следующие результаты: Win: String length: 1300000; Elapsed time: 37ms Mono: String length: 1300000; Elapsed time: 98ms
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	88. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от coder on 21-Мрт-10, 10:44
	И какая связь этого с "Размышление над проблемами формата Ogg"? :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	92. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Аноним (??) on 21-Мрт-10, 15:50
	>И какая связь этого с "Размышление над проблемами формата Ogg"? :) Никакой. Зато прямое подтверждение стратегии M$: win всегда будет значительно быстрее mono.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	93. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Интересующийся (??) on 21-Мрт-10, 16:27
	Исправил. Без cout получается: real    0m0.010s user    0m0.008s sys     0m0.000s
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	95. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от iZEN (ok) on 22-Мрт-10, 16:36
	>[оверквотинг удален] > >             >Console.WriteLine ("String length: {0}; Elapsed time: {1}ms", result.Length, watch.ElapsedMilliseconds) ; >        } >    } >} > >C2Q Q6600/Windows: String length: 1300000; Elapsed time: 10ms >C2D E6300/FreeBSD/Mono JIT compiler version 2.4.2.3: String length: 1300000; Elapsed time: 63ms > Хех, у меня на Java ~60 мс для 13000000 символов (в десять раз больше, чем у вас): public class StrBench4 {     public static void main(String[] arg) {         final int TEST_COUNT = 10;         final int COUNT = 1000000;         final String a = "Маша", b = "мыла", c = "раму!";         for (int tests = 1; tests <= TEST_COUNT; tests++) {             StringBuilder sb = new StringBuilder((a.length() + b.length() + c.length()) * COUNT);             long begin = System.currentTimeMillis();             for (int cnt = COUNT; --cnt >= 0;) {                 sb.append(a).append(b).append(c);             }             long end = System.currentTimeMillis();             System.out.printf("Тест №%d\nРезультат: %.78s — длина строки %s символов\nВремя выполнения  %d мс.\n", tests, sb, sb.length(), (end - begin));         }     } } Вывод: Тест №1 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  84 мс. Тест №2 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  74 мс. Тест №3 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  42 мс. Тест №4 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  42 мс. Тест №5 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  42 мс. Тест №6 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  43 мс. Тест №7 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  42 мс. Тест №8 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  42 мс. Тест №9 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  42 мс. Тест №10 Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов Время выполнения  42 мс. Эта ваша Mono сливает Яве в десять раз! $ java -version openjdk version "1.6.0" OpenJDK Runtime Environment (build 1.6.0-b17) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) % uname -rsm FreeBSD 8.0-STABLE amd64 % dmesg | grep AMD CPU: AMD Phenom(tm) II X4 810 Processor (2594.47-MHz K8-class CPU)   Origin = "AuthenticAMD"  Id = 0x100f42  Stepping = 2   AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	52. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Аноним (??) on 19-Мрт-10, 09:42
	>Java не быстрее C/C++, так как JVM написана на C/C++. Не факт, что байткод интерпретируется JVM. Язык может приблизится по скорости к C/C++, если он на лету преобразует байткод в машинные инструкции. JIT-компиляция великая вещь.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	56. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от sluge (ok) on 19-Мрт-10, 11:12
	скажу по секрету gcc умеет из java делать бинарный код который работает без всякой JVM и прочих извращений
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	60. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Онаним on 19-Мрт-10, 15:00
	>>Думаете, именно из-за этого Java быстрее, чем C/C++ ? > >Java не быстрее C/C++, так как JVM написана на C/C++. А вы знаете, что реализация Python, написанная на самом Python, говорят, в Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины (VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то виртуальная машина обгоняли физическую, на которой сами работали.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	61. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от pavel_simple (ok) on 19-Мрт-10, 15:58
	>>>Думаете, именно из-за этого Java быстрее, чем C/C++ ? >> >>Java не быстрее C/C++, так как JVM написана на C/C++. > >А вы знаете, что реализация Python, написанная на самом Python, говорят, в >Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же >на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины >(VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то >виртуальная машина обгоняли физическую, на которой сами работали. нет -- не читайте до обеда.... эти люди ещё жалуются .... мама дорогая -- Кругом они! (C) Опеннет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	32. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aesthetus Animus (ok) on 18-Мрт-10, 21:50
	> Это напомнило мне строки в C/C++... А плюсы то Вы не знаете... http://www.cplusplus.com/reference/string/string/length/
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	36. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от slayer (??) on 18-Мрт-10, 22:04
	А как эта функция внутри работает, не задумывались?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	40. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Aesthetus Animus (ok) on 18-Мрт-10, 22:54
	Отройте исходники, да посмотрите наконец сами!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	34. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Аноним (??) on 18-Мрт-10, 22:00
	>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять! И откуда же, по-вашему, они берут длину?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	37. "Размышление над проблемами формата Ogg"		+2 +/–
	Сообщение от uZver (??) on 18-Мрт-10, 22:19
	>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять! > >И откуда же, по-вашему, они берут длину? считают заранее в java String - immutable
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	38. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от Аноним (??) on 18-Мрт-10, 22:26
	>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять! > >И откуда же, по-вашему, они берут длину? Вначале строки хранят размер.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

33. "Размышление над проблемами формата Ogg"		+/–
Сообщение от Аноним (??) on 18-Мрт-10, 21:58
А зачем вообще мешать все в кучу и вставлять в ogg видео?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	35. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от аноним on 18-Мрт-10, 22:03
	>А зачем вообще мешать все в кучу и вставлять в ogg видео? есть другие предложения?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	50. "Размышление над проблемами формата Ogg"		+1 +/–
	Сообщение от Алексей (??) on 19-Мрт-10, 05:18
	Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся. Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	59. "Размышление над проблемами формата Ogg"		+/–
	Сообщение от аноним on 19-Мрт-10, 14:12
	>Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся. Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть. OGG и не разрабатывался для хранения всего на свете. хз почему решили именно этот контейнер всунуть в рекомендации. matroska/mp4+ h.264 + aac - гораздо лучший вариант, ставший стандартом де-факто
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

39. "Размышление над проблемами формата Ogg"		+/–
Сообщение от Аноним (??) on 18-Мрт-10, 22:40
>есть другие предложения? Ну как? Создать отдельный контейнер для видео.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

51. "Размышление над проблемами формата Ogg"		+1 +/–
Сообщение от gapsf2 (ok) on 19-Мрт-10, 06:56
В целом  - почитайте FAQ - там говорится, что для целей аудио Ogg хорошо сделан, а для аудио/видео есть Ogm, хотя MKV более гибкий. Так что ничего страшного. Из http://www.matroska.org/technical/guides/faq/index.html Ogg 1. Designed for streaming. 2. Designed to hold Vorbis. 3. Well documented for above two purposes. Ogm 1. Implementation of Ogg to hold video, other audio codecs, and a type of subtitle. 2. Implements Chapter support. Matroska 1. Designed to hold any type of codec. (Audio, Video, Subtitle, etc) 2. Designed for editability. 3. Purposely flexible design. 4. Well documented portions, others in process. 5. Initial design is to support presentation container features such as Chapters, Tags, AudioGain, Menus, etc. Will Matroska be streamable? Yes, but low bitrate streaming like streaming Vorbis, will always be better in Ogg. This is because their design is for different purposes.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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