| |
| 2.6, RedRat (ok), 17:23, 18/03/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
Вот только формат MKV настолько "развесист", что Avery Lee отказался его добавлять в свой VirtualBub. Приходится извращаться с AviSynth или DirectShow-фильтром.
| | |
| |
| |
| 4.10, pavlinux (ok), 17:54, 18/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
Афтор Видовской рипалки/декодера/плющилки Virtualdub, меж прочим GPL-ная
| | |
|
| 3.18, gfh (??), 18:35, 18/03/2010 [^] [^^] [^^^] [ответить]
| +3 +/– | |
То что Avery Lee не осилил mkv формат - как то не очень отзывается на его репутации.
PS. Для меня VD стал неактуален после появления avidemux'а
| | |
| |
| 4.19, аноним (?), 18:44, 18/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Для меня VD стал неактуален после появления avidemux'а
может подскажете, где в videmux задаются теги
| | |
|
| 3.27, name (??), 20:51, 18/03/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
а про virtualdubmod(который работает с мкв) не слышали?
| | |
|
|
| 1.2, Vitto74 (ok), 16:54, 18/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 OGG был сделан для аудио и в этом плане он очень хорош, а с вдео подкачал не только OGG, но и Theora.
Будем надеяться, что появится свободный формат видео и контейнер для него, не уступающий H.264.
| | |
| |
| 2.8, аноним (?), 17:48, 18/03/2010 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> контейнер для него, не уступающий H.264.
H.264 - не контейнер.
| | |
| |
| 3.26, Vitto74 (ok), 20:50, 18/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> контейнер для него, не уступающий H.264.
>
>H.264 - не контейнер.
Я не верно выразился. Я имел в виду, что надеюсь на создание формата, не уступающего H.264
| | |
|
| 2.24, iZEN (ok), 19:37, 18/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Вместо OGG все нормальные люди пользуются AAC. Я, например, кодирую трэки Audio CD в M4A и спокойно прослушиваю их на телефоне. На настольном компьютере использую кодеки faac/faad2.
| | |
| |
| 3.28, h31 (ok), 20:55, 18/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
Faac просто ужасен. По качеству сравнимо с Lame. Какой тогда толк от AAC, если можно закодировать с тем же качеством в MP3, который читается везде?
| | |
| |
| 4.42, iZEN (ok), 00:23, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом VBR от 150 до 320kbps и оптимизацией (ключ -s).
В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого нет.
| | |
| |
| 5.47, pavlinux (ok), 03:59, 19/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом
>VBR от 150 до 320kbps и оптимизацией (ключ -s).
>
>В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический
>звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого
>нет.
Врубай какой нить SACD Музикал Фиделити с усилком Raysonic с пирделками Paradigm Signature
и тебе скрипки Страдивари выпущенные до 1700 года покажутся говном :)
| | |
|
|
|
|
| 1.4, Антоним (?), 17:13, 18/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Зато звук можно аж 256 каналов в ogg завернуть =) Ведь был-же у Монти проект OGG2, только чего-то не пилят его больше. Сорцы в транке два года назад правились.
| | |
| |
| 2.11, аноним (?), 18:07, 18/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>какие проблемы? взяли да и переделали
а финансировать кто будет
| | |
|
| |
| 2.15, Аноним (-), 18:22, 18/03/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
>а чем ЗВУК отличается от ВИДИО?
>
>чтото так и не понял....
Данных меньше и при видео появляются две субстанции, которые нужно синхронизировать, звук + видео.
| | |
| |
| 3.49, pavlinux (ok), 04:11, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Звук ты слушаешь ушами, видио - смотришь глазами
Можно наоборот сделать, только долго учится придется...
Хотя, звукоинженеры замечательно синусойды АЧХ слушают.
Бум - Большая широкая горка, Тыц - несколько маленьких, тыц-тыц-тыц - гармошка :)
| | |
| |
| |
| 5.54, azure (ok), 10:49, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
У вас либо видения либо двойка по математике. Гитара не дает синусоиду.
| | |
|
| 4.87, Aesthetus Animus (??), 05:21, 21/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Более того, дирижеры порою воспринимают звук через ощущения цвета: в результате симфония видится как некоторая картина.
| | |
|
|
| 2.48, pavlinux (ok), 04:07, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>а чем ЗВУК отличается от ВИДИО?
>чтото так и не понял....
Звук есть везде, видео как-такого вообще нет.
| | |
|
| 1.22, Анон (?), 19:07, 18/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Только это, ошибочка в переводе, latency - эт время ожидания и чем оно меньше, тем лучше.
| | |
| 1.23, iZEN (ok), 19:33, 18/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>Задержка на стороне отправителя возникает из-за того что заголовок страницы данных в Ogg зависит от содержимого страницы, т.е. отображение и передача страниц осуществляется только блоками - пока весь блок данных не будет получен, невозможно рассчитать передаваемую в заголовке контрольную сумму и размер страницы, что приводит к задержке из-за лишней буферизации.
Это напомнило мне строки в C/C++: пока не просканируешь ВСЮ строку от начала до завершающего нуля, не узнаешь её длину. Сильно, сильно. :))
То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
| | |
| |
| |
| 3.41, XoRe (ok), 00:02, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
Да он сарказмирует )
| | |
| 3.44, iZEN (ok), 00:29, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
Java не быстрее C/C++, так как JVM написана на C/C++. Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.
| | |
| |
| 4.45, Aesthetus Animus (ok), 01:03, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.
Хотите сравнить? Давайте, я напишу на Си тот код по работе со строками, который у Вас, будучи реализованым на Java, работает "гораздо быстрее"? А потом посмотрим, насколько хороша Ваша Java.
| | |
| |
| 5.46, iZEN (ok), 02:04, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
"Маша" + "мыла" + "раму!" и так мульён раз. Спорим, что на Java быстрее?
| | |
| |
| 6.62, coder (?), 18:23, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Проверяйте... и больше не пишите глупостей
#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);
}
| | |
| |
| 7.64, iZEN (ok), 21:06, 19/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>[оверквотинг удален]
>#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
Машамылараму!
И это всё?!
Научись сначала правильно писать программы.
| | |
|
|
| 5.65, iZEN (ok), 21:51, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Код на 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 секунд.
| | |
| |
| 6.66, coder (?), 00:18, 20/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
#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
| | |
| |
| 7.67, iZEN (ok), 01:56, 20/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> 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 миллисекунд. Откуда такая разница?
Сто миллионов итераций за две или (в зависимости от способа компиляции) шесть секунд. Круто!
| | |
| 7.79, Aleksey Salow (ok), 12:47, 20/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > char *string = (char*) malloc (d * (strlen (a) + strlen (b) + strlen (c)));
И привет buffer overflow.
| | |
| |
| 8.82, coder (?), 21:16, 20/03/2010 [^] [^^] [^^^] [ответить] | +/– | Молодец Внимателен При редактировании 1 случайно удалил, а исправить здесь ... текст свёрнут, показать | | |
| |
| 9.94, qpq (ok), 12:51, 22/03/2010 [^] [^^] [^^^] [ответить] | +/– | как бы то ни было, наглядная демонстрация проблем языков более низкого уровня... текст свёрнут, показать | | |
|
|
| 7.90, coder (?), 11:15, 21/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Быстрее уже не бывает...
#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
Быстрее уже не бывает...
Отсюда вывод: чем ниже уровень ЯП, тем выше скорость программы при прочих равных условиях.
| | |
|
| 6.68, qpq (ok), 02:30, 20/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
не позорили бы 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++
| | |
| |
| 7.69, iZEN (ok), 02:50, 20/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>не позорили бы Java что ли!
>вот так бы хотя бы написали:
Давайте Вы не будете указывать, что мне делать.
Строковую конкатенацию оптимизировали на уровне компилятора ещё в Java2 1.4.x — там вместо конкатенации используется StringBuffer. А в Java 5.0 его "заменили" на StringBuilder. Если декомпилировать мой класс, то можно увидеть StringBuilder.append(...); вместо "сложения" строк.
Привет!
| | |
| |
| 8.70, qpq (ok), 02:53, 20/03/2010 [^] [^^] [^^^] [ответить] | +/– | а Вы попробуйте откомпилировать и запустить предоставленные мной примеры, ну пож... текст свёрнут, показать | | |
| |
| 9.71, iZEN (ok), 02:58, 20/03/2010 [^] [^^] [^^^] [ответить] | +/– | StrBench2 Результат Машамылараму Машамылараму Машамылараму Машамылараму Машамыл... текст свёрнут, показать | | |
| |
| 10.72, qpq (ok), 03:02, 20/03/2010 [^] [^^] [^^^] [ответить] | +/– | это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамичес... текст свёрнут, показать | | |
| |
| 11.73, iZEN (ok), 03:20, 20/03/2010 [^] [^^] [^^^] [ответить] | +/– | Что вы бабушку лохматите И в первом и во втором ваших тестах ЗАРАНЕЕ распределя... текст свёрнут, показать | | |
| |
| 12.74, qpq (ok), 03:40, 20/03/2010 [^] [^^] [^^^] [ответить] | +/– | 130 с vs 40 мс по Вашему всего в 3 раза пожалуй с Вами не стоит спорить, впро... текст свёрнут, показать | | |
| |
| |
| Часть нити удалена модератором |
| 14.76, qpq (ok), 04:59, 20/03/2010 [ответить] | +2 +/– | лучше спать идите, а то поздно уже 130 с 40 мс 3250 раз - вот такой оп... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 6.83, Aesthetus Animus (??), 22:09, 20/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Напишите хотябы для ста тысяч итераций конкатенаций строк...
У меня Ваш код работает несколько медленнее:
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 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
| | |
| 6.84, Интересующийся (??), 00:07, 21/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
#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.
Сейчас буду гонять Ваш код.
| | |
| |
| 7.85, Aleksey Salow (ok), 01:40, 21/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
> 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
| | |
| |
| 8.95, iZEN (ok), 16:36, 22/03/2010 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Хех, у меня на Java 60 мс для 13000000 символов в деся... большой текст свёрнут, показать | | |
|
|
|
|
| 4.52, Аноним (-), 09:42, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Java не быстрее C/C++, так как JVM написана на C/C++.
Не факт, что байткод интерпретируется JVM. Язык может приблизится по скорости к C/C++, если он на лету преобразует байткод в машинные инструкции. JIT-компиляция великая вещь.
| | |
| |
| 5.56, sluge (ok), 11:12, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
скажу по секрету gcc умеет из java делать бинарный код который работает без всякой JVM и прочих извращений
| | |
|
| 4.60, Онаним (?), 15:00, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
>
>Java не быстрее C/C++, так как JVM написана на C/C++.
А вы знаете, что реализация Python, написанная на самом Python, говорят, в Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины (VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то виртуальная машина обгоняли физическую, на которой сами работали.
| | |
| |
| 5.61, pavel_simple (ok), 15:58, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
>>
>>Java не быстрее C/C++, так как JVM написана на C/C++.
>
>А вы знаете, что реализация Python, написанная на самом Python, говорят, в
>Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же
>на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины
>(VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то
>виртуальная машина обгоняли физическую, на которой сами работали.
нет -- не читайте до обеда....
эти люди ещё жалуются .... мама дорогая -- Кругом они! (C) Опеннет.
| | |
|
|
|
| 2.34, Аноним (-), 22:00, 18/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
И откуда же, по-вашему, они берут длину?
| | |
| |
| 3.37, uZver (??), 22:19, 18/03/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
>
>И откуда же, по-вашему, они берут длину?
считают заранее в java String - immutable
| | |
| 3.38, Аноним (-), 22:26, 18/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
>
>И откуда же, по-вашему, они берут длину?
Вначале строки хранят размер.
| | |
|
|
| |
| 2.35, аноним (?), 22:03, 18/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>А зачем вообще мешать все в кучу и вставлять в ogg видео?
есть другие предложения?
| | |
| |
| 3.50, Алексей (??), 05:18, 19/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся.
Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть.
| | |
| |
| 4.59, аноним (?), 14:12, 19/03/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся. Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть.
OGG и не разрабатывался для хранения всего на свете. хз почему решили именно этот контейнер всунуть в рекомендации. matroska/mp4+ h.264 + aac - гораздо лучший вариант, ставший стандартом де-факто
| | |
|
|
|
| 1.51, gapsf2 (ok), 06:56, 19/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
В целом - почитайте 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.
| | |
|
