Re: [vdr] vdr 1.5.13 & dvb-s2 H.264 patch from Reinhard
Hello :-) The version for vdr-1.5.12 still apply and works :-) On Jan 16, 2008 7:57 AM, Igor <[EMAIL PROTECTED]> wrote: > Dear Reinhard > > are you planning to release the cumulate dvb-s2 h.264 patch for vdr 1.5.13 ? > > 10x very much for your contribution in hdtv-future for VDR project > > Igor > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- Grégoire FAVRE http://picasaweb.google.com/Gregoire.Favre http://gregoire.favre.googlepages.com/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.5.13 & dvb-s2 H.264 patch from Reinhard
Dear Reinhard are you planning to release the cumulate dvb-s2 h.264 patch for vdr 1.5.13 ? 10x very much for your contribution in hdtv-future for VDR project Igor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] H.264 VPID's
I guess that's caused by an offset defined in the patch: vdr-1.5.12-dvbs2-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff: #define VPID_OFFSET_BASE 1 I don't know what it does or is meant to do, but I also have wrong pids in my channels.conf Best regards, Christian ShorTie schrieb: > Been playing with this genpix, hd and xine. Pretty much got everything > running except for 1 thing seems to be hiding from me. > > For vdr to be able to tune to a hd channel I need to add 1 to the > vpid’s which I do in my nscan/convert/pad10 no biggie. > > The problem is that when I tune away from a hd channel vdr rights back > to the channels.conf with the normal vpid not the vpid+1 like I had. > > Thus I can’t tune back to that channel till i manually change the > channels.conf back again. > > > > I’m I missing a setting somewhere? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto
Reinhard Nissl wrote: > Hi, > > Morfsta schrieb: > >>> Please report the debug output here for further investigation. >> Attached are two files - tuning to the same DVB-T channel using either >> system and the Philips frontend... vdr-1.4.x shows the channel fine, >> 1.5.12 does not. >> >> Hope this helps and thanks again for your assistance. > > Hmm, the translation layer doesn't work correctly. It doesn't > translate new bandwidth value 1 to old bandwidth value 0, > although there exists code to do this translation, and it should > get called as the other translations happen correctly. > > As a result the old driver uses a bandwidth of 7 MHz instead of 8 > MHz. > > While copying the code here to ask for help in searching the bug, > it seems that I found the bug -- a missing break in the DVB-T > case ;-) > > Please try the attached patch. That indeed did fix. Have applied it to the tree. Thanks, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] H.264 VPID's
Hi,
ShorTie schrieb:
> Many thankz once again Reinhard Nissl, yes it keeps vdr from removing the 1,
> but it kills the video on h.264 channels .. :/~
I do not see, how this can happen due to the cheat.
> I get a picture but no motion and normally a green line across the tv.
>
> In looking thru messages I see see stuff like this
>
> ERROR: H264::cContext::ActivateSPS(): id out of range
> ERROR: H264::cContext::DefineSPS(): id out of range
> ERROR: H264::cBitReader::ReadBits(): bitbuffer overflow
> ERROR: H264::cContext::ActivateSPS(): requested SPS is undefined
> ERROR: H264::cContext::ActivatePPS(): requested PPS is undefined
> ERROR: H264::cBitReader::NextByte(): premature end of data
>
> ERROR: cAudGenerator::Generate(): dropping frame without slices
In case it didn't work (and does still not work) without the
cheat (i. e. you get the same errors), try increasing the
nalUnitDataBuffer a bit in h264parser.c:
> cParser::cParser(bool OmitPicTiming)
> : nalUnitDataBuffer(1000)
> {
> // the above buffer size of 1000 bytes wont hold a complete NAL unit but
> // should be sufficient for the relevant part used for parsing.
> omitPicTiming = OmitPicTiming; // only necessary to determine frames per
> second
> Reset();
> }
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + h264
Hi, Stefan Lucke schrieb: > The bad thing is, PSM info should be repeated more often, as the decoder > may reset itself due to bad reception (ahead of each video packet ??). > > Or is there a simpler way to recognize h264 (or other codecs) > as Klaus demands? In VDR context, you may want to use cRemux::IsFrameH264() on the first PES-Paket of a frame to detect H.264. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] H.264 VPID's
Many thankz once again Reinhard Nissl, yes it keeps vdr from removing the 1, but it kills the video on h.264 channels .. :/~ I get a picture but no motion and normally a green line across the tv. In looking thru messages I see see stuff like this ERROR: H264::cContext::ActivateSPS(): id out of range ERROR: H264::cContext::DefineSPS(): id out of range ERROR: H264::cBitReader::ReadBits(): bitbuffer overflow ERROR: H264::cContext::ActivateSPS(): requested SPS is undefined ERROR: H264::cContext::ActivatePPS(): requested PPS is undefined ERROR: H264::cBitReader::NextByte(): premature end of data ERROR: cAudGenerator::Generate(): dropping frame without slices Changing channels back to a sd 1 can be tricky but that could be cause it's trying to recover from a freakout, lol. ShorTie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reinhard Nissl Sent: Monday, January 14, 2008 2:09 PM To: VDR Mailing List Subject: Re: [vdr] H.264 VPID's Hi, ShorTie schrieb: > Been playing with this genpix, hd and xine. Pretty much got everything > running except for 1 thing seems to be hiding from me. > > For vdr to be able to tune to a hd channel I need to add 1 to the > vpid’s which I do in my nscan/convert/pad10 no biggie. > > The problem is that when I tune away from a hd channel vdr rights back > to the channels.conf with the normal vpid not the vpid+1 like I had. > > Thus I can’t tune back to that channel till i manually change the > channels.conf back again. > > I’m I missing a setting somewhere? No -- looks like your service provider announces the stream as MPEG2. Please ask your service provider to fix this issue. Try the attached patch as workaround meanwhile. It doesn't change vpid anymore to MPEG2 once you've changed it to H.264 manually. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1221 - Release Date: 1/12/2008 2:04 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1224 - Release Date: 1/14/2008 5:39 PM ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.5.13 (and earlier)
Le dimanche 13 janvier 2008 à 22:35 +0100, Gregoire Favre a écrit : > ITV1 > London;BSkyB:10758:vC56S0Z0:S28.2E:22000:2305:2310=eng,2314=NAR:2315:0:10060:2:2044:0 I have recorded from it and can see recording but it is not visible as live TV Does that help? Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev-client multiple servers
Олег, et al., Yes, I thought about that (It would work even better if you replace /bin/cp with /bin/ln:), but still, wouldn't a solution with one plugin work better, namely, I've noticed that the start-up latency of VDR depends largely on a number of loaded plugins. Another solution that works, but still is unacceptable (to me), is to setup another client in the first server that uses the second server (and so on). In any case, for both solutions, channel switch time for a large number of servers (say 10) will be much larger than ideal, since every server would be queried serially. Doing it with just one client in parallel for every configured server would be much more scalable I think... Thanks for reply! Pjotr oleg roitburd wrote: > Hi, > > 2008/1/14, Pjotr Kourzanov <[EMAIL PROTECTED]>: >>Is there a patch for allowing streamdev-client to connect (using VTP) to >> multiple streamdev-server's? Current code AFAIK only handles one IP for the >> VTP server. What I actually want is to have streamdev-client support for >> querying a list of servers (in some order) for a given channel, and then >> connecting to a suitable one if several were found. > > it's easy. You don't need any patch ;-) > http://www.vdr-wiki.de/wiki/index.php/Streamdev-plugin#Streamdev-client_mit_mehreren_Verbindungen_oder_Servern > Small translation > Copy a libvdr-streamdev-client.so.$(APIVERSION) to > libvdr-streamdev-client2.so.$(APIVERSION). Start a vdr with both > clients, and define for each client a IP of server. > > Пока > Олег > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + h264
On Tuesday 15 January 2008, Stefan Lucke wrote:
> On Tuesday 15 January 2008, Reinhard Nissl wrote:
> > Hi,
> >
> > Stefan Lucke schrieb:
> >
> > > is it correct that h264 is written as PES via PlayVideo() ?
> > >
> > > For decoding with ffmpeg it would be useful to have a
> > > PROGRAM_STREAM_MAP in front of a new video stream.
> >
> > Basically not a bad idea, but where do you put it in live
> > streaming?
>
> I think it should be transmitted first, after a stream reset.
> A basic PSM that maps from PES 0x01e0 to h264 could
> look like:
> unsigned char psm_map_0xe0_to_h264 [] =
> { 0x00, 0x00, 0x01, 0xbc,
> 0x00, 0x10, // psm length
> 0x00, 0x00, // unknown
> 0x00, 0x00, // info length
> // info data here
> 0x00, 0x04 // map length
> // map data here
> 0x1b, 0xe0, 0x00, 0x00 // h264 map entry / NO map info
> 0x00, 0x00, 0x00, 0x00 // crc32
> };
>
> That is inspired by ffmpegs: libavformat/mpeg.c
> mpegps_psm_parse() line ~220 .
And now I know that softdevice can switch between h264 and mpeg2
when using the following addition (file remux.c line ~2552):
#define TEST_cVideoRepacker
#ifdef TEST_cVideoRepacker
ts2pes[numTracks++] = new cTS2PES(VPid, resultBuffer, IPACKS, 0xE0, 0x00,
new cVideoRepacker(h264));
#else
ts2pes[numTracks++] = new cTS2PES(VPid, resultBuffer, IPACKS, 0xE0);
#endif
-- cut --
if (h264) {
resultBuffer->Put (psm_map_0xe0_to_h264, sizeof (psm_map_0xe0_to_h264));
fprintf(stderr, " is h264\n");
} else {
fprintf(stderr, " is NO h264\n");
}
-- cut --
The bad thing is, PSM info should be repeated more often, as the decoder
may reset itself due to bad reception (ahead of each video packet ??).
Or is there a simpler way to recognize h264 (or other codecs)
as Klaus demands?
Stefan Lucke
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Pseudo-real-time h264 transcoding of mpeg2 vdr recordings
Magnus Hörlin wrote: -snip- > then I can't relax Therefore I have made a script that scans my video > dir for new recordings -snip- Have you tried the "-r" option? You can start a conversion after the file has been recorded completly. Take a look here: http://www.vdr-wiki.de/wiki/index.php/VDR_Optionen#record Have a nice holiday. André > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Pseudo-real-time h264 transcoding of mpeg2 vdr recordings
On 15.01.2008 09:35, Magnus Hörlin wrote: > I'm sorry for bothering you with a question that should possibly have been > sent to the mplayer mailing list. > Next week I'm going to Tenerife to relax by the pool, but I don't want to > miss any biathlon, alpine- or cross-country skiing transmissions, because > then I can't relax Therefore I have made a script that scans my video > dir for new recordings and starts encoding them to h264/AAC right away to a > bitrate of around 800kbps, which is what I can send from my server. Since I > will have internet access in my hotel room, I'm hoping to sit on the balcony > with my laptop and play the recordings using mplayer or xine while > downloading them. > One problem is that my vdr server is too slow to do it in real time and my > vdr client is too fast (AMD BE-2400), so when mencoder "catches up" with > real-time it exits instead of continuing until the vdr file is closed. > And the same goes for wget which I planned to use for downloading the files. > I guess there are many very simple ways to do this so I hope you don't mind > my wasting your time by asking here. > The obvious way would be to let vdr start encoding when the recording ends, > but I don't want to wait for that. There must be a better way. For the download-part the easiest(tm) way is to rate-limit the connection. wget --limit-rate scp -l rsync --bwlimit With a little head-start on the encoding and a matching limit a continous download shouldn't be a problem. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + h264
On 01/15/08 08:53, Stefan Lucke wrote:
> On Tuesday 15 January 2008, Reinhard Nissl wrote:
>> Hi,
>>
>> Stefan Lucke schrieb:
>>
>>> is it correct that h264 is written as PES via PlayVideo() ?
>>>
>>> For decoding with ffmpeg it would be useful to have a
>>> PROGRAM_STREAM_MAP in front of a new video stream.
>> Basically not a bad idea, but where do you put it in live
>> streaming?
>
> I think it should be transmitted first, after a stream reset.
> A basic PSM that maps from PES 0x01e0 to h264 could
> look like:
> unsigned char psm_map_0xe0_to_h264 [] =
> { 0x00, 0x00, 0x01, 0xbc,
> 0x00, 0x10, // psm length
> 0x00, 0x00, // unknown
> 0x00, 0x00, // info length
> // info data here
> 0x00, 0x04 // map length
> // map data here
> 0x1b, 0xe0, 0x00, 0x00 // h264 map entry / NO map info
> 0x00, 0x00, 0x00, 0x00 // crc32
> };
>
> That is inspired by ffmpegs: libavformat/mpeg.c
> mpegps_psm_parse() line ~220 .
>
>> Or after a seek in VDR's recording player?
>
> By above, it's just (pinned) at the beginning of the file.
> Don't know if we should expect changes in between
> (but all bad things happen).
>
>> Mplayer does some nice tests to determine PES vs. ES. It has just
>> not been extended to detect H.264 in the same way.
>
> Aren't users beeing told to feed mplayer with PSM too ?
>
>> H.264 uses a
>> limited start code set compared to MPEG1/2 so it should be easy
>> to detect the content, due to the distribution of start codes.
Why does H.264 have to be such a broken format?
MPEG2 can be handled just fine in PES, why can't H.264 be, too?
Why can't H.264 video packets be recognized as such all by themselves,
just like MPEG2 or MPEG1 packets are?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT: Pseudo-real-time h264 transcoding of mpeg2 vdr recordings
I'm sorry for bothering you with a question that should possibly have been sent to the mplayer mailing list. Next week I'm going to Tenerife to relax by the pool, but I don't want to miss any biathlon, alpine- or cross-country skiing transmissions, because then I can't relax Therefore I have made a script that scans my video dir for new recordings and starts encoding them to h264/AAC right away to a bitrate of around 800kbps, which is what I can send from my server. Since I will have internet access in my hotel room, I'm hoping to sit on the balcony with my laptop and play the recordings using mplayer or xine while downloading them. One problem is that my vdr server is too slow to do it in real time and my vdr client is too fast (AMD BE-2400), so when mencoder "catches up" with real-time it exits instead of continuing until the vdr file is closed. And the same goes for wget which I planned to use for downloading the files. I guess there are many very simple ways to do this so I hope you don't mind my wasting your time by asking here. The obvious way would be to let vdr start encoding when the recording ends, but I don't want to wait for that. There must be a better way. /Magnus H ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
