1. PHP / Говнокод #26405

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    42. 42
    43. 43
    44. 44
    45. 45
    46. 46
    47. 47
    48. 48
    49. 49
    50. 50
    51. 51
    52. 52
    53. 53
    54. 54
    55. 55
    56. 56
    57. 57
    58. 58
    59. 59
    60. 60
    61. 61
    62. 62
    63. 63
    64. 64
    65. 65
    66. 66
    67. 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);
    }

    Говнокод для загрузки фото в ВК)

    Запостил: kaluginvlad, 01 Февраля 2020

    Комментарии (104) RSS

    • Попахивает говнецом...
      Ответить
      • Хотя нет, через API же. Я ещё долго невкуривал, почему UserAgent не заляпали.
        Ответить
    • любой бэк не на js попахивает говнецом
      Ответить
    • > Получаем ссылку для загрузки фотографии

      я конечно не ожидал чего-то сверхъестественного от разработчиков контакта, но они блядь не могут даже статическую ссылку для загрузки сделать?
      Ответить
    • Именно поэтому я за пхп
      Ответить
    • Одному мне кажется, что с активизацией уебка 3,14 срущего ворециями, нахождение на говнокоде стало неприятно?
      Ответить
    • Access token вида 533bacf01e11f55b536a565b57531ac114461ae8 736d6506a3, какой-то hash и random_id которые пихаются туда сюда, сделали бы уже по-человечески v2 апи и по-тихоньку бы слили этот, оно ж застряло в 2012-м.
      Ответить
      • > сделали бы уже по-человечески

        Я тут хотел написать длинную рецензию на видео 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, который отличается от первого только тем, что работает параллельно в несколько тредов, сокращая таким образом время исполнения. Видимо, потоки это настолько богохульная тема, что даже видимый нам карго-культ не так страшен.
        Ответить
        • > -XX:-TieredCompilation
          Отрубить к хуям промежуточный компилятор и либо интерпретировать код, либо компилить его более лучшим компилятором, который должен выкинуть все лишнее. Но есть нюанс.
          - Мы любим JIT за PGO, а профайл собирается как раз выхлопом промежуточного компилятора
          - Бэкграунд-компиляция, как мы помним, отключена, то есть всё встает как только компилятор начинает работать
          - И ладно бы он просто сразу всё откомпилил, у него ж еще есть трешолды (по количеству вызовов метода), до достижения которых вообще будет работать медленный интерпретатор

          -XX:CICompilerCount=1
          "Использовать только один тред для компиляции"
          Я, блядь, уже просто отказываюсь это комментировать

          Внутренности там тоже забавные, даже не олимпиадным стилем программирования, а тем, что он заранее подсчитывает суммы для всей матрицы, и при обновлении одного элемента пересчитываются все последующие суммы.
          Другими словами, если бы хитрые организаторы подавали на вход не рандом, а обновление первого элемента N раз, они могли бы устроить его решению DOS-атаку.
          Ответить
          • Да. Это всё ржачно.

            Там ещё жаба-машину нужно прогревать перед запуском, но об этом уже сказано:
            >у него ж еще есть трешолды (по количеству вызовов метода), до достижения которых вообще будет работать медленный интерпретатор

            Но я чёт особенно проиграл с этого
            Царь-задача
            
            Дана квадратная матрица A[0...N-1, 0...N-1]. Вашей программе могут поступать запросы двух типов:
            
            Напишите Java приложение под jdk 1.8.
            
            Входные данные подаются приложению в стандартном потоке ввода (System.in). Приложение должно выводить ответ в стандартный поток вывода (System.out).
            
            Решение проверяется на наборе тестов. Time Limit на один тест 2 секунды. За каждый непройденный тест (вердикт не АС) штраф 10 секунд. Memory Limit на один тест 256 Мб.
            Ответить
            • > царь задача

              Кстати, царь на ГК как раз же складывал элементы матрицы?
              Ответить
          • Золотые, бессмертные строки Царя как нельзя лучше подходят к моменту

            Ведь задача какая была?

            Показать, что жаба-отребье обделалось.

            Версия на сишке компактней, быстрее, проще и выигрывает во всём.

            >XX:+UseSerialGc
            К тому же, нужно понимать, что никому никакие многопоточные оптимизации gc сишке ненужны.

            Ну и пару императивных строк, которые в говне валяют эти потуги.

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

            Пойти и писать реальные программы, реальную логику - отребье не может.

            Соревноваться с лучшим - это не удел отребья.

            Жаба-отребье, как и всякое другое отребье не может ничего родить. Оно может только воровать, врать и соревноваться с другими инвалидами.

            >-XX:-TieredCompilation -XX:CICompilerCount=1
            Очевидно, что с простым «си» они соревноваться не могут. Поэтому удел отребья - морочить себе голову каким-то непонятным говном, причём даже не имея нужного функционала.
            Ответить
            • про нулл терминаторы в рожи сектантов и начинается оно заменяет список захвата выглядит как должна быть ссылка может кончится расширяется она спастила из тонн синтаксического мусора скобочек и поэтому прибежал .

              все поиметь пропаганда настолько мразью быть снабжена информацией об этом можно ужать строк до где в конце выдавать все тезисы этого там вс то насколько сильно не быть ссылка может .

              тогда когда оно страшное не имеет проблему фундаментальную проблему что такое не си на самом деле нормальное число а если же сделали больше чем нужно все пойдет как и ифов .

              не потому что дизайн этого ублюдка так не мой код ты бы создать структуру с файлами и что пыталось родить это просто насрала рандомными символами которые она везде это поток .

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

              адресуется вс остальное что их это может только попробуйте осознать это устаревшее говно обладает самантикой недоязычка с файлами и что разделение .
              Ответить
        • >Архитектура и алгоритмы для индексации всей музыки ВКонтакте
          >музыки ВКонтакте

          Фублядь, фунахуй.

          Эти клоуны в 2к20 продолжают раздавать музло в издохшем mp3.

          И до сих анскилябры не могут перейти на божественный opus.
          Ответить
          • да там хорошо, ну чего
            они взяли биндинги libmad для гошки - они их не устроили по производительности
            тогда что они делают? вызывают ffmpeg
            нет, не libffmpeg
            они натурально кормят файл в экзекьютабл через stdin и сохраняют stdout в память
            так перформанса больше

            там еще про heap очень смешно, вместо того, чтобы выяснить, где именно тормозит, они тупо отдали сишникам, типа мы ниче не понимаем, сделайте шонибудь
            Ответить
            • > ffmpeg через stdin

              Да норм решение, на самом деле. Простое, асинхронное, да и процессы на линуксе не такие уж дорогие.
              Ответить
              • но как же пирформанс и многократное копирование одних и тех же байтов туда-сюда
                Ответить
                • А что пирфоманс? Сишный код в ffmpeg'е делает всю тяжёлую работу, пайпы в линуксе очень шустрые, а го тупо работает передастом.

                  Я не думаю, что перенос кодека в процесс go даст какой-то значительный выигрыш. А ёбли с вызовом сишной либы будет на порядок больше.

                  Ну и это про звук, для видео все эти копирования будут просто ничтожны на фоне самого кодека.
                  Ответить
                  • > пайпы в линуксе очень шустрые

                    вызов библиотеки напрямую: копирование с диска в буфер -> передача буфера в функцию библиотеки -> построение нового массива байт с декодированным содержимым и его возврат

                    вызов executable: копирование с диска в буфер -> копирование из буфера в пайп -> чтение из пайпа в буфер -> передача буфера в функцию библиотеки -> построение нового массива байт с декодированным содержимым -> копирование в пайп -> чтение из пайпа

                    плюс еще постоянные переходы из юзерлэнда в кернел и наоборот

                    чет дохуя для ребят, которые рассказывают нам на «HighLoad++» историю про эффективное программирование и ускорение работы, когда вся обработка ведется на цпу

                    хотя они там и параллелят не по ядрам, а по файлам
                    Ответить
                    • а если я неправильно понял, и ffmpeg работает с файлами, а не stdin/stdout, то это еще хуже: чтение с диска, запись на диск, еще одно чтение с диска, причем вавка-то легко весит уже солидную сотню мегабайт
                      Ответить
                      • >и ffmpeg работает с файлами, а не stdin/stdout

                        ffmpeg — это standalone приложение работает и с файлами и с stdin/stdout пайпами.

                        Традиционно вместо имени файла ставят минус.

                        capture /dev/stdout | ffmpeg -i -

                        Ответить
                        • да, я просто не уверен, как конкретно эти ребята кормят - через путь к файлу или через stdin-пайп
                          Ответить
                          • Смысл в том что ffmpeg внутри себя декодит, а потом просто пересылает указатель на сырой фрейм-буфер в нужный кодек.

                            Они всё делают по-царски, для оптимальности переопределяют malloc линкуемой либы, чтобы не делать лиший memcpy.

                            И кодек сам высирает кодированный стрим обратно же во внутренние буфера ffmpeg.
                            commit 9e62e1a1104bb0d64e604051ffc25004ad748eaf
                            Author: James Almer <[email protected]>
                            Date:   Mon Mar 18 10:38:31 2019 -0300
                            
                                avcodec/libdav1d: use a reference to the allocated buffer instead of wrapping the Dav1dPicture
                                
                                Removes an av_malloc() per frame.
                            
                            commit 28746a0e2088d762817795a0833df8633d8be6d2
                            Author: James Almer <[email protected]>
                            Date:   Tue Mar 12 19:11:19 2019 -0300
                            
                                avcodec/libdav1d: use a custom picture allocator
                                
                                Replaces the libdav1d internal allocator. It uses an AVBufferPool to reduce the
                                amount of allocated buffers.
                                About 5% speed up when decoding 720p or higher streams.
                                
                                Reviewed-by: "Vittorio Giovara <[email protected]>"
                                Signed-off-by: James Almer <[email protected]>

                            Ответить
                            • ты заебал со стертором пиздеть
                              Ответить
                            • > ffmpeg внутри себя декодит, а потом просто пересылает указатель на сырой фрейм-буфер в нужный кодек.

                              возможно, вы имели ввиду "вытаскивает из контейнера"?
                              Ответить
                              • Он берёт допустим H.265 стрим, декодит его в сырой буфер. И отсылает сырые кадры в x264.

                                Или берёт flac, демуксит его, потом декодирует и пересылает декодированое в opus.
                                Ответить
                                • H.265 это сжиматель?

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

                                  Задача ffmpeg всю эту капусту разобрать, и отдать кодекам уже данные, которые они могут играть?
                                  Ответить
              • > ffmpeg через stdin
                Нет, в целом я использовал такое локально и решение нормальное.

                Но через пайп иногда проблемы бывают. У меня когда-то цветовые профили хериться начали. Через либы биндинг к ffmpeg всё работает, а через пайп надо дрочиться с аргументами, потому что у видео цвета поплыли.
                Ответить
                • > цветовые профили

                  У headless сервака... Походу там в любом случае с опциями дрочиться.
                  Ответить
            • >они взяли биндинги libmad для гошки - они их не устроили по производительности
              >тогда что они делают? вызывают ffmpeg

              Да анскильные отбросы. О чём речь.

              К ffmpegy давно прикручены все мыслимые и немыслимые биндинги: libmad, libopus, libfdk_aac.

              Там натурально поддерживаются сотни либ.
              Ответить
            • >libffmpeg

              Такой либы нет в принципе.
              Возможно вы имели ввиду libavcodec

              При запуске ffmpeg показывает, какие у него внутри либы и с чем он слинкован.

              ffmpeg version  Copyright (c) 2000-2019 the FFmpeg developers
                configuration: --enable-gpl --enable-nonfree --enable-libvmaf --enable-version3 --enable-libx264 --enable-libvpx --enable-libx265 --enable-libopus 
              --enable-libaom --enable-libdav1d --enable-sdl2 --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libvorbis --enable-libfreetype --assert-level=1 
                built with clang version 8.0.0
                libavutil      56. 35.101 / 56. 35.101
                libavcodec     58. 60.100 / 58. 60.100
                libavformat    58. 33.100 / 58. 33.100
                libavdevice    58.  9.100 / 58.  9.100
                libavfilter     7. 66.100 /  7. 66.100
                libswscale      5.  6.100 /  5.  6.100
                libswresample   3.  6.100 /  3.  6.100
                libpostproc    55.  6.100 / 55.  6.100
              Hyper fast Audio and Video encoder
              Ответить
              • хмм, походу это какое-то кустарное произведение https://www.google.com/search?q=libffmpeg.so https://github.com/cpp-labs/ffmpeg/blob/master/armeabi-v7a/libffmpeg.so
                Ответить
                • Это хромое гавнище чтобы в браузеры типа оперы и хрома запихнуть шустрый ffmpeg-декодер.

                  Потому что анскильные гугло-питушки, писавшие vp8/vp9 не шмогли даже написать приличный декодер для СВОИХ же кодеков.
                  Ответить
          • 1. Почему издохшем?
            2. Какая разница конченому пользователю от этого? Судя по графикам, MP3 на стандартных 128kbps выдаёт обратно не меньше ценного меха, чем Opus. Делать ниже 128 особого смысла наверно нет, т.к. основная нагрузка на пространство и трафик - скорее всего картиночки, а не музыка.
            Ответить
            • > почему издохшем

              Потому что патент закончился.
              Ответить
              • Хмм, то есть это теперь такой же опенсорс, как и Опус, если использовать правильные библиотеки. Тогда и для серверной стороны он ничем не плох.
                Ответить
            • https://www.npr.org/sections/therecord/2017/05/11/527829909/the-mp3-is-officially-dead-according-to-its-creators

              https://www.telegraph.co.uk/technology/2017/05/15/creators-mp3-declare-dead/
              Ответить
            • >Делать ниже 128 особого смысла наверно нет, т.к. основная нагрузка на пространство и трафик - скорее всего картиночки, а не музыка.

              1 минута музыки в 128 — примерно мегабайт. А люди часто льют 320.
              Не знаю. Возможно у Алишера куры денег не клюют, и ему хватает на оплату лишних серверов и траффика.

              >Какая разница конченому пользователю от этого?
              Качество заметно выше .

              >Судя по графикам, MP3 на стандартных 128kbps выдаёт обратно не меньше ценного меха, чем Opus.

              Нет. Нужно судить не по графикам, а по прослушиванию.
              В MP3 на 128kbps заметны артефакты. Он очень сильно режет высокие частоты.
              Даже 320kbps не считаются прозрачными.

              Опус 128kbps stereo считается практически прозрачным.
              То есть разницу может услышать только упоротый аудиофил, при многократном задрачивании.
              А opus 160kbps от flaca не отличают даже самые упоротые аудиофилы.

              Ответить
              • А в «Opus» используется «Машинное Обучение» и «Искусственный Интеллект»?
                Ответить
                • Сейчас вместо них применяют "сквозных цифровых технологий", "блокчейн" и "квант"

                  https://www.kommersant.ru/doc/4242911
                  Ответить
                • Материалы для внеклассного чтения.

                  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.
                  Ответить
              • > В MP3 на 128kbps заметны артефакты
                Чувак, купи приличные колонки, 128kbps звучит как сраный pottyphone.
                Ответить
              • > Возможно у Алишера куры денег не клюют, и ему хватает на оплату лишних серверов и траффика.

                пффф, да ему хватает даже на олимпиадников
                Ответить
            • > Судя по графикам, MP3 на стандартных 128kbps выдаёт обратно не меньше ценного меха, чем Opus.

              Какие-то анскильные графики.
              Судя по спектрограммам 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
              Ответить
              • 128kbps нужен только для того, чтобы ужаснуть Кортни Лав паршивым качеством

                очередной спич-кодек, расходимся
                Ответить
                • > очередной спич-кодек, расходимся
                  Тебе, безусловно, виднее.
                  Ответить
                  • Разумеется. Ведь если бы было виднее тебе, то ты и твой опус бы обязательно бы похвастались средними и высокими битрейтами, а не 128kbps.
                    Ответить
                    • >средними и высокими битрейтами, а не 128kbps.

                      Спешите видеть! Дурачок определяет качество звука по циферке битрейта.

                      Ещё раз повторяю: даже 96kbps достаточно для достижения transparency на большинстве сэмплов.
                      Ответить
                      • Пи, зачем ты говоришь с уёбком? Он же нихуя ни в чем не понимает, просто несет какую-то бессмысленную хуйню. Хуже вореций, ей богу.
                        Ответить
                        • Сугубо в просветительских целях. Может кому-то ещё интересно.

                          Да и ржачно почитать откровения идиотов.

                          Тут посоны на гидрогене вообще спорят: 80 или 96?
                          https://hydrogenaud.io/index.php/topic,114656.0.html
                          >Yes, I've done some ABX listening tests to find out about my point of transparency.
                          >--bitrate 96 is transparent to me for the vast majority of even critical samples. If you ignore these you can go even lower.
                          >There were samples that weren't totally fine using --bitrate 96. With one exception even they were transparent using --bitrate 128.
                          
                          >I'll be honest, I struggled to ABX at 64kbps. 80kbps is enough for me.
                          
                          >It was easy to ABX Opus 160kbps in the days Opus were celt 0.11.2 in 2011, but there were tremendous amount of improvement since then.
                          >https://kamedo2.hatenablog.jp/entry/20110701/1309515702
                          Ответить
                          • Если я верно понимаю, то битрейт это количество бит в секунду, используемых для кодировки звука.

                            Разные кодеки могут использовать эти биты по разному.

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

                            "bmp" весит много больше "jpeg", но совсем не факт, что картинка будет там лучше)_
                            Ответить
                            • > "bmp" весит много больше "jpeg", но совсем не факт, что картинка будет там лучше)_
                              На самом деле факт, кстати. Корректнее будет сравнивать какой-нибудь «gif» и «jpeg».
                              Ответить
                              • Нахуя вообще сравнивать LZW и DCT? А долбоеб выше так вообще RLE приволок...
                                Ответить
                              • "gif" примерно так же и устроен как bmp, но только цвета там индксные, нет?

                                Качество может быть хуже, а может быть и таким же, смотря что нарисовано.

                                Сохрани мне черный квадрат 900x900 в 24х битном bmp, потом конвертни в JPEG, и сравни размер.
                                Ответить
                                • Да, это я туплю, забыл, что там тоже сжатия нет, только похеривание палитры.

                                  «BMP», если не вдаваться в извращения — это просто матрица пикселей безо всякого сжатия. И именно поэтому качество картинки в «BMP» всегда будет максимальным, «BMP» просто не может какую-то инфу из неё потерять. А вот «JPEG» информацию теряет всегда.
                                  Ответить
                                  • mp3 всегда оберзает верхние частоты, но если у меня нет таких частот, то я ничего не теряю.

                                    проверь мой примерн с черным квадратом 900x900 :)
                                    Ответить
                                    • Проверил. На высоком качестве (>80) зожимает и разжимает правильно. На 70 получается дрисня: вместо 900*900 пикселей FF000000 половина оказывается FF010101.
                                      Ответить
                                      • я сохранял на максималном
                                        разница в размере довольно большая, не правда ли?
                                        Ответить
                                        • Большая. Впрочем, она никак не опровергает мой первый коммент.

                                          Кстати, если сохранить тот же квадрат в четырёхбитном «PNG», то обратно он разожмётся тоже без потерь. А весить будет 583 байта — против 16833 байт у «JPEG» (для любого качества).
                                          Ответить
                                          • ну ладно, можешь заменить "jpg" на "png" в моем примере.

                                            Причем в png еще и прозрачность бывает

                                            >Впрочем, она никак не опровергает мой первый коммент.
                                            Да ну?

                                            Есть два файла c черным квадратом
                                            * bmp
                                            * jpeg высшего качества
                                            * размер файлов разный
                                            * картинка одинаковая

                                            что не так?
                                            Ответить
                                            • Если уж вдаваться в формализм без неопределённого поведения, то исходное утверждение нужно сформулировать так:
                                              Для любой картинки x, Q(BMP(x)) ≥ Q(JPEG(x)), где Q(x) — качество картинки.

                                              Про размер, кстати, тоже не совсем верно: изображение из одного пикселя в «BMP» (24 бита) будет весить 58 байт, в «JPEG» (100) — 784.
                                              Ответить
                                              • согласен с формулировкой

                                                и про размер тоже согласен, потому я и предложил 900x900
                                                Ответить
                                      • Они умудрились испортить сплошную заливку? Какой скилл )))

                                        Надо изучить документацию, чтобы понять, что же реально в этом случае хранится в джипеге.
                                        Ответить
                                      • И ещё замечание: JPEG вроде хранит не RGB, а яркость и цветоразностные кокококомпоненты (Y-R), (Y-B). Поскольку яркость получается кобенацией R, G, B с дробными коэффициентами, то плавающий питух может в жопу клюнуть. При переходе из одного цветового пространства в другое и обратно могут вылезать ошибки округления. Кроме того, цвета, оказавшиеся на границе пространства, будут искажаться, потому что разрядность компонент ограничена.
                                        Ответить
                                • «BMP» бывает без зожатия, а бывает с «RLE». «GIF» же всегда с зожатием «LZW». Да, у «GIF» цвета индексные, причём размер палитры довольно жёстко ограничен.

                                  Есть «GIF89a» с дополнительными фишками, которых нет у «BMP». Это, например, анимация. Вообще спецификация «GIF89a» включала особенности, делающие его похожим на HTML или на SWF: наложение текста (именно в виде текста, а не в виде растра), интерактивные компоненты (видел демонстрационный вьюер, который это всё поддерживал). Но из этого всего прижилась только анимация.
                                  Ответить
                                  • о, да
                                    анимированный гиф, мой милый 1997-й год
                                    https://giphy.com/stickers/geocities-NTINffFKwlXvW
                                    Ответить
                                • JPEG зожимает с потерями. Он разбивает изображение на квадраты 8x8, каждый квадрат раскладывает в двухмерный ряд Фурье и отбрасывает высокие частоты. Совсем как «MP3». Коэффициенты перед оставшимися частотами зожимаются по фомфану.

                                  При сплошной заливке достаточно сохранить одну частоту. Квадрат 8×8 превратится в один пиксель. Итого нужно сохранить 113×113 пикселей = 12769 пикселей, зожатых по фомфану.

                                  Как я уже заметил, «BMP» бывает с «RLE» (правда, «RLE» не везде поддерживается). Если зожать с «RLE», то каждая строка будет выглядеть как один пиксель («BMP» зожимает только в горизонтальном направлении). Итого будет сохранено 900 пикселей.
                                  Ответить
                                  • Ну кстати чпег можно закапывать. Видеокодеки должны справиться с картинкой гораздо лучше, у них даже в пределах одной картинки работают предсказания и интерполяция. А чпег тупо квадратиками считает.
                                    Ответить
                                    • Кстати, авторы «WebP» так и сделали: это тупо кадр из «WebM» (точнее, из кодека «VP8»).
                                      Ответить
                                  • > квадрат 8х8 превратится в 1 пиксель
                                    А видеокодек на сплошной заливке управится в 1 бит символ* "totally predicted" на квадратик.

                                    * символ может занять меньше бита, намного меньше бита если он предсказуем
                                    Ответить
                                    • Лол, превратили осуждение обработки одномерного сигнал в осуждение значительно более сложной обработки двумерного.
                                      Хорошо, что вас не пускают на стековерфлоу.
                                      Ответить
                                    • > символ может занять меньше бита
                                      всё-таки удалось реализовать алгоритм бесконечного зожатия?
                                      Ответить
                                      • Нет, просто фокусы с энтропией.
                                        См., напр., «орефметическое кодирование».
                                        Ответить
                                      • Да нет, никакой магии, остальные символы становятся намного длиннее бита.
                                        Ответить
                                      • конечно

                                        кто помнит момеды и боды?
                                        Ответить
                                        • Полада Бюльбюль оглы Мамедова знаю:
                                          https://youtu.be/uaRlBavLCN4

                                          Момеда не знаю.
                                          Ответить
                                          • Момед мудолировал сигнал трясясь вокруг несущей в линии телефона, количество трясок в сикунду называлось БОД (вч есть Жана, Мориса и Эмиля Бодо)

                                            В одном боде мог быть сокрыт один бит (так было очень давно), потом хитровыебанные ученые придумали как впихнуть туда больше битов.
                                            Ответить
                            • Именно так.

                              opus более экономно расходует битрейт за счёт гораздо более продвинутых алгоритмов и консервации аудиоэнергии.

                              mp3 тупо режет высокие, сколько ты ему не дай. А в 320kbps у него треть битрейта вообще уходит в паддинг пакетов.

                              Потому 320kbps mp3 обычно зожимаются до 70-80% простым архиватором. Можете сами убедиться.
                              Ответить
                        • Малость пидорашка подгорает.
                          Ответить
                      • Ну, допустим. Но тогда становится непонятно, зачем они так радуются как уделали заведомо говняный MP3 128kbpb. Все равно, что хвастаться экономикой лучше чем в рашке.
                        Ответить
                      • А если у меня какая-нибудь исследовательская питушня с 20разрядного АЦП и частоты несколько сотен килогерц? Зажмёт как следует без пердолинга с компиляцией альтернативных версий?
                        (Кстати, тут как раз и битрейт понадобится.
                        Ответить
                        • >>> In data compression and psychoacoustics, transparency is the result of lossy data compression accurate enough that the compressed result is perceptually indistinguishable from the uncompressed input. In other words, transparent compression has no perceptible compression artifacts.
                          Зожмёт, и ушами ты разницы не услышишь. Но ведь это далеко не всё, что требуется от сигнала с 20-разрядного АЦП и частотой в несколько сотен килогерц, да?
                          Ответить
                          • > transparency
                            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.
                            Ответить
                            • > transparent rustery
                              Это англоязычные вореции?
                              Ответить
                              • прозрачная ржавельня?

                                ps
                                transparent roostery
                                Ответить
                              • Дядя Пи же минимум два раза повторял:
                                §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!
                          Ответить
                          • > If you want a codec to handle high sampling rates losslessly
                            Но мы же хотим лосси, просто лосси!


                            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.

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

    Добавить комментарий