É possível , mas provavelmente não é desejável. O cliente VLC (janela) será mostrado na tela que você quiser, mas estará reproduzindo o vídeo descompactado , que terá que ser enviado como pedidos X em rede. Mesmo sem quaisquer despesas gerais, o envio de 720 × 540 a 24 bpp e 30 fps necessitará de cerca de 279 Mbps (720px × 540px × 3 bytes / pixel × 30 fps × 8 bits por byte).
Quadros Ethernet, pacotes TCP / IP e o próprio protocolo X irão inchar ainda mais isso.
O que é ainda mais contra-intuitivo é que, uma vez que você está exibindo dados RGB pós-processados, quanto maior a janela, mais largura de banda será necessária. (leve isso com uma pitada de sal, o escalonamento real pode acontecer no lado do display - nesse caso, reduzindo o tamanho da janela não terá nenhum efeito no desempenho)
Quando o VLC (ou qualquer outro cliente X) está sendo exibido em um display em localhost , uma grande família de grandes otimizações é acionada, o que lhe dá a capacidade de resposta que você espera.
Você pode tentar isso sozinho se quiser (é bem interessante vê-lo em ação):
ssh -Yf user@hostname vlc some-file.avi
O VLC inicia, MAS: o áudio é reproduzido no host do cliente X ( hostname acima), não o host do servidor X e o vídeo é atualizado em uma fração do fps esperado. Alguns segundos no fluxo, e o vídeo e o áudio estão irremediavelmente dessincronizados. A maioria dos fluxos padrão é unwatchable. Nem pense em fluxos HD A / V.
A configuração padrão do servidor de mídia fornece o fluxo compactado do servidor para o cliente usando alguma forma de protocolo de acesso a arquivos de rede (por exemplo, NFS, CIFS) e permite que o cliente de vídeo faça a descompactação e reprodução.