Programando em NCL 3.0.pdf - Telemidia - PUC-Rio
Programando em NCL 3.0.pdf - Telemidia - PUC-Rio Programando em NCL 3.0.pdf - Telemidia - PUC-Rio
Apêndice GHTGA apresentação com qualidade de uma aplicação NCL depende de uma sériede procedimentos de escalonamento que devem ser realizados tanto pelosreceptores quanto pelos provedores de conteúdo das aplicações.Para a realização desses procedimentos, estruturas de dados específicasdevem ser computadas. Este apêndice traz uma discussão a respeito dessasestruturas de dados e de como elas podem ser deduzidas de uma outraestrutura de dados única chamada HTG (Hypermedia Temporal Graph).518
G.1 EscalonadoresComo já discutimos em diversas parte do livro, nas aplicações em que osincronismo depende da ocorrência de eventos com duração variável oumesmo imprevisível no momento da especificação, é imperativo que essaespecificação seja realizada de forma relativa à ocorrência desses eventos,isto é, independentemente do momento temporal em que eles ocorrem e se defato eles ocorrerem. É nesse paradigma orientado a eventos que se baseia alinguagem NCL e a sua linguagem de script Lua.Quando o sincronismo é especificado de forma relativa, os instantestemporais de ocorrência dos eventos somente serão conhecidos na fase deexecução da aplicação.O uso do paradigma orientado a eventos traz não só o problema decomo especificar relacionamentos temporais e espaciais entre eventos,solucionados pelo uso de NCL, como dois outros problemas adicionais:1) como controlar a execução de uma aplicação de forma a garantir que osrelacionamentos especificados sejam respeitados;2) como gerenciar as transmissões, dos servidores de conteúdos para osclientes receptores, mantendo uma qualidade de serviço tal que garanta que osconteúdos estejam presentes no receptor nos momentos necessários de suasapresentações.O primeiro problema diz respeito apenas aos receptores das aplicações evai exigir o trabalho complementar de dois escalonadores na implementaçãodo formatador NCL.O primeiro escalonador (“escalonador de exibidores”) é responsável porinstanciar os vários exibidores de mídia, de forma que eles estejam prontosnos momentos necessários à apresentação dos vários objetos. Esse trabalhonão é simples porque, devido à limitação de memória da maioria dosdispositivos receptores para TV, é importante manter o mínimo decomponentes exibidores instanciados ou mesmo na memória principal (RAM)do receptor.O segundo escalonador (“escalonador de apresentação”) é o núcleocentral do formatador, sendo responsável por entregar os conteúdos a seremapresentados pelos exibidores de mídia em um dado instante. Em outraspalavras, é esse escalonador que de fato resolve todos os relacionamentos desincronismo temporal em tempo de execução, transformando os temposrelativos dos relacionamentos em tempos absolutos.Entre os vários problemas que deve tratar, o escalonador deapresentação deve permitir que uma aplicação inicie a partir de qualquerponto de sua cadeia temporal de exibição de objetos. Isso é muito importanteem aplicações para TV digital, por exemplo, na qual um serviço ou canal519
- Page 507 and 508: Outro tipo especial de nó de conte
- Page 509 and 510: Note que a definição de dois tipo
- Page 511 and 512: 2..nidRule1..* ruleList1..*0..10..*
- Page 513 and 514: podem ser estendidas: evento de exi
- Page 515 and 516: Um evento de apresentação pode mu
- Page 517 and 518: C.9.1 ConectoresA Figura C.6 ilustr
- Page 519 and 520: RoleideventTypeminCardinalitymaxCar
- Page 521 and 522: condição ou avaliação, quanto u
- Page 523 and 524: opcionalmente negada. Qualquer expr
- Page 525 and 526: de estados de eventos, a ideia é f
- Page 527 and 528: Por outro lado, a exibição do nó
- Page 529 and 530: C.10 Objetos de Dados XObjetos de R
- Page 531 and 532: O NCM define uma classe descritor g
- Page 533 and 534: navegação em um documento. Usuár
- Page 535 and 536: i) ela pode conter nós de conteúd
- Page 537 and 538: D.1 Conectores CausaisNo Capítulo
- Page 539 and 540: Listagem D.1 Exemplo de base de con
- Page 541 and 542: E.1 IntroduçãoUm receptor pode co
- Page 543 and 544: Como mencionamos, um NPT pode come
- Page 545 and 546: F.1 IntroduçãoComo mencionamos no
- Page 547 and 548: Assim, quando um comando de ediçã
- Page 549 and 550: carrossel de objetos diferente daqu
- Page 552 and 553: documento XML representando o metad
- Page 554 and 555: Sistema de Arquivo LocalC:\nclRepos
- Page 556 and 557: Tabela F.4 Indicação de Fragmento
- Page 560 and 561: pode ser sintonizado em qualquer in
- Page 562 and 563: As condições podem ser simples ou
- Page 564 and 565: condição de percurso de uma arest
- Page 566 and 567: propaganda é inserida no meio de u
- Page 568 and 569: passa a construir o grafo temporal
- Page 570 and 571: Apêndice HComportamento deExibidor
- Page 572 and 573: A instrução start emitida por um
- Page 574 and 575: associado ao elemento, mesmo se out
- Page 576 and 577: H.2.1.3 Instrução abortNo caso de
- Page 578 and 579: deve ser realizado por instruções
- Page 580 and 581: Para objetos de mídia com código
- Page 582 and 583: No caso de objetos de mídia com c
- Page 584 and 585: Se a composição contiver elos sen
- Page 586 and 587: ncl-NCL”, todas as portas do docu
- Page 588 and 589: Se o objeto de mídia com código d
Apêndice GHTGA apresentação com qualidade de uma aplicação <strong>NCL</strong> depende de uma sériede procedimentos de escalonamento que dev<strong>em</strong> ser realizados tanto pelosreceptores quanto pelos provedores de conteúdo das aplicações.Para a realização desses procedimentos, estruturas de dados específicasdev<strong>em</strong> ser computadas. Este apêndice traz uma discussão a respeito dessasestruturas de dados e de como elas pod<strong>em</strong> ser deduzidas de uma outraestrutura de dados única chamada HTG (Hypermedia T<strong>em</strong>poral Graph).518
Change language