Wolfgang Rohdewald wrote:
> char *s;
> asprintf(&s,"%ld-%.9s",random(),artist.original());
>
> segfaults only if illegal utf8 chars appear in artist.original()
>
> asprintf returns -1, so s is nothing that could be freed,
> and this gives a nice backtrace:
So its basically just free'
On Monday 11 February 2008, Luca Olivetti wrote:
> En/na Kartsa ha escrit:
> > I can read germany but I do not understand it :). But understood that I
> > could use that script to test acpi. Well this did not work. I did check
> > that the time was actually written in /proc/acpi/alarm. Still not w
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).
>
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.lin
En/na Kartsa ha escrit:
> I can read germany but I do not understand it :). But understood that I
> could use that script to test acpi. Well this did not work. I did check
> that the time was actually written in /proc/acpi/alarm. Still not waking up.
IIRC, acpi wakeup wouldn't work here if I di
[EMAIL PROTECTED](Udo Richter) 05.02.08 22:51
>Theunis Potgieter wrote:
>> udev rules
>Any good rules that could be used as a starting point?
>I thought of doing this with udev, but there are some
>obstacles for that:
>First, a DVB device has several device files, not just one.
vdr:~# ll /d
Udo Richter wrote:
> Wolfgang Rohdewald wrote:
> > char *s;
> > asprintf(&s,"%ld-%.9s",random(),artist.original());
> >
> > segfaults only if illegal utf8 chars appear in artist.original()
> >
> > asprintf returns -1, so s is nothing that could be freed,
> > and this gives a nice backtrac
Rainer Zocholl kirjoitti:
> [EMAIL PROTECTED](Kartsa) 10.02.08 10:37
>
>> What different wakeupmethods are there? I've built a few vdr boxes and
>> I've been forced to use different motherboards and they do not all
>> work the same. I've used nvram-wakeup on some and acpi on others when
>> nvra
Petri Helin <[EMAIL PROTECTED]> wrote:
> Thanks for informing about the update. Seems to work now with recordings
> with dvb-subtitles from the Finnish broadcaster, YLE, too.
>
> Regarding the renaming of the audio files, I made a few changes in the
> Project-X in order to fix that:
>
> --- parse
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 fo
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,
> +
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:
>>
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
I demand that Ludwig Nussel may or may not have written...
> Darren Salt wrote:
>> I demand that Ludwig Nussel may or may not have written...
>> [snip]
>>> asprintf needs to check for multibyte characters to not cut them in
>>> the middle and produce invalid output.
>> No - it's encoding-neutral.
OK, I spent a bit of time looking at this today as there doesn't seem
to be much movement on FFMPEG and H264 at the moment.
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(&bi
Darren Salt wrote:
> I demand that Ludwig Nussel may or may not have written...
>
> [snip]
> > asprintf needs to check for multibyte characters to not cut them in
> > the middle and produce invalid output.
>
> No - it's encoding-neutral. What you want is your own version which does that
Try the
I demand that Ludwig Nussel may or may not have written...
[snip]
> asprintf needs to check for multibyte characters to not cut them in
> the middle and produce invalid output.
No - it's encoding-neutral. What you want is your own version which does that
(but if you still think that that should b
> 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 disc
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
On Montag, 11. Februar 2008, Udo Richter wrote:
> Well, that leads to the question whether s is unchanged in case of a -1
> error return, and whether this would work:
I can confirm that. The man page however says the value will be undefined.
My current understanding is:
1. dont forget to call s
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 t
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;
>
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.li
Rainer Zocholl wrote:
> Too, long time ago "one time timers" were not deleted automatically.
> That has the advantage that if i found that "one time" worth to be
> recorded again, it was easy by editing that old "used" one time timer.
> Manually deleting the superflous "used" timers was much easie
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 H26
On Feb 10, 2008 3:20 PM, Stefan Wagner <[EMAIL PROTECTED]> wrote:
> "Petri Helin" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
> news:[EMAIL PROTECTED]
> > Has there been any progress regarding this issue? It looks like ProjectX
> > will fail in case there are subtitles in a VDR recording made with
Il giorno dom, 10/02/2008 alle 18.32 +0100, Stefan Wagner ha scritto:
> >> ProjectX 0.90.4.b22 works with vdr 1.5.x recordings.
> >
> > Just tried the last cvs, it still fails to process subtitles, getting
> > stuck in a loop with message "suppic unknown cmd: 44" as the previous
> > version I te
Wolfgang Rohdewald wrote:
> My problem code:
>
> mgDb::Build_cddbid(const mgSQLString& artist) const
> {
> char *s;
> asprintf(&s,"%ld-%.9s",random(),artist.original());
>
> segfaults only if illegal utf8 chars appear in artist.original()
>
> asprintf returns -1, so s is nothing that
Hello,
I am trying to configure a new vdr streaming client.
As 1.5.14 needs the multiproto driver, I did download it from Mercurial.
When I compile I get an error about "stk-webcam"
I found that one of the solutions was to disable this webcam in make
menuconfig.
My problem is that I can't f
Wolfgang Rohdewald wrote:
> since asprintf leads to segfaults if feeded with incorrect UTF-8 characters,
It's not asprintf that segfaults but the call to free uninitialized
memory afterwards.
> I wanted to write a wrapper function which would then check the return value
> of asprintf. However I h
Klaus Schmidinger wrote:
Please run the tests with the original, *unpatched* version 1.5.14
(or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to
be part of version 1.6.0) and use as few plugins as possible (best would
be without *any* plugins).
Here we are...
Clean vdr-1.5.13 wi
Davide Cavalca wrote:
> Il giorno dom, 10/02/2008 alle 18.32 +0100, Stefan Wagner ha scritto:
ProjectX 0.90.4.b22 works with vdr 1.5.x recordings.
>>> Just tried the last cvs, it still fails to process subtitles, getting
>>> stuck in a loop with message "suppic unknown cmd: 44" as the previou
Udo Richter wrote:
> Wolfgang Rohdewald wrote:
> > since asprintf leads to segfaults if feeded with incorrect UTF-8 characters,
> > I wanted to write a wrapper function which would then check the return value
> > of asprintf.
>
> I never understood what the problem is with utf8 and asprintf, sinc
Klaus Schmidinger wrote:
Maybe you could activate the debug outputs in ci.c to see whether VDR
actually sends the CA_PMT data to the CAM.
Sorry for delay, busy weekend...
I enabled debug outputs in ci.c and made 2 attempts:
-crypted channel recording (ok files)
-FTA recording and try to switc
On Montag, 11. Februar 2008, Ludwig Nussel wrote:
> As you can see it doesn't segfault on asprintf but on free().
I did see that. I did not say it segfaults but it does lead
to segfaults.
> if(asprintf(...) >= 0)
> {
> printf(...);
> free(...);
> }
I do not want to change dozens of
On 02/11/08 10:39, Arthur Konovalov wrote:
> Klaus Schmidinger wrote:
>>
>> Maybe you could activate the debug outputs in ci.c to see whether VDR
>> actually sends the CA_PMT data to the CAM.
>
> Sorry for delay, busy weekend...
>
> I enabled debug outputs in ci.c and made 2 attempts:
> -crypted
Kartsa schrieb:
> Rainer Zocholl kirjoitti:
>> [EMAIL PROTECTED](Kartsa) 10.02.08 10:37
>>
>>> What different wakeupmethods are there? I've built a few vdr boxes and
>>> I've been forced to use different motherboards and they do not all
>>> work the same. I've used nvram-wakeup on some and acpi
37 matches
Mail list logo
