看了很久的ijkplayer的视频播放，其实还是没有怎么看懂，只是个人浅浅的笔记
关键部分就是联网获取数据那部分，还没有搞定其实
从用户点击一个已有地址的网络视频开始，从源码分析播放流程。
1. // init player 加载native底层库
IjkMediaPlayer.loadLibrariesOnce(null);
IjkMediaPlayer.native_profileBegin("libijkplayer.so");
第一句话是加载三个重要的so文件
libLoader.loadLibrary("ijkffmpeg");
libLoader.loadLibrary("ijksdl");
libLoader.loadLibrary("ijkplayer");
第二句话调用了一个native方法public static native void native_profileBegin(String libName);
2. 设置uri，可以是rtmp，rtsp，http等，native ffplay代码中会根据该uri匹配不同的流媒体协议，具体参考ffplay。 支持本地和网络视频。
if (mVideoPath != null)
mVideoView.setVideoPath(mVideoPath);
else if (mVideoUri != null)
mVideoView.setVideoURI(mVideoUri);
3. 分析网络视频源：接着openVideo()
先创建播放器 mMediaPlayer = createPlayer(mSettings.getPlayer());接着是播放器的相关设置
诸如: mMediaPlayer.setOnPreparedListener(mPreparedListener);
mMediaPlayer.setOnVideoSizeChangedListener(mSizeChangedListener);
mMediaPlayer.setOnCompletionListener(mCompletionListener);
mMediaPlayer.setOnErrorListener(mErrorListener);
mMediaPlayer.setOnInfoListener(mInfoListener);
mMediaPlayer.setOnBufferingUpdateListener(mBufferingUpdateListener);等
当然，还需要设置播放源，会调用
tv.danmaku.ijk.media.player.IMediaPlayer#setDataSource(android.content.Context, android.net.Uri, java.util.Map<java.lang.String,java.lang.String>)
开始播放mVideoView.start();调用tv.danmaku.ijk.media.player.IMediaPlayer#start，这里java层就结束了，进入c底层，其实从加载native底层库开始就进入c底层了
4. 分析c底层：/ijkmedia/ijkplayer/android/ijkplayer_jni.c这个文件里 static JNINativeMethod g_methods[] 一个数组，声明了全部的java层的native方法 ，而调用native的方法集中在类 tv.danmaku.ijk.media.player.IjkMediaPlayer
5. 没想到居然是c主动调用java,通过反射生成java端所需要的函数，这个地方不是我们正常JNI的调用思路
正常调用JNI的思路：是通过javah，获取一组带签名函数，然后实现这些函数。这种方法很常用，也是官方推荐的方法。
分析一下JNI运行时机制：
当在系统中调用System.loadLibrary函数时，该函数会找到对应的动态库，然后首先试图找到"JNI_OnLoad"函数，如果该函数存在，则调用它。
JNI_OnLoad可以和JNIEnv的registerNatives函数结合起来，实现动态的函数替换。很显然ijk的作者是使用的这种调用方式
在 ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/android/ijkplayer_jni.c
然后在JNI_OnLoad 初始化好多内容，比如上图三个 global 型的函数
这样就可以理解作者为什么一开始就先调用三个 so 文件了
ijkplayer-sample/src/main/jni/ijkmedia/ijksdl/android/ijksdl_android_jni.c里也有JNI_OnLoad。
Ffmpeg的个人感觉是不需要，因为作者直接使用的ffmpeg的代码，只需要正常引入就好。
6. J4a里生成的两个java文件也是很重要的类
目前还不清楚作用
7. ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ff_ffplay_def.h 这个定义了ijk播放器核心数据结构体的类，作者是直接使用的ffmpeg的ijkplayer-sample/src/main/jni/ffmpeg/ffplay.c在ffmpeg的文件的基础上的扩展，里面引用了很多ffmpeg的源文件。基本上就不需要关心ffmpeg的源代码了。
8. 这里只分析libijkplayer.so
8.1 ijkmp_global_init 在 ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkplayer.c
void ijkmp_global_init()
{
ffp_global_init();
}
ffp_global_init() 在
ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkplayer_internal.h的include的
ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ff_ffplay.h里，具体定义代码在
ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ff_ffplay.c中，主要是ffmpeg的初始化工作。
8.2 ijkmp_global_set_inject_callback(inject_callback)是在
ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkplayer.c的include的
ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkavformat/ijkavformat.h里声明，
在ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkavformat/utils.c里定义
这里使用最多的是ijkavformat.h里的
typedef int (*IjkAVInjectCallback)(void *opaque, int message, void *data, size_t data_size);
这个声明引入了 IjkAVInjectCallback 类型作为函数指针的同义字，该函数有四个不同 类型的参数以及一个 int 类型的返回值
IjkAVInjectCallback ijkav_register_inject_callback(IjkAVInjectCallback callback);定义一个函数ijkav_register_inject_callback，这个函数的参数是一个函数指针，返回值也是个函数指针，相当于int ( *ijkav_register_inject_callback( int (*callback)(void *opaque, int message, void *data, size_t data_size) ) )(void *opaque, int message, void *data, size_t data_size);
由于int (*callback)(void *opaque, int message, void *data, size_t data_size)
是IjkAVInjectCallback ，上面的简化一下就是
int ( *ijkav_register_inject_callback( IjkAVInjectCallback ) )(void *opaque, int message, void *data, size_t data_size);这里的
*ijkav_register_inject_callback( IjkAVInjectCallback ) 又是一个返回IjkAVInjectCallback的函数 ，再简化一下，即
int IjkAVInjectCallback (void *opaque, int message, void *data, size_t data_size);
8.3 FFmpegApi_global_init(env)在
ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/android/ffmpeg_api_jni.c
主要作用是 初始化 tv.danmaku.ijk.media.player.ffmpeg.FFmpegApi#av_base64_encode 的函数
9. 在System.loadLibrary 三个so文件时作者做了一些初始化的工作，接着调用native native_profileBegin方法，在
ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/android/ijkplayer_jni.c的
IjkMediaPlayer_native_profileBegin 方法，卡在void monstartup(const char *libname);这个函数，没有找到定义的地方。决定试试注释IjkMediaPlayer.native_profileBegin("libijkplayer.so");
tv/danmaku/ijk/media/sample/activities/VideoActivity.java:139
这句话不执行，注释后依旧可以播放，我就不能理解了。哈哈，此处留坑。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
10. 接着看看_setDataSource(String path, String[] keys, String[] values)别看有三个参数，实际调用时只需要一个参数
tv.danmaku.ijk.media.player.IjkMediaPlayer#383 _setDataSource(path, null, null);
关键就是 ijkmp_set_data_source(mp, c_path);这是通过include "ijkplayer_android.h"然后#include "../ijkplayer.h"，具体定义在ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkplayer.c
ijkmp_set_data_source(IjkMediaPlayer *mp, const char *url)两个参数，一个参数是是IjkMediaPlayer，
typedef struct IjkMediaPlayer IjkMediaPlayer;
（ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkplayer.h）
只是声明了名字，定义在ijkplayer-sample/src/main/jni/ijkmedia/ijkplayer/ijkplayer_internal.h
另一个参数是视频源地址。
这是视频源 mp->data_source = strdup(url);这样IjkMediaPlayer类型的mp 里的VideoState （ff_ffplay_def.h）类型的 is 里的filename 就有了视频源
接着就执行到 ijkmp_change_state_l(mp, MP_STATE_INITIALIZED);更换播放器状态
void ijkmp_change_state_l(IjkMediaPlayer *mp, int new_state)
{
mp->mp_state = new_state;
ffp_notify_msg1(mp->ffplayer, FFP_MSG_PLAYBACK_STATE_CHANGED);
}
ffp_notify_msg1这个函数是通过#include "ijkplayer_internal.h"再#include "ff_ffplay.h"再#include "ff_ffplay_def.h"进来，定义为
inline static void ffp_notify_msg1(FFPlayer *ffp, int what) {
msg_queue_put_simple3(&ffp->msg_queue, what, 0, 0);
}
其中 inline这个关键词会给编译器这样一种建议：不要进行实际的函数调用而只是将这段代码插入到进行调用的地方。
上面用到的一个比较重要的结构体FFPlayer 定义在ijkmedia/ijkplayer/ff_ffplay_def.h#494
目前还不知道其具体作用，但是感觉这是播放时一个很重要的结构体。
msg_queue_put_simple3在 ijkmedia/ijkplayer/ff_ffmsg_queue.h
继续跟踪代码，发现走到msg_queue_put_private这个函数，将其放在消息队列里。
至于放在哪个消息队列里，谁又负责读取消息队列里的消息，这个在后面分析。
按照递归的思想，依次返回，
在ijkplayer_jni.c里 IJK_CHECK_MPRET_GOTO(retval, env, LABEL_RETURN); 这个不知是干嘛的，只是看见difine里，继续留坑。。。。。。。。。。。。。。。。。。。。。。。。。。。。
11. 现在开始执行tv.danmaku.ijk.media.player.IjkMediaPlayer#_start的方法，
在ijkmedia/ijkplayer/android/ijkplayer_jni.c#226 ijkmp_start(mp);根据作者的命名规则，ijkmp...都是在ijkmedia/ijkplayer/ijkplayer.h里，这个函数定义在197行
实现自然就在ijkplayer.c#441
最重要的应该就是这句话了 ffp_notify_msg1(mp->ffplayer, FFP_REQ_START);
ffp_notify_msg1 通过 #include "ijkplayer_internal.h"，#include "ff_ffplay.h"，#include "ff_ffplay_def.h"，调用了 msg_queue_put_simple3(&ffp->msg_queue, what, 0, 0);这个跟第10条是调用一个函数，都是msg_queue_put_simple3，这次传递的消息是FFP_REQ_START，定义在ijkmedia/ijkplayer/ff_ffmsg.h里，关于消息队列的分析，在后面分析。
12. 其实在这里会有个疑问，作者先是设置了视频源，接着开始播放，这是两个不同的C函数，都使用了 IjkMediaPlayer 这个对象，用面向对象的语言来提问就是：如何保证这两个对象是同一个对象，即设置播放源的IjkMediaPlayer和播放的IjkMediaPlayer是同一个对象
设置播放源里：IjkMediaPlayer *mp = jni_get_media_player(env, thiz);
播放函数里面：IjkMediaPlayer *mp = jni_get_media_player(env, thiz); (JNIEnv *env, jobject thiz)
jni_get_media_player在ijkplayer_jni.c#61 ，调用了IjkMediaPlayer *mp = (IjkMediaPlayer *) (intptr_t) J4AC_IjkMediaPlayer__mNativeMediaPlayer__get__catchAll(env, thiz);
这里用到的就是上文第六点提到j4a，在
ijkmedia/ijkj4a/j4a/class/tv/danmaku/ijk/media/player/IjkMediaPlayer.h#53 define
#define A B 的意思就是在程序里使用A替代B，A就代表B，
看看作者是怎么实现的
在这里使用了一个JNI函数
GetLongField() NativeType Get<type>Field(JNIEnv *env, jobject obj, jfieldID fieldID);
Static 修饰的fieldID即可以保证两次获取的是同一个对象。
上面的方法里有个强转 ，intptr_t类型是为指针准备的，C语言指针用来保存变量或常量的地址，地址由处理器的位数决定，intptr_t在不同的平台是不一样的，始终与地址位数相同，因此用来存放地址，即地址。
13. 分析消息队列：现在知道了c里面关键变量都是做了单例的，比如我们现在要分析的IjkMediaPlayer。
其定义在ijkmedia/ijkplayer/ijkplayer_internal.h
标红的，一个是线程互斥锁pthread_mutex_t，这个的使用在源码中随处可见，另一个是很重要的FFPlayer，定义在ijkmedia/ijkplayer/ff_ffplay_def.h里，结构体里面包含了很多内容，目前只分析一个MessageQueue msg_queue;定义在ijkmedia/ijkplayer/ff_ffmsg_queue.h
msg_queue_put_private一大段处理消息的算法，找出关键函数 SDL_CondSignal(q->cond);通过#include "ff_ffinc.h"，#include "ijksdl/ijksdl.h"，#include "ijksdl_mutex.h"。具体定义在ijkmedia/ijksdl/ijksdl_mutex.c，
pthread_cond_signal(pthread_cond_t *cond)函数是用来在条件满足时，给正在等待的对象发送信息，表示唤醒该变量，一般和pthread_cond_wait函数联合使用
其实到这个地方，就会发现源代码分析不下去了，因为找不到可用函数了，这里用来唤醒线程，但是又不清楚唤醒的是哪个进程，这个进程什么时候堵塞的，其实是我们少分析了一部分，作者在最开始加载三个so文件时，做了很多初始化的工作，这里就不可避免要去分析ffmpeg的源代码了。
回过头来再看看初始化三个so文件时的操作
av_ 开头的函数都是ffmpeg里的，avformat_network_init在ffmpeg/libavformat/avformat.h里声明，做网络的初始化，可惜我还没有找到定义的位置。这里关注ijkav_register_all，声明在 ijkmedia/ijkplayer/ijkavformat/ijkavformat.h ，定义在ijkavformat/allformats.c
标红的部分是我要重点分析的地方
URLProtocol ffmpeg里一个很重要的结构体，定义在libavformat/url.h
URLProtocol存储输入视音频使用的封装格式，功能就是完成各种输入协议的读写等操作
其中包含了用于协议读写的函数指针。例如：
url_open()：打开协议。
url_read()：读数据。
url_write()：写数据。
url_close()：关闭协议。
但输入协议种类繁多，它是怎样做到“大一统”的呢？
原来，每个具体的输入协议都有自己对应的URLProtocol。
比如ijktcphook协议
ijklongurl：
还有好多，不一一例举了，它们把各自的函数指针都赋值给了URLProtocol结构体的函数指针。
上面的代码中，有个很关键的关键字，extern，使用时extern URLProtocol ijkff_##x##_protocol;
extern可以置于变量或者函数前，以标示变量或者函数的定义在别的文件中，提示编译器遇到此变量和函数时在其他模块中寻找其定义。
上面的声明最终都是调用ffurl_register_protocol这个ffmpeg里的函数，无从下手，看来得需要阅读ffmpeg的源码
原谅我源码读的有够失败，没有找到ffurl_register_protocol的声明和定义。。。。。。。
但是，从这个同名大概可以猜测一些，应该就是引用这些文件吧，这只是猜测而已。
14. 到这里好像已经进行不下去了，因为全部都是开始调用ffmpeg里的代码了，顺序走不下去可以逆序嘛。现在就逆序分析，我们知道ijk的作者写的ijkmedia/ijkplayer/ff_ffplay.c是建立在ffmpeg的ffmpeg/ffplay.c的基础上的，基本上这里面的代码是直接使用ffmpeg的代码，在这个文件里有一个read_thread函数，ffmpeg的作者写了一个注释
Ijk的作者应该是重写了ffplay.c，从read_thread的被调用来看，ffp_prepare_async_l --> stream_open --> read_thread，我没有找到ffp_prepare_async_l 被调用的地方，然后看到read_thread里面的代码
很熟悉有没有，输出的日志嘛
可以猜测这段代码是在设置视频源初始化时被调用的，不知是否还记得分析的第10条，而且看参数ffp_prepare_async_l(FFPlayer *ffp, const char *file_name) ，一个是FFPlayer ，一个是file_name，如果是网络视频，那就是视频源地址了。
虽然还没有分析代码里线程池睡眠唤醒的机制，但是可以猜测使用的是同一个一个FFPlayer 对象。
继续分析代码，在stream_open 函数里，不是我瞎猜想，看ijk作者注释
证明我的猜想分析是正确的，然后就到了我们很重要的read_thread。
这个函数主要就是读取二进制流，里面用到了以下这些很重要的结构体:FFPlayer，VideoState，AVFormatContext，AVPacket，
可以看见执行了avformat_open_input(&ic, is->filename, is->iformat, &ffp->format_opts);
这个函数是ffmpeg里的，应该是读取视频文件。这个函数的声明int avformat_open_input(AVFormatContext **ps, const char *url, AVInputFormat *fmt, AVDictionary **options); 在ffmpeg/libavformat/avformat.h
定义在ffmpeg/libavformat/utils.c ，知道这几个参数很重要，但是还清楚其具体作用，那我怎么阅读呢，int avformat_open_input(AVFormatContext **ps, const char *filename, AVInputFormat *fmt, AVDictionary **options)，看参数，有个filename，那我就已filename为主线，第一次被调用是init_input(s, filename, &tmp)，这个函数在utils.c，好像是一个什么评分规则，没看懂反正，估计是判断视频源是什么格式的。我不是瞎猜测的哈
Ffmpeg的作者对这个函数有注释，它的主要工作就是打开输入的视频数据并且探测视频的格式。这里没有几行代码，但是好多return，足见次函数的算法逻辑。
调用av_probe_input_buffer2这个内容很多，此处不分析，在第16条分析
这里有个目测是最基础的结构体 AVFormatContext ，定义在 ffmpeg/libavformat/avformat.h
作用就是 Format I/O context 中文讲就是处理封装格式（FLV/RMVB/MP4等），你要是好奇ffmpeg到底支持哪些格式，我告诉你个地方，ffmpeg/libavformat/allformats.c，里面有av_register_all，熟悉吧，初始化时都执行的函数，里面出现的格式都是ffmpeg支持的。
这个结构体里有两个指针 protocol_whitelist 和 protocol_blacklist ，大概猜测就是白名单黑名单的作用，这个出现应该是处理上文第13条里种类繁多的URLProtocol。
接着执行到
/* e.g. AVFMT_NOFILE formats will not have a AVIOContext */
if (s->pb)
ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, 0);
这里有个
AVIOContext *pb;类型的pb。AVIOContext 结构体的分析放在第15条，这里不分析。
ff_id3v2_read的定义在ffmpeg/libavformat/id3v2.c。目测是处理id3v2头信息的。这个函数调用id3v2_read_internal，里面有个函数avio_tell定义在ffmpeg/libavformat/avio.h，
接着执行 avio_read。声明在ffmpeg/libavformat/avio.h
原谅我没有找到这个函数的定义，avio_read应该是联网读取是调用。联网的分析放在第16条。
读取网络数据包头信息时调用id3v2_parse(pb, metadata, s, len, buf[3], buf[5], extra_meta);接着调用get_extra_meta_func，会使用到id3v2_extra_meta_funcs[]这个数组，里面有read_geobtag这样一个方法，这个方法里会read encoding type byte，read MIME type (always ISO-8859)，read file name，read content description 。
别小看这里的读取头信息，这里其实ff_id3v2_read的操作结果是直接对参数 &id3v2_extra_meta 进行更改的。获取到头信息后会执行ff_id3v2_parse_apic，这个函数也是在id3v2.c 里，这个函数带给我们有一个ffmpeg里很重要的结构体AVStream。定义在ffmpeg/libavformat/avformat.h。视音频流对应的结构体，用于视音频编解码，
同时AVStream这个结构体里包含了另外一个很重要的结构体，AVPacket attached_pic，这个attached_pic在ff_id3v2_parse_apic使用率较高
AVPacket 的定义在ffmpeg/libavcodec/avcodec.h ，主要是存储压缩数据（视频对应H.264等码流数据，音频对应AAC/MP3等码流数据），这个结构真的很重要，ffmpeg的原作者注释
For video, it should typically contain one compressed frame. For audio it maycontain several compressed frames. 即视频和音频还不一样。
avformat_open_input这个函数同样的，执行完成后对参数AVFormatContext **ps进行了更新。
在ffmpeg/libavformat/utils.c里发现一个函数avformat_find_stream_info，虽然还没有发现其使用的地方，但是大概看了一下函数方法，应该是解析流，可以解析出很多信息，没有细看内容，应该是可以解析出视频流的详细信息，时长，比特率等等。
退回到ff_ffplay.c的read_thread，作者在寻找h246流，即视频流
我们知道访问网络是获取的数据包有很多，作者取出其中的H264包。
av_find_best_stream的声明在 ffmpeg/libavformat/avformat.h，定义在ffmpeg/libavformat/utils.c，ffmpeg的作者有一套算法找出用户最想要的streams，我没有去研究去算法。
接着就是 open the streams
stream_component_open 函数在同一个文件里
其实这个函数的最主要的作用应该是创建audio_thread和video_thread线程，关于这两个线程，放在18条分析
在decoder_start 里 调用packet_queue_start(d->queue);
当然前面调用了avcodec_find_decoder，根据id找到解码器。
现在audio和video都有了，就准备播放了，主要包括SDL_mutex信号量创建（这个就是类似13条里说的线程锁
）、AVFormatContext创建、打开输入文件、解析码流信息、查找音视频数据流并打开对应的数据流，这是函数里的第一部分。
接着后面跟了一个死循环，开始循环读取视频流了
循环读取代码里好多的算法逻辑，好些地方不太明白。具体分析放在17条，这是第二部分。
代码里还有一部分fail时的操作，在代码的最后，主要包括退出前的等待、关闭音视频流、关闭avformat、给主线程发送FF_QUIT_EVENT消息以及销毁SDL_mutex信号量，这是第三部分。
15. AVIOContext 是ffmpeg中很重要的结构体，定义在libavformat/avio.h，输入输出对应的结构体，用于输入输出（读写文件，RTMP协议等），ffmpeg的作者给了一个形象的图来解释其重要性
16. 分析ffmpeg的获取数据（联网）
av_probe_input_buffer2，调用在ffmpeg/libavformat/utils.c的init_input函数
声明在ffmpeg/libavformat/avformat.h，作用Probe a bytestream to determine the input format.定义在 ffmpeg/libavformat/format.c
使用了一个结构体AVProbeData 定义在libavformat/avformat.h，用于存储输入文件的一些信息
av_probe_input_buffer2也可以分为三部分分析，初始化，循环读取，反初始化，重点分析循环读取部分，循环部分调用avio_read()读取数据，调用av_probe_input_format2推测文件格式
int avio_read(AVIOContext *s, unsigned char *buf, int size); Read size bytes from AVIOContext into buf.
av_probe_input_format2定义在ffmpeg/libavformat/format.c ，里面调用av_probe_input_format3，这个也是定义在ffmpeg/libavformat/format.c，这个函数的返回值是AVInputFormat类型的，定义在ffmpeg/libavformat/avformat.h，里面定义了一个int (*read_probe)(AVProbeData *) 这个是av_probe_input_format3函数里循环部分调用的比较重要的，关键read_probe 是一个函数呀，这个函数用于获得匹配函数的函数指针，不同的封装格式包含不同的实现函数。以常见的flv格式来说，在ffmpeg/libavformat/flvdec.c
read_probe对应的就是 live_flv_probe,live_flv_probe定义在同一个文件里。在比如swf格式
每个格式都有不同的匹配规则，为了判断当前文件的格式，就已得分的高低来判断，av_probe_input_format2的操作结果是更新参数里的得分，同时得出文件是什么格式的。
现在可以回到init_input函数，在avformat_open_input里调用结束后，接着执行到ff_id3v2_read函数，这个在14条里已分析，接着执行s->iformat->read_header(s)，没错，会调用AVInputFormat的read_header()方法读取媒体文件的文件头并且完成相关的初始化工作。以flv格式来看，会调用flv里实现的flv_read_header方法，在函数里没有找到代码，但是我感觉如果读取头文件成功应该会继续调用AVInputFormat的read_packet()读取网络数据包，原谅我没有找到。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
虽然我没有找到，但代码就是这么执行的，可以接着分析，
回到avformat_open_input，接着调用avformat_queue_attached_pictures，这里面有个方法，add_to_pktbuf，作用是 Add the packet in the buffered packet list。完成后，紧接着就是update_stream_avctx，有新的packet到达，里面做的操作无非就是判断当前状态，然后清空队列等等。
由于正向没有找到入口函数，这里才有逆向分析
主要是分析两个文件 ffmpeg/libavformat/url.c 和 ffmpeg/libavformat/network.c 从源码中分析出ffmpeg是使用socket联网
不知是否还记得13条里初始化时有个网络的输出化avformat_network_init，这个函数的定义在ffmpeg/libavformat/utils.c，这里有两个初试化。一个ff_network_init，一个ff_tls_init。
ff_network_init在ffmpeg/libavformat/network.c里定义，里面用了一个全局变量ff_network_inited_globally，在 .h 文件里声明了extern int ff_network_inited_globally;还没有找到其定义哈，哎呀都什么眼神，在avformat_network_init函数里，就调用了ff_network_inited_globally = 1;
ff_tls_init定义也在network.c，会用到两个函数ff_openssl_init和ff_gnutls_init，都是声明在ffmpeg/libavformat/tls.h，至于定义嘛，我还没有找见。只好看看注释咯
17. 循环读取分析：即for死循环里的代码
先是对是否暂停(暂停就不接受数据包了
，看来这个网络接收这块是一直连接着，只要没停止就一直接收着数据)，是否拖动快进或快退判断接着往packet的队列里put
还有判断队列是否满了 if the queue are full, no need to read more
av_read_frame 声明在 ffmpeg/libavformat/avformat.h ，作用:Return the next frame of a stream.
作者的算法逻辑很强，当然这段代码里只是往packet队列里put，只是取出packet，在取的时候要判断当前的各种状态，暂停？快进？队列是否满，正在播放？等等，这些函数都是处理这些逻辑的，比如：ffp_toggle_buffering，step_to_next_frame_l，stream_update_pause_l等 。
代码中多次出现continue_read_thread，
从其名字上来看，是一个控制read_thread线程是否继续阻塞的信号量，上面两次阻塞的地方分别是：packet队列已满，需要等待一会(即超时10ms)或者收到信号重新循环；读数据失败，av_read_frame出错时，如读取网络实时数据时取不到数据，此时也需要等待或者收到信号重新循环。
总结一下，循环读取数据部分：主要包括pause和resume操作处理、seek操作处理、packet队列写入失败处理、读数据结束处理、然后是读数据并写入到对应的音视频队列中。
处理真正播放不在这里，继续分析
18. audio_thread和video_thread
定义在ff_ffplay.c，会发现作者开启线程是把其设为异步线程
ffplay_video_thread是处理视频核心实现部分，这个函数同read_thread一样也是分了三部分
初始化部分：主要包括AVFrame创建和AVFilterGraph创建。
AVFrame *frame = av_frame_alloc();
AVFilterGraph *graph = avfilter_graph_alloc();
循环解码部分（for循环）：主要包括pause和resume操作处理、读取frame处理、AVFILTER处理、然后是将frame写入视频picture队列中以及每次解码后的清理动作。
读取get_video_frame，作者每次都是先释放再初始化AVFilterGraph 。
avfilter_graph_free(&graph);
graph = avfilter_graph_alloc();
添加frame到buffer缓存区av_buffersrc_add_frame，
其中AVFILTER部分，过滤器嘛，学过通信原理都知道，接收到的信号会有损失，有杂波，需要对解码后的数据进行滤波，去除方块效应
出现了一个结构体，AVRational，没有找到其定义，但是从使用来看，这个结构体里面有两个参数：frame_rate.num && frame_rate.den，应该就是用这两个参数算出一个值，类似分式那种分子分母。
queue_picture函数里，调用里YUV
SDL_VoutFillFrameYUVOverlay(vp->bmp, src_frame)
这里使用到了YUV，大概流程就是ffmpeg解码,转成YUV格式的视频帧，然后再使用sdl的yuv覆盖的模式进行渲染，剩下的就是显示了，这个是SDL处理的，用于视频图像显示和刷新，暂时不做分析。
结束部分：主要包括刷新codec中的数据、释放AVFilterGraph、释放AVPacket以及释放AVFrame。
这里要总结两个结构体：
AVFrame：存储非压缩的数据（视频对应RGB/YUV像素数据，音频对应PCM采样数据）
AVPacket：存储压缩数据（视频对应H.264等码流数据，音频对应AAC/MP3等码流数据）
audio_thread的分析类似，只是少了YUV的渲染，不做重复分析了，源码在ff_ffplay.c。