Banco de dados de mídia da Netflix – o modelo de dados da linha de tempo de mídia

Netflix Technology Blog Blocked Unblock Seguir Seguindo 31 de outubro de 2018

No post anterior desta série, descrevemos alguns negócios importantes Netflix necessidades, bem como as características do sistema de dados de mídia – chamado de “N etflix M EDIA D ata B ase” (NMDB) que é utilizado para resolvê-los. O curioso leitor pode ter notado que a maioria dessas características está relacionada às propriedades dos dados gerenciados pelo NMDB. Especificamente, dados estruturados que são modelados em torno da noção de uma linha de tempo de mídia, com propriedades espaciais adicionais. Esta postagem do blog detalha a estrutura do modelo de dados de linha de tempo de mídia usado pelo NMDB chamado de “ Documento de Mídia ”.

O modelo de documento de mídia

O modelo de documento de mídia deve ser uma estrutura flexível que pode ser usada para representar metadados estáticos e dinâmicos (variando com tempo e espaço) para várias modalidades de mídia. Por exemplo, gostaríamos de poder representar (1) informações de cor e luminosidade por quadro para um arquivo de vídeo com taxa de quadros NTSC de 29,97 fps, (2) informações de estilo e layout de legendas em um arquivo de texto cronometrado que esteja usando unidades de a " base de tempo de mídia ", bem como (3) atributos espaciais de modelos 3D variáveis no tempo gerados por artistas de efeitos visuais , todos com precisão total nas dimensões temporais e espaciais.

O modelo de documento de mídia é projetado para ser versátil, para permitir a representação de vários tipos de documentos, desde documentos resultantes da análise de um fluxo de vídeo codificado e contendo pontuações VMAF até documentos que fornecem informações sobre eventos que ocorrem simultaneamente em vários fluxos de texto cronometrados. , para documentos que fornecem informações estruturadas sobre uma série de imagens DPX que formam um clipe de filme. Para satisfazer todos esses casos de uso, o documento de mídia se baseia em alguns princípios básicos detalhados a seguir.

Modelo de Tempo

Usamos o modelo de documento de mídia para representar metadados cronometrados para nossos ativos de mídia. Por isso, projetamos isso principalmente em torno da noção de eventos cronometrados. Os eventos cronometrados podem ser usados para representar cronogramas intrinsecamente "periódicos" e "baseados em eventos". A Figura 1 visualiza uma sequência periódica de quadros de vídeo sucessivos. O evento de interesse, neste caso, é um evento de mudança de tiro que ocorre após o terceiro quadro.

Figura 1: Uma seqüência de quadros de vídeo que abrangem uma mudança de tiro

Um snippet de instância de documento de mídia correspondente à Figura 1 pode ser o seguinte.

 { 

“Eventos”: [
{
"StartTime": T0,
"EndTime": T1,
"Metadados": {
“ShotEnvironment”: “ao ar livre”
}
}
{
"StartTime": T1,
"Fim do tempo": T2,
"Metadados": {
“ShotEnvironment”: “dentro de casa”
}
}

]

}

Os eventos cronometrados são semelhantes aos eventos de legenda TTML (Timed Text Markup Language), mas com a principal diferença de que, no caso do documento de mídia, esses eventos não devem ser exibidos para os usuários finais. Em vez disso, eles representam metadados sobre o ativo de mídia, que corresponde ao intervalo de tempo especificado. Em nosso modelo, fizemos a escolha de que todos os eventos em uma determinada instância de documento de mídia correspondam a uma única linha de tempo, correspondendo à linha do tempo do recurso de mídia (gostaríamos de salientar que o modelo de tempo do documento de mídia é equivalente ao modelo de tempo associado com o elemento par da especificação SMIL .). Um objetivo por trás dessa escolha é facilitar as consultas cronometradas, dentro de uma instância do documento (“ fazer com que todos os eventos ocorram entre 56 segundos e 80 segundos no filme ”), mas também em instâncias de documentos (“ há legendas ativas em todos os idiomas de um filme? entre 132 segundos e 149 segundos no filme? ”).

Figura 2: Uma linha de tempo de mídia correspondente aos eventos de legenda

Em nosso modelo, cada evento ocupa um intervalo de tempo na linha do tempo. Nós não fazemos nenhuma suposição sobre como os eventos estão relacionados. Por exemplo, nos arquivos de formato de arquivo de mídia base ISO (BMFF) , os exemplos podem não se sobrepor e são contíguos em uma faixa. No modelo de documento de mídia, no entanto, os eventos podem se sobrepor. Também pode haver lacunas na linha do tempo, isto é, intervalos sem eventos. A Figura 2 mostra uma linha de tempo de legendas baseada em eventos, em que alguns dos intervalos não têm eventos. Um trecho de instância de documento de mídia correspondente à Figura 2 poderia ser o seguinte.

 { 

“Eventos”: [
{
"StartTime": T0,
"EndTime": T1,
"Metadados": {
“Subtítulo”: “Olá! Como você está?"
}
}
{
"StartTime": T2,
"EndTime": T3,
"Metadados": {
"Subtítulo": "Obrigado por perguntar - eu sou bom. Como você está?"
}
}
{
"StartTime": T4,
"EndTime": T5,
"Metadados": {
"Subtítulo": "Muito bem - muito obrigado!"
}
}
]

}

Modelo Espacial

Assim como o modelo de temporização, um documento de mídia é associado a um único espaço de coordenadas espaciais e os eventos podem ser qualificados por atributos espaciais, fornecendo detalhes sobre onde o evento ocorre nesse espaço de coordenadas. Isso nos permite oferecer consultas espaciais (“ faça com que todos os eventos apareçam nessa região do ativo de mídia em todo o filme ”) ou consultas espaço-temporais (“ faça todos os eventos acontecerem durante determinado (s) intervalo (s) de tempo em determinada região ”).

Figura 3: Uma seqüência de quadros de vídeo em que a região espacial de interesse varia ao longo do tempo

A Figura 3 mostra a visualização de uma linha do tempo de vídeo composta por dois eventos temporais separados por uma mudança de cena. Dentro de cada evento temporal, uma região espacial diferente (correspondente a uma face humana e ilustrada com um retângulo colorido) forma a região de interesse. Uma instância completa do documento de mídia correspondente a essa linha de tempo de mídia é mostrada no final desta seção.

Estrutura aninhada

Inspirado nos formatos de contêiner de mídia líderes do setor, como o IMF ( Interoperable Master Format ) do SMPTE ou ISO BMFF, o modelo do documento de mídia agrupa eventos que possuem propriedades semelhantes. Dois níveis aninhados de agrupamento estão disponíveis: faixas e componentes . Nosso modelo é flexível: dois eventos abrangendo um intervalo comum de uma linha do tempo podem ser colocados no mesmo componente, ou em dois componentes diferentes da mesma faixa, ou até mesmo em componentes de trilhas diferentes.

A semântica de componentes e trilhas pode ser definida livremente pelo autor da instância do documento de mídia. Em uma instanciação típica para ativos de mídia multiplexados, uma instância de documento de mídia conteria um elemento de trilha por modalidade de mídia no ativo de mídia, ou seja, uma instância de documento de mídia para um recurso de áudio-vídeo teria duas faixas. Tal cenário é ilustrado na Figura 4 para um ativo que contém a modalidade de áudio, vídeo e texto.

Figura 4: Uma linha de tempo de mídia composta por várias faixas

Como foi mencionado acima, um snippet de instância de documento de mídia correspondente à Figura 4 poderia ser o seguinte.

 { 
...
"faixas": [
{
"id": "1",
"metadados": {"type": "video"},
...
}
{
"id": "2",
"metadados": {"type": "audio"},
...
}
{
"id": "3",
"metadados": {"type": "text"},
...
}
]
}

Como alternativa, para um recurso de áudio multicanal, a instância do documento de mídia teria uma trilha, mas dentro da trilha, um elemento de componente separado forneceria os metadados e eventos para cada canal, como mostra a Figura 5.

Figura 5: Uma linha de tempo de mídia que mostra vários componentes pertencentes a uma única trilha

Um trecho de documento de mídia correspondente à Figura 5 poderia ser o seguinte.

 { 
...
"faixas": [
{
"id": "1",
"metadados": {"type": "stereo audio"},
"componentes": [
{
"id": "0",
"metadados": {"canal": "esquerda"},
...
}
{
"id": "1",
"metadados": {"canal": "direita"},
...
}
]
}
]
}

A estrutura aninhada geral de um documento de mídia é mostrada na Figura 6. Cada nível exige que os autores especifiquem informações comuns (obrigatórias) para todas as instâncias do documento de mídia (um id em cada nível, unidades de resolução temporal e espacial no nível de componente, tempo informações de intervalo no nível do evento, informações espaciais no nível da região). Além disso, cada nível permite que os autores forneçam metadados específicos para cada tipo de documento de mídia em cada nível (por exemplo, pontuação VMAF para cada quadro no nível do evento ou média no nível do documento ou informações de intensidade para áudio em um componente ou nível de faixa ).

Figura 6: Hierarquia de estrutura de dados do documento de mídia

Embora uma instância de documento de mídia possa ser representada em qualquer um dos formatos de serialização populares, como JSON , Google Protocol Buffers ou XML , usamos JSON como o formato preferido. Isso decorre, em parte, do uso comum do JSON como formato de carga útil entre diferentes sistemas baseados na web. Mais importante ainda, muitos dos populares bancos de dados distribuídos de indexação de documentos, como o Elasticsearch e o MongoDB, trabalham com documentos JSON. A escolha de JSON como nosso formato de serialização abre a possibilidade de usar qualquer um desses bancos de dados de documentos escalonáveis para indexar as instâncias do documento de mídia. Observe que a indexação das informações do intervalo de tempo no nível do evento, bem como as informações espaciais no nível da região, fornece a capacidade de consulta espaço-temporal pronta para uso.

O exemplo a seguir mostra uma instância completa do documento de mídia que representa os metadados de detecção de face pela linha do tempo da sequência de vídeo mostrada na Figura 3. A sequência de vídeo em questão é uma sequência de vídeo de alta definição (resolução espacial 1920×1080) com uma taxa de quadros de 23,976 quadros por segundo. Compreende dois eventos temporais distintos. Cada um desses eventos contém uma única região espacial de interesse que corresponde ao retângulo da caixa delimitadora para um rosto humano detectado.

 { 
"metadados": {
"algoritmo": "video_face_detection"
}
"faixas": [
{
"id": "0",
"componentes": [
{
"id": "0",
"eventRateNumerator": 24000,
"eventRateDenominator": 1001,
"xSize": 1920,
"ySize": 1080,
"eventos": [
{
"startTime": 0,
"endTime": 2,
"regiões": [
{
"xmin": 1152,
"xmax": 1536,
"ymin": 108,
"ymax": 648
}
]
}
{
"startTime": 3,
"endTime": 4,
"regiões": [
{
"xmin": 576,
"xmax": 960,
"ymin": 108,
"ymax": 648
}
]
}
]
}
]
}
]
}

O Esquema do Documento de Mídia

A seção anterior apresentou os princípios básicos do modelo do documento de mídia. Os objetos do documento de mídia são amplamente usados em vários fluxos de trabalho de processamento de mídia da Netflix. A seguir, um ciclo de vida típico:

  1. um algoritmo de processamento de mídia, executado, por exemplo, na plataforma Archer , produz uma instância de documento de mídia de um tipo específico, dentro da qual as partes de metadados contêm metadados específicos do domínio (por exemplo, caixas delimitadoras para texto em quadros de vídeo);
  2. a instância do documento de mídia é ingerida, persistida e indexada no NMDB;
  3. um usuário do NMDB consulta um conjunto de instâncias específicas do documento de mídia com características semelhantes. Normalmente, essas são consultas espaço-temporais com características adicionais específicas do domínio (por exemplo, “localizar todas as ocorrências de texto no meio da tela”)
  4. APIs específicas de domínio são usadas para expor instâncias específicas do documento de mídia aos usuários de recebimento de dados.

Para sustentar esse ciclo de vida na escala Netflix, percebemos que era necessário adotar uma abordagem de “esquema na escrita”. Nesta abordagem, todo tipo de documento de mídia está associado a um esquema. Todas as instâncias do Documento de Mídia de um tipo específico que são submetidas ao NMDB passam pela primeira validação no esquema definido para esse tipo. Uma instância do documento de mídia é rejeitada se não estiver em conformidade com as regras de validação. Mais especificamente, decidimos expressar nossas regras de validação usando um subconjunto da sintaxe do esquema JSON. Por isso, primeiro pede-se a um produtor de instâncias do documento de mídia que forneça o esquema JSON que descreve a estrutura do tipo de documento de mídia associado. Essa abordagem leva a vários benefícios:

  • Podemos garantir que todas as instâncias do documento de mídia associadas a um domínio sejam estruturadas de forma semelhante. Isso nos permite escrever consultas específicas de domínio e obter resultados consistentes. Por exemplo, se todas as instâncias de documentos de mídia que representam conteúdo de legenda seguem a mesma estrutura (por exemplo, um elemento de corpo TTML contendo um elemento div contendo um elemento p contendo elementos de span ), é possível fazer uma consulta solicitando todos os eventos TTML que usam ruby anotação , e a consulta pode ser executada em uma instância do documento de mídia ou no conjunto inteiro nesse domínio.
  • Podemos garantir que, para o mesmo tipo de documento de mídia, uma propriedade de um determinado nome em um determinado local na árvore de documentos seja de um tipo preciso e não de uma string de propósito geral. Isso permite, por exemplo, impor o tipo de uma propriedade que é de natureza numérica para ser um tipo numérico. Poder-se-ia então realizar consultas de alcance contra a propriedade (especificamente, escolhemos cuidadosamente um subconjunto do esquema JSON para garantir que nenhum elemento possa ter uma definição ambígua ou permitir interpretações incompatíveis, ou seja, cada objeto é especificado em seus tipos primitivos, que inclua string , booleano , número e inteiro . Na ausência de esquema, a leitura de uma instância do Documento de Mídia pode degradar algo como o seguinte pseudocódigo. Tal implementação fica difícil de manter a partir de uma perspectiva de software e resulta em menor desempenho de leitura.
 if (property1 instanceOf String) { 

} else if (property1 instanceOf Integer) {

} else if (property1 instanceOf Boolean) {

if (property2 instanceOf Double) {

} else if (property2 instanceOf List) {

}

}
  • Podemos fornecer automaticamente APIs fortemente tipificadas que permitem o consumo de instâncias de documentos de mídia de um tipo específico. Os usuários do NMDB estão livres de ter que escrever código para analisar as instâncias do documento de mídia e são fornecidos com código fortemente tipado para processá-los e propor APIs específicas do domínio.

Além disso, como os desenvolvedores exigem flexibilidade em suas definições de documentos de mídia e geralmente precisam evoluir seus metadados específicos de domínio ou, em geral, seus tipos de documentos de mídia específicos ao domínio, permitimos a atualização do esquema do documento de mídia. No entanto, para manter os benefícios indicados acima, temos atualizações limitadas no esquema apenas para a adição de campos opcionais. Isso garante a compatibilidade com versões anteriores e posteriores entre as instâncias do documento de mídia e os leitores de documentos de mídia, ao mesmo tempo em que mantém a estabilidade da indexação e da consulta da instância do documento de mídia. Em poucas palavras, essa escolha de design ajudou a facilitar a adoção do sistema NMDB, ao mesmo tempo que nos permite operar o NMDB em grande escala. Finalmente, quando uma mudança de esquema não compatível é necessária, pode-se criar um novo tipo de documento de mídia.

Qual é o próximo

Na próxima postagem do blog, aprofundaremos nossa implementação do sistema NMDB. Discutiremos nossas escolhas de projeto para obter os requisitos de disponibilidade de serviço e escala de serviço que surgem das necessidades de negócios da Netflix.

– por Subbu Venkatrav, por Arsen Kostenko, por Shinjan Tiwary, por Sreeram Chakrovorthy, por Cyril Concolato, por Rohit Puri e por Yi Guo

Texto original em inglês.