Beiträge von rvdb

Also put a { before the mutexlock and a } after the Lock, to free the mutex.
I forgot to tell you this, sorry

Hi, some time ago I looked at this propblem. Didn't fully understand it, but according to my documentation from then I believe:

The main thread is busy detaching receivers. ( void cDevice::Detach(cReceiver *Receiver in device.c)
holding mutexreceiver and doing a Lock()

Another thread is doing "Distribute the packet to all attached receivers" (device.c 1605)
If you put a delay after the lock at line 1606 you will see the deadlock very fast.

At this time I am not shure if this is the problem, but maybe worth investigating.

As a bypass I put a "cMutexLock MutexLock(&mutexReceiver);" before the Lock() in line 1605, this problem seems to be gone,
but now I somethimes have lock problems with the streamdev plugin (but not very often) , so this is not a real solution.

Greetings Rene

johns vai-api from sep 30 + patch on braswell

on ZDF HD I get only lines as follows :

13 upto 26 -D's per line ending with "error not reached"

vbuf is staying at (very low about 0-3) +1 v-buf

Greetings Rene

Zitat von rofafor

..and those horizontal bars exists only with softhddevice? Have you tried other vaapi mediaplayers with vpp enabled on your system? I still think this is due to a incompatible library version or buggy driver.

Not that easy: kodi and mpv use vaapi-vpp, but only for deinterlacing, not the other filters such as the color_balance filters.
Both (compiled) programs work perfect.

The only user of other vpp filters I could found was
github.com/gbeauchesne/gstreamer-vaapi
after compiling this, I saw the horizontal bars !
and only if setting any vaapipostproc filter.

So you are right, it must be somethng in my system.

Greetings Rene

Zitat von xyzzy

N.B. I found something else:
As soon as I get into the menu : setup : plugins :softhddevice , and out of it again
(without doing something), the picture is distorted (like over saturated) but very bad.

Well, this was a user error (sort of).
If I go into the menu and directly out of it, the values for brightness, contrast etc. are set to
the values that are (hiden) in the menu.
The values for contrast and saturation where on max.

N.B. I believe the defaults for these are coming from

static int ConfigVideoContrast = 1000; ///< config video contrast
static int ConfigVideoSaturation = 1000; ///< config video saturation

in softhddevice.cpp.

It would be better if they where 10.

greetings Rene

>.and those horizontal bars exists only with softhddevice? Have you tried other vaapi mediaplayers with vpp enabled on your system? I still think this is due to a incompatible library version or buggy driver.

Well I wanted to test with xbmc, but I cannot seem to find the vpp settings (kodi-bin:amd64/sid 15.1+dfsg1-3)
That will take some time to figure out.

N.B. I found something else:
As soon as I get into the menu : setup : plugins :softhddevice , and out of it again
(without doing something), the picture is distorted (like over saturated) but very bad.

rofafor:

I tested the new pesintta git
both va-api and va-api-glx are working, no more segfaults.
I can use the menu and all settings seem to work.
The color_balance filters are working.
I couldn't see any difference in the tone settings, but that is probably because
it is difficult to see with the horizontal bars flickering.

Yes, I still have the horizontal bars

Rene

> Did this happen on va-api or va-api-glx only? I've commited a fix for the latter, but the former one sounds a like a compiler bug.

In va-api when expanding video under 576i you could see strange characters, when on 576i pressing right arrow a segment fault
was created.
va-api-glx didn;t do anything at all.
I will have a look at the status after you're commits, but that will be tomorrow.

Rene

rofafor:

I already did that,

no matter what filter is set, as soon as
decoder->filters[decoder->filter_n++] = filter_buf_id;
is hit, no matter what the contents of cbal_param the problem exist.

NB there is also a smal problem with the tone filter, in VaapiSetupParameterBufferProcessing
cap_n == 0 so no buffer is created
And also the & is forgotten in vaQueryVideoProcFilterCaps

Hmm, I believe line 4166
now: VAProcFilterColorBalance, colorbalance_caps,

should be : VAProcFilterColorBalance, &colorbalance_caps,

This is not a solution for the bars, but it does fix the segfault when entering the menu
video - 576i etc. (and also -v va-api-glx)
(there are probably more)

video/vaapi: enabling color balance filters
video/vaapi: Supported color balance filter count: 4
Hue (-180.00 - 180.00 ++ 1.00 = 0.00) (pos = 2)
Saturation (0.00 - 10.00 ++ 0.10 = 1.00) (pos = 2)
Brightness (-100.00 - 100.00 ++ 1.00 = 0.00) (pos = 2)
Contrast (0.00 - 10.00 ++ 0.10 = 1.00) (pos = 2)
video/vaapi: skin tone enhancement supported
Wrong number of capabilities (0) for filter 0x00000005

Yes, pesintta

Well, some more testing:

if in video.c line 4122 I put a break just after
"case VAProcFilterColorBalance:"

Thus disabeling the colorbalance filters, the bars are gone !

The N3700 should be perfect for a HTPC, but for now the
N24 ticker is still better on XBMC

ddd

kernel 4.3.0-040300rc1-generic.

Hi,

New asrock n3700M, I installed debian sid, pesintta softhddevice.
Same horizontal bars on all resolutions.

Somebody already found a resolution?

greetings Rene

Hmmm,

I would like fmode =5 to mean:

6 demods on input 0 (SRC)
2 demods on input 1 (for a normal lnb)

Is that a possible (future) configuration ?

Greetings Rene

Zitat von jack-itb

Es sind wohl doch die Buffer.
Wenn ich die Buffer am Anfang von AlsaSetup neu initialisiere klappts mit 5.0:

Hi, just to let you know, I have exactly the same problem.
Reinit the buffer is also a working bypass.

Greetings

Getting you're accuweather location (as indicated above) doesn't seem to work anymore.

But you can also use

http://forecastfox.accuweather…_city.asp?location=Berlin

in a browser to get a location.

Greetings

@reel_schorsch:

I was reading bytes, now I am reading uint_32, and I sometimes read
0xc2240913.

Greetings XYZZY
N.B. remember? this is the mini-pci to PCI with a fried transitor.

About my memory problems (see above):

when I am playing a live vdr over the hde, and at the same time
read the pci memory (with a small program doing
a mmap from /dev/mem at 0xE301A000 in a loop)
I get corrupted bytes
the values are always the same 13 09 24 c2 depending on the position
of the byte in the 4-byte integer.
Not all 4 bytes are always affected at the same time.

Is this a (timing) problem with the pci-bus ?

Anyone got a clue?