NetStream.seek в миллисекундах - PullRequest
       12

NetStream.seek в миллисекундах

1 голос
/ 01 февраля 2011

У меня есть видео в кодировке H.264, ключевые кадры которого разнесены на 100 миллисекунд. Я заметил, что я не могу искать определенные ключевые кадры. После того, как я выполняю поиск, точка воспроизведения переходит к желаемому времени (времени ключевого кадра), а затем примерно на несколько миллисекунд вперед или назад. Мой вывод трассировки для NetStream.time выглядит как

ns.t: 2,86
ns.t: 2,86
ns.t: 2,86
[10:12:01 GMT + 0100] VideoPlayerNetStream: NetStatusEvent - NetStream.Seek.Netify time: ns.time = 2.86
[10:12:02 GMT + 0100] VideoPlayerNetStream: поиск.Notify info.seekPoint: не определено
ns.t: 2,76
ns.t: 2,76
ns.t: 2,76
ns.t: 2,76
ns.t: 2,8
ns.t: 2,8

Я ищу 2,76 (то есть 2 секунды и 76 миллисекунд). Как вы можете видеть, он ищет нужный ключевой кадр (ключевой кадр на 2,76), но затем он переходит на 2,8. Это вызывает много проблем при переходе кадра назад. Странно то, что он работает для некоторых ключевых кадров и просто не работает для некоторых. Может ли быть проблема с видео? Есть ли способ проверить правильность кодирования видео? Поиск в Google показал, что у людей возникают проблемы с поиском не ключевых кадров. Но здесь я пытаюсь найти ключевые кадры. приложение работает для видео, у которых есть ключевые кадры, которые разделены секундами. Проблема возникла, когда видео было закодировано по-другому, чтобы получить функцию миллисекунд.

Я уже давно борюсь с этой проблемой и был бы признателен, если бы я получил какие-либо подсказки / указатели в правильном направлении для ее решения.

Привет
Врушали

1 Ответ

2 голосов
/ 01 февраля 2011

как указано в справке:

Свойство playheadTime может не иметь ожидаемого значения сразу после вызова одного из методов seek или установки playheadTime, чтобы вызвать поиск. Для прогрессивной загрузки вы можете искать только ключевой кадр; поэтому поиск приводит вас ко времени первого ключевого кадра после указанного времени.

[...]

Поиск является асинхронным , поэтому, если вы вызываете метод поиска или устанавливаете свойство playheadTime, playheadTime не обновляется немедленно . Чтобы получить время после завершения поиска, прослушивает событие поиска , которое не начинается, пока не будет обновлено свойство playheadTime.

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fl/video/VideoPlayer.html#seek()

так что http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fl/video/VideoEvent.html#SEEKED отправляется (предполагается), когда точка воспроизведения фактически достигает ключевого кадра.

другими словами, наличие нескольких ключевых кадров делает методы поиска неточными. Примечание: это не так для потокового видео, когда для точки воспроизведения всегда сразу устанавливается правильное время / ключевой кадр.

если у вас включены ключевые точки, решение состоит в том, чтобы «закрепить» важные кадры видео и использовать seekToNavCuePoint (), seekToNextNavCuePoint () и seekToPrevNavCuePoint () насколько я помню, они были более острыми.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...