Re[13]: Очень медленное чтение IMediaSample в transform филь
От: Aleksey Skurihin Украина http://www.adept7.kiev.ua
Дата: 10.09.07 11:30
Оценка:
Здравствуйте, Денис Майдыковский, Вы писали:

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


AS>>видео идет но раз в 100 быстрее чем надо и вверх ногами


ДМ>Про "вверх ногами" надо самостоятельно обрабаотывать динамическое измненение формата.



Get/Set mediaType есть и VMR коннектится

В примере этого нет. Описание здесь http://msdn2.microsoft.com/en-us/library/ms867156.aspx#dynformat_queryacceptupstream Увы, простым копированием данных не обойтись, придётся делать анализ ориентации DIB-ов и в некоторых случаях выполнять построчное копирование.

опс, а почему когда все работало на аллокаторе VMR жтого не требовалось? А как проанализироватьориантацию? Я знаю что если высота отрицательная то изображение перевернуто, есть ли еще какие методы?

ДМ>По скорость. Смотрите что с временами. Обратитите внимание что IMediaSample::GetTime() может вернуть значение VFW_S_NO_STOP_TIME, это значит что время старта сэмпла всё-же нужно установить.


Насчет времени GetMediaTime исправно дает номер кадра, GetTime исправно дает время, все работает... но на экране такое впечателние что getTime дает ноль, а отладчик показывает что все верно.... куда можно копать?
Радость от нахождения ошибки часто омрачаеться осознанием собственой глупости.
Re[14]: Очень медленное чтение IMediaSample в transform филь
От: Денис Майдыковский Россия http://www.maydyk.com
Дата: 10.09.07 12:21
Оценка:
Здравствуйте, Aleksey Skurihin, Вы писали:

AS>Get/Set mediaType есть и VMR коннектится


Этого недостаточно. Нужно вызвать GetMediaType() у выходного сэмпла и если возращённое значение S_OK надо пересоедениться с указаным медиатипом.

AS>опс, а почему когда все работало на аллокаторе VMR жтого не требовалось? А как проанализироватьориантацию? Я знаю что если высота отрицательная то изображение перевернуто, есть ли еще какие методы?


Других нет, этого достаточно. Если знаки biHeight совпадают, то копирование производится построчно, если противоположные, то изображение надо переворачивать при копировании. Кроме того VMR может требовать битмап с большей шириной чем указано при соеденении. Именнно поэтому CopyMemory не всегда примнима и надо копировать построчно.

Значит между вашим фильтром и VMR "влез" какой-нибудь Color Space Converter. Вы граф смотрели? VMR отвергает соеденение, если используется аллокатор предыдущего фильтра.

AS>Насчет времени GetMediaTime исправно дает номер кадра, GetTime исправно дает время, все работает... но на экране такое впечателние что getTime дает ноль, а отладчик показывает что все верно.... куда можно копать?


Может быть у графа сброшены часы вызовом IMediaFilter::SetSynkSource(NULL)?
Re[15]: Очень медленное чтение IMediaSample в transform филь
От: Aleksey Skurihin Украина http://www.adept7.kiev.ua
Дата: 10.09.07 13:11
Оценка:
Здравствуйте, Денис Майдыковский, Вы писали:

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


AS>>Get/Set mediaType есть и VMR коннектится


ДМ>Этого недостаточно. Нужно вызвать GetMediaType() у выходного сэмпла и если возращённое значение S_OK надо пересоедениться с указаным медиатипом.


AS>>опс, а почему когда все работало на аллокаторе VMR жтого не требовалось? А как проанализироватьориантацию? Я знаю что если высота отрицательная то изображение перевернуто, есть ли еще какие методы?


ДМ>Других нет, этого достаточно. Если знаки biHeight совпадают, то копирование производится построчно, если противоположные, то изображение надо переворачивать при копировании. Кроме того VMR может требовать битмап с большей шириной чем указано при соеденении. Именнно поэтому CopyMemory не всегда примнима и надо копировать построчно.


ДМ>Значит между вашим фильтром и VMR "влез" какой-нибудь Color Space Converter. Вы граф смотрели? VMR отвергает соеденение, если используется аллокатор предыдущего фильтра.


Я смотрел, я его вручную строю, biHeight положительное, а изображение перевернуто, причем если я работаю TranInPlace (т.е даю DivX аллоктаор VMR то все ок, а как только я начинаю перекладывать семпл сам возникает такие вот три лажи (скорость, перевернутость, креш при остановке)


AS>>Насчет времени GetMediaTime исправно дает номер кадра, GetTime исправно дает время, все работает... но на экране такое впечателние что getTime дает ноль, а отладчик показывает что все верно.... куда можно копать?


ДМ>Может быть у графа сброшены часы вызовом IMediaFilter::SetSynkSource(NULL)?


Нет, я такого не делаю, GetSynkSource возвращает какой то указатель.


а при останове графа теперь либо зависаю (в output висит "Non-key discontinuity — wait for keyframe") либо крешусь неизвестно где. Это чем может быть вызвано.
Радость от нахождения ошибки часто омрачаеться осознанием собственой глупости.
Re[16]: Очень медленное чтение IMediaSample в transform филь
От: Денис Майдыковский Россия http://www.maydyk.com
Дата: 10.09.07 14:45
Оценка:
Здравствуйте, Aleksey Skurihin, Вы писали:

AS>Я смотрел, я его вручную строю, biHeight положительное, а изображение перевернуто, причем если я работаю TranInPlace (т.е даю DivX аллоктаор VMR то все ок, а как только я начинаю перекладывать семпл сам возникает такие вот три лажи (скорость, перевернутость, креш при остановке)


Про перевёрнутость я уже написал, у выходного сэмпла вызови GetMediaType() посмотри какой реально медиатип хочет от тебя VMR. Скорее всего знак высоты будет противоположным, а ширина будет на несколько пикселей больше.
Re[17]: Очень медленное чтение IMediaSample в transform филь
От: Aleksey Skurihin Украина http://www.adept7.kiev.ua
Дата: 10.09.07 16:21
Оценка:
Здравствуйте, Денис Майдыковский, Вы писали:

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


AS>>Я смотрел, я его вручную строю, biHeight положительное, а изображение перевернуто, причем если я работаю TranInPlace (т.е даю DivX аллоктаор VMR то все ок, а как только я начинаю перекладывать семпл сам возникает такие вот три лажи (скорость, перевернутость, креш при остановке)


ДМ>Про перевёрнутость я уже написал, у выходного сэмпла вызови GetMediaType() посмотри какой реально медиатип хочет от тебя VMR. Скорее всего знак высоты будет противоположным, а ширина будет на несколько пикселей больше.



спасибо, насчет перевернутости я понял, похоже в случае с старым моим фильтром этим divx занимался, я хотел узнать почему РАНЬШЕ этого не требовалось.


Но вопрос с крешем остался, какая самая первая входная точка при нажатии кнопки стоп в графедите?
ЧТо вызываеться в первую очередь? Не могу отдебажить, ну и вопрос что делать с скоростью пока открыт, не могу понять где у меня лажа, все по примеру, дебаг говорит что все ок но такое впечатление что видео летит с максимально возможной скоростью
Радость от нахождения ошибки часто омрачаеться осознанием собственой глупости.
Re[18]: Очень медленное чтение IMediaSample в transform филь
От: Денис Майдыковский Россия http://www.maydyk.com
Дата: 11.09.07 06:53
Оценка:
Здравствуйте, Aleksey Skurihin, Вы писали:


AS>Но вопрос с крешем остался, какая самая первая входная точка при нажатии кнопки стоп в графедите?


Самая вероятная причина -- в память нагадил при копировании или где-нибудь ещё. Убери копирование буффера и проверь.
Re[19]: Очень медленное чтение IMediaSample в transform филь
От: Aleksey Skurihin Украина http://www.adept7.kiev.ua
Дата: 11.09.07 13:45
Оценка:
Здравствуйте, Денис Майдыковский, Вы писали:

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



AS>>Но вопрос с крешем остался, какая самая первая входная точка при нажатии кнопки стоп в графедите?


ДМ>Самая вероятная причина -- в память нагадил при копировании или где-нибудь ещё. Убери копирование буффера и проверь.



Спасибо, в общем после того как обнаружил несколько несоответствий внутри (написанных кадром) библиотек решил просто плюнуть и написать заново. Понял что с моими знаниями написать заново будет быстрее чем найти эту ошибку.
каркас фильтра уже поднял.
Радость от нахождения ошибки часто омрачаеться осознанием собственой глупости.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.