У меня есть transform filter (написан без использования базовых классов CTrans...., а на обычных CBase...).
Почему-то глючит с видео рендерами (как с VMR7, так и с VMR9)

Падает в DecideBufferSize, а точнее в DecideAllocator, если коннект идет на UYVY формате

hr = DecideBufferSize(*ppAlloc, &prop);
if (SUCCEEDED(hr))
{
hr = pPin->NotifyAllocator(*ppAlloc, FALSE); //Возвращает E_FAIL.
if (SUCCEEDED(hr))
{
return NOERROR;
}
}

Т.е. входной пин рендерера не принимает мои проперти. (cbAlign = 1, cBuffers = 2, cbBuffer считается правильно)

Если коннект идет на RGB32 формате, то все проходит замечательно, но картинка получается перевернутой . Я знаю о том, что положительное значение высоты означает bottom-top картинку. Результат никак не изменяется от того, что я меняю знак высоты.

Если я конекчусь не к рендереру, а скажем к MPEG2 encoder, то результирующий файл записывается прекрасно, как и должен был бы в любом формате (RGB32, UYVY)

Есть еще одна фигня, которую я заметил при коннекте на UYVY формате — в GetMediaType я возвращаю размер 720х576, а в CheckMediaType мне приходит предложение о типе 1024х-576. Если я соглашаюсь на данный тип, то коннект проходит на ура, но результат естественно получается малость сказать смещенный.

Стандартный DV decoder прекрасно проигрывает файл в формате YUY2 на VMR7,9

Кто-нибудь сталкивался с такими явлениями когда-нибудь?

При дальнейших исследованиях обнаружилось, что проблема проявляется только если:
1. subtype = MEDIASUBTYPE_UYVY
2. format = FORMAT_VideoInfo2

??????


"Romul" <18524@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:1178081@news.rsdn.ru...
From: Romul

У меня есть transform filter (написан без использования базовых классов CTrans...., а на обычных CBase...).
Почему-то глючит с видео рендерами (как с VMR7, так и с VMR9)

Падает в DecideBufferSize, а точнее в DecideAllocator, если коннект идет на UYVY формате

hr = DecideBufferSize(*ppAlloc, &prop);
if (SUCCEEDED(hr))
{
hr = pPin->NotifyAllocator(*ppAlloc, FALSE); //Возвращает E_FAIL.
if (SUCCEEDED(hr))
{
return NOERROR;
}
}

Т.е. входной пин рендерера не принимает мои проперти. (cbAlign = 1, cBuffers = 2, cbBuffer считается правильно)

Если коннект идет на RGB32 формате, то все проходит замечательно, но картинка получается перевернутой . Я знаю о том, что положительное значение высоты означает bottom-top картинку. Результат никак не изменяется от того, что я меняю знак высоты.

Если я конекчусь не к рендереру, а скажем к MPEG2 encoder, то результирующий файл записывается прекрасно, как и должен был бы в любом формате (RGB32, UYVY)

Есть еще одна фигня, которую я заметил при коннекте на UYVY формате — в GetMediaType я возвращаю размер 720х576, а в CheckMediaType мне приходит предложение о типе 1024х-576. Если я соглашаюсь на данный тип, то коннект проходит на ура, но результат естественно получается малость сказать смещенный.

Стандартный DV decoder прекрасно проигрывает файл в формате YUY2 на VMR7,9

Кто-нибудь сталкивался с такими явлениями когда-нибудь?
Posted via RSDN NNTP Server 1.9
проблема с videomixingrenderer Оценить

Здравствуйте, Romul, Вы писали:

R>При дальнейших исследованиях обнаружилось, что проблема проявляется только если:
R>1. subtype = MEDIASUBTYPE_UYVY
R>2. format = FORMAT_VideoInfo2

R>??????

Знакомо, знакомо...

VMR использует т.н. Dynamic Format Changes. Иными словами, то как ты к нему присоедеился на этапе сборки графа ещё ни о чём не говорит. VMR может взять и поменять формат прямо при воспроиведении. Обычно это происходит на первом-же видео-сэмпле. Чаще всего изменяется знак высоты битмапа (т.е. флаг перевёрнутости) или ширина (точнее выравнивание) битмапа.

Подробности здесь, второй случай.

Romul wrote:
>
> Есть еще одна фигня, которую я заметил при коннекте на UYVY формате — в
> GetMediaType я возвращаю размер 720х576, а в CheckMediaType мне приходит
> предложение о типе 1024х-576. Если я соглашаюсь на данный тип, то
> коннект проходит на ура, но результат естественно получается малость
> сказать смещенный.
>

//
// m_Stride is the distance between in bytes between a pel on the
// screen and the pel directly underneath it.
//

m_Stride = ((pbmiHeader->biWidth * pbmiHeader->biBitCount) + 7) / 8;

m_Stride = (m_Stride + 3) & ~3;

//
// m_Offset is the distance in bytes from the top corner of the
// target bitmap to the top corner of the video image. When we are //
using DIBs this value allways be zero.
//
// When we are using DCI/DirectDraw this value will only be zero if
// we are drawing the video image at the top left hand corner of the
// display.
//

m_Offset = (((prcTarget->left * pbmiHeader->biBitCount) + 7) / 8) +
(prcTarget->top * m_Stride);


pbmiHeader, prcTarget указывают на соотвествующие структуры в MediaType
который предлагает рендерер (1024х-576).

Копируем так:

pOutputSample->GetBuffer(&pBuffer);

pDst = pBuffer + m_Offset;

for(row = 0; row < Height; row++){
memcpy(pDst, pSrc, Width);
pDst += m_Stride
pSrc += ...;
}

В результате картинка будет без смещений.

В Transform() или там где вызываем
m_pOutput->GetDeliveryBuffer(&pOutputSample) вствляем код вида

if(pOutputSample->GetMediaType(&mt)){
// renderer tries to change output media type
перепроверить mt
пересчитать m_Stride и m_Offset
}

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>Подробности здесь, второй случай.

биг сенкс

Здравствуйте, j.smith, Вы писали:

JS>Romul wrote:
>>
>> Есть еще одна фигня, которую я заметил при коннекте на UYVY формате — в
>> GetMediaType я возвращаю размер 720х576, а в CheckMediaType мне приходит
>> предложение о типе 1024х-576. Если я соглашаюсь на данный тип, то
>> коннект проходит на ура, но результат естественно получается малость
>> сказать смещенный.
>>

.........
JS>for(row = 0; row < Height; row++){
JS> memcpy(pDst, pSrc, Width);
JS> pDst += m_Stride
JS> pSrc += ...;
JS>}

JS>В результате картинка будет без смещений.


Насколько я понял картинка будет без смещений, но будет располагаться по середине окна?

Здравствуйте, Romul, Вы писали:

R>Насколько я понял картинка будет без смещений, но будет располагаться по середине окна?

Нет. Строки в битмапе выровнены, как праивло на 4 байта. Это значит что каждая следующая строка начинается не сразу за концом предыдущей, а чперез некоторый интервал, определяемый выравниванием.

В случае с VMR ещё хитрее. Например ты заказал кадр размером 320х240. По каким-то одному ему ведомым причинам (обычно это связано с железом видеоадаптера) VMR выделяет память скажем 324х240. На экране всё равно будет отображаться картинка реального размера 320х240, но класть в память данные ты должен строками по 342 пикселя. Что будет в "хвостиках" всё равно.

Здравствуйте, Денис Майдыковский, Вы писали:

ДМ>Здравствуйте, Romul, Вы писали:

R>>Насколько я понял картинка будет без смещений, но будет располагаться по середине окна?

ДМ>Нет. Строки в битмапе выровнены, как праивло на 4 байта. Это значит что каждая следующая строка начинается не сразу за концом предыдущей, а чперез некоторый интервал, определяемый выравниванием.

ДМ>В случае с VMR ещё хитрее. Например ты заказал кадр размером 320х240. По каким-то одному ему ведомым причинам (обычно это связано с железом видеоадаптера) VMR выделяет память скажем 324х240. На экране всё равно будет отображаться картинка реального размера 320х240, но класть в память данные ты должен строками по 342 пикселя. Что будет в "хвостиках" всё равно.

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

Romul wrote:
>
>
> JS>В результате картинка будет без смещений.
>
>
> Насколько я понял картинка будет без смещений, но будет располагаться по
> середине окна?

Нет, она будет ровно там где должна быть.

Здравствуйте, j.smith, Вы писали:

JS>Romul wrote:
>>
>>
>> JS>В результате картинка будет без смещений.
>>
>>
>> Насколько я понял картинка будет без смещений, но будет располагаться по
>> середине окна?

JS>Нет, она будет ровно там где должна быть.

Списибо за помощью. Сделал такую штуку, все заработало нормально, но вот только в ConnectComplete передается исходный размер, а не тот, который затребовал себе VMR. В итоге пришлось в CheckComplete считать m_Stride

Romul wrote:
>
> Списибо за помощью. Сделал такую штуку, все заработало нормально, но вот
> только в ConnectComplete передается исходный размер, а не тот, который
> затребовал себе VMR. В итоге пришлось в CheckComplete считать m_Stride

ConnectComplete()/CheckComplete() — чьи? (class)

Думаю самый надежный способ это при изменениее состояния фильтра из
Stopped в Paused узнать текущий mediatype. А при попытке соединения
соглашатся на все более-менее похожее на то что надо.

BTW, рекомендую проверить работает ли ваш код с не-XP (там где рендерер
по умолчанию старый).

Здравствуйте, j.smith, Вы писали:

JS>Romul wrote:
>>
>> Списибо за помощью. Сделал такую штуку, все заработало нормально, но вот
>> только в ConnectComplete передается исходный размер, а не тот, который
>> затребовал себе VMR. В итоге пришлось в CheckComplete считать m_Stride

JS>ConnectComplete()/CheckComplete() — чьи? (class)

CBaseOutputPin

JS>BTW, рекомендую проверить работает ли ваш код с не-XP (там где рендерер
JS>по умолчанию старый).

Софт только на XP будет работать. Но вообще конечно интерестно проверить и на Win2k