Openh264 Binary Options

A Cisco fornece um codec OpenH264 (como uma fonte e um binário), que é o seu codec H.264 de implementação, e cobrem todas as taxas de licenciamento para todas as partes usando seu binário. Este codec permite que você use H.264 em WebRTC com gstreamer e Firefox. Ele não permite a reprodução genérica H.264, apenas WebRTC (consulte bug Mozilla 1057646). A fonte de código está disponível em github / cisco / openh264 sob uma licença BSD. O binário é liberado sob este acordo da Cisco: openh264.org/BINARYLICENSE. txt Upstream Firefox versões baixar e instalar o plugin OpenH264 por padrão automaticamente. Devido à sua natureza binária, o Fedora desativa esse download automático. O repositório fedora-cisco-openh264 é distribuído desde o Fedora 24 por padrão (se você tiver pelo menos um pacote fedora-repos-24-0.5 ou mais recente). Ele contém um binário OpenH264 construído dentro da infra-estrutura do Fedora. Mas distribuídos pela Cisco, de modo que todas as taxas de licenciamento ainda são cobertas por eles. Este repositório também contém plugins OpenH264 para gstreamer e Firefox. É desativado por padrão. Para instalar o OpenH264, você precisa primeiro ativá-lo: e depois instalar os plugins: Depois, você precisa abrir o Firefox, ir ao menu - gt Add-ons - gt Plugins e ativar o plugin OpenH264. Você pode fazer um teste simples se seu H.264 funciona no RTC nesta página (verifique Exigir vídeo H.264). Instalação manual do binário Exemplo de instalação para a versão 1.1: Alterações de configuração do Firefox Digite about: config no campo endereço / URL do Firefox e aceite o aviso. No campo de pesquisa digite 264 e um punhado de opções aparecerá. Dê aos seguintes Nomes de Preferência um valor de true clicando duas vezes em false: Reiniciar o Firefox Depois de reiniciar, a seguinte seqüência de caracteres em about: config mudará para a versão atual que foi instalada da web: Copyright copy 2016 Red Hat, Inc. e outros. Todos os direitos reservados. Para comentários ou questões, por favor contacte-nos. O Projeto Fedora é mantido e dirigido pela comunidade e patrocinado pela Red Hat. Este é um site mantido pela comunidade. Red Hat não é responsável pelo conteúdo. Eu estou procurando um argumento de linha de comando para converter série de imagens em H264 usando CISCO H264. (Algo como imagem FFMPEG para funcionalidade de vídeo). Infelizmente, eu não posso usar FFMPEG como estou criando um aplicativo comercial, onde eu uso o codec instalado no sistema cliente para codificar a série de imagens em H264. Eu acho que o FFMPEG não tem o licenciamento de H264 Binaries como CISCO H264 tem que paga o Royalty para MPEGLA. Se não me engano. Seria ótimo ter sugestões em ambas as considerações. Pediu Feb 18 14 at 15:42 Dependendo de como você pretende usá-lo, OpenH264 pode ser compilado e usado em seu software livre. Os detalhes completos podem ser encontrados aqui: Como o vídeo diz, ao codificar sua própria aplicação / software, há dois cenários que abrange: 1) Você é livre para usar o código-fonte OpenH264 diretamente em seu aplicativo. Os direitos de patente de MPEG-LA que surgem a partir deste ainda se aplicam mesmo que seu aplicativo é gratuito (veja a citação abaixo). A licença de software do seu aplicativo não importa - pode ser aberta, fechada ou até mesmo comercial. Além disso, se você vender ou não não importa. O que importa é quantas unidades você realmente distribuir. No entanto, não é tão ruim quanto você pensa. Se você distribuir lt100.000 unidades por ano, você não pagará royalties (veja termos de licença de MPEG-LA). Assim, se você escrever gratuitamente (como sem nenhum custo) de software, você pode compilar OpenH264 diretamente, e não precisa forçar o seu usuário para recuperar um plug-in, e não precisa se preocupar com advogados até youre 100.000 unidades distribuídas. 2) Se você deseja evitar os royalties de MPEG-LA, não deve compilar o código-fonte do OpenH264, mas deve permitir ao usuário final baixar os binários de plug-in do OpenH264 para seu aplicativo. Você distribui seu próprio aplicativo compilado. Você não distribui os binários de plug-in diretamente, mas pode apontar seu usuário para eles, ou até mesmo ter seu aplicativo dar ao usuário a opção de recuperá-los. Mais importante ainda, a decisão de recuperar o plug-in OpenH264 deve residir com o usuário final ao instalar ou executar seu aplicativo. A Cisco está pagando os royalties do usuário final que surgem do plugin OpenH264, e como seu aplicativo comercial só carrega o plug-in, eles podem fazer isso por você. Novamente, você é livre para escolher qualquer opção acima. Em ambos os casos, não importa se seu aplicativo é aberto, fechado, gratuito ou comercial. O que importa é como você gostaria de cobrir os royalties de distribuição. Opção 1, você paga-los com base em quantos downloads seu software recebe (não quantos vendidos). Opção 2, a Cisco paga-os se o seu app ligar ao seu plug-in, que é recuperado por escolha pelo seu usuário do aplicativo. (Observe, eu não sou um advogado. Esta é a minha própria interpretação técnica do vídeo Cisco H.264 e do acordo de licenciamento MPEG-LA. A última linha é, se você distribuir mais de 100.000 unidades, para qualquer licença de software ou pagar Estrutura, falar com um advogado. Menos que isso, não se preocupe muito.) Primeiro você precisa entender o legal em torno open264. Você não pode compilá-lo. Somente as versões compiladas pelo cisco são cobertas pela licença existente do ciscos. Você não pode distribuí-lo. Se você distribuir um aplicativo que o usa, ele não pode fazer parte do instalador. Seu aplicativo deve fazer o download do binário do cisco. Open264 é uma biblioteca, não um executável, Você precisa criar seu próprio executável. Você também vai precisar de bibliotecas para ler as imagens e convertê-los para o colorspace. Finally corretamente, O codificador cisco produz vídeo de qualidade muito ruim como apposed x264. Gostaria de sugerir apenas pagar por uma licença x264, bem como mpeg-la royalties. Eles provavelmente não são tão caros como você pensa. Respondida Feb 18 14 at 20:33 Isso pode ter sido correto no momento da escrita, mas atualmente openh264 (código-fonte, sic) é BSD-licenciado, então a maioria da resposta é baseada na base errada. Eu não sou um advogado, mas acredito que você pode compilá-lo e distribuí-lo, mas as taxas de MPEG-LA ainda se aplicam. Ndash Victor Sergienko Apr 7 14 at 12:49 Sim, você está correto. Você pode compilar e distribuir o código, mas VOCÊ deve então pagar mpeg-la. Porque o cartaz já mencionado ele não pode usar x264 devido ao licenciamento, os meus comentários são 100 correto dado o contexto da questão, mas de outra forma incompleta. Ndash szatmary Apr 10 14 at 17:19 Eu vejo. I39m tentando remover meu downvote (resposta precisa ser editada ainda). No entanto, acredito que a resposta não é completamente correta: não é possível distribuir x264 em um aplicativo de código fechado (sem pagar por ele, como x264 é dupla licenciado), período, mas um pode distribuir openh264 em um aplicativo de código fechado, enquanto ele paga Taxas de MPEG-LA. IANAL, ainda. Ndash Victor Sergienko Apr 10 14 at 19:22 Open264 pode produzir vídeo de menor qualidade, mas por outro lado, ele produz melhores córregos de vídeo. Open264 tem recursos como Flexible Macroblock Ordering (ver github) que x264 não suporta. Isso torna os vídeos openh264 melhores onde a rede pode não ser 100 (pacotes perdidos não significa necessariamente perder todo o fluxo de vídeo). Ndash timgws Jun 9 at 18: 03OpenH264 é uma biblioteca de codec que suporta a codificação e decodificação H.264. É adequado para uso em aplicações em tempo real, como WebRTC. Veja openh264.org/ para mais detalhes. Resolução de arbitragem, não restrita a múltiplos de 16x16 Controle de taxa com quantização adaptativa ou quantização constante Opções de fatia: 1 fatia por quadro, N fatias por quadro, N macroblocos Por fatia ou N bytes por fatia Múltiplos segmentos automaticamente usados ​​para várias fatias Escalabilidade temporal até 4 camadas em uma hierarquia diádica Simulcast AVC até 4 resoluções a partir de uma única entrada Simulação espacial simultânea até 4 resoluções de uma única entrada Referência de longo prazo (LTR ) Processo de gerenciamento de memória (MMCO) Referência modificação da lista de imagens Quadro de referência único para inter predição Múltiplos quadros de referência ao usar LTR e / ou 3-4 camadas temporais Decodificador periódico e a pedido Instantâneo Refresh (IDR) inserção de quadros Mudanças dinâmicas no bit Taxa de quadros e resolução Anexo B saída de fluxo de bytes YUV 4: 2: 0 entrada planar Constrained Baseline Profile até Nível 5.2 (tamanho máximo de quadro é 36864 macroblocos) Resolução arbitrária, não restrita a múltiplos de 16x16 Single thread para todos (MMCO) Referência de modificação da lista de imagens Múltiplas referências quando especificadas no Conjunto de Parâmetros de Seqüência (SPS) Anexo B entrada de fluxo de bytes YUV 4: 2: 0 saída planar Windows 64 bits e 32 Mac OS X 64 bits e 32 bits Linux 64 bits e 32 bits Android 64 bits e 32 bits iOS 64 bits e 32 bits Windows Phone 32 bits Intel x86 opcionalmente com MMX / SSE AVX ainda, a ajuda é bem-vinda) ARMv7 opcionalmente com NEON, AArch64 opcionalmente com NEON Qualquer arquitetura usando C / C fallback funções Construindo a Biblioteca NASM precisava ser instalado para o assembly código: workable versão 2.10.06 ou superior, NASM pode baixado do nasm. nos/. Para Mac OSX 64-bit NASM necessário para ser abaixo da versão 2.11.08 como NASM 2.11.08 introduzirá erro ao usar RIP-relativa endereços em Mac OSX 64-bit Para construir o braço assembly para Windows Phone, pré-processador de gás é necessária. Ele pode ser baixado do git: //git. libav. org/gas-preprocessor. git Para Android Builds Para construir para a plataforma android, você precisa instalar o android sdk e ndk. Você também precisa exportar ANDROIDSDK / tools para o PATH. No Linux, isso pode ser feito pelo codec e demo pode ser construído por ANDROIDTARGET válido pode ser encontrado em ANDROIDSDK / plataformas. Tal como o android-12. Você também pode definir ARCH. NDKLEVEL de acordo com o seu dispositivo ea versão NDK. ARCH especifica a arquitetura do dispositivo android. Atualmente braço. Arm64. X86 e x8664 são suportados, o padrão é braço. (Mips e mips64 também podem ser usados, mas não há nenhuma otimização específica para essas arquiteturas.) NDKLEVEL especifica android api nível, o padrão é 12. Possibilidades disponíveis podem ser encontradas em ANDROIDNDK / plataformas. Como o android-21 (remova o prefixo android). Por padrão, esses comandos são compilados para o armeabi-v7a ABI. Para criar as outras ABIs do Android, adicione ARCHarm64. ARCHx86. ARCHx8664. ARCHmips ou ARCHmips64. Para construir para o armeabi mais antigo ABI (que tem armv5te como linha de base), adicionar APPABIarmeabi (ARCHarm é implícito). Para construir para 64-bit ABI, como arm64. Definir explicitamente NDKLEVEL para 21 ou superior. Você pode construir as bibliotecas e aplicativos de demonstração usando arquivos de projeto xcode localizados em codec / build / iOS / dec e codec / build / iOS / enc. Você também pode criar as bibliotecas (mas não os aplicativos de demonstração) usando o sistema de compilação baseado em make a partir da linha de comando. Build with Valores válidos para ARCH são os nomes de arquitetura iOS normais, como armv7. Armv7s. Arm64. E i386 e x8664 para o simulador. Outro parâmetro iOS específico configurável é SDKMIN. Especificando o destino de implantação mínimo para a biblioteca compilada. Para obter mais detalhes sobre como criar usando make na linha de comando, consulte Para todas as plataformas abaixo. Para Windows Builds Nossas compilações do Windows usam MinGW que pode ser baixado do mingw. org/ Para criar com o gcc, adicione o diretório bin MinGW (por exemplo, / c / MinGW / bin) ao seu caminho e siga as instruções de Todas as plataformas abaixo. Para criar com o Visual Studio, você precisará configurar seu caminho para executar cl. exe. A maneira mais fácil é iniciar o MSYS a partir de uma sessão de linha de comando do desenvolvedor. As instruções podem ser encontradas em msdn. microsoft/en-us/library/ms229859(vvs.110).aspx. Se você precisar fazer isso à mão, aqui está um exemplo de uma instalação do Windows 64bit do VS2012: Você também precisará definir seus caminhos INCLUDE e LIB para apontar para as instalações VS e SDK. Algo como isto, novamente a partir do Win64 com VS2012 (observe o uso de caminhos do Windows-estilo aqui). Em seguida, adicione OSmsvc à linha make das instruções For All Platforms. Para Windows Phone Builds Siga as instruções acima para versões normais do Windows, mas use OSmsvc-wp em vez de OSmsvc. Você também precisará de pré-processador de gás (como mencionado abaixo Construindo a Biblioteca). Se construir para o Windows Phone com o MSVC 2013, não há nenhum arquivo de morcego incluído que define os caminhos de lib para o kit do Windows Phone, mas isso pode ser feito com um comando como este: Isso só é necessário para construir a DLL a biblioteca estática pode ser construída Sem definir isso. Para todas as plataformas Do diretório principal do projeto: fazer para detectar automaticamente a arquitetura ea construção de acordo fazer ARCHi386 para construções x86 de 32 bits fazer ARCHx8664 para construções x86 de 64 bits fazer VNo para uma compilação silenciosa (não mostrando os comandos do compilador real) make DEBUGSYMBOLSTrue for Duas bibliotecas, uma é bibliotecas normais, outra é removida as entradas da tabela de símbolos de depuração (aquelas criadas pela opção - g) Os programas de linha de comando h264enc e h264dec aparecerão no diretório principal do projeto. Um script de shell para executar os aplicativos de linha de comando está em testbin / CmdLineExample. sh As informações de uso podem ser encontradas em testbin / CmdLineReadMe Usando o codec de origem - codificador, decodificador, console (app de teste), build (makefile, vcproj) build - scripts Para teste de sistema de compilação Makefile - arquivos de testtest de GTest testbin - scripts de construção automática, arquivos de configuração de app de teste res - yuv e arquivos de teste de fluxo de bits Erros de codificador quando a resolução excede 3840x2160 Codificador de erros quando o tamanho de quadro comprimido excede o tamanho de metade descompactado RC requer saltar quadro para ser habilitado para bater a taxa de bits alvo, se saltar quadro é desativado a taxa de bits alvo pode ser excedido BSD, consulte o arquivo LICENSE para obter detalhes.