Convertendo vídeos do Decodificador de TV Digital/PVR LB-SAT LBDTV10T para AVI no Linux

Com o surgimento da TV Digital no Brasil, no seu padrão ISDB-Tb (ou ISDB-International), vários conversores estão sendo vendidos a preços interessantes com a mais diversa gama de recursos. Um muito popular é o recurso de PVR (Personal Video Recorder – Gravador Pessoal de Vídeo), onde o aparelho grava em um disco rígido externo ou pendrive à programação de TV, como era o caso nos antigos videocassetes. No caso, iremos falar do decodificador LBDTV10T, da empresa LBSat. Esse é um produto a um preço razoável e que pode ser encontrado em boas casas especializadas em equipamento de TV (no caso, comprei em uma loja da Rua Vitória, uma das travessas da Santa Efigênia), e possui as seguintes características.

Características:

  • HDTV e SDTV
  • Instalação automática de canais
  • Menu na tela (OSD) – facilita a configuração do aparelho.
  • Saída HDMI para imagens em alta definição e áudio digital
  • Saídas S-Video, Vídeo Componente, vídeo e áudio estéreo
  • Saída de áudio digital óptica e SPDIF
  • EPG (Guia de Programação Eletrônica) Permite visualizar informações sobre os programas da TV. (Este recurso depende da transmissão pela emissora)
  • Programação de canais favoritos
  • Sintonia automática UHF para TV Digital – Canais 7 ao 69
  • Controle Remoto multifunção
  • Ajustes de Áudio / Vídeo / Volume
  • Seleção automática de voltagem – entre 100 e 240 Vac
  • Idiomas do menu: Português

Observações:
Antes de comprar o conversor, certifique-se de que a sua região já recebe as transmissões da TV Digital. Para captar o sinal digital corretamente é necessária a utilização de uma antena UHF, interna ou externa. A captação é restrita aos sinais da TV aberta, não incluindo, portanto, os sinais de TV por assinatura.
Especificações:

  • Resolução de vídeo : 1080i / 720p / 576i
  • Conexão USB para : MP-3, MP-4, Fotos. Através dela é possível reproduzir arquivos de músicas em MP-3, de vídeo MPEG-2, MPEG-4, e exibir arquivos de fotos JPEG.
  • Formatos de Tela : 16:9 e 4:3

É ótimo poder gravar vídeos em um HD externo, ainda mais se pensarmos que esses arquivos são acessíveis pelo computador como arquivos normais de vídeo. O problema é que a maior parte dos decodificadores (esse incluído) gravam o stream DTV recebido da antena diretamente (como se usasse um tee entre a saídea de vídeo e um arquivo no HD externo), o que envolve formatos proprietátios estranhos e convenções um pouco complexas. Mas com a ajuda do Google e do pessoal do Clube do LBDTV10T no HT-Fórum. Ainda não foi possível automatizar o processo devido a alguns problemas com o arquivo do decodificador, em especial na parte de áudio, mas tentarei fazer o melhor possível para expĺicar detalhadamente o processso de modo que você possa converter adequadamente os seus vídeos para usá-los no computador.
Esse tutorial foi elaborado em um Intel Core 2 Duo 2GHz, 3GB de RAM, 320 GB de disco, Ubuntu Linux Karmic Koala (9.10), com o repositório Medibuntu original e todos os pacotes de vídeos e áudio, incluindo os non-free e restricted. Você precisará ter instalado mencoder, mplayer, VLC e ffmpeg. Uma vez dito isso, vamos começar o processo.

1-) Encontrando o vídeo no disco e preparando-o para codificação

A primeira parte é encontrar e prepara o vídeo. Nesse caso, existe apenas uma sugestão: limpe o disco pelo decodificador (MENU -> Meu de Função -> Função PVR -> Formatar HDD). Caso contrário, você terá que descobrir o arquivo em meio aos diversos vídeos gravados e o modo como os vídeos são nomeados internamente pelo decodificador não ajuda. Os arquivos ficam gravados em uma pasta dentro do HD chamada PVR, em diretórios com o nome PVRXXXXX, (onde X são números hexadecimais), Dentro dessas pastas, existem pastas ~DATA/, onde vários arquivos DATAXX.trp (onde X são números normais). Esses arquivos são as várias partes do vídeo gravadas pelo decodificador. Isso ocorre pois, como ele formata os discos em FAT32 para maior eficiência, o tamanho máximo do arquivo é de 2 GB. Quando esse valor é superado, o decodificador cria um novo arquivo. Nesse caso, iremos fundir os arquivos com o seguinte comando em um terminal, dentro da pasta ~DATA/ do vídeo: cat DATA00.trp DATA01.trp DATA02.trp ... DATAXX.trp > convert.trp. Caso o vídeo tenha menos partes, basta usar menos arquivos. É só lembrar de listar todos os arquivos DATAXX.trp nesse comando. PS: não faça isso no disco do PVR! Copie os arquivos para uma partição Ext3/ext4/NTFS ou outro formato de arquivos mais avançado, caso contrário continuará com a limitação do tamanho de arquivo e não funcionará. Um comando alternativo seria cat DATA*.trp > convert.trp, mas não existe como garantir a seqüência dos arquivos.
Trabalharemos no caso com esse arquivo convert.trp. Ele é um arquivo em um formato chamado Transport Stream (TS), um encapsulamento do MPEG-2 para a transmissão contínua de arquivos, E conterá vídeo e áudio. Esse tutorial não irá aprofundar nos mecanismos de extração de áudio, uma vez que o TS permite vários canais de áudio e isso é usado em especial em vídeos (onde você pode colocar um canal de áudio em porutugês e um no idioma nativo do programa). No caso, nos restringiremos ao uso mais simples possível desse tutorial.

2-) Demultiplexação do vídeo original:

Um problema com o sistema de TV Digital Brasileiro é que ele utiliza na camada de áudio o formato HE-AAC, que não é muito bem suportado tanto por FFMpeg quanto por MPlayer/mencoder, os principais mecanismos de codificaçaão/decodificação/reprodução de vídeos e áudios em Linux. Porém, ele funciona muito bem no VLC e isso permite que utilizemos tal player para codificar o áudio.
A primeira parte então é demultiplexar o vídeo original, ou seja, separar as partes de vídeo e áudo do TS para que possamos trabalhar calma e corretamente com cada arquivo sem maiores problemas. No final desse processso, teremos um arquivo .mp4 (MPEG-4 AVC H264) e um outro arquivo de áudio .aac (MPEG-4 HE-AAC). Para esse processo, utilizaremos o Mplayer. Abra um terminal e, dentro da pasta ~DATA/ do vídeo desejado, use os seguintes comandos:

mencoder convert.trp -o convertVideo.mp4 -demuxer lavf -nosound -ovc copy
mplayer -dumpaudio -dumpfile convertAudio.aac convert.trp

Nesse momento, podemos reproduzir o vídeo no sistema para (1) testar se a demulplexação foi bem-sucedida e (2) verificar se o arquivo é o desejado. Para isso, digite mplayer convertVideo.mp4 e veja se está OK. Tudo OK, vamos para começar a trabalhar os arquivos.

3-) Codificação do áudio:

Um problema de fazer o processo de demultiplexação dos arquivos é que precisaremos optar por formatos de vídeo e aúdio individuais dos formatos de vídeo desejados, sem podermos recorrer a templates e outros esquemas que associem o vídeo e áudio a um formato. No caso, utilizaremos o AVI com vídeo XviD e áudio MP3. Nesse processo, iremos codificar cada parte separadamente e depois iremos multiplexar os arquivos no arquivo final, juntando ambos os arquivos de vídeo e áudio em uma saída final.
No caso, vamos focar primeiro na codificação do áudio, que iremos fazer usando o VLC. Esse passo justamente é o que impede criar-se um script para automatizar a codificação do arquivo, uma vez que VLC é um programa em iterface gráfica. Então, vamos ao passo a passo:

  1. Abra o VLC e vá no menu Mídia e escolha a opção Converter/Salvar;
  2. Na Aba Arquivo, clique em Adicionar. Na caixa de diálogo de arquivos, vá até a pasta PVRXXXXX/~DATA do vídeo desejado e escolha o arquivo convertAudio.aac desse ~DATA;
  3. Clique em Converter/Salvar. Na janela que abrir, na seção Configurações, escolha o perfil “Áudio – MP3“;
  4. Copie o conteúdo de Fonte (onde deverá ter o caminho completo para o arquivo de origem convertAudio.aac) para Destino e modifique a extensão para .mp3, de modo que fique convertAudio.mp3;
  5. Clique em “Iniciar“. Se quiser verificar as configurações, clique no ícone de chave de fenda, que irá apresentar as informações de codificação de áudio;

Agora, aguarde o arquivo ser codificado pelo VLC. Se preferir, teste o arquivo de saída com mpg123 convertAudio.mp3. Tudo estando OK, é hora de codificar o vídeo e encerrar o serviço.

4-) Codificar o vídeo e obter o arquivo final:

Agora codificado o áudio de saída em MP3, é hora de codificar o vídeo para XviD. No caso, também usaremos o mencoder para codificar o arquivo de saída de vídeo. Para isso, use o seguinte comando em um terminal na pasta PVRXXXXX/~DATA do vídeo desejado:

mencoder -o convertVideo.avi -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=5000 -vf scale -zoom -xy 720 convertVideo.mp4

No caso, setei algumas poucas opções, entre elas -vf scale -zoom -xy 720, que permite codificar corretamente o vídeo para 720p. Se você preferir outras opções, dê uma pesquisada na Internet que configurações possam ser ajustadas para melhor resultado. O único objetivo aqui é obter uma saída de qualidade razoável. Atenção: esse comando foi baseado em sugestões para ripping de DVD obtidas em sites na Internet. Não sou um especialista em codificação de vídeos e não saberia informar a melhor combinação de parâmetros.
Se desejar, teste o vídeo no Mplayer como fizemos anteriormente. Uma vez tudo OK, você pode multiplexar (juntar) os arquivos de vídeo e áudio em um arquivo de saída com os comandos abaixo:

ffmpeg -i convertVideo.avi -i convertAudio.mp3 -acodec copy -vcodec copy convertFinal.avi
ou
mencoder -oac copy -ovc copy -o convertFinal.avi -audiofile convertAudio.mp3 convertVideo.avi

O resultado é o arquivo AVI com o nome convertFinal.avi. Esse arquivo é o resultado final, que poderá ser usado em outros formatos e gerar DVD e afins. Não vou entrar nesses méritos, mas muita documantação pode ser encontrada na Internet. Também não foi testado se a saída possui ou não perda de sincronismo entre o áudio e o vídeo. Aparentemente isso pode acontecer ocasionalmente e infelizmente não existe uma solução simples nesse caso. O que pode-se sugerir caso isso ocorra é ajustar-se o arquivo de áudio MP3, removendo alguns milisegundos de seu início e depois multiplexar novamente o vídeo.
Espero que esse tutorial tenha sido útil e que você possa obter o melhor de seu decodificador de TV Digital.

WSIS: Sociedade da Informação

Reblog de um artigo meu antigo, em cooperação com o Carlísson Galdino.


Todos sabemos do impacto da Internet no cenário sócio-político-econômico mundial. Alguns afirmam que a Internet é uma aldeia global, e de certa forma ela é. Porém, como em toda aldeia, existe muito ainda a ser decidido. Se por um lado abriu novos mercados e modos de comunicação, pelo outro gerou cybercrime, pirataria e outros assuntos problemáticos.
Com esse objetivo, a ONU propôs uma discussão sobre o assunto, a WSIS (World Summit of Information SocietyCúpula Mundial da Sociedade da Informação), com a participação de todos os países membros da ONU.
Vários temas que serão tratados nessa cúpula são importantes e polêmicos, envolvendo assuntos como Inclusão Digital, Governança Eletrônica, Cybercrime, Pedofilia, Racismo, Software Livre, Copyright, Multiculturalismo e desenvolvimento sustentável.
A primeira rodada, em Genebra, já mostrava que a discussão seria complicada. De um lado, os Estados Unidos e os países do G8 querendo travar a discussão da WSIS às questões do cybercrime, copyright e tarifações. Já um outro bloco, formado pelo Brasil e alguns países do chamado G20 (o bloco dos países em desenvolvimento), incluindo China, Índia e África do Sul, procurando descentralizar o poder da Net e propor idéias para Multiculturalismo, Inclusão Digital (principalmente fugindo do modelo tradicional e usando soluções livres e baseadas em formatos abertos).
O debate foi acirrado, mas no final das contas o grupo do G20 foi bem sucedido na colocação de idéias como a descentralização do controle da Internet e outras.
A próxima rodada, a se realizar entre os dias 16 a 18 de Novembro de 2005, será o tira-teima e poderá representar um grande avanço ou uma grande guinada de rumos para a internet.
Vamos resumir alguns pontos que podem não estar muito claros para a maioria das pessoas.

Governança Eletrônica

A idéia por trás da Governança Eletrônica é que cada país possa gerenciar seus tráfegos de Internet, ao mesmo tempo em que nenhum deles detenha o controle absoluto da Internet.
Os problemas nesse caso chamam-se DNS (Domain Name ServicesServiços de Nome de Domínio) e ICANN (Internet Corporation for Assigned Names and NumbersCorporação para a distribuição de nomes e números de Internet). Falemos primeiro de DNS.
Esse sistema, o DNS, funciona como uma espécie de “agenda telefônica” que traduz nomes de sites legíveis por pessoas (como http://www.google.com.br) para números IP que os computadores possam usar para procurar tais páginas (como 64.233.187.104). Para evitar a sobrecarga em um único servidor, ele é construído de uma maneira que cada um dos domínios (cada trecho antes de um ponto) seja descentralizado. Antes do último domínio (nesse caso, o “.br”), existem servidores chamados root servers (servidores raiz) que são o início de tudo, onde as pesquisas começam.
O grande problema é que os root servers atualmente são 10, sendo que destes, 7 são americanos, dos quais 4 são militares. Os outros 3 estão na Alemanha, na Suiça e no Japão.
Parece não ser grande problema, mas bastaria, por exemplo, um desses países apagar a entrada para o domínio de um país em guerra (por exemplo, o domínio .br) e aquele país ficaria isolado, ou ao menos MUITO mais difícil de ser alcançado.
As sugestões, principalmente do G20, é de que esses root servers sejam distribuídos, espalhados pelo mundo, ajudando na descentrazação. Isso impediria que uma exclusão americana pudesse afetar o sistema como um todo, já que uma das características do DNS é ser redundante (tradução: ter os mesmos dados em todos os sistemas). Ou seja, uma “remoção” tem que ser feita em todos os root servers. Com o controle saindo das mãos dos EUA, isso com certeza seria muito difícil.
O outro problema é o ICANN, Internet Corporation for Assigned Names and Numbers (Corporação para a distribuição de nomes e números de Internet), uma organização norte-americana que controla o fornecimento dos domínios nacionais já citados e dos números de IP.
Os Estados Unidos não abrem mão de deterem o controle dessa organização, alegando “questões de segurança”, mesmo com a sugestão de passar esse controle para uma organização pan-nacional, como o ITU (International Telecommunication UnionUnião Internacional de Telecomunicações), órgão ligado à ONU que já trata da questão de telecomunicações, com padronizações em vários setores relacionados. Porém, o principal medo dos outros países é que os americanos comecem a usar seu poder no ICANN para atuarem como Grande Irmão (referência a 1984 de George Orwell), o que, considerando-se a atual “Guerra contra o Terror” não seria de se estranhar.
Há um perigo de que uma decisão intransigente americana possa romper a estrutura da Internet como a conhecemos, isolando os EUA do mundo e vice-versa, com cada país criando variações da Internet individuais, talvez ligadas entre si, mas sem o alcance global da Internet como a conhecemos.
Outro problema envolvido na Governança Eletrônica está relacionado ao Multiculturalismo, ou à existência de conteúdo e funcionamento da Internet em idiomas diferentes do inglês ou com alfabetos não latinos (como o Hindi ou Gujarati do Indiano, o Cirílico do Russo e os caracteres japoneses e chineses). Há um crescente interesse pelo uso do sistema IDN – Internationalized Domain Names (Nomes de Domínio Internacionalizados), mas os americanos evitam falar do assunto, alegando que complicaria tecnologicamente o sistema DNS, além de tornar complexo o acesso para americanos. Porém, a alegação é recíproca por parte de países que usam idiomas com alfabetos não-latinos ou até mesmo com alfabetos com acentos, como o Brasil. É que deixar de fora seus alfabetos ou acentos locais fere o respeito à cultura de um povo. Além disso, o fato de o IDN utilizar sistemas técnicos já reconhecidos têm derrubado a barreira da complexidade. De fato, alguns países, como Grécia, Alemanha e Brasil, já adotam domínios IDN.

Liberdade de Expressão:

Outro problema sério a ser tratado no caso da Internet é a Liberdade de Expressão, onde muitas vezes os países acabam sendo pedra e vidraça.
Os Estados Unidos estranhamente não aceitam que o racismo ou a xenofobia (ódio a estrangeiros, relacionado ao nazismo) sejam incluídos como temas a serem deplorados no cyber-espaço, alegando para isso parte da Primeira Emenda de sua Constituição, que declara que o principal valor americano é a liberdade de expressão. Por isso não é tão estranho que sites norte americano sobre racismo e xenofobia sejam tão prósperos em “net-solo” americano.
Esse mesmo princípio que os faz extremamente tolerantes à difusão de idéias xenofóbicas e racistas em seu território é o que os faz ir contra o Grande Firewall da China (um filtro de conteúdo nacional que não permite que chineses acessem sites como o do New York Times ou sobre o Dalai Lama).
Mas se de um lado a China quer barrar certos tipos de conteúdo, do outro os EUA querem censurar o conteúdo pornográfico na Internet. Para isso estão dispostos a tudo, inclusive a impedir a criação de um novo domínio chamado “.xxx” (lembrando que XXX é uma notória convenção para indicar-se pornografia explícita, principalmnete em fitas de vídeo e DVDs) e a exigir que empresas “suspeitas” divulguem incondicionalmente informações sobre “conteúdos polêmicos”. Estranhamente, os EUA possuem muitas leis bizarras sobre a questão sexual, inclusive com estados que permitem a zoofilia (sexo com animais) e até mesmo a necrofilia (sexo com pessoas mortas).

Cyberjus (ou Leis para a Internet):

Na área de crimes digitais, o consenso existe quando se trata de crimes contra bancos, roubos em contas bancárias a partir do roubo de senhas e demais versões informáticas de crimes “do mundo físico”. Fora isso, tratar do Direito Informático ainda é um problema enorme, e pode ficar ainda maior. Principalmente se a WSIS for pressionada a aceitar leis rígidas como a DMCA (Digital Millenium Copyright ActLei de Copyright do Milênio Digital).
A DMCA é uma lei que impede a engenharia reversa (ou seja, a pesquisa do funcionamento e possíveis formas de contornar “travas de segurança” digitais), considerando-a crime de pirataria de dados. O maior problema desse caso é que a DMCA está sendo usada como uma forma de impedir a disseminação cultural e tecnológica. Os Estados Unidos, para variar, são os principais defensores da idéia de leis que lindem legalmente tecnologias de proteção, também chamadas de leis anti-contorno (anti-circunvention em inglês). Já países como o Brasil, China e Índia defendem modelos de copyright mais maleáveis, como aquelas baseadas em Creative Commons para uma maior difusão sócio-tecno-cultural.
Outros dois problemas sérios na Internet também fazem parte dessa discussão. São eles a questão da pirataria e do spam.
A pirataria é inegavelmente nociva, mas o maior problema da questão da pirataria não é o fato em si, mas o que está por trás dele, que é uma supressão velada da cultura de outros países, cuja cultura será substituída pela cultura americana. Esse fato já acontece, mas as empresas midiáticas e de software têm o desejo de conseguir mercados consumidores para seus produtos, não importa o que aconteça. Países de diversos tipos vêm defendendo um modelo que permita que supostos piratas (normalmente pessoas que baixam músicas de bandas pouco conhecidas, como os irlandeses do Ceolbeg ou os coreanos do Banya) possam pagar preços justos pela música, ao invés de serem obrigados a pagar US$ 20,00 em um CD do qual aproveitarão uma ou duas músicas. Claro que as empresas midiáticas são contra, uma vez que perderiam parte expressiva da renda.
Já em se tratando de mensagens de propaganda abusiva (os famosos spams), existem queixas americanas de que os países em desenvolvimento seriam o ponto de partida da maior parte deles. Por sua vez, a maior parte dos países defende que o spam é disparado por empresas norte-americanas que usam de adulteração dos emails para indicarem suas origens em endereços legítimos nas regiões em desenvolvimento.
A questão da invasão de sistemas, principalmente a do defacement (pichação, onde a página de um site é removida e é colocada outra, como em uma pichação de muros), também tem sua polêmica, principalmente sobre como deverão e quem deverá ser responsabilizado. Há uma tendência de que se responsabilize também o administrador de qualquer sistema que tenha sido usado para essa invasão.
Mas há casos em que esta decisão se torna deveras injusta, como ocorre com o tipo de ataque DDoS (Distributed Denail of ServiceNegação de Serviço Distribuída). O DDoS pode ser comparado a uma espécie de “trote coletivo” capaz de desativar um servidor de conteúdo da Internet, e pode se utilizar de (muitos) computadores inocentes. Se a responsabilização se extender aos donos desses computadores, afetará pessoas que nada têm a ver com o problema e que podem ter tido suas máquinas transformadas em zumbis (termo que quer dizer: transformar-se uma máquina comum em uma preparada para participar – sem conhecimento do seu dono – de um ataque de DDoS).

Inclusão Digital:

O tema Inclusão poderia ser o único tema de concórdia entre todos os países na WSIS, já que não existe país que não reconheça a importância da Inclusão Digital e da Internet, e não saiba que para uma evolução no 3° Milênio é necessário combater o Analfabetismo Funcional.
O ponto de discórdia resume-se a como ela deve ser feita.
Os países em desenvolvimentos, liderados por Brasil, China, África do Sul e Índia, sugeriram um modelo de Inclusão baseado na preferência pelo software livre, o que permitiria menores custos e um maior intercâmbio de tecnologia. Esse modelo também possui proponentes na Rússia, Alemanha, Polônia e outros países da União Européia.
Porém, os países desenvolvidos, liderados principalmente pelos Estados Unidos, sugerem um “modelo neutro”, sem preferências, o que em geral acaba abrindo espaço para o tradicional lobby do modelo proprietário de software, que termina sendo imposto por algumas empresas de software, principalmente pela Microsoft. Tais países também possuem interesse em manter o eterno atraso tecnológico dos países em desenvolvimentos.

Conclusão

Enfim, a WSIS teria tudo para ser um campo de decisões unânimes, se prevalecesse o bom-senso e houvesse real preocupação com os países ainda-não-desenvolvidos ou em desenvolvimento. Se houvesse uma real preocupação com uma globalização justa. Mas como não há, de que adianta serem razoáveis?
As ações, os grupos e suas motivações estão bem delineadas. O importante é que as motivações sejam compreendidas e debatidas, e que a sociedade não aceite nenhum tipo de indefinição que favoreça pequenos grupos de elite. É sempre bom notar que, por mais que os atuais donos da Internet entendam assim, a Internet não é um shopping center virtual. Ela é muito mais que isso, e foi fundada com outro objetivo, o objetivo que grupos como FSF, EFF, Creative Commons e outros defendem… A livre troca de conhecimento, para melhoria não apenas de um ou outro país, e sim da humanidade como um todo.
O que está em jogo para os donos do mundo não é a melhoria dos pequenos, mas a preparação de um mercado consumidor nesses países, e só. Teremos, nessa Cúpula, uma chance de mudar as coisas como são hoje, pelo menos no mundo da Informática. Torçamos por ela.
Referência

Powered by ScribeFire.

Por que não me surpreendo? Documentos produzidos no MS Office 2007 NÃO SÃO COMPATÍVEIS com DIS 25900 (OOXML)

Certas coisas, quando você lê, não te surpreende. Não interessa o que, mas certas coisas, ao lê, não te surpreende. No meu caso foi ler que, via Groklaw, que documentos MS Office 2007 não são compatíveis com o ISO 25900, também conhecido como OOXML.
Surpreendente? Calma que a coisa ainda vai fiar pior!!!

Bem, tudo começa quando Alex Brown, um dos pais dessa aberração chamada OOXML, decide fazer um teste após receber os schemas atualizados com as modificações sugeridas no BRM.

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

I was excited to receive from Murata Makoto a set of the RELAX NG schemas for the (post-BRM) revision of OOXML, and thought it would be interesting to validate some real-world content against them, to get a rough idea of how non-conformant the standardisation of 29500 had made MS Office 2007.

Not having Office 2007 installed at work (our clients aren’t using it – yet), the first problem is actually getting a reasonable sample for testing. Fortunately, the Ecma 376 specification itself is available for download from Ecma as a .docx file, and this hefty document is a reasonable basis for a smoke test …

Resumindo aqui, uma vez que a tradução seria longa e desenecessária: ele recebeu os novos schemas do OOXML atualizados para considerar as modificações do BRM e decidiu validar algum conteúdo “real” para ter uma idéia de o quão não-padronizado um arquivo .docx produzido pelo MS Office 2007 era. Como ele não tinha nenhum Office 2007 à mão, ele utilizou as próprias especificações do OOXML segundo a ECMA, que foram publicadas em… .docx.
Perceba a fina ironia: o que deveria confirmar o padrão acabou tornando-se um caso de uso negativo contra o mesmo. Acha engraçado? Eu não.

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

The main document (“document.xml”) content for Part 4 of Ecma 376 weighs in at approx. 60MB of XML. (…) So we have a document and a RELAX NG schema. All that’s necessary now it to use jing (or similar) and we can validate (…) The STRICT conformance model is quite a bit different from Ecma 376, essentially because most of that format’s most notorious features (non ISO dates, compatibility settings like autospacewotnot, VML, etc.) have been removed. Thus the expectation is that existing Office 2007 documents might be some distance away from being valid according to the strict schemas.

Sure enough, jing emitted 17MB (around 122,000) of invalidity messages when validating in this scenario. Most of them seem to involve unrecognised attributes or attribute values: I would expect a document which exercised a wider range of features to generate a more diverse set of error message.

Traduzindo

Os conteúdos do documento principal (“document.xml”) da Parte 4 do ECMA 376 [a primeira versão do OOXML] tinham algo em torno de 60 MB de XML (…) portanto tinhamos um documento e um schema em formato RELAX NG. Tudo o que precisávamos portanto era usar o jing [validador de documentos segundo schemas RELAX NG feito em Java] ou outros sistemas similares e poderíamos validar o documento (…) O modelo de conformitade STRICT é um tanto diferente do ECMA 376, essencialmente por causa de que os mais notórios recursos (como datas não-ISO, informações de compatibilidade como os do autospacewotnot, VML, etc.) forma removidos. Desse modo a expectativa era de que documentos Office 2007 deveriam estar longe de serem considerado válidos segundo schemas restritos.
Obviamente, o jing retornou algo em torno de 17MB (ou por volta de 122.000) de mensagens de erro enquanto validando o documento nesse cenário. A maior parte deles tem a ver com atributos ou valores de atributos não reconhecidos: imagino que um documento que utilize uma gama maior de recursos provoque uma gama maior de erros.
(Grifos meus)

Note que o próprio autor assume que (1) documentos do MS Office 2007 não estavam longe de serem considerados padrão e (2) que documentos que usassem mais recursos provavelmente gerariam mais mensagans de erro.
Agora, a pergunta é: se o formato foi padronizado, quanto tempo o usuário do Office 2007 deveria esperar para ter documentos DIS-25900 compliant, uma vez que o Office 2007 é a “implementação de referência” do OOXML? Como comparação, o OpenOffice.org é a “implementação de referência” do ODF, e levou apenas duas semanas para que o mesmo gerasse documentos ODF compliant.
No mesmo post, o autor mostra um outro schema, TRANSITIONAL, que é mais “liberal” que o STRICT. Mesmo assim, o documento gerou mensagens de erro relacionadas a uma tag específica. As concluões? O próprio autor coloca:

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

  • Word documents generated by today’s version of MS Office 2007 do not conform to ISO/IEC 29500
  • Making them conform to the STRICT schema is going to require some surgery to the (de)serialisation code of the application
  • Making them conform to the TRANSITIONAL will require less of the same sort of surgery (since they’re quite close to conformant as-is)

Traduzindo:

  • Documentos do Word gerados pela versão atual do MS Office 2007 não são compatíveis com o ISO/IEC 29500
  • Torná-los compatíveis com o schema STRICT demandaria alguma “cirurgia” nos códigos de (de)serialização de objetos na aplicação
  • Torná-los compatíveis com o schema TRANSITIONAL demandaria menos “cirurgia”, uma verz que ele está mais próximo da compatibilidade como-está;

Para resumir:

  1. Documentos do Word 2007 não são compatíveis com o OOXML;
  2. Torná-los compatíveis fielmente ao padrão OOXML (ISO 29500) demandaria grandes modificações no código do Office 2007;
  3. Torná-los compatíveis ao schema de transição demandaria poucas modificações, uma vez de que este schema está mais próximo do Office 2007;

Será que sou só eu que ainda acredito que isso não passou de um motivo para a MS arrumar um selinho de ISO para seus produtos e ainda assim manter seu lock-in nos documentos?
Além disso, será que a própria Microsoft não irá sabotar esse “padrão ISO” por si? O autor do post que estamos comentando é otimista (talvez de maneira quase Polianística):
Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

Given
Microsoft’s proven ability to tinker with the Office XML file format
between service packs, I am hoping that MS Office will shortly be
brought into line with the 29500 specification, and will stay that way.
Indeed, a strong motivation for approving 29500 as an ISO/IEC standard
was to discourage Microsoft from this kind of file format rug-pulling
stunt in future.

Ou seja

Dada à habilidade da Microsoft de melhorar o formato do Office XML por meio dos service packs, espero que logo o MS Office seja alinhado com as especificações 29500 e assim permaneça. De fato, um dos maiores motivadores para a aprovação do 29500 como um padrão ISO/IEC foi como uma forma de desencorajar a Microsoft quanto a essa atitude de discrepâncias em relação ao padrão no futuro.

Diferentemente do autor do post em questão, sou mais cético: o retrospecto histórico, inclusive durante o processo de padronização do OOXML, da MS joga contra ela. Porém, espero realmente que, caso a MS continue por essa vereda, que ela ao menos alinhe-se ao padrão que, por mais ruim que seja, ela ajudou a criar. Mas até lá, vou continuar atento, observando isso e evitando ao máximo o OOXML.

Office OpenXML (OOXML) e inapto pela ISO 29500