Hi! I have vdr-1.7.0 installed and when I tune to that "Nelonen HD" channel, I get very disordered picture and sound. And lot's of errors. Have anybody here at HTV are managed to get that h264 channel working, if yes, how? (What I'm missing)
Full logfile can be found http://jjussi.pp.fi/logs/h264.log
JJussi wrote:
Hi! I have vdr-1.7.0 installed and when I tune to that "Nelonen HD" channel, I get very disordered picture and sound. And lot's of errors. Have anybody here at HTV are managed to get that h264 channel working, if yes, how? (What I'm missing)
Full logfile can be found http://jjussi.pp.fi/logs/h264.log
[h264 @ 0xb791d708]PAFF interlacing is not implemented
This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF.
Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year.
On Sunday, 29. Juneta 2008 03:34:57 Anssi Hannula wrote:
[h264 @ 0xb791d708]PAFF interlacing is not implemented
This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF.
Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year.
But as you can see from xine-lib compile log, --with-external-ffmpeg is "on".. ffmpeg version is 0.4.9_p20070616-r2 as compile log states.
http://jjussi.pp.fi/logs/xine-lib_compile.log http://jjussi.pp.fi/logs/h264_29.6.08.log http://jjussi.pp.fi/logs/ffmpeg_compile.log http://jjussi.pp.fi/logs/vdr-xineliboutput_compile.log
Hopefully these log files can "give more light" to this problem..
BTW, when I change channel from some other channel to that "Nelonen HD" my vdr-sxfe crashes with "Memory overflow" error message.
Hi,
On Sun, Jun 29, 2008 at 12:23:37PM +0300, JJussi wrote:
On Sunday, 29. Juneta 2008 03:34:57 Anssi Hannula wrote:
[h264 @ 0xb791d708]PAFF interlacing is not implemented
IF i remember right, there were commit for replacing that "PAFF + spatial direct ... not supported" with this "PAFF + Interlaced ... not supported". In either case, it's encoded with something ffmpeg can't handle just now. The mentioned channel is just fine with reelbox-plugin and Extension HD. Same restrictions applies for same operator (Finland HTV) for channels like Eurosport HD, Silver HD. Canal Film+ HD and Voom should work quite ok and Discovery HD is still mpeg2 and therefor work.
JJussi wrote:
On Sunday, 29. Juneta 2008 03:34:57 Anssi Hannula wrote:
[h264 @ 0xb791d708]PAFF interlacing is not implemented
This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF.
Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year.
But as you can see from xine-lib compile log, --with-external-ffmpeg is "on".. ffmpeg version is 0.4.9_p20070616-r2 as compile log states.
Too old ffmpeg snapshot, then. If the problem is just PAFF, then a newer snapshot will fix it.
However, PAFF + spatial direct mode is not supported by current ffmpeg. If that is the case, the error message will change to "PAFF + spatial direct mode is not implemented".
I'm not on Welho so I don't know whether Nelonen HD uses that mode.
On Sun, Jun 29, 2008 at 08:02:05PM +0300, Anssi Hannula wrote:
JJussi wrote:
On Sunday, 29. Juneta 2008 03:34:57 Anssi Hannula wrote:
[h264 @ 0xb791d708]PAFF interlacing is not implemented
This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF.
Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year.
But as you can see from xine-lib compile log, --with-external-ffmpeg is "on".. ffmpeg version is 0.4.9_p20070616-r2 as compile log states.
Too old ffmpeg snapshot, then. If the problem is just PAFF, then a newer snapshot will fix it.
However, PAFF + spatial direct mode is not supported by current ffmpeg. If that is the case, the error message will change to "PAFF + spatial direct mode is not implemented".
When I try to play streams with mplayer (debian-multimedia, 1:1.0.rc2svn20080531-0.1) it says: [h264 @ 0x87a30d0]PAFF + spatial direct mode is not implemented% 85 0 0%
I'm not on Welho so I don't know whether Nelonen HD uses that mode.
FWIW, I put a few seconds long test clip of that channel to http://kelvin.aketzu.net/~akolehma/nelonen-hd.ts
Recoded using vdr-streamdev and wget http://vdr:3000/TS/12
Anssi Kolehmainen wrote:
On Sun, Jun 29, 2008 at 08:02:05PM +0300, Anssi Hannula wrote:
JJussi wrote:
On Sunday, 29. Juneta 2008 03:34:57 Anssi Hannula wrote:
[h264 @ 0xb791d708]PAFF interlacing is not implemented
This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF.
Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year.
But as you can see from xine-lib compile log, --with-external-ffmpeg is "on".. ffmpeg version is 0.4.9_p20070616-r2 as compile log states.
Too old ffmpeg snapshot, then. If the problem is just PAFF, then a newer snapshot will fix it.
However, PAFF + spatial direct mode is not supported by current ffmpeg. If that is the case, the error message will change to "PAFF + spatial direct mode is not implemented".
When I try to play streams with mplayer (debian-multimedia, 1:1.0.rc2svn20080531-0.1) it says: [h264 @ 0x87a30d0]PAFF + spatial direct mode is not implemented% 85 0 0%
I'm not on Welho so I don't know whether Nelonen HD uses that mode.
FWIW, I put a few seconds long test clip of that channel to http://kelvin.aketzu.net/~akolehma/nelonen-hd.ts
Hmm, I indeed get the same message with current ffmpeg SVN (using ffplay). However, the picture is decoded fine (!).
Recoded using vdr-streamdev and wget http://vdr:3000/TS/12
On Monday, 30. Juneta 2008 08:20:20 Anssi Hannula wrote:
Hmm, I indeed get the same message with current ffmpeg SVN (using ffplay). However, the picture is decoded fine (!).
I changed my ffmpeg to version 0.4.9_p20080326 and now it don't crash anymore and I can see few seconds quite good (but little bit jumppy) picture..
Jul 1 07:46:35 htpc vdr: [6169] switching to channel 10 Jul 1 07:46:35 htpc vdr: [6482] transfer thread ended (pid=6169, tid=6482) Jul 1 07:46:35 htpc vdr: [6169] buffer stats: 156604 (7%) used Jul 1 07:46:35 htpc vdr: [6169] buffer stats: 0 (0%) used Jul 1 07:46:35 htpc vdr: [6486] transfer thread started (pid=6169, tid=6486) Jul 1 07:46:35 htpc vdr: [6487] receiver on device 2 thread started (pid=6169, tid=6487) Jul 1 07:46:35 htpc vdr: [6489] TS buffer on device 2 thread started (pid=6169, tid=6489) Jul 1 07:46:35 htpc vdr: [6485] TS buffer on device 1 thread ended (pid=6169, tid=6485) Jul 1 07:46:35 htpc vdr: [6483] buffer stats: 114868 (5%) used Jul 1 07:46:35 htpc vdr: [6483] receiver on device 1 thread ended (pid=6169, tid=6483) Jul 1 07:46:35 htpc vdr: [6486] cVideoRepacker: operating in H.264 mode Jul 1 07:46:35 htpc vdr: [6486] [xine..put] cXinelibDevice::PlayVideo: Detected H.264 video Jul 1 07:46:36 htpc vdr: [6486] [xine..put] H.264: Found NAL SPS at offset 6/2029 Jul 1 07:46:36 htpc vdr: [6486] [xine..put] H.264 SPS: profile_idc 77 Jul 1 07:46:36 htpc vdr: [6486] [xine..put] H.264 SPS: pic_width: 120 mbs Jul 1 07:46:36 htpc vdr: [6486] [xine..put] H.264 SPS: pic_height: 34 mbs Jul 1 07:46:36 htpc vdr: [6486] [xine..put] H.264 SPS: frame only flag: 0 Jul 1 07:46:36 htpc vdr: [6486] [xine..put] H.264 SPS: cropping 0 0 0 2 Jul 1 07:46:36 htpc vdr: [6486] [xine..put] H.264 SPS: -> video size 1920x1080 Jul 1 07:46:36 htpc vdr: [6486] [xine..put] Detected video size 1920x1080 Jul 1 07:46:36 htpc vdr: [6169] [xine..put] OSD bandwidth: 279696 bytes/s (2185 kbit/s) Jul 1 07:46:37 htpc vdr: [6169] [xine..put] OSD bandwidth: 274988 bytes/s (2148 kbit/s) Jul 1 07:46:38 htpc vdr: [6169] [xine..put] OSD bandwidth: 265972 bytes/s (2077 kbit/s) Jul 1 07:46:39 htpc vdr: [6169] [xine..put] OSD bandwidth: 261464 bytes/s (2042 kbit/s) Jul 1 07:46:40 htpc vdr: [6169] [xine..put] OSD bandwidth: 220892 bytes/s (1725 kbit/s) Jul 1 07:46:41 htpc vdr: [6169] [xine..put] OSD bandwidth: 265972 bytes/s (2077 kbit/s) Jul 1 07:46:42 htpc vdr: [6169] [xine..put] OSD bandwidth: 279496 bytes/s (2183 kbit/s)
After that picture moves to "colorfully boxes" and I start get " Jul 1 07:46:59 htpc vdr: [6486] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE)" messages in the log. CPU don't show any extra load. So, how I can (in gentoo system) "tune" that buffer bigger?
yes, it's better to use svn ffmpeg version, but anyway
from this commit http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/h264.c?r1=13538&r2=13542 we can see that in ffmpeg "PAFF + spatial direct mode is not implemented" currently
concerning of
[9784] [input_vdr] H.264: -> pts 8176924854 <- 0 (DTS 8176921254) [9784] [input_vdr] H.264: -> pts 8176937454 <- 0 (DTS 8176923054) [9784] [input_vdr] H.264: -> pts 8176935654 <- 0 [9784] [input_vdr] H.264: -> pts 8176944654 <- 0 (DTS 8176941054) [9784] [input_vdr] H.264: -> pts 8176946454 <- 0 (DTS 8176942854) [9784] [input_vdr] H.264: -> pts 8176955454 <- 0 (DTS 8176951854) [9784] [input_vdr] H.264: -> pts 8176957254 <- 0 (DTS 8176953654)
I don't know what's
concerning of
video_out: throwing away image with pts 1143799 because it's too old (diff : 1019097). video_out: throwing away image with pts 1158199 because it's too old (diff : 1027966). video_out: throwing away image with pts 1168999 because it's too old (diff : 1035015). video_out: throwing away image with pts 1172599 because it's too old (diff : 1049212). video_out: throwing away image with pts 1186999 because it's too old (diff : 1053726).
be sure that your CPU is fast enough
JJussi wrote:
Hi! I have vdr-1.7.0 installed and when I tune to that "Nelonen HD" channel, I get very disordered picture and sound. And lot's of errors. Have anybody here at HTV are managed to get that h264 channel working, if yes, how? (What I'm missing)
Full logfile can be found http://jjussi.pp.fi/logs/h264.log
[h264 @ 0xb791d708]PAFF interlacing is not implemented
This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF.
Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year.
On Sunday, 29. Juneta 2008 16:35:04 Goga777 wrote:
yes, it's better to use svn ffmpeg version, but anyway
from this commit http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/h264.c?r1=13538&r2=13542 we can see that in ffmpeg "PAFF + spatial direct mode is not implemented" currently
But hopefully in near (?) future it is?!?
[9784] [input_vdr] H.264: -> pts 8176924854 <- 0 (DTS 8176921254) [9784] [input_vdr] H.264: -> pts 8176937454 <- 0 (DTS 8176923054) [9784] [input_vdr] H.264: -> pts 8176935654 <- 0 [9784] [input_vdr] H.264: -> pts 8176944654 <- 0 (DTS 8176941054) [9784] [input_vdr] H.264: -> pts 8176946454 <- 0 (DTS 8176942854) [9784] [input_vdr] H.264: -> pts 8176955454 <- 0 (DTS 8176951854) [9784] [input_vdr] H.264: -> pts 8176957254 <- 0 (DTS 8176953654)
I don't know what's
Neather I do.. ;-)
concerning of
video_out: throwing away image with pts 1143799 because it's too old (diff : 1019097). video_out: throwing away image with pts 1158199 because it's too old (diff : 1027966). video_out: throwing away image with pts 1168999 because it's too old (diff : 1035015). video_out: throwing away image with pts 1172599 because it's too old (diff : 1049212). video_out: throwing away image with pts 1186999 because it's too old (diff : 1053726).
be sure that your CPU is fast enough
Maybe 2x "Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz" is not enough.. I think that it happened because everything else (those problems PAFF and so) took so long time that it couldn't keep up the sync.
Lauri Tischler wrote:
Umm.. why does the log say 1596 MHz ?
http://en.wikipedia.org/wiki/EIST
Could be SpeedStep.
On Monday, 7. Julyta 2008 12:39:31 Lauri Tischler wrote:
JJussi wrote:
Maybe 2x "Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz" is not enough..
Umm.. why does the log say 1596 MHz ?
Because CPU speed is controlled with "ondemand" style. When there is no "need" for power, speed is lowered.. That point (at point where playback has not started yet) cpu power was not needed.
Maybe this gives some light to this matter, in way or other.. I tried to play recording from that channel, with xine.. With verbosity=3.
http://jjussi.pp.fi/logs/NelonenHD_playback.log
-
Anssi Hannula -
Anssi Kolehmainen -
Goga777 -
JJussi -
Lauri Tischler -
Pasi Pirhonen -
Pertti Kosunen