Как сгенерировать временные метки образца в фильтре источника RTSP? - PullRequest
0 голосов
/ 24 октября 2011

На самом деле, я уже могу генерировать временные метки, и это работает с некоторыми фильтрами (мультиплексорами), но, поскольку я хочу иметь возможность использовать GDCL MP4 Multiplexer Filter, я хочу обсудить мой метод расчета значений времени выборки.

Странная вещь, если я поставлю Smart Tee Filter между моими RTSP Source Filter и GDCL MP4 Multiplexer Filter, кажется, что все работает.Я могу правильно захватывать видеопотоки.Но без Smart Tee Filter я все еще могу снимать видео, но на этот раз с периодическими сбоями.Насколько я знаю, Smart Tee Filter ничего не делает, за исключением того, что дает двойные выходные выводы, один с временными метками (вывод захвата) и один без временных меток (вывод предварительного просмотра), и оба вывода совместно используют один и тот же буфер потока.Итак, мне пришло в голову, что как-то Smart Tee Filter реорганизует такие вещи, как метки времени.Но если я не генерирую метки времени, Smart Tee Filter тоже не генерирует эти значения.Мое текущее предположение состоит в том, что я правильно рассчитываю время начала кадра, но время остановки кадра неправильно, и Smart Tee Filter пересчитывает время остановки кадра, как и должно быть (это всего лишь предположение, конечно).

Я привык крассчитайте время начала и окончания, как показано ниже.

startTime = now
timeDelta = now - previousFrame
endTime = startTime + timeDelta

Это не точная формула, но она была близка.И результаты были такими, как показано ниже.

Media Time/Time: 0-1    0-0
Media Time/Time: 1-2    500028-1000056
Media Time/Time: 2-3    930053-1360078
Media Time/Time: 3-4    1610092-2290131
Media Time/Time: 4-5    2200126-2790160
Media Time/Time: 5-6    2900166-3600206
Media Time/Time: 6-7    3500200-4100234
Media Time/Time: 7-8    4240242-4980284
Media Time/Time: 8-9    4720270-5200298
Media Time/Time: 9-10   5350306-5980342
Media Time/Time: 10-11  5980342-6610378
Media Time/Time: 11-12  6610378-7240414
Media Time/Time: 12-13  7250414-7890450
Media Time/Time: 13-14  7880450-8510486
Media Time/Time: 14-15  8510486-9140522
Media Time/Time: 15-16  9140522-9770558
Media Time/Time: 16-17  9780559-10420596
Media Time/Time: 17-18  10410595-11040631
Media Time/Time: 18-19  11040631-11670667
Media Time/Time: 19-20  11680668-12320705
Media Time/Time: 20-21  12310704-12940740
Media Time/Time: 21-22  12940740-13570776
Media Time/Time: 22-23  13600778-14260816
Media Time/Time: 23-24  14220813-14840848
Media Time/Time: 24-25  14840849-15460885
Media Time/Time: 25-26  15480885-16120921
Media Time/Time: 26-27  16110921-16740957
Media Time/Time: 27-28  16740957-17370993
Media Time/Time: 28-29  17380994-18021031
Media Time/Time: 29-30  18011030-18641066
Media Time/Time: 30-31  18631065-19251100

Это значения времени и времени мультимедиа (оба в формате start-stop), которые устанавливаются методами SetMediaTime () и SetTime ().Проблема, которую я видел, состояла в том, что некоторые времена начала / окончания перекрывались в последовательных кадрах.Конечно, это вызвано факторами дрожания и т. Д. Если я вычисляю дельту времени в зависимости от предыдущего кадра и если следующий кадр прибывает раньше, чем ожидалось, происходит наложение.Итак, я сделал небольшое изменение в своем коде.мой окончательный код подобен приведенному ниже.

        _FILETIME fileTime;
        GetSystemTimeAsFileTime(&fileTime);
        now = ((((__int64)fileTime.dwHighDateTime << 32) + fileTime.dwLowDateTime) - streamReader->rtpProtocolHandler->m_iReferenceTime);
        timeDelta = now - m_iFrameTimePrevious;
        m_iFrameTime = max(now, m_iFrameTime);
        m_iFrameTimePrevious = m_iFrameTime;
        REFERENCE_TIME rtStart = m_iFrameTime;
        REFERENCE_TIME rtStop;
        if(timeDelta > 0) {
            m_iFrameTime += timeDelta;
            rtStop = m_iFrameTime;
        } else {
            rtStop = rtStart;
        }
        pSample->SetTime(&rtStart, &rtStop);
        pSample->SetMediaTime(&m_iMediaTime, &(++m_iMediaTime));

И результаты примерно такие:

Media Time/Time: 0-1 0-0
Media Time/Time: 1-2 470027-940054
Media Time/Time: 2-3 940054-1380079
Media Time/Time: 3-4 1580091-2220128
Media Time/Time: 4-5 2220128-2810161
Media Time/Time: 5-6 2870164-3520200
Media Time/Time: 6-7 3520200-4110234
Media Time/Time: 7-8 4170239-4820278
Media Time/Time: 8-9 4820278-5420312
Media Time/Time: 9-10 5470313-6120348
Media Time/Time: 10-11 6120348-6720382
Media Time/Time: 11-12 6770387-7420426
Media Time/Time: 12-13 7420426-8060463
Media Time/Time: 13-14 8060463-8630494
Media Time/Time: 14-15 8630494-9140521
Media Time/Time: 15-16 9260530-9890566
Media Time/Time: 16-17 9890566-10490600
Media Time/Time: 17-18 10560604-11230642
Media Time/Time: 18-19 11230642-11840677
Media Time/Time: 19-20 11860679-12490716
Media Time/Time: 20-21 12490716-13090750
Media Time/Time: 21-22 13170754-13850792
Media Time/Time: 22-23 13850792-14450826
Media Time/Time: 23-24 14460827-15070862
Media Time/Time: 24-25 15070862-15680897
Media Time/Time: 25-26 15760902-16450942
Media Time/Time: 26-27 16450942-17060977
Media Time/Time: 27-28 17100978-17751014
Media Time/Time: 28-29 17751014-18171038
Media Time/Time: 29-30 18171040-18591066
Media Time/Time: 30-31 18771074-19371108

На этот раз нет совпадений, но все глюки остаются.что я делаю не так?

Пожалуйста, помните, что мой фильтр исходного кода работает с другими мультиплексорами mp4, а также с GDCL MP4 Muxer, если я помещаю фильтр Smart Tee в середину.

Ответы [ 2 ]

1 голос
/ 25 октября 2011

При использовании RTSP / RTP / RTCP я бы рекомендовал использовать временные метки RTP для времени представления образца (смещение на ноль).

Как вы можете быть уверены, что каждый кадр точно одинаковой продолжительности? По моему опыту, такого никогда не было, будь то использование живых источников или файловых носителей. Ваш вариант использования может, конечно, отличаться.

Кроме того, вычисляя временные метки, вы не можете синхронизировать несколько потоков RTP, например, аудио и видео. Это одна из причин получения отчетов об отправителях RTCP.

0 голосов
/ 25 октября 2011

Проблема была вызвана не временными метками, а какой-то повреждением буфера. Фильтр Smart Tee решал проблему, возможно, удаляя недопустимые кадры или предоставляя очередь кадров, отсутствующую в моем исходном фильтре. Когда я изменил свой глючный общий буфер с правильным механизмом очереди, все стало работать правильно.

Спасибо Герайнту Дэвису за его огромную поддержку и его инструменты отладки для решения моей проблемы.

...