Видео для тестов своего энкодера/декодера

Ай ладно, чёт я перемудрил вот это пойдёт http://demo.nimius.net/video_test/videos/test.mp4

my_home_porn.mkv

чёт я перемудрил

Да нет. Не перемудрил. Всем кто занимался обработкой изображений известно лицо Лены и морда бабуина. Эти изображения проходят тестировку в первую очередь. Для видео такой выбор «пропущен». Не есть гуд.

Код дашь позырить?

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

Хотя выглядит слишком примитивно

Код дашь позырить?

https://gitlab.freedesktop.org/wayland/weston/tree/master/wcap

известно лицо Лены

Ну, кому лицо, а кому поболее, https://imgur.com/a/6YM88sF

Код дашь позырить? Хотя выглядит слишком примитивно

Да, примитивно, но нет в текущем виде не дам. Если получится что-то вменяемое (сейчас там ад из экспериментов я же в этом ничего не понимаю просто по ходу дела придумываю как и что делать) то я портану это на Corange и скорее всего Даниэль примет PR. Что бы сё по человечески и энкодер и декодер и плеер =) Я отпишу сюда если что =)

Не вракай! Это не моё!

Ты придумал GIF?

Не, ща википедию почитал там не, не то у меня всё тупее ))))

1) Ты занимаешься ерундой, когда есть VP9

2) В том же ffmpeg есть тесты, можно посмотреть. Или в библиотеках, реализующих кодеки

Чёрный квадрат, белый квадрат, чёрный квадрат на белом фоне каждый кадр смещается на один пиксель, то же самое наоборот, белый шум, двигающиеся полоски, тестовых данных много можно придумать

1. Ты занимаешься ерундой, когда есть VP9

Дай ссылку на либу под BSD/MIT где без танцев с барабаном можно просто открыть файл сказать «рисуй в эту текстуру» и смотреть видосик. =) или сказать, «дай мне следующий кадр я его сам нарисую на чём мне надо»

В том же ffmpeg есть тесты, можно посмотреть. Или в библиотеках, реализующих кодеки

Поищу, спасибо

тестовых данных много можно придумать

Ну, да вот я и подумал что кто-то уже придумал и запилил =)

Дай ссылку на либу под BSD/MIT где без танцев с барабаном можно просто открыть файл сказать «рисуй в эту текстуру» и смотреть видосик. =) или сказать, «дай мне следующий кадр я его сам нарисую на чём мне надо»

а в чём сложность?

Pekka Paalanen authored 6 months ago

YOBA ETO TI?

а в чём сложность?

Хз, ну каюсь самому захотелось реализовать что то простое и лёгкое для коротеньких роликов =) Может и в правду потыкать, тут в гугле libvpx вылезло, пойду попробую в OpenGL текстуру проигрыватель сделать. Вроде демки есть какие то.

Это фин какой-то

Что такое дискретно-косинусное преобразование, быстра! :)

Не знаю =)

Я сказал

что то простое и лёгкое

Ну в моих словах простое читай как тупое :D

Простое будет гигабайты на кадр выдавать

Нуууу, нееее, если в 1920x1080 60 fps видео длинною 1 секунду будет по экрану 1 пиксель летать то для построения каждого следующего кадра мне нужно хранить только два rgbX первый затереть место где был пиксель, второй рисует новый, где X это положение где в опорном кадре произвести изменения то есть w|h. При этом можно ещё игнорировать диапазоны цветов, то есть если в точке был красный типа r=150 а в следующем кадре он 155, а ещё в следующем 145 то это можно тупо игнорировать и не считать за изменение тем самым это изменение не хранить. Одинаковые кадры просто ссылки на предыдущие. По сути получается я храню diff изображений и патчу картинку этими diff ами для построения следующей.

Понятное дело что даже 5 минутный ролик это проблема, но мои потребности для игры это максимум 1 минута ролики, вот я и подумал что стоит попробовать похимичить ))

И это довольно интересно я бы сказал, особенно когда всё на ходу придумывать надо =)

все тру-кодеки работают с цветовым пространством YUV, а не RGB

Нафига мне эти сложности =) Мне сначала надо (выбрать готовую либу или ) запилить хоть что-то работающее, пусть тупорылое как скатинка, но полностью работающее. А уже потом (удалить весь этот треш нахрен) что-то улучшать если храниение в YUV можно считать таковым. :D Ща, libvpx попробую завести,хз, может понравиться и буду использовать его или чёнить ещё более лёгкое найду, я боюсь зависомостей лишних.

все тру-кодеки

У меня не тру, а наколенная поделка, полноценный кодек пилить мне жизни не хватит, да и серых клеточек тоже.

https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/encode_video.c

Простое будет гигабайты на кадр выдавать

а сложное сожрёт процессор

Не обязательно использовать 4k h265.

Мне сначала надо (выбрать готовую либу или ) запилить хоть что-то работающее

Не mjpeg ли?

Всегда считал что для видео это - https://download.blender.org/peach/bigbuckbunny_movies/

Где это вообще используется?

Короче хвалюсь https://youtu.be/vEN_W6g_CD8 297 кадров в разрешении 1920x1080 кодек на основе разности кадров вообще без сжатий выдаёт 204 метра )))))))))) Ну, что-то наколдовать с размерами раза в четыре ужать подшаманить и жить можно =) Два видеоролика в игру вставить можно, а больше чаще и не надо. ))))))))))))))

Хотя выглядит слишком примитивно

Я бы сказал, что выглядит как обычный MPEG. Ну если не считать что в mpeg цвет идет в виде YCrCb и что разрешение для Y, обычно, больше чем для CrCb

все тру-кодеки работают с цветовым пространством YUV, а не RGB

К стати вопрос - а нахрена?

Я понимаю почему это, например, есть в допотомном мпеге - такую картинку можно нормально без преобразований показывать на Ч/Б телеке тупо игноря компоненту цветности, но в современных кодеках какой смысл так делать? Тупо чтобы мочь делать разрешение цветности меньше, чем у яркости? (т.е. немножко уменьшаем размер, в ущерб точной цветопередаче)

т.е. немножко уменьшаем размер

в два раза меньше

в допотомном мпеге

ась?

ась?

ISO/IEC 11172-1:1993 Publication date : 1993-08

Стандарт, так на минуточку, ровестник дума.

в ущерб точной

Человек неспособен заметить разницу.

Человек неспособен заметить разницу.

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

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

ну да