我正在制作h264流分析器,并且在编写和阅读与MPEG-TS打包的同一帧时发现了奇怪的ffmpeg行为。
我已经在HEX中转储了编码和解码帧数据,并发现了以下区别:
在框架的开头,添加了NAL分隔符:
+ 00
+ 00
+ 00
+ 01
+ 09
+ f0在我看来是完全合法的。
但奇怪的事情来了:
如果当前数据包不是最后一个包,则添加一些后缀(即在最后的书面帧中没有此后缀)。并且这个后缀被添加到当前读取帧(即,这不是下一个帧的前缀)。
+ e0
+ 00
+ 00
+ 00
+ 01
+ ce
+ 8c
+ 4d
+ 9d
+ 10
+ 8e
+ 25
+ e9
+ fe(从添加e0字节开始)
我在试着理解这可能意味着什么。如果00000001是NAL头,则后面是禁止零位等于1的ce字节,这是绝对破坏的。
我使用的是ffmpeg github上一次与89092fafdde894c6ba4d4f8e3cd1cce0d68bfc22提交合并的叉子。
ffmpeg是用--disable-everything --enable-encoder=libopenh264 --enable-muxer=mpegts --enable-demuxer=mpegts --enable-protocol=file --enable-parser=h264 --enable-decoder=libopenh264 --enable-shared --disable-static --disable-programs --disable-doc --enable-libopenh264选项构建的。
发布于 2016-12-13 09:50:47
所以我发现了问题所在。
TL;DR:
pInputFormatContext->flags |= AVFMT_FLAG_KEEP_SIDE_DATA;就在avformat_open_input之后
解释:
我发现AVPacket在表演的时候被utils.c:1661宠坏了
av_packet_merge_side_data(pkt);更重要的是,我还发现了之前看到的其他数据的后续情况:
#define FF_MERGE_MARKER 0x8c4d9d108e25e9feULL用于av_packet_merge_side_data
Side在AVPacket中的数据类型是AV_PKT_DATA_MPEGTS_STREAM_ID (78),它只用于演示器和muxers,而不用于编解码器。
我对从文件中读取帧数据所用的av_read_frame注释感到困惑:
Return the next frame of a stream.
This function returns what is stored in the file, and does not validate
that what is there are valid frames for the decoder. It will split what is
stored in the file into frames and return one for each call. It will not
omit invalid data between valid frames so as to give the decoder the maximum
information possible for decoding.我完全不知道为什么streams标记在我使用过的两台PC上不同的地方,但是禁用将侧数据合并到数据包的数据中是起了作用的。
因此,我认为这是ffmpeg的文档问题,它向我保证“我将返回存储在文件中的内容”,而没有提到可以添加一些额外的数据。
https://stackoverflow.com/questions/40991412
复制相似问题