- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
function send_message_with_photo($token, $peer_id, $message, $image_file_path) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
/* Получаем ссылку для загрузки фотографии */
curl_setopt($ch, CURLOPT_URL, 'https://api.vk.com/method/photos.getMessagesUploadServer');
curl_setopt($ch, CURLOPT_POSTFIELDS, array(
"access_token" => $token,
"v" => "5.103"
));
$result = json_decode(curl_exec($ch), true);
$upload_url = $result['response']['upload_url'];
/* Отправляем фотографию */
curl_setopt($ch, CURLOPT_URL, $upload_url);
$file = curl_file_create($image_file_path);
curl_setopt($ch, CURLOPT_POSTFIELDS, array(
"photo" => $file,
));
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: multipart/form-data'));
$result = json_decode(curl_exec($ch), true);
$server = $result['server'];
$photo = $result['photo'];
$hash = $result['hash'];
/* Сохраняем фотографию */
curl_setopt($ch, CURLOPT_URL, 'https://api.vk.com/method/photos.saveMessagesPhoto');
curl_setopt($ch, CURLOPT_POSTFIELDS, array(
"access_token" => $token,
"v" => "5.103",
"server" => $server,
"photo" => $photo,
"hash" => $hash
));
$result = json_decode(curl_exec($ch), true);
$photo_id = strval($result['response'][0]['id']);
$owner_id = strval($result['response'][0]['owner_id']);
$attachment = "photo" . $owner_id . "_" . $photo_id;
/* Отправляем сообщение */
curl_setopt($ch, CURLOPT_URL, 'https://api.vk.com/method/messages.send');
curl_setopt($ch, CURLOPT_POSTFIELDS, array(
"access_token" => $token,
"v" => "5.103",
"random_id" => rand(),
"peer_id" => $peer_id,
"message" => $message,
"attachment" => $attachment
));
$result = json_decode(curl_exec($ch), true);
curl_close($ch);
}
Follow us!
я конечно не ожидал чего-то сверхъестественного от разработчиков контакта, но они блядь не могут даже статическую ссылку для загрузки сделать?
Я тут хотел написать длинную рецензию на видео https://www.youtube.com/watch?v=Qk9EKzxc9uE, но она оказалось слишком длинной, поэтому в адаптированном варианте я ее оставлю своим друзяшкам в том самом контакте, а здесь просто один из репозиториев автора видео, потому что остальные мне чет влом копать.
https://github.com/atercattus/quiz.sidenis.ru.solution
> Решение (исходный код Java приложения) запускается ... командной строкой:
> java -Xmx256M -Xms16M -Xbatch -XX:+UseSerialGc -XX:-TieredCompilation -XX:CICompilerCount=1 Main
казалось бы, раз человек ставит флаги - он знает, что они значат
> -Xmx256M -Xms16M
"начни с размера хипа в 16 метров и по необходимости раздувай до 256"
Все джависты знают, что сразу выставить хип в максимальное значение - это дешевле, чем дать ему туда добраться самому. Один хуй время аллокации хипа от этого не изменится, реальная инициализация страницы памяти происходит только при первом обращении к ней.
> -Xbatch
Отрубаем комиляцию кода в фоне, пусть идет в мейн-треде. Ну эээээ ладно, пускай
> -XX:+UseSerialGc
"Использовать последовательный сборщик мусора"
Очевидно, автор очень боится thread contention, контекст свитчей и всего вот этого - что бэкграунд треды JVM засрут ему весь пирформанс, поэтому, пожалуйста, не делайте сборку мусора в параллель с моим кодом. Предположим, это имеет право на жизнь, но есть нюанс. Serial GC появился до Parallel GC, который отличается от первого только тем, что работает параллельно в несколько тредов, сокращая таким образом время исполнения. Видимо, потоки это настолько богохульная тема, что даже видимый нам карго-культ не так страшен.
Отрубить к хуям промежуточный компилятор и либо интерпретировать код, либо компилить его более лучшим компилятором, который должен выкинуть все лишнее. Но есть нюанс.
- Мы любим JIT за PGO, а профайл собирается как раз выхлопом промежуточного компилятора
- Бэкграунд-компиляция, как мы помним, отключена, то есть всё встает как только компилятор начинает работать
- И ладно бы он просто сразу всё откомпилил, у него ж еще есть трешолды (по количеству вызовов метода), до достижения которых вообще будет работать медленный интерпретатор
-XX:CICompilerCount=1
"Использовать только один тред для компиляции"
Я, блядь, уже просто отказываюсь это комментировать
Внутренности там тоже забавные, даже не олимпиадным стилем программирования, а тем, что он заранее подсчитывает суммы для всей матрицы, и при обновлении одного элемента пересчитываются все последующие суммы.
Другими словами, если бы хитрые организаторы подавали на вход не рандом, а обновление первого элемента N раз, они могли бы устроить его решению DOS-атаку.
Там ещё жаба-машину нужно прогревать перед запуском, но об этом уже сказано:
>у него ж еще есть трешолды (по количеству вызовов метода), до достижения которых вообще будет работать медленный интерпретатор
Но я чёт особенно проиграл с этого
Кстати, царь на ГК как раз же складывал элементы матрицы?
Ведь задача какая была?
Показать, что жаба-отребье обделалось.
Версия на сишке компактней, быстрее, проще и выигрывает во всём.
>XX:+UseSerialGc
К тому же, нужно понимать, что никому никакие многопоточные оптимизации gc сишке ненужны.
Ну и пару императивных строк, которые в говне валяют эти потуги.
Поэтому жаба-отребье так любит брать подобную херню и кого-то побеждать, правда оппонент как всегда не явился.
Пойти и писать реальные программы, реальную логику - отребье не может.
Соревноваться с лучшим - это не удел отребья.
Жаба-отребье, как и всякое другое отребье не может ничего родить. Оно может только воровать, врать и соревноваться с другими инвалидами.
>-XX:-TieredCompilation -XX:CICompilerCount=1
Очевидно, что с простым «си» они соревноваться не могут. Поэтому удел отребья - морочить себе голову каким-то непонятным говном, причём даже не имея нужного функционала.
все поиметь пропаганда настолько мразью быть снабжена информацией об этом можно ужать строк до где в конце выдавать все тезисы этого там вс то насколько сильно не быть ссылка может .
тогда когда оно страшное не имеет проблему фундаментальную проблему что такое не си на самом деле нормальное число а если же сделали больше чем нужно все пойдет как и ифов .
не потому что дизайн этого ублюдка так не мой код ты бы создать структуру с файлами и что пыталось родить это просто насрала рандомными символами которые она везде это поток .
вот полноценный вариант который первый на этом будет больше но я могу спокойно пишется строковое представление об ошибке здесь увидел ошибку любой адекватный челове крешит это дошкол нок это генераций .
адресуется вс остальное что их это может только попробуйте осознать это устаревшее говно обладает самантикой недоязычка с файлами и что разделение .
>музыки ВКонтакте
Фублядь, фунахуй.
Эти клоуны в 2к20 продолжают раздавать музло в издохшем mp3.
И до сих анскилябры не могут перейти на божественный opus.
они взяли биндинги libmad для гошки - они их не устроили по производительности
тогда что они делают? вызывают ffmpeg
нет, не libffmpeg
они натурально кормят файл в экзекьютабл через stdin и сохраняют stdout в память
так перформанса больше
там еще про heap очень смешно, вместо того, чтобы выяснить, где именно тормозит, они тупо отдали сишникам, типа мы ниче не понимаем, сделайте шонибудь
Да норм решение, на самом деле. Простое, асинхронное, да и процессы на линуксе не такие уж дорогие.
Я не думаю, что перенос кодека в процесс go даст какой-то значительный выигрыш. А ёбли с вызовом сишной либы будет на порядок больше.
Ну и это про звук, для видео все эти копирования будут просто ничтожны на фоне самого кодека.
вызов библиотеки напрямую: копирование с диска в буфер -> передача буфера в функцию библиотеки -> построение нового массива байт с декодированным содержимым и его возврат
вызов executable: копирование с диска в буфер -> копирование из буфера в пайп -> чтение из пайпа в буфер -> передача буфера в функцию библиотеки -> построение нового массива байт с декодированным содержимым -> копирование в пайп -> чтение из пайпа
плюс еще постоянные переходы из юзерлэнда в кернел и наоборот
чет дохуя для ребят, которые рассказывают нам на «HighLoad++» историю про эффективное программирование и ускорение работы, когда вся обработка ведется на цпу
хотя они там и параллелят не по ядрам, а по файлам
ffmpeg — это standalone приложение работает и с файлами и с stdin/stdout пайпами.
Традиционно вместо имени файла ставят минус.
capture /dev/stdout | ffmpeg -i -
Они всё делают по-царски, для оптимальности переопределяют malloc линкуемой либы, чтобы не делать лиший memcpy.
И кодек сам высирает кодированный стрим обратно же во внутренние буфера ffmpeg.
Или берёт flac, демуксит его, потом декодирует и пересылает декодированое в opus.
Нет, в целом я использовал такое локально и решение нормальное.
Но через пайп иногда проблемы бывают. У меня когда-то цветовые профили хериться начали. Через либы биндинг к ffmpeg всё работает, а через пайп надо дрочиться с аргументами, потому что у видео цвета поплыли.
У headless сервака... Походу там в любом случае с опциями дрочиться.
>тогда что они делают? вызывают ffmpeg
Да анскильные отбросы. О чём речь.
К ffmpegy давно прикручены все мыслимые и немыслимые биндинги: libmad, libopus, libfdk_aac.
Там натурально поддерживаются сотни либ.
Такой либы нет в принципе.
Возможно вы имели ввиду libavcodec
При запуске ffmpeg показывает, какие у него внутри либы и с чем он слинкован.
Потому что анскильные гугло-питушки, писавшие vp8/vp9 не шмогли даже написать приличный декодер для СВОИХ же кодеков.
2. Какая разница конченому пользователю от этого? Судя по графикам, MP3 на стандартных 128kbps выдаёт обратно не меньше ценного меха, чем Opus. Делать ниже 128 особого смысла наверно нет, т.к. основная нагрузка на пространство и трафик - скорее всего картиночки, а не музыка.
Потому что патент закончился.
https://www.telegraph.co.uk/technology/2017/05/15/creators-mp3-declare-dead/
1 минута музыки в 128 — примерно мегабайт. А люди часто льют 320.
Не знаю. Возможно у Алишера куры денег не клюют, и ему хватает на оплату лишних серверов и траффика.
>Какая разница конченому пользователю от этого?
Качество заметно выше .
>Судя по графикам, MP3 на стандартных 128kbps выдаёт обратно не меньше ценного меха, чем Opus.
Нет. Нужно судить не по графикам, а по прослушиванию.
В MP3 на 128kbps заметны артефакты. Он очень сильно режет высокие частоты.
Даже 320kbps не считаются прозрачными.
Опус 128kbps stereo считается практически прозрачным.
То есть разницу может услышать только упоротый аудиофил, при многократном задрачивании.
А opus 160kbps от flaca не отличают даже самые упоротые аудиофилы.
https://people.xiph.org/~xiphmont/demo/celt/demo.html
https://people.xiph.org/~greg/opus/ha2011/
https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml
https://people.xiph.org/~jm/opus/opus-1.2/
https://people.xiph.org/~jm/opus/opus-1.3/
В самом кодеке нет. В 1.3 сделали простенький RNN для определения speech/music.
Чувак, купи приличные колонки, 128kbps звучит как сраный pottyphone.
пффф, да ему хватает даже на олимпиадников
Какие-то анскильные графики.
Судя по спектрограммам MP3 — это жуткий пиздец.
MP3
https://people.xiph.org/~xiphmont/demo/celt/pr-spec.mp3.png
Opus
https://people.xiph.org/~xiphmont/demo/celt/pr-spec.celt.png
Оригинал
https://people.xiph.org/~xiphmont/demo/celt/pr-spec.orig.png
Он заточен под всё сразу. Это гибридный кодек.
У Opusа очень низкая алгоритмическая задержка и отсутствие патентов.
И звучит при 48kbps лучше чем mp3 при 128 kbps. Вообще по тестам на 64kbps звучит он лучше чем у aac, ogg.
https://upload.wikimedia.org/wikipedia/commons/e/ec/Opus_bitrate%2Blatency_comparison.svg
https://upload.wikimedia.org/wikipedia/commons/8/8d/Opus_quality_comparison_colorblind_compatible.svg
очередной спич-кодек, расходимся
Тебе, безусловно, виднее.
Спешите видеть! Дурачок определяет качество звука по циферке битрейта.
Ещё раз повторяю: даже 96kbps достаточно для достижения transparency на большинстве сэмплов.
Да и ржачно почитать откровения идиотов.
Тут посоны на гидрогене вообще спорят: 80 или 96?
https://hydrogenaud.io/index.php/topic,114656.0.html
На самом деле факт, кстати. Корректнее будет сравнивать какой-нибудь «gif» и «jpeg».
«BMP», если не вдаваться в извращения — это просто матрица пикселей безо всякого сжатия. И именно поэтому качество картинки в «BMP» всегда будет максимальным, «BMP» просто не может какую-то инфу из неё потерять. А вот «JPEG» информацию теряет всегда.
Кстати, если сохранить тот же квадрат в четырёхбитном «PNG», то обратно он разожмётся тоже без потерь. А весить будет 583 байта — против 16833 байт у «JPEG» (для любого качества).
Про размер, кстати, тоже не совсем верно: изображение из одного пикселя в «BMP» (24 бита) будет весить 58 байт, в «JPEG» (100) — 784.
Надо изучить документацию, чтобы понять, что же реально в этом случае хранится в джипеге.
Есть «GIF89a» с дополнительными фишками, которых нет у «BMP». Это, например, анимация. Вообще спецификация «GIF89a» включала особенности, делающие его похожим на HTML или на SWF: наложение текста (именно в виде текста, а не в виде растра), интерактивные компоненты (видел демонстрационный вьюер, который это всё поддерживал). Но из этого всего прижилась только анимация.
При сплошной заливке достаточно сохранить одну частоту. Квадрат 8×8 превратится в один пиксель. Итого нужно сохранить 113×113 пикселей = 12769 пикселей, зожатых по фомфану.
Как я уже заметил, «BMP» бывает с «RLE» (правда, «RLE» не везде поддерживается). Если зожать с «RLE», то каждая строка будет выглядеть как один пиксель («BMP» зожимает только в горизонтальном направлении). Итого будет сохранено 900 пикселей.
А видеокодек на сплошной заливке управится в 1 бит символ* "totally predicted" на квадратик.
* символ может занять меньше бита, намного меньше бита если он предсказуем
Хорошо, что вас не пускают на стековерфлоу.
всё-таки удалось реализовать алгоритм бесконечного зожатия?
См., напр., «орефметическое кодирование».
https://youtu.be/uaRlBavLCN4
Момеда не знаю.
opus более экономно расходует битрейт за счёт гораздо более продвинутых алгоритмов и консервации аудиоэнергии.
mp3 тупо режет высокие, сколько ты ему не дай. А в 320kbps у него треть битрейта вообще уходит в паддинг пакетов.
Потому 320kbps mp3 обычно зожимаются до 70-80% простым архиватором. Можете сами убедиться.
(Кстати, тут как раз и битрейт понадобится.
Зожмёт, и ушами ты разницы не услышишь. Но ведь это далеко не всё, что требуется от сигнала с 20-разрядного АЦП и частотой в несколько сотен килогерц, да?
Transparency is not an upper limit. Identity transformation it transparent too.
A transparent rustery could be an identity transformation or a limiting rustery like MP3. I don't know what kind of rustery Opus could provide except of transparency.
Это англоязычные вореции?
§1. roost - петух
§2. rust - питух
Зожмёт.
> 20разрядного АЦП и
> частоты несколько сотен килогерц?
https://wiki.xiph.org/OpusFAQ#Does_Opus_support_higher_sampling_rates.2C_such_as_96_kHz_or_192_kHz.3F
Does Opus support higher sampling rates, such as 96 kHz or 192 kHz?
Yes and no.
Opus encoding tools like opusenc will happily encode input files that are sampled at 96 or 192 kHz.
However, files at these rates are internally converted to 48 kHz and then only frequencies up to 20 kHz are encoded.
The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information.
Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.
If you want a codec to handle high sampling rates losslessly, use FLAC!
Но мы же хотим лосси, просто лосси!
Вот из-за такого пиздобольства им и нет доверия.