Testcap & MPEG2-TS
in [Device Drivers]
|
From:
Max Paklin on 20 Aug 2006 16:52 Debug the state transition, not just the stream creation. -- Max. "dos" <dos(a)discussions.microsoft.com> wrote in message news:885A43D5-4F5D-40B1-8C87-DCF8AC51B943(a)microsoft.com... > Hi Max, > Thanks! > In fact, I can use SoftIce and WinDBG to debug driver. But in this case, I > can't find anything wrong during tracing code from initial to opening > stream. > It just gives me an error, "Invalid user buffer!" > > "Max Paklin" wrote: > >> You should use WinDBG. >> Download it from MS site and spend some time learning how to debug. >> Without >> that you aren't going anywhere. >> >> -- Max. >> >> >> >> "dos" <dos(a)discussions.microsoft.com> wrote in message >> news:37E820A2-0447-4D99-AD17-D7737480F53B(a)microsoft.com... >> > Hi Max, >> > >> > I tried DScaler Mpeg2 Video Decoder and Moonlight-Elecard MPEG2 Video >> > Decoder and got the same result. >> > Which debugger I can use to trace this bug? KS Studio? >> > In KS Studio, I tried to connect my capture pin to input pin of Video >> > Capture Pump. But I got some strange information: >> > >> > Attempting to get preferred format for pin 0 ...Succeeded. >> > Preferred Data Format = ... >> > FormatSize = 64 (0x00000040) >> > Flags = 64 (0x00000040) >> > SampleSize = 64 (0x00000040) >> > Reserved = 64 (0x00000040) >> > MajorFormat = {00000040-0000-0000-0000-000000000000} >> > SubFormat = {00000040-0000-0000-0000-000000000000} >> > Specifier = {00000040-0000-0000-0000-000000000000} >> > >> > Why this parameters are different with my KSDATARANGE? When and how did >> > KS >> > Studio get the "preferred format for pin 0"? >> > >> > Thanks! >> > >> > dos >> > >> > "Max Paklin" wrote: >> > >> >> I don't see anything wrong with the code you posted. As I said before, >> >> now >> >> is a good time to use the debugger to see if there is anything that >> >> you >> >> are >> >> failing during state transition. Have you done that? >> >> >> >> If all your calbacks return success then it must be somebody else who >> >> is >> >> unhappy. >> >> Try building partial graph (remove A/V decoders and renderers) and see >> >> what >> >> happens. >> >> >> >> I remember that stupid InterVideo decoders would expire (if you are >> >> using >> >> trial version of InterVideo package) and then quietly stop working by >> >> failing state transition. At the same time their own DVD player app >> >> continued to work fine. You gotta love those guys. >> >> >> >> -- Max. >> >> >> >> >> >> >> >> >> >> "dos" <dos(a)discussions.microsoft.com> wrote in message >> >> news:D85045A6-6CD4-4994-8665-4BD62966CC5F(a)microsoft.com... >> >> > Yes, output A/V pins are separately connected with audio and video >> >> > decoder. >> >> > Here is the code for changing state. It's just TestCap sample code >> >> > without >> >> > any modification: >> >> > /////////////////////////// >> >> > Set State >> >> > switch (pSrb->CommandData.StreamState) >> >> > >> >> > { >> >> > case KSSTATE_STOP: >> >> > >> >> > // >> >> > // The stream class will cancel all outstanding IRPs for us >> >> > // (but only if it is maintaining the queue ie. using Stream >> >> > Class >> >> > synchronization) >> >> > // Since Testcap is not using Stream Class synchronization, >> >> > we >> >> > must >> >> > clear the queue here >> >> > >> >> > VideoQueueCancelAllSRBs (pStrmEx); >> >> > >> >> > DbgLogInfo(("TestCap: STATE Stopped, Stream=%d\n", >> >> > StreamNumber)); >> >> > break; >> >> > >> >> > case KSSTATE_ACQUIRE: >> >> > >> >> > // >> >> > // This is a KS only state, that has no correspondence in >> >> > DirectShow >> >> > // >> >> > DbgLogInfo(("TestCap: STATE Acquire, Stream=%d\n", >> >> > StreamNumber)); >> >> > break; >> >> > >> >> > case KSSTATE_PAUSE: >> >> > >> >> > // >> >> > // On a transition to pause from acquire or stop, start our >> >> > timer >> >> > running. >> >> > // >> >> > >> >> > if (PreviousState == KSSTATE_ACQUIRE || PreviousState == >> >> > KSSTATE_STOP) { >> >> > >> >> > // Zero the frame counters >> >> > pStrmEx->FrameInfo.PictureNumber = 0; >> >> > pStrmEx->FrameInfo.DropCount = 0; >> >> > pStrmEx->FrameInfo.dwFrameFlags = 0; >> >> > >> >> > // Setup the next timer callback(s) >> >> > VideoTimerRoutine(pStrmEx); >> >> > } >> >> > DbgLogInfo(("TestCap: STATE Pause, Stream=%d\n", >> >> > StreamNumber)); >> >> > break; >> >> > >> >> > case KSSTATE_RUN: >> >> > >> >> > // >> >> > // Begin Streaming. >> >> > // >> >> > >> >> > // Reset the discontinuity flag >> >> > >> >> > pStrmEx->fDiscontinuity = FALSE; >> >> > >> >> > // Setting the NextFrame time to zero will cause the value to >> >> > be >> >> > // reset from the stream time >> >> > >> >> > pStrmEx->QST_NextFrame = 0; >> >> > >> >> > DbgLogInfo(("TestCap: STATE Run, Stream=%d\n", >> >> > StreamNumber)); >> >> > break; >> >> > >> >> > } // end switch (pSrb->CommandData.StreamState) >> >> > >> >> > /////////////////////// >> >> > Get State >> >> > pSrb->CommandData.StreamState = pStrmEx->KSState; >> >> > pSrb->ActualBytesTransferred = sizeof (KSSTATE); >> >> > >> >> > // A very odd rule: >> >> > // When transitioning from stop to pause, DShow tries to preroll >> >> > // the graph. Capture sources can't preroll, and indicate this >> >> > // by returning VFW_S_CANT_CUE in user mode. To indicate this >> >> > // condition from drivers, they must return >> >> > STATUS_NO_DATA_DETECTED >> >> > >> >> > if (pStrmEx->KSState == KSSTATE_PAUSE) { >> >> > pSrb->Status = STATUS_NO_DATA_DETECTED; >> >> > } >> >> > >> >> > dos >> >> > >> >> > >> >> > "Max Paklin" wrote: >> >> > >> >> >> What is your graph topology? >> >> >> Output A/V pins of the demux are connected, aren't they? >> >> >> >> >> >> Now it is time to put some breakpoints in your pin handlers and >> >> >> make >> >> >> sure >> >> >> that state transition is handled correctly. >> >> >> >> >> >> -- Max. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> "dos" <dos(a)discussions.microsoft.com> wrote in message >> >> >> news:9EC0A3F7-8DA7-4BFB-8CBA-45B752640A65(a)microsoft |