Delírios de um defunto: Blogspot como hospedagem gratuita e ilimitada de vídeos

Enquanto trabalhei no Meganim, meu foco sempre foi qualidade máxima possível. Armazenava no MEGA e em qualquer outro site o arquivo exatamente como era disponibilizado pela fansub.

Eventualmente todos que praticam isso irão se chocar com complexidade de armazenar arquivos tão pesados e, infelizmente, o total desprezo dos usuários que não dão tanta importância a esse tipo de prática.

Durante um bom tempo o drive não contava o uso do armazenamento para arquivos de vídeos enviados pelo Backup. Melhor ainda, quando o arquivo era enviado no formato MKV, ele não fazia reencode do vídeo, mantinha na qualidade original.

Usaram e abusaram deste recurso, enquanto isso o google precisava de diferenciais para o Pixel, e este foi uma delas. Backup ilimitado de vídeos agora só passava a funcionar no google Pixel.

Desde aquela época eu sabia que os vídeos enviados para o Blogspot não consumiam o armazenamento do Google. Se você procurar na internet, não vai ter nenhuma informação do google e, fora do google, dizeres de que vídeos do blogspot consomem os dados da conta google.

Isso é incorreto (hoje). Nada consta

Eis aqui um vídeo h264 com áudio aac, casa perfeito:

O tema para PC não está exibindo o player atualmente, apenas a versão mobile do site.

Mas aqui está um iframe para o vídeo, sem usar o objeto do player

O metodo que funciona atualmente mas que não garante funcionar no futuro é o seguinte:

Primeiro o blog precisa ter o feed habilitado, que é habilitado por padrão.

Depois precisamos obter a postagem em formato JSON, pois nele conterá o token do vídeo.

A url é essa:

https://www.blogger.com/feeds/BLOGID/posts/default/POSTID?alt=json

BLOGID e POSTID eu os tenho diretamente enquanto edito uma postagem, no meu caso a url final para este post fica:

https://www.blogger.com/feeds/4820739341202018909/posts/default/4879988590493974761?alt=json

No resultado eu tenho algo como:

https:\/\/www.blogger.com\/video.g?token=AD6v5dzikwfceAjllzF1C0fEv3K5-1A1JPpvCmZWju1un0kXNJvZKRP7_0WJy4z-gpTQ2ZhZMwihhZzoon8s2i1cEg

(~~duvido que este token seja permanente~~) este token é permanente

Nesta url tenho o player, no html eu tenho links diretos para os arquivos

É claro que, se você disponibilizar esta url ao público, em alguns segundos a URL vai ser derrubada, junto com o blog.

Sua opção é usar um proxy entre o arquivo e o usuário. Talvez ainda mais, tornar o blog privado.

Limitações.

A única limitação conhecida é o limite de 100MB por arquivo, mas tem limites não conhecidos, e os principais são os codecs de áudio e vídeo.

h264 e aac funcionam perfeitamente. Vou tentar:

h264 e opus:

h264 e vorbis:

Ambos funcionaram bem. Agora ao teste interessante, pois precisamos nos afastar do limite de 100MB:

hevc e aac:

av1 e aac:

Av1 funcionou bem, HEVC ficou travado indefinidamente em Processing, talvez falhou.

O vídeo em questão tem a resolução 1440x1080 e o player só gera resoluções até 720p. Vamos descobrir se é um problema do vídeo ou limite, testando com um vídeo 1920x1080 e 60fps, com h264:

Sim, o 1080p foi ignorado junto com os 60fps. Isso já era de se esperar, já que vimos que o youtube só trabalha com arquivo único até 720p, de lá em diante os arquivos são separados em chunks, também separados do áudio.

E agora descobrir se tem problema extrapolar o limite de 100MB pelo server side, afinal de contas, tudo é codado para h264. Então, irei codar um vídeo com svtav1 com o limite de 100MB e enviar, e verei se terei problemas:

Antes disto preciso confirmar se a altura 720p é suficiente para o encoder do google gerar o vídeo 720. Então eu faço scale=-1:720. Isso também se faz necessário porque tudo além de 720p será descartado, então é um peso descartável que nos apróxima do limite de 100MB sem necessidade.

Certo, funcionou perfeitamente, o player me deu 720p.

A proposito usei mpdecimate, qualquer coisa para tentar diminuir o trabalho do encoder do google ajuda a obter um arquivo com qualidade melhorzinha.

O arquivo final deu 96MB, svtav1 + vorbis:

Funcionou perfeitamente. O player está entregando um vídeo de 185MB.

Mais um teste (60 segundos de kodomo no jikan, 480p) para verificar se de fato gera o 480p, porque só vejo 360 e 720, nada mais.

Este vídeo gerou apenas 360.

Parece que foi removido definitivamente. No caso nem ao menos 144p.

O truque então é fazer upscale para 720p.

Finalmente, aqui está o iframe de todos os vídeos deste post:

Vídeo h264 com áudio AAC

Vídeo h264 com áudio AAC (alternativo)

Vídeo h264 com opus

Vídeo h264 com vorbis

Vídeo h264 1920x1080 60fps

Vídeo HEVC com aac

Vídeo AV1 com aac

Vídeo SVT-AV1 + vorbis (96MB)

Vídeo escalonado para 720p

Vídeo 480p (Kodomo no jikan)

Vídeo upscalado para 720p

Lutando contra o encoder do youtube

Primeiro devemos respeitar os limites "físicos" do arquivo, que é 720@30, tudo além disso será imprevisivelmente descartado.

Os primeiros 100MB do primeiro episodio de dance in the vampire bund, legendado pela infinite fansub, sem encode, apenas copiado

Como esperado, com pouca movimentação a diferença é humanamente nula.

O comando

ffmpeg -i [Infinite\ Fansub\ \&\ Nadja\ Applefield\ Fansub]\ Dance\ In\ The\ Vampire\ Bund\ -\ 01\ \(Blu-Ray\ -\ 1080px\).mkv -map 0:v:0 -map 0:a:0 -c:a libopus -b:a 32k -map _metadata -1 -c:v libsvtav1 -vf mpdecimate,scale=-1:720 -preset 2 -y -crf 40 -force_key_frames 'expr:gte(t,n_forced*60)' video.mp4

Nos dá este arquivo visivelmente inferior ao arquivo original, mas ainda superior ao que costumamos ver em sites de streaming como anintube. Os mesmos 02:18, porem em 8MB

ele:

Com o player nos entregando um arquivo de 23MB

Seria interessante também comparar estes dois arquivos

ffmpeg -i e.mp4 -i 1.mp4 -filter_complex "[0:v]fps=24000/1001,scale=1280:720[ref];[1:v]fps=24000/1001,scale=1280:720[test];[ref][test]psnr" -f null -

O resultado foi como esperado:

PSNR y:37.69

PSNR u:42.36

PSNR v:43.38

average:38.83

min:11.24

max:inf

Como é um anime parado, a diferença foi quase nula (contextualizando, acima de 40 é praticamente nenhuma diferença, acima de 30 imperceptível sem focar e abaixo disto começa a ficar visível)

Com o min 11 isso deixa óbvio que o problema são movimentações na cena. Deve então, antes de enviar, buscar filtros que tentem vetorizar a movimentação. Efeitos caros como fumaça é só fé.

Exemplo real

primeiros 60 segundos de Django de 1966, com muito filtro, com b:v limitado de modo que o audio e video (completo, uma hora meia) caibam em 99MB. Esses 60 segundos deram 1.1MB. Poderia reduzir pela metade a qualidade do audio que aumentaria notavelmente a qualidade do vídeo.

A parte que exibe "A film by" com a camera nos pés, deixa evidente a baixa qualidade, com os macroblocos expostos. Mas, isso está visível no arquivo original, não no arquivo do player. Então, reduzimos a qualidade de forma controlada e previsível, assim o player não reduz oque não deveria.

A proposito, o arquivo gerado pelo player foi de 10.3MB. Ele não conseguiu reduzir a qualidade além do que já estava e também gerou um arquivo 10 vezes maior.

Acabei descobrindo que, atualmente, o ffmpeg não suporta 2pass com svt.

Refiz o reencode usando o proprio svt, 2 pass, usei preset 0 e tirei 15kb do audio para o vídeo. O resultado foi bom mas, sem filtros, a qualidade gerada será desconhecidamente desgraçada pelo encoder do youtube:

Sim, mesmo sem filtros, a qualidade ficou visivelmente superior.

Então fica assim afirmado: SVT, 2 pass e preset 0 são, atualmente (enquanto não lançam nem suportam AV2) a melhor opção para upload no blogspot.

Note também que esse áudio de baxíssimo bitrate só deu certo (até certo ponto) por conta da idade do filme, que ele por si só já tem baixa qualidade.

Preset 0 com certeza é a melhor opção para um arquivo final bom, mas está muito custoso no tempo de encode, então vamos dar uma olhada nessa tabela aqui

É claro que o resultado nem sempre será o mesmo, mas sendo, preset 2 deve dá, humanamente, a mesma coisa que preset 0. (AInda assim, se tiver tempo, é bom dar prioridade a preset 0)

Obtendo o vídeo

Seja lá qual forma você usar para armazenar e obter os vídeos, todos eles serão propensos a falhar em um futuro desconhecido. Talvez o melhor seja usar todos os metodos possíveis como fallback?

Tokens para blogspot.com/video.g

Os tokens são permanentes e o vídeo não precisa estar no post para a url do token continuar viva, pelo menos depois que você obtem o token do post.

Deixar os vídeos no post?

Deixar os vídeos no post é algo inseguro, pois mesmo se o blog se tornar privado ele PODE ou não passar pelo copyright do google. Mas também dá mais segurança para caso no futuro quebre alguma coisa.

Obtendo diretamente do armazenamento

Essa é a parte interessante.

Em Settings -> Manage Blog -> Videos from your Blog somos levados para, atualmente, a url https://www.blogger.com/mediamanager/videos

No html desta página temos algo como

AF_initDataCallback({
    key: 'ds:3',
    hash: '2',
    data: [
      [
        ["824...", "166....webm", "i9.ytimg.com/...", null, 1756872789541],
        ["-460...", "175....webm", "i9.ytimg.com/...", null, 1756872767452],
        ["-108...", "175....webm", "i9.ytimg.com/...", null, 1756872778703],
      ], null, 1, 26
    ],
    sideChannel: {}
});

Aqui temos finalmente um ID real de cada vídeo enviado, bem como o nome original do arquivo, url da thumbnail, alguma outra coisa e quando foi enviado.

Este ID basicamente é a real localização do arquivo nos servidores do google, e com isso você está praticamente com o queijo na mão.

A faca seria o protocolo batchexecute do google.

Quando clicamos no download do arquivo, um post é feito para

https://www.blogger.com/mediamanager/_/BloggerMediaManagerUi/data/batchexecute?rpcids=tGSakb&source-path=%2Fmediamanager%2Fvideos%2Fuser&f.sid=-7965130047374227573&bl=boq_bloggeruiserver_20250901.04_p0&hl=en&soc-app=1&soc-platform=1&soc-device=1&_reqid=318262&rt=c

Com muita porcaria, inclusive e principalmente os cookies. No post tem:

[[["tGSakb","[\"-4603218945479374243\"]",null,"generic"]]]

Sendo -4603218945479374243 o ID do arquivo.

E finalmente a url nos retorna:

)
]
}'

1337
[
  [
    "wrb.fr",
    "tGSakb",
    [
      "-4603218945479374243",
      "https://rr1---sn-8p85uxjovavbp5cg-nn5e.googlevideo.com/videoplayback?..."
    ],
    null,
    null,
    null,
    "generic"
  ],
  [
    "di",
    60
  ],
  [
    "af.httprm",
    59,
    "-1131709396517021259",
    42
  ]
]

26
[
  [
    "e",
    4,
    null,
    null,
    1375
  ]
]

com a url para o vídeo. Sendo este, sem dúvidas, o metodo mais future proof, embora um pouco problemático por conta dos cookies.

Postar um comentário