wangtonghua97的博客

最近在搞MEMC优化过程中，经常能够发现视频在起播阶段会丢几帧，记录下问题分析过程。对于AV同步及丢帧等问题的分析，最好就是将数据从demux到decoder最后到output的pts都打印出来，VLC还涉及到stream时间与系统时间的转换，因此clock_point也需要打印出来，这样能够快速地定位到问题原因。对于这题，视频被丢的前几帧和后续的正常帧有一个区别，那就是它们在做时间转换时参考的clock_point不一样。为什么会发生这种情况呢？我们回顾下VLC-Android音画同步原理中关于b

最近在分析一个播放器退出ANR的问题时，详细地跟踪了VLC的退出流程，这里问题的分析先按下不表，我们先结合代码详细了解下播放器的退出流程。1.java—>jni—>native的Stop调用流程，没什么好说的，直接上代码 //MediaPlayer.java /** * Stops the playing media * */ publicvoidstop() { synchronized(this) { ...

最近在做MEMC调试涉及到了播放器刷帧频率的问题，因此深入研究了一下VLC视频的显示流程，仔细研究过后发现还是有挺多坑的，在这里分享下：VLC的视频显示逻辑主要在video_output.c中，其内部维护了一个线程用来接收control和刷新显示（这里和ijkplayer很像）： //vout中其实有两个线程，分别名为Thread和ThreadStep，视频正常播放走的是Thread，步进播放走的是ThreadStep（类似ffplay的s键），这里主要还是介绍Thread /****

对于音频播放异常的问题，由于我们可以拿到解码前后的数据，因此还是比视频播放异常的问题好分析一些的。通过dump解封装后的es数据和解码后的pcm数据，我们可以快速的定位问题出现的大致位置：demux，decoder，aout。本题也是一样，先dump es和pcm数据，发现都没有问题，那基本就是aout部分惹的祸了。通过加日志，发现在音频播放快结束的时候，aout调用了两次flush。全局搜索aout_DecFlush函数，发现有三种情况下会调用：1.decoder flush；2.decoder de

VLC ExoPlayer ijkplayer 平台 Android、iOS、Linux、Windows跨平台 Android Android、iOS 封装格式 全面 一般 全面 协议 全面 全面 全面 Android MediaCodec NDK java jni->java Tunnel Mode 不支持 支持 支持 Audio Bypass 不支持 支...

VLC通过variables来接受外部控制事件和向外部发送事件，variables同时也可以作为modules之间简单通讯的载体。本文通过举例详细介绍下variables的功能。接受外部控制事件以seek为例，vlc-android在seek时可以调用MediaPlayer.java的setTime()方法。 /** * Sets the movie time (in ms), if any media is being played. * @param time: T..

简介播放器的音视频同步无外乎三种方式：视频往音频同步、音频往视频同步及音视频同时往系统时钟同步。大部分播放器都是采取第一种方式，例如ffplay、EXOPlayer、Nuplayer、ijkplayer等。而VLC就比较不合群了，它采用音视频同时往系统时钟同步的方式，下面结合代码简单介绍下音画同步的原理。VLC专门有一个clock.c文件，用来维护时钟信息，其核心结构体如下，阐述了VLC音画同步的核心思想： typedef struct { mtime_t i_st...

从测试描述了解到该问题复现概率较高，因此决定刷最新版本后重新抓份log。果然，seek几次就遇到了问题，查看log并定位到最后一次seek的位置，可以明显的看到如下异常打印： //seekto指令 04-3012:02:08.8401616416164I PlayerWrapper: [FMPlayer] [3] seekTo(69069) //dequeue_in超时 04-3012:02:10.9021616419639W VLC : [e3f8...

一、简介了解一定播放器知识的同学应该都知道，播放器内部是有缓存的（非直播场景）。缓存的作用主要是解决生产者和消费者速度的不匹配，给用户更好的使用体验。例如，在网络不稳定的情况下，可以提前缓存部分数据确保视频流畅播放；在网络差的情况下，可以及时弹出缓冲标志提示用户当前网络不好。下面简单介绍下VLC的Buffering机制。我们在使用VLC播放视频时，能够明确的看到类似如下日志： 08-0613:48:51.8451149512427D VLC : [894f9830/308b...

在讲这个问题之前需要先介绍下VLC的AV同步逻辑，截止VLC 3.0.16版本，VLC只支持AV同步到系统时钟，所以clock中有stream和system两个概念。播放器会将解码后数据的pts从stream参考系转换到system参考系，具体的转换方式这里不做赘述，这里想说明的是，解码之后数据的pts被转换成系统时间了，如果此时暂停播放器，系统时间还是会线性增长的，一段时间后恢复播放，这些数据会触发too late逻辑被丢掉。为了防止这种情况出现，VLC在video_output中添加了如下逻辑，记录了从

拿到问题首先还是看日志，可以明显看到触发了VLC的too early条件，往AudioTrack塞0导致的无声。 04-2811:33:12.5541082511073W VLC : [a5a8d430/2b41] libvlc audio output: playback way too early (-1264388) than (-240000), cache734153: playing silence 04-2811:33:12.5551082511073...

最近在做Dolby认证时遇到了一个fMP4视频seek后卡顿的问题，最终定位到是ffmpeg对于异常片源的容错做的不是很好。由于该问题涉及到大量ffmpeg原生代码流程的分析，整体分析的时间会比较长，对mov.c的理解也更加深刻了，特此记录一下。对于这种卡顿问题首先肯定是怀疑丢帧，果然在问题日志中看到了如下异常打印： 05-1211:04:51.24753340487508W VLC : [d294a530/1d54] libvlc video output: pictur...

VLC的avsync方案是audio video同步到系统时钟，且audio sync的阈值比较敏感，很容易出现丢帧的情况。相对于audio master的同步方案，VLC的同步方案比较“理想”化，经常会出现无声问题。下面记录下目前遇到过的无声问题及分析记录：目录一、seek后无声1.片源av pts差异较大2.pts跳变二、起播无声1.AudioTrack起播慢一、seek后无声1.片源av pts差异较大首先先介绍下ffmpeg的demux方式，ffmpeg在解封

VLC 音频同步的核心代码在aout_DecSynchronize函数中，其中涉及到的变量及逻辑比较复杂，但其核心思想其实已经包含在了下面的注释中： /** * Depending on the drift between the actual and intended playback times, * the audio core may ignore the drift, trigger upsampling or downsampling, * insert ...