Re: [vdr] VDR - xine - CoreAVC
On Feb 11, 2008 11:03 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote: > I've posted the URL to the spec some weeks ago already. In that > issue, have a look into Annex E.2.1, Table E-1, Page 313. > Sorry. I'll see what I can dig out to set that up properly. For now hardcoding works well as most H264 channels are 16:9. > Simply set the progressive_frame flag. > > To disable it completely for your decoder even in this case, do > not set VO_INTERLACED_FLAG when getting the frame. > Yup, it was set right there and no need for it. Now CoreAVC runs with much better performance with xine. No more dropped frames... :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
On Feb 11, 2008 11:00 PM, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > Which CPU are you using? > AMD BE-2350 overclocked to 2.6Ghz. Now running H264 channels like a charm with CoreAVC. Almost there ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi, Morfsta schrieb: >> Well, the spec tells you that aspect_ratio_idc 11 means a sample >> (pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080 >> pixels so the frame aspect ratio yields: >> >>far = 1.3636 * 1440 / 1080 = 1.8181 > > Could you give me a link to where you found that please? I've posted the URL to the spec some weeks ago already. In that issue, have a look into Annex E.2.1, Table E-1, Page 313. > Also, I just discovered another problem with this method. I was > wondering why the performance on HD was so poor and it turns out that > the picture was being de-interlaced twice, once by CoreAVC for the > h264 picture and then by xine post plugin (tvtime). When I remove the > post deinterlacing plugin the performance is much better and now seems > to decode all the h264 channels I have access to pretty well with ~40% > idle. However, when I go back to a MPEG2 channel of course the > deinterlacing is now disabled and it looks terrible! > > Do you know if its possible to enable de-interlacing for only a > certain picture type(s), or am I looking at this the wrong way? Simply set the progressive_frame flag. But use_progressive_frame_flag=0 overrides this information and will still deinterlace. To disable it completely for your decoder even in this case, do not set VO_INTERLACED_FLAG when getting the frame. Have a look into ff_video_decoder.c. 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 - xine - CoreAVC
On 12 Feb 2008, at 08:27, Morfsta wrote: > now seems to decode all the h264 channels I have access to pretty > well with ~40% idle. Which CPU are you using? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
> Well, the spec tells you that aspect_ratio_idc 11 means a sample > (pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080 > pixels so the frame aspect ratio yields: > >far = 1.3636 * 1440 / 1080 = 1.8181 > Could you give me a link to where you found that please? Also, I just discovered another problem with this method. I was wondering why the performance on HD was so poor and it turns out that the picture was being de-interlaced twice, once by CoreAVC for the h264 picture and then by xine post plugin (tvtime). When I remove the post deinterlacing plugin the performance is much better and now seems to decode all the h264 channels I have access to pretty well with ~40% idle. However, when I go back to a MPEG2 channel of course the deinterlacing is now disabled and it looks terrible! Do you know if its possible to enable de-interlacing for only a certain picture type(s), or am I looking at this the wrong way? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi,
Morfsta schrieb:
> I used xinelibout for my H264 parser but Petri Hintukainen skips
> parsing of the VUI! I am looking in your h264parser.c in VDR and you
> also seem to comment this stuff out!
Well, I have no use for this kind of information, but I have to
read over it as there is no other way to get to relevant
information behind it :-(
> So, here is my code: -
>
>if (br_get_bit(&br)) { /* VUI parameters */
> if (br_get_bit(&br)) { /* Aspect Info */
> uint32_t aspect_ratio_idc = br_get_u8(&br);
> printf("H.264 SPS: -> Aspect Ratio IDC %d\n", aspect_ratio_idc);
> const uint32_t Extended_SAR = 255;
> if (aspect_ratio_idc == Extended_SAR) {
> uint32_t sar_width = br_get_u16(&br);
> uint32_t sar_height = br_get_u16(&br);
> printf("H.264 SPS: -> SAR_Size = %dx%d\n",
> sar_width, sar_height);
> }
> }
>}
>
> I am getting an Aspect Ratio IDC of 11 so the sar width and height
> calcs are not called. What do I need to do here to get the aspect
> (~1.818181)?
Well, the spec tells you that aspect_ratio_idc 11 means a sample
(pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080
pixels so the frame aspect ratio yields:
far = 1.3636 * 1440 / 1080 = 1.8181
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 - xine - CoreAVC
On Feb 11, 2008 9:09 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> In case the decoder doesn't provide the image aspect ratio (and
> it looks like that as you had to provide the image size too),
> you'll have to extract it from the H.264 data yourself (as you
> did already for the image size).
>
OK - thanks for your help and patience Reinhard.
We are on the right track here. If I hardcode the this->ratio to be
1.8181 all looks good for my channels. However it is a hack and I have
come this far, so I might as well get the rest correct!
I used xinelibout for my H264 parser but Petri Hintukainen skips
parsing of the VUI! I am looking in your h264parser.c in VDR and you
also seem to comment this stuff out!
So, here is my code: -
if (br_get_bit(&br)) { /* VUI parameters */
if (br_get_bit(&br)) { /* Aspect Info */
uint32_t aspect_ratio_idc = br_get_u8(&br);
printf("H.264 SPS: -> Aspect Ratio IDC %d\n", aspect_ratio_idc);
const uint32_t Extended_SAR = 255;
if (aspect_ratio_idc == Extended_SAR) {
uint32_t sar_width = br_get_u16(&br);
uint32_t sar_height = br_get_u16(&br);
printf("H.264 SPS: -> SAR_Size = %dx%d\n",
sar_width, sar_height);
}
}
}
I am getting an Aspect Ratio IDC of 11 so the sar width and height
calcs are not called. What do I need to do here to get the aspect
(~1.818181)?
Thanks again!
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
> 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 - xine - CoreAVC
Hi,
Morfsta schrieb:
> The coreavc patch for xine has this code in it: -
>
> +if(!img) {
> +img = this->stream->video_out->get_frame (this->stream->video_out,
> + this->bih->biWidth,
> + this->bih->biHeight,
> + this->ratio,
> + IMGFMT_YUY2,
> + field);
> +}
>
> with this->ratio =
> (double)this->bih->biWidth/(double)this->bih->biHeight;
Looks not bad, but ratio is wrong. For your sample 1440 x 1080 it
will yield 1. and not 1.8181 (or 1.7778). Therefore you get
those black bars left and right to the image.
In case the decoder doesn't provide the image aspect ratio (and
it looks like that as you had to provide the image size too),
you'll have to extract it from the H.264 data yourself (as you
did already for the image size).
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 - xine - CoreAVC
On Feb 11, 2008 8:09 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Anyway, does the decoder tell you the aspect ratio anywhere?
>
> The aspect ratio must be passed to get_frame(). When the frame
> has the correct aspect ratio set, xine-lib will take care to
> setup the video scaler to stretch for example the image to 136 %
> horizontally.
The coreavc patch for xine has this code in it: -
+if(!img) {
+img = this->stream->video_out->get_frame (this->stream->video_out,
+ this->bih->biWidth,
+ this->bih->biHeight,
+ this->ratio,
+ IMGFMT_YUY2,
+ field);
+}
with this->ratio = (double)this->bih->biWidth/(double)this->bih->biHeight;
This is all within xine's src/libw32dll/w32codec.c which is a
different area to which I was modifying before
(src/demuxers/demux_mpeg_pes.c) where the codec is initialised.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi, Morfsta schrieb: >> Just a guess: maybe the above bih.biXPelsPerMeter and >> bih.biYPelsPerMeter can be used to set the pixel aspect ratio >> which will then in turn yield the frame aspect ratio when applied >> to the coded frame size. So pixel aspect for the above sample >> should yield: >> >>pa = 1.81818 * 1080 / 1440 = 1.363635 >> >> and most likely: >> >>bih.biXPelsPerMeter=13636 > > I tried that, what would the bih.biYPelsPerMeter be in this instance? > 1? Even then it doesn't seem to make any difference. That's why I wrote "guess". Anyway, does the decoder tell you the aspect ratio anywhere? The aspect ratio must be passed to get_frame(). When the frame has the correct aspect ratio set, xine-lib will take care to setup the video scaler to stretch for example the image to 136 % horizontally. 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 - xine - CoreAVC
On Feb 11, 2008 6:31 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote: > Just a guess: maybe the above bih.biXPelsPerMeter and > bih.biYPelsPerMeter can be used to set the pixel aspect ratio > which will then in turn yield the frame aspect ratio when applied > to the coded frame size. So pixel aspect for the above sample > should yield: > >pa = 1.81818 * 1080 / 1440 = 1.363635 > > and most likely: > >bih.biXPelsPerMeter=13636 > I tried that, what would the bih.biYPelsPerMeter be in this instance? 1? Even then it doesn't seem to make any difference. There is a reference to that structure here: - http://www.herdsoft.com/ti/davincie/davp3xo2.htm I think I'm quite close to getting this sorted but just can't seem to get this final output right.. :-( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi, Morfsta schrieb: > I have managed to get xine to now detect the H264 video size prior to > starting up the CoreAVC decoder and set the size within the > initialisation function: - > > memset(&bih, 0x00, sizeof(bih)); > bih.biWidth = sps.width; > bih.biHeight = sps.height; > bih.biPlanes = 1; > bih.biBitCount = 24; > bih.biCompression = 0x34363248; //31435641; //AVC1 > bih.biSizeImage = 0; > bih.biXPelsPerMeter=1; > bih.biYPelsPerMeter=1; > bih.biClrUsed=0; > bih.biClrImportant=0; > bih.biSize = sizeof(bih); > buf->content = malloc(sizeof(bih)); > > It detects BBC HD as the right video size, i.e. 1440 x 1080 - however > this now results in a squased image on the display with black bars > down the left and right sides. Any idea how you tell CoreAVC what the > video size is and to scale it to the size that xine is using? It > detects other video sizes such as 1920x1088 and displays them all > correctly on the screen so I know that we are now very close! Looks like you/CoreAVC miss setting the aspect ratio of the frame. If you replay a BBC HD recording with xine (using FFmpeg) and open a VDR menu, you should see messages like that which tell you the frame aspect ratio after the @: vdr_video: osd: (0, 0)-(1440, 1080)@1,81818 ratio: 18182 Just a guess: maybe the above bih.biXPelsPerMeter and bih.biYPelsPerMeter can be used to set the pixel aspect ratio which will then in turn yield the frame aspect ratio when applied to the coded frame size. So pixel aspect for the above sample should yield: pa = 1.81818 * 1080 / 1440 = 1.363635 and most likely: bih.biXPelsPerMeter=13636 BTW: the above ratio of 1.81818 is different from 16:9 which is 1.8. I've no idea why BBC uses this "strange" ratio. And 1920x1088 doesn't yield 16:9 either, but 1.76471. 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 - xine - CoreAVC
Hi, Morfsta schrieb: > I'm not sure about that. So, if the function identifies an AUD at the > start of the payload then it could go on and scan the rest of the > payload for an SPS? In other words we must scan after the AUD for > > Data[0] = 0x00 > Data[1] = 0x00 > Data[2] = 0x01 > Data[3] & 0x1F = 0x07 > > and start parsing from Data[4]? > > How can we be sure that combination of bytes doesn't exist by chance > in the picture payload anyway? cVideoRepacker takes care that each field / frame is preceded by an AUD. A SPS appears before slice start codes and is typically found only in I frames. The special coding (see annex B if I recall correctly) takes care that video data doesn't emulate NAL start codes. 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 - xine - CoreAVC
On Jan 24, 2008 9:54 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Typically, a SPS is found in the same memory block which starts
> with an AUD for an "I frame". From VDR's remux.c,
> cRemux::ScanVideoPacket():
>
> if (!p[-2] && !p[-1]) { // found 0x01
> if (h264) {
>int nal_unit_type = p[1] & 0x1F;
>switch (nal_unit_type) {
> case 9: { // access unit delimiter
> int primary_pic_type = p[2] >> 5;
> switch (primary_pic_type) {
> case 0: // I
> case 3: // SI
> case 5: // I, SI
> PictureType = I_FRAME;
> break;
>
> > It might be the case that the whole initialisation of the CoreAVC
> > decoder would be better suited somewhere else in the code :-\
>
> Doesn't the decoder support a callback function where it tells
> you, the detected frame size? It'll really be a mess to do H.264
> "decoding" in the demuxer.
>
I'm not sure about that. So, if the function identifies an AUD at the
start of the payload then it could go on and scan the rest of the
payload for an SPS? In other words we must scan after the AUD for
Data[0] = 0x00
Data[1] = 0x00
Data[2] = 0x01
Data[3] & 0x1F = 0x07
and start parsing from Data[4]?
How can we be sure that combination of bytes doesn't exist by chance
in the picture payload anyway?
Cheers
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi,
Morfsta schrieb:
> It seems that you must start scanning the mpeg stream for a Sequence
> Parameter Set with a NAL Access Code of 7. At first glance this
> doesn't appear too bad, as the code is already in
> src/demuxers/demux_mpeg_pes.c to scan for a NAL code of 9 (Access Unit
> Delimiter), which it uses to detect the presence of H264 stream.
Correct.
> I thought it would be quite straightforward to find the NAL code of 7
> and then parse the SPS and in turn find the height and width
> parameters. However, trying to get this to work in sequence is not
> that easy as the parse_video_stream seems to want to identify MPEG1/2
> or H264 and then just init the decoders. This is where the
> initialisation of CoreAVCDecoder.ax is made, currently with the
> hardcoded video size of 1920x1080. What I want it to do is identify
> the H264 stream and then keep scanning for an SPS to identify the size
> prior to initting the decoder.
>
> It seems that once it's found the AUD it doesn't really want to keep
> looking for a SPS. I tried modifying the code to look for a SPS to
> init the H264 sequence, however haven't had much success with that
> either.
Typically, a SPS is found in the same memory block which starts
with an AUD for an "I frame". From VDR's remux.c,
cRemux::ScanVideoPacket():
if (!p[-2] && !p[-1]) { // found 0x01
if (h264) {
int nal_unit_type = p[1] & 0x1F;
switch (nal_unit_type) {
case 9: { // access unit delimiter
int primary_pic_type = p[2] >> 5;
switch (primary_pic_type) {
case 0: // I
case 3: // SI
case 5: // I, SI
PictureType = I_FRAME;
break;
> It might be the case that the whole initialisation of the CoreAVC
> decoder would be better suited somewhere else in the code :-\
Doesn't the decoder support a callback function where it tells
you, the detected frame size? It'll really be a mess to do H.264
"decoding" in the demuxer.
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 - xine - CoreAVC
Yes, I started looking at that. I also downloaded some H264 reference
utilities that someone at Dolby put together.
It seems that you must start scanning the mpeg stream for a Sequence
Parameter Set with a NAL Access Code of 7. At first glance this
doesn't appear too bad, as the code is already in
src/demuxers/demux_mpeg_pes.c to scan for a NAL code of 9 (Access Unit
Delimiter), which it uses to detect the presence of H264 stream.
I thought it would be quite straightforward to find the NAL code of 7
and then parse the SPS and in turn find the height and width
parameters. However, trying to get this to work in sequence is not
that easy as the parse_video_stream seems to want to identify MPEG1/2
or H264 and then just init the decoders. This is where the
initialisation of CoreAVCDecoder.ax is made, currently with the
hardcoded video size of 1920x1080. What I want it to do is identify
the H264 stream and then keep scanning for an SPS to identify the size
prior to initting the decoder.
It seems that once it's found the AUD it doesn't really want to keep
looking for a SPS. I tried modifying the code to look for a SPS to
init the H264 sequence, however haven't had much success with that
either.
It might be the case that the whole initialisation of the CoreAVC
decoder would be better suited somewhere else in the code :-\
Still, I knew nothing about MPEG2 and MPEG4 formats this morning and
now I know a tiny bit! Unfortunately, I'm not sure if I have the
coding skills to be able to finish the job.. :-(
On Jan 24, 2008 7:31 PM, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Morfsta schrieb:
>
>
> > OK, I have added the following code into src/demuxers/demux_mpeg_pes.c
> >
> > static int32_t GetVideoSize(const uint8_t *buf, int length, int
> > *width, int *height)
> > {
> > int i = 0; // the minimum length of the video packet header
> > //i += buf[i] + 1; // possible additional header bytes
> > for (; i < length-6; i++) {
> > if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
> > if(buf[i + 3] == 0xb3) {
> > int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
> > *width = (d >> 12);
> > *height = (d & 0xfff);
> > return 1;
> > }
> > }
> > }
> > return 0;
> > }
> >
> > and then put the following code in parse_video_stream: -
> >
> > int Width, Height;
> > if (GetVideoSize(p, payload_size, &Width, &Height)) {
> >printf("Detected video size %dx%d\n", Width, Height);
> > }
> > else {
> >printf("Failed to detect video size\n");
> > }
> >
> > before: /* H.264 broadcasts via DVB-S use standard video PES packets,
> >
> > This detects the video size for MPEG2 broadcasts (Detected video size
> > 704x576
> > ), but not for H264, I'm guessing the payload is in a different
> > format. Can anyone point me in the direction of a GetVideoSize type of
> > function for H264 (I looked in libavcodec and the code looks a bit
> > more complex!), or spot what I am doing wrong here?
>
> In H.264, this information in coded far more complex. Have a look
> into VDR's h264parser.c. Look for pic_width_in_mbs_minus1,
> pic_height_in_map_units_minus1 and frame_crop_*_offset.
>
> You can get the standard from here for free:
> http://www.itu.int/rec/T-REC-H.264-200503-I/en
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:[EMAIL PROTECTED]
>
> ___
>
> 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 - xine - CoreAVC
Hi,
Morfsta schrieb:
> OK, I have added the following code into src/demuxers/demux_mpeg_pes.c
>
> static int32_t GetVideoSize(const uint8_t *buf, int length, int
> *width, int *height)
> {
> int i = 0; // the minimum length of the video packet header
> //i += buf[i] + 1; // possible additional header bytes
> for (; i < length-6; i++) {
> if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
> if(buf[i + 3] == 0xb3) {
> int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
> *width = (d >> 12);
> *height = (d & 0xfff);
> return 1;
> }
> }
> }
> return 0;
> }
>
> and then put the following code in parse_video_stream: -
>
> int Width, Height;
> if (GetVideoSize(p, payload_size, &Width, &Height)) {
>printf("Detected video size %dx%d\n", Width, Height);
> }
> else {
>printf("Failed to detect video size\n");
> }
>
> before: /* H.264 broadcasts via DVB-S use standard video PES packets,
>
> This detects the video size for MPEG2 broadcasts (Detected video size 704x576
> ), but not for H264, I'm guessing the payload is in a different
> format. Can anyone point me in the direction of a GetVideoSize type of
> function for H264 (I looked in libavcodec and the code looks a bit
> more complex!), or spot what I am doing wrong here?
In H.264, this information in coded far more complex. Have a look
into VDR's h264parser.c. Look for pic_width_in_mbs_minus1,
pic_height_in_map_units_minus1 and frame_crop_*_offset.
You can get the standard from here for free:
http://www.itu.int/rec/T-REC-H.264-200503-I/en
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 - xine - CoreAVC
OK, I have added the following code into src/demuxers/demux_mpeg_pes.c
static int32_t GetVideoSize(const uint8_t *buf, int length, int
*width, int *height)
{
int i = 0; // the minimum length of the video packet header
//i += buf[i] + 1; // possible additional header bytes
for (; i < length-6; i++) {
if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
if(buf[i + 3] == 0xb3) {
int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
*width = (d >> 12);
*height = (d & 0xfff);
return 1;
}
}
}
return 0;
}
and then put the following code in parse_video_stream: -
int Width, Height;
if (GetVideoSize(p, payload_size, &Width, &Height)) {
printf("Detected video size %dx%d\n", Width, Height);
}
else {
printf("Failed to detect video size\n");
}
before: /* H.264 broadcasts via DVB-S use standard video PES packets,
This detects the video size for MPEG2 broadcasts (Detected video size 704x576
), but not for H264, I'm guessing the payload is in a different
format. Can anyone point me in the direction of a GetVideoSize type of
function for H264 (I looked in libavcodec and the code looks a bit
more complex!), or spot what I am doing wrong here?
TIA
On Jan 23, 2008 11:50 AM, Morfsta <[EMAIL PROTECTED]> wrote:
> hmmm, I've been looking into the demux_mpeg_pes function in xine,
> isn't the height and width stored in the transport stream within the
> pes? I tried to adapt the code that shows the resolution in femon to
> work on the stream in demux_mpeg_pes but not had much success so far..
> :-(
>
> Do you have to parse through the payload itself?
>
>
> On Jan 23, 2008 3:10 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote:
> > Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly
> > up, and for BBS HD it is necessary 1440?1080
> >
> > > Hey, it works ... Sort of. Anyone else having the "green bar" problem?
> > > I get a large green bar across the bottom of the screen and four fuzzy
> > > representations of the picture above it on: -
> > >
> > > BBC HD
> > > DigitalAlb HD-1
> > > DigitalAlb HD-2
> > > SVT HD
> >
> >
> >
> > ___
> > 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 - xine - CoreAVC
hmmm, I've been looking into the demux_mpeg_pes function in xine, isn't the height and width stored in the transport stream within the pes? I tried to adapt the code that shows the resolution in femon to work on the stream in demux_mpeg_pes but not had much success so far.. :-( Do you have to parse through the payload itself? On Jan 23, 2008 3:10 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote: > Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly > up, and for BBS HD it is necessary 1440?1080 > > > Hey, it works ... Sort of. Anyone else having the "green bar" problem? > > I get a large green bar across the bottom of the screen and four fuzzy > > representations of the picture above it on: - > > > > BBC HD > > DigitalAlb HD-1 > > DigitalAlb HD-2 > > SVT HD > > > > ___ > 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 - xine - CoreAVC
Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly up, and for BBS HD it is necessary 1440?1080 > Hey, it works ... Sort of. Anyone else having the "green bar" problem? > I get a large green bar across the bottom of the screen and four fuzzy > representations of the picture above it on: - > > BBC HD > DigitalAlb HD-1 > DigitalAlb HD-2 > SVT HD ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hey, it works ... Sort of. Anyone else having the "green bar" problem? I get a large green bar across the bottom of the screen and four fuzzy representations of the picture above it on: - BBC HD DigitalAlb HD-1 DigitalAlb HD-2 SVT HD However, Channel 4 HD and a number of other HD channels work fine. Anyone else managed to see BBC HD okay? I know it is supported with the CoreAVC codec... It's swings and roundabouts - some spatial mode channels now are fine! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Darren Salt skrev: > I demand that Morfsta may or may not have top-posted AGAIN... > >> On Jan 21, 2008 4:06 PM, Darren Salt <[EMAIL PROTECTED]> >> wrote: >>> I demand that Morfsta may or may not have written... Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1 is defined in xine-engine.h. >>> I don't know where your xine-engine.h came from, but it's not xine-lib. > >> It was in the tar file that Per posted earlier of his xine-lib! > > I've not looked in that tarball, but I can say for certain that there is no > header of that name in any xine-lib tarball which I've generated. > > [snip quoted .sigs] That tar-ball included all the patches from coreavc, dvbn and walery. IIRC the difference is in the dvbn-patch. Per ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
I demand that Morfsta may or may not have top-posted AGAIN... > On Jan 21, 2008 4:06 PM, Darren Salt <[EMAIL PROTECTED]> > wrote: >> I demand that Morfsta may or may not have written... >>> Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1 >>> is defined in xine-engine.h. >> I don't know where your xine-engine.h came from, but it's not xine-lib. > It was in the tar file that Per posted earlier of his xine-lib! I've not looked in that tarball, but I can say for certain that there is no header of that name in any xine-lib tarball which I've generated. [snip quoted .sigs] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | http://www.youmustbejoking.demon.co.uk/progs.packages.html> Get out of that one. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
That got it! I've got it working now in the 32-bit chroot environment, I can see it loading the CoreAVC codec when switching to BBC HD. Sadly, I'm doing this remotely so can't see how the results actually look on the TV until tomorrow! I'm keen on seeing a channel that uses spatial direct mode. Has anyone managed to get the xinelibout patch working so that VDR doesn't coredump on startup? On Jan 21, 2008 5:45 PM, VDR User <[EMAIL PROTECTED]> wrote: > On Jan 21, 2008 7:01 AM, Morfsta <[EMAIL PROTECTED]> wrote: > > However, I get this error message: - > > > > w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this > > function) > > Try: > > --- xine-lib/src/xine-engine/buffer.h.orig 2007-11-05 18:33:03.0 > -0500 > +++ xine-lib/src/xine-engine/buffer.h 2007-11-05 18:33:38.0 -0500 > @@ -192,6 +192,8 @@ > #define BUF_VIDEO_CAVS 0x0262 > #define BUF_VIDEO_VP6F 0x0263 > #define BUF_VIDEO_THEORA_RAW 0x0264 > +#define BUF_VIDEO_VC1 0x0265 > +#define BUF_VIDEO_WVC1 0x0265 > > /* audio buffer types: (please keep in sync with buffer_types.c) */ > > > ___ > 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 - xine - CoreAVC
Hi, Igor schrieb: > is there any difference between xine-lib 1.2 branch and 1.1 branch for our > case ? The 1.2 branch contains my VDR plugins while the 1.1 branch needs a patch, which vdr-xine-0.8.1 provides. Don't think that this is relevant for our goals. The patch for the 1.1 branch is mainly meant for distributions which want to ship a xine-lib-1.1 with support for my VDR plugin. As 1.2 is still in development, API version numbers are likely to change and therefore most xine-lib-1.1 based software needs some (often minor) patches to get it going with xine-lib-1.2. 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 - xine - CoreAVC
On Jan 21, 2008 7:01 AM, Morfsta <[EMAIL PROTECTED]> wrote: > However, I get this error message: - > > w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this > function) Try: --- xine-lib/src/xine-engine/buffer.h.orig 2007-11-05 18:33:03.0 -0500 +++ xine-lib/src/xine-engine/buffer.h 2007-11-05 18:33:38.0 -0500 @@ -192,6 +192,8 @@ #define BUF_VIDEO_CAVS 0x0262 #define BUF_VIDEO_VP6F 0x0263 #define BUF_VIDEO_THEORA_RAW 0x0264 +#define BUF_VIDEO_VC1 0x0265 +#define BUF_VIDEO_WVC1 0x0265 /* audio buffer types: (please keep in sync with buffer_types.c) */ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
It was in the tar file that Per posted earlier of his xine-lib! On Jan 21, 2008 4:06 PM, Darren Salt <[EMAIL PROTECTED]> wrote: > I demand that Morfsta may or may not have written... > > > Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1 > > is defined in xine-engine.h. > > I don't know where your xine-engine.h came from, but it's not xine-lib. > > [snip; don't top-post] > -- > | Darren Salt| linux or ds at | nr. Ashington, | Toon > | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army > | + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING. > > Avoid run-on sentences they are hard to read. > > > ___ > 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 - xine - CoreAVC
I demand that Morfsta may or may not have written... > Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1 > is defined in xine-engine.h. I don't know where your xine-engine.h came from, but it's not xine-lib. [snip; don't top-post] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING. Avoid run-on sentences they are hard to read. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1 is defined in xine-engine.h. I added it to an include and its compiling-ish I'm actually cross compiling 32bit in my 64 bit environment which is fun with having to provide so many 32-bit libs. Still I don't fancy trashing my 64bit VDR box just to play around with CoreAVC - it runs quite a few other bits and pieces. On Jan 21, 2008 3:16 PM, Darren Salt <[EMAIL PROTECTED]> wrote: > I demand that Morfsta may or may not have written... > > [snip] > > However, I get this error message: - > > > w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this > > function) > > > I can't find anywhere in the code where this is declared but the > > coreavc patch adds it.. > > > Any ideas? > > Incomplete patch? > > Anyway, I'm guessing that it's for the same codec as BUF_VIDEO_VC1, which I > added for 1.1.9 (since it's one which ffmpeg implements). > > [snip] > -- > | Darren Salt| linux or ds at | nr. Ashington, | Toon > | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army > | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. > > Don't use a big word where a diminutive one will suffice. > > > ___ > 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 - xine - CoreAVC
I demand that Morfsta may or may not have written... [snip] > However, I get this error message: - > w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this > function) > I can't find anywhere in the code where this is declared but the > coreavc patch adds it.. > Any ideas? Incomplete patch? Anyway, I'm guessing that it's for the same codec as BUF_VIDEO_VC1, which I added for 1.1.9 (since it's one which ffmpeg implements). [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. Don't use a big word where a diminutive one will suffice. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC (Was: Re: CoreAVC + xineliboutput)
I demand that Gregoire Favre may or may not have written... > On Sun, Jan 20, 2008 at 10:20:40PM +0300, Igor wrote: >> please, try with this Makefile version from Walery >> http://allrussian.info/thread.php?postid=1226030#post1226030 > Thank. > I'll be lazy and wait for a current patch against xine-lib-1.2 :-) For these changes to have any chance of being accepted, they must be: * based on current 1.2 * split up into a series of incremental patches - a functional xine-lib after each patch is considered useful :-) and they must have: * the necessary changes to get libw32dll built on amd64 - unless it won't work on amd64, of course... * copyright/licence headers in each new file * suitable descriptions for each patch, with summary lines - this will make for easy import and useful output from "hg log" ffmpeg remains the preferred option, though. [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Economy makes men independent. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
OK, you are right. I am building it in a 32bit chroot environment and now it tried to build in lib32dll! However, I get this error message: - w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this function) I can't find anywhere in the code where this is declared but the coreavc patch adds it.. Any ideas? On Jan 21, 2008 2:42 PM, Darren Salt <[EMAIL PROTECTED]> wrote: > I demand that Morfsta may or may not have written... > > > I have been using xine-1.2 from the Mercurial distribution, but it > > still creates a plugin directory called 1.1.9 and sometimes 1.1.90. > > Wrong. 1.1.90 only. Any 1.1.9 which you see is from xine-lib 1.1.9. > > [snip] > > Running on Ubuntu 7.10 x86_64. > > libw32dll is built only in i386; I see nothing in the patch which causes it > to be built on amd64. > > [snip] > -- > | Darren Salt| linux or ds at | nr. Ashington, | Toon > | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army > | Kill all extremists! > > b Wrong file type, 0:1 > > > ___ > 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 - xine - CoreAVC
I demand that Morfsta may or may not have written... > I have been using xine-1.2 from the Mercurial distribution, but it > still creates a plugin directory called 1.1.9 and sometimes 1.1.90. Wrong. 1.1.90 only. Any 1.1.9 which you see is from xine-lib 1.1.9. [snip] > Running on Ubuntu 7.10 x86_64. libw32dll is built only in i386; I see nothing in the patch which causes it to be built on amd64. [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Kill all extremists! b Wrong file type, 0:1 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
At least Hoochster says in his HowTo (for myth this time) that "..CoreAVC will only run in 32bit mode. So if you are running 64bit Linux, then you will need to setup a 32bit Chroot to compile Mplayer with the patches. This Howto does not cover that, but if you reference the Wiki site at the top, there is a pre-compiled dshowserver binary for 64bit that will help. You will still need the 32bit setup for mplayer though.."http://www.hoochvdr.info/viewtopic.php?f=29&t=546 I didn't try this, just thought this info might help someone..> From: [EMAIL PROTECTED]> To: vdr@linuxtv.org> Date: Mon, 21 Jan 2008 14:40:01 +0300> Subject: Re: [vdr] VDR - xine - CoreAVC> > linux 64bit? Most likely in it a problem.> > > Also, if I do a make clean && make in that directory it doesn't do > > anything: -> >> > # make> > make[1]: Entering directory `/root/dshow/xine-lib-1.2/src/libw32dll'> > make[1]: Nothing to be done for `all-am'.> > make[1]: Leaving directory `/root/dshow/xine-lib-1.2/src/libw32dll'> >> > Could this be the problem? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC (Was: Re: CoreAVC + xineliboutput)
On Sun, Jan 20, 2008 at 10:20:40PM +0300, Igor wrote: > please, try with this Makefile version from Walery > http://allrussian.info/thread.php?postid=1226030#post1226030 Thank. I'll be lazy and wait for a current patch against xine-lib-1.2 :-) All the channels I have access to seems to works with ffmpeg and xine-lib-1.2 sofar... -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
linux 64bit? Most likely in it a problem. > Also, if I do a make clean && make in that directory it doesn't do > anything: - > > # make > make[1]: Entering directory `/root/dshow/xine-lib-1.2/src/libw32dll' > make[1]: Nothing to be done for `all-am'. > make[1]: Leaving directory `/root/dshow/xine-lib-1.2/src/libw32dll' > > Could this be the problem? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Same problem. I'm not sure that the w32 codec support is being built in xine. If I look in src/libw32dll I see: - :~/dshow/xine-lib-1.2/src/libw32dll# ls common.cMakefile Makefile.in qtx wine DirectShow Makefile.am nal_parser.c w32codec.c dmo Makefile.am.orig nal_parser.h w32codec.c.orig libwin32.h Makefile.am.rej qt_decoder.c w32codec.h there doesn't seem to be any .lo or .o files - do you have them? Also, if I do a make clean && make in that directory it doesn't do anything: - # make make[1]: Entering directory `/root/dshow/xine-lib-1.2/src/libw32dll' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/root/dshow/xine-lib-1.2/src/libw32dll' Could this be the problem? Thanks On Jan 21, 2008 11:05 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote: > > > See attached xine.log > > > > >load_plugins: plugin mpeg2 will be used for video streamtype 00. > > try delete /usr/local/lib libxine* and /usr/local/lib/xine dir and make > install xine again > > Walery > > > > ___ > 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 - xine - CoreAVC
> See attached xine.log > >load_plugins: plugin mpeg2 will be used for video streamtype 00. try delete /usr/local/lib libxine* and /usr/local/lib/xine dir and make install xine again Walery ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
See attached xine.log On Jan 21, 2008 7:30 AM, Walery Daniloff <[EMAIL PROTECTED]> wrote: > Hi, > > > Tried vdr-xine - this shows a black screen with audio but no video - > > message says it can't find a plugin to handle the video. > > show verbose-log - xine --verbose=2 > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > xine.log Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Morfsta skrev: > I have been using xine-1.2 from the Mercurial distribution, but it > still creates a plugin directory called 1.1.9 and sometimes 1.1.90. > Evereything except that you use Mercurial looks like my setup. I started of with the xine-lib I had on my machine, which was originally taken from Reinhards xine-site. ( http://home.vrweb.de/~rnissl ) > > So it seems that it just doesn't load the DLL. Am I missing any other > dependencies, do you need wine or anything else? You don't need wine. The thing I did to see if the .ax is loaded is [EMAIL PROTECTED] plugins]# lsof | grep Core xine 4548 root mem REG8,2 1031168141 /usr/lib/win32/CoreAVCDecoder.ax I can see it gets opened whenever I switch to a H.264 channel. > > Thanks for your help and hopefully the above can lead to a howto, and > perhaps someone can upload somewhere a patched and working xine-lib as > well as a patched and working xinelibout? My xine-lib: http://www.mellander.org/per/projects/linux/VDR-CoreAVC/xine-lib-with-coreavc-dvbn-walery.tar.gz This is in Swedish but please have a look at http://www.vdr.nu/forum/viewtopic.php?t=431 Per ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Hi, > Tried vdr-xine - this shows a black screen with audio but no video - > message says it can't find a plugin to handle the video. show verbose-log - xine --verbose=2 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
I have been using xine-1.2 from the Mercurial distribution, but it still creates a plugin directory called 1.1.9 and sometimes 1.1.90. I just can't get it to work! Here's the steps I have taken: - Running on Ubuntu 7.10 x86_64. Downloaded xine-lib-1.2 from hg Patched with xine.patch from google code site Fixed the Makefile.am problem Patched with additional patch posted from Per in this mailing list Patched with all additional patches that are in the Genpix thread on DVBN Ran configure (./configure --disable-dxr3) && make && make install Downloaded the CoreAVC unpacked file from rapidshare (coreavcdecoder_unpacked.ax) Put it in /usr/lib/win32 as (CoreAVCDecoder.ax) Remove /usr/local/lib/plugins/1.1.9/xineplug_decode_ff.so [THERE IS NO /usr/local/lib//1.1.9/xineplug_decode_qt.so] Remove /usr/local/lib/plugins/1.1.90/xineplug_decode_ff.so [THERE IS NO /usr/local/lib//1.1.90/xineplug_decode_qt.so] Patched xinelibout (this doesn't work and causes a segfault on VDR startup) Tried vdr-xine - this shows a black screen with audio but no video - message says it can't find a plugin to handle the video. So it seems that it just doesn't load the DLL. Am I missing any other dependencies, do you need wine or anything else? Thanks for your help and hopefully the above can lead to a howto, and perhaps someone can upload somewhere a patched and working xine-lib as well as a patched and working xinelibout? Thanks in advance for all your help. 2008/1/21 Igor <[EMAIL PROTECTED]>: > > I'll try 1.2, > > > may be it's the best case :) > > @Reinhard > > is there any difference between xine-lib 1.2 branch and 1.1 branch for our > case ? > > Igor > > > > > > > ___ > 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 - xine - CoreAVC
> I'll try 1.2, may be it's the best case :) @Reinhard is there any difference between xine-lib 1.2 branch and 1.1 branch for our case ? Igor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Gregoire Favre skrev: > On Sun, Jan 20, 2008 at 06:38:31PM +0100, Per Mellander wrote: > >> Don't know if it works for x86_64. >> >> I checked out xine-lib one minute ago to test and I had no problem. > > Well, that's very strange, I checked revision 32 of the svn, and the svn > (you spoke about a CVS of xine-lib which is abandonned for a long time) > of xine-lib-1.2 : > hg pull -u http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ > > Are you using xine-lib-1.1 by any chance ? Yes, 1.1.9 It's been very confusing to me. I started of by using the xine-lib that can be found on Reinards site http://home.vrweb.de/~rnissl/ Later on I figured out that cvs was abandoned so I checked out latest from hg clone http://hg.debian.org/hg/xine-lib/xine-lib/ I'm running the first one, patched with xine.patch from http://coreavc-for-linux.googlecode.com/svn/trunk/ and then handpatched with the diff's from happysat and last Walerys patch. I'm sorry if my input has been not that straight but I didn't realize the matter that cvs was abandoned until recently. I'll try 1.2, Per ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
On Sun, Jan 20, 2008 at 06:38:31PM +0100, Per Mellander wrote: > Don't know if it works for x86_64. > > I checked out xine-lib one minute ago to test and I had no problem. Well, that's very strange, I checked revision 32 of the svn, and the svn (you spoke about a CVS of xine-lib which is abandonned for a long time) of xine-lib-1.2 : hg pull -u http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ Are you using xine-lib-1.1 by any chance ? -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC (Was: Re: CoreA VC + xineliboutput)
> I wanted to try it, but if fails at patching : > > patching file src/libw32dll/Makefile.am > Hunk #1 FAILED at 13. > Hunk #2 FAILED at 33. > 2 out of 2 hunks FAILED -- saving rejects to file > src/libw32dll/Makefile.am.rej please, try with this Makefile version from Walery http://allrussian.info/thread.php?postid=1226030#post1226030 Igor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC
Gregoire Favre skrev: > Hello, > > one more "stupid" question : does it works also for x86_64 ? > > I wanted to try it, but if fails at patching : > > patching file src/libw32dll/Makefile.am > Hunk #1 FAILED at 13. > Hunk #2 FAILED at 33. > 2 out of 2 hunks FAILED -- saving rejects to file > src/libw32dll/Makefile.am.rej > > that with coreavc-for-linux/xine/xine.patch against xine-lib-1.2 from > today. > > Thank, Don't know if it works for x86_64. I checked out xine-lib one minute ago to test and I had no problem. patching file src/libw32dll/Makefile.am Hunk #1 succeeded at 15 (offset 2 lines). patching file src/libw32dll/nal_parser.c Where did you get the xine.patch? svn checkout http://coreavc-for-linux.googlecode.com/svn/trunk/ coreavc-for-linux-read-only from yesterday is what I'm using. Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC (Was: Re: CoreAVC + xineliboutput)
Hello, one more "stupid" question : does it works also for x86_64 ? I wanted to try it, but if fails at patching : patching file src/libw32dll/Makefile.am Hunk #1 FAILED at 13. Hunk #2 FAILED at 33. 2 out of 2 hunks FAILED -- saving rejects to file src/libw32dll/Makefile.am.rej that with coreavc-for-linux/xine/xine.patch against xine-lib-1.2 from today. Thank, -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC (Was: Re: CoreAVC + xineliboutput)
Walery Daniloff skrev: > Hi, >> I'm sorry but the latest mail is not about how to get xineliboutput to >> work but xine. Walery has a patch for xineliboutput and I've tried it >> but I haven't been able to get it to work without segfault. >> >> http://allrussian.info/thread.php?threadid=89361&threadview=0&hilight=&hilightuser=0&page=3 >> > try cvs-version xineliboutput.. I did that. Don't know if I got the patch correctly applied. I had to patch it manually. Will try again later today. Thanks anyway for your efforts :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - xine - CoreAVC (Was: Re: CoreAVC + xineliboutput)
Hi, > I'm sorry but the latest mail is not about how to get xineliboutput to > work but xine. Walery has a patch for xineliboutput and I've tried it > but I haven't been able to get it to work without segfault. > > http://allrussian.info/thread.php?threadid=89361&threadview=0&hilight=&hilightuser=0&page=3 > try cvs-version xineliboutput.. Walery ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
