How to become an author
Search
Write a publication
Pull to refresh

Comments 24

Читал, что в Андроид N будет фича — Picture-in-Picture
Вот интересно, можно ли будет играть 2 потока видео в этом случае, т.е. один на основном экране одного приложение, а другой маленький от какого-нибудь другого приложения.
Если да, то возможно вашу проблему уже решили в Android N…
Total votes 1: ↑1 and ↓0+1
Я так понял, что это фишка именно для сворачивания видео и работы с остальным приложением пока видео продолжает играть
In Android N, Android TV users can now watch a video in a pinned window in a corner of the screen when navigating within apps.
Судя по данной записи здесь идет разговор о том, что отображается только одно видео в режиме PIP
PIP is intended for activities that play full-screen video. When switching your activity into PIP mode, avoid showing anything except video content. Track when your activity enters PIP mode and hide UI elements, as described in Handling UI During Picture-in-picture.
Total votes 1: ↑1 and ↓0+1
а собственно зачем для реализации аналога Picture-in-Picture нужна специальная поддержка? берем permission android.permission.SYSTEM_ALERT_WINDOW и работаем. Так умеет например BSPlayer.
отличие в том что готовая поддержка в библиотеках и permission не надо?
Total votes 1: ↑1 and ↓0+1
Попробовал BSPlayer, не получилось у меня включить оконный режим. Но судя по данному виде здесь как вы и сказали есть интерфейс что бы понять что мы в оконном режиме и работаем без пермишенов. Так же приложение с PIP по другому отображается в истории приложений
Total votes 1: ↑1 and ↓0+1
пробую по описанию фичи действовать — «background playback in popup window (long tap on button Back to playback video and audio in popup video)» и видео стало поверх плеера, затем Home и видео есть поверх рабочего стола.
в истории разумеется отображается как обычно (и перекрывает ее)

This comment wasn’t rated yet0
Я что-то не понимаю, или функция compareUrl — это просто нет слов и косяк на косяке?
Total votes 1: ↑1 and ↓0+1
Возможно. Если вы укажите на ошибки я их исправлю. В этом методе я сначало сравнил размера, а после сравнил url посимвольно сравнил ссылки.
Total votes 2: ↑2 and ↓0+2
я не знаю что имел ввиду автор выше, но как минимум нужно использовать безопасные функции, вроде strlen_s и не забывать проверять указатель перед использованием…
Total votes 2: ↑1 and ↓10
*_s функции, на секундочку, это расширение, пролоббированное Microsoft и нигде более, чем в их MSVC, это не поддерживается. И слава богу.
This comment wasn’t rated yet0

я ж и сказал "вроде strlen_s"

This comment wasn’t rated yet0
Изобретаем велосипед. Чем просто стандартная strcmp не устроила?

Мы два раза бежим по обоим строкам (сначала strlen, потом в цикле), что в общем-то лишняя работа, достаточно одного прохода. Зачем вообще размер сравнивать, если один фиг в ноль упрёмся в более короткой строке?
Total votes 2: ↑2 and ↓0+2
Согласен с вами. Почему-то во время разработки я ушол от метода strcmp, сейчас вернул его и исправил с статье. Но метод отсавил, что бы не менять везде
Total votes 1: ↑1 and ↓0+1
Как один из косяков: URL в общем случае не просто строка. Для уверенности я бы урлы ещё бы и декодировал бы.
This comment wasn’t rated yet0
Данный момент я оставил на совести самого ffmpeg. Здесь я уже работаю с теми ссылками которые он сам сделал и с которыми она сам может работать
Total votes 1: ↑1 and ↓0+1
реализывать — реализовывать
ни одно видео нb — ни одно видео не
не только в нашем приложение — не только в нашем приложении
а и в других приложениях — но и в других приложениях
И начался велики пойиск — И начался великий поиск
является оберткой ffmep — является оберткой ffmpeg ???
кладем его в буффер — кладем его в буфер
смена сигмента — смена сегмента
Так же будет не плохо — Так же будет неплохо
сделать так, что бы — сделать так, чтобы
Итак, подитожим — Итак, подытожим
для ссответственной пропускной способности — для соответственной пропускной способности

Может стоит вычитывать перед отправкой?
Total votes 1: ↑0 and ↓1-1
Так же будет не плохо — Также будет неплохо

Упустил.
Total votes 1: ↑0 and ↓1-1
Спасибо за замечание. Исправил
Total votes 1: ↑1 and ↓0+1

Ваше решение несёт практическую пользу? Если да, то почему бы не оформить ваш код согласно соглашению по кодированию FFmpeg и не отправить патч? По всему опыту: нужные вещи принимают хорошо. Плюс на ревью бы указали на косяки: вдруг что-то не так понято в кишках FFmpeg.


К примеру, now_ms(), зачем, если есть libavutil/time.h и av_gettime(), которая, правда, выдаёт время в микросекундах, либо av_gettime_relative() которая более соответствует вашим потребностям (с тем же увеличением точности).


Или, зачем такое количество глобальных переменных в bitrate_manager.c? Почему не добавить static к ним, ведь доступ только из функций внутри.


Или, внутри FFmpeg для выделения памяти непринято использовать malloc() напрямую. Воспользуйтесь av_malloc() или av_mallocz() (если нужно сразу занулить память). Парная функция для освобождения — av_free()/av_freep() — вторая сразу зануляет указатель, дабы избежать. Для случая массивов же, вообще следует воспользоваться av_malloc_array()/av_realloc_array()


Или, подобное:


    urls[i] = (char*) malloc(strlen(url) * sizeof(char));
    strcpy(urls[pointerAfterLastItem], url);

вообще стоит заменить одним вызовом av_strdup()


Ну и последнее, почему вы как-то отдельно от всего остального вызываете freeData()? Почему бы не поместить его в hls_close()? Ведь логично, что такой механизм может потребоваться при чтении этого формата, логично, что освобождать нужно при закрытии оного.


Ещё бы я пересмотрел бы правки в avio.c и локализовал бы их только в hls.c. Дабы не превращать код в лапшу.


После такой краткой ревизии: решение в таком виде я бы постеснялся кому-то показывать, а тем более использовать, кроме как для случая — "быстро проверить".

Total votes 1: ↑1 and ↓0+1
Практическую пользу несет. Тоесть, с данной проблемой сталкиваются многие и решений в интернете я не нашол. Откровенно говоря, я не видел «согласно соглашению по кодированию FFmpeg», но патч я и не хотел создавать вместо этого я оформил в виде руководства и добавил к тикету. С вашими замечаниями согласен, здесь сказалось неуверенное знание FFmpeg(это, кстати, основная причина, почему я не хотел делать патч, так как в коде могут быть проблемы, которые я не знаю ). Переработаю код согласно вашим замечаниям и опубликую изменения. Спасибо за ревью
This comment wasn’t rated yet0
я не видел «согласно соглашению по кодированию FFmpeg»

http://ffmpeg.org/developer.html#Coding-Rules-1


Практическую пользу несет
но патч я и не хотел создавать вместо этого я оформил в виде руководства и добавил к тикету

Патч добавляет +100500 к шансу попасть в апстрим.

Total votes 1: ↑1 and ↓0+1
я так понимаю что вы оставили либу в девстенном виде и только заменили часть файлов? делали ли пул реквест на репо?
Total votes 1: ↑1 and ↓0+1
Да, либу я не менял, и старался как можно меньше изменений делать в ней, что бы избежать какх либо ошибок. Пул реквест не делал, так как работал в рамке ijkplayer'a. Оформил чтото типо руководства в англ виде и сделал коментарий под тикетом, что бы если комуто необходимо мог воспользоваться
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Your account

Sections

Information

Services

Support
© 2006–2024, Habr