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 10000 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+10000 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?
Thankz
ShorTie
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.2/1221 - Release Date: 1/12/2008 2:04 PM
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 10000 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+10000 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.
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: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] 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 10000 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+10000 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.
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.
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 10000
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 10000 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+10000 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?
Hi,
Christian Tramnitz schrieb:
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 10000
I don't know what it does or is meant to do, but I also have wrong pids in my channels.conf
At the moment, cRemux needs to know whether it has to do MPEG1/2 or H.264. kls didn't want to spend an extra parameter, so we decided to code this information into Vpid, like polarisation is coded into frequency.
Regular pid values range from 0 to 8191, and as the value is stored in decimal system in channels.conf, we chose 10000 as offset to have the original vpid still readable.
I'm thinking about auto detecting H.264 in cRemux (i. e. cVideoRepacker), but it may yield wrong results. That's why I haven't started coding yet.
Bye.
On Wed, Jan 16, 2008 at 08:19:53PM +0100, Reinhard Nissl wrote:
I'm thinking about auto detecting H.264 in cRemux (i. e. cVideoRepacker), but it may yield wrong results. That's why I haven't started coding yet.
Such a simple detection is implemented in ScanVideoPacket() of the remuxer-rewrite of the Reelbox. I haven't seen a problem with that code for almost a year now...
-
Christian Tramnitz -
Georg Acher -
Reinhard Nissl -
ShorTie