• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 808
  • Last Modified:

Directshow / Stream Buffer Engine / Mediaseeking

Hi,

I've got a strange problem, and maybe there is someone out there that can
help me out. I'm using the Stream Buffer Engine in WinXPsp1  (SBE for short)
to build my own PVR (personal video recorder). I've got allmost everything
working now (including timeshifting) but I've a problem creating permanent
recordings using the SBE (file extention DVR-MS)

What I do:
- create a capture graph and use the Streamsink to write to disk (create a
recorderobject, set to permanent writing, enter filename blah blah blah);
- start the actual recording to the permanent file
(pRecordControl->start(0));

Now while recording I can open the file using any player (after the TV
performance update Q810243) and watch the file while it is being recorder. While
recording media player shows the correct mediaduration (time)

- when i'm done recording i call pRecordControl->stop(0). This stops the
recording and trims the created file to the length actually used. I free the
Recorderobject (_Release) . Now when I try playing the newly recorded file ,
mediaplayer (or any other program for that matter) shows a mediaduration
that is absolutely nonsense (sometime 4 hrs for a 10 second recording,
sometimes for example 22094993939393 hrs 3434783278789mins for a 2 minute
recording). Getting the current position from the IMediaSeeking interface is no
problem and works correctly.

What do I do wrong ? Do I have to set the mediaduration myself just before
stopping the recorder object (if so how ?)... Any suggestions are
appreciated.

Rgds,

Tom


0
Bombadil
Asked:
Bombadil
  • 4
  • 2
  • 2
1 Solution
 
TascoDLXCommented:
Are you confirming that the recording has stopped before you release the recording object?

You might try spinning on GetRecordingStatus() [*after* calling Stop()] and waiting for it to return bStopped as TRUE.

Something like this, only less off-the-cuff:

BOOL bStopped;
do
{
  Sleep(0);
  pRecordControl->GetRecordingStatus(NULL,NULL,&bStopped);

} while (bStopped == FALSE);
0
 
DanRollinsCommented:
Your question made me read up on this subject and it is way cool.   Obviously, one cannot rule out bugs in this fledgling technology.

The only thing that jumps out at me is that you did not specify the type you are using in the CreateRecorder call.  Do you get similar problems with both RECORDING_TYPE_REFERENCE and RECORDING_TYPE_CONTENT ?  Also do you get the same problem when you *don't* open the stream for playing while it is currently recording?

-- Dan
0
 
BombadilAuthor Commented:
TascoDLX. Yes before releasing the recording object I make sure it has stopped.

Dan, it sure is cool ! I started writing my own filters but found out 'by accident' that Windows XP sp1 had these filters standard. I could understand there are some bugs, but Windows MCE also uses the same technology. I would guess MS would have fixed it by now. I get the problem for both content and reference recordings. I also get the problem when i don't open the stream while it is still being recorded to.

Rgds. Tom
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
TascoDLXCommented:
The only other thing I can think of is if you use the RecordingAttribute interface to manually set the duration after you've stopped recording.

I'd imagine you've probably already tried this, but just in case, the call is (I believe):

pRecordingAttribute->SetAttribute(0, L"Duration", STREAMBUFFER_TYPE_QWORD, &qwDuration, sizeof(QWORD));

If that doesn't work, I'd say open up the newly created vidfile and manually write the duration into the header.
Can't say I know the DVR-MS format off hand though.
0
 
BombadilAuthor Commented:
TascoDLX,

Had not tried that before (cool feature b.t.w. to add additional information to the recording itself; date, program, genre ,etc).

I found out that writing Attributes after the recording has started is not possible. Any attributes you want to set you would heve to set before the recording starts (so it seems). Also setting attributes just before or just after stopping the recording doesn't seem to work.

What I did find is, that the correct duration is actually present in the file header. I haven't figured out the header format, but I noticed that the incorrect duration (8 bytes) is allways followed by the correct duration (also 8 bytes). Depending on the additional attributes you set the position of these bytes tends to shift so before I can actually do something with this info, I'll have to figure out the header format. Manually hacking the header and shifting these 8 bytes results in a file that has a correct duration though.

Rgds,

Tom
0
 
DanRollinsCommented:
>>when I try playing the newly recorded file, mediaplayer ... shows a mediaduration that is absolutely nonsense

Is this only a 'cosmetic' problem?  That is, does media player correctly play only 10 seconds of a 10-second recording?  Maybe the fault is that the media player is misinterpretting the the data.  For instance, it may be doing 32-bit math with 64-bit values.  Or perhaps it assumes that the upper 32 bit have been cleared, etc.  

If you try to seek eleven seconds into a ten-second file, does the API indicate the error correctly?  If you use the correct procedure to obtain the duration data (whatever procedure that is), do you get correct values?

-- Dan
0
 
BombadilAuthor Commented:
Dan,

It is not just a cosmetic problem. All methods for obtaining the media duration give the same wrong result. Zoomplayer for example simply crashes if you seek beyond the actual end of the file.

Currenty I've found a workaround. It's dirty, but it works (dirty because there has to be a clean method).

After the recording is finished I open the file and just hack the header, replacing the incorrect duration data with the correct duration data. For now I'm happy.

Rgds,

Tom
0
 
BombadilAuthor Commented:
It's not the "clean" answer I was looking for, but I go for the "write the duration myself" part of your answer.
(for now that seems to work).

Thanks.

0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 4
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now