Я предполагаю, что задержка становится такой длинной, потому что вы отображаете только обработанные кадры. Фактически показывается только 1 из каждых 120 кадров. И этот кадр показан для следующих 120 кадров и времени обработки. Это сделало бы его действительно запаздывающим.
Вы должны отображать все кадры нормально и вызывать функцию process_img()
только через каждый 120-й кадр.
Попробуйте, если это улучшит ситуацию:
if a!=-1 and b!=-1:
drop_count+=1
jpg = bytes[a:b+2]
bytes= bytes[b+2:]
i=cv2.imdecode(np.fromstring(jpg,dtype=np.uint8),cv2.IMREAD_COLOR)
cv2.imshow(hoststr,i)
if drop_count > 120: # only process every 120th frame
drop_count = 0
process_img(i)#my image processing
if cv2.waitKey(1) ==27:
exit(0)
Я думаю, загружаете ли Вы использование класса
Class.forName(clsname, init, classloader);
(Javadoc здесь), Вы получите экземпляр класса, обеспеченного данным classloader. Все загрузилось из-за того класса, будет также загружен через тот же classloader.
Пока Вы очень осторожны с объектами, которые инстанцируют с этого момента (для обеспечения GC), необходимо смочь перезагрузить различные версии. Я сделал это однажды с Java 1.3, потребовалась большая отладка, но в конце у меня было приложение "начальной загрузки", которое загрузило a Runnable
класс по имени и смог к ""мягкому "перезапуску" путем инстанцирования нового classloader против другого URL и движения снова.
OSGi является платформой, которая позволит Вам делать это. JSR 277 Система Модуля Java разработана для того, чтобы сделать это также (я думаю). Я не следовал за дебатами OSGi-vs-JSR 277, таким образом, я не знаю f, они пробуют к marge их вообще.
Можно прокрутить собственное с загрузчиками класса, но это будет меньше "забавы".
Да. Я видел сделанный на конференции NFJS. Это - как вещи как веб-контейнеры поддерживают горячее развертывание приложений, и включает использование в своих интересах объема загрузчиков класса. Для выполнения его, необходимо создать новый загрузчик класса и использование что загрузить рассматриваемую библиотеку.. затем выбросьте загрузчик (или не) и создайте другого, когда Вы захотите перезагрузить. Вам, вероятно, также придется переопределить поведение загрузчика класса (я помню что-то о загрузчиках класса, получающих классы через их родителя сначала по умолчанию.) Кроме того, я помню предупреждение, что объекты, созданные различными загрузчиками класса, не совместимы (не того же типа) друг с другом, даже если .class файл является точно тем же.
Это - главным образом глубокое волшебство мне все же.;-)
Наверное, нет. Java classloader действительно не поддерживает загрузку во время выполнения; даже доступные classloaders являются взломами, которые используют объект прокси.
You could programatically modify your classpath to reflect your JAR changes. Here is how I would do it:
URLClassLoader urlClassLoader = (URLClassLoader) ClassLoader.getSystemClassLoader();
Method m = URLClassLoader.class.getDeclaredMethod("addURL", new Class[]{URL.class});
m.setAccessible(true);
m.invoke(urlClassLoader, jarFile.toURI().toURL());
String cp = System.getProperty("java.class.path");
if (cp != null) {
cp += File.pathSeparatorChar + jarFile.getCanonicalPath();
} else {
cp = jarFile.toURI().getPath();
}
System.setProperty("java.class.path", cp);
where jarFile is the version of the jar you want to use/overwrite.
Вы можете использовать пакет с открытым исходным кодом: JclLoader , который помогает загружать разные версии одного и того же jar-файла. Это также было необходимо в одной из наших систем для тестирования.