[mpeg2] Re: Only _one_ TS recording possible

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

mocm@metzlerbros.de wrote:
> 
> Klaus Schmidinger writes:
>  > After the "One line disturbance in picture" has been solved by using
>  > a 2.4.18 kernel I'm now trying to solve the (still persisting) problem
>  > that only _one_ TS recording is possible - every following TS recording
>  > shows heavy artefacts, and at some point there's no recording possible
>  > at all any more.
>  >
>  > Here's a recipe how this can be reproduced:
>  >
>  >  insmod kfir.o vidinput=0 vidrate=3000000 streamtype=4
>  >
>  >  cat /dev/video > file1.ts    (Ctrl-C after some 10 seconds)
>  >
>  >  cat /dev/video > file2.ts    (Ctrl-C after some 10 seconds)
>  >
>  >  rmmod kfir
>  >
>  >  insmod kfir.o vidinput=0 vidrate=3000000 streamtype=4
>  >
>  >  cat /dev/video > file3.ts    (Ctrl-C after some 10 seconds)
>  >
>  > After this you have three TS files. Convert them to any format you
>  > can replay and watch the results. 'file1' is ok, while 'file2' shows
>  > artefacts. 'file3' is ok again, as is every first recording after
>  > the driver has been freshly loaded.
>  >
>  > If I do the same with the default setting for 'streamtype' (which
>  > produces a Program Stream), every recording is ok. So I would assume
>  > that something doesn't get set or reset correctly in case of TS.
>  >
> 
> I guess something isn't reset properly. AFAIK, There hasn't been much testing
> with TS on kfir. We don't have a kfir installed right now, so I can't
> test it myself, but try looking at the init routines in the driver and
> see what is done in the the open and close/release functions. There
> probably is something set for PS on default in the later.
> 
> Marcus

Well, from what I can see in kfir.c there's really not that much difference between
the PS and TS cases, especially when looking at the open and close functions.

One difference is that there are different micro codes loaded in KfirLoadMicro().
But then again that's only done once at the very beginning, when loading kfir.o.
So I would assume the micro code should be ok.

The only other place where VT_KFIR_TRANSPORT is explicitly checked is in kfir_irq():

                                        if (kfir->Params.StreamType ==
                                             VT_KFIR_TRANSPORT) {
                                                kfir->recording=0;
                                                break;
                                        }

Simply commenting out this sequence caused buffer overflows, but maybe there's
something "fishy" about this? It appears to have to do with ending a recording
session, so maybe this is an area for further tests? Can you suggest something
I should try?

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________