Коротко Нужна программа на Python, которая запускается у меня на ПК (Windows) и делает faceless-видео формата «закадровый голос + сменяющийся видеоряд из фото и клипов» — как исторические документалки на YouTube (пример прикреплю отдельно). Я ввожу тему → программа пишет сценарий, озвучивает, подбирает под каждый кусок текста видео/фото из бесплатных архивов, склеивает → выдаёт готовый MP4. Только для меня. Без сайта, без пользователей, без продажи. Один пользователь — я. Как работает (по шагам) 1. Ввод. Открывается простое окно. Я ввожу тему ролика и выбираю голос озвучки из списка (**список голосов подтягивается автоматически из ElevenLabs по API** — доступные на моём аккаунте). Жму «Создать». (Второй режим: вставить готовый сценарий вместо генерации.) 2. Сценарий. Программа через LLM API (OpenAI/Anthropic, ключ в настройках) пишет сценарий по теме, заданной длины. 3. Разбивка на сцены. LLM делит сценарий на сцены и для каждой возвращает: текст сцены; тип визуала: видео или фото; поисковый запрос (развёрнутая фраза, что должно быть в кадре); пометку «highlight» + оценку важности 1-10 (для интро, см. ниже). 4. Озвучка. Текст отправляется в ElevenLabs API выбранным голосом → аудио. Под длину аудио каждой сцены режется видеоряд. 5. Подбор видео/фото — из бесплатных источников по API (см. список ниже). Под каждый источник запрос формируется по-своему (для точности). Если в одном не нашлось — пробует следующий. 6. Проверка (максимум 3 шага на сцену). Шаг 1: программа берёт первый найденный вариант (видео/фото) по запросу. Шаг 2: отправляет кадр в LLM — «подходит под сцену?». Подходит → стоп. Шаг 3 (если не подходит): программа переключается на поиск фото (по точному запросу фото найти проще, чем видео, — так гарантированно попадаем по смыслу) и берёт его с усиленным движением (зум + панорама). Больше 3 шагов на одну сцену не делать — это экономит бюджет LLM и гарантирует, что кадр в тему. 7. Сборка через ffmpeg/moviepy: клипы и фото под тайминг озвучки, фото оживляются зумом (эффект Кена Бёрнса), голос поверх, простые переходы. Выход: MP4 1920×1080. Правила видеоряда (важно — за это отвечает программа) Первые 60 секунд — интро-тизер: нарезка самых эффектных клипов из всего ролика (берутся сцены с высшей оценкой важности, где есть видео) под отдельный текст-вступление от LLM («в этом видео вы узнаете…»), кадры без пояснений, как интрига. Потом переход и основная часть. Чередование: видео-вставка минимум каждые ~6 секунд, нельзя много фото подряд. Доля видео: не меньше ~40% времени — живые клипы, остальное — фото с зумом. Длина кадра: 4-6 секунд (и фото, и видео). Не мельтешить, не держать статику долго. Для чисто исторических тем, где видео нет — фото с усиленным движением (зум + панорама). Источники (все бесплатные, с API) Современное видео+фото: Pexels, Pixabay. Историческое / архивное (public domain): Wikimedia Commons, Archive.org,Library of Congress, Europeana, NASA, Smithsonian Open Access,Flickr Commons, openverse. Каждый источник — отдельный модуль, легко добавить новый. Использовать только public domain / свободные лицензии с правом коммерческого использования. Никакого парсинга чужих YouTube/сайтов, кусков фильмов, картинок «из гугла».Уникальность подбора Чтобы видео не совпадали с чужими: брать случайный клип из топ-выдачи (не первый), вести базу уже использованных (не повторять), опционально — лёгкая обработка клипа (кроп/зеркало/ скорость). Опции (вкл/выкл в настройках) Субтитры (вшить или отдельным .srt). Фоновая музыка. Обработка клипов для уникальности. Разрешение/формат, длина видео, доля видео, глубина поиска.Технические требования Python. Модульная структура (источники и LLM — через сменные модули, чтобы легко заменить или добавить). Все API-ключи — в файле настроек, не в коде. Простое окно (GUI на выбор исполнителя — Tkinter/PyQt), запуск двойным кликом. README с инструкцией, понятные логи, комментарии в коде.Что даю я API-ключи (ElevenLabs, LLM, где нужна регистрация — оформлю). Платное оплачиваю сам. Примеры видео-референсов (прикреплю) и примеры тем для тестов.Приёмка (готово, если) Запускаю → окно → ввожу тему, выбираю голос → «Создать» → получаю готовый MP4. Видеоряд по смыслу текста, чередование видео/фото, интро-тизер 60 сек, озвучка поверх. Работает минимум с 6 бесплатными источниками, с fallback между ними. Проверка кадров через LLM: макс. 3 шага на сцену (нашли → LLM проверил → если нет, фото с движением как верняк). Уникальность: рандомизация + база использованного. Только легальные источники. Есть README, запускается с нуля.Передача результата Весь исходный код — в открытом виде (все файлы), без обфускации + собранная рабочая версия. Я могу сам запустить из исходников по инструкции (README: установка, ключи, запуск). Код должен быть чистым, прокомментированным и понятным, чтобы **любой другой программист мог продолжить работу** над ним, если понадобится (не привязка к автору). Все права на код после оплаты — мои.Управление местом на диске (важно) Программа не должна забивать диск. Реализовать: После сборки видео все промежуточные файлы (скачанные клипы, временные куски, аудио-нарезки) автоматически удаляются — на диске остаётся только готовый MP4. Лимит на кэш (параметр в настройках, напр. 5 ГБ): при превышении старые скачанные файлы удаляются автоматически (сначала самые старые). Папку для готовых видео и для временных файлов я задаю в настройках. Показывать, сколько места занято, и кнопка «очистить кэш» вручную.Прошу указать в отклике Примеры похожих работ (ffmpeg/moviepy, работа со стоковыми/архивными API, ElevenLabs/LLM). Предложение по GUI. Использует ли решение базу данных (какую и зачем) — или хватает локальных файлов. Срок и стоимость.
Aktualnie brak ofert
Aktualnie brak ofert
-
Oleksandr Bobyliev 3 maja 2022Usunięte przez moderatora
Aktualne zlecenia dla freelancerów w kategorii Python
O projekcie: Uruchamiamy usługę B2B do analityki i zarządzania kampaniami reklamowymi dla specjalistów ds. reklamy i mediów. Produkt będzie działał z oficjalnym Meta API. Główna techniczna trudność i fokus projektu — wirtuozowska praca z limitami Facebooka, routowanie ruchu między pulą naszych aplikacji oraz ścisły system ochrony infrastruktury przed blokadami szarych kont reklamowych. Mamy już szczegółowe zadanie techniczne, opisaną architekturę baz danych, logikę balansu oraz wymagania dotyczące interfejsów. Szukamy wykonawcy, który zrealizuje to w trybie „pod klucz” (backend + frontend pulpitów). Co należy zrobić (Kluczowe zadania): Integracja z Meta API: Skonfigurować autoryzację użytkowników oraz regularne asynchroniczne parsowanie statystyk kont reklamowych. Zapytania powinny być wysyłane wyłącznie w paczkach, aby oszczędzać limity. System automatycznego odłączania kont: Napisać moduł, który nieprzerwanie monitoruje statusy kont reklamowych. Jeśli konto zostanie zablokowane, system powinien automatycznie cofnąć token dostępu w ciągu 60 sekund, aby chronić naszą aplikację przed sankcjami Meta. Infrastruktura proxy: Zrealizować tunelowanie wszystkich zapytań do API przez pulę SOCKS5. Obowiązkowe jest ścisłe powiązanie konkretnego tokena użytkownika z statycznym adresem IP. Inteligentne routowanie: Stworzyć algorytm, który będzie rozdzielał przypisywane konta reklamowe między kilka naszych aplikacji Facebook w określonych proporcjach, aby zmniejszyć ryzyko. Rozwój interfejsów: Stworzyć pulpit klienta z tabelą podsumowującą statystyki oraz zaawansowany panel administracyjny do ręcznego zarządzania limitami użytkowników, przypisaniami do aplikacji i pulą proxy. Oczekiwany stos technologii: Backend: Python, FastAPI. Zadania asynchroniczne: Celery, Redis. Bazy danych: PostgreSQL (lub ClickHouse dla statystyk, według uznania). Frontend: Vue.js lub React (można używać gotowych bibliotek UI i szablonów pulpitów, nacisk na funkcjonalność, a nie skomplikowany design). Wymagania dla wykonawcy: Pewne doświadczenie w pracy z Meta Graph API i Marketing API. Musisz rozumieć, jak działają płynne limity, jak czytać nagłówki obciążenia i jak pracować z tokenami. Znajomość specyfiki arbitrażu ruchu. Słowa „billing”, „ban konta reklamowego”, „menedżer biznesowy” i „farm” nie powinny budzić wątpliwości. Doświadczenie w budowaniu asynchronicznych parserów i pracy z serwerami proxy na poziomie zapytań sieciowych. Gotowość do pracy według jasnego zadania technicznego i dostarczania projektu etapami. Warunki: Format współpracy: Praca projektowa (z możliwością przejścia na długoterminowe wsparcie i rozwój nowych modułów). Budżet: Do uzgodnienia indywidualnie na podstawie twojej oceny zadania technicznego. Płatność: Etapowa, związana z punktami kontrolnymi. Jak odpowiedzieć: W liście motywacyjnym koniecznie podaj swoje doświadczenie w pracy z Meta API, dołącz linki do podobnych projektów (lub opisz ich funkcjonalność, jeśli są objęte NDA) i napisz orientacyjną widełkę cenową oraz terminy na rozwój podobnego systemu od podstaw. Odpowiedzi bez opisu odpowiedniego doświadczenia w pracy z Facebook API nie będą rozpatrywane.
Wymagana jest разработка lokalnego skryptu Python do automatycznego wypełniania Google Arkuszy danymi z wewnętrznego serwisu firmy. Główna logika: 1. Połączyć się z Google Arkuszem. 2. Znaleźć wiersze, w których wypełniony jest ID, ale brakuje dwóch docelowych wartości. 3. Sformułować link według szablonu: https://internal-service.example/item/{ID} 4. Uzyskać dwie wartości (przez API, jeśli istnieje, w przeciwnym razie przez Playwright). 5. Zapisz wartości z powrotem do Google Arkusza. 6. Oznaczyć wiersz jako przetworzony. 7. Kontynuować przetwarzanie kolejnych wierszy. Wymagania: • Python • Google Sheets API • Priorytetowe użycie oficjalnego API • W przypadku braku API — Playwright • Bez OCR, rozpoznawania ekranu i współrzędnych myszy • Poufne dane nie powinny trafiać do logów • Konfiguracja przez .env • Tryb testowy (bez zapisu do arkusza) • Nie przetwarzać już wypełnionych wierszy • Zbiorowe zapisywanie zmian w Google Sheets • Poprawne przetwarzanie błędów i ponownych prób Wymagane do dostarczenia: - kod źródłowy; - requirements.txt; - przykład .env.example; - instrukcja instalacji; - instrukcja uruchamiania; - krótki opis architektury. Przed rozpoczęciem realizacji proszę: 1. Zaproponować architekturę. 2. Wymienić niezbędne dostępności. 3. Zadać pytania wyjaśniające. 4. Podać koszt, terminy i orientacyjną liczbę godzin.
W ramach podnoszenia poziomu cyberbezpieczeństwa naszej infrastruktury musimy zrezygnować z praktyki przechowywania „wiecznych” i statycznych kluczy API, haseł oraz tokenów integracji w plikach konfiguracyjnych (.env, appsettings.json, config.yaml) naszych mikroserwisów. Cel biznesowy: Stworzyć jednolity, zabezpieczony punkt przechowywania danych poufnych (sekretów) z mechanizmem ich automatycznego aktualizowania (rotacji) w systemach zewnętrznych według harmonogramu. Inne nasze usługi będą żądać aktualnych tokenów „na żywo” przez API, co zminimalizuje szkody w przypadku kompromitacji któregokolwiek z komponentów systemu.Model bezpieczeństwa i szyfrowanie (Crypto Core) W bazie danych żaden sekret nie powinien być przechowywany w postaci jawnej. Podczas uruchamiania aplikacji do zmiennych środowiskowych przekazywany jest Klucz główny (Master Key). Jeśli klucz jest nieobecny lub ma nieprawidłową długość, usługa powinna zakończyć działanie na etapie inicjalizacji z zrozumiałym błędem w logach. Każdy sekret jest szyfrowany przed zapisaniem w bazie danych z użyciem tego Klucza głównego. Przy żądaniu — jest deszyfrowany w pamięci i zwracany w treści odpowiedzi.Audyt-logowanie (Audit Trail) Każda akcja z sekretami (tworzenie, odczyt przez usługę, udana lub nieudana rotacja) powinna być zapisywana w oddzielnym pliku logów audit.log (lub w oddzielnej tabeli w bazie danych). Ścisły zakaz: W audyt-logu kategorycznie zabrania się zapisywania samych wartości sekretów (ani w postaci jawnej, ani w postaci zaszyfrowanej).
Potrzebny specjalista do pisania parserów, który będzie w stanie obejść CLOUDFRAME. Parsowanie produktów odbywa się z witryn z autoryzacją. Jest 10+ donorów o różnym stopniu trudności, z różnym poziomem ochrony. Parsowanie produktów odbywa się z witryn z autoryzacją. Parsuje dane do gotowej bazy danych Mysql + zdjęcia na serwer. Należy napisać parser zgodnie z zadaniami opisanymi w specyfikacji technicznej i dostosować dane do istniejącej bazy danych, aby zapewnić pełną funkcjonalność na stronie. Specyfikacja techniczna oraz przykład donora na żądanie. Nie rozważamy parserów desktopowych ani C#.