ffmpeg里提取的h264解码器不能解有些.264文件

[tianma_25]

如题，，我下载的是vs2005的工程，测试了两个264文件，一个可以解，一个不能解，提示

Video decoding
[h264 @ 004DFD60]non existing PPS referenced
[h264 @ 004DFD60]decode_slice_header error
[h264 @ 004DFD60]no frame!
Error while decoding frame 0

这两个文件用VLC都能正常播放，请问是为什么？

[blackmash]

错误已经说明了啊。。。找不到当前slice需要的PPS。
有可能你用的VLC使用的FFmpeg库新，而你的比较旧；
还有可能写VLC的人本身对其ffmpeg库有做过一些fix呢？

[tianma_25]

[Quote=引用 1 楼 blackmash 的回复:]
错误已经说明了啊。。。找不到当前slice需要的PPS。
有可能你用的VLC使用的FFmpeg库新，而你的比较旧；
还有可能写VLC的人本身对其ffmpeg库有做过一些fix呢？
[/Quote]

那我该怎么办啊，这个里面都是源代码，没有用到lib或者dll之类的，我要一个能用的有源码的h264解码器，能给我推荐一个吗？
谢谢

[blackmash]

首先，你可以去ffmpeg官方网站，下载一个最新的ffmpeg
然后，用最新的ffmpeg播放看看，是否能解。
如果可以解，说明你vs2005工程里面的code比较旧，你需要更新一下。
如果还是不能解，哪说明vlc的人应该自己有做一些fix，你就没有办法了，除非你自己研究如何来fix

[GoogleGeek]

>> 我下载的是vs2005的工程，测试了两个264文件，一个可以解，一个不能解，提示

这说明你下载的工程有问题

请用gcc编译ffmpeg,而不要什么vs2005来编译，后者会导致非常多的问题。

总的来说H264的码流的打包方式有两种,一种为nnex-b byte stream format的格式，这个是绝大部分编码器的默认输出格式，就是每个帧的开头的3~4个字节是H264的start_code,0x00000001或者0x000001。
另一种是原始的NAL打包格式，就是开始的若干字节（1，2，4字节）是NAL的长度，而不是start_code,此时必须借助某个全局的数据来获得编码器的profile,level,PPS,SPS等信息才可以解码。

[GoogleGeek]

上面的回复少写了一个字母

>> 一种为nnex-b byte stream format的格式

应该是：
一种为annex-b byte stream format的格式

[tianma_25]

我是在http://bbs.chinavideo.org/viewthread.php?tid=4103&extra=page%3D1下载的工程，刚在svn上下了最新的ffmpeg，把同名的文件用刚下载的覆盖掉，这样在vs里已经编译不过了（一些头文件的目录变了），因为我只想在windows下用ffmpeg里的264解码部分解码文件生成.yuv文件，不用编译整个ffmpeg吧，我应该怎么弄啊？
指点指点我吧！

[GoogleGeek]

repeat again:

Please do not try to compile FFmpeg by Visual Studio

[GoogleGeek]

同时奉劝所有尝试所谓的从ffmpeg提取xxx 解码器的朋友：
别浪费您的宝贵时间从ffmpeg中提取某个解码器了，因为这是一个没有意义的事情。
你即使提取了，也不能用。并且你提取的解码器的速度会慢比ffmpeg官方编译版本慢很多。

[tianma_25]

[Quote=引用 7 楼 psusong 的回复:]
repeat again:

Please do not try to compile FFmpeg by Visual Studio
[/Quote]

那我这样可以吗，我用下载的FFmpeg的SDK再加上它提供的apiexample.c来解264文件。
请问这样做需要修改些什么东西？

[GoogleGeek]

理论上可以
但这要看你对ffmpeg理解的程度了。

你必须区分annex-b和non-annex-b这两种H264 bitstream format,因为解码器在解码过程中对这两种码流有些初始化环节不一样。

[kroody]

引用 10 楼 psusong 的回复:

同时奉劝所有尝试所谓的从ffmpeg提取xxx 解码器的朋友：
别浪费您的宝贵时间从ffmpeg中提取某个解码器了，因为这是一个没有意义的事情。
你即使提取了，也不能用。并且你提取的解码器的速度会慢比ffmpeg官方编译版本慢很多。

哥 你说的太对了 我虽然把那个提取的工程编译通过了 但是解码速度慢的跟牛一样
为啥呢 是因为官方代码编译过程中优化了么

0000000: 0000 0001 6742 801e da02 d0f4 4000 0000 ....gB......@...
0000010: 0168 ce3c 8000 0000 0165 b842 7262 8000 .h.<.....e.Brb..

这个264文件头表明为annex-b byte stream format的格式的吧

[GoogleGeek]

引用 11 楼 kroody 的回复:

哥 你说的太对了 我虽然把那个提取的工程编译通过了  但是解码速度慢的跟牛一样
为啥呢  是因为官方代码编译过程中优化了么

0000000: 0000 0001 6742 801e da02 d0f4 4000 0000  ....gB......@...
0000010: 0168 ce3c 8000 0000 0165 b842 7262 8000  .h. <.....e.Brb..

这个264文件头表明为annex-b byte stream format的格式的吧

这是因为很多人的所谓的提取的过程都是把C代码提取出来了，而汇编代码都禁止了，这样造成了至少50%的性能下降，因为gcc的inline汇编是AT&T格式，默认情况下是没法用MSVC编译的。即使通过某些途径将汇编代码编译链接到了MSVC的工程，还是有极大的风险的，因为FFmpeg很多优化代码都是假定函数的调用stack是16字节对齐的逻辑进行的（基于此假定可以生成一些优化的代码），GCC可以保证这一逻辑是正确的，而MSVC就不没法保证，因为MSVC的stack对齐一般是4字节对齐，你可以手动改变相应的对齐约定，但这个工作量比较大，我估计有几百个地方需要修改，但是即使你修改过来了，你的代码的编译结果还是比GCC的慢。
关于stack对齐的一些细节参见我的blog上的说明。

另外你给出的码流是annex-b byte stream format

[kroody]

引用 12 楼 psusong 的回复:

这是因为很多人的所谓的
华丽的省略中

另外你给出的码流是annex-b byte stream format

感谢大牛 我原来只是想到了 是不是 GCC 在编译中进行了某些inline函数或GCC扩展的优化 导致了二者在最终代码执行效率上的差别导致的 原来这里面这么多猫腻哇

另外我现在有个问题跟网上这个人问的一样

就是我现在annex-b byte stream format 的文件我可以用ffmpeg解码，那么我想一个机器用TCP 发送，另外一个机器接收并且解码怎么处理？是不是当开始接收的时候先找到 0000 0001就好比读文件的刚开始的那些字节一样 否则找不到PPS信息
另外 我google “annex-b byte stream format” 发现找不到这种格式描述 我想把这个文件头弄明白 我知道0000 0001是startcode
有什么好办法么？

大牛指教下吧

[FFmpeg-user] Annex B H.264 decoding with FFMPEG
Felipe Lalanne flalanne at gmail.com
Tue Feb 3 15:52:30 CET 2009

* Previous message: [FFmpeg-user] Vhooks does not work with latest FFMPEG code
* Next message: [FFmpeg-user] ffmpeg input from udp socket ??
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I have the following question, i haven't been able to find an answer
anywhere. I'm implementing a H.264 video tranmission application, the way it
works is very simple, I take a h.264 annex B file, divide it into the NAL
units according to the specification, and then send each NAL unit using UDP
over the network.

On the reception side, I want to receive the NAL units and start decoding
inmediatly (or as soon as posible) for playback, without necessarily saving
it into a file. I've been trying to do it using ffmpeg, and
avcodec_decode_video using a code similar to the one following the text.
This doesn't work, as I understand, because a nal unit usually doesn't
contain a whole frame (hence the [h264 @ 0x8055550]no frame! message)

The reason I'm doing it like this, and not using RTP is because I am doing
some H.264 and network protocol testing and need to have full control of the
way packets are sent or received.

I'm thinking of concatenating the received NAL units and try to parse the
union with av_parser_parse, before decoding the frame, but I'm not sure if
that would be most efficient solucion.
What do you think? Could anyone give me any suggestions?

Thank you all in advance.
Best regards
Felipe Lalanne


--- Code --

/* NAL Structure description */
typedef struct NAL {
int ref_idc;
int unit_type;
int slice_type;
unsigned char * buf;
int len;
} NALUnit;


int decode_video() {
AVCodec * codec = avcodec_find_decoder(CODEC_ID_H264);
if (!pCodec) {
return -1;
}

AVCodecContext * context = avcodec_alloc_context();
context->width = width;
context->height = height;

if (avcodec_open(context, codec) < 0) {;
return -1;
}

int frameFinished, len;

AVFrame * frame = avcodec_alloc_frame();
while (true) {
NAL * nal = receive_nal();

len = avcodec_decode_video(context, frame,
&frameFinished, nal->buf, nal->len);

if (frameFinished) {
display_frame(frame);
}
}
}

[songzhengwei]

牛人啊，太牛了

[gavial2011]

但是关键是要移植到vc上

[gavial2011]

所以必须要用msvc……

[gavial2011]

要不然怎么合到其他工程里

[dj0379]

要合到VC工程里有很多方法，不一定非要MSVC来编译，只要你使用的ffmpeg是Window对应版本的，通过配置和使用exe或者dll就能实现。

[dj0379]

要合到VC工程里有很多方法，不一定非要MSVC来编译，只要你使用的ffmpeg是Window对应版本的，通过配置和使用exe或者dll就能实现。