场景
探测ES流，avformat_open_input会非常快的返回，PS反而是一个例外。通过调用av_log_set_callback设置日志写文件的方式，
在调用avformat_open_input函数探测PS输入格式时候，
会打印如下的日志：
Probing mp3 score:1 size:2048
Probing mp3 score:1 size:4096
Probing mp3 score:1 size:8192
Probing mp3 score:1 size:16384
Probing h264 score:51 size:32768
Format h264 probed with size=32768 and score=51
Input #0, h264, from '':
Duration: N/A, bitrate: N/A
Stream #0:0, 0, 1/1200000: Video: h264 (Baseline), yuvj420p, 1920x1080, 25 fps, 0.04 tbr, 1200k tbn
deprecated pixel format used, make sure you did set range correctly
non-existing PPS 0 referenced
non-existing PPS 0 referenced
nal_unit_type: 1, nal_ref_idc: 3
non-existing PPS 0 referenced
non-existing PPS 0 referenced
decode_slice_header error
non-existing PPS 0 referenced
non-existing PPS 0 referenced
non-existing PPS 0 referenced
no frame!
通过跟踪源码Probing h264 score:51 size:32768日志打印在调用
av_probe_input_format3函数会打印
name h264
long_name raw H.264 video
raw_codec_id 28
说明如果指定了AVInputFormat结构体，就可以节省探测码流格式的时间
ffmpeg 针对指定的h264 es流延时优化
参考http://blog.csdn.net/rain_2011_kai/article/details/7746805文章，
是否只需要知道发送端发送的视屏的解码器ID,视频帧的长和宽，就可以直接
直接省略掉ffmpeg库的视频流探测接口，avformat_open_input函数
和avformat_find_stream_info函数耗时超过500毫秒
手动指定解码格式 效果不明显
+buffer0x00000000002cbdc0 <字符串中的字符无效。>unsigned char *
+buf_end0x00000000002d3626 <字符串中的字符无效。>unsigned char *
30822
pos 262349
buffer 2932160
buf_end 2962982
buffsize 35840
buf_end-buffer 30822
pos的值从哪里来，值得考虑
pFormatContext->pb->pos = pFormatContext->pb->buf_end;
在已有的版本是编译不过的，因为pos是一个64位整型，buf_end是一个字符指针
但是从上面还是看不出它们之间的关系，尽管手动指定解码格式，但是效果并不理想
还有在这里读取一帧的数据
m_pVideoc->io_ctx = avio_alloc_context(m_pAvioBuf, BUF_SIZE, 0, this, ReadStreamData, NULL, NULL);
探测ES流，avformat_open_input会非常快的返回，PS反而是一个例外。通过调用av_log_set_callback设置日志写文件的方式，
在调用avformat_open_input函数探测PS输入格式时候，
会打印如下的日志：
Probing mp3 score:1 size:2048
Probing mp3 score:1 size:4096
Probing mp3 score:1 size:8192
Probing mp3 score:1 size:16384
Probing h264 score:51 size:32768
Format h264 probed with size=32768 and score=51
Input #0, h264, from '':
Duration: N/A, bitrate: N/A
Stream #0:0, 0, 1/1200000: Video: h264 (Baseline), yuvj420p, 1920x1080, 25 fps, 0.04 tbr, 1200k tbn
deprecated pixel format used, make sure you did set range correctly
non-existing PPS 0 referenced
non-existing PPS 0 referenced
nal_unit_type: 1, nal_ref_idc: 3
non-existing PPS 0 referenced
non-existing PPS 0 referenced
decode_slice_header error
non-existing PPS 0 referenced
non-existing PPS 0 referenced
non-existing PPS 0 referenced
no frame!
通过跟踪源码Probing h264 score:51 size:32768日志打印在调用
av_probe_input_format3函数会打印
name h264
long_name raw H.264 video
raw_codec_id 28
说明如果指定了AVInputFormat结构体，就可以节省探测码流格式的时间
ffmpeg 针对指定的h264 es流延时优化
参考http://blog.csdn.net/rain_2011_kai/article/details/7746805文章，
是否只需要知道发送端发送的视屏的解码器ID,视频帧的长和宽，就可以直接
直接省略掉ffmpeg库的视频流探测接口，avformat_open_input函数
和avformat_find_stream_info函数耗时超过500毫秒
手动指定解码格式 效果不明显
+buffer0x00000000002cbdc0 <字符串中的字符无效。>unsigned char *
+buf_end0x00000000002d3626 <字符串中的字符无效。>unsigned char *
30822
pos 262349
buffer 2932160
buf_end 2962982
buffsize 35840
buf_end-buffer 30822
pos的值从哪里来，值得考虑
pFormatContext->pb->pos = pFormatContext->pb->buf_end;
在已有的版本是编译不过的，因为pos是一个64位整型，buf_end是一个字符指针
但是从上面还是看不出它们之间的关系，尽管手动指定解码格式，但是效果并不理想
还有在这里读取一帧的数据
m_pVideoc->io_ctx = avio_alloc_context(m_pAvioBuf, BUF_SIZE, 0, this, ReadStreamData, NULL, NULL);
设置BUF_SIZE的大小为4*1024,实际上是否有效果，尚未可知
本文转自fengyuzaitu 51CTO博客，原文链接：http://blog.51cto.com/fengyuzaitu/1952406，如需转载请自行联系原作者
