I am having a problem with corrupt TS streams when capturing with the BDA driver.
At first I though it was the way the Mux filters were muxing the streams that the MS Demux outputs so I added some test code to dump the full TS as well as the demuxed and then remuxed file.
What I have found is that 1 in about 15 captures fails, this failure is jittery sounds and most of the time no video but some times highly pixulated video or parts of different frames all merged together.
I then did some tests with just dumping the full TS alone to disk and I still get about 1 in 15 failures.
When you have a look at the full TS all the data looks like it is there ie it is the same size as a 1 min long working capture but nothing can demultiplex it correctly. Normally I can play back full TS captures using Moonlights Elecard player but these broken TS streams can not be played back.
When you try to run these broken full TS captues through ProjectX you get lots of messages of the following:
--> PID 0x207 -> packet 11868 @ pos. 5624960 out of sequence (8/3) (shifting..)
--> PID 0x207 -> packet 11874 @ pos. 5626088 out of sequence (4/10) (shifting..)
--> PID 0x207 -> packet 12029 @ pos. 5655228 out of sequence (3/13) (shifting..)
--> PID 0x207 -> packet 12035 @ pos. 5656356 out of sequence (15/4) (shifting..)
--> PID 0x207 -> packet 12350 @ pos. 5715576 out of sequence (8/3) (shifting..)
And eventually a very small (smaller than it should be) video file than can not be played.
As I have said this only happens randomly and from what I can tell there is no set of circumstances that can trigger it, I have failures on Channel Nine, Ten, ABC and SBS so it looks like it is not just one station.
I am fast running out of ideas.
Full Version: BDA capture problem
DVB Owners Discussion Forum - dvbowners.com > Technical & Development Forums > BDA Driver Development
I've never had a problem demuxing a TS from Webscheduler or BDA DW.
I get the same thing as null_pointer. It seems to be entirly random and averages out at one in even 10 or so for me.
The only non-random thing i have noticed is that for testing purposes i had a weekly recording set for ch 10 on sunday mornings at 6:30 for 5 minutes and for about 5 weeks every one of them resulted in a corrupted stream.
My best guess was that it was something to do with the signal strength at that particular time of the morning, but about a week ago I altered that schedule to record everyday at 6:30 for 5 minutes and they have all worked fine.
The only non-random thing i have noticed is that for testing purposes i had a weekly recording set for ch 10 on sunday mornings at 6:30 for 5 minutes and for about 5 weeks every one of them resulted in a corrupted stream.
My best guess was that it was something to do with the signal strength at that particular time of the morning, but about a week ago I altered that schedule to record everyday at 6:30 for 5 minutes and they have all worked fine.
OK, I've added KSPIN_FLAG_ENFORCE_FIFO to the flags on the capture output pin. See http://msdn.microsoft.com/library/en-us/st...4a75833.xml.asp. I don't know if this will be of any use and I hope it doesn't add any problems. I thought I'd give it a go seeing as "out of sequence" appears in your output above.
There have been a few small changes in this version mostly to stop paging of the driver code while streaming (any page fault will cause hiccups while waiting for the O/S to get virtual memory pages back from disk). Oh, it will also try to tune the last frequency when transitioning from D3 to D0.
Version 1.5.3.0 test_drivers.zip
Finally, quick vote, if the hardware fails to lock a channel on a tune request should I resubmit the request to try again or should I leave it up to the application software to make that decision?
Spectrum
There have been a few small changes in this version mostly to stop paging of the driver code while streaming (any page fault will cause hiccups while waiting for the O/S to get virtual memory pages back from disk). Oh, it will also try to tune the last frequency when transitioning from D3 to D0.
Version 1.5.3.0 test_drivers.zip
Finally, quick vote, if the hardware fails to lock a channel on a tune request should I resubmit the request to try again or should I leave it up to the application software to make that decision?
Spectrum
QUOTE (Spectrum @ Jul 11 2004, 11:22 AM)
OK, I've added KSPIN_FLAG_ENFORCE_FIFO to the flags on the capture output pin. See http://msdn.microsoft.com/library/en-us/st...4a75833.xml.asp. I don't know if this will be of any use and I hope it doesn't add any problems. I thought I'd give it a go seeing as "out of sequence" appears in your output above.
There have been a few small changes in this version mostly to stop paging of the driver code while streaming (any page fault will cause hiccups while waiting for the O/S to get virtual memory pages back from disk). Oh, it will also try to tune the last frequency when transitioning from D3 to D0.
Version 1.5.3.0 test_drivers.zip
Finally, quick vote, if the hardware fails to lock a channel on a tune request should I resubmit the request to try again or should I leave it up to the application software to make that decision?
Spectrum
There have been a few small changes in this version mostly to stop paging of the driver code while streaming (any page fault will cause hiccups while waiting for the O/S to get virtual memory pages back from disk). Oh, it will also try to tune the last frequency when transitioning from D3 to D0.
Version 1.5.3.0 test_drivers.zip
Finally, quick vote, if the hardware fails to lock a channel on a tune request should I resubmit the request to try again or should I leave it up to the application software to make that decision?
Spectrum
QUOTE (Spectrum)
OK, I've added KSPIN_FLAG_ENFORCE_FIFO to the flags on the capture output pin. See http://msdn.microsoft.com/library/en-us/st...4a75833.xml.asp. I don't know if this will be of any use and I hope it doesn't add any problems. I thought I'd give it a go seeing as "out of sequence" appears in your output above.
Cool, I will test to this afternoon.
QUOTE (Spectrum)
Finally, quick vote, if the hardware fails to lock a channel on a tune request should I resubmit the request to try again or should I leave it up to the application software to make that decision?
I am still not quite sure what is the best way to approach tune
failures, is the best way to detect them from an application point of
view by using the tuner statistics and looking at the Locked call?
At the moment what I am doing in WS is I submitting the tuner request
and then running the graph, I then get the signal stats and check for
LOCKED and if it is false I stop the graph and return an error from
the RunGraph call. This causes the next available card to be tried as
the first card may not be plugged in to an antenna etc.
I also remember from your notes somewhere that you were going to
implement asynchronous tuning so the tuner request call returned
immediately and the tune happened in the background. If this is the case
then it should probably try at least twice or three time to tuner
before giving up.
If the driver is tuning the hardware asynchronous how long does this take, how long should the app wait from submitting the tuner reqiest to checking the LOCKED status?
I have done 50 small captures 1 min long with 1 min between them with the above test driver and two failed in the same way as above.
null,
I also have had this issue u describe on occation (i think i emailed you one of the "glitchy" captures). It has not happened in a little while, nor the 100% java.exe issue, but in saying that its so "irregular" that it could occur tonight. hmmm.
I also have had this issue u describe on occation (i think i emailed you one of the "glitchy" captures). It has not happened in a little while, nor the 100% java.exe issue, but in saying that its so "irregular" that it could occur tonight. hmmm.
Spoonfed, yes when I got your capture I started to look into it a bit more and that is when I found the problem with the corrupt TS captures.
QUOTE (null_pointer)
I also remember from your notes somewhere that you were going to
implement asynchronous tuning so the tuner request call returned
immediately and the tune happened in the background. If this is the case
then it should probably try at least twice or three time to tuner
before giving up.
I've done a quick code mod to retry tuning once if an initial attempt fails - same download, no changes to version numbers.implement asynchronous tuning so the tuner request call returned
immediately and the tune happened in the background. If this is the case
then it should probably try at least twice or three time to tuner
before giving up.
QUOTE (null_pointer)
If the driver is tuning the hardware asynchronous how long does this take, how long should the app wait from submitting the tuner reqiest to checking the LOCKED status?
It takes approx. 500 milliseconds to return from failing to lock a frequency so with the new change to retry on first fail, you should probably wait 1.5 seconds. I have also changed the code (some time ago) to the original setup where signal locked and signal present now return the same value from the hardware - ie. a signal stats request is made to the card and the one signal locked/present value from that is returned.Back to this problem with corrupt captures, is there any Windows software I can download to gauge the quality of a TS?
Also is the whole TS corrupt or only some of the components.
Spectrum
QUOTE (Spectrum)
you should probably wait 1.5 seconds
Cool thanks.
QUOTE (Spectrum)
Back to this problem with corrupt captures, is there any Windows software I can download to gauge the quality of a TS?
I think the following gives an error bit rate etc:
http://www.coolstf.com/tsreader/
Does anyone know of any other TS reader tools?
QUOTE (Spectrum)
Also is the whole TS corrupt or only some of the components.
It looks like the whole stream is corrupt, if you want I have one I can send you on CD or download from my server (download speed would be 128 Kb ADSL)
separate (perhaps) to the corruption issue, my above post just jinxed my system again 
Had the 100% CPU java.exe WS/crash just before.
2sec was captured (seemingly glitch free) and that was it. hmmm very frustrating this one. I wonder if these issues could at all be releated. I have had the 100% usage issue and later check the capture to see it corrupt....ahhh i don't know
Null, i think i mentioned it a little bit ago, is it possible to re-add the feature where if a file exists for a schedule on reboot and the schedule is still valid that a new file (ie file1.mpg) is created and the capture automaticly continue, it was featured sometime ago in old TH versions.
Had the 100% CPU java.exe WS/crash just before.2sec was captured (seemingly glitch free) and that was it. hmmm very frustrating this one. I wonder if these issues could at all be releated. I have had the 100% usage issue and later check the capture to see it corrupt....ahhh i don't know
Null, i think i mentioned it a little bit ago, is it possible to re-add the feature where if a file exists for a schedule on reboot and the schedule is still valid that a new file (ie file1.mpg) is created and the capture automaticly continue, it was featured sometime ago in old TH versions.
At the moment I am concerned with the corruption problem, there is no point having a schedule application that fails randomly, if I can not sort this problem out there is no point adding anything to WS as it will be unusable.
I don't have two cards in my machine at the moment but is it possible to set up two captures on the same channel at the same time.
I'm thinking that if we could get one that is corrupt and one that is not then we can directly compare them to see exactly what is getting misplaced.
I'm thinking that if we could get one that is corrupt and one that is not then we can directly compare them to see exactly what is getting misplaced.
Guys,
RE: BDA WS 2.8.1.0, Capt eng 4.2.1.0, BDA Drv 1.5.2.1
I have completed 49, 1 min SS Captures of Network 10 SD, spaced 1 min apart similar to Null_pointer with the following results:-
1st Capture @ 2134hrs ok.
...........
13th Capture @ 2158hrs ok.
14th Capture @ 2200hrs failed at 0sec into file.
PVA Says File Header ok rest is garbage. corrupt Video & Audio Data.
File size was 650kB instead of 50MB.
15th Capture @ 2202hrs ok.
............
22nd Capture @ 2216hrs stopped at 52sec.
23rd Capture @ 2218hrs ok.
...............................
42th Capture @ 2256hrs ok.
43th Capture @ 2258hrs Failed at 51sec.
BSOD Thbdacap.sys Addr F71437A1 Base AT F7143000 Date Stamp 40daa2b8.
PC Reset required.
44th Capture @ 2300hrs Missed.
45st Capture @ 2302hrs ok.
...
49th Capture ok.
Wrapper Log.
Direct Show Log:-
Noted the following process on asus P4P800S 2.8ghz 1G Ram.
.................................Waiting..........Running
Peak CPU Usage:-................3%..............6%
PF Usage :- ........................260MB..............274MB
Threads:-............................405...............417
Processes:-..........................37..................37
BOSD occured without warning.
No increase in process of Java.
My speculation so far is not to record more than 42 scheduled recording without a reboot. Allow for every 14th recording to be corrupt, and stay away from exact record start times arround the top of the hour.
Hope this helps in finding the problem.
Dan
RE: BDA WS 2.8.1.0, Capt eng 4.2.1.0, BDA Drv 1.5.2.1
I have completed 49, 1 min SS Captures of Network 10 SD, spaced 1 min apart similar to Null_pointer with the following results:-
1st Capture @ 2134hrs ok.
...........
13th Capture @ 2158hrs ok.
14th Capture @ 2200hrs failed at 0sec into file.
PVA Says File Header ok rest is garbage. corrupt Video & Audio Data.
File size was 650kB instead of 50MB.
15th Capture @ 2202hrs ok.
............
22nd Capture @ 2216hrs stopped at 52sec.
23rd Capture @ 2218hrs ok.
...............................
42th Capture @ 2256hrs ok.
43th Capture @ 2258hrs Failed at 51sec.
BSOD Thbdacap.sys Addr F71437A1 Base AT F7143000 Date Stamp 40daa2b8.
PC Reset required.
44th Capture @ 2300hrs Missed.
45st Capture @ 2302hrs ok.
...
49th Capture ok.
Wrapper Log.
QUOTE
Failure 1.............................File Corrupt 2200hrs.
INFO | jvm 1 | 2004/07/11 21:58:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 21:58:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 21:58:01 | (2004-07-11 21-58) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 21:58:01 | About to start capture
INFO | jvm 1 | 2004/07/11 21:58:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 21:59:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 21:59:00 | Capture Thread Exiting
INFO | jvm 1 | 2004/07/11 22:00:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:00:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:00:01 | (2004-07-11 22-00) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:00:01 | About to start capture
INFO | jvm 1 | 2004/07/11 22:00:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 22:01:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:01:00 | Capture Thread Exiting
INFO | jvm 1 | 2004/07/11 22:02:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:02:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:02:01 | (2004-07-11 22-02) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:02:01 | About to start capture
INFO | jvm 1 | 2004/07/11 22:02:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 22:03:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:03:00 | Capture Thread Exiting
Failure 2............................................BSOD 2258hrs
INFO | jvm 1 | 2004/07/11 22:56:02 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:56:02 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:56:02 | (2004-07-11 22-56) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:56:02 | About to start capture
INFO | jvm 1 | 2004/07/11 22:56:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 22:57:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:57:00 | Capture Thread Exiting
INFO | jvm 1 | 2004/07/11 22:58:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:58:02 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:58:02 | (2004-07-11 22-58) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:58:02 | About to start capture
INFO | jvm 1 | 2004/07/11 22:58:04 | Capture started with code : 0
STATUS | wrapper | 2004/07/11 23:02:11 | --> Wrapper Started as Service
STATUS | wrapper | 2004/07/11 23:02:13 | Launching a JVM...
INFO | jvm 1 | 2004/07/11 23:02:14 | Wrapper (Version 3.0.4)
INFO | jvm 1 | 2004/07/11 23:02:14 |
INFO | jvm 1 | 2004/07/11 23:02:14 | New DataStore Object created (2.8.1.0)
INFO | jvm 1 | 2004/07/11 23:02:14 | channels.obj found and loaded 17 channels
INFO | jvm 1 | 2004/07/11 23:02:14 | data\channelMap.store loaded.
INFO | jvm 1 | 2004/07/11 23:02:14 | Loading Users
INFO | jvm 1 | 2004/07/11 23:02:14 | 2 Users added
INFO | jvm 1 | 2004/07/11 23:02:14 | Times.obj found and loaded.
INFO | jvm 1 | 2004/07/11 23:02:15 | data\epg.store loaded.
INFO | jvm 1 | 2004/07/11 23:02:15 | cards.obj found and loaded
INFO | jvm 1 | 2004/07/11 23:02:15 | epg-auto.obj found and loaded
INFO | jvm 1 | 2004/07/11 23:02:15 | Timer Thread: Created
INFO | jvm 1 | 2004/07/11 23:02:15 | Timer Thread: Started
INFO | jvm 1 | 2004/07/11 23:02:15 | Starting server listening on port : 8080
INFO | jvm 1 | 2004/07/11 23:02:15 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 23:02:15 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 23:02:15 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 23:02:15 | (2004-07-11 23-02) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 23:02:15 | About to start capture
INFO | jvm 1 | 2004/07/11 23:02:25 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 23:03:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 23:03:01 | Capture Thread Exiting
INFO | jvm 1 | 2004/07/11 21:58:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 21:58:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 21:58:01 | (2004-07-11 21-58) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 21:58:01 | About to start capture
INFO | jvm 1 | 2004/07/11 21:58:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 21:59:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 21:59:00 | Capture Thread Exiting
INFO | jvm 1 | 2004/07/11 22:00:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:00:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:00:01 | (2004-07-11 22-00) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:00:01 | About to start capture
INFO | jvm 1 | 2004/07/11 22:00:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 22:01:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:01:00 | Capture Thread Exiting
INFO | jvm 1 | 2004/07/11 22:02:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:02:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:02:01 | (2004-07-11 22-02) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:02:01 | About to start capture
INFO | jvm 1 | 2004/07/11 22:02:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 22:03:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:03:00 | Capture Thread Exiting
Failure 2............................................BSOD 2258hrs
INFO | jvm 1 | 2004/07/11 22:56:02 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:56:02 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:56:02 | (2004-07-11 22-56) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:56:02 | About to start capture
INFO | jvm 1 | 2004/07/11 22:56:04 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 22:57:00 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:57:00 | Capture Thread Exiting
INFO | jvm 1 | 2004/07/11 22:58:01 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 22:58:02 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 22:58:02 | (2004-07-11 22-58) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 22:58:02 | About to start capture
INFO | jvm 1 | 2004/07/11 22:58:04 | Capture started with code : 0
STATUS | wrapper | 2004/07/11 23:02:11 | --> Wrapper Started as Service
STATUS | wrapper | 2004/07/11 23:02:13 | Launching a JVM...
INFO | jvm 1 | 2004/07/11 23:02:14 | Wrapper (Version 3.0.4)
INFO | jvm 1 | 2004/07/11 23:02:14 |
INFO | jvm 1 | 2004/07/11 23:02:14 | New DataStore Object created (2.8.1.0)
INFO | jvm 1 | 2004/07/11 23:02:14 | channels.obj found and loaded 17 channels
INFO | jvm 1 | 2004/07/11 23:02:14 | data\channelMap.store loaded.
INFO | jvm 1 | 2004/07/11 23:02:14 | Loading Users
INFO | jvm 1 | 2004/07/11 23:02:14 | 2 Users added
INFO | jvm 1 | 2004/07/11 23:02:14 | Times.obj found and loaded.
INFO | jvm 1 | 2004/07/11 23:02:15 | data\epg.store loaded.
INFO | jvm 1 | 2004/07/11 23:02:15 | cards.obj found and loaded
INFO | jvm 1 | 2004/07/11 23:02:15 | epg-auto.obj found and loaded
INFO | jvm 1 | 2004/07/11 23:02:15 | Timer Thread: Created
INFO | jvm 1 | 2004/07/11 23:02:15 | Timer Thread: Started
INFO | jvm 1 | 2004/07/11 23:02:15 | Starting server listening on port : 8080
INFO | jvm 1 | 2004/07/11 23:02:15 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 23:02:15 | Number of cards available (1) number in use (0)
INFO | jvm 1 | 2004/07/11 23:02:15 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 23:02:15 | (2004-07-11 23-02) Network TEN Brisbane.mpg
INFO | jvm 1 | 2004/07/11 23:02:15 | About to start capture
INFO | jvm 1 | 2004/07/11 23:02:25 | Capture started with code : 0
INFO | jvm 1 | 2004/07/11 23:03:01 | Times.obj saved.
INFO | jvm 1 | 2004/07/11 23:03:01 | Capture Thread Exiting
Direct Show Log:-
QUOTE
Failure 1...................................File Corrupt @ 2200hrs
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h21 m57 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h21 m59 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 21-58) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
win32-DLL : Trying to clean up card 0
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h21 m59 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m1 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 22-00) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
win32-DLL : Trying to clean up card 0
Failure 2.............................................BSOD @ 2258hrs
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m55 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m57 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 22-56) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
win32-DLL : Trying to clean up card 0
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m57 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m59 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 22-58) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
-------------------------------------------------------------------------------------------------
win32-DLL : Process Attached : CaptureEngine.dll Version:4.2.1.0
-------------------------------------------------------------------------------------------------
win32-DLL : Creating Waitable Timer
win32-DLL : Waitable Timer ID 384
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h21 m57 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h21 m59 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 21-58) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
win32-DLL : Trying to clean up card 0
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h21 m59 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m1 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 22-00) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
win32-DLL : Trying to clean up card 0
Failure 2.............................................BSOD @ 2258hrs
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m55 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m57 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 22-56) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
win32-DLL : Trying to clean up card 0
CoUninitialize Called
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m57 s15)
win32-DLL : Setting Wake up Time (y2004 m7 d11 h22 m59 s15)
CoInitializeEx worked with result of S_OK
win32-DLL : BDAwrapper : Getting next free card.
win32-DLL : BDAwrapper : Capturing to file : C:\Capture\(2004-07-11 22-58) Network TEN Brisbane.mpg.
win32-DLL : BDAwrapper : Found a free card and will try to set it up: card ID=0
win32-DLL : BDAwrapper : About to build Capture Graph
win32-DLL-BDA : Starting build of capture graph
win32-DLL-BDA : Loading Network Provider
win32-DLL-BDA : Creating Tune Request
win32-DLL-BDA : Submiting Tune Request
win32-DLL-BDA : Loading Tuner Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Tuner Filter
win32-DLL-BDA : Loading Capture Filter
win32-DLL-BDA : LoadFilter(): THDTV DVB-t BDA Capture Filter
win32-DLL-BDA : About to Load Main Demux
win32-DLL-BDA : Registering Graph in ROT
win32-DLL-BDA : Configuring Main Demux
win32-DLL-BDA : LoadFilter(): BDA MPEG2 Transport Information Filter
win32-DLL-BDA : Capture Graph Built
win32-DLL : BDAwrapper : Capture Graph Built
win32-DLL : BDAwrapper : Trying to Start Capture of Pid v = 512 a = 650 on card 0
win32-DLL : BDAwrapper : About to setup Capture Type (ShowShifter Mux Cap)
win32-DLL-BDA : Changing Frequency 219500 bandwidth 7.
win32-DLL-BDA : Mapping Video PID 512
win32-DLL-BDA : Mapping Audio PID 650
win32-DLL-BDA : Signal Strength 84
win32-DLL-BDA : Found IBDA_Topology interface 0
win32-DLL-BDA : Got Control Node 1 0
win32-DLL-BDA : Found IBDA_SignalStatistics interface 0
win32-DLL-BDA : Got Signal Quality : 98
win32-DLL-BDA : Got Signal Locked : 1
win32-DLL-BDA : About to leave RunGraph with code 0
-------------------------------------------------------------------------------------------------
win32-DLL : Process Attached : CaptureEngine.dll Version:4.2.1.0
-------------------------------------------------------------------------------------------------
win32-DLL : Creating Waitable Timer
win32-DLL : Waitable Timer ID 384
Noted the following process on asus P4P800S 2.8ghz 1G Ram.
.................................Waiting..........Running
Peak CPU Usage:-................3%..............6%
PF Usage :- ........................260MB..............274MB
Threads:-............................405...............417
Processes:-..........................37..................37
BOSD occured without warning.
No increase in process of Java.
My speculation so far is not to record more than 42 scheduled recording without a reboot. Allow for every 14th recording to be corrupt, and stay away from exact record start times arround the top of the hour.
Hope this helps in finding the problem.
Dan
I think perhaps your 14th capture was the same issue but the crash is a completely different problem.
The shorter captures, well that might just be short captures.
The shorter captures, well that might just be short captures.
OK, I'm seeing this to now - I know I've seen it before but I ignored it as some kind of anomaly. I've witnessed (quite randomly) the lock up of a streaming session. I've only seen it right at the start - after the first 8meg or so of data is pumped through, the filters downstream seem to stop and the driver runs out of buffers to DMA data in to.
If the clue is a TS with corrupt data then possibly the downstream filters have locked up and streaming comes to a halt. This would likely explain the java process going to 100% as it can't communicate properly with the filters??
I don't think it's possible for the card to return TS data out of order, so I hope there's a problem with the driver code (That's always my hope - if it ever turns out that the hardware is crap then we're all screwed).
I haven't been able to see aproblem from scanning the code, so I've got more serious debugging sessions ahead of me.
Spectrum
If the clue is a TS with corrupt data then possibly the downstream filters have locked up and streaming comes to a halt. This would likely explain the java process going to 100% as it can't communicate properly with the filters??
I don't think it's possible for the card to return TS data out of order, so I hope there's a problem with the driver code (That's always my hope - if it ever turns out that the hardware is crap then we're all screwed).
I haven't been able to see aproblem from scanning the code, so I've got more serious debugging sessions ahead of me.
Spectrum
It is possible that the data isn't out of order. It's just got corruption in it and when projectX sees a corrupt timecode it assumes it's out of order.
I think it's unlikely that the hardware is causing the problem or we would have seen something with the twinhan drivers.
I think it's unlikely that the hardware is causing the problem or we would have seen something with the twinhan drivers.
Yes Nate I agree, ProjectX could just be confused and thus thinks the packet it out of sequence, also if this was a hardware issue then it would show up in the TH driver also.
Although Spoonfed has seen 100% Java usage in all my testing I have not seen this. When I get the corrupt TS everything looks fine and functions as it should it is just that the TS is corrupt.
Although Spoonfed has seen 100% Java usage in all my testing I have not seen this. When I get the corrupt TS everything looks fine and functions as it should it is just that the TS is corrupt.
I wish damn Dvico would release the BDA drivers, then at least could test WS with another "real" BDA card hence elimnating VP hardware and spectrums drivers (well would help in someway i guess).
Guys,
Round 2 of WS capture tests, same format as before,
1st Capture @ 1008hrs ok.
............
13th Capture @ 1032hrs ok.
14th Capture @ 1034hrs. Failed at 0sec into file.
15th Capture @ 1036hrs ok.
..........
26th Capture @ 1058hrs ok.
27th Capture @ 1100hrs. Failed at 0sec into file.
28th Capture @ 1002hrs ok.
........
36th Capture @ 1118hrs ok.
37th Capture @ 1120hrs. Failed at 0sec into file.
38th Capture @ 1122hrs ok.
........
47th Capture @ 1140hrs ok.
Next capture @ 1200hrs. Failed at 0sec into file.
Next capture @ 1202hrs. Failed at 25sec into file.
Next capture @ 1258hrs. ok.
Next capture @ 1300hrs. ok.
Next capture @ 1302hrs. ok.
Next capture @ 1358hrs. ok.
Next capture @ 1400hrs. ok.
Next capture @ 1402hrs. Failed at 0sec into file.
Next capture @ 1458hrs. ok.
Next capture @ 1500hrs. ok.
Next capture @ 1502hrs. ok.
Nothing unusual in the wrapper & Directshow logs.
No unusual increase in processor usage.
No BSOD thank goodness.
No increase in Wrapper Process memory usage.
Java memory usage monitoring.
Average memory usage increase from idle to running:- 10200kB.
Average increase in idle memory usage:- 8kB/Recording.
Average increase in running usage:- 8kB/Recording.
Total increase in idle memory usage over 50 captures:- from 14220kB - 15576kB.
Total increase in Run memory usage over 50 captures:- from 24452kB - 25920kB.
Guys is it possible there may be a memory leak causing the increase in memory usage of java?
Looks like the 14th capture failure is repeatable. Also strange that the top of the Clock is still a possibility.
Hope it helps,
Dan.
Round 2 of WS capture tests, same format as before,
1st Capture @ 1008hrs ok.
............
13th Capture @ 1032hrs ok.
14th Capture @ 1034hrs. Failed at 0sec into file.
15th Capture @ 1036hrs ok.
..........
26th Capture @ 1058hrs ok.
27th Capture @ 1100hrs. Failed at 0sec into file.
28th Capture @ 1002hrs ok.
........
36th Capture @ 1118hrs ok.
37th Capture @ 1120hrs. Failed at 0sec into file.
38th Capture @ 1122hrs ok.
........
47th Capture @ 1140hrs ok.
Next capture @ 1200hrs. Failed at 0sec into file.
Next capture @ 1202hrs. Failed at 25sec into file.
Next capture @ 1258hrs. ok.
Next capture @ 1300hrs. ok.
Next capture @ 1302hrs. ok.
Next capture @ 1358hrs. ok.
Next capture @ 1400hrs. ok.
Next capture @ 1402hrs. Failed at 0sec into file.
Next capture @ 1458hrs. ok.
Next capture @ 1500hrs. ok.
Next capture @ 1502hrs. ok.
Nothing unusual in the wrapper & Directshow logs.
No unusual increase in processor usage.
No BSOD thank goodness.
No increase in Wrapper Process memory usage.
Java memory usage monitoring.
Average memory usage increase from idle to running:- 10200kB.
Average increase in idle memory usage:- 8kB/Recording.
Average increase in running usage:- 8kB/Recording.
Total increase in idle memory usage over 50 captures:- from 14220kB - 15576kB.
Total increase in Run memory usage over 50 captures:- from 24452kB - 25920kB.
Guys is it possible there may be a memory leak causing the increase in memory usage of java?
Looks like the 14th capture failure is repeatable. Also strange that the top of the Clock is still a possibility.
Hope it helps,
Dan.
I ust tested 17 captures (1min) with no gapps, 4 of them had the short file/corruption issue. It almost seems like the "more" it is pushed/used the more frequent the issue shows up.
All of the ABC caps had the issue, and 1 of the Seven caps. Yet i do an ABC "stand alone" cap now and it works fine.
All of the ABC caps had the issue, and 1 of the Seven caps. Yet i do an ABC "stand alone" cap now and it works fine.
If you are testing this you really should be using the full TS capture, this is the only way you can rule out demux and remux issues.
I have also just uploaded a new version od WS that has an added feature for creating multiple test captures.
Version 2.8.2.0
http://www.digtv.ws/files/dvb/BDA
TESTING
=======
If you want to add a number of test captures to test your system for stability with WS and the driver/SDK etc you can use the following URL to add them automatically:
number = number of items to add, this will add 5 cycles of the channel list, i.e. all the channels you currently have setup 5 times (5 channels = 25 entries)
type = the is the type of capture (0 TS mux, 1 Full TS, 2 CL Mux, 3 SS Mux, 4 Sep Files, 5 TEST 01)
duration = the duration of each capture
The items will have a 1 min gape between them.
I have also just uploaded a new version od WS that has an added feature for creating multiple test captures.
Version 2.8.2.0
http://www.digtv.ws/files/dvb/BDA
TESTING
=======
If you want to add a number of test captures to test your system for stability with WS and the driver/SDK etc you can use the following URL to add them automatically:
CODE
http://localhost:8080/servlet/ScheduleDataRes?action=10&duration=1&number=5&type=1
number = number of items to add, this will add 5 cycles of the channel list, i.e. all the channels you currently have setup 5 times (5 channels = 25 entries)
type = the is the type of capture (0 TS mux, 1 Full TS, 2 CL Mux, 3 SS Mux, 4 Sep Files, 5 TEST 01)
duration = the duration of each capture
The items will have a 1 min gape between them.
Null,
Thanks Null, will do some more captures tonight using full TS, the previous captures I listed were referenced to the startup of the PC using SS Mux.
Do you think its a good idea to update to the BDA 1.5.3.0 test drivers as previously discussed or would it be helpful to stick to a known BDA driver version for your cross reference?
or
Do we need to continue to post our test capture results?
Dan.
QUOTE
If you are testing this you really should be using the full TS capture, this is the only way you can rule out demux and remux issues.
I have also just uploaded a new version od WS that has an added feature for creating multiple test captures.
I have also just uploaded a new version od WS that has an added feature for creating multiple test captures.
Thanks Null, will do some more captures tonight using full TS, the previous captures I listed were referenced to the startup of the PC using SS Mux.
Do you think its a good idea to update to the BDA 1.5.3.0 test drivers as previously discussed or would it be helpful to stick to a known BDA driver version for your cross reference?
or
Do we need to continue to post our test capture results?
Dan.
bear, I think spectrum has now been able to reproduce the problem with the corrupt TS so give him a while to see what he can work out.
Null,
I can reproduce the same issues using CL mux or not (as it seems you can).
Im pretty certain that it somewhat relates to the number of captures performed before reboot
My system shuts down its self each night (late....well early
) and turns on in the arvo automaticly.
Usually it only does 2 or maybe 3 captures per night and this corruption issue i have almost never seen during normal capture.
However in testing (with many captures) it is reproduced many times. Even a "normal" schedule tonight many hours after testing was done (and directly after a OK "normal" capture) ended up capturing with corruption (lucky i checked).
I will load latest "test" drivers and WS tommorrow to do some further tests.
I can reproduce the same issues using CL mux or not (as it seems you can).
Im pretty certain that it somewhat relates to the number of captures performed before reboot
My system shuts down its self each night (late....well early
) and turns on in the arvo automaticly.Usually it only does 2 or maybe 3 captures per night and this corruption issue i have almost never seen during normal capture.
However in testing (with many captures) it is reproduced many times. Even a "normal" schedule tonight many hours after testing was done (and directly after a OK "normal" capture) ended up capturing with corruption (lucky i checked
).I will load latest "test" drivers and WS tommorrow to do some further tests.
I just used null's latest version and the capture generator to make 30 1 minute captures and 9 of them turned out corrupt. Actually 6 of the last 7 were corrupt, and the other three were captures 13 and 17 and 19.
Taking a look at the contents of the files with a hex editor (UltraEdit) it's quite obvious which one's are corrupt.
The captures that are currupt all have huge sections of zero's in them and always start with 15040 bytes of zeros.
Example.
15040 bytes of zeros
20096 bytes of data
9984 bytes of zeros
752 bytes of data
14288 bytes of zeros
896 bytes of data
14144 bytes of zeros
352 bytes of data
etc.
After a few Mb it tends to settle down a bit more and put more data compared to zeros, but there's still way too many zeros there.
None of the good captures have any zeros at the start but on further examination they do have 184 byte long blocks of 0x00, 0xFF, 0xED and 0xFEEDFACE (I laughed at this one too) throughout them.
These may be part of the original stream though so I'd really need to switch back to the twinhan drivers and do a dump from it's TS pin to see what a standard ts stream should look like (assuming twinhan got it right. am i asking too much?).
Hope that's of some help to you spectrum.
[EDIT]I should mention that i did all the capture on the same channel (Ten) to try and get a bit of consistency[/EDIT]
Taking a look at the contents of the files with a hex editor (UltraEdit) it's quite obvious which one's are corrupt.
The captures that are currupt all have huge sections of zero's in them and always start with 15040 bytes of zeros.
Example.
15040 bytes of zeros
20096 bytes of data
9984 bytes of zeros
752 bytes of data
14288 bytes of zeros
896 bytes of data
14144 bytes of zeros
352 bytes of data
etc.
After a few Mb it tends to settle down a bit more and put more data compared to zeros, but there's still way too many zeros there.
None of the good captures have any zeros at the start but on further examination they do have 184 byte long blocks of 0x00, 0xFF, 0xED and 0xFEEDFACE (I laughed at this one too) throughout them.
These may be part of the original stream though so I'd really need to switch back to the twinhan drivers and do a dump from it's TS pin to see what a standard ts stream should look like (assuming twinhan got it right. am i asking too much?).
Hope that's of some help to you spectrum.
[EDIT]I should mention that i did all the capture on the same channel (Ten) to try and get a bit of consistency[/EDIT]
will comparing the .tp capture from dvico help? i guess the .tp file should be same/simlar to the .ts? let us know
Is one of the many streams transmited corrupt or is the whole lot corrupt ?
Is it possible for the Driver to detect, software/hardware a totaly corrupt packet, and drop it, for stability reasons. e.g what happens when the TS structure is corrupt, and the next filter therefore can not decode the TS structure.
Which begs the question what does a packet look like, is it like ethernet, with a standard header or something so that the start of a packet can be found ?
Is there any benefit in coding the driver to dump directly to disk, ie. no filters. And looking at the contents of this .e.g compare nice capture with one that had eletrical motors and switches going off and on. It may also provide a repeatable test/data.
Cheers
Is it possible for the Driver to detect, software/hardware a totaly corrupt packet, and drop it, for stability reasons. e.g what happens when the TS structure is corrupt, and the next filter therefore can not decode the TS structure.
Which begs the question what does a packet look like, is it like ethernet, with a standard header or something so that the start of a packet can be found ?
Is there any benefit in coding the driver to dump directly to disk, ie. no filters. And looking at the contents of this .e.g compare nice capture with one that had eletrical motors and switches going off and on. It may also provide a repeatable test/data.
Cheers
Ok, just switched over to the twinhan drivers and did a dump of the TS pin and found the same blocks of 0x00's 0xFACEFEED's etc.. that were in the good BDA driver captures.
Either
- that's the way the stream is,
- twinhan's drivers arn't 100% either, or
- that's the best we're going to get out of the card.
Spoonfed, could you open up one of your DVICO's tp files in a hex editor and have a look though it to see if that has blocks of 0x00's etc. also.
If you don't have a hex editor then grab a trial version of ultraedit. Just make sure you check "Open File without Temp File" in the configuration or you'll be waiting for a while for files to load.
Either
- that's the way the stream is,
- twinhan's drivers arn't 100% either, or
- that's the best we're going to get out of the card.
Spoonfed, could you open up one of your DVICO's tp files in a hex editor and have a look though it to see if that has blocks of 0x00's etc. also.
If you don't have a hex editor then grab a trial version of ultraedit. Just make sure you check "Open File without Temp File" in the configuration or you'll be waiting for a while for files to load.
FACEFEED on Google
http://support.microsoft.com/default.aspx?...kb;EN-US;185787
http://support.microsoft.com/default.aspx?...kb;EN-US;193548
http://www.mail-archive.com/gimp-developer...u/msg01998.html
#define MY_DEBUG_MAGIC_HEAD (0xdeadbeaf)
#define MY_DEBUG_MAGIC_TAIL (0xfacefeed)
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/pro...ndy/interp/gc.c
It look like facefeed has something todo with using an I/O card or the stack
http://support.microsoft.com/default.aspx?...kb;EN-US;185787
http://support.microsoft.com/default.aspx?...kb;EN-US;193548
http://www.mail-archive.com/gimp-developer...u/msg01998.html
#define MY_DEBUG_MAGIC_HEAD (0xdeadbeaf)
#define MY_DEBUG_MAGIC_TAIL (0xfacefeed)
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/pro...ndy/interp/gc.c
It look like facefeed has something todo with using an I/O card or the stack
datkins, thanks for the effort but none of those links are relevant.
Currently each frame is 15040 bytes of data worked out like this:
If my current thinking is right, I would interpret your example as:
Spectrum
QUOTE ("nate")
Example.
15040 bytes of zeros
20096 bytes of data
9984 bytes of zeros
752 bytes of data
14288 bytes of zeros
896 bytes of data
14144 bytes of zeros
352 bytes of data
etc.
This is helpful. It seems to indicate that the hardware is losing sync and jumping to the end of the frame to resynchronise.15040 bytes of zeros
20096 bytes of data
9984 bytes of zeros
752 bytes of data
14288 bytes of zeros
896 bytes of data
14144 bytes of zeros
352 bytes of data
etc.
Currently each frame is 15040 bytes of data worked out like this:
- 188 bytes in a TS packet (going by MS spec. to align on 188 byte boundary)
- In the bt878 hardware a "line" of data can be up to 4095 bytes so I've chosen 188*20 = 3760 bytes
- In the bt878 hardware a "frame" can be up to 255 "lines" so I've chosen 4 lines at the moment
- which gives 3760 * 4 = 15040
If my current thinking is right, I would interpret your example as:
- 15040: a whole frame lost sync
- 20096: (15040+5056) one whole good frame plus 5056 good bytes
- 9984: the remainder of a frame lost (9984+5056 from above = 15040)
- 752: 752 good bytes
- 14288: the remainder of a frame lost (14288+752 from above = 15040)
- 896: 896 good bytes
- 14144: the remainder of a frame lost (14144+895 from above = 15040)
Spectrum
Figuring out "why" is obviously the best thing to do. Perhaps though it is hardware related. In which case a work around can only be sort? Can the drivers be made to "check" for such inconsistencies and perform a "retune" or similar as a "fix"? Perhaps even the TH drivers do this, which would impliy that they know there is a hardware issue and simply "patch" it.......not that it would suprise me
Just to elaborate, from the bt878 PDF.
Paragraph 4 covers my thoughts. I still need to find where my code is going wrong.
Spectrum
CODE
2.12.7 FIFO Data Stream Resynchronization
The Fusion 878A DMA controller is constantly monitoring whether there is a mismatch between the amount of data expected by the RISC instruction and the amount of data being provided by the FIFO. The DMA controller then corrects for the mismatches and realigns the RISC program and the FIFO data stream.
For example, if the FIFO contains a shorter video line than expected by the RISC instruction, the DMA controller detects the EOL control code from the FIFO earlier than expected. The DMA controller then aborts the rest of the RISC instructions until it detects the EOL control code from the RISC program.
If the FIFO contains a longer video line than expected by the RISC instruction, the DMA controller will not detect the EOL control code from the FIFO at the expected time. The DMA controller will continue reading the FIFO data; however it will discard the additional FIFO data until it reaches the EOL control code from the FIFO.
Similarly, if the FIFO provides a smaller number of scan lines per field than expected by the RISC program, the end of field control codes from the FIFO (VRE/VRO) will arrive early. The DMA controller then aborts all RISC instructions until the SYNC status codes from the RISC instruction match the end of field status codes from the FIFO.
If the FIFO provides a larger number of scan lines per field than expected by the RISC program, the end of field control codes from the FIFO (VRE/VRO) will not arrive at the expected time. Again, the FIFO data is read by the DMA controller and discarded until the SYNC status codes from the RISC instruction match the end of field status codes from the FIFO.
The DMA controller manages all of the above error conditions, but the FIFO Data Stream Resynchronization (FDSR) interrupt bit will be set as well.
The Fusion 878A DMA controller is constantly monitoring whether there is a mismatch between the amount of data expected by the RISC instruction and the amount of data being provided by the FIFO. The DMA controller then corrects for the mismatches and realigns the RISC program and the FIFO data stream.
For example, if the FIFO contains a shorter video line than expected by the RISC instruction, the DMA controller detects the EOL control code from the FIFO earlier than expected. The DMA controller then aborts the rest of the RISC instructions until it detects the EOL control code from the RISC program.
If the FIFO contains a longer video line than expected by the RISC instruction, the DMA controller will not detect the EOL control code from the FIFO at the expected time. The DMA controller will continue reading the FIFO data; however it will discard the additional FIFO data until it reaches the EOL control code from the FIFO.
Similarly, if the FIFO provides a smaller number of scan lines per field than expected by the RISC program, the end of field control codes from the FIFO (VRE/VRO) will arrive early. The DMA controller then aborts all RISC instructions until the SYNC status codes from the RISC instruction match the end of field status codes from the FIFO.
If the FIFO provides a larger number of scan lines per field than expected by the RISC program, the end of field control codes from the FIFO (VRE/VRO) will not arrive at the expected time. Again, the FIFO data is read by the DMA controller and discarded until the SYNC status codes from the RISC instruction match the end of field status codes from the FIFO.
The DMA controller manages all of the above error conditions, but the FIFO Data Stream Resynchronization (FDSR) interrupt bit will be set as well.
Paragraph 4 covers my thoughts. I still need to find where my code is going wrong.
Spectrum
With the Hex edit comparing.....should the 0x00 only show up on errored files?
can't see anything as discribed either VP or Dvico captures. My guess is it will be in the left column? As the others only have 2 characters
can't see anything as discribed either VP or Dvico captures. My guess is it will be in the left column? As the others only have 2 characters
QUOTE (spectrum)
I still need to find where my code is going wrong
That fact that it happens for the duration of a capture and not at all in other captures to me means it's not a data transfer issue. It's more likely that it's something to do with the tuning or something else that happens once at the start of the capture.QUOTE (spoonfed)
With the Hex edit comparing.....should the 0x00 only show up on errored files?
can't see anything as discribed either VP or Dvico captures. My guess is it will be in the left column? As the others only have 2 characters
can't see anything as discribed either VP or Dvico captures. My guess is it will be in the left column? As the others only have 2 characters
I've noticed zeros on both good and bad captures, but the blocks of zeros in good captures tend to not be any longer than 184 zeros in a row.
If you're using ultraedit just press Ctrl-F and type in 0 about 320 times 00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
1 byte is 2 zeros
That should find any blocks of zeros for you.
I've been looking at some TS dumps and seeing a lot of series of 0x00's and 0xff's. So long as they follow the usual 0x47 0xXX 0xXX 0xXX 4-byte header then I don't think there's any problem with a lot of the data we're seeing. Even the feedface's appear to be a normal part of the TS.
It's takes me a lot of testing to get it to grind to a halt, but on the one occasion it did, everything looked normal. It's just that the whole AV streaming system came to a stop but the TS did not appear to be unusual.
Still investigating.
Spectrum
It's takes me a lot of testing to get it to grind to a halt, but on the one occasion it did, everything looked normal. It's just that the whole AV streaming system came to a stop but the TS did not appear to be unusual.
Still investigating.
Spectrum
Ok, i don't think it's anything to do with the tune request itself.
I created a graph with the network provider, THDTV Tuner filter, THDTV Capture filter, and Dump Filter.
I applied a tune request (for ch 10), connected up the pins, and ran the graph for a few seconds and it resulted in a corrupt capture.
I deleted the file and without submitting any more tune request just restarted the graph. The file was fine.
I did this another 30 or so times and all of them were fine.
Next i tried submitting a new tune request between each capture for about 20 captures and they still turned out all fine.
So on that bit of limited testing it looks like it only happens the first time you run the filter after creating it.
Shaun, could you do a test version of captureengine.dll that starts, stops, deletes the file, and then starts the graph again? That way if we find that it always works then it will have narrowed it down a lot for Spectrum.
I created a graph with the network provider, THDTV Tuner filter, THDTV Capture filter, and Dump Filter.
I applied a tune request (for ch 10), connected up the pins, and ran the graph for a few seconds and it resulted in a corrupt capture.
I deleted the file and without submitting any more tune request just restarted the graph. The file was fine.
I did this another 30 or so times and all of them were fine.
Next i tried submitting a new tune request between each capture for about 20 captures and they still turned out all fine.
So on that bit of limited testing it looks like it only happens the first time you run the filter after creating it.
Shaun, could you do a test version of captureengine.dll that starts, stops, deletes the file, and then starts the graph again? That way if we find that it always works then it will have narrowed it down a lot for Spectrum.
QUOTE (Spectrum @ Jul 13 2004, 07:13 PM)
It's takes me a lot of testing to get it to grind to a halt, but on the one occasion it did, everything looked normal. It's just that the whole AV streaming system came to a stop but the TS did not appear to be unusual.
For me it does not grind to a half, everything is still working fine (no 100% usage etc) it is just that the TS is corrupt.
QUOTE (Nate)
Shaun, could you do a test version of captureengine.dll that starts, stops, deletes the file, and then starts the graph again? That way if we find that it always works then it will have narrowed it down a lot for Spectrum.
Ok, the dump filter overwrites anyway so there is no need to delete the file, just start, stop and start again. If I get it finished tonight I will post here.
Ok, test version of the DLL is available.
http://www.digtv.ws/files/dvb/BDA
It builds and starts the graph, waits for 1 sec stops the graph waits for 1 sec and then restarts the graph.
http://www.digtv.ws/files/dvb/BDA
It builds and starts the graph, waits for 1 sec stops the graph waits for 1 sec and then restarts the graph.
Problem not fixed with the above hack. I got 3 out of 25 captures with the corruption problem using the above DLL
I had a quick look in them using bin editor and I do not see the all 0 blocks that Nate saw, the data looks continuous.
I had a quick look in them using bin editor and I do not see the all 0 blocks that Nate saw, the data looks continuous.
Null,
Same here. Im not 100% sure what im looking at with hex but the short test files i did seem not to contain to much continuous 00 's
However the .tp file output from Dvico card does contain sustantial sections of 00 always followed by 47 04 01 18 which goes up sequentially after each "batch" of sequential 00 's. ie 47 04 01 19 but is "sort of" reset after each section of sequential data/info (ie not 00 's)
beats me what it all means, though if many 00 's is bad then the output from Dvico is far worse than from VP.
(excuse my stupidity in my interpretation hehe)
Same here. Im not 100% sure what im looking at with hex but the short test files i did seem not to contain to much continuous 00 's
However the .tp file output from Dvico card does contain sustantial sections of 00 always followed by 47 04 01 18 which goes up sequentially after each "batch" of sequential 00 's. ie 47 04 01 19 but is "sort of" reset after each section of sequential data/info (ie not 00 's)
beats me what it all means, though if many 00 's is bad then the output from Dvico is far worse than from VP.
(excuse my stupidity in my interpretation hehe)
yeah. I've had it going for nearly half an hour now and 6 out of 13 have corrupt data in them, but none of the corrupt files have huge chunks of zeros in them now.
At first glance it looks like some of the 15040 byte sections are all fine, and others are stuffed up (ie, packets not all starting with 0x47).
I'll see if i can see any sort of pattern to this now.
At first glance it looks like some of the 15040 byte sections are all fine, and others are stuffed up (ie, packets not all starting with 0x47).
I'll see if i can see any sort of pattern to this now.
FYI. A TS packet is 188 bytes. The first 4 bytes are the header, the first byte of the header is the sync byte 0x47, the remaining bits have meanings with the final 4 bits of the 4th byte being the continuity counter.
eg in hex 47 09 05 16, you have 47 the TS sync and the 6 at the end is the continuity counter which increments and rolls back to zero after 0xf. After the 4 byte header, 184 bytes of payload follow.
Spectrum
eg in hex 47 09 05 16, you have 47 the TS sync and the 6 at the end is the continuity counter which increments and rolls back to zero after 0xf. After the 4 byte header, 184 bytes of payload follow.
Spectrum
QUOTE (Spectrum @ Jul 13 2004, 05:13 PM)
and seeing a lot of series of 0x00's and 0xff's. So long as they follow the usual 0x47 0xXX 0xXX 0xXX 4-byte header then I don't think there's any problem with a lot of the data we're seeing.
Full TS captures have a null PID which is always identified as 0x1fff. It can range from 400kbits (SBS and Ten) to 15mbits (Regional networks with no HD). It's just unused mux space.
P.S. How do you identify these corrupt TS files? Sometimes I get TS captures that appear weird in DVD2AVI TS version (looks like very frequent corrupt frames) but once demuxed in ProjectX, they are fine.
I decided to write a quick TS stream analyzer. Download (24Kb, includes source code)
and it looks like the in the corrupt captures the first few TS packets of every frame aren't aligned properly.
and it looks like the in the corrupt captures the first few TS packets of every frame aren't aligned properly.
CODE
Offset diff TS Header Seq.number
0x0000008f (+ 143) - 0x47 0x02 0x00 0x1a a
0x0000014b (+ 188) - 0x47 0x02 0x02 0x17 7
0x00000207 (+ 188) - 0x47 0x02 0x00 0x1b b
0x000002c3 (+ 188) - 0x47 0x02 0x02 0x18 8
0x0000037f (+ 188) - 0x47 0x02 0x02 0x19 9
0x0000043b (+ 188) - 0x47 0x02 0x00 0x1c c
0x000004f7 (+ 188) - 0x47 0x02 0x02 0x1a a
...
0x0000333b (+ 188) - 0x47 0x02 0x01 0x15 5
...
0x000039d7 (+ 188) - 0x47 0x02 0x02 0x13 3
0x00003a93 (+ 188) - 0x47 0x02 0x00 0x13 3
0x00003b74 (+ 225) - 0x47 0x02 0x01 0x17 7 Out of sequence
0x00003c30 (+ 188) - 0x47 0x02 0x02 0x15 5 Out of sequence
0x00003d83 (+ 339) - 0x47 0x02 0x01 0x1e e Out of sequence
0x00003e3f (+ 188) - 0x47 0x02 0x02 0x1b b Out of sequence
0x00003efb (+ 188) - 0x47 0x02 0x02 0x1c c
0x00003fb7 (+ 188) - 0x47 0x02 0x00 0x13 3 Out of sequence
0x00004073 (+ 188) - 0x47 0x02 0x02 0x1d d
0x0000412f (+ 188) - 0x47 0x02 0x00 0x14 4
0x000041eb (+ 188) - 0x47 0x02 0x02 0x1e e
0x000042a7 (+ 188) - 0x47 0x02 0x02 0x1f f
0x00004363 (+ 188) - 0x47 0x02 0x00 0x15 5
...
0x000073db (+ 188) - 0x47 0x02 0x02 0x15 5
0x00007497 (+ 188) - 0x47 0x1f 0xff 0x10
0x00007553 (+ 188) - 0x47 0x02 0x02 0x16 6
0x00007634 (+ 225) - 0x47 0x02 0x02 0x12 2 Out of sequence
0x00007787 (+ 339) - 0x47 0x02 0x02 0x1d d Out of sequence
0x00007843 (+ 188) - 0x47 0x02 0x01 0x1a a Out of sequence
0x000078ff (+ 188) - 0x47 0x02 0x02 0x1e e
...
0x0000ae9b (+ 188) - 0x47 0x02 0x02 0x17 7
0x0000af57 (+ 188) - 0x47 0x02 0x02 0x18 8
0x0000b013 (+ 188) - 0x47 0x02 0x00 0x11 1
0x0000b0f4 (+ 225) - 0x47 0x02 0x02 0x1f f Out of sequence
0x0000b1d1 (+ 221) - 0x47 0x08 0x51 0x3f
0x0000b303 (+ 306) - 0x47 0x02 0x02 0x10 0
0x0000b3bf (+ 188) - 0x47 0x02 0x00 0x11 1 Out of sequence
0x0000b47b (+ 188) - 0x47 0x02 0x02 0x11 1
...
0x0000ea17 (+ 188) - 0x47 0x02 0x00 0x18 8
0x0000ead3 (+ 188) - 0x47 0x02 0x02 0x1b b
0x0000ebb4 (+ 225) - 0x47 0x02 0x00 0x1f f Out of sequence
0x0000ec70 (+ 188) - 0x47 0x02 0x02 0x1d d Out of sequence
0x0000ed2c (+ 188) - 0x47 0x02 0x01 0x13 3 Out of sequence
0x0000ee7f (+ 339) - 0x47 0x02 0x02 0x13 3 Out of sequence
0x0000ef3b (+ 188) - 0x47 0x02 0x8b 0x15
0x0000eff7 (+ 188) - 0x47 0x02 0x02 0x14 4
0x0000f0b3 (+ 188) - 0x47 0x02 0x02 0x15 5
0x0000008f (+ 143) - 0x47 0x02 0x00 0x1a a
0x0000014b (+ 188) - 0x47 0x02 0x02 0x17 7
0x00000207 (+ 188) - 0x47 0x02 0x00 0x1b b
0x000002c3 (+ 188) - 0x47 0x02 0x02 0x18 8
0x0000037f (+ 188) - 0x47 0x02 0x02 0x19 9
0x0000043b (+ 188) - 0x47 0x02 0x00 0x1c c
0x000004f7 (+ 188) - 0x47 0x02 0x02 0x1a a
...
0x0000333b (+ 188) - 0x47 0x02 0x01 0x15 5
...
0x000039d7 (+ 188) - 0x47 0x02 0x02 0x13 3
0x00003a93 (+ 188) - 0x47 0x02 0x00 0x13 3
0x00003b74 (+ 225) - 0x47 0x02 0x01 0x17 7 Out of sequence
0x00003c30 (+ 188) - 0x47 0x02 0x02 0x15 5 Out of sequence
0x00003d83 (+ 339) - 0x47 0x02 0x01 0x1e e Out of sequence
0x00003e3f (+ 188) - 0x47 0x02 0x02 0x1b b Out of sequence
0x00003efb (+ 188) - 0x47 0x02 0x02 0x1c c
0x00003fb7 (+ 188) - 0x47 0x02 0x00 0x13 3 Out of sequence
0x00004073 (+ 188) - 0x47 0x02 0x02 0x1d d
0x0000412f (+ 188) - 0x47 0x02 0x00 0x14 4
0x000041eb (+ 188) - 0x47 0x02 0x02 0x1e e
0x000042a7 (+ 188) - 0x47 0x02 0x02 0x1f f
0x00004363 (+ 188) - 0x47 0x02 0x00 0x15 5
...
0x000073db (+ 188) - 0x47 0x02 0x02 0x15 5
0x00007497 (+ 188) - 0x47 0x1f 0xff 0x10
0x00007553 (+ 188) - 0x47 0x02 0x02 0x16 6
0x00007634 (+ 225) - 0x47 0x02 0x02 0x12 2 Out of sequence
0x00007787 (+ 339) - 0x47 0x02 0x02 0x1d d Out of sequence
0x00007843 (+ 188) - 0x47 0x02 0x01 0x1a a Out of sequence
0x000078ff (+ 188) - 0x47 0x02 0x02 0x1e e
...
0x0000ae9b (+ 188) - 0x47 0x02 0x02 0x17 7
0x0000af57 (+ 188) - 0x47 0x02 0x02 0x18 8
0x0000b013 (+ 188) - 0x47 0x02 0x00 0x11 1
0x0000b0f4 (+ 225) - 0x47 0x02 0x02 0x1f f Out of sequence
0x0000b1d1 (+ 221) - 0x47 0x08 0x51 0x3f
0x0000b303 (+ 306) - 0x47 0x02 0x02 0x10 0
0x0000b3bf (+ 188) - 0x47 0x02 0x00 0x11 1 Out of sequence
0x0000b47b (+ 188) - 0x47 0x02 0x02 0x11 1
...
0x0000ea17 (+ 188) - 0x47 0x02 0x00 0x18 8
0x0000ead3 (+ 188) - 0x47 0x02 0x02 0x1b b
0x0000ebb4 (+ 225) - 0x47 0x02 0x00 0x1f f Out of sequence
0x0000ec70 (+ 188) - 0x47 0x02 0x02 0x1d d Out of sequence
0x0000ed2c (+ 188) - 0x47 0x02 0x01 0x13 3 Out of sequence
0x0000ee7f (+ 339) - 0x47 0x02 0x02 0x13 3 Out of sequence
0x0000ef3b (+ 188) - 0x47 0x02 0x8b 0x15
0x0000eff7 (+ 188) - 0x47 0x02 0x02 0x14 4
0x0000f0b3 (+ 188) - 0x47 0x02 0x02 0x15 5
QUOTE (Champion_R @ Jul 13 2004, 11:47 PM)
P.S. How do you identify these corrupt TS files? Sometimes I get TS captures that appear weird in DVD2AVI TS version (looks like very frequent corrupt frames) but once demuxed in ProjectX, they are fine.
See the first post about ProjectX results with these corrupt TS caps.
Basically when I play them in the Moonlight player the video and audio are as if there is a lot of breakup in the stream i.e. blocks of missing data from the video and audio. It is like this all the way through the file from start to finish not just in a few frames etc.
QUOTE (Nate)
I decided to write a quick TS stream analyzer. Download (24Kb, includes source code)
Excellent Nate, I will have a play tonight.
It looks like there's two different problems in corrupt captures.
1. The problem of blocks of zeros's. This seems to be solvable by stopping and restarting the graph.
2. The first 100-500 bytes of frames appears to be not aligned correctly.
Spectrum,
Would it be possible to tell the bt878 to use lines 5-8 of the frame instead of lines 1-4? Perhaps the VP is having intermittent problems accessing the start of the first line of the frame and so isn't filling the buffer correctly?
Also, and this is a long shot, but is it possible to tell the VP to duplicate data in different frames?
eg.
frame 1 - (packet 1, packet 2, ..., packet 79, packet 80)
frame 2 - (packet 41, packet 42, ..., packet 119, packet 120)
frame 3 - (packet 81, packet 82, ..., packet 159, packet 160)
If it is then even though it'd double the data flow on the PCI bus you'd be able to do an integrity check to make sure packet 41 in frame 2 is the same as packet 41 in frame 1.
1. The problem of blocks of zeros's. This seems to be solvable by stopping and restarting the graph.
2. The first 100-500 bytes of frames appears to be not aligned correctly.
Spectrum,
Would it be possible to tell the bt878 to use lines 5-8 of the frame instead of lines 1-4? Perhaps the VP is having intermittent problems accessing the start of the first line of the frame and so isn't filling the buffer correctly?
Also, and this is a long shot, but is it possible to tell the VP to duplicate data in different frames?
eg.
frame 1 - (packet 1, packet 2, ..., packet 79, packet 80)
frame 2 - (packet 41, packet 42, ..., packet 119, packet 120)
frame 3 - (packet 81, packet 82, ..., packet 159, packet 160)
If it is then even though it'd double the data flow on the PCI bus you'd be able to do an integrity check to make sure packet 41 in frame 2 is the same as packet 41 in frame 1.
nate, what you are asking is not possible with this hardware. I'm starting to think the problem you are seeing is different from the one I've been experiencing.
My problem looks to be with downstream filters and shows up as a freezing of the streaming process. The actual data doesn't seem to be bad.
You don't appear to experience streaming freezes but your data is problematic. Your explanations of the problem suggest errors in the RISC DMA program I construct for the bt878 to run.
I wonder if there are differences in the various platforms we're all using. I hope I'm not making wrong assumptons in my code - though there aren't many areas that might.
Hmmm, maybe there are timing issues between me updating the RISC code and the board reading the code from host memory to itself..... Something for me to look at - sorry, just thinking out loud. Think yourselves lucky I don't write a blog.
Spectrum
My problem looks to be with downstream filters and shows up as a freezing of the streaming process. The actual data doesn't seem to be bad.
You don't appear to experience streaming freezes but your data is problematic. Your explanations of the problem suggest errors in the RISC DMA program I construct for the bt878 to run.
I wonder if there are differences in the various platforms we're all using. I hope I'm not making wrong assumptons in my code - though there aren't many areas that might.
Hmmm, maybe there are timing issues between me updating the RISC code and the board reading the code from host memory to itself..... Something for me to look at - sorry, just thinking out loud. Think yourselves lucky I don't write a blog.
Spectrum
Spectrum,
I wouldn't describe i as the stream freezing, but as Nate has. The capture does play back, but with perhaps a "strip" of blocked up video along the top for a while, which many then change to most of the screen but with blocks (large in size) missing, randomly changing etc.
I wouldn't describe i as the stream freezing, but as Nate has. The capture does play back, but with perhaps a "strip" of blocked up video along the top for a while, which many then change to most of the screen but with blocks (large in size) missing, randomly changing etc.
QUOTE (Spectrum @ Jul 14 2004, 12:17 PM)
nate, what you are asking is not possible with this hardware. I'm starting to think the problem you are seeing is different from the one I've been experiencing.
That's ok. I thought it was worth suggesting though incase it was possible.QUOTE (Spectrum @ Jul 14 2004, 12:17 PM)
My problem looks to be with downstream filters and shows up as a freezing of the streaming process. The actual data doesn't seem to be bad.
does "downstream filters" include just having the dump filter connected? or is it only when you try to decode the stream that it freezes?QUOTE (Spectrum @ Jul 14 2004, 12:17 PM)
I wonder if there are differences in the various platforms we're all using. I hope I'm not making wrong assumptons in my code - though there aren't many areas that might.
I'm running an VIA based MSI motherboard with an Athlon 2000+. I might actually double check that i've got the latest 4in1 drivers installed tonight.I havn't studied this thoroughly, but it seems that file turns out ok if it starts with with a TS header at the beginning of the file.
Corrupt files occur when the first TS header is not at the start, like in the analysis i posted before. The first TS header is at offset 0x8f but then the TS packets are fine until the end of the frame, but none of the TS packets are aligned on the 188 byte boundary. Could it be an alignment issue right at the start that's causing the screwups the rest of the way through the file?
Look what you've done spectrum. Now i'm thinking out loud too.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.