» VideoLAN (VLC media player)

jolo

Цитата:

Это как написал shura1973 или нет?

Нет. shura1973 предлагает сделать отдельный плейлист с этой одной радиостанцией и его открывать.
Я предлагаю добавить радиостанцию в Медиа-библиотеку

Trolzen

Цитата:

предлагает сделать отдельный плейлист с этой одной радиостанцией и его открывать

ну можно и не с одной а несколько станций вогнать в плейлист хоть сто,это уж как пожелаете! причём его можно будет постоянно дополнять ведь...

Цитата:

cvlc --no-video --no-audio --sout=#rtp{dst=172.18.0.3,port=5004,mux=ts} --sout-all --sout-keep udp://@235.10.10.16:1234

Что ж ты хочешь получить, если но-видео, но-аудио
cvlc udp://@235.10.10.16:1234 --sout=#rtp{dst=172.18.0.3,mux=ts} --sout-keep

port=5004 итак по-умолчанию для rtp

скачал последнюю версию VideoLAN 1.1.11, открываю им плейлист IPTV каналов, список появляется а видео нет. кодеки у него же свои, так? что посоветуете?
winXP SP3

cheshirscat
Проверить разрешение IGMP в фаерволе + интерфейс вывода мультикаст-потока в VLC посоветую.

как сделать окно VLC с видео поверх остальных?

cppvas
А что? Не «делается»?

Народ подскжите плиз может кто в курсе.
Linux VLC 1.1.12 нет звука с файлами содержащими АС3, остальные нормально играет
В других программах все окей играет (mplayer и parole)

ShadowNev
Лог?

Народ подскжите пожалуйста.
Компьютер подключен без модема и роутера напрямую (ethernet) к провайдеру Башинформсвязь.
Подключался в ночное время с одной точки доступа на два аккаунта (поочередно), разных по скорости соединения :
1. тарифный план-Скоростной-2. Входящая скорость до 2 Мбит/с
2. тарифный план-Скоростной 15. Входящая скорость до 15 Мбит/с
В ночное время скорость соединения, для всех тарифных планов, объявлена провайдером до 100 Мбит/с.
Использовал (поочередно) Media Player_ы VLC - 1.1.11 for Windows и vlc-1.3.0-git-20111208-0005-win32
Проигрывался:
#EXTINF:0,OSMY KANAL
http://clck.ru/Pj5L

Ситуация следующая:
Фильм транслируется какими то порциями (см рис.1)





Создается впечатление, что определенное время идет закачка в некий буфер и в этот момент предыдущее изображение замирает, затем закачка прекращается и идет нормальная трансляция до полного опустошения буфера и далее все повторяется?
Причем такая картина наблюдается и на других плейлистах и не зависит от версии VLC и аккаунта.
Я в этих вопросах "не очень то".
В каком направлении пойти дальше? изменить какие то настройки VLC? если предположить, что в момент опустошения какого то буфера он прекращает прием трафика? но ведь плейер и в дефолтовых настройках не должен иметь такой картины.
Или это козни провайдера - например ограничения (на непрерывность трафика) на отдельные протоколы передачи?
Для сравнения (см. рис2 )




привожу график закачки фильма с торрента и примерно через 30 секунд - просмотр фильма на VLC.


PS
есть каналы с трансляцией примерно до 2Мбит/с -они проигрываются нормально, то есть непрерывно.

Вообще, когда ширины канала не хватает, то, естественно, воспроизведение прерываться будет.



Добавлено:
wtau
Вообще, когда ширины канала не хватает, то, естественно, воспроизведение прерываться будет. Но вот такие скачки -- это странно, должно быть без пауз. У меня вот так (v.1.1.11, шаг сетки по горизонтали -- 6 секунд, падение в конце -- это остановка воспроизведения):



При просмотре через версию 1.1.11 график такой же?

Причина может быть либо в самом плеере (баги версии 1.3), в прове (имхо маловероятно), в сервере-вещателе (например, у них там какие-то проблемы с нагрузкой).

Надо бы сравнить длину буфера и расстояния на графике. Там на графике непонятно, какой масштаб по горизонтали. В качестве эксперимента попробовать поставить длину буфера, чтобы она захватывала как минимум две "горки". Натсройка буфера: http://mozhay.net/forum/thread127-1.html (пятое сообщение).

Добавлено:
Окак интересно. Только что (до этого всё замерялось днём) воспроизведение начало тупить, и график сети стал похож на твой.

Но через некоторое время всё восстановилось и график стал практически идеальным (я даже удивился)



Но через пару минут его опять стало колбасить



В общем, я практически убеждён, что проблема в сервере-вещателе из-за нагрузки или неправильной настройки. И проявляется это ночью почему-то.

to Trolzen


Цитата:

При просмотре через версию 1.1.11 график такой же?

Да график имеет такойже вид. Пробовал и портейбл и обычную версию VLC 1.1.11
Судя по графику- кто-то со стороны вещания через примерно равные промежутки времени прекращает трансляцию.


Цитата:

Надо бы сравнить длину буфера и расстояния на графике..

Цитата:

...чтобы она захватывала как минимум две "горки".

Спасибо. Попробую выполнить



Добавлено:



Привожу график трафика при размере кэш- 1200 мс (дефолт) и при устанновке значения-10000мс.
рис.
Что то я не вижу разницы. Две разные программы показывают одинаковую форму входного сигнала

Вопросы остаются:
1. видно, что примерно 30сек мне отпущено на закачку -затем она обрывается.
2 также непонятно- почему в момент 30 секундной закачки -плейер не показывает изображение и эвук
3 если буфер 10 сек- то куда идет трафик в оставшиеся 20 сек? -плейер то не показывает!
3 непонятно- почему плейер не ведет закачку трафика в момент воспроизведения изображения и эвука

PS. почему-то не удается приаттачить картинку непосредственно в пост.

Сразу замечание: шаг на графике NetWorx, скорее всего, 30 секунд, а не минута. Но это так, можно не обсуждать, а то уйдём в сторону.

Всё дело в том, что плееру не отдаются данные. То есть эта картина с пиками и пустыми промежутками из-за сервера (или что-то по пути мешает). Причина -- это трафик, на графике, все остальное -- следствие, не наоборот. Поэтому эти все вопросы 1-4 это просто следствия. По второму вопросу: плеер останавливает воспроизведение, когда буфер опустошается. Потом он ждёт, когда буфер полностью заполнится (я не знаю, можно ли это поведение поменять). Вопросы 3-4: плеер потому и не показывает, что оставшиеся 20 сек трафик не идёт, и не ведет закачку трафика в момент воспроизведения изображения и эвука потому что сервер ему не отдаёт ничего.

На примере графика с кешем 1200 мс хорошо видно: сначала высокий пик (это кеширование), потом плато (плеер показывает и одновременно поддерживает буфер заполненным, скорость примерно соответствует битрейту трансляции), потом отдача прекращается, и через секунду плеер глохнет.

Конечно, непонятно, почему у меня график другой: его хоть и колбасит, но без таких пауз. Может, из-за того, что мы в разных местах, может из-за того, что в разное время замеры делаем.

Ещё можно трейс сделать до сервера, с которого идёт вещание (173.mozhay.tv), посмотреть какие ip-шники по пути попадаются, вдруг натолкнёт на мысль.

Цитата:

..шаг на графике NetWorx, скорее всего, 30 секунд, а не минута.

В "моей" версии NetWorx 5.1.7 действительно минутные метки (без возможности их перемасштабирования) - я даже проверил секундомером.
Получается, что ширина каждого пика закачки равна 30 сек.


Цитата:

плеер потому и не показывает, что оставшиеся 20 сек трафик не идёт, и не ведет закачку трафика

Я исходил из того, что за время закачки (30 сек.), при моих возможностях сети (см. график закачки с торрента рис2 в предыдущем посте.), десятисекундный буфер уже заполнится, и начнется воспроизведение изображения и эвука.
Реально же воспроизведение изображения и эвука НЕ начинается до конца пика закачки и куда всеже идет трафик еще 20 сек? и почему воспроизведение изображения и эвука начинается только после пика закачки? рис1 в предыдущем посте.

Кстати, равные по ширине импульсы закачки, наводят на мысль о запрограммировании этого процесса у тех, кто отдает или передает мне трафик или плейер сам периодически рвет закачку?


Цитата:

трейс сделать до сервера, с которого идёт вещание

Сделать сходу не получилось. Разбираюсь .





Добавлено:
Сделал на 173.mozhay.tv, но оценить не могу.


На роутер не обращай внимание. Я его поставил только сегодня и картину происходящего он не изменил.

Я уже начинаю путаться, поэтому мне сложно дальше рассуждать. Пока как-то очень сумбурно все данные представлены.


Цитата:

Я исходил из того, что за время закачки (30 сек.), при моих возможностях сети (см. график закачки с торрента рис2 в предыдущем посте.), десятисекундный буфер уже заполнится, и начнется воспроизведение изображения и эвука.

Масштаба по горизонтали там нет, так что сложно говорить о каких-то конкретных значениях, будь то 30 сек или какое-то другое число.


Цитата:

Реально же воспроизведение изображения и эвука НЕ начинается до конца пика закачки

Да, плеер ждёт, когда заполнится буфер.
Надеюсь, мы одинаково понимаем термин "пик"? Я так:
Горка -- отдельная зелёная часть. Состоит из двух частей:
1) пик -- высокая часть (длиной в четверть для второй горки, в половину для третьей, почти во всю для четвёртой http://www.onlinedisk.ru/view/784580 )
2) плато -- ровненькая часть высотой на уровне 3.3 Мбит/с

Я бы не стал больше упоминать первые два рисунка, т.к. из них сложно вытащить полезную информацию: во-первых масштаб, а во-вторых там версия не официальная стабильная, и это может вносить дополнительную путаницу (может там переделано внутренне устройство; даже наверняка переделано, судя по номеру версии). Реально полезный пока только третий рисунок: есть масштаб, хоть и спорный, можно сравнить поведение при разных размерах буфера, и я могу сравнить со своим поведением, т.к. у меня только версия 1.1.11.

Торрент вообще отдельная песня. Соответствующий график показывает возможности внутренней сети, и не показывает возможности отдельно внешки.

Я бы попросил ещё раз уточнить масштаб по горизонтали на третьем рисунке. Потому что мне непонятно следующее. NetWorks и Диспетчер задач по-видимому показывают один и тот же промежуток времени в одном и том же масштабе. У меня в Диспетчере задач шаг сетки составляет 6 сек. Думаю, у тебя так же. Шаг NetWorx'a равен пяти шагам диспетчера (см. третий рисунок), т.е. 30 сек. Где я неправ?

Добавлено:
Лучше было трейс текстом давать.

Вот мой:


Добавлено:
Лучше было трейс текстом давать.

Вот мой:
[more=Трейс]C:\>tracert 173.mozhay.tv

Трассировка маршрута к 173.mozhay.tv [109.197.112.20]
с максимальным числом прыжков 30:

1 2 ms <1 мс 1 ms modem [192.168.16.1]
2 42 ms 45 ms 41 ms 10.16.255.136
3 68 ms 45 ms 51 ms 10.16.248.233
4 45 ms 45 ms 47 ms 10.16.248.70
5 43 ms 42 ms 44 ms 10.16.248.38
6 43 ms 42 ms 82 ms 10.16.248.42
7 45 ms 45 ms 45 ms 178.170.198.38
8 45 ms 60 ms 47 ms 81.211.10.241
9 62 ms 60 ms 59 ms 213.33.216.42
10 64 ms 65 ms 65 ms mks-gw.mkc-net.ru [91.210.84.194]
11 59 ms 62 ms 59 ms tv.mozhay.net [109.197.112.20]

Трассировка завершена. [/more]

Вот, маршруты у нас совсем разные, так что, в принципе это могут быть "козни" Ростелекома (серьёзно эту фразу воспринимать не стоит)

Цитата:

Надеюсь, мы одинаково понимаем термин "пик"? Я так:
Горка -- отдельная зелёная часть. Состоит из двух частей:
1) пик -- высокая часть (длиной в четверть для второй горки, в половину для третьей, почти во всю для четвёртой http://www.onlinedisk.ru/view/784580 )
2) плато -- ровненькая часть высотой на уровне 3.3 Мбит/с

Согласен со всем вышенаписанным. По аналогии с электроникой горку (отдельную зеленую часть) можно назвать импульсом. А поскольку график в NetWorx 5.1.7, как и в Диспетчере задач идет справа налево, то левое начало горки (импульса) называется передний фронт, а правый его конец- задний фронт или спад.

Цитирую себя:
..Реально же воспроизведение изображения и эвука НЕ начинается до конца пика закачки..

Здесь я неверно применил термин "пик". признаю. Здесь мне нужно было написать например: до конца горки , т.е. до заднего фронта или спада.


Цитата:

ещё раз уточнить масштаб по горизонтали

Масштаб по горизонтали в программе NetWorx 5.1.7 объявлен следующий:
Между соседними вертикальными линиями координатной сетки - 1минута.
Я замерял секундомером- любая точка (например передний фронт) любого импульса проходит между соседними вертикальными неподвижными линиями сетки за 1 минуту.
Длительность любого импульса закачки ( по его подошве) на глаз равна 30 сек.

Импульсы того же сигнала на Диспетчере задач у меня идут синхронно с импульсами в NetWorx. Кстати сетка в Диспетчере задач движется вместе симпульсами в ту же сторону.


Цитата:

У меня в Диспетчере задач шаг сетки составляет 6 сек. Думаю, у тебя так же

Что то я у себя (ХР SP3) не нашел где такие данные.

Нанес пояснения на рис.

Если площадью предыдущего импульса заполнить пустоту справа от себя до последующего, то выйдет средний уровень примерно в 3 Мбит/с
Кстати: расстояние справа от каждого импульса до последующего зависит от площади предыдущего . Получается, если предыдущий импульс закачки был мал то и буфер был недозаполнен и израсходовался он быстрее. Все это логично, но как мог знать провайдер или кто-то еще в сети, через кого идет трафик, что у меня опустошился буфер и вновь дать мне трафик на закачку?? Ведь она начинается именно в этот момент. Что-то здесь не вяжется. Неужели плейер сам рвет и возобновляет закачку?


Цитата:

Торрент вообще отдельная песня. Соответствующий график показывает возможности внутренней сети, и не показывает возможности отдельно внешки.

Хорошо. оставим торрент в покое, но ведь на графике для плейера видно, что скорость закачки может достигать 17 Мбит/сек, почему за 30 сек (время ширины импульса) может недозагрузиться 10 секундный буфер? Кстати, а для какого потока буфер объявлен 10 секундным?

Все пока надо остановиться- что то много вопросов возникло


Мой трейс

1.Трассировка сделана, когда нет закачки и плейер ровно воспроизводит изображение и звук

C:\Documents and Settings\Admin>tracert 173.mozhay.tv

Трассировка маршрута к 173.mozhay.tv [109.197.112.20]
с максимальным числом прыжков 30:

1 <1 мс <1 мс <1 мс Dlink-Router.Dlink [192.168.0.1]
2 3 ms 3 ms 3 ms ufa-core2-g4-34.bashtel.ru [83.174.192.34]
3 3 ms 3 ms 3 ms ufa-c1-g4-9-909.ufamts.ru [83.174.194.64]
4 4 ms 4 ms 5 ms h83-174-194-49.static.bashtel.ru [83.174.194.49]

5 5 ms 5 ms 4 ms 213.189.237.41
6 3 ms 3 ms 3 ms xe-3-1-0.519.ufa-rgr2.pv.ip.rostelecom.ru [87.226.140.105]
7 28 ms 27 ms 26 ms ae-8.m7-ar4.msk.ip.rostelecom.ru [87.226.133.178]
8 27 ms 26 ms 27 ms 87.226.202.242
9 27 ms 28 ms 27 ms mks-gw.mkc-net.ru [91.210.84.194]
10 31 ms 30 ms 30 ms tv.mozhay.net [109.197.112.20]

Трассировка завершена.
--------------------------------------------------------------------------------
2.Трассировка сделана, когда идет закачка и плейер не воспроизводит изображение и звук

C:\Documents and Settings\Admin>tracert 173.mozhay.tv

Трассировка маршрута к 173.mozhay.tv [109.197.112.20]
с максимальным числом прыжков 30:

1 <1 мс <1 мс <1 мс Dlink-Router.Dlink [192.168.0.1]
2 3 ms 3 ms 3 ms ufa-core2-g4-34.bashtel.ru [83.174.192.34]
3 3 ms 3 ms 3 ms ufa-c1-g4-9-909.ufamts.ru [83.174.194.64]
4 3 ms 3 ms 3 ms h83-174-194-49.static.bashtel.ru [83.174.194.49]

5 3 ms 3 ms 4 ms 213.189.237.41
6 5 ms 3 ms 3 ms xe-3-1-0.519.ufa-rgr2.pv.ip.rostelecom.ru [87.226.140.105]
7 26 ms 26 ms 26 ms ae-8.m7-ar4.msk.ip.rostelecom.ru [87.226.133.178]
8 26 ms 26 ms 26 ms 87.226.202.242
9 28 ms 26 ms 28 ms mks-gw.mkc-net.ru [91.210.84.194]
10 29 ms 28 ms 28 ms tv.mozhay.net [109.197.112.20]

Трассировка завершена.

C:\Documents and Settings\Admin>

to Trolzen


Цитата:

Ещё можно трейс сделать до сервера, с которого идёт вещание (173.mozhay.tv), посмотреть какие ip-шники по пути попадаются, вдруг натолкнёт на мысль.

Trolzen, а почему ты решил что трейс нужно делать на (173.mozhay.tv)?
Я посмотрел в логе VLC откуда идет вещание

#EXTINF:0,OSMY KANAL
http://clck.ru/Pj5L

и получилось это где то на украине.

Добавлено:

Цитата:

Trolzen, а почему ты решил что трейс нужно делать на (173.mozhay.tv)?
Я посмотрел в логе VLC откуда идет вещание

clck.ru -- это просто сокращалка адресов. Если по ней перейти в браузере или посмотреть в лог плеера, видно, что происходит редирект на mozhay.tv


Цитата:

#EXTINF:0,OSMY KANAL
http://clck.ru/Pj5L

Судя по записи, ты, видимо, смотрел в исходнике плейлиста, а не логе.


Цитата:

Что то я у себя (ХР SP3) не нашел где такие данные.

Я замерял сам вручную. Взял часы с секундной стрелкой, которые тикают раз в секунду и следил за движением сетки, слушая это тиканье. Так получилось 6 секунд на шаг сетки.


Цитата:

Кстати: расстояние справа от каждого импульса до последующего зависит от площади предыдущего .

Да, это странно.


Цитата:

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

Это неверно. Плеер ждёт, когда буфер заполнится полностью, по крайне мере у меня на версии 1.1.11 это так. Т.е. ни о каких недозаполненных буферах, которые расходуются быстрее, говорить нельзя.


Цитата:

Все это логично, но как мог знать провайдер или кто-то еще в сети, через кого идет трафик, что у меня опустошился буфер и вновь дать мне трафик на закачку?? Ведь она начинается именно в этот момент. Что-то здесь не вяжется.

Думаю, это совпадение: сервер перестаёт отдавать данные примерно в тот же момент, когда буфер успевает заполниться, и возобновляет передачу слегка после того, как буфер опустошится. По крайней мере случай 10000 мс на третьем графике очень хорошо вписывается в такую гипотезу: на первом импульсе видно маленькое плато, поеер начинает играть не в момент заднего фронта, а во время начала плато, и эта разница незаметна, а на следующих импульсах она просто меньше точности графика. Ну и проигрывание может заканчиваться не в момент переднего фронта, а чуть раньше, и это тоже сложно заметить, несколько секунд-то точно, график ведь не такой и точный и ползёт не непрерывно.


Цитата:

Мой трейс

Трейсы одинаковые, можно было не выкладывать оба, а просто сказать. Да и с чего бы им стать разными, маршруты же не меняются каждую секунду.

Кстати, другие непонятности вроде "Как же так? Почему плеер играет целую минуту при буфере 10 сек, не получая ни байта в это время?" могут быть объяснены тем, что плеер изменяет размер после каждого опустошения буфера. На это меня натолкнули вот такие строчки в логе:

Цитата:

main error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 4255 ms)

Хотя, я конечно могу ошибаться, потому что я не очень хорошо пониамю эту терминологию и не знаю, что это за PCR и pts_delay.

Вообще полезно смотреть подробный лог (Ctrl+M, детальность 2). Некоторые вещи там понятны и полезны. Например, можно следить, как заполняется буфер во времени. Или узнать, за какое время он заполнился, например

Цитата:

main debug: Stream buffering done (4650 ms in 4168 ms)

Иногда бывает даже так:

Цитата:

main debug: Stream buffering done (1224 ms in 4689 ms)

(стандартный буфер заполнялся целых 4,5 секунды)

Ну и вообще, нужно мерить, мерить и мерить. Много раз в разное время, и сопоставлять. По паре измерений сложно делать выводы. Короче ждём новые результаты замеров с уточнённой инфой о соответствии моментов при проигрывании и на графике, уточнённым масштабом и размерами буферов.

И про вставку картинок. После загрузки там справа есть четыре поля, одно из них -- "Для форумов:". Для загруженных ранее есть сссылка "Получить коды для данной картинки" под картинкой, по ней можно найти такие же четыре поля.

Цитата:

Судя по записи, ты, видимо, смотрел в исходнике плейлиста, а не логе.

Да нет. Смотрел я в логе да видно не тo вычитал:

...main error: open of `http://clck.ru/KCUw' failed
access_http error: failed to send request
access_http error: cannot connect to 173.mozhay.tv:80
access_mms error: cannot connect to 173.mozhay.tv:80
main error: open of `http://clck.ru/Pj5L' failed
access_http error: cannot connect to 195.211.252.12:8040
access_mms error: cannot connect to 195.211.252.12:8040
main error: open of `http://goo.gl/sxSCd' failed...

просто я простой юзер - отсюда все недоразумения


Цитата:

Взял часы с секундной стрелкой, которые тикают раз в секунду и следил за движением сетки, слушая это тиканье. Так получилось 6 секунд на шаг сетки.

Аналогично проверил секундомером -у меня здесь получилось 12 сек.


Цитата:

..мерить и мерить. Много раз в разное время, и сопоставлять.

Сегодня замерил тот же канал примерно в 8 часов GMT+5. Рис4.


После нажатия Play, и установления соединения, пошла закачка (кстати это общий трафик в комп). Примерно в середине 1го импульса появился застывший кадр без звука.
По спаду 1го импульса началось нормальное изображение и звук. Зоны нормального изображения и звука обозначены на графике голубым цветом.
По окончании голубой зоны начинается желтая зона, в которой плейер показывает застывший последний кадр от нормального изображения. Звук отсутствует.

Отличия от предыдущих измерений:
Однозначно прослеживается, что застывает изображение и пропадает звук не по фронту следующего импульса (начало закачки) а несколько позже- это видно на графике. Следовательно плейер пытается подкачать в свой буфер при воспроизведении фильма.

Возможно это было и при предыдущих замерах, но это не было замечено. График динамичен а восприятие субъективно.
Такое поведение плейера разумно, но я считаю, что он должен постоянно пополнять свой буфер, ориентируясь на скорость его опустошения и не давать ему это сделать.

Еще один момент:
Обрати внимание на оранжевые зоны по подошве импульсов. Это программа NetWorx нарисовала мой исходящий трафик, наложенный на входящий.
Конец исходящего трафика всегда совпадает с началом полки (уровень примерно 3 Мбит/с) на импульсах!

Здесь непонятно:
1. От меня шла исходящая команда на поддержание входящего трафика на уровне17 Мбит/с?
2. От меня шла команда на снижение уровня входящего трафика с 17 Мбит/с до 3 Мбит/с?

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

Вопрос -кто мне дозирует закачку остается.

Извините, если этот вопрос уже был. может я его пропустил.
можно ли отключить извечное кеширование ВЛС, или хотя бы сделать его недолгим. так на пару секунд..
устал уже постоянно ждать)

Цитата:

сделать его недолгим. так на пару секунд..

Так там по умолчанию стоит 1,2 сек.

wtau
видимо мой ВЛС
VLC_Portable_1.1.7_Multilingual этого не знает. а по сему в среднем и кэширует файлы по 30-40 секунд в лучшем случае)
а где на это умолчание можно посмотреть?)

Цитата:

а где на это умолчание можно посмотреть?

В моей версии 1.1.11 VLCPortable здесь:
Tools-Preferences-All-input/ Codecs-Access modules-HTTP(S)-Сaching value in ms
Там по умолчанию стояло 1200мс.
Наверное об этом идет речь?

VLC не может открыть один образ диска (FLAC+CUE) из-за хитрой буквы в названии. Исправил букву, вылезла другая проблема: неверно разбивает этот образ на треки, все треки одинаковой длины получаются.
Как скинуть его разрабам?

ToALL
Подскажите, есть видео с интернет потока, воспроизводимое через плеер. как его записать ?

Mirillis Action!

RTX
> Mirillis Action!
Что это?

zhuchella
> как его записать?
Как гуглили?
Ключ типа --sout=file/ps:mystream.mpg

Прошу объяснить, в чём разница между портабельной версией из шапки и в виде архива (например 7z) без установки с точки зрения пользователя и для реестра винды? Где сохраняются настройки?

wtau
Повторюсь: я тоже не понимаю, почему трафик такой странный. Мысль остлась только одна: "Шайтан!"


Цитата:

Аналогично проверил секундомером -у меня здесь получилось 12 сек.

Поковырялся немного. Оказывается в Диспетчере задач если менять скорость обновления, то шаг сетки меняется. Теперь после экспериментов у меня шаг тоже стал 12 сек. wtau, что ты сделал с моим компьютером?!


Цитата:

Обрати внимание на оранжевые зоны по подошве импульсов. Это программа NetWorx нарисовала мой исходящий трафик, наложенный на входящий.
Конец исходящего трафика всегда совпадает с началом полки (уровень примерно 3 Мбит/с) на импульсах!

На самом деле, исходящий трафик есть всегда из-за особенностей протокола TCP. Просто его не видно в период плато. Во время пика высота входящего -- 250px, исходящего -- 4px; входящего во время плато -- 47px. Выходит, что высота исходящего во время плато должна быть 4*47/250 = 0,752px. Так что ничего удивительного в том, что оранжевая часть во время плато отсутствует.


Цитата:

Здесь непонятно:
1. От меня шла исходящая команда на поддержание входящего трафика на уровне17 Мбит/с?
2. От меня шла команда на снижение уровня входящего трафика с 17 Мбит/с до 3 Мбит/с?

Нет никаких исходящих команд. Во время заполнения буфера плеер качает во всю ширь канала. А потом просто со скоростью опустошения буфера, равной битрейту потока.


Цитата:

Вопрос -кто мне дозирует закачку остается.

Сервер или пров (далее они). Ширина импульсов одинаковая => они выдают 30 сек непрерывного скачивания. То, что расстояние между импульсами меняется -- это странно. Возможно они подсчитывают накачанный трафик за это 30 сек и пропорционально ему меняют задержку. Напрашивается гипотеза, что у прова стоит какой-то странный шейпер. В этом рассуждении вроде противоречий нет, но я как-то всё равно не верю.

Надо было всё-таки посмотреть в логах, как меняется размер буфера для каждого импульса. Было бы интересно, хотя не думаю, что сильно помогло бы.

Вот ещё что надо попробовать. Надо понаблюдать за графиком при просмотре других каналов с меньшим битрейтом, про которые ты говорил, что нормально показываются. И чтобы канал был на том же mozhay.tv, или чтоб хотя бы маршрут примерно такой же был, через ростелеком.

lucky_Luk

Цитата:

VLC не может открыть один образ диска (FLAC+CUE) из-за хитрой буквы в названии. Исправил букву, вылезла другая проблема: неверно разбивает этот образ на треки, все треки одинаковой длины получаются.
Как скинуть его разрабам?

По-моему, на любых FLAC+CUE у отдельных треков показывается длина всего альбома, вне зависимости от хитрых букв. Но проигрывается всегда правильно. Баги вроде можно сообщать через официальный форум.

zhuchella

Цитата:

Подскажите, есть видео с интернет потока, воспроизводимое через плеер. как его записать ?

При открытии нужно нажимать не кнопку "Воспроизвести", а выбрать "Поток" в выпадающем списке рядом с этой кнопкой.

antabu

Цитата:

Прошу объяснить, в чём разница между портабельной версией из шапки и в виде архива (например 7z) без установки с точки зрения пользователя и для реестра винды? Где сохраняются настройки?

Похоже, портабельная хранит настройки рядом с бинарником, а архивная в профиле пользователя. Ну и ещё немного по ссылке: http://portableapps.com/support/vlc_portable#modifications
В реестре VLC ничего не хранит, кроме ассоциаций файлов и инфы о деинсталляции. Фактически, даже не он хранит, а виндовые подсистемы.