* tw68: Congratulations :-) and possible vsync problem :-( @ 2010-02-16 9:51 Michael 2010-02-16 10:22 ` Michael 0 siblings, 1 reply; 5+ messages in thread From: Michael @ 2010-02-16 9:51 UTC (permalink / raw) To: linux-media 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tw68: Congratulations :-) and possible vsync problem :-( 2010-02-16 9:51 tw68: Congratulations :-) and possible vsync problem :-( Michael @ 2010-02-16 10:22 ` Michael 2010-02-16 10:58 ` Michael 0 siblings, 1 reply; 5+ messages in thread From: Michael @ 2010-02-16 10:22 UTC (permalink / raw) To: linux-media 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tw68: Congratulations :-) and possible vsync problem :-( 2010-02-16 10:22 ` Michael @ 2010-02-16 10:58 ` Michael 2010-02-16 12:27 ` Michael 2010-02-17 16:37 ` William M. Brack 0 siblings, 2 replies; 5+ messages in thread From: Michael @ 2010-02-16 10:58 UTC (permalink / raw) To: linux-media 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tw68: Congratulations :-) and possible vsync problem :-( 2010-02-16 10:58 ` Michael @ 2010-02-16 12:27 ` Michael 2010-02-17 16:37 ` William M. Brack 1 sibling, 0 replies; 5+ messages in thread From: Michael @ 2010-02-16 12:27 UTC (permalink / raw) To: linux-media 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tw68: Congratulations :-) and possible vsync problem :-( 2010-02-16 10:58 ` Michael 2010-02-16 12:27 ` Michael @ 2010-02-17 16:37 ` William M. Brack 1 sibling, 0 replies; 5+ messages in thread From: William M. Brack @ 2010-02-17 16:37 UTC (permalink / raw) To: linux-media 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-02-17 16:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-02-16 9:51 tw68: Congratulations :-) and possible vsync problem :-( Michael 2010-02-16 10:22 ` Michael 2010-02-16 10:58 ` Michael 2010-02-16 12:27 ` Michael 2010-02-17 16:37 ` William M. Brack
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox