媒体处理 MTS-基础问题

案例：

出现更换 MTS key 后转码失败

排查：

• KEY 有两种类型，一个是 BASE64 另外一个是 KMS，如果选择 KMS 需要购买 KMS 的管理服务。
  如果是 BASE64 的方式自己设定一个 128bit 的 KEY 然后 BASE64 传给 server 端即可。
• 如果出现更换 KEY 转码失败的话，需要确认使用的是哪种类型的 KEY，如果使用的 BASE64 要确认是否是 128bit。

案例：

查询 OSS 的视频媒体信息

排查：

可以通过以下接口传和 MTS 关联的 bucket 存在 OSS 的视频媒体信息

参考

案例：

媒体处理提供了转码转码模式的转码

排查：

• CBR 模式下，如果设置了固定码率需要结合 maxrate minrate vbv 三个参数才能用，CBR 要求保持的码率是恒定的，不能有波动，比如运动比较大的画面。
• ONEPASS 模式下，用户可以设置客户端设置的固定码率，允许码率有波动。
• TWO PASS 模式下，在第一次其实是检测收集运动啊亮度等相关数据，这样在第二次编码的时候就会针对不同的场景来进行动态的压缩编码。二次编码比一次编码质量要好一些的。但是编码时间也会增加不少。使用二次编码可以把变化不大的画面转换时码率低一些（如静态画面），而变化大的码率高一些（如打斗动作部分），这样码率是变化的，可以使整部影片的清晰度比较均匀，只有在转换高清影片时二次编码才能发挥最大做用。

结论：

更改 ONEPASS 模式后问题解决。

案例：

工作流绑定的 bucket 可以是同一个吗

目前工作流的方式还不支持提交的输入 bucket 输出 bucket 是同一个。

案例：

MTS PHP SDK 提示 region 变量异常

排查：

出现上述的告警可以忽略掉，原因是提示 coreSDK 和 MTS SDK 的变量命名有冲突，可以直接替换掉 PHP 异常的类，或者直接将 coreSDK 替换成 github 链接中的版本，pre-release 分支。

https://github.com/aliyun/aliyun-openapi-php-sdk/tree/pre-release/aliyun-php-sdk-core

案例：

工作流中的 bucket 只能看到一个

排查：

• 工作流中看到的 bucket 必须要在 “媒体 bucket ” 中先关联好，然后才能在工作流中看到关联的 bucket ，如果只关联了一个 bucket ，那么就只能看到一个 bucket。

案例：

工作流转码弯沉过后没有回调通知

排查：

• 先看下设置的工作流是否正确，如果设置多个工作流的情况下建议核对好使用的哪个通知。
• 调下工作流的接口看看是否已经完成流转码。
• 看下源站是否有网络状态异常， access、error log 中是否有错误日志。

案例：

用户源视频经过转码后音画不同步

排查：

出现问题，如果源视频是 m3u8 格式的可以先将 ts 索引拼出来，然后用 ./ffprobe -i ${i} -show_streams 将所有的 ts 切片捣出到一个文件中。
如果源视频不是 m3u8 ，可以直接用 ./ffprobe -i ${i} -show_streams > ts_result 将源视频的 streams 信息输入到一个文件中。

• 1）先看下用户的视频中是否有 discontinuity 属性，如果源视频是多个视频内容拼到一起的，视频中都会带有这个字段。出现这种问题，可以看下出现 discontinuity 的前一个 ts 片的音频 duration 和视频 duration 时间戳是否不一致。一般都是因为源视频写入的音视频的时间差距较大导致的。
• 2）discontinuity ，我们直接分析源视频导出的 streams 信息，egrep "codec_name=.*|duration=|codec_name=aac|duration=" ts_result 目的主要对比音视频的写入时间差距。通过下面的导出的 ts 音视频 duration 对比可知道源视频中就出现了音视频不同步的问题，那么转码得到的肯定也是不同步的。

codec_name=h264
duration=8.573000
codec_name=aac
duration=8.271211
codec_name=h264
duration=8.248000
codec_name=aac
duration=8.114211
codec_name=h264
duration=4.636000
codec_name=aac
duration=3.546211
codec_name=h264
duration=3.460000
codec_name=aac
duration=2.137211
codec_name=h264
duration=3.991000
codec_name=aac
duration=2.000211
codec_name=h264
duration=8.251000
codec_name=aac

案例：

经过 MTS 拼接处理后，通过 jobid 查到的转码文件地址无法播放，下载文件 404 。

排查：

• 出现这种视频问题，先校验一下自己调用 MTS 的转码输出参数。 参考
  拿到这个视频的参数后，优先看下视频的 seek 参数，一般 拼接视频，都会用到 seek （从哪个时间戳开始拼接），该转码任务的提交 seek 参数是 76s 。
• 使用分析工具 ffprobe 去分析用户的视频，看下原视频的 duration ，是 27s ；

./ffprobe -i "http://test.oss-cn-hangzhou.aliyuncs.com/p%E6%B5%8B%E8%AF%95-17-53f9d9edc3-7555-456f-819a-7b7aed901764%2Ff9d9edc3-7555-456f-819a-7b7aed9017644.mp4"

  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.12.100
  Duration: 00:00:27.63, start: 122.600998, bitrate: 2611 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720, 2470 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 129 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

• 经过对比，可以知道提交的转码任务 seek 时间大于原视频时间，所以转码失败。