Televize 9, ctstream 3 (diskuse)

[pc2005]

Protože svět médií je v překotném vývoji, nové verze televize a ctstream jsou tu.

To mě rozesmálo, thx .

Ad NASA: Tak na ISS budou lítat přes Rusko to není problém. Spíš by mě zajímalo jak moc je ten stream opožděný oproti realtime. A pokud je to fakt realtime, tak zda jim někdo dává echo, že se někdo kouká. Protože co jsem vždycky začal sledovat, tak před kamerou něco dělali (třeba i 4 lidi) a pak se najednou začali vytrácet, až tam nikdo nebyl a kamera se přepla do stand-by . Jednou tuším i nějaká astronautka mávala směrem ke kameře.

[Atilius]

Může mi někdo prosím říct, co mám napsat do příkazového řádku, aby se to rozběhlo? Nějak se mi nedaří...:(

Díky.

[petr_p]

Kdybyste řekl, co přesně chcete a v čem se to chová jinak, než čekáte, tak by vám někdo mohl poradit.

[Atilius]

Právě, že se to nechová:) Chci tedy např pustit v mplayeru ct24. Co mám napsat?

[optim]

bash televize-9.txt ct4-h100

[petr_p]

Když si oba skripty uložíte někam do PATH pod názvy bez závěrečných pomlček a čísel a doinstalujete si chybějící perlové závislosti, tak by mělo fungovat televize ct24-h500.

[Petr Tomášek]

Tak je to nějaký rozbitý. Ještě kolem cca 19.45 to fungovalo. Viz:

$ ctstream-1 http://www.ceskatelevize.cz/ivysilani/zive/ct24/ 1000
Could not find iframe address in http://www.ceskatelevize.cz/ivysilani/zive/ct24/
$ ctstream-2 http://www.ceskatelevize.cz/ivysilani/zive/ct24/ 1000
Could not get SMIL playlist: 400 URL must be absolute
$ ctstream-3 http://www.ceskatelevize.cz/ivysilani/zive/ct24/ 1000
Could not get SMIL playlist: 400 URL must be absolute
$
$
$ ctstream-1 http://www.ct24.cz/vysilani/ 500
Could not get SMIL playlist: 400 URL must be absolute
$ ctstream-2 http://www.ct24.cz/vysilani/ 500
Could not get SMIL playlist: 400 URL must be absolute
$ ctstream-3 http://www.ct24.cz/vysilani/ 500
Could not get SMIL playlist: 400 URL must be absolute

[Petr Tomášek]

Tak už to jde, asi nějaký dočasný problém...

[petr_p]

Asi to zas předělávaj. Chyba „400 URL must be absolute“ je o tom, že neumí napsat CGI skript. Vrátí jim HTTP kód 200, ale v těle je „<errorSOAP>…“. Ale chvílemi to funguje. Asi záleží do jakého serveru se člověk zrovna trefí.

[petznaku]

"nepřiřetězuje" .. ha, nové slovo...

[xHire]

Ve skutečnosti se v určitých oblastech používá zcela běžně. Například v teorii (formálních) jazyků.

[Matěj Cepl]

Má někdo nějaké nápady jak stáhnout pořady z archivu iVysilani? Bývalo možné z webu vydolovat mms:// URL, ale teď jak jsou zcela flashovatí, tak už je to zjevně složitější. Na druhou stranu existuje aplikace pro iPhone/iPad, takže musí být nějaká metoda jak získat neFlashové URL.

[Jendа]

Zkus tohle.

[petr_p]

Pokud myslíš stejný archiv jako já (Pořady A–Z, vybrat pořad, Videoarchiv, vybrat datum vysílání), tak ctstream na to funguje.

[Matěj Cepl]

bradford:~ $ rtmpdump -o komensky.dump $(ctstream -d http://www.ceskatelevize.cz/ivysilani/10177109865-dejiny-udatneho-ceskeho-naroda/208552116230065-jan-amos-komensky/ 2000|head -n 1)
RTMPDump v2.3
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
Connecting ...
INFO: Connected...
Starting download at: 0.000 kB
INFO: Metadata:
INFO: trackinfo:
INFO:   timescale             25.00
INFO:   length                274.00
INFO:   language              eng
INFO: sampledescription:
INFO:   sampletype            avc1
INFO:   timescale             44100.00
INFO:   length                482304.00
INFO:   language              eng
INFO: sampledescription:
INFO:   sampletype            mp4a
INFO:   audiochannels         2.00
INFO:   audiosamplerate       44100.00
INFO:   videoframerate        25.00
INFO:   aacaot                2.00
INFO:   avclevel              31.00
INFO:   avcprofile            66.00
INFO:   audiocodecid          mp4a
INFO:   videocodecid          avc1
INFO:   width                 1024.00
INFO:   height                576.00
INFO:   frameWidth            1024.00
INFO:   frameHeight           576.00
INFO:   displayWidth          1024.00
INFO:   displayHeight         576.00
INFO:   moovposition          1905667.00
INFO:   duration              10.96
1874.854 kB / 10.92 sec (99.6%)
Download may be incomplete (downloaded about 99.60%), try resuming
bradford:~ $ mplayer komensky.dump 
MPlayer SVN-r33251-4.6.0 (C) 2000-2011 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing komensky.dump.
libavformat file format detected.


MPlayer interrupted by signal 11 in module: demux_open
- MPlayer crashed by bad usage of CPU/FPU/RAM.
  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.
bradford:~ $ 

[petr_p]

Takže ctstream funguje. Co nefunguje, je tvůj MPlayer:

$ md5sum -b komensky.dump 
f36dd337156aee0d563a53d5513bd2cd *komensky.dump

$ rpm -q mplayer
mplayer-1.0-0.119.20100703svn.fc14.x86_64

$ mplayer komensky.dump 
MPlayer SVN-r31628-4.4.4 (C) 2000-2010 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing komensky.dump.
libavformat file format detected.
[flv @ 0x356f8c0] Estimating duration from bitrate, this may be inaccurate
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0
VIDEO:  [H264]  1024x576  0bpp  25.000 fps    0.0 kbps ( 0.0 kbyte/s)
Clip info:
 audiochannels: 2
 audiosamplerate: 44100
 videoframerate: 25
 aacaot: 2
 avclevel: 31
 avcprofile: 66
 audiocodecid: mp4a
 videocodecid: avc1
 width: 1024
 height: 576
 frameWidth: 1024
 frameHeight: 576
 displayWidth: 1024
 displayHeight: 576
 moovposition: 1905667
 duration: 11
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Trying to force audio codec driver family -dmo...
Trying to force audio codec driver family ...
Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
FAAD: compressed input bitrate missing, assuming 128kbit/s!
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1024x576 => 1024x576 Planar YV12 
A:   0.6 V:   0.6 A-V:  0.006 ct:  0.018   0/  0 10%  3%  1.4% 0 0              
Exiting... (Quit)

(Místo head bych doporučil tail, tedy pokud se nezajímáš o reklamu).

[Matěj Cepl]

No, není to tak jednoduché.

totem "$(ctstream http://www.ceskatelevize.cz/ivysilani/10177109865-dejiny-udatneho-ceskeho-naroda/208552116230065-jan-amos-komensky/ 2000|tail -n 1)"

funguje, ale totem ten dump (aa69bdb77a6f11747fbfd71082706454) z rtmpdumpu nezpracuje, zhroutí se po několika sekundách (když se JAK hlava objeví na obrazovce).

[petr_p]

Co se týče stahovaného binárního proudu, tak zatímco krátká reklama se opakovaně stáhne v pořádku (identické kopie), tak stahování následujícího dlouhého videa se často restartartuje a rtmpdump bohužel do výstupu zopakuje i znovu staženou část. MPlayer/ffplay se v takovém případě řídí metadaty, takže pokračuje v přehrávání vloženého opakování a časomíra se „vrátí“ na patřičné místo, protože číslo snímku je uloženo v proudu. Zajímavé že restart se objevuje pravidelně kolem 39. sekundy, ale stažené soubory jsou pokaždé jiné. Zkoušel jsem poslení verzi rtmpdumpu ze SVN a ta tím také trpí.

Otázka je, jestli se tomu lze vůbec systematicky bránit, když rtmpdump nejprve vypíše potenciálně poškozená data, pak se rozhodne pro restart (nebo ty restarty vyvolává server?) a co pak se správnými daty? Kdyby librtmp měla přístup do do bufferu aplikace (nikoliv jako roura do aplikace), tak by se dala opakovaná data zapsat na správnou pozici (jak je běžné u RTP proudů).

Nebo to prostě je nějaká nepodporovaná funkce serveru, kterou si librtmp neumí vyložit, nebo je ten restart schválně, protože Adobe Flash Player by se třeba rozsynchronizoval. Co já vím.

Nicméně když proud přehrávám přímo mplayerem (nikoliv stažený soubor), tak se žádné restarty neprojevují. Zrovna tak když ho mplayerem uložím přes -dumpstream, tak opakovaně získávám shodné nepoškozené soubory o délce 46639625 B a MD5 součtu 43608d9d32f80420e29b83e8e1b9782b. Zrovna tak když rtmpdumpu přidám parametr --live, který zakazuje posun v proudu (pak opakované části vypustí z výstupu).

[petr_p]

ffmpeg, mencoder, mplayer and vlc fail to handle FLV files in F15