Когда всё место на смартфоне сожрали фото и видео..

[AnalyzeR]

Если активно снимать на смартфон, место на нём заканчивается довольно быстро, каких бы размеров не был флеш. Если мы хотим продолжать смотреть фото и видео - случай с моей супругой Юлей и сотнями видео / тысячами фото с детьми, мы можем ужать снятое для уменьшения размера. Файлы в исходном качестве сбрасываем на внешний архивный диск, и бережно его храним, а на смарт помещаем с качеством похуже, но достаточном для просмотра на экране смартфона.
Я потратил некоторое время разобраться, а для видео пришлось писать скрипт, чего ранее не умел, потому делюсь.

Для конвертации фото используем imagemagick, видео - ffmpeg, стандартные для такой задачи и кроссплатформенные (т.е. работают в разных ОС) инструменты.
Если приложения не установлены, в виндусе гуглим офсайты и скачиваем, а в убунту это делается из терминала одной командой
$ sudo apt install imagemagick ffmpeg exiftool

ФОТО
Как выполнить команду в Windows, не знаю, но пишут, что должно работать так же, если есть умельцы выполнения команд, напишите про запуск в виндусе.
Команда для конвертации фото в линукс запускается из терминала в папке с файлами jpg ($ здесь - не часть команды, а приглашение командной строки):
$ find ./ -maxdepth 1 -type f -iname '*.jpg' -execdir convert {} -strip -quality 70 -resize 1400x1400 -set filename:currentfile '%t-%wx%h' 'small/%[filename:currentfile].jpg' \;
Подкаталог small нужно создать в папке с файлами до, ужатые файлы будут записаны туда. Имя нового файла во избежании недоразумений формируется другое, из IMG_20190919_154402.jpg получится IMG_20190919_154402-1400x1050.jpg
Значения качества и размера меняем по своему усмотрению. В этой команде 1400 будет длина меньшей стороны, а вторая установится с сохранением исходных пропорций.
Убедитесь, что количество сжатых файлов совпадает с исходным. - в процессе выяснилось, что на смартфоне есть недописанные фото, названия файлов которых заканчиваются на jpg.tmp. Что-то сбойнуло при фотографировании, эти файлы только удалять. И бывают файлы нулевого размера, то же самое. В моём случае из ~3500 фото их было 2 и 1.
Запуск терминала обычно настроен на Ctrl+Alt+T, вставка и копирование в нём Ctrl+Shft+V, а не Ctrl+V (и C).

ВИДЕО
Для конвертации видео придётся пользоваться скриптом.
Проблема оказалась в том, что для конвертации нельзя использовать тег ориентации Rotation, записанный в свойствах исходного видео - он достаточно часто не соответствует записанным там же ширине и высоте. Видимо, это происходит из-за положения камеры при записи. И также ориентацию нельзя определить по соотношению Ш и В. При этом плееры с разной успешностью по большей части их понимают, но некоторые видео показывают неверно, например перевёрнутыми.
Rotation может принимать всего 4 значения: 0,180 - горизонтальное, 90,270 - вертикальное, при этом 180,270 - перевёрнутые.
В частности, из 796 файлов у 15 с rotation=0 ширина оказалась меньше высоты, по результату просмотра плеером все они вертикальные - явная ошибка записи тега. У всех остальных Ш>В. По выборочной проверке, если R=90, то видео вертикальное, а если R=0 или 180 - горизонтальное.
8 файлов с R=270, у всех тоже Ш>В. Из них один оказался горизонтальным.
25 с rotation 180 горизонтальные и, вроде, действительно перевёрнутые. Понять сложно, т.к. проигрыватель сам возвращает в нужное положение, быстро мигает при запуске видео. Как определяет? Вопрос. Но это почти всегда видно.

При конвертации мы скармливаем ffmpeg параметры, в частности нужный нам новый размер видео. Вариант с автоматическим определением второй стороны scale=720:-1 или scale=-1:720 оказался неработающим при вертикальных видео с Ш>В, ffmpeg возвращал ошибку. При принудительной подстановке размера второй стороны ffmpeg неверно записывает новые значения ширины. Само конвертированное видео при этом имеет правильные размеры и плеер его правильно показывает. Возможно потому правильно, что есть два параметра ширины и высоты, видимо, что-то немного разное отображающих - Image Width и Source Image Width, и то же для Height, так вот второй записывается правильно, а первый нет. Пример
VID_20200408_194738.mp4
Rotation; Width; Height
90;1280;720;
Итоговые значения:
VID_20200408_194738_1280х720x24.mp4
0;405;720
Image Width : 405
Image Height : 720
Source Image Width : 1280
Source Image Height : 720
Возможно, этот косяк касается только текущей версии ffmpeg.
По итогу Rotation остаётся просто справочной информацией, ffmpeg во все файлы записал в Rotation 0. Но плеер нормально считывает, и даже исходно перевёрнутые видео стали правильно воспроизводиться.

Параметр качества лучше подбирать к содержимому видео. Чем активнее движется картинка в видео, тем хуже оно будет после пережатия. Стандартно рекомендуемое в интернетах значение - 24.

Для работы скрипта необходимы установленные ffmpeg и exiftool, оба приложения кроссплатформенные, должно работать в разных ОС. Как запускать скрипт в Windows, я не в курсе, прошу умеющих дополнить комментарием.

Скрипт прилагаю, комментариев в нём много, работа должна быть ясна. На всякий случай - это мой первый опыт написания скрипта для bash, использование его на свой собственный страх и риск, автор отказывается от какой-либо было ответственности за его применение. В любом случае, сохраняйте исходные файлы.

Подробности для убунту чайникам
- открыть терминал (обычно Ctrl+Alt+T)
- перейти в папку со скриптом
$ cd путь_к_файлу
- дать файлу со скриптом права на исполнение
$ chmod a+x mp4convert4.sh
- Если не установлены ffmpeg и exiftool, установить
$ sudo apt install ffmpeg exiftool
- если скрипт лежи в той же директории, что и mp4 файлы, создать в ней подкаталог small
- если нет, создать подкаталог small в папке со скриптом, а сам скрипт открыть в текстовом редакторе и вписать путь к файлам mp4
- запустить скрипт
$ ./mp4convert4.sh
- убедиться, что в отчёте о работе скрипта нет ошибок конвертации ffmpeg, а количество сжатых файлов совпадает с исходным, при ином результате смотреть отчётную таблицу в файле convert_result.cvs