基于 FFmpeg 的视频编辑器开发—踩坑记
折腾了两周,视频编辑器已初具规模:
- 解封装
- 解码
- 快速跳转和精准跳转
- 格式转换
- 缩放
- 重采样
- 添加文字
- 添加 srt 字幕
- 编码
- 封装
基本满足了当初想做一个 gif 生成器的需求,也是时候回顾下过去两周踩过的坑了。
折腾了两周,视频编辑器已初具规模:
基本满足了当初想做一个 gif 生成器的需求,也是时候回顾下过去两周踩过的坑了。
尝试在 VS 2019 中导入 QtPropertyBrowser 源码到 VS 工程(vcxproj)进行编译时,遇到如下编译错误:
1 | 1>moc_qtpropertybrowser.cpp |
解决办法如下:
在 VS 项目目录内右键对应 moc 文件的头文件,选中属性—Qt Meta-Object Compiler—moc,将 C++ Dynamic Source
值从 “Output File” 改为 “Disable”,重新编译即可。
简言之,这个项的作用是将当前文件中 Qt 类生成的 moc 源文件在编译阶段动态添加到编译器的源码文件列表中。 因为 Private 类的定义在 x.cpp 文件而非 x.h 中,导致编译 moc_x.cpp 时找不到类定义。
项值 Disable 即不将 moc_x.cpp 动态添加到编译器中。这么做是没问题的,因为 QtPropertyBrowser 相关源文件的最后都已显式 include 了对应的 moc.cpp。
具体可参考:
https://forum.qt.io/topic/119401/how-to-compile-source-code-of-qtpropertybrowser-by-vs2019-correctly
https://www.qt.io/blog/2018/01/24/qt-visual-studio-new-approach-based-msbuild
通过 PyCharm 的包管理工具分别下载安装 requests 、bs4 、lxml 库。
requests 是一个简洁优雅的 HTTP 库,基于 urllib3 再封装。一个 get 请求用一行代码即可实现:
1 | res = requests.get('https://github.com/') |
ScriptableObject 是一个数据容器类,可以用它来存储与类实例无关的数据。ScriptableObject 一个主要用途是利用它存储共享资源(比如 Prefab),减少无谓的复制,降低内存使用。
比如说,场景 A 和场景 B 都需要一个登录对话框。常规做法是创建一个 Prefab,分别在 A 和 B 中各自实例化;为了节省内存,可以在 ScriptableObject 中实例此 Prefab,在运行时将此 Prefab 实例添加到 A/B 场景中。
ScriptableObject 最典型的一个应用场景,便是用它来实现预加载了。
绝大多数应用里,都会有类似的业务逻辑:从 A 页面跳转到 B 页面,执行一系列操作后返回 A 页面。
这看似寻常的操作流程,Unity 是不能天然支持的。Unity 的 SceneManager 和 Android 的 activity stacks 在”页面”管理策略上大概有以下不同:
Unity 是微软旗下的跨平台游戏/应用开发工具,C# 自然成为其首推支持的前端开发语言。C# 虽是从 Java 脱胎而出,经过近二十年的独立发展,已经成长为一门明显优于 Java 的现代化语言(这当然是我个人的主观见解)。我也发愿以此项目为起点,重新掌握 C#/.NET 的技术体系。
开发阶段用的是 UnityEditor.EditorUtility.OpenFilePanel()
函数,简单易用。但是如其名所示,UnityEditor
只在 Unity 编辑器内可见,尝试 build 出 Windows 下 standalone 包时会报编译错误。
解决办法是用 mono 库下的相应功能实现打开文件。
2020年会整体围绕StreamingCore项目运作。先期会先做一部分复习工作,比如C++相关、工程相关;其它所列知识点会边学边应用。
尽量详细地列出各项,不断回顾并更新进度。