>Да не влияет никак pts на качество.
Как бы опыт показывает другое. Либо он влияет, либо там цепляется что-то ещё (хотя по логике да, не должен никак влиять)
>Под каждой опцией есть описание.
Это описание для тех, кто понимает, что оно значит. Я лишь очень примерно представляю, о чём речь.
Последний параметр вообще не понятен. Разница между соседними кадрами или что?
битрейт как минимум отображается в плеере. Хотя других эффектов я не заметил.
Grobozavr
> Либо он влияет, либо там цепляется что-то ещё (хотя по логике да, не должен никак влиять)
Есть расстояние между ключевыми кадрами, Group Of Pictures. Чем оно больше, тем ключевых кадров меньше с соответствующим влиянием на размер фала. По умолчанию GOP в ffmpeg что-то типа 250.
Когда ты к PTS, прибавляешь не по 1, а по 25, то кодек будет думать, что у тебя каждый 10 кадр - ключевой. Хотя, возможно, я все это придумал.
> Разница между соседними кадрами или что?
На сколько можно изменять качество между соседними кадрами.
Оно разумеется в попугаях, а не в децибелах, поэтому ставь 1, не ошибешься.
> битрейт как минимум отображается в плеере
Битрейт хорошо задавать при двухпроходном сжатии или стриминге.
Как я понимаю, это совсем не твои случаи.
Ага, эти работают более предсказуемо.
>Когда ты к PTS, прибавляешь не по 1, а по 25, то кодек будет думать, что у тебя каждый 10 кадр - ключевой.
Не, явно не оно. При 1 даже ключевые кадры пожаты так, что от них ничего не остаётся. Сейчас с новыми параметрами попробовал. При максимальном значении 63/1024 из 58Мб осталось 21КИЛОбайт. Во примерно такой же эффект был и при единице там.
При больших значениях визуально потери качества не заметил.
>Как я понимаю, это совсем не твои случаи.
Ну с 2х-проходным может потом поиграюсь, у меня не риалтайм, но в целом да.
Осталось разобраться, как заставить другие плееры понимать это видео. Пока понимает только один.
Grobozavr
> Задача - программа генерит видео (иногда из другого видео, иногда сама по себе)
> и надо его сохранить в заданном качестве. Иногда для обработки в высоком,
> иногда как конечное - в компактном.
если совсем будет беда, то можешь OpenCV или VLC заюзать. OpenCV имеет writer, который получает кадры из внешнего источника. VLC тоже всякие колбеки поддерживает и забор данных из других источников
Grobozavr
> При 1 даже ключевые кадры пожаты так, что от них ничего не остаётся
Сжатие никаким образом с этим процессом не связано. Им управляют другие параметры. Я выше объяснял, почему может быть связь между pts и размером файла.
>если совсем будет беда, то можешь OpenCV или VLC заюзать. OpenCV имеет writer, который получает кадры из внешнего источника. VLC тоже всякие колбеки поддерживает и забор данных из других источников
VLC, кстати,, как раз один из тех, кто отказывается открывать. А Opencv есть, он для обработки используется. Но вроде он без поддержки видео собран (долго я с ним мучался) да и не хочется его постоянно с собой таскать. Слишком толстый
>Сжатие никаким образом с этим процессом не связано. Им управляют другие параметры. Я выше объяснял, почему может быть связь между pts и размером файла.
Расстояние между кк не должно влиять на качество самого кк. А он их в ноль жмёт. Или не жмёт. Только из-за этого параметра. Там явно хитрее связь.
А что за ошибка "Invalid NAL unit 8"? Может это она плеерам не нравится?
Какой кодек используете? Как сохраняете в файл? Возможно вы просто поток данных сохраняете?
>Какой кодек используете? Как сохраняете в файл? Возможно вы просто поток данных сохраняете?
h264
Вкратце - так:
codec = avcodec_find_encoder_by_name(codec_name); c = avcodec_alloc_context3(codec); pkt = av_packet_alloc(); avcodec_open2(enc->c, codec, &opt); f = fopen(filename, "wb"); avcodec_send_frame(enc_ctx, frame); avcodec_receive_packet(enc_ctx, pkt); fwrite(pkt->data, 1, pkt->size, outfile);
Может и поток только, я пока не разобрался. Выдрал из примера, который шел в комплекте с ffmpeg.
Да, так и есть, вы сохраняете только поток данных. Плеер это не воспроизведет. С ffmpeg работал очень давно, так что уже плохо помню. Посмотрите этот пример. В main функции настраивается формат файла и добавляются потоки для сохранения. У вас должно быть что-то подобное.
Ага, примерно понял. Благодарю.
Grobozavr
> А он их в ноль жмёт. Или не жмёт. Только из-за этого параметра
Блин. Битрейт это поток байт за единицу времени. Так вот меняя инкремент pts ты реально изменяешь битрейт с точки зрения кодека.
ffmpeg хочет сохранить битрейт, т.к. ты его задал, поэтому ухудшает качество в зависимости от объема информации, поступающей ему на вход.
Ты посмотри, сколько у тебя фреймов кодек сжирает перед тем, как выплюнуть первый пакет. Дофига.
> Вкратце - так:
Вкратце, советую залезть в папку doc/examples и начать ковырять файл muxing.c, особое внимание уделяя работе с AVFormatContext и AVStream.
Ты складываешь в файл голые данные с выхода кодека. А плееры любят, чтобы они были завернуты в контейнер (avi, mp4, mov и т.д.)
>меняя инкремент pts ты реально изменяешь битрейт с точки зрения кодека.
Но, похоже, не с точки зрения плеера. Хотя теперь логику понял.
>залезть в папку doc/examples
Так оттуда и пример был. Но, видимо, не тот.
Выше уже показали правильный.
Тема в архиве.