Вход | Регистрация

  1  2  3  4  5  6  7   

Глюки пятого ифона. Бойтесь.

Глюки пятого ифона. Бойтесь.
Я
   IamAlexy
 
25.12.12 - 13:43
4. другое40% (22)
2. аахххааа хааа29% (16)
3. слава богу у меня андроид27% (15)
1. Я так и знал!4% (2)
Всего мнений: 55

Собственно после недели использования выявилось следующее:

1. по утрам первый звонок обрывается через 40 секунд.
незнаю глюк телефона или мегафона но суть в том что постоянно такое - первый входящий звонок на 40ой секунде обрывается. Если перезвонить или дождаться перезвона работает на ура - хоть 25 минут трепись до технического отбоя.

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

это собственно закономерные косяки которые повторяются изодня в день.
не разовый тупняк а постоянно такая фигня.

так что - вывод неутешителен..
 
 
   NS
 
301 - 27.12.12 - 20:32
(300) Я тебя не вижу в моей квартире, так что могу предположить что у тебя другая вышка рядом.
У тебя у самого ума до такой простой мысли дойти не хватает?
   NS
 
302 - 27.12.12 - 20:34
По городу никаких проблем с 3G у меня нет. Только в квартире. Большинство телефонов при этом глючит и на gprs/edge.
   ХочуСказать
 
303 - 27.12.12 - 20:54
Классно Джобс хомячков на смартфоны развел

Зы. У меня мотороловский слайдер, поменял недавно шлейф и я счастлив. Нафиг ваши смартфоны. Но подумываю в дополнение к айпаду докупить айпад мини
   TormozIT
 
304 - 27.12.12 - 20:56
htc desire s - скоро год, глюков нет. мегафон, москва

2. аахххааа хааа
   McArt
 
305 - 28.12.12 - 09:33
(287) В ВинФоне тоже есть такая штука, что не может не радовать.
   McArt
 
306 - 28.12.12 - 09:38
+(305) А вот в Симбе либо она не совсем так работает, либо я криво настроил, но, допустим, заходя в яндекс карты, моя нокла умудрялась всё равно успевать отдъедать трафик, хотя я нажимал отмену при запросе подключения. В итоге я просто пароль специально сделал неправильный (добавив единицу в конец), чтобы интернет не подключался когда я этого не хочу.
   dmpl
 
307 - 28.12.12 - 09:43
(268)(277) Он гнется только о тощие костлявые задницы китайских работяг. А о толстые задницы американцев не гнется. Так что все нормально. Ответ Apple будет в стиле "ну так не делайте так". А если уж очень хотите - купите чехольчик за 59,95$.
   IamAlexy
 
308 - 28.12.12 - 10:09
был на детском утреннике.
записал 40 минут видео
батарейка скушалась на 28 процентов.


это хорошо или плохо ?
   zak555
 
309 - 28.12.12 - 10:15
(308) ты позвонил в мегафон ?
   Shrek_yar
 
310 - 28.12.12 - 10:17
Сдай в СЦ если купле у официалов, брак попался просто, у моего знакомого такого нет)

4. другое
 
 Рекламное место пустует
   IamAlexy
 
311 - 28.12.12 - 10:18
(309) неа..
   zak555
 
312 - 28.12.12 - 10:31
(311) позвони, расскажи про ситуацию
трудно что ли ?
   IamAlexy
 
313 - 28.12.12 - 10:34
(312) стесняюсь.. да и зачем хороших людей по пустякам беспокоить.. нервировать..
   zak555
 
314 - 28.12.12 - 10:35
(313) есть кто вхож к тебе в дом тоже с айфоном тогда 7
   NS
 
315 - 28.12.12 - 10:44
(308) А на сколько должен был сесть по ТТХ?
   IamAlexy
 
316 - 28.12.12 - 10:48
(315) хз.. вот спрашиваю...
   NS
 
317 - 28.12.12 - 10:52
(316) 4S держит 2.20 записи в 1080p по ТТХ.
   NS
 
318 - 28.12.12 - 10:57
нагрузка (поток) при записи в 1080p в два раза больше чем при записи в 720p
   Jaffar
 
319 - 28.12.12 - 11:02
(318) поток влияет на скорость разрядки?
   bodri
 
320 - 28.12.12 - 11:10
наткнулся...
http://hi-tech.mail.ru/news/misc/bendable_iphone_5.html
незнаю глюк или так и надо
   dmpl
 
321 - 28.12.12 - 11:12
(319) Ну, как минимум, чаще приходится просыпаться и дольше писать на карточку. Другое дело что эта разница, чаще всего, находится в пределах погрешности
   Ахиллес
 
322 - 28.12.12 - 11:42
(320) Покорми аленей.
   NS
 
323 - 28.12.12 - 11:47
(319) вот это вопрос. Это пять!
Да, в дыа раза больше всех операций - в два раза быстрее сажают аккум.
   ХочуСказать
 
324 - 28.12.12 - 11:52
кстати, а чем отличается iPod Touch  от айфона?
нет GPS и GSM ?
   Jaffar
 
325 - 28.12.12 - 11:55
(323) "в два раза больше всех операций"
за счет чего? я понимаю, если бы вместо 30fps записывалось бы 60fps, но тут частота кадров не меняется - меняется только длина блока, записываемого в файл. надеюсь, SIMD-инструкции уже применяются в процессорах для смартфонов?
   NS
 
326 - 28.12.12 - 11:59
(325) Правильно думаешь, сжатие аппаратное.
Но в любом случае - чтоб сжать поток который в два раза больше - независимо от того в два раза больше разрешение или количество кадров - необходимо ровно в два раза больше операций.
   Ахиллес
 
327 - 28.12.12 - 12:02
(326) то есть под более мене нагрузкой огрызок живёт около 2-х часов, как самый последний китайский нонейм? Это успих :-)
   Ахиллес
 
328 - 28.12.12 - 12:04
Вот тебе и самый мощный процессор. Гыгыгы :-) Ничего кроме повышенного расхода батареи и +15 к понтам на форуме он не даёт.
   NS
 
329 - 28.12.12 - 12:07
(327) Прежде чем нести чушь, найди инфу об автономности в режиме записи видео других решений.
   ЧеловекДуши
 
330 - 28.12.12 - 12:12
Все это баловство

2. аахххааа хааа
   NS
 
331 - 28.12.12 - 12:14
(328) Как достали домохозяйки. На любом проце. Если пишешь поток в два раза больше - проц жрет в два раза больше.
   acsent
 
332 - 28.12.12 - 12:15
(329) не ужто камера столько есть?
   acsent
 
333 - 28.12.12 - 12:15
(331) Так основное отъедание - это вайфай, сеть и камера. Разве нет?
 
 
   acsent
 
334 - 28.12.12 - 12:16
(333) не камера, дисплей
   Jaffar
 
335 - 28.12.12 - 12:20
(332) "не ужто камера столько есть?"
нет, пить.
   dmpl
 
336 - 28.12.12 - 12:25
(331) На специализированном проце разницы практически нет. А с учетом того, что та же матрица жрет поболее этого проца - разница околонулевая. Например, мой видеорегистратор что в 1920x1080, что в 640 x 480 работает от аккумулятора 2 часа. И плевать ему на то, что поток во втором случае в 8 раз меньше.
   NS
 
337 - 28.12.12 - 12:26
(332) Во время записи видео макимальной энергопотребление, жрет экран, оптический сенсор, память и проц на полную катушку. Кодирование видео на порядок более ресурсоемко чем декодирование.
Ни один смартфон (да и камера) долго в режиме записи видео не живет.
   NS
 
338 - 28.12.12 - 12:27
(336) На любом проце, в том чиле и специализированном нагрузка на проц при в два раза большем потоку - ровно в два раза больше. Так как на кодирование в два раза большего потока требуется ровно в два раза больше операций. Независимо от наличия аппаратной поддержки.
   NS
 
339 - 28.12.12 - 12:31
(336) Да, только видеорегистраторы при большем разрешении уменьшают fps, и поток остается таким-же. А если поток увеличишь - то и садится будет быстрее.
   dmpl
 
340 - 28.12.12 - 12:31
(338) Поток - нет, просто другие (более высокие) коэффициенты квантования (которые обнулят больше коэффициентов перед huffman сжатием). Ну а дальше обратная связь по среднему потоку просто регулирует диапазон коэффициентов квантования.
   dmpl
 
341 - 28.12.12 - 12:32
(339) 30 fps везде.
   NS
 
342 - 28.12.12 - 12:35
(340) Да просто прочитать поток и записать на диск - уже ровно в два раза большая нагрузка, и в два раза больше операций. И на память, и на носитель, и на проц. Что ты мне втираешь?
   dmpl
 
343 - 28.12.12 - 12:36
+(338) Более того, при программном сжатии меньший поток может давать даже бОльшее количество операций, если алгоритм сжатия выполняет несколько вариантов сжатия и по максимальному значению PSNR выбирает лучший вариант. Здесь чем сильнее сжатие - тем сложнее уложиться в заданный PSNR.
   NS
 
344 - 28.12.12 - 12:36
Напиши на ассемблере (Да хоть с аппаратной поддержкой) код считывания и записи потока в память.
   NS
 
345 - 28.12.12 - 12:37
(343) Во первых - чем больше поток, тем большие коэффициенты сжатия используют, что еще повышает нагрузку.
   dmpl
 
346 - 28.12.12 - 12:37
(342) Это 0,5-1% максимум от общей нагрузки.

(344) DMA рулит, поменяется только размер блока.
   dmpl
 
347 - 28.12.12 - 12:37
(345) Чем больше поток - тем проще его сжать с заданным качеством.
   Ursus maritimus
 
348 - 28.12.12 - 12:39
(347) Ща те объяснят, что ты не прав.
   NS
 
349 - 28.12.12 - 12:44
(347) ИМХО у кого-то поехала крыша. У тебя разное качество на выходе в 720p и 1080p
 
 Рекламное место пустует
   IamAlexy
 
350 - 28.12.12 - 12:45
так чо там
40 минут записи видео и 28% разряд батареи иэто хорошо или плохо?
   IamAlexy
 
351 - 28.12.12 - 12:46
(347) да да да.. расскажи это всем программным сжималщикам...

никогда ролики на ютьюб не выкидывал?
сожми видео 800х600 и 1900х1200

посмотрим где у тебя быстрее сожмется :) :): )
   Jaffar
 
352 - 28.12.12 - 12:47
(351) "проще" не в смысле "быстрее"
   acsent
 
353 - 28.12.12 - 12:47
(350) раз сравнивать не с чем, то это просто супер очень долгое время
   NS
 
354 - 28.12.12 - 12:47
(350) Так и должно быть по ТТХ.
   dmpl
 
355 - 28.12.12 - 12:50
(348) Не, не объяснят. Я-то и XviD, и H.264 в исходниках видел, и даже кое-что там оптимизировал, так что результаты профайлера у меня где-то лежат.

(349) Ты сначала почитай, как кодеки сжатия с потерями устроены, прежде чем фигню писать. Основное время занимает первичная обработка кадра, количество операций в которой зависит только от размера кадра (дискретное косинусное преобразование, поиск векторов движения и т.п.), и только на этапе, когда все эти преобразования уже сделаны, кодек просто часть данных ВЫБРАСЫВАЕТ, оставляя только самые нужные, чтобы уложиться в заданные параметры.

(351) Речь идет про поток, а не про размер. И да, аппаратно они жмутся абсолютно с одинаковой скоростью ;)
   NS
 
356 - 28.12.12 - 12:53
(355) Еще раз повторю - если ты сжимаешь в 1080p у тебя на входе просто в два раза больший файл который нужно сжать с той-же степенью сжатия (и на выходе файл ровно в два раза больше). Каждая картинка ровно в два раза больше. И чтоб сжать на каждый кадр уходит ровно в два раза больше процессорного времени. И никакая аппаратная поддержка это соотношение не изменит.
   NS
 
357 - 28.12.12 - 12:54
Даже даун понимает чтоб сжать с той-же степенью сжатия в два раз больший файл - уйдет ровно в два раза больше процессорного времени. Дома у дочери спрошу. На 100% уверен что даже она это понимает. Любая фильтрация, любой алгоритм обработки изображения займет ровно в два раза больше времени.
   NS
 
358 - 28.12.12 - 12:56
И даже даун понимает что чтоб записать в два раза больший файл - через память нужно прогнать в два раза больше информации, и на носитель нужно записать в два раза больше информации.
   dmpl
 
359 - 28.12.12 - 12:58
(356) В 2 раза больше относительно чего? Картинка на входе не зависит от выходного потока.

(357) Ты бы не писал о том, в чем не разбираешься. Ибо смешно, ей богу... даже при изменении размеров изображения на входе есть часть операций, которые пропорциональны квадрату объема входных данных, есть часть операций, пропорциональных первой степени объема входных данных, и есть часть операций, которые пропорциональны менее чем первой степени объема входных данных, а есть вообще операции, которые от объема входных данных не зависят никоим образом.
   dmpl
 
360 - 28.12.12 - 12:59
(358) См. (346).
   godmod80
 
361 - 28.12.12 - 13:01
вощем два часа видео и икФон кирпич...
   NS
 
362 - 28.12.12 - 13:01
(360) Ты что, не понимаешь что размер блока у тебя ограничен, и в случае в два раза большего разрешения на входе и на выходе, тем же качеством у тебя ровно в два раза вырастет количество блоков?
   NS
 
363 - 28.12.12 - 13:02
(361) Почти три. Конкуренты садятся значительно быстрее.
И попробуй меня опровергнуть.
   Кокос
 
364 - 28.12.12 - 13:02
айос женераль сосьете :)

3. слава богу у меня андроид
   dmpl
 
365 - 28.12.12 - 13:03
(362) А ты что, не понимаешь, что ОС использует отложенную запись, так что все определяется временем отложенной записи (как решит ОС - так и будет). Например, если она сбрасывает поток на карточку раз в 1 с - то количество обращений к карте памяти не изменится вообще.
   godmod80
 
366 - 28.12.12 - 13:04
(363) у конкурентов разные показатели аккумов так что не тупите, что все отстают
   acsent
 
367 - 28.12.12 - 13:04
(357) у тебя дочь разработчик кодеков видео?
   Ursus maritimus
 
368 - 28.12.12 - 13:07
(362) имхо, на входе размер должен быть одинаковым. сколько матрица выдает - столько выдает. или при записи 720 пол матрицы используется?н
   NS
 
369 - 28.12.12 - 13:08
(367) Нет, но любой ребенок понимает что на обработку в два раза блольшего объема информации требуется в два раза больше времени.
   godmod80
 
370 - 28.12.12 - 13:09
(369) а если ядер больше сделать то чё)
   NS
 
371 - 28.12.12 - 13:09
(368) Нет, порезать поток в два раза просто не занимает времени. Матрица отдает поток в 1080p и 720p одинаково легко, если не учитывать что на передачу в два раза большего потока требуется в два раза больше мощи.
   Ursus maritimus
 
372 - 28.12.12 - 13:10
(366) NS все правильно говорит. Просто у айфона конкуренты это андроиды до 8 тыр. С более дорогими девайсами он сравнения не выдерживает.
   NS
 
373 - 28.12.12 - 13:10
(270) То эти в два раза больше ядер будут кодировать 720p точно так-же в два раза быстрее чем эти-же в два раза больше ядер в 1080p.
И энергопотребление на кодирование от количества ядер не зависит. В два раза больше ядер, на каждое из которых в два раза меньше нагрузка.
   dmpl
 
374 - 28.12.12 - 13:11
(368) Происходит масштабирование. Чаще всего с помощью децимации (на это, кстати, тоже надо затратить процессорное время), намного реже - полноценное бикубическое масштабирование. Весьма, кстати, тяжелое по затратам времени.

(369) Дети вообще видят мир очень упрощенно. А взрослые понимают, что не все так просто, и многое зависит от алгоритма, и, о Боже! даже от содержания картинки в кадре.
   NS
 
375 - 28.12.12 - 13:11
(372) Докажи. у SGS3 прр видеосъемке заряд падет с бешенной скоростью.
   Jaffar
 
376 - 28.12.12 - 13:12
(356) "Каждая картинка ровно в два раза больше. "
только я один знаю, что в файле с видео не все кадры лежат в виде отдельных картинок???
   Ursus maritimus
 
377 - 28.12.12 - 13:13
(372) Что доказать? Я же не спорю.
   dmpl
 
378 - 28.12.12 - 13:14
(376) Тс-с-с... не грузи. Он даже про VBR не знает, а ты уже про разные типы кадров...
   NS
 
379 - 28.12.12 - 13:14
(374) Сложность (и количество операций) Бикубической апроксимации прямо пропорционально разрешению на выходе. Если ты не в курсе.
   ssh2006
 
380 - 28.12.12 - 13:15
(372) > у айфона конкуренты это андроиды до 8 тыр.

Андроид - нишевая ос для бюджетных гаджетов.
   dmpl
 
381 - 28.12.12 - 13:17
(379) Ты забыл, что это не единственный коэффициент пропорциональности. От входного разрешения зависимость уже квадратичная.
   NS
 
382 - 28.12.12 - 13:22
(381) Чего?
При бикубической интерполяции значение в результирующем изображении, для каждой точки вычисляется по значению в 16 соседних точках. И количество вычислений не зависит от разрешения входного файла. Совсем. И прямо пропорционально разрешению (количеству точек) в выходном файле.
   NS
 
383 - 28.12.12 - 13:23
(381) Азы хотя-бы сначала пойми, а потом спорить уже лезь.
   godmod80
 
384 - 28.12.12 - 13:26
(382) нихуху загнул)
   dmpl
 
385 - 28.12.12 - 13:26
(382) Ты забываешь, что при масштабировании более чем на 50% чистая бикубическая интерполяция даст артефакты в виде лесенок и пропадания тонких линий. У тебя матрица выдает вовсе не 2 Мпикс, а гораздо больше. Так что перед самой интерполяцией тебе придется ограничить спектр входного сигнала до нужного. Или мириться с артефактами (как при масштабировании по соседним пикселам). Вот как раз это ограничение и имеет квадратичную зависимость.
   dmpl
 
386 - 28.12.12 - 13:28
(383) Понимаешь ли, прочитать теоретическую статью на Википедии недостаточно, чтобы аргументированно спорить в прикладной области.
   godmod80
 
387 - 28.12.12 - 13:29
(380) гг , иОС для бюджетных Америкосов вопщето
   Ахиллес
 
388 - 28.12.12 - 13:30
Нашла коса на камень :-)
Похоже Сирожу размазали тонким слоем :-)
   NS
 
389 - 28.12.12 - 13:31
(386) У меня есть подозрение, что я вообще не с разработчиков разговариваю. А у меня всё ОК и понятием сложности алгоритмов и со всем остальным.
Сложность бикубической интерполяции никак не зависит от разрешения входного файла. Вообще.
   Ursus maritimus
 
390 - 28.12.12 - 13:31
только я чувствую себя имбицилом?
   ХочуСказать
 
391 - 28.12.12 - 13:31
(387) не... iOS для тех, кому не в напряг выкинуть штуку баксов за звонилку
   NS
 
392 - 28.12.12 - 13:32
И более того - получение нужного контента от сенсора по ресурсоемкости не идет ни в какое сравнение с ресурсоемкостью кодирования.
   Jaffar
 
393 - 28.12.12 - 13:34
(373) "И энергопотребление на кодирование от количества ядер не зависит."
вот как раз от количества ядер энергопотребление еще как зависит - больше, чем от разрешения.
   godmod80
 
394 - 28.12.12 - 13:36
(393) от программиста зависит будет ли зависеть)
   NS
 
395 - 28.12.12 - 13:39
(393) Каким образом? На каждом ядре в два раза меньше операций (тратится в два раза меньше процессорного времени), но ядер в два раза больше. Суммарно такая-же нагрузка, энергопотребление такое-же.
   NS
 
396 - 28.12.12 - 13:40
При этом параллелятся и фильтрации и алгоритмы кодирования видео - влет. Со 100% эффективностью.
   Кокос
 
397 - 28.12.12 - 13:41
NS держит оборону практически в одиночестве :)
   dmpl
 
398 - 28.12.12 - 13:41
(389) Намекаю - статья Википедии имеет весьма опосредованное отношение к реализации этого масштабирования в реальном железе.

(392) Правильное масштабирование занимает 10-50%, в зависимости от коэффициентов масштабирования. Чем больше уменьшение - тем больше масштабирование занимает в процентах.

(395) Ты не в курсе, что до 50% потребления ядра - это затраты на доставку сигнала синхронизации ко всем блокам? И она никоим образом не зависит от нагрузки?
   dmpl
 
399 - 28.12.12 - 13:42
(396) 100% эффективности не бывает, хотя бы из-за коллиций при обращении к данным и из-за общего кеша 3-го уровня.
   NS
 
400 - 28.12.12 - 13:42
(398) (392) Не неси глупость.
(395) Аналогично. В простое нормальный проц жрет в 10 раз меньше чем под нагрузкой.
  1  2  3  4  5  6  7   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует