ПрограммированиеФорумОбщее

сжатие видео через либу ffmpeg [решено] (2 стр)

Страницы: 1 2 3 Следующая »
#15
15:22, 26 янв 2018

>Да не влияет никак pts на качество.
Как бы опыт показывает другое. Либо он влияет, либо там цепляется что-то ещё (хотя по логике да, не должен никак влиять)

>Под каждой опцией есть описание.
Это описание для тех, кто понимает, что оно значит. Я лишь  очень примерно представляю, о чём речь.
Последний параметр вообще не понятен. Разница между соседними кадрами или что?

битрейт как минимум отображается в плеере. Хотя других эффектов я не заметил.

#16
15:57, 26 янв 2018

Grobozavr

> Либо он влияет, либо там цепляется что-то ещё (хотя по логике да, не должен никак влиять)
Есть расстояние между ключевыми кадрами, Group Of Pictures. Чем оно больше, тем ключевых кадров меньше с соответствующим влиянием на размер фала. По умолчанию GOP в ffmpeg что-то типа 250.
Когда ты к PTS, прибавляешь не по 1, а по 25, то кодек будет думать, что у тебя каждый 10 кадр - ключевой. Хотя, возможно, я все это придумал.

> Разница между соседними кадрами или что?
На сколько можно изменять качество между соседними кадрами.
Оно разумеется в попугаях, а не в децибелах, поэтому ставь 1, не ошибешься.

> битрейт как минимум отображается в плеере
Битрейт хорошо задавать при двухпроходном сжатии или стриминге.
Как я понимаю, это совсем не твои случаи.

#17
15:59, 26 янв 2018

Ага, эти работают более предсказуемо.

#18
16:03, 26 янв 2018

>Когда ты к PTS, прибавляешь не по 1, а по 25, то кодек будет думать, что у тебя каждый 10 кадр - ключевой.
Не, явно не оно. При 1 даже ключевые кадры пожаты так, что от них ничего не остаётся. Сейчас с новыми параметрами попробовал. При максимальном значении 63/1024 из 58Мб осталось 21КИЛОбайт. Во примерно такой же эффект был и при единице там.
При больших значениях визуально потери качества не заметил.

>Как я понимаю, это совсем не твои случаи.
Ну с 2х-проходным может потом поиграюсь, у меня не риалтайм, но в целом да.

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

#19
16:07, 26 янв 2018

Grobozavr
> Задача - программа генерит видео (иногда из другого видео, иногда сама по себе)
> и надо его сохранить в заданном качестве. Иногда для обработки в высоком,
> иногда как конечное - в компактном.
если совсем будет беда, то можешь OpenCV или VLC заюзать.  OpenCV имеет writer, который  получает кадры из внешнего источника. VLC тоже всякие колбеки поддерживает и забор данных из других источников

#20
16:31, 26 янв 2018

Grobozavr

> При 1 даже ключевые кадры пожаты так, что от них ничего не остаётся
Сжатие никаким образом с этим процессом не связано. Им управляют другие параметры. Я выше объяснял, почему может быть связь между pts и размером файла.

#21
18:51, 26 янв 2018

>если совсем будет беда, то можешь OpenCV или VLC заюзать. OpenCV имеет writer, который получает кадры из внешнего источника. VLC тоже всякие колбеки поддерживает и забор данных из других источников
VLC, кстати,, как раз один из тех, кто отказывается открывать. А Opencv есть, он для обработки используется. Но вроде он без поддержки видео собран (долго я с ним мучался) да и не хочется его постоянно с собой таскать. Слишком толстый

#22
18:54, 26 янв 2018

>Сжатие никаким образом с этим процессом не связано. Им управляют другие параметры. Я выше объяснял, почему может быть связь между pts и размером файла.

Расстояние между кк не должно влиять на качество самого кк. А он их в ноль жмёт. Или не жмёт. Только из-за этого параметра. Там явно хитрее связь.

#23
18:55, 26 янв 2018

А что за ошибка "Invalid NAL unit 8"? Может это она плеерам не нравится?

#24
19:11, 26 янв 2018

Какой кодек используете? Как сохраняете в файл? Возможно вы просто поток данных сохраняете?

#25
20:13, 26 янв 2018

>Какой кодек используете? Как сохраняете в файл? Возможно вы просто поток данных сохраняете?
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.

#26
21:41, 26 янв 2018

Да, так и есть, вы сохраняете только поток данных. Плеер это не воспроизведет. С ffmpeg работал очень давно, так что уже плохо помню. Посмотрите этот пример. В main функции настраивается формат файла и добавляются потоки для сохранения. У вас должно быть что-то подобное.

#27
21:55, 26 янв 2018

Ага, примерно понял. Благодарю.

#28
0:34, 27 янв 2018

Grobozavr

> А он их в ноль жмёт. Или не жмёт. Только из-за этого параметра
Блин. Битрейт это поток байт за единицу времени. Так вот меняя инкремент pts ты реально изменяешь битрейт с точки зрения кодека.
ffmpeg хочет сохранить битрейт, т.к. ты его задал, поэтому ухудшает качество в зависимости от объема информации, поступающей ему на вход.
Ты посмотри, сколько у тебя фреймов кодек сжирает перед тем, как выплюнуть первый пакет. Дофига.

> Вкратце - так:
Вкратце, советую залезть в папку doc/examples и начать ковырять файл muxing.c, особое внимание уделяя работе с AVFormatContext и AVStream.
Ты складываешь в файл голые данные с выхода кодека. А плееры любят, чтобы они были завернуты в контейнер (avi, mp4, mov и т.д.)

#29
9:19, 27 янв 2018

>меняя инкремент pts ты реально изменяешь битрейт с точки зрения кодека.
Но, похоже, не с точки зрения плеера. Хотя теперь логику понял.

>залезть в папку doc/examples
Так оттуда и пример был. Но, видимо, не тот.
Выше уже показали правильный.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.