EE4中的关键帧间隔 [英] Key Frame Interval in EE4

查看:82
本文介绍了EE4中的关键帧间隔的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用EE4 Pro ver 4.0.1639.0将源文件编码为IIS平滑流格式。我需要使用四种不同的关键帧间隔大小对文件进行编码。以下是我将文件编码为的两种分辨率

I am using EE4 Pro ver 4.0.1639.0 to encode a source file into IIS smooth streaming format. I need to encode the files with four different key frame interval sizes. Below are the two resolutions that i am encoding the files into

352 x 576 

352 x 576 

720 x 480

720 x 480

这两个文件都是用H.264Baseline视频编解码器编码的。我可以用2秒,5秒和10秒的持续时间成功编码。 Eventhouh当我把关键帧间隔设置为15秒时,在.ismc文件中看到的结果块持续时间仅为10秒,并且不超过

Both the files are encoded with H.264Baseline video codec. I can successfully encode with 2 sec, 5 sec and 10 sec durations. Eventhouh when i put the key frame interval to 15 sec, the resulting chunk duration as seen in .ismc file is only 10 sec and is not going beyond that.

当下我改变了分辨率和视频编解码器,我可以使用15秒的关键帧间隔。我使用CIF分辨率与VC1A进行验证,我可以生成15秒的块持续时间,如.ismc文件中所示

The moment i change the resolution and the video codec I am able to use a key frame interval of 15sec. I used CIF resolution with VC1A for verifying this and i was able to generate a chunk duration of 15 sec as seen in .ismc file

 

请帮助我了解问题所在?这是H.264编码的问题还是其他问题?

Kindly help me understand where the problem is? Is this an issue with H.264 encoding or is it something else?

问候

Venugopal G

Venugopal G

推荐答案

平滑流媒体的默认和推荐关键帧间隔为2秒。

The default and reccommended keyframe interval for smooth streaming is two seconds.

流畅的流媒体传送方式可以调整请求的比特率在Keyframe /"chunk:  interval。  在回放开始时和搜索之后,第一个"块"块被放置。所请求的通常是最低比特率,并且取决于
,该"块"的速度有多快。由网络提供(以及客户端可以提供该比特率的程度)将确定为后续"块"请求的比特率。 当播放继续时,客户端播放器中的hueristics监视
网络状况和客户端处理器负载并调整所请求的比特率。 

The smooth streaming delivery method makes adjustments to the requested bitrate at Keyframe / "chunk: intervals.   At the start of playback and after a seek, the first "chunk" requested will typically be at the lowest bitrate and depending on how quickly that "chunk" is delivered by the network (and how well the client can rendered that bitrate) will determine the bitrate requested for subsequent "chunks".  As playback continues hueristics in the client player monitor network conditions and client processor load and make adjustments to the requested bitrate. 

将关键帧间隔设置为fifeteen秒将导致内容播放以最低比特率开始播放15秒,然后向上调整到更高质量的比特率。                     间隔将调整得更慢,可能导致"缓冲"。 这将导致不太均衡的播放体验。

Setting the keyframe interval to fifeteen seconds will result in the content playing starting playback at the lowest bitrate for fifteen seconds before adjusting upward to a higher quality bitrate.  If network conditions change during playback, the longer "chunk" intervals will adjust more slowly, possibly resulting in "buffering".  This will result is a less even playback experience.

BTW我已经确认VC-1编解码器将愉快地生成三十秒"块"。并且H.264编解码器确实产生了十秒的"块"。当第三十二个"块"时请求。 我已经创建了一个工作项来调查在这种情况下为什么没有生成警告消息

BTW I've verified that the VC-1 codec  will happily generate thirty second "chunks" and that the H.264 codec does generated ten second "chunks" when thirty second "chunks" are requested.  I've created a work item to investigate why no warning message is generated in this case.


这篇关于EE4中的关键帧间隔的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆