видео со змеей
Dec. 14th, 2017 01:04 pm(noob rant) А вот Питон. Никогда раньше на нем не писал, но тут приходят клиенты и говорят: хотим ваше чудо чудесное в своем приложении на питоне использовать, да на винде, не где-нибудь. Я им говорю, ща, демку вам набросаем. Про себя думаю, это ж Питон, там батарейки, аккумуляторы, богатая экосистема, напишешь import antigravity и полетел. А там... Вот есть технология, которая примерно ровесница самому питону, и до сих пор вполне себе работает во всех виндах - Video for Windows. Какие есть в питоне средства с ней работать? Я так понял, вообще никаких. Ну ладно, может это слишком виндово для гзмеев. Для сжатия видео все равно будет моя DLL-ка вызываться. Но потом мне надо сжатое видео в файл записать. Что там у вас в библиотеках для записи AVI, сравнительно простого и старинного формата? Да как-то тоже практически ничего, про видео видно лишь пару оберток над ffmpeg. Вызывать стороннее приложение - вот все, на что питонисты способны тут. В итоге плюнул, сделал свою простенькую писалку AVI в 128 строк, для небольших файлов.
В итоге все заработало как хотелось, даже в процессе получилось в моей DLL-ке баг найти: в одном месте 64-битный указатель обрезался до 32 бит при передаче в мою виртуальную машинку, ИЧСХ при загрузке DLL-ки из моих тестовых прог и при загрузке кодека в приложения вроде VirtualDub все раньше работало, т.е. указатель тот всегда оказывался нулем в верхних битах. А вот при вызове из питона не оказался, так получилось это обнаружить.
Для работы с DLL использовал модуль ctypes. Они там берутся контролировать типы передаваемых данных, и, как я понял, для передачи бинарных данных вроде BYTE* предполагается использовать массивы вроде c_ubyte * size, причем тип указывается при объявлении прототипа ф-ии, и если у меня при разных вызовах передается разное количество данных, то получается фигня: массив другой длины это уже другой тип, его ctypes не дает передать. Это что же, перед каждым вызовом надо заново определять тип вызываемой функции? Или, видимо, надо объявлять там POINTER(c_ubyte), а при вызовах делать cast()...
И в то же время этот их строгий контроль типов спокойно разрешил целое число вместо указателя на void передать (ненамеренно). С непривычки тяжело, конечно, пока писал скрипт на 200 строк успел несколько раз словить в рантайме "а вот тут число аргументов не то", "а вот эту переменную я не знаю" и другие прелести недотипизированных интерпретируемых языков.
В итоге все заработало как хотелось, даже в процессе получилось в моей DLL-ке баг найти: в одном месте 64-битный указатель обрезался до 32 бит при передаче в мою виртуальную машинку, ИЧСХ при загрузке DLL-ки из моих тестовых прог и при загрузке кодека в приложения вроде VirtualDub все раньше работало, т.е. указатель тот всегда оказывался нулем в верхних битах. А вот при вызове из питона не оказался, так получилось это обнаружить.
Для работы с DLL использовал модуль ctypes. Они там берутся контролировать типы передаваемых данных, и, как я понял, для передачи бинарных данных вроде BYTE* предполагается использовать массивы вроде c_ubyte * size, причем тип указывается при объявлении прототипа ф-ии, и если у меня при разных вызовах передается разное количество данных, то получается фигня: массив другой длины это уже другой тип, его ctypes не дает передать. Это что же, перед каждым вызовом надо заново определять тип вызываемой функции? Или, видимо, надо объявлять там POINTER(c_ubyte), а при вызовах делать cast()...
И в то же время этот их строгий контроль типов спокойно разрешил целое число вместо указателя на void передать (ненамеренно). С непривычки тяжело, конечно, пока писал скрипт на 200 строк успел несколько раз словить в рантайме "а вот тут число аргументов не то", "а вот эту переменную я не знаю" и другие прелести недотипизированных интерпретируемых языков.