Where can I download the H.264 patch from? I can't find it on Google. My card is only DVB-S, not DVB-S2; do I need the s2api patch as well?
to vdr-1.7.0, in attach file of this message : http://www.linuxtv.org/pipermail/vdr/2008-April/016513.html
jlacvdr
2008/11/21 Tony Houghton h@realh.co.uk:
Where can I download the H.264 patch from? I can't find it on Google. My card is only DVB-S, not DVB-S2; do I need the s2api patch as well?
-- TH * http://www.realh.co.uk
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Fri, 21 Nov 2008 11:49:23 +0100 jlacvdr jlacvdr@gmail.com wrote:
to vdr-1.7.0, in attach file of this message : http://www.linuxtv.org/pipermail/vdr/2008-April/016513.html
Is there a patch that will work with 1.6.0? It'll make things rather easier if I can just patch the debian packages instead of completely replacing them.
If I do have to use 1.7.x does this patch still work with 1.7.1 ie it's safe to ignore the failed hunk in transfer.c which has apparently changed radically?
On Mon, Nov 24, 2008 at 9:44 PM, Tony Houghton h@realh.co.uk wrote:
On Fri, 21 Nov 2008 11:49:23 +0100 jlacvdr jlacvdr@gmail.com wrote:
to vdr-1.7.0, in attach file of this message : http://www.linuxtv.org/pipermail/vdr/2008-April/016513.html
Is there a patch that will work with 1.6.0? It'll make things rather easier if I can just patch the debian packages instead of completely replacing them.
http://www.linuxtv.org/pipermail/vdr/2008-March/016227.html
-Petri
On Mon, 24 Nov 2008 22:25:00 +0200 "Petri Helin" phelin@googlemail.com wrote:
On Mon, Nov 24, 2008 at 9:44 PM, Tony Houghton h@realh.co.uk wrote:
Is there a patch that will work with 1.6.0? It'll make things rather easier if I can just patch the debian packages instead of completely replacing them.
Thanks; I used the second one (without s2api) and it applied cleanly to the debian 1.6.0 source.
I'm having trouble with playback though. I found "In The Night Garden" playing on BBC HD and tried testing with that. With vdr-sxfe the picture was mostly OK but very jerky while the sound was hopeless, mostly silence with a click or brief snatch of recognisable sound every few seconds. Then I made a recording and tried playing it in mplayer, but that couldn't make sense of the file at all, even with -demuxer lavf:
: ~ $ mplayer -demuxer lavf -identify '/home/tony/001.vdr' : MPlayer dev-SVN-r26940 : CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (Family: 6, Model: 15, Stepping: 2) : CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 : Compiled with runtime CPU detection. : Can't open joystick device /dev/input/js0: No such file or directory : Can't init input joystick : 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 /home/tony/001.vdr. : libavformat file format detected. : ID_VIDEO_ID=0 : [lavf] Video stream found, -vid 0 : ID_AUDIO_ID=1 : [lavf] Audio stream found, -aid 1 : VIDEO: [mpg2] 0x0 0bpp 90000.000 fps 0.0 kbps ( 0.0 kbyte/s) : ID_FILENAME=/home/tony/001.vdr : ID_DEMUXER=lavf : ID_VIDEO_FORMAT=mpg2 : ID_VIDEO_BITRATE=0 : ID_VIDEO_WIDTH=0 : ID_VIDEO_HEIGHT=0 : ID_VIDEO_FPS=90000.000 : ID_VIDEO_ASPECT=nan : ID_AUDIO_FORMAT=80 : ID_AUDIO_BITRATE=256000 : ID_AUDIO_RATE=0 : ID_AUDIO_NCH=2 : ID_LENGTH=249.63 : ID_SEEKABLE=1 : ========================================================================== : Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough : VDecoder init failed :( : Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family : Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2) : ========================================================================== : ID_VIDEO_CODEC=ffmpeg2 : ========================================================================== : Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 : : Too many video packets in the buffer: (1 in 497662055 bytes). : Maybe you are playing a non-interleaved stream/file or the codec failed? : For AVI files, try to force non-interleaved mode with the -ni option. : ADecoder init failed :( : ADecoder init failed :( : Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
etc etc
Gxine had more success with the recording, but was pretty much the same as vdr-sxfe. It identified the stream as 1440x1080 H.264 video and MPEG audio layer 2. With only one decoding thread enabled there are loads of error messages like this:
: [h264 @ 0x7f1d69f8f5a0]concealing 5040 DC, 5040 AC, 5040 MV errors
I guess that's a performance issue, because with multithreading enabled gxine used most of the CPU power available in both cores, but not all of it, and the above message appeared only once. Video playback was much smoother but the audio was still as described above.
MPlayer is Christian Marillat's debian package 1:1.0.rc2svn20080706-0.1. Do I need a newer version or a patch for VDR HD recordings? My xine packages are all the plain debian unstable ones. Does libxine or vdr's xineliboutput need a patch?
On Mon, Nov 24, 2008 at 9:44 PM, Tony Houghton h@realh.co.uk wrote:
Is there a patch that will work with 1.6.0? It'll make things rather easier if I can just patch the debian packages instead of completely replacing them.
Thanks; I used the second one (without s2api) and it applied cleanly to the debian 1.6.0 source.
I'm having trouble with playback though. I found "In The Night Garden" playing on BBC HD and tried testing with that. With vdr-sxfe the picture was mostly OK but very jerky while the sound was hopeless, mostly silence with a click or brief snatch of recognisable sound every few seconds. Then I made a recording and tried playing it in mplayer, but that couldn't make sense of the file at all, even with -demuxer lavf:
: ~ $ mplayer -demuxer lavf -identify '/home/tony/001.vdr' : MPlayer dev-SVN-r26940
please try to playback your sample with ffplay/ffmpeg from svn. If you will have the problem with playback could you download somewhere your sample with no more than 20 MB size
Goga
On Thu, 27 Nov 2008 19:00:58 +0300 Goga777 goga777@bk.ru wrote:
On Mon, Nov 24, 2008 at 9:44 PM, Tony Houghton h@realh.co.uk wrote:
I'm having trouble with playback though. I found "In The Night Garden" playing on BBC HD and tried testing with that. With vdr-sxfe the picture was mostly OK but very jerky while the sound was hopeless, mostly silence with a click or brief snatch of recognisable sound every few seconds. Then I made a recording and tried playing it in mplayer, but that couldn't make sense of the file at all, even with -demuxer lavf:
[Snip]
please try to playback your sample with ffplay/ffmpeg from svn. If you will have the problem with playback could you download somewhere your sample with no more than 20 MB size
With ffplay from svn there was no audio at all (I checked it did work with another file). I tried to report it on the ffmpeg bug tracker but I got an error message when I tried to submit the report. I've put the info as well as a 10MB sample of the stream in ftp://upload.mplayerhq.hu/MPlayer/incoming/realh/ so I hope one of the developers will find it.
I'm having trouble with playback though. I found "In The Night Garden" playing on BBC HD and tried testing with that. With vdr-sxfe the picture was mostly OK but very jerky while the sound was hopeless, mostly silence with a click or brief snatch of recognisable sound every few seconds.
Did you see my post recently about BBC HD not playing with the eHD card? I am seeing the same symptoms.
From what I can tell they have changed the way they broadcast the AC3
stream. I noticed they trialled it for a few days then went back to the original method. Unfortunately they now seem to be using it permanently which results in BBC HD being unwatchable whilst using AC3.
Tony, try go into the DVB menu and turn "Use Dolby Digital" to off. You will then be using the Mpeg Audio track which doesn't exhibit the same problems here, but I think it has audio description enabled which is quite irritating.
Sorry to double post, but as an update to this the Reel Multimedia guys have found that it appears that the AC3 track is currently being broadcast in a PES packet stream with an ID of 0xc0, which could be incorrect and AC3 should be broadcast with an id of 0xbd. Perhaps some other set top boxes ignore the id and process the stream based on content, but it causes severe problems with VDR, including stuttering picture and no audio.
Klaus, do you have any idea of what they have done and whether it can or should be fixed in VDR? The RMM guys believe the fix should occur in VDR and not the eHD driver, which sounds right if other users with xine/ffmpeg are also suffering.
On 28.11.2008 11:56, Morfsta wrote:
Sorry to double post, but as an update to this the Reel Multimedia guys have found that it appears that the AC3 track is currently being broadcast in a PES packet stream with an ID of 0xc0, which could be incorrect and AC3 should be broadcast with an id of 0xbd. Perhaps some other set top boxes ignore the id and process the stream based on content, but it causes severe problems with VDR, including stuttering picture and no audio.
Klaus, do you have any idea of what they have done and whether it can or should be fixed in VDR? The RMM guys believe the fix should occur in VDR and not the eHD driver, which sounds right if other users with xine/ffmpeg are also suffering.
I haven't followed this lately, but if the broadcast stream contains AC3 data in PES packets with ID 0xC0, then the problem needs to be fixed at the broadcaster - VDR merely follows the standard. Unless, of course, a bug in VDR can be pointed out...
Klaus
On Fri, Nov 28, 2008 at 11:02 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I haven't followed this lately, but if the broadcast stream contains AC3 data in PES packets with ID 0xC0, then the problem needs to be fixed at the broadcaster - VDR merely follows the standard. Unless, of course, a bug in VDR can be pointed out...
Hi Klaus,
Perhaps you are right, but the bizarre thing is that I don't see any evidence on the Internet of other set top boxes suffering from this problem. But 0xC0 is normally reserved for MPA audio right? Surely this would cause problems with other STBs? I also don't see users of other software (e.g. MythTV) having this problem, which seems a bit suspicious.
I have uploaded a VDR recording of BBC HD to megaupload if you (or anyone else) is interested in looking at it? Appreciate you might be busy with other things right now though. Otherwise, I had a look in device.c around
case 0xC0 ... 0xDF: // audio ...
case 0xBD: { // private stream 1 ... case 0x80: // AC3 & DTS
but if 0xC0 is being used for audio I can't understand how this can be adjusted to permit checking for the content of AC3 data too.
Thanks,
Morfsta
On 28.11.2008 12:21, Morfsta wrote:
On Fri, Nov 28, 2008 at 11:02 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I haven't followed this lately, but if the broadcast stream contains AC3 data in PES packets with ID 0xC0, then the problem needs to be fixed at the broadcaster - VDR merely follows the standard. Unless, of course, a bug in VDR can be pointed out...
Hi Klaus,
Perhaps you are right, but the bizarre thing is that I don't see any evidence on the Internet of other set top boxes suffering from this problem. But 0xC0 is normally reserved for MPA audio right? Surely this would cause problems with other STBs? I also don't see users of other software (e.g. MythTV) having this problem, which seems a bit suspicious.
I have uploaded a VDR recording of BBC HD to megaupload if you (or anyone else) is interested in looking at it? Appreciate you might be busy with other things right now though. Otherwise, I had a look in device.c around
case 0xC0 ... 0xDF: // audio ... case 0xBD: { // private stream 1 ... case 0x80: // AC3 & DTSbut if 0xC0 is being used for audio I can't understand how this can be adjusted to permit checking for the content of AC3 data too.
I haven't done anything in the direction of replaying HD content so far, and I won't get myself involved in replaying PES HD material. My guess would be that as soon as VDR is completely switched to TS recording, this problem should just go away, because VDR then no longer looks at these IDs at all.
Klaus
On Fri, 28 Nov 2008 12:34:07 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 28.11.2008 12:21, Morfsta wrote:
On Fri, Nov 28, 2008 at 11:02 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I haven't followed this lately, but if the broadcast stream contains AC3 data in PES packets with ID 0xC0, then the problem needs to be fixed at the broadcaster - VDR merely follows the standard. Unless, of course, a bug in VDR can be pointed out...
The trouble is the broadcasters won't care about "true" standards if they're doing something that works for them and STBs. I appreciate your view, but if VDR refuses to accommodate these deviations, the big beaureaucratic broadcasters won't care and it spoils VDR for the users.
Hi Klaus,
Perhaps you are right, but the bizarre thing is that I don't see any evidence on the Internet of other set top boxes suffering from this problem. But 0xC0 is normally reserved for MPA audio right? Surely this would cause problems with other STBs? I also don't see users of other software (e.g. MythTV) having this problem, which seems a bit suspicious.
I have uploaded a VDR recording of BBC HD to megaupload if you (or anyone else) is interested in looking at it? Appreciate you might be busy with other things right now though. Otherwise, I had a look in device.c around
case 0xC0 ... 0xDF: // audio ... case 0xBD: { // private stream 1 ... case 0x80: // AC3 & DTSbut if 0xC0 is being used for audio I can't understand how this can be adjusted to permit checking for the content of AC3 data too.
I really hope someone can work this out and devise a patch even if it never becomes official.
I haven't done anything in the direction of replaying HD content so far, and I won't get myself involved in replaying PES HD material. My guess would be that as soon as VDR is completely switched to TS recording, this problem should just go away, because VDR then no longer looks at these IDs at all.
Will that mean it won't be a problem for live playback with xineliboutput either?
On 30.11.2008 17:30, Tony Houghton wrote:
On Fri, 28 Nov 2008 12:34:07 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote: ...
I haven't done anything in the direction of replaying HD content so far, and I won't get myself involved in replaying PES HD material. My guess would be that as soon as VDR is completely switched to TS recording, this problem should just go away, because VDR then no longer looks at these IDs at all.
Will that mean it won't be a problem for live playback with xineliboutput either?
Live mode will also use TS, so it shouldn't be a problem there, either. At least from VDR's side. Any replay device will, at some point, have to assemble the PES packets from the TS, and then it's up to the device whether it can handle such non-standard stuff or not.
Klaus
On Sun, 30 Nov 2008 17:39:38 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 30.11.2008 17:30, Tony Houghton wrote:
On Fri, 28 Nov 2008 12:34:07 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote: ...
I haven't done anything in the direction of replaying HD content so far, and I won't get myself involved in replaying PES HD material. My guess would be that as soon as VDR is completely switched to TS recording, this problem should just go away, because VDR then no longer looks at these IDs at all.
Will that mean it won't be a problem for live playback with xineliboutput either?
Live mode will also use TS, so it shouldn't be a problem there, either. At least from VDR's side. Any replay device will, at some point, have to assemble the PES packets from the TS, and then it's up to the device whether it can handle such non-standard stuff or not.
So in any case I'll need the workaround in xine or one of its libraries such as ffmpeg, rather than in VDR? And there's not only xine but things like Project-X, mencoder or whatever I might use to convert and edit the recordings into a more manageable format.
On 30.11.2008 18:52, Tony Houghton wrote:
On Sun, 30 Nov 2008 17:39:38 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 30.11.2008 17:30, Tony Houghton wrote:
On Fri, 28 Nov 2008 12:34:07 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote: ...
I haven't done anything in the direction of replaying HD content so far, and I won't get myself involved in replaying PES HD material. My guess would be that as soon as VDR is completely switched to TS recording, this problem should just go away, because VDR then no longer looks at these IDs at all.
Will that mean it won't be a problem for live playback with xineliboutput either?
Live mode will also use TS, so it shouldn't be a problem there, either. At least from VDR's side. Any replay device will, at some point, have to assemble the PES packets from the TS, and then it's up to the device whether it can handle such non-standard stuff or not.
So in any case I'll need the workaround in xine or one of its libraries such as ffmpeg, rather than in VDR? And there's not only xine but things like Project-X, mencoder or whatever I might use to convert and edit the recordings into a more manageable format.
All I can say is that currently VDR does look at the IDs, and with TS recording it won't do so any more. So if the current problem is in VDR, it should just go away after the switch to TS recording.
Klaus
-
Goga777 -
jlacvdr -
Klaus Schmidinger -
Morfsta -
Petri Helin -
Tony Houghton