苏州建设网站市政中标项目,wordpress指定关键词自动内链,企业qq怎么申请,深圳软件外包公司排行榜田克平(94338047) 16:57:34能自己设置某帧为关键帧吗#xff1f; 抱柱者(86311414) 16:57:59to 田克平可以 田克平(94338047) 17:00:00呵呵#xff0c;把丢包后的下一帧设置为I帧可以吗#xff1f;来处理丢帧现象 ☆雪天/kf☆(279373002) 17:00:42这个难度大了 田克平(94338…田克平(94338047) 16:57:34能自己设置某帧为关键帧吗 抱柱者(86311414) 16:57:59to 田克平可以 田克平(94338047) 17:00:00呵呵把丢包后的下一帧设置为I帧可以吗来处理丢帧现象 ☆雪天/kf☆(279373002) 17:00:42这个难度大了 田克平(94338047) 17:01:15难度在哪 抱柱者(86311414) 17:01:53如果1to1那应该可行但是要是传到多点那可能比较麻烦 田克平(94338047) 17:03:54谢谢 抱柱者(86311414) 17:04:05比如传至A、B两点到A的丢包很少而到B丢包较多那A也要因为B点而经常接受关键帧 抱柱者(86311414) 17:04:29不过你也可以现象折中的方法 抱柱者(86311414) 17:04:38不过你也可以想想折中的方法 田克平(94338047) 17:04:48就1to1的话、、、 田克平(94338047) 17:05:11怎么做 抱柱者(86311414) 17:05:22就像你说的做啊 抱柱者(86311414) 17:05:50丢包了就通知编码端下一帧编为关键帧 田克平(94338047) 17:06:07好的谢谢 ☆雪天/kf☆(279373002) 17:06:16田克平(94338047) 17:00:00呵呵把丢包后的下一帧设置为I帧可以吗来处理丢帧现象
编码的时候你怎么会知道哪一帧会丢
☆雪天/kf☆(279373002) 17:07:55除非你有反馈通道 抱柱者(86311414) 17:08:58肯定是反馈啊正常可能是丢包了就通知编码端重发现在改为通知编码端设置关键帧 傻子更聪明(120928606) 17:09:43这样好象实时性比较差啊也难免不会再被丢。 呵呵(369873095) 17:10:11网络的来回时间考虑了吗RTT ☆雪天/kf☆(279373002) 17:10:15这样效率很低呀 ☆雪天/kf☆(279373002) 17:10:25你编码器一直要等在那里 抱柱者(86311414) 17:11:07他是设置下一帧为关键帧而不是处理丢了的那一帧所以实时性应该没有问题 田克平(94338047) 17:11:09丢包了不通知吗 ☆雪天/kf☆(279373002) 17:11:21两次传输路径时间解码器处理时间 编码器无法并行 ☆雪天/kf☆(279373002) 17:12:25就是说你反馈回来的时候 编码器已经编到后面去了 丢的哪一帧后面的一帧 早编完了 抱柱者(86311414) 17:12:57编码器为什么要等编码器就按正常的编码如果解码器反馈丢包了应用程序就修改编码参数设置关键帧与并行扯不上关系 田克平(94338047) 17:12:58好像是这样啊 傻子更聪明(120928606) 17:14:09网络UDP不可靠传输多少秒来一个关键帧比较合适 抱柱者(86311414) 17:14:16为什么要局限于下一帧下两帧也没关系啊 抱柱者(86311414) 17:14:35反正只是要尽快出现一个关键帧就行了 ☆雪天/kf☆(279373002) 17:15:13你说的没错 但是一个反馈的时间编码器可能已经编码了好多帧了 ☆雪天/kf☆(279373002) 17:15:56所以只能说是一接到反馈就立即置I帧 ☆雪天/kf☆(279373002) 17:22:06可以结合周期插入I帧一起来用 周期可以大一点田克平(94338047) 17:23:10关键帧间隔是定好的、、、 抱柱者(86311414) 17:23:15肯定是会有固定关键帧周期的 傻子更聪明(120928606) 17:23:48这种方法是在关键帧间隔比较大的情况下可以用。 田克平(94338047) 17:24:422s间隔有什么问题 傻子更聪明(120928606) 17:25:06而且非关键帧丢失后怎么处理会有花屏之类的。 傻子更聪明(120928606) 17:25:39把导致花屏的帧丢掉后图象会有停顿。 田克平(94338047) 17:25:52间隔很小的话当然是作用不大 ☆雪天/kf☆(279373002) 17:25:58那也没有办法 只能跳到下一个I帧 呵呵(369873095) 17:26:24在码率大的时候一帧的数据都是由几十个包承载的多个包里掉一个包几个包是否反馈要求I帧 ☆雪天/kf☆(279373002) 17:27:21那倒不用 使用EC足够应付了 傻子更聪明(120928606) 17:27:22网络传输应该不用I帧吧把I帧全变为IDR帧这样才有意义。 sunj(39310543) 17:28:42这个问题有rfc来定义的 傻子更聪明(120928606) 17:28:42错误掩藏解码器不支持的话怎么整。也需要编码器支持吧。 sunj(39310543) 17:28:52消息已经标准化了 ☆雪天/kf☆(279373002) 17:29:34简单的块copy就可以搞定这个了 不需要编码器做什么 傻子更聪明(120928606) 17:31:12这样子也是会引起连续的失真。。
☆雪天/kf☆(279373002) 17:22:06可以结合周期插入I帧一起来用 周期可以大一点田克平(94338047) 17:23:10关键帧间隔是定好的、、、 抱柱者(86311414) 17:23:15肯定是会有固定关键帧周期的 傻子更聪明(120928606) 17:23:48这种方法是在关键帧间隔比较大的情况下可以用。 田克平(94338047) 17:24:422s间隔有什么问题 傻子更聪明(120928606) 17:25:06而且非关键帧丢失后怎么处理会有花屏之类的。 傻子更聪明(120928606) 17:25:39把导致花屏的帧丢掉后图象会有停顿。 田克平(94338047) 17:25:52间隔很小的话当然是作用不大 ☆雪天/kf☆(279373002) 17:25:58那也没有办法 只能跳到下一个I帧 呵呵(369873095) 17:26:24在码率大的时候一帧的数据都是由几十个包承载的多个包里掉一个包几个包是否反馈要求I帧 ☆雪天/kf☆(279373002) 17:27:21那倒不用 使用EC足够应付了 傻子更聪明(120928606) 17:27:22网络传输应该不用I帧吧把I帧全变为IDR帧这样才有意义。 sunj(39310543) 17:28:42这个问题有rfc来定义的 傻子更聪明(120928606) 17:28:42错误掩藏解码器不支持的话怎么整。也需要编码器支持吧。 sunj(39310543) 17:28:52消息已经标准化了 ☆雪天/kf☆(279373002) 17:29:34简单的块copy就可以搞定这个了 不需要编码器做什么 傻子更聪明(120928606) 17:31:12这样子也是会引起连续的失真。。 main(){... while (decode_one_frame(img, input, snr) ! EOS);...}
然后在decode_one_frame()
{ ... currSlice-next_header -8888; ..... while ((currSlice-next_header ! EOS currSlice-next_header ! SOP)) { current_header read_new_slice(); if (current_header EOS) { exit_picture(); return EOS; } decode_slice(img, inp, current_header); ... } ... exit_picture(); return (SOP);}
按照上面的代码经过跟踪发现currSlice-next_header 一直不变那么decode_one_frame()中的while循环永远不会因为条件的不满足而跳出循环只会因为current_header EOS条件的满足而推出该函数。因此 decode_one_frame()函数只可能返回EOS而不会是SOP那么main()中的while循环将只会执行一次。而且在代码跟踪的过程中发现输入码流的所有序列是在decode_one_frame()函数中全部解出然后才推出该函数。请教各位jm为什么要这样呢还是我什么地方没注意到谢谢了
A:再次仔细跟踪了一下代码发现jm整个解码的结构是这样的1。在main中调用while (decode_one_frame(img, input, snr) ! EOS);但实际上这个while只会循环一次因为decode_one_frame只可能返回EOS下面讲为什么2。在decode_one_frame中通过调用 while ((currSlice-next_header ! EOS currSlice-next_header ! SOP)) { current_header read_new_slice(); if (current_header EOS) { exit_picture(); return EOS; } decode_slice(img, inp, current_header); ... }解码所有帧。如上所述currSlice-next_header根本没有起到任何作用因为没有其他地方为 其赋值为什么呢因为如果要想知道next_header必须要将下一个slice码流读进来再进行解析既然已经读进来不管判断的是一个新的pic还是同一个pic中的新的slice都必须立刻进行解码也就没有必要再回到main中的while循环了。实际上起作用的是current_header即通过read_new_slice()来获得sop or sos if(is_new_picture()) { init_picture(img, input); current_header SOP;//start of pic } else current_header SOS;//start of slice如果current_headersop那么将会调用init_picture()这个函数主要实现两个功能首先通过exit_picture把上一次解码的图像及相关信息进行保存等处理 然后再为当前slice新的一帧的解码做好准备。如果current_headersos那么将不会调用init_picture()直接利用当前pic的准备信息进行解码。如果在read_new_slice()中发现已经到码流的结尾了那么将返回EOS.
这时在decode_one_frame中一旦current_headerEOS那么将退出解码返回到main中来。值得注意的是返回之前它还是调用了exit_picture从而将最后一个解码帧进行保存。大概流程应该就是这样如果有漏掉或错误的地方还请高手补充指正。总之jm中的有些函数的内容并不一定与其函数名称相吻合这可能也是他们开发到后期没有办法的事情。不知道x264或其他的解码器是不是如此复杂
