PMW-EX1摄影机

XDCAM为sony在2003年所推出的无影带式专业录影系统。2003年10月开始发售SD系统商品，2006年4月开始发售HD系统。 XDCAM的首两代XDCAM及XDCAM HD，使用Professional Disc作储存媒体，媒体和Blu-ray Disc相似及同样可储存23 GB（PFD23，单面）或50 GB（PFD50，双面）数据。第三代XDCAM EX，使用固态SxS记忆卡。在2008年，JVC宣布和Sony结盟支援XDCAM EX格式。 XDCAM产品范围包括了摄影机和录影机，作为突发取代传统录影机的格式，容许XDCAM光碟可以应用在传统影带式的工作流程。其录影机亦可作为随机存取磁盘机，以IEEE 1394及以太网等途径容易汇入录像到非线性编辑系统。所以与过去使用影带的录影机系统比起来，进行非线性编辑更容易。 一.压缩方式XDCAM格式使用数种不同的压缩方式和储存格式。虽然DVCAM及IMX独立型号有提供，很多标清XDCAM摄影机可简易切换IMX至DVCAM等格式。 IMX (MPEG IMX)IMX容许录影标清视讯，使用MPEG-2编码，位元率达30、40或50 Mbit/s。 MPEG IMX不使用暂时压缩，这可适合作剪接格式。50 Mbit/s的品质在视觉上可和Digital Betacam比较，及常作电视制作用途，主要是电子新闻采集，因在实际上色彩分辨率（DigiBeta的10位元对IMX的8位元）和更低压缩比比Digital Betcam更好 DVCAM (DV25)DVCAM使用标准DV编码，位元率高达25 Mbit/s，相容于大部分DV剪接系统。 XDCAM HD (XDCAM HD420, MPEG HD420)XDCAM HD支援多种品质模式。HQ模式位元率可达35 Mbit/s，使用可变动位元率 (VBR) MPEG-2长GOP式压缩。可选的18 Mbit/s (VBR) 及25 Mbit/s (CBR)模式可增加录影时间，相对地减少视讯品质。 XDCAM HD422 (MPEG HD422)第三代XDCAM使用4:2:2抽样的MPEG-2编码，比以往的格式有双倍色度分辨率。为可容纳更细致的色度，最大位元率增加至50 Mbit/s。 2008年后期，Sony推出了PDW-700摄影机及PDW-HD1500半体积录影机。同时，Sony亦藉着免费固件升级，扩展XDCAM HD422支援至PDW-U1录影机。 XDCAM EXXDCAM EX索尼公司于2007年11月发布了XDCAM EX标准和PMW-EX1摄影机。该标准使用同XDCAM相似的编码格式，只是存储介质换成了SxS内存卡。该标准能够以25Mbit/s的固定码率存储标清格式（1440x1080）或以35 Mbit/s的浮动码率存储高清格式（1920x1080）的视频。相比于XDCAM标准的MXF文件格式，已编码的视频存储为MP4格式。两个标准在封装文件上规格的不同意味着在XDCAM EX格式发布之初，既存编辑软件对于XDCAM HD的编解码器无法处理XDCAM EX的编码。使用SxS内存卡时，由于文件系统为FAT32格式，单条长视频编码后会被分割成一系列不超过4GB（更确切的说，3.49GB）的文件（折合约13分钟的高清或约19分钟的标清素材）。 PMW-EX1摄影机搭载3块1/2英寸、分辨率超过两百万像素、代号“Exmor”的CMOS传感器。该机型在全美广播工作者协会（NAB）2007年展会上首次展出。该机在使用SxS固态存储内存卡时，使用4:2:0 MPEG-2 Long-GOP编码，但是其内部色度抽样实为4:2:2，并且可以在HD-SDI接口上实现4:2:2抽样的输出。XDCAM EX1被索尼定位为CineAlta系列（索尼的高清电影摄像机系列）产品的一款设备，它提供丰富的帧数模式，可以实现从60帧/秒（在1080p模式下30帧/秒）到间隔拍摄。 在2008年4月，索尼在XDCAM EX产品线推出了一款新的可更换镜头的摄影机，PMW-EX3。EX3在内部设计上和EX1并无二致，在外观上改用了肩托支撑设计（也许可以理解为向佳能XL系列的外型致敬？），并增加了可选外挂硬盘系统。相应的，售价相对于EX1大幅度提升。视频流中的DTSPTS到底是什么? DTS（解码时间戳）和PTS（显示时间戳）分别是解码器进行解码和显示帧时相对于SCR（系统参考）的时间戳。SCR可以理解为解码器应该开始从磁盘读取数据时的时间。mpeg文件中的每一个包都有一个SCR时间戳并且这个时间戳就是读取这个数据包时的系统时间。通常情况下，解码器会在它开始读取mpeg流时启动系统时钟（系统时钟的初始值是第一个数据包的SCR值，通常为0但也可以不从0开始）。DTS 时间戳决定了解码器在SCR时间等于DTS时间时进行解码，PTS时间戳也是类似的。通常，DTS/PTS时间戳指示的是晚于音视频包中的SCR的一个时 间。例如，如果一个视频数据包的SCR是100ms（意味着此包是播放100ms以后从磁盘中读取的），那么DTS/PTS值就差不多是200 /280ms，表明当SCR到200ms时这个视频数据应该被解码并在80ms以后被显示出来（视频数据在一个buffer中一直保存到开始解码）下 溢通常发生在设置的视频数据流相关mux率太高。如果mux率是1000000bits/sec（意味着解码器要以1000000bits/sec的速率 读取文件），可是视频速率是2000000bits/sec（意味着需要以2000000bits/sec的速率显示视频数据），从磁盘中读取视频数据时 速度不够快以至于1秒钟内不能够读取足够的视频数据。这种情况下DTS/PTS时间戳就会指示视频在从硬盘中读出来之前进行解码或显示（DTS/PTS时间戳就要比包含它们的数据包中的SCR时间要早了）。如今依靠解码器，这基本已经不是什么问题了（尽管MPEG文件因为应该没有下溢而并不完全符合MPEG标准）。一些解码器（很多著名的基于PC的播放器）尽可能快的读取文件以便显示视频，可以的话直接忽略SCR。注意在你提供的列表中，平均的视频流速率为3Mbps（3000000bits/sec）但是它的峰值达到了14Mbps（相当大，DVD限制在 9.8Mbps内）。这意味着mux率需要调整足够大以处理14Mbps的部分， bbMPEG计算出来的mux率有时候太低而导致下溢。你计划让视频流速率这么高么？这已经超过了DVD的说明了，而且很可能在大多数独立播放其中都不能播放。如果你不是这么计划，我会从1增加mquant的值并且在视频设置中将最大码流设置为9Mbps以保持一个小一点的码流。如果你确实想让视频码率那么高，你需要增大mux率。从提供的列表可以得出bbMPEG使用14706800bits/sec或者1838350bytes /sec的mux率（总数据速率为：1838350bytes/sec（14706800bits/sec）行）。你在强制mux率字段设置的值应该是以 bytes/sec为单位并被50整除。所以我会从36767（1838350/50）开始，一直增加直到不会再出现下溢错误为止音视频同步原理ffmpeg ffmpeg对视频文件进行解码的大致流程1. 注册所有容器格式和CODEC: av_register_all()2. 打开文件: av_open_input_file()3. 从文件中提取流信息: av_find_stream_info()4. 穷举所有的流，查找其中种类为CODEC_TYPE_VIDEO5. 查找对应的解码器: avcodec_find_decoder()6. 打开编解码器: avcodec_open()7. 为解码帧分配内存: avcodec_alloc_frame()8. 不停地从码流中提取中帧数据: av_read_frame()9. 判断帧的类型，对于视频帧调用: avcodec_decode_video()10. 解码完后，释放解码器: avcodec_close()11. 关闭输入文件:av_close_input_file()output_example.c 中AV同步的代码如下(我的代码有些修改)，这个实现相当简单，不过挺说明问题。阅读前希望大家先了解一下时间戳的概念。/* compute current audio and video time */if (pOutputVars-pOutAudio_st)/存在音频流pOutputVars-audio_pts = (double)pOutputVars-pOutAudio_st-pts.val* pOutputVars-pOutAudio_st-time_base.num / pOutputVars- pOutAudio_st-time_base.den; /(pts是时间戳结构)输出音频的时间戳, 转换为基准时间elsepOutputVars-audio_pts = 0.0;if (pOutputVars-pOutVideo_st)pOutputVars-video_pts = (double)pOutputVars-pOutVideo_st-pts.val * pOutputVars-pOutVideo_st-time_base.num / pOutputVars- pOutVideo_st-time_base.den;/输出视频时间戳elsepOutputVars-video_pts = 0.0;if (!pOutputVars-pOutAudio_st & !pOutputVars-pOutVideo_st)return 0;/* write interleaved audio and video frames */if (!pOutputVars-pOutVideo_st | (pOutputVars-pOutVideo_st & pOutputVars-pOutAudio_st & pOutputVars-audio_pts video_pts) write_audio_frame(pOutputVars-pOutFormatCtx, pOutputVars-pOutAudio_st, pInputAudioBuf); /没有视频流，或者音频流时间没赶上视频流（通过比较时间戳), 则输出（编码输出）音频祯数据 else write_video_frame(pOutputVars-pOutFormatCtx, pOutputVars-pOutVideo_st, pInputVedioFrame);/否则输出视频祯数据输出数据的时间戳怎么得到的, 以音频为例: pkt.size= avcodec_encode_audio(c, audio_outbuf, audio_outbuf_size, pInputAudioBuf);/源数据应该包含时间戳, pInputAudio是源文件解码后的音频数据 pkt.pts= av_rescale_q(c-coded_frame-pts, c-time_base, st-time_base);/编码后的祯也含有源文件的时间戳，这个函数应该是转换同时间基准，没研究过 pkt.flags |= PKT_FLAG_KEY; pkt.stream_index= st-index; pkt.data= audio_outbuf;.应该就是这么个过程了，然后用av_write_frame(oc, &pkt), 把音频祯和视频祯交错写入到输出文件. 通过上面分析，可以看到，有时候可能连续写几个音频祯或视频祯. 播放时的同步可能ffplay中有，还没细看音视频同步-时间戳 媒体内容在播放时，最令人头痛的就是音视频不同步。从技术上来说，解决音视频同步问题的最佳方案就是时间戳：首先选择一个参考时钟（要求参考时钟上的时间是线性递增的）；生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳（一般包括开始时间和结束时间）；在播放时，读取数据块上的时间戳，同时参考当前参考时钟上的时间来安排播放（如果数据块的开始时间大于当前参考时钟上的时间，则不急于播放该数据块，直到参考时钟达到数据块的开始时间；如果数据块的开始时间小于当前参考时钟上的时间，则“尽快”播放这块数据或者索性将这块数据“丢弃”，以使播放进度追上参考时钟）。 可见，避免音视频不同步现象有两个关键一是在生成数据流时要打上正确的时间戳。如果数据块上打的时间戳本身就有问题，那么播放时再怎么调整也于事无补。假如，视频流内容是从0s开始的，假设10s时有人开始说话，要求配上音频流，那么音频流的起始时间应该是10s，如果时间戳从0s或其它时间开始打，则这个混合的音视频流在时间同步上本身就出了问题。打时间戳时，视频流和音频流都是参考参考时钟的时间，而数据流之间不会发生参考关系；也就是说，视频流和音频流是通过一个中立的第三方（也就是参考时钟）来实现同步的。第二个关键的地方，就是在播放时基于时间戳对数据流的控制，也就是对数据块早到或晚到采取不同的处理方法。图2.8中，参考时钟时间在0-10s内播放视频流内容过程中，即使收到了音频流数据块也不能立即播放它，而必须等到参考时钟的时间达到10s之后才可以，否则就会引起音视频不同步问题。 基于时间戳的播放过程中，仅仅对早到的或晚到的数据块进行等待或快速处理，有时候是不够的。如果想要更加主动并且有效地调节播放性能，需要引入一个反馈机制，也就是要将当前数据流速度太快或太慢的状态反馈给“源”，让源去放慢或加快数据流的速度。熟悉DirectShow的读者一定知道，DirectSh