在 Silverlight 中无法搜索某些 H.264 视频中下载的数据

发布于 2024-10-12 07:24:06 字数 2523 浏览 4 评论 0原文

我目前正在进行的项目是使用基于 Silverlight 的播放器来流式传输通过 WME 编码的 wmv 视频。 然而,我们希望将来能够摆脱 Silverlight 并转向 HTML5 中的视频标签,因此我们需要在 mp4 容器中将视频编码为 H.264。

一切都很好,除了小问题之外,不可能超越已下载的内容,至少不能在较低质量的编码上进行搜索。 我们的测试文件之一是高清 wmv 视频,我们使用 FFmpeg 将其编码为 2 Mbit、1 Mbit 和 0.5 Mbit,并使用 mp4box 来重新排序 moov 原子。

在 2 Mbit 和 1 Mbit 编码中,Silverlight MediaElement 都会识别超出我们希望的下载内容的搜索,并请求视频数据并从搜索点开始播放。
然而,对于 0.5 Mbit 的视频,这种情况不会发生,而是在正常下载视频的同时视频冻结。

使用来自 Youtube 的低质量 H.264 视频可以,所以我不知道是 FFmpeg 的参数有问题还是其他原因。

这是编码命令行:

ffmpeg -y -i fooHD.wmv -an                               -vcodec libx264 -vpre slow -level 41 -b 2000k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 1 -f rawvideo nul
ffmpeg -y -i fooHD.wmv -acodec libfaac -ar 44100 -ab 96k -vcodec libx264 -vpre slow -level 41 -b 2000k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 2 bar2000k.mp4
ffmpeg -y -i fooHD.wmv -acodec libfaac -ar 44100 -ab 96k -vcodec libx264 -vpre slow -level 41 -b 1000k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 2 bar1000k.mp4
ffmpeg -y -i fooHD.wmv -acodec libfaac -ar 44100 -ab 96k -vcodec libx264 -vpre slow -level 41 -b 500k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 2 bar500k.mp4

mp4box.exe -inter bar2000k.mp4
mp4box.exe -inter bar1000k.mp4
mp4box.exe -inter bar500k.mp4

fooHD.wmv 长 2:17,运行速度为 8 Mbit/s @ 29.97 fps。

The project I'm currently working on is using a Silverlight based player to stream wmv videos encoded through WME.
However we want to be able to move away from Silverlight in the future and to the video tag in HTML5, so we need to encode our videos to H.264 in an mp4 container.

Everything is fine except for on small problem, it's not possible to seek beyond what has been downloaded, at least not on lower quality encodes.
One of our test files is an HD wmv video, which we encode down to 2 Mbit, 1 Mbit and 0.5 Mbit using FFmpeg, and mp4box to reorder the moov atoms.

In both the 2 and 1 Mbit encodes the Silverlight MediaElement recognizes a seek beyond what's downloaded as we'd like it to, and requests video data and starts playing from the seek point.
However, with the 0.5 Mbit video that doesn't happen, and instead the video freezes while it keeps downloading the video normally.

Using a low-quality H.264 video from Youtube works, so I don't know if it's the parameters to FFmpeg that's the problem or something else.

Here's the encoding command-line:

ffmpeg -y -i fooHD.wmv -an                               -vcodec libx264 -vpre slow -level 41 -b 2000k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 1 -f rawvideo nul
ffmpeg -y -i fooHD.wmv -acodec libfaac -ar 44100 -ab 96k -vcodec libx264 -vpre slow -level 41 -b 2000k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 2 bar2000k.mp4
ffmpeg -y -i fooHD.wmv -acodec libfaac -ar 44100 -ab 96k -vcodec libx264 -vpre slow -level 41 -b 1000k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 2 bar1000k.mp4
ffmpeg -y -i fooHD.wmv -acodec libfaac -ar 44100 -ab 96k -vcodec libx264 -vpre slow -level 41 -b 500k -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +dct8x8+bpyramid -me_method umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -threads 0 -pass 2 bar500k.mp4

mp4box.exe -inter bar2000k.mp4
mp4box.exe -inter bar1000k.mp4
mp4box.exe -inter bar500k.mp4

fooHD.wmv is 2:17 long and running at 8 Mbit/s @ 29.97 fps.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

煮茶煮酒煮时光 2024-10-19 07:24:06

我立即想到了与缺少关键帧相关的问题,但我看到所有编码设置都是 -g 250 。然而,基于过去的一些问题,编码器在低带宽下使用 I 帧设置变得快速和松散,我仍然建议读回 I 帧/关键帧统计信息,看看您的 500k 文件是否没有按照您要求的方式进行编码。

My throught immediately goes to an issue related to a lack of keyframes, but I see -g 250 for all your encoding settings. However based on some past issues with encoders getting fast and loose with I-frame settings at low bandwidth I still suggest reading back the I-frame/keyframe stats to see if your 500k file is not being encoded the way you asked.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文