Hello!
I'm not living in an area where Digita transmits this channel via dvb-t, so I was wondering if there are other .fi users who could record/dump some minutes of this channel and upload it somewhere so we others could check the quality etc :)
http://www.digita.fi/digita_dokumentti.asp?path=1840;3793;1973;9850;10653
-- Pasi
Pasi Kärkkäinen wrote:
Unfortunately I don't have Elisa/Saunalahti ADSL.. :(
In DVB-S2 19.2E FTA channel Anixe HD there seems to be some olympics going on.
ANIXE HD;BetaDigital:11915:hC910M2O0S1:S19.2E:27500:1535:1539=deu:0:0:132:0:0:0
So, if someone is able to record/dump that stream, please do so :)
I just recorded some horse riding to try with various xine lib versions. Send me pm if you'd like to get a clip.
My first try on Ubuntu 8.04 produced
"[h264 @ 0x7faf7a9c7330]PAFF interlacing is not implemented gxine has suffered a fatal internal error."
Xine-lib 1.2 from mercurial decodes it now but the playback is very jerky on Intel E8200 CPU. The result is not much better than on my other old AMD Sempron 3100+ based HTPC.
BR, Seppo
On Tue, Aug 12, 2008 at 12:11:07AM +0300, Seppo Ingalsuo wrote:
Too bad I don't have satellite dish atm either..
Maybe try with recent mplayer (from svn).. and give it "-demuxer lavf -lavdopts fast:threads=2 -no-correct-pts" or something similar.. you can also try with threads=4 etc..
-- Pasi
Pasi Kärkkäinen wrote:
"mplayer -demuxer lavf -lavdopts fast:threads=4 -nocorrect-pts ..." gives steady but slow motion (roughly 50% speed) video. It is weird that the load on CPU1 and CPU2 is less than 40% during playback according to gnome system monitor. Somehow mplayer is not able to max both CPUs close to 100%.
With mplayer I noticed that the video is 1080i -- it is silly to broadcast interlaced crap. That probably explains why vdr xinelibout choked due to greedy de-interlacer that is pretty power consuming for 1080i. Other channels such as Arte HD (arte HD;ZDFvision:11362:hC23M5O0S1:S19.2E:22000:6210:6221=deu,6222=fra:6230:0:11120:1:1011:0) work OK.
BR, Seppo
On Tue, Aug 12, 2008 at 03:07:57PM +0300, Seppo Ingalsuo wrote:
Actually interlaced video kinda makes sense for sports and other live video.. you get 50 fields per second, so the movement is smooth..
If you look at interlaced video on a progressive display, then you need to do pretty heavy deinterlacing, preferrably using "full motion" methods to get 50 or 100 fps output.. takes a lot of CPU. Check http://www.100fps.com
Where did you get that stream from btw?
Digita is broadcasting this channel as 720p in DVB-T.. dunno if it's 25 fps or 50 fps.. Hopefully not 25 fps..
In what format is that Arte HD?
-- Pasi
Pasi Kärkkäinen wrote:
Actually interlaced video kinda makes sense for sports and other live video.. you get 50 fields per second, so the movement is smooth..
720p50 or even 720p60 would give superior motion with in practise better vertical resolution than 1080i. It would better to let the video encoder lose data in a controlled way than rudely alternating between two 540 line fields with interlaced video. Also now when carbon footprint matters it's insane to double every set top box / HDTV power consumption at recipient side for doing magical motion vectors based tricks in trying to restore the 1080 line image.
Recorded from Anixe HD yesterday.
At the moment
VIDEO: [H264] 1280x720 0bpp 50.000 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
But that was an old B/W film so not real HD content.
BR, Seppo
On Tue, Aug 12, 2008 at 04:18:15PM +0300, Seppo Ingalsuo wrote:
Yep, 720p50 or 720p60 is nice.
25 or 30 fps is not enough.. that's why they do 1080i50 instead of 1080p25.
1080p50 would be excellent though :) Takes a lot of bandwidth also.. I guess too much.
I just checked a sample of DVB-T YLE HD and it seems to be:
VIDEO: [H264] 1280x720 0bpp 50.000 fps 0.0 kbps ( 0.0 kbyte/s) Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
AUDIO: 48000 Hz, 2 ch, s16le, 320.0 kbit/20.83% (ratio: 40000->192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
So yeah, 720p50 is nice :)
-- Pasi
On Tue, Aug 12, 2008 at 03:59:19PM +0300, Lauri Tischler wrote:
A friend of mine was able to view DVB-T YLE HD on dual-core Intel core2 3 GHz CPU.. I think it didn't work very well on 2,66 GHz dual-core one.
Notice that there was been some optimizations and fixes lately to mplayer/ffmpeg/libavcodec so you should be running latest SVN version..
Or then you could try with CoreAVC H.264 codec..
-- Pasi
Lauri Tischler wrote:
Hi. What card are you using to get DVB-S2 ?
Technotrend S2-3200.
CPU power ? Dual-core ? GHz ?
Intel E8200 is a low power dual core 2.66GHz chip. On arte HD (720p50) the load for vdr-sxfe (vdr server on other PC) is about 50%.
Quad core could be good for 1080i stuff based on my 1st experiences ... My dual core handles 1080p24 trailers but I suppose not the better 1080p formats (and the 1080i case without going for low end deinterlacer such as bob).
BR, Seppo
When I started to convert my vdr recordings to h264 using ffmpeg -vcodec libx264. I saw that running it without -threads or with -threads set to 2, it used the same cpu usage. When I changed it to -threads 3 I started to see more than 100% usage. Perhaps decoding should also use -threads 3 to see it run on more than one cpu ? Perhaps you can modify the ffmpeg profiles?
This was on a Core 2 Duo 1.8GHz. Hope this helps somebody.
On 8/12/08, Seppo Ingalsuo seppo.ingalsuo@iki.fi wrote:
On Tue, Aug 12, 2008 at 03:07:57PM +0300, Seppo Ingalsuo wrote:
Just tried a sample of DVB-T YLE HD (720p50) on my computer..
It seems mplayer is not able to use multiple threads, at least on my system.. I just see a single process/thread taking all of the CPU.
I guess there's still something to fix for a proper multithreading for h.264 decoding in mplayer/ffmpeg/libavcodec..
I used:
mplayer -demuxer lavf -lavdopts fast:threads=4
-- Pasi
-
Antti Hartikainen -
JJussi -
Lauri Tischler -
Pasi Kärkkäinen -
Rolf Ahrenberg -
Seppo Ingalsuo -
Theunis Potgieter