tw68: Congratulations :-) and possible vsync problem :-(

tw68: Congratulations :-) and possible vsync problem :-(

[Michael]

Hello

I have tested a TW6805 based mini-pci card with the new tw68-v2 driver from 
git (22 January 2010).

First of all: Congratulations! It is really working great.

However, I noticed some frame errors here and then. It is not easy to 
identify what the reason is. It looks a bit like a buffer problem as it 
happens more often, if there is some load on the system.

Here is a simple way how I can reproduce the frame errors:

mplayer -framedrop -fs -vo x11 tv:// -tv 
device=/dev/video0:width=640:height=480:normid=3

With this command, cpu load goes to 100% on my low powered geode system. The 
frame errors are very obvious. It looks like a vsync problem as the wrong 
frames always start somewhere in the middle. There is no horizontal shift 
visible.

Reducing the image size:

mplayer -framedrop -fs -vo x11 tv:// -tv 
device=/dev/video0:width=320:height=240:normid=3

gives a drop in CPU load to 13%. No more frame errors.

Also using hardware accelerated video playback (xv) reduces CPU load to some 
20% and removes the frame errors:

mplayer -framedrop -fs -vo xv tv:// -tv 
device=/dev/video0:width=640:height=480:normid=3

Still, even here, occasionally there are some frame errors, depending on 
what happens on the system. These can be induced as follows. Using this 
program: 

mkfifo /tmp/mp
mplayer -framedrop -fs -vf screenshot -vo xv tv:// -tv 
device=/dev/video0:normid=3 -slave -input file=/tmp/mp </dev/null >/dev/null

When this test prog runs, you can issue commands to mplayer, e.g.

echo pause > /tmp/mp

This pauses mplayer. A second

echo pause > /tmp/mp

starts mplayer again. Here the first frame shows the error.

The same happens if you issue:

echo screenshot 0 > /tmp/mp

This captures a screenshot and saves it into the current pwd. Again, when 
mplayer takes the shot, there comes one error frame (probably also wrong 
vsync).


Btw. using instead a bttv based card all these tests run without frame 
errors.

Does this information help to identify and remove the bug?

Best regards

Michael

Re: tw68: Congratulations :-) and possible vsync problem :-(

[Michael]

Wow things are really moving fast here.

This morning there was a commit in git, which actually eliminates the below 
mentioned problem.

It, however, introduced another small problem. The pictures is wrongly 
cropped. There is the lower part missing (roughly 150-200 lines).

With the last version, I had the same problem, but was able to get the full 
picture with the option "normid=3". This is no longer working.

Otherwise, great work!

Michael


Michael wrote:

> Hello
> 
> I have tested a TW6805 based mini-pci card with the new tw68-v2 driver
> from git (22 January 2010).
> 
> First of all: Congratulations! It is really working great.
> 
> However, I noticed some frame errors here and then. It is not easy to
> identify what the reason is. It looks a bit like a buffer problem as it
> happens more often, if there is some load on the system.
> 
> Here is a simple way how I can reproduce the frame errors:
> 
> mplayer -framedrop -fs -vo x11 tv:// -tv
> device=/dev/video0:width=640:height=480:normid=3
> 
> With this command, cpu load goes to 100% on my low powered geode system.
> The frame errors are very obvious. It looks like a vsync problem as the
> wrong frames always start somewhere in the middle. There is no horizontal
> shift visible.
> 
> Reducing the image size:
> 
> mplayer -framedrop -fs -vo x11 tv:// -tv
> device=/dev/video0:width=320:height=240:normid=3
> 
> gives a drop in CPU load to 13%. No more frame errors.
> 
> Also using hardware accelerated video playback (xv) reduces CPU load to
> some 20% and removes the frame errors:
> 
> mplayer -framedrop -fs -vo xv tv:// -tv
> device=/dev/video0:width=640:height=480:normid=3
> 
> Still, even here, occasionally there are some frame errors, depending on
> what happens on the system. These can be induced as follows. Using this
> program:
> 
> mkfifo /tmp/mp
> mplayer -framedrop -fs -vf screenshot -vo xv tv:// -tv
> device=/dev/video0:normid=3 -slave -input file=/tmp/mp </dev/null
> >/dev/null
> 
> When this test prog runs, you can issue commands to mplayer, e.g.
> 
> echo pause > /tmp/mp
> 
> This pauses mplayer. A second
> 
> echo pause > /tmp/mp
> 
> starts mplayer again. Here the first frame shows the error.
> 
> The same happens if you issue:
> 
> echo screenshot 0 > /tmp/mp
> 
> This captures a screenshot and saves it into the current pwd. Again, when
> mplayer takes the shot, there comes one error frame (probably also wrong
> vsync).
> 
> 
> Btw. using instead a bttv based card all these tests run without frame
> errors.
> 
> Does this information help to identify and remove the bug?
> 
> Best regards
> 
> Michael

Re: tw68: Congratulations :-) and possible vsync problem :-(

[Michael]

Sorry for spamming this :-)

The problem is not solved. Now that I tested all possible normid settings, 
it became clear that it only occurs if I have the correct cropping.

With the PAL and SECAM settings, I get correct cropping, but the vsync 
problem in case of high cpu load. With NTSC settings I get wrong cropping 
(missing bottom lines), but no vsync problems.

If I switch my video cam from PAL to NTSC output, I also get vsync problems 
with NTSC normids.

It seems that the driver misses the vsync somehow if it went down correctly 
till the last horizontal line and if there is high CPU load.

Michael

Michael wrote:

> Wow things are really moving fast here.
> 
> This morning there was a commit in git, which actually eliminates the
> below mentioned problem.
> 
> It, however, introduced another small problem. The pictures is wrongly
> cropped. There is the lower part missing (roughly 150-200 lines).
> 
> With the last version, I had the same problem, but was able to get the
> full picture with the option "normid=3". This is no longer working.
> 
> Otherwise, great work!
> 
> Michael
> 
> 
> Michael wrote:
> 
>> Hello
>> 
>> I have tested a TW6805 based mini-pci card with the new tw68-v2 driver
>> from git (22 January 2010).
>> 
>> First of all: Congratulations! It is really working great.
>> 
>> However, I noticed some frame errors here and then. It is not easy to
>> identify what the reason is. It looks a bit like a buffer problem as it
>> happens more often, if there is some load on the system.
>> 
>> Here is a simple way how I can reproduce the frame errors:
>> 
>> mplayer -framedrop -fs -vo x11 tv:// -tv
>> device=/dev/video0:width=640:height=480:normid=3
>> 
>> With this command, cpu load goes to 100% on my low powered geode system.
>> The frame errors are very obvious. It looks like a vsync problem as the
>> wrong frames always start somewhere in the middle. There is no horizontal
>> shift visible.
>> 
>> Reducing the image size:
>> 
>> mplayer -framedrop -fs -vo x11 tv:// -tv
>> device=/dev/video0:width=320:height=240:normid=3
>> 
>> gives a drop in CPU load to 13%. No more frame errors.
>> 
>> Also using hardware accelerated video playback (xv) reduces CPU load to
>> some 20% and removes the frame errors:
>> 
>> mplayer -framedrop -fs -vo xv tv:// -tv
>> device=/dev/video0:width=640:height=480:normid=3
>> 
>> Still, even here, occasionally there are some frame errors, depending on
>> what happens on the system. These can be induced as follows. Using this
>> program:
>> 
>> mkfifo /tmp/mp
>> mplayer -framedrop -fs -vf screenshot -vo xv tv:// -tv
>> device=/dev/video0:normid=3 -slave -input file=/tmp/mp </dev/null
>> >/dev/null
>> 
>> When this test prog runs, you can issue commands to mplayer, e.g.
>> 
>> echo pause > /tmp/mp
>> 
>> This pauses mplayer. A second
>> 
>> echo pause > /tmp/mp
>> 
>> starts mplayer again. Here the first frame shows the error.
>> 
>> The same happens if you issue:
>> 
>> echo screenshot 0 > /tmp/mp
>> 
>> This captures a screenshot and saves it into the current pwd. Again, when
>> mplayer takes the shot, there comes one error frame (probably also wrong
>> vsync).
>> 
>> 
>> Btw. using instead a bttv based card all these tests run without frame
>> errors.
>> 
>> Does this information help to identify and remove the bug?
>> 
>> Best regards
>> 
>> Michael

Re: tw68: Congratulations :-) and possible vsync problem :-(

[Michael]

Here is some more info:

I loaded the module with option core_debug=15.

When I run with low CPU load (vx driver), I get the following log lines:

[10261.346087] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10261.346087] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] first active
[10261.346087] tw6804[0]: tw68_buffer_queue: queuing buffer cc91b260
[10261.346087] tw6804[0]: tw68_buffer_queue: [cc91b260/1] appended to active
[10261.393852] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=293
[10261.397831] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10261.397831] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] appended to active
[10261.433849] tw6804[0]: tw68_wakeup: [cc91b260/1] field_count=294
[10261.437823] tw6804[0]: tw68_buffer_queue: queuing buffer cc91b260
[10261.437823] tw6804[0]: tw68_buffer_queue: [cc91b260/1] appended to active
[10261.473839] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=295
[10261.477415] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10261.477415] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] appended to active
[10261.511590] tw6804[0]: tw68_wakeup: [cc91b260/1] field_count=296
[10261.518421] tw6804[0]: tw68_buffer_queue: queuing buffer cc91b260
[10261.518421] tw6804[0]: tw68_buffer_queue: [cc91b260/1] appended to active
[10261.552610] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=297
[10261.577131] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10261.577158] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] appended to active
[10261.593610] tw6804[0]: tw68_wakeup: [cc91b260/1] field_count=298
[10261.599735] tw6804[0]: tw68_buffer_queue: queuing buffer cc91b260
[10261.599759] tw6804[0]: tw68_buffer_queue: [cc91b260/1] appended to active
[10261.633812] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=299
[10261.637784] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10261.637784] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] appended to active
[10261.673804] tw6804[0]: tw68_wakeup: [cc91b260/1] field_count=300
[10261.677776] tw6804[0]: tw68_buffer_queue: queuing buffer cc91b260
[10261.677776] tw6804[0]: tw68_buffer_queue: [cc91b260/1] appended to active

Very regular, just one "first active".

With high CPU load (x11 driver) I get:

[10066.494080] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10066.494080] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] first active
[10066.548758] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb600
[10066.548758] tw6804[0]: tw68_buffer_queue: [cd7bb600/1] appended to active
[10066.552054] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=173
[10066.589772] tw6804[0]: tw68_wakeup: [cd7bb600/1] field_count=174
[10066.596604] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10066.596604] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] first active
[10066.630773] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=175
[10066.658108] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb600
[10066.658108] tw6804[0]: tw68_buffer_queue: [cd7bb600/1] first active
[10066.712033] tw6804[0]: tw68_wakeup: [cd7bb600/1] field_count=176
[10066.726463] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10066.726463] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] first active
[10066.752027] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=177
[10066.781142] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb600
[10066.781142] tw6804[0]: tw68_buffer_queue: [cd7bb600/1] first active
[10066.832009] tw6804[0]: tw68_wakeup: [cd7bb600/1] field_count=178
[10066.835821] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10066.835821] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] first active
[10066.869996] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=179
[10066.890493] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb600
[10066.890493] tw6804[0]: tw68_buffer_queue: [cd7bb600/1] first active
[10066.911006] tw6804[0]: tw68_wakeup: [cd7bb600/1] field_count=180
[10066.945177] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10066.945177] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] first active
[10066.991979] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=181
[10066.999859] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb600
[10066.999859] tw6804[0]: tw68_buffer_queue: [cd7bb600/1] first active
[10067.031973] tw6804[0]: tw68_wakeup: [cd7bb600/1] field_count=182
[10067.061365] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0
[10067.061365] tw6804[0]: tw68_buffer_queue: [cd7bb3c0/0] first active
[10067.109211] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb600
[10067.109211] tw6804[0]: tw68_buffer_queue: [cd7bb600/1] appended to active
[10067.109211] tw6804[0]: tw68_wakeup: [cd7bb3c0/0] field_count=183
[10067.150229] tw6804[0]: tw68_wakeup: [cd7bb600/1] field_count=184
[10067.170720] tw6804[0]: tw68_buffer_queue: queuing buffer cd7bb3c0

Strongly irregular, many "first active", sometimes two "field counts" after 
each other.

Hope this helps.

Michael

Re: tw68: Congratulations :-) and possible vsync problem :-(

[William M. Brack]

This driver has not yet been submitted for review by members of the
linux-media list (although it most certainly will be in the future). I
greatly appreciate this report (and would also welcome any others),
but I don't want to spend much time here responding to it. Reports
sent to me by direct email are also welcome.

The problem is basically caused by an overload of your CPU - it
doesn't have enough power to handle the processing of the video stream
the application has asked for. I'm able to run all of your examples on
my development machine (an Intel i7a with 4gb) with no problems at
all. That said, it is also true that the driver should do a better job
of assuring the buffer stream being sent to the application is correct
and consistent. I can reproduce the problem on relatively slow systems
(an AMD Duron and a Pentium4, each with 256mb), and will try to
improve the driver's behaviour.

Thanks for the report!

Bill
TW68 developer

Michael wrote:
> Sorry for spamming this :-)
>
> The problem is not solved. Now that I tested all possible normid
> settings,
> it became clear that it only occurs if I have the correct cropping.
>
> With the PAL and SECAM settings, I get correct cropping, but the vsync
> problem in case of high cpu load. With NTSC settings I get wrong
> cropping
> (missing bottom lines), but no vsync problems.
>
> If I switch my video cam from PAL to NTSC output, I also get vsync
> problems
> with NTSC normids.
>
> It seems that the driver misses the vsync somehow if it went down
> correctly
> till the last horizontal line and if there is high CPU load.
>
> Michael
>
> Michael wrote:
>
>> Wow things are really moving fast here.
>>
>> This morning there was a commit in git, which actually eliminates
>> the
>> below mentioned problem.
>>
>> It, however, introduced another small problem. The pictures is
>> wrongly
>> cropped. There is the lower part missing (roughly 150-200 lines).
>>
>> With the last version, I had the same problem, but was able to get
>> the
>> full picture with the option "normid=3". This is no longer working.
>>
>> Otherwise, great work!
>>
>> Michael
>>
>>
>> Michael wrote:
>>
>>> Hello
>>>
>>> I have tested a TW6805 based mini-pci card with the new tw68-v2
>>> driver
>>> from git (22 January 2010).
>>>
>>> First of all: Congratulations! It is really working great.
>>>
>>> However, I noticed some frame errors here and then. It is not easy
>>> to
>>> identify what the reason is. It looks a bit like a buffer problem
>>> as it
>>> happens more often, if there is some load on the system.
>>>
>>> Here is a simple way how I can reproduce the frame errors:
>>>
>>> mplayer -framedrop -fs -vo x11 tv:// -tv
>>> device=/dev/video0:width=640:height=480:normid=3
>>>
>>> With this command, cpu load goes to 100% on my low powered geode
>>> system.
>>> The frame errors are very obvious. It looks like a vsync problem as
>>> the
>>> wrong frames always start somewhere in the middle. There is no
>>> horizontal
>>> shift visible.
>>>
>>> Reducing the image size:
>>>
>>> mplayer -framedrop -fs -vo x11 tv:// -tv
>>> device=/dev/video0:width=320:height=240:normid=3
>>>
>>> gives a drop in CPU load to 13%. No more frame errors.
>>>
>>> Also using hardware accelerated video playback (xv) reduces CPU
>>> load to
>>> some 20% and removes the frame errors:
>>>
>>> mplayer -framedrop -fs -vo xv tv:// -tv
>>> device=/dev/video0:width=640:height=480:normid=3
>>>
>>> Still, even here, occasionally there are some frame errors,
>>> depending on
>>> what happens on the system. These can be induced as follows. Using
>>> this
>>> program:
>>>
>>> mkfifo /tmp/mp
>>> mplayer -framedrop -fs -vf screenshot -vo xv tv:// -tv
>>> device=/dev/video0:normid=3 -slave -input file=/tmp/mp </dev/null
>>> >/dev/null
>>>
>>> When this test prog runs, you can issue commands to mplayer, e.g.
>>>
>>> echo pause > /tmp/mp
>>>
>>> This pauses mplayer. A second
>>>
>>> echo pause > /tmp/mp
>>>
>>> starts mplayer again. Here the first frame shows the error.
>>>
>>> The same happens if you issue:
>>>
>>> echo screenshot 0 > /tmp/mp
>>>
>>> This captures a screenshot and saves it into the current pwd.
>>> Again, when
>>> mplayer takes the shot, there comes one error frame (probably also
>>> wrong
>>> vsync).
>>>
>>>
>>> Btw. using instead a bttv based card all these tests run without
>>> frame
>>> errors.
>>>
>>> Does this information help to identify and remove the bug?
>>>
>>> Best regards
>>>
>>> Michael
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>