Close Topic Options

Если я правильно понял из твоего ЖЖ, ты умеешь программно перейти на любое заданное место фильма.

Далее. Энди007 научил меня сохранять громкость в EEPROM, и извлекать её оттуда. Значит мы можем сохранить там же и текущее положение фильма.

Что осталось ? Поймать стоп или выключение плейера, и записать текущее положение в фильме. Сможешь ?

vboroda

Толи я не догоняю, толи туплю до ужаса. Как я рассуждаю: 8032 выводит на экран свои, банальные 6-ь имён файлов и 1-н путь. И ему(8032) глубоко наплевать это имена с CD или FAT он тупо их выводит, причём что бы они отобразились они должны располагаться в строго определенной структуре. Понятно, что с CD и FAT читают разные процедуры, так же понятно, что они могут использовать промежуточный буфер но финишем их работы будет та единственная структура. Идём далее если ты знаешь две простые ф-ции которые вытягивают сами длинные имена из структуры и записывают в массив, где хранится короткое имя, после этого самого короткого имени значит дело сделано, это и есть финишный массив. А свистопляска с OSD 65 я так думаю это он следы путает, т.е. если кто то пересадит его правленый ARM то получит в лучшем случае короткие имена в худшем бред. А меняя вызов OSD 65 он как раз подстраивает 8032 на начало длинного имени. Оставлять короткое не имеет ни какого смысла кому оно нужно. Нам надо сделать проще затирать коротки длинными.

Посмотрев исходник что я нашел:

Если я опять не ошибаюсь, то либо банально добавить команду vSendUopCmd(UOP_PLAY, SV_STOP_PLAY_CHK_LASTMEM, 0, 0); либо восстановить весь код для ISO_LAST_MEM как в исходнике.

cax

так есть уже функция vEepromWriteLastMem(); Description : called from power down
она поидее это и делает если же нет то вручную дописать если в С рубишь глянь сам может скорее догонишь, а то я туплю что то!!!

Rvs,

Вероятно ты таки прав. Потратил сегодня половину рабочего дня в поисках пути к vISOInit, начиная с vPlayerTimer и далее... Докопался в конце концов. Надо подумать, как подставить сюда вызов

vSendUopCmd(UOP_PLAY, SV_STOP_PLAY_CHK_LASTMEM, 0, 0);

Напрямую делать этого не хочу, хочу добавить проверку флага, чтобы resume проводился исключительно по желанию заказчика (т.е. при нажатии кнопки PLAY во время Loading). В случае по умолчанию - как и сейчас, идти в меню выбора файлов. Авось получится.

cax,

В какую прошивку ты бы хотел добавить ф-цию GOTO TIME? Если хочешь, могу взглянуть, авось чего и накопаю. Philips'овские прошивки все очень похожи, и там везде практически нужно делать один и тот же патч (из трех частей). Как я понимаю, у тебя прошивки других производителей, возможно и 8032 код совершенно другой, может быть даже другого, предыдущего поколения. Но взглянуть можно.

Rvs,

И опять я не отрицаю, что ты прав. Просто NA в тех немногих крохах информации, которые он бросил любителям, пишет, что переписывать кототкое имя длинным в функциях, занимающихся чтением FAT, нельзя, т.к. по многим причинам файлы с "длинными именами" проигрываться после подмены не будут (возможно есть еще и другая ф-ция, которая ищет файл по имени, и она-то и не умеет искать по длинному имени?). В общем, я просто не знаю настоящей причины, но уверен, что если бы можно было элементарно подставить длинные имена на место коротких, NA это бы сделал, и не возился бы с OSD 65. Я не думаю, что ему есть какой-то смысл заметать следы таким жутким образом (ты попробуй, почитай его OSD 65 код!), даже если ему очень хочется, чтобы длинные имена на USB были его эксклюзивом.

Я не изучал File Browser в исходниках 8032 подробно, поэтому не буду утверждать, что я прав. Но из того, что я просматривал, мне показалось, что ARM по запросу 8032 просто пишет в SDRAM какие-то 6 (в моем случае 4) поинтеров к строкам, и их-то 8032 и воспринимает как имена файлов. Если так, то совершенно неважно, куда эти пойнтеры указывают - м.б. в массив идущих подряд имен файлов, как в случае ISO диска, а может быть на буфера в каком-то списке структур. В принципе, для 8032 это совершенно безразлично.

Может быть, если удастся что-то сделать с ISO Resume, попробую изучить проблему длинных имен более подробно.

Ну и опять я отвечаю сам себе. Сделал патч, чтобы вызывать

в случае запроса Resume (по флагу в SI_LAST_MEM):

Очевидно, вызывается в таком случае последний проигрывавшийся MPEG (но не MPEG4) , потому что у меня на экране появился бэкграунд файл-браузера, но без списка файлов (т.е. как бы не меню, но и не DivX фильм).

Вероятно, нужно каким-то образом при остановке запоминать файл и время, а при восстановлении инициализировать сначала список файлов, потом определенный файл, а потом уже точку в файле. И все это вручную. Ох... В общем, боюсь, маленьким патчиком не отделаться, а большой мне делать не очень хочется.

Я предлагал вещь более простую.
Уже находясь внутри проигрываемого файла, умеешь ли ты сделать GOTO ?? Если да, то просто добавь кнопку или пункт меню, который приведёт уже играемый файл в запомненную точку в нём. Оставь выбор файла пользователю. Это устроит практически всех.

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

cax

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

Насчет потенциального решения для восстановления игры DivX. Чтобы перейти в некоторую точку проигрываемого в настоящий момент потока, необходимо послать ARM команду:

Ты, как я понял, предлагаешь сделать что-то вроде BOOKMARK - закладки. Нажал кнопочку - запомнил. Нажал другую кнопочку - прыг на закладку. В принципе поддержка таких закладок (и даже не одной, а целого списка) в MTK плеерах существует, хотя в мою прошивку она, к сожалению, не откомпилирована.

Дело в том, что такое решение не многим лучше простой GOTO TIME, которая у меня уже есть. Т.е. от юзера требуется некое действие: в одном случае нажать кнопочку, в другом (моем) - запомнить время остановки. Прелесть готового решения для DVD/VCD в том, что юзеру делать ничего не нужно! Вот тебе пример. В плеере существует само-отключение после 20 минут в скрин-сэйвере. Зрительница поставила фильм на паузу, и пошла успокаивать проснувшегося ребенка. Если она в течение 20 минут не вернулась - плеер само-отключился. Что ей теперь делать? Если она смотрела DVD, то все совсем не страшно: при включении, когда появился экран Loading, она нажимает кнопку PLAY, и плеер переходит на то место, где она остановила фильм. А вот если она смотрела DivX программу, и при этом не запомнила время останова, то ей ничего не остается, как поставить фильм на быструю 32x перемотку. Что тоже, разумеется, не конец света...

В общем, чтобы решить такую проблему так, как мне хотелось бы, нужно запоминать последний проигрываемый в момент отключения файл + время HH MM SS - скажем, 4 байта.

В точке восстановления (которая мною уже идентифицирована) нужно было бы делать:
(0) восстановление меню и MPEG4 режима.
(1) прыжок на файл - пока не знаю, как.
(2) прыжок на время - знаю как.

This post has been edited by vboroda on 25-05-2007, 19:38

Похоже, я всё-таки плохо объяснил свою задумку.
Попробую ещё раз объяснить, как я вижу реализацию запоминания:

1) при нажатии на паузу/стоп/отключение запоминание времени - автоматическое.

2) Восстановление воспроизведения в запомненном месте: уже после начала воспроизведения файла, нажатием на клавишу или выбором пункта в меню.

В таком варианте не придётся выполнять пункты (0) и (1).

По поводу "моей" прошивки: разумеется, я буду рад встроить такую возможность во все свои плейеры, просто сейчас нет смысла разбрасываться, пока эта фича не реализована и не обкатана до конца у тебя на твоём аппарате.

vboroda

хммм тогда надо ещё помозговать ...

Так на вскидку по адресу ShMem+ 022B , 022С, 022D, 022E лежит указатель на адрес названия папок. И ещё 4-е адреса на указатель начало структуры, что я показал выше. Согласен указатели могут указывать куда угодно, но 8032 вычисляет начало строк так:

т.е. через пресловутую структуру. А вот она уже указывает на начало каждой строки. Поэтому указатели могут указывать только на эту структуру. Причём я так понимаю место положение её низменно.

Зачем вручную. Я когда бегло смотрел то нашёл функции, которые пишут всё это в память. Их надо разблокировать скомпилить прошивку и подставить к себе. Надо пробежаться по всем таким местам #ifdef ISO_LAST_MEM. Покопаюсь на выходных.

Понял. Да, идея не плохая. Я думаю использовать >>| кнопку:

Если есть сохраненное время, проверить валидность, затем прыгнуть на него и затереть сохраненное время.

Если нет сохраненного времени - все как обычно.

Насчет сохранения в EEPROM нескольких байт я пока не очень понимаю, пример бы не помешал. Ну и восстановление, естественно. Покамест сохраним в Sh. Mem.

Rvs

Я думаю, структура списка файлов одна и та же, но список - коллекция пойнтеров, которые указывают "куда-то". Хорошо было бы, если бы на те самые буферы, в которых за короткими именами следуют длинные. Иначе придется копать ARM, и меня это пока очень пугает.

Ну я пока накатал пару ф-ций на ассемблере (сохранить и восстановить с прыжком). Как cax посоветовал. Но еще не тестировал. Я не на 100% уверен, что ISO_LAST_MEM сделала бы все, что нам надо. Там еще дело в том, что меняются размеры массивов EEPROM SHADOW, боюсь, как бы это не подвинуло чего-нибудь. Надо разобраться, как это все работает, и сделать по аналогии, мне кажется.

Вот очень сырое "руководство" по сохранению громкости, реализованное по наводке и под руководством Энди007 (из него легко понять как читать из/писать в EEPROM).

В чём его сырость ?

1) не описывается как найти свободную ячейку EEPROM
(вкратце: берём наугад некий адрес - я использовал от 0x55 до 0x99 - и проверяем по всей прошивке, нет ли для него вызовов PREF_GetChar. Если нет - возможно, что он не используется)

2) в 4 из 5 случаев у меня не было свободного места в нужном банке, и мне приходилось размещать дополнительный код в пустом месте другого банка, и, соответственно, использовать "межбанковский" вызов. Боюсь, что для читателей, знакомых лишь с hex-редактором, это будет сложно объяснить
(вкратце: вместо обычного 12 zz zz надо использовать 90 zz zz 02 kk kk, где kk kk - подпрограмма вызова кода по адресу zz zz в другом банке памяти)

Как всегда, описываю применительно к DVD Hyundai 3899 servo 02.09:

This post has been edited by cax on 27-05-2007, 12:09

Люди, извиняюсь за вторжение в вашу высоконоучную дискуссию. Облазил весь e-net - похоже вы глубже всех зарылись в тему, если нет - подскажите где искать....
Аппарат BBK DV966S=DV516S. Проц MTK1389FE.
В общем-то притензий к аппарату по большому счёту нет, но главный глюк котрой BBK'ейщики не исправили за 3 года ( и теперь уже вряд ли исправят ) это то что все регулировки: громкость по каналам, эквалайзер, яркость, контрастность, насыщенность, навигация по меню и пр. происходят не плавно ( при длительном удержиании соответствующих кнопок на пульте ) а дискретно - когда чтобы изменить необходимый параметр, например на 10, - нужно десять раз нажать соответствующую кнопку. Задалбливает. Кнопки на пульту скоро до дыр продавятся. У знакомого 965-ый - так там такого глюка нет. Прошивка стоит последняя 966S-4A-427 с официального сайта BBK. Ни кто не сталкивался с таким глюком, не ковырял прошиву на эту тему? Брал пульт от 965-го всё тоже самое - значит проблема не в пульте. Может есть у кого какие мысли в какую сторону копать? .
Есть даже 966S-4A-0427-m1 патченная a-ha ( должны знать ) - но проблемма осталсь. Если надо могу приаттачить прошиву.
TIA

This post has been edited by lill on 29-05-2007, 06:05

Слабые попытки сделать "нажатие с удержанием" предпринимались на плейерах Пионер, но и там - только при пролистывании списка файлов. Если я не ошибаюсь, для этого в прошивке должна быть неактивированная поддержка "долгого нажатия", которую нужно включить и подвесить к ней нужную функцию.

В общем, я точными знаниями по сабжу не обладаю, а искать нужно, как всегда, если на русском - то в ixbt, а если на английском - то на Яху в группе mt13x9 и разных других форумах.

cax

Прочитал я инструкцию, спасибо. Если бы ты еще называл PREF_GetChar и PREF_PutChar их настоящими названиями bEepromReadByte и fgEepromWriteByte, я бы сразу понял, о чем речь. В общем, похоже что поиск "свободных ячеек" EEPROM осуществляется методом "научного тыка", или лучше сказать, наугад.

Проверить какой-либо адрес на предмет существования вызовов на него PREF_GetChar, просто изучая дизассемблер прошивки, в принципе практически невозможно. Если почитать исходники, станет понятно - почему. Кроме того, что таких мест, где вызывается эта ф-ция (напрямую или через Bank Switch) - несколько сот, во многих местах она вызывается с параметрами, записанными в некоей таблице, в которой в принципе состоят ВСЕ ячейки LAST_MEMORY - от нуля и до последней. Это не значит, что все они используются в каждой прошивке, некоторые могут относиться к опциям, для конкретного железа ничего не значащим (караоке, например), но теоретически каждая из ячеек может использоваться, и на нее существует пусть непрямой, но вызов. Т.е. более правильным подходом в таком случае было бы просто попытаться сделать два дампа EEPROM - до и после того, как ты изменил ВСЕ возможные опции, а заодно и проиграл все возможные виды дисков - и посмотреть, значение каких ячеек не изменилось.

В общем, без кабеля я пока не знаю, как действовать. Но думаю, что можно писать я ячейки, следующие за EEPROM_END_POS, т.е. в моем случае где-то после адреса 0x20C в EEPROM. Там, как я понимаю - no man's land - ничего не значащие и не используемые ячейки. Для писания и читания в EEPROM напрямую (а не через Shadow, как PREF_...) можно использовать ф-ции:

BOOL fgWrite_EEPROMByteDirect(BYTE bId, BYTE bAddr, BYTE bData) и BOOL fgRead_EEPROMByteDirect(BYTE bDevice, BYTE bData_Addr, BYTE *pbData)

А вообще, твоя идея с resume мне понравилась, и я ее уже даже осуществил, хотя пока без сохранения и восстановления из EEPROM. Сделал [пока, в тестовом варианте] так:

(1) по нажатию IR_PAUSE (в дальнейшем будет также IR_STOP и IR_POWER) сохраняем в Shared Mem. текущее время.
(2) по нажатию кнопки IR_NEXT ( >|| ) если сохраненное время валидно, прыгаем на него, и затираем. Если сохраненное время затерто - отрабатываем кнопку по умолчанию.

This post has been edited by vboroda on 29-05-2007, 01:05

Да на ixbt я завсегдатай ( оттуда и прошивка от a-ha ), на yahoo grooop тоже есть свой аккаунт - вот уже три года слежу и за cachirulo, mabreacer, Cherry и иже с ними. Но народ почему в основном упёрся в рюшечки типа фонты, картинки, заставки. Я понимаю - хозяин-барин и что эти задачи тоже требуют уйму времени - респект и уважуха им за это, но вот глюк о котором я писал почему-то ни кого не интересует хотя он куда больше доставляет неудобств чем кривые фонты. У самого нет столько времени чтобы с ноля драть прошивку идой - а зацепиться незачто. Ладно...- это крик души Похоже готового решения не найти - предётся возится помаленьку самому. Тем более что чтобы не париться с ISO образами штатно установил в сабж на правой боковой панели разъём RJ-45 для низковольтного COM порт на MAX3232. Получилось аккуратно. Работает без проблем. Лей теперь что хочешь - былобы что.
Главное нет инфы в чём проблема - ведь в DV965S нет такого глюка! Что поменялось-то? Железо практически одинаковое.

This post has been edited by lill on 29-05-2007, 07:00