DirectShow MPEG-1 keyframe detection
From: john_o (john_o_at_verizon.net)
Date: 01/28/05
- Next message: Alessandro Angeli [MVP::DigitalMedia]: "Re: DirectShow MPEG-1 keyframe detection"
- Previous message: DVBPortal: "Re: Windows Media Player 10 does not seek with custom source filter in push mode"
- Next in thread: Alessandro Angeli [MVP::DigitalMedia]: "Re: DirectShow MPEG-1 keyframe detection"
- Reply: Alessandro Angeli [MVP::DigitalMedia]: "Re: DirectShow MPEG-1 keyframe detection"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 28 Jan 2005 00:55:59 GMT
DirectShow MPEG-1 keyframe detection
All 23 messages in topic - view as tree
Joe Flynn Dec 16 2003, 7:43 pm show options
Newsgroups: microsoft.public.win32.programmer.directx.video
From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author
Date: Tue, 16 Dec 2003 19:42:42 -0800
Local: Tues, Dec 16 2003 7:42 pm
Subject: DirectShow MPEG-1 keyframe detection
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse
I have been working to add keyframe position detection
capability to a DirectShow video editing application that
I am developing. Adding this capability for AVI files was
fairly trivial - create a graph consisting of a source
file, stream splitter, sample grabber, and null renderer.
In the SampleGrabber callback analyze the IsSyncPoint()
parameter for each of the samples flowing through the
graph and mark the sample times of those for which it is
set.
However using this same process for keyframe detection in
MPEG-1 files has proven to be a real pain-in-the-!@#. The
test file that I am using in my development contains 1425
total frames, the IPB frame ratio is 1:5:2 which gives me
18 frames per GOP. The entire file contains 81 I-frames,
400 P-frames, and 944 B-frames. However, whenever I run
this test file through my DirectShow keyframe detection
graph IsSyncPoint() is set on a total of 1130 samples
rather than the expected 81. Does anyone have any ideas
why this might be happening?
I have looked at the VTRANS samples in the Base Classes
and the code comments seem to imply that using IsSyncPoint
should be valid method for keyframe detection in MPEG
files. Any ideas on what I might be doing wrong? Is there
a better/preferred method for keyframe detection in MPEG-1
files?
Any help is appreciated. Thanks.
Joe Flynn
Reply
Iain Dec 17 2003, 12:19 am show options
Newsgroups: microsoft.public.win32.programmer.directx.video
From: "Iain" <idownsX...@dircon.co.uk> - Find messages by this author
Date: Wed, 17 Dec 2003 08:17:30 -0000
Local: Wed, Dec 17 2003 12:17 am
Subject: Re: DirectShow MPEG-1 keyframe detection
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse
Joust a guess.
Does it depend on the MPEG decoder? try another one (or 2).
Does it depend on where you put the sample grabber?
Maybe it needs to go before the decoder (to determing which samples are key
frames) and then pick them up from the time stamps afterwards.
Iain
"Joe Flynn" <joseph.fl...@nospam.com> wrote in message
news:002901c3c44f$d3699b80$a001280a@phx.gbl...
- Hide quoted text -
- Show quoted text -
> I have been working to add keyframe position detection
> capability to a DirectShow video editing application that
> I am developing. Adding this capability for AVI files was
> fairly trivial - create a graph consisting of a source
> file, stream splitter, sample grabber, and null renderer.
> In the SampleGrabber callback analyze the IsSyncPoint()
> parameter for each of the samples flowing through the
> graph and mark the sample times of those for which it is
> set.
> However using this same process for keyframe detection in
> MPEG-1 files has proven to be a real pain-in-the-!@#. The
> test file that I am using in my development contains 1425
> total frames, the IPB frame ratio is 1:5:2 which gives me
> 18 frames per GOP. The entire file contains 81 I-frames,
> 400 P-frames, and 944 B-frames. However, whenever I run
> this test file through my DirectShow keyframe detection
> graph IsSyncPoint() is set on a total of 1130 samples
> rather than the expected 81. Does anyone have any ideas
> why this might be happening?
> I have looked at the VTRANS samples in the Base Classes
> and the code comments seem to imply that using IsSyncPoint
> should be valid method for keyframe detection in MPEG
> files. Any ideas on what I might be doing wrong? Is there
> a better/preferred method for keyframe detection in MPEG-1
> files?
> Any help is appreciated. Thanks.
> Joe Flynn
Reply
anonymous Dec 17 2003, 5:57 am show options
Newsgroups: microsoft.public.win32.programmer.directx.video
From: <anonym...@discussions.microsoft.com> - Find messages by this author
Date: Wed, 17 Dec 2003 05:57:03 -0800
Local: Wed, Dec 17 2003 5:57 am
Subject: Re: DirectShow MPEG-1 keyframe detection
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse
No, I have found that if I place the SampleGrabber after
the decoder then 100% of the frames are considered
keyframes by IsSyncPoint. Placing the Grabber after the
decoder also created some problems with keyframe detection
in certain AVI formats like DIVX (MPEG4) and Cinepak. The
current method I use doesn't include a decoder - it just
looks like:
SourceFile -> Stream Splitter -> SampleGrab -> NullRenderer
This method seemed to give the best overall results for
most formats - except MPEG-1.
Thanks
Joe Flynn
- Hide quoted text -
- Show quoted text -
>-----Original Message-----
>Joust a guess.
>Does it depend on the MPEG decoder? try another one (or
2).
>Does it depend on where you put the sample grabber?
>Maybe it needs to go before the decoder (to determing
which samples are key
>frames) and then pick them up from the time stamps
afterwards.
>Iain
>"Joe Flynn" <joseph.fl...@nospam.com> wrote in message
>news:002901c3c44f$d3699b80$a001280a@phx.gbl...
>> I have been working to add keyframe position detection
>> capability to a DirectShow video editing application
that
>> I am developing. Adding this capability for AVI files
was
>> fairly trivial - create a graph consisting of a source
>> file, stream splitter, sample grabber, and null
renderer.
>> In the SampleGrabber callback analyze the IsSyncPoint()
>> parameter for each of the samples flowing through the
>> graph and mark the sample times of those for which it is
>> set.
>> However using this same process for keyframe detection
in
>> MPEG-1 files has proven to be a real pain-in-the-!@#.
The
>> test file that I am using in my development contains
1425
>> total frames, the IPB frame ratio is 1:5:2 which gives
me
>> 18 frames per GOP. The entire file contains 81 I-frames,
>> 400 P-frames, and 944 B-frames. However, whenever I run
>> this test file through my DirectShow keyframe detection
>> graph IsSyncPoint() is set on a total of 1130 samples
>> rather than the expected 81. Does anyone have any ideas
>> why this might be happening?
>> I have looked at the VTRANS samples in the Base Classes
>> and the code comments seem to imply that using
IsSyncPoint
>> should be valid method for keyframe detection in MPEG
>> files. Any ideas on what I might be doing wrong? Is
there
>> a better/preferred method for keyframe detection in
MPEG-1
>> files?
>> Any help is appreciated. Thanks.
>> Joe Flynn
>.
Reply
Joe Flynn Dec 19 2003, 7:30 am show options
Newsgroups: microsoft.public.win32.programmer.directx.video
From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author
Date: Fri, 19 Dec 2003 07:29:57 -0800
Local: Fri, Dec 19 2003 7:29 am
Subject: DirectShow MPEG-1 keyframe detection
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse
ATTN: MSDN subscriber support - this is a re-post of a
message originally posted on 12/16/03 @ 7:42PM that never
received a response. You can validate my MSDN subscription
info via the nospam alias listed above or can contact me
directly at: jwflynn1REMOVETHEC...@hotmail.com Thank you.
- Hide quoted text -
- Show quoted text -
I have been working to add keyframe position detection
capability to a DirectShow video editing application that
I am developing. Adding this capability for AVI files was
fairly trivial - create a graph consisting of a source
file, stream splitter, sample grabber, and null renderer.
In the SampleGrabber callback analyze the IsSyncPoint()
parameter for each of the samples flowing through the
graph and mark the sample times of those for which it is
set.
However using this same process for keyframe detection in
MPEG-1 files has proven to be a real pain-in-the-!@#. The
test file that I am using in my development contains 1425
total frames, the IPB frame ratio is 1:5:2 which gives me
18 frames per GOP. The entire file contains 81 I-frames,
400 P-frames, and 944 B-frames. However, whenever I run
this test file through my DirectShow keyframe detection
graph IsSyncPoint() is set on a total of 1130 samples
rather than the expected 81. Does anyone have any ideas
why this might be happening?
I have looked at the VTRANS samples in the Base Classes
and the code comments seem to imply that using IsSyncPoint
should be valid method for keyframe detection in MPEG
files. Any ideas on what I might be doing wrong? Is there
a better/preferred method for keyframe detection in MPEG-1
files?
Any help is appreciated. Thanks.
Joe Flynn
Reply
Yan-Hong Huang[MSFT] Dec 25 2003, 7:02 pm show options
Newsgroups: microsoft.public.win32.programmer.directx.video
From: yhhu...@online.microsoft.com (Yan-Hong Huang[MSFT]) - Find
messages by this author
Date: Fri, 26 Dec 2003 03:01:11 GMT
Local: Thurs, Dec 25 2003 7:01 pm
Subject: Re: DirectShow MPEG-1 keyframe detection
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse
Hello Joe,
Thanks for your post.
I just reviewed this issue and found that nobody touched it for many days.
If you are still monitoring for this issue, could you please add a reply
here? I will look for somebody to look into this question.
Merry Christmas and Happy Holiday!
Best regards,
Yanhong Huang
Microsoft Community Support
Get Secure! 每 www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
Reply
Joe Flynn Dec 26 2003, 9:31 am show options
Newsgroups: microsoft.public.win32.programmer.directx.video
From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author
Date: Fri, 26 Dec 2003 09:29:42 -0800
Local: Fri, Dec 26 2003 9:29 am
Subject: Re: DirectShow MPEG-1 keyframe detection
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse
Yanhong
Merry Christmas and yes I am still monitoring this thread.
I have done some more experiments but still don't have any
definitive way of detecting MPEG-1 I-frames. The
IsSyncPoint() call in my SampleGrabber callback routine
doesn't seem tbe able to discriminate between I, P, and B
frame samples. Any guidance or suggestions would be
greatly appreciated.
Thank you for your assistance.
Joe Flynn
- Hide quoted text -
- Show quoted text -
>-----Original Message-----
>Hello Joe,
>Thanks for your post.
>I just reviewed this issue and found that nobody touched
it for many days.
>If you are still monitoring for this issue, could you
please add a reply
>here? I will look for somebody to look into this question.
>Merry Christmas and Happy Holiday!
>Best regards,
>Yanhong Huang
>Microsoft Community Support
>Get Secure! 每 www.microsoft.com/security
>This posting is provided "AS IS" with no warranties, and
confers no rights
.
- Hide quoted text -
- Show quoted text -
>.
Reply
Alessandro Angeli [MVP::DigitalMedia] Dec 26 2003, 12:15 pm show
options
Newsgroups: microsoft.public.win32.programmer.directx.video
From: "Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.net> -
Find messages by this author
Date: Fri, 26 Dec 2003 21:11:47 +0100
Local: Fri, Dec 26 2003 12:11 pm
Subject: Re: DirectShow MPEG-1 keyframe detection
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse
Have you tried with different MPEG splitters? In the end,
it's the demuxer's responsiblity to flag the samples. This
is fine with an AVI splitter since the keyframe flags are in
the AVI index, that is in the system stream, which is what
the splitter analyzes. With MPEG, the flags are in the video
ES and not in the system stream, so the splitter may simply
have no idea about the picture type (I, B or P) if it only
looks at the PES packets. For example, the Elecard splitter
(which supports MPEG1 system streams, MPEG2 program streams
and MPEG1/2 video streams) may be smarter than the default
MPEG1 splitter shipped with DirectShow (which only supports
M1S).
Joe Flynn wrote:
- Hide quoted text -
- Show quoted text -
> Yanhong
> Merry Christmas and yes I am still monitoring this thread.
> I have done some more experiments but still don't have any
> definitive way of detecting MPEG-1 I-frames. The
> IsSyncPoint() call in my SampleGrabber callback routine
> doesn't seem tbe able to discriminate between I, P, and B
> frame samples. Any guidance or suggestions would be
> greatly appreciated.
> Thank you for your assistance.
> Joe Flynn
>> -----Original Message-----
>> Hello Joe,
>> Thanks for your post.
>> I just reviewed this issue and found that nobody touched
>> it for many days. If you are still monitoring for this
>> issue, could you please add a reply here? I will look
>> for somebody to look into this question.
>> Merry Christmas and Happy Holiday!
>> Best regards,
>> Yanhong Huang
>> Microsoft Community Support
>> Get Secure! 每 www.microsoft.com/security
>> This posting is provided "AS IS" with no warranties, and
>> confers no rights.
>> .
-- /** * Alessandro Angeli * * MVP::DigitalMedia * * a dot angeli at biosys dot net */ Reply Joe Flynn Dec 26 2003, 1:31 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author Date: Fri, 26 Dec 2003 13:30:11 -0800 Local: Fri, Dec 26 2003 1:30 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Alessandro Thanks for the response. I haven't tried different MPEG Splitters and will try the Elecard and Ligos ones to see if they fare any better than the standard one that ships with DirectShow. When I first started working with keyframe detection I did some quick tests based on the SampleGrabberCB example that ships with the DirectX SDK. It used the SampleGrabber that is in embedded in the IMediaDet interface to analyze the samples flowing through the graph. The graph it produced looked like: Source -> MPEG Splitter -> MPEG Decoder -> SampleGrabber - > Null Renderer Even though the SampleGrabber was positioned after the decoder when this graph was run it indicated that 100% of the MPEG samples were keyframes (but as you mentioned it was using the standard DShow components). This method of detection also gave me some erroneous results with the DIVX and Cinepak AVI file types so I moved away from using the IMediaDet method and just manually constructed my own graph that excluded the decoder component. I understand what you are saying about the MPEG-1 frame types being embedded within the video elemental stream and will try using the Elecard components in both my current detection graph (without a video decoder) and also in a graph similar to that produced using the ImediaDet method. I appreciate your input. Thanks. Joe Flynn - Hide quoted text - - Show quoted text - >-----Original Message----- >Have you tried with different MPEG splitters? In the end, >it's the demuxer's responsiblity to flag the samples. This >is fine with an AVI splitter since the keyframe flags are in >the AVI index, that is in the system stream, which is what >the splitter analyzes. With MPEG, the flags are in the video >ES and not in the system stream, so the splitter may simply >have no idea about the picture type (I, B or P) if it only >looks at the PES packets. For example, the Elecard splitter >(which supports MPEG1 system streams, MPEG2 program streams >and MPEG1/2 video streams) may be smarter than the default >MPEG1 splitter shipped with DirectShow (which only supports >M1S). >Joe Flynn wrote: >> Yanhong >> Merry Christmas and yes I am still monitoring this thread. >> I have done some more experiments but still don't have any >> definitive way of detecting MPEG-1 I-frames. The >> IsSyncPoint() call in my SampleGrabber callback routine >> doesn't seem tbe able to discriminate between I, P, and B >> frame samples. Any guidance or suggestions would be >> greatly appreciated. >> Thank you for your assistance. >> Joe Flynn >>> -----Original Message----- >>> Hello Joe, >>> Thanks for your post. >>> I just reviewed this issue and found that nobody touched >>> it for many days. If you are still monitoring for this >>> issue, could you please add a reply here? I will look >>> for somebody to look into this question. >>> Merry Christmas and Happy Holiday! >>> Best regards, >>> Yanhong Huang >>> Microsoft Community Support >>> Get Secure! 每 www.microsoft.com/security >>> This posting is provided "AS IS" with no warranties, and >>> confers no rights. >>> . >-- >/** > * Alessandro Angeli > * > * MVP::DigitalMedia > * > * a dot angeli at biosys dot net > */ >. Reply Joe Flynn Dec 26 2003, 4:44 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author Date: Fri, 26 Dec 2003 16:42:18 -0800 Local: Fri, Dec 26 2003 4:42 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse I ran some tests using the Ligos and Elecard MPEG components but am still not having any success. The Ligos components only allow me to connect the SampleGrabber to the output of the Ligos decoder so the resulting graph looks like: Source -> Ligos Splitter -> Ligos Video Decoder -> SampGrab -> Null Renderer Running my standard test file through this graph returns zero for the total keyframe count - go figure?? The Elecard MPEG demultiplexer does allow me to connect the SampleGrabber directly to the Demux output so the graph looks like: Source -> Elecard Demux -> SampGrab -> Null Renderer Running the test file through this graph returns 1135 total keyframes - so the result is still way off from the correct total of 81. I haven't yet tried adding the Elecard Video Decoder between the Demux and SampleGrabber but I don't have much hope that it will work either. If anyone has an idea please let me know. Thanks - Hide quoted text - - Show quoted text - >-----Original Message----- >Alessandro >Thanks for the response. I haven't tried different MPEG >Splitters and will try the Elecard and Ligos ones to see >if they fare any better than the standard one that ships >with DirectShow. When I first started working with >keyframe detection I did some quick tests based on the >SampleGrabberCB example that ships with the DirectX SDK. >It used the SampleGrabber that is in embedded in the >IMediaDet interface to analyze the samples flowing through >the graph. The graph it produced looked like: >Source -> MPEG Splitter -> MPEG Decoder -> SampleGrabber - >> Null Renderer >Even though the SampleGrabber was positioned after the >decoder when this graph was run it indicated that 100% of >the MPEG samples were keyframes (but as you mentioned it >was using the standard DShow components). This method of >detection also gave me some erroneous results with the >DIVX and Cinepak AVI file types so I moved away from using >the IMediaDet method and just manually constructed my own >graph that excluded the decoder component. >I understand what you are saying about the MPEG-1 frame >types being embedded within the video elemental stream and >will try using the Elecard components in both my current >detection graph (without a video decoder) and also in a >graph similar to that produced using the ImediaDet method. >I appreciate your input. Thanks. >Joe Flynn >>-----Original Message----- >>Have you tried with different MPEG splitters? In the end, >>it's the demuxer's responsiblity to flag the samples. This >>is fine with an AVI splitter since the keyframe flags are >in >>the AVI index, that is in the system stream, which is what >>the splitter analyzes. With MPEG, the flags are in the >video >>ES and not in the system stream, so the splitter may >simply >>have no idea about the picture type (I, B or P) if it only >>looks at the PES packets. For example, the Elecard >splitter >>(which supports MPEG1 system streams, MPEG2 program >streams >>and MPEG1/2 video streams) may be smarter than the default >>MPEG1 splitter shipped with DirectShow (which only >supports >>M1S). >>Joe Flynn wrote: >>> Yanhong >>> Merry Christmas and yes I am still monitoring this >thread. >>> I have done some more experiments but still don't have >any >>> definitive way of detecting MPEG-1 I-frames. The >>> IsSyncPoint() call in my SampleGrabber callback routine >>> doesn't seem tbe able to discriminate between I, P, and >B >>> frame samples. Any guidance or suggestions would be >>> greatly appreciated. >>> Thank you for your assistance. >>> Joe Flynn >>>> -----Original Message----- >>>> Hello Joe, >>>> Thanks for your post. >>>> I just reviewed this issue and found that nobody >touched >>>> it for many days. If you are still monitoring for this >>>> issue, could you please add a reply here? I will look >>>> for somebody to look into this question. >>>> Merry Christmas and Happy Holiday! >>>> Best regards, >>>> Yanhong Huang >>>> Microsoft Community Support >>>> Get Secure! 每 www.microsoft.com/security >>>> This posting is provided "AS IS" with no warranties, >and >>>> confers no rights. >>>> . >>-- >>/** >> * Alessandro Angeli >> * >> * MVP::DigitalMedia >> * >> * a dot angeli at biosys dot net >> */ >>. >. Reply Alessandro Angeli [MVP::DigitalMedia] Dec 27 2003, 7:14 am show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.net> - Find messages by this author Date: Sat, 27 Dec 2003 16:10:11 +0100 Local: Sat, Dec 27 2003 7:10 am Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Joe Flynn wrote: > Even though the SampleGrabber was positioned after the > decoder when this graph was run it indicated that 100% of > the MPEG samples were keyframes (but as you mentioned it > was using the standard DShow components). This method of > detection also gave me some erroneous results with the > DIVX and Cinepak AVI file types so I moved away from using > the IMediaDet method and just manually constructed my own > graph that excluded the decoder component. After the decoder, I would expect that every sample is a sync point, since there is no temporal compression anymore. > If anyone has an idea please let me know. Thanks I don't know what you are doing but, as long as you only need to scan a system or video stream for the keyframe flags, you could drop DirectShow, at least in the MPEG1/2 case (but also with AVIs), and write your own scanner, which would be a lot faster, 100% reliable and not system-dependent. Parsing an MPEG system or video stream hunting for I-frames requires half a page of code. You could also write your own sniffing filter in place of the SampleGrabber to insert right after the splitter or you could look at the actual video samples the grabber gives you to determine whether they contain an I-frame or not. If you're not familiar with MPEG, I can tell you what to look for. -- /** * Alessandro Angeli * * MVP::DigitalMedia * * a dot angeli at biosys dot net */ Reply Joe Flynn Dec 27 2003, 9:08 am show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author Date: Sat, 27 Dec 2003 09:06:38 -0800 Local: Sat, Dec 27 2003 9:06 am Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse With MPEG files I am already doing most of the real "work" outside of DirectShow - that is how I am sure of the correct I,B, and P frame content of my test file. As you mentioned parsing the MPEG file for I-frames is fairly easy - it is just that DirectShow provided a really nice framework for video preview and other than its quirks regarding keyframe detection meets my needs quite well - plus I was already using it to handle my AVI files so I guess I was trying to be lazy. I am interested in your suggestion regarding analyzing the samples delivered by the SampleGrabber though - do you know offhand if the samples that it delivers contain the raw Elemental Stream content of the source? I appreciate the advice. Joe Flynn - Hide quoted text - - Show quoted text - >-----Original Message----- >Joe Flynn wrote: >> Even though the SampleGrabber was positioned after the >> decoder when this graph was run it indicated that 100% of >> the MPEG samples were keyframes (but as you mentioned it >> was using the standard DShow components). This method of >> detection also gave me some erroneous results with the >> DIVX and Cinepak AVI file types so I moved away from using >> the IMediaDet method and just manually constructed my own >> graph that excluded the decoder component. >After the decoder, I would expect that every sample is a >sync point, since there is no temporal compression anymore. >> If anyone has an idea please let me know. Thanks >I don't know what you are doing but, as long as you only >need to scan a system or video stream for the keyframe >flags, you could drop DirectShow, at least in the MPEG1/2 >case (but also with AVIs), and write your own scanner, which >would be a lot faster, 100% reliable and not >system-dependent. Parsing an MPEG system or video stream >hunting for I-frames requires half a page of code. You could >also write your own sniffing filter in place of the >SampleGrabber to insert right after the splitter or you >could look at the actual video samples the grabber gives you >to determine whether they contain an I-frame or not. If >you're not familiar with MPEG, I can tell you what to look >for. >-- >/** > * Alessandro Angeli > * > * MVP::DigitalMedia > * > * a dot angeli at biosys dot net > */ >. Reply Alessandro Angeli [MVP::DigitalMedia] Dec 27 2003, 9:51 am show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.net> - Find messages by this author Date: Sat, 27 Dec 2003 18:50:53 +0100 Local: Sat, Dec 27 2003 9:50 am Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse If you place the grabber between the splitter and the decoder, it will provide you with the samples the decoder receives, which should be the single video ES pictures, including GOP and sequence headers. Most likely, the splitter will provide a sample for each picture in the stream, but the actual picture header may not start at offset 0 in the sample if it's preceeded but any sequence, GOP or extension header. In this case, just hunt for the picture_start_code in the sample (0x00000100) and then look at the value of the picture_coding_type bitfield (3 bits after 10 bits following the start code; 1 = I, 2 = P, 3 = B). Joe Flynn wrote: - Hide quoted text - - Show quoted text - > With MPEG files I am already doing most of the real "work" > outside of DirectShow - that is how I am sure of the > correct I,B, and P frame content of my test file. As you > mentioned parsing the MPEG file for I-frames is fairly > easy - it is just that DirectShow provided a really nice > framework for video preview and other than its quirks > regarding keyframe detection meets my needs quite well - > plus I was already using it to handle my AVI files so I > guess I was trying to be lazy. I am interested in your > suggestion regarding analyzing the samples delivered by > the SampleGrabber though - do you know offhand if the > samples that it delivers contain the raw Elemental Stream > content of the source? I appreciate the advice. > Joe Flynn >> -----Original Message----- >> Joe Flynn wrote: >>> Even though the SampleGrabber was positioned after the >>> decoder when this graph was run it indicated that 100% >>> of the MPEG samples were keyframes (but as you >>> mentioned it was using the standard DShow components). >>> This method of detection also gave me some erroneous >>> results with the DIVX and Cinepak AVI file types so I >>> moved away from using the IMediaDet method and just >>> manually constructed my own graph that excluded the >>> decoder component. >> After the decoder, I would expect that every sample is a >> sync point, since there is no temporal compression >> anymore. >>> If anyone has an idea please let me know. Thanks >> I don't know what you are doing but, as long as you only >> need to scan a system or video stream for the keyframe >> flags, you could drop DirectShow, at least in the MPEG1/2 >> case (but also with AVIs), and write your own scanner, >> which would be a lot faster, 100% reliable and not >> system-dependent. Parsing an MPEG system or video stream >> hunting for I-frames requires half a page of code. You >> could also write your own sniffing filter in place of the >> SampleGrabber to insert right after the splitter or you >> could look at the actual video samples the grabber gives >> you to determine whether they contain an I-frame or not. >> If you're not familiar with MPEG, I can tell you what to >> look for. >> -- >> /** >> * Alessandro Angeli >> * >> * MVP::DigitalMedia >> * >> * a dot angeli at biosys dot net >> */ >> . -- /** * Alessandro Angeli * * MVP::DigitalMedia * * a dot angeli at biosys dot net */ Reply Joe Flynn Dec 28 2003, 9:20 am show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author Date: Sun, 28 Dec 2003 09:18:04 -0800 Local: Sun, Dec 28 2003 9:18 am Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Alessandro Thanks for your guidance about manually analyzing the Elemental Stream samples returned by the SampleGrabber. Once I started doing that I had no problem determining the correct MPEG frame type for each of the video frames. One thing I did learn is that from the Splitter's perspective a "sample" is a video packet (0x000001E0) and not a video frame so there are considerably more "samples" than there are frames. In retrospect this makes perfect sense. Now the only problem I have to solve is why the sample times returned for some of my I-frames occasionally appear to be off by a couple of frames whenever I encode using B- frames. Joe Flynn - Hide quoted text - - Show quoted text - >-----Original Message----- >If you place the grabber between the splitter and the >decoder, it will provide you with the samples the decoder >receives, which should be the single video ES pictures, >including GOP and sequence headers. Most likely, the >splitter will provide a sample for each picture in the >stream, but the actual picture header may not start at >offset 0 in the sample if it's preceeded but any sequence, >GOP or extension header. In this case, just hunt for the >picture_start_code in the sample (0x00000100) and then look >at the value of the picture_coding_type bitfield (3 bits >after 10 bits following the start code; 1 = I, 2 = P, 3 = >B). >Joe Flynn wrote: >> With MPEG files I am already doing most of the real "work " >> outside of DirectShow - that is how I am sure of the >> correct I,B, and P frame content of my test file. As you >> mentioned parsing the MPEG file for I-frames is fairly >> easy - it is just that DirectShow provided a really nice >> framework for video preview and other than its quirks >> regarding keyframe detection meets my needs quite well - >> plus I was already using it to handle my AVI files so I >> guess I was trying to be lazy. I am interested in your >> suggestion regarding analyzing the samples delivered by >> the SampleGrabber though - do you know offhand if the >> samples that it delivers contain the raw Elemental Stream >> content of the source? I appreciate the advice. >> Joe Flynn >>> -----Original Message----- >>> Joe Flynn wrote: >>>> Even though the SampleGrabber was positioned after the >>>> decoder when this graph was run it indicated that 100% >>>> of the MPEG samples were keyframes (but as you >>>> mentioned it was using the standard DShow components). >>>> This method of detection also gave me some erroneous >>>> results with the DIVX and Cinepak AVI file types so I >>>> moved away from using the IMediaDet method and just >>>> manually constructed my own graph that excluded the >>>> decoder component. >>> After the decoder, I would expect that every sample is a >>> sync point, since there is no temporal compression >>> anymore. >>>> If anyone has an idea please let me know. Thanks >>> I don't know what you are doing but, as long as you only >>> need to scan a system or video stream for the keyframe >>> flags, you could drop DirectShow, at least in the MPEG1/2 >>> case (but also with AVIs), and write your own scanner, >>> which would be a lot faster, 100% reliable and not >>> system-dependent. Parsing an MPEG system or video stream >>> hunting for I-frames requires half a page of code. You >>> could also write your own sniffing filter in place of the >>> SampleGrabber to insert right after the splitter or you >>> could look at the actual video samples the grabber gives >>> you to determine whether they contain an I-frame or not. >>> If you're not familiar with MPEG, I can tell you what to >>> look for. >>> -- >>> /** >>> * Alessandro Angeli >>> * >>> * MVP::DigitalMedia >>> * >>> * a dot angeli at biosys dot net >>> */ >>> . >-- >/** > * Alessandro Angeli > * > * MVP::DigitalMedia > * > * a dot angeli at biosys dot net > */ >. Reply Alessandro Angeli [MVP::DigitalMedia] Dec 28 2003, 11:00 am show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.net> - Find messages by this author Date: Sun, 28 Dec 2003 19:56:23 +0100 Local: Sun, Dec 28 2003 10:56 am Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Joe Flynn wrote: > the only problem I have to solve is why the sample times > returned for some of my I-frames occasionally appear to be > off by a couple of frames whenever I encode using B- > frames. Maybe I'm saying something stupid here since I'm too lazy to go check ;) If you have a GOP like the following: I[BB]P[BB] I... It should be delivered as IP[BB]I[BB] ... because of the backward prediction dependency of the last B-frames on the sequent I-frame. So in this scenario, because of frame reordering, you end up getting the I-frame in advance of 2 B-frames. -- /** * Alessandro Angeli * * MVP::DigitalMedia * * a dot angeli at biosys dot net */ Reply Joe Flynn Dec 28 2003, 4:31 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author Date: Sun, 28 Dec 2003 16:28:13 -0800 Local: Sun, Dec 28 2003 4:28 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Alessandro You are exactly right about the B-frame reordering sequence. I thought that this issue might be the cause of the problem so I spent quite a bit of time last night staring at the ISO 11172 spec. The only thing that bothered me though was that it didn't occur on every keyframe like you would expect if reordering was the cause. Only about 20% of my detected keyframes were "off" and every time the error was exactly 4 frames low - for instance the sample time returned for a particular erroneous I-frame put it at frame position #1219 however the correct sample time for that I-frame would have put it at frame #1223. I think the problem has something to do with a situation where there are two pictures (0x00000100) in the same video packet (0x000001E0). It seems that every time this error occurs the target I-frame is the second picture in the video packet. Since the SampleGrabber seems to consider a "sample" to be a video packet the same sample time ( via IMediaSample::GetTime() ) is returned for both picture fields. My guess is that the sample time is correct for the first picture entry but is wrong for the second entry. Which brings up the question of how does the decoder determine the correct presentation time for each of the picture fields in this instance? The PTS/DTS time stamps are located in the header for the video packet and I assume they only apply to one of the picture entries - which one? If a picture entry doesn't have a dedicated PTS/DTS stamp does the decoder simply "estimate" the correct presentation time based on frame rate etc? It seems like the farther I go with this the less I really know!! Joe Flynn - Hide quoted text - - Show quoted text - >-----Original Message----- >Joe Flynn wrote: >> the only problem I have to solve is why the sample times >> returned for some of my I-frames occasionally appear to be >> off by a couple of frames whenever I encode using B- >> frames. >Maybe I'm saying something stupid here since I'm too lazy to >go check ;) >If you have a GOP like the following: >I[BB]P[BB] I... >It should be delivered as >IP[BB]I[BB] ... >because of the backward prediction dependency of the last >B-frames on the sequent I-frame. So in this scenario, >because of frame reordering, you end up getting the I- frame >in advance of 2 B-frames. >-- >/** > * Alessandro Angeli > * > * MVP::DigitalMedia > * > * a dot angeli at biosys dot net > */ >. Reply Yan-Hong Huang[MSFT] Dec 28 2003, 5:43 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: yhhu...@online.microsoft.com (Yan-Hong Huang[MSFT]) - Find messages by this author Date: Mon, 29 Dec 2003 01:40:41 GMT Local: Sun, Dec 28 2003 5:40 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Hi Joe, Sorry for the late response. Most of engineers are in holidays. So the reply may need some more time. But please rest assure that we are monitoring it and will reply here as soon as possible. Thanks very much for your patience. Best regards, Yanhong Huang Microsoft Community Support Get Secure! 每 www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights . Reply Alessandro Angeli [MVP::DigitalMedia] Dec 28 2003, 6:04 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.net> - Find messages by this author Date: Mon, 29 Dec 2003 03:03:58 +0100 Local: Sun, Dec 28 2003 6:03 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse You're reaching the bottom of my knowledge on this matter... There are no timestamps in the video ES. Nonetheless, you can successfully decode the ES with the same set of filters. So I guess the video decoder does not need the timestamps in the system stream, but relies on the constant frame rate and the picture count in the GOP (temporal_reference) and most likely also makes use of the vbv_delay field. Actually, the GOP header includes a time_code field, but it is unclear to me whether it is of any use in MPEG1 (MPEG2 clearly states that "The information carried by time_code plays no part in the decoding process."). So, I suppose the decoder pays no attention to the media sample's timestamp except perhaps as time base. You could try to demux the video ES to a file and then see how the graph behaves. Joe Flynn wrote: - Hide quoted text - - Show quoted text - > Alessandro > You are exactly right about the B-frame reordering > sequence. I thought that this issue might be the cause of > the problem so I spent quite a bit of time last night > staring at the ISO 11172 spec. The only thing that > bothered me though was that it didn't occur on every > keyframe like you would expect if reordering was the > cause. Only about 20% of my detected keyframes were "off" > and every time the error was exactly 4 frames low - for > instance the sample time returned for a particular > erroneous I-frame put it at frame position #1219 however > the correct sample time for that I-frame would have put it > at frame #1223. > I think the problem has something to do with a situation > where there are two pictures (0x00000100) in the same > video packet (0x000001E0). It seems that every time this > error occurs the target I-frame is the second picture in > the video packet. Since the SampleGrabber seems to > consider a "sample" to be a video packet the same sample > time ( via IMediaSample::GetTime() ) is returned for both > picture fields. My guess is that the sample time is > correct for the first picture entry but is wrong for the > second entry. Which brings up the question of how does the > decoder determine the correct presentation time for each > of the picture fields in this instance? The PTS/DTS time > stamps are located in the header for the video packet and > I assume they only apply to one of the picture entries - > which one? If a picture entry doesn't have a dedicated > PTS/DTS stamp does the decoder simply "estimate" the > correct presentation time based on frame rate etc? > It seems like the farther I go with this the less I really > know!! > Joe Flynn >> -----Original Message----- >> Joe Flynn wrote: >>> the only problem I have to solve is why the sample times >>> returned for some of my I-frames occasionally appear to >>> be off by a couple of frames whenever I encode using B- >>> frames. >> Maybe I'm saying something stupid here since I'm too >> lazy to go check ;) >> If you have a GOP like the following: >> I[BB]P[BB] I... >> It should be delivered as >> IP[BB]I[BB] ... >> because of the backward prediction dependency of the last >> B-frames on the sequent I-frame. So in this scenario, >> because of frame reordering, you end up getting the I- >> frame in advance of 2 B-frames. >> -- >> /** >> * Alessandro Angeli >> * >> * MVP::DigitalMedia >> * >> * a dot angeli at biosys dot net >> */ >> . -- Reply Joe Flynn Dec 28 2003, 8:42 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author Date: Sun, 28 Dec 2003 20:40:06 -0800 Local: Sun, Dec 28 2003 8:40 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse I did confirm that in a situation where there are multiple picture entries (0x00000100) in the same video packet (0x000001E0) the sample time returned by IMediaSample::GetTime() is only valid for the first picture entry in the packet. However, I think you hit on a possible work-around by using the temporal reference of the pictures. If I have a picture that I can't get a valid sample time for I can just scan the pictures with temporal references adjacent to this frame. Assuming that I can get a valid sample time for one of these pictures I can then just derive the correct sample time for my desired frame using the frame rate value. I really wish the IsSyncPoint() call had worked properly for MPEGs. Of course it is really going to be frustrating if one of the Microsoft guys comes back and gives me a one- line solution to this whole mess... I appreciate all of your help. Thanks. Joe Flynn - Hide quoted text - - Show quoted text - >-----Original Message----- >You're reaching the bottom of my knowledge on this matter... >There are no timestamps in the video ES. Nonetheless, you >can successfully decode the ES with the same set of filters. >So I guess the video decoder does not need the timestamps in >the system stream, but relies on the constant frame rate and >the picture count in the GOP (temporal_reference) and most >likely also makes use of the vbv_delay field. Actually, the >GOP header includes a time_code field, but it is unclear to >me whether it is of any use in MPEG1 (MPEG2 clearly states >that "The information carried by time_code plays no part in >the decoding process."). So, I suppose the decoder pays no >attention to the media sample's timestamp except perhaps as >time base. >You could try to demux the video ES to a file and then see >how the graph behaves. >Joe Flynn wrote: >> Alessandro >> You are exactly right about the B-frame reordering >> sequence. I thought that this issue might be the cause of >> the problem so I spent quite a bit of time last night >> staring at the ISO 11172 spec. The only thing that >> bothered me though was that it didn't occur on every >> keyframe like you would expect if reordering was the >> cause. Only about 20% of my detected keyframes were "off" >> and every time the error was exactly 4 frames low - for >> instance the sample time returned for a particular >> erroneous I-frame put it at frame position #1219 however >> the correct sample time for that I-frame would have put it >> at frame #1223. >> I think the problem has something to do with a situation >> where there are two pictures (0x00000100) in the same >> video packet (0x000001E0). It seems that every time this >> error occurs the target I-frame is the second picture in >> the video packet. Since the SampleGrabber seems to >> consider a "sample" to be a video packet the same sample >> time ( via IMediaSample::GetTime() ) is returned for both >> picture fields. My guess is that the sample time is >> correct for the first picture entry but is wrong for the >> second entry. Which brings up the question of how does the >> decoder determine the correct presentation time for each >> of the picture fields in this instance? The PTS/DTS time >> stamps are located in the header for the video packet and >> I assume they only apply to one of the picture entries - >> which one? If a picture entry doesn't have a dedicated >> PTS/DTS stamp does the decoder simply "estimate" the >> correct presentation time based on frame rate etc? >> It seems like the farther I go with this the less I really >> know!! >> Joe Flynn >>> -----Original Message----- >>> Joe Flynn wrote: >>>> the only problem I have to solve is why the sample times >>>> returned for some of my I-frames occasionally appear to >>>> be off by a couple of frames whenever I encode using B- >>>> frames. >>> Maybe I'm saying something stupid here since I'm too >>> lazy to go check ;) >>> If you have a GOP like the following: >>> I[BB]P[BB] I... >>> It should be delivered as >>> IP[BB]I[BB] ... >>> because of the backward prediction dependency of the last >>> B-frames on the sequent I-frame. So in this scenario, >>> because of frame reordering, you end up getting the I- >>> frame in advance of 2 B-frames. >>> -- >>> /** >>> * Alessandro Angeli >>> * >>> * MVP::DigitalMedia >>> * >>> * a dot angeli at biosys dot net >>> */ >>> . >-- >. Reply Sameer Murudkar Jan 5 2004, 3:55 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: email7-nos...@microsoft.com (Sameer Murudkar) - Find messages by this author Date: Mon, 05 Jan 2004 23:53:43 GMT Local: Mon, Jan 5 2004 3:53 pm Subject: RE: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Hi, There is no one to one correspondence between the samples output by the MPEG splitter and the decoder. If it were the case then the number of sample going into the decoder and coming out of the decoder would be the same. However, this is not the case as the splitter output (MPEG1 Payload) does not correspond to a single frame; a sample can contain information for a partial frame. This is the reason you are seeing more sync points at the output of the splitter than you expect. You can confirm this be creating the following two graphs. You need to add code to the Sample Grabber to count the number of sync points. 1. File Source--->MPEG Splitter--->Sample Grabber'Null Renderer. 2. File Source--->MPEG Splitter-->Video Decoder---> Sample Grabber'Null Renderer. In the second case the count will be number of actual frames. In the first case the count is samples output by the splitter with the sync point flag set. This does not necessarily mean I-frames; in fact they will be significantly more than the actual I-frames. The MPEG decoder combines partial frames and treats them as a single frame, decodes the frame and outputs the un-compressed frame to the renderer. All un-compressed frames are sync points. In short, calling IsSyncPoint to determine if a frame is an I-frame is not appropriate. You need to use the MPEG specification or some third party SDK to get these frame (I.B, P) counts. There is a third party tool called Virtual Dub http://www.virtualdub.org/ that you can use to get information on I, B and P frames. Thanks, Sameer Microsoft Developer Support This posting is provided "AS IS" with no warranties, and confers no rights . Reply Yan-Hong Huang[MSFT] Jan 5 2004, 5:59 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: yhhu...@online.microsoft.com (Yan-Hong Huang[MSFT]) - Find messages by this author Date: Tue, 06 Jan 2004 01:58:32 GMT Local: Mon, Jan 5 2004 5:58 pm Subject: RE: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Hello Joe, Our colleague Sameer replied with more informaiton at another duplicated post. I copied the content here for your reference. If you have any more concerns on it, please post there and we will follow up it. Thanks very much. ----------------- - Hide quoted text - - Show quoted text - Hi, There is no one to one correspondence between the samples output by the MPEG splitter and the decoder. If it were the case then the number of sample going into the decoder and coming out of the decoder would be the same. However, this is not the case as the splitter output (MPEG1 Payload) does not correspond to a single frame; a sample can contain information for a partial frame. This is the reason you are seeing more sync points at the output of the splitter than you expect. You can confirm this be creating the following two graphs. You need to add code to the Sample Grabber to count the number of sync points. 1. File Source--->MPEG Splitter--->Sample Grabber'Null Renderer. 2. File Source--->MPEG Splitter-->Video Decoder---> Sample Grabber'Null Renderer. In the second case the count will be number of actual frames. In the first case the count is samples output by the splitter with the sync point flag set. This does not necessarily mean I-frames; in fact they will be significantly more than the actual I-frames. The MPEG decoder combines partial frames and treats them as a single frame, decodes the frame and outputs the un-compressed frame to the renderer. All un-compressed frames are sync points. In short, calling IsSyncPoint to determine if a frame is an I-frame is not appropriate. You need to use the MPEG specification or some third party SDK to get these frame (I.B, P) counts. There is a third party tool called Virtual Dub http://www.virtualdub.org/ that you can use to get information on I, B and P frames. Thanks, Sameer Microsoft Developer Support This posting is provided "AS IS" with no warranties, and confers no rights . ---------------------- Best regards, Yanhong Huang Microsoft Community Support Get Secure! 每 www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights. Reply Yan-Hong Huang[MSFT] Jan 6 2004, 5:19 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: yhhu...@online.microsoft.com (Yan-Hong Huang[MSFT]) - Find messages by this author Date: Wed, 07 Jan 2004 01:15:35 GMT Local: Tues, Jan 6 2004 5:15 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Hello Joe, Thanks very much for your patience. Does Sameer's reply answer your question? If you have any more concerns on it, please feel free to post here. I will closely monitor this issue thread. Best regards, Yanhong Huang Microsoft Community Support Get Secure! 每 www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights . Reply Joe Flynn Jan 7 2004, 10:43 am show options Newsgroups: microsoft.public.win32.programmer.directx.video From: "Joe Flynn" <joseph.fl...@nospam.com> - Find messages by this author Date: Wed, 7 Jan 2004 10:41:44 -0800 Local: Wed, Jan 7 2004 10:41 am Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Yanhong Yes, Sameer's response explains the results that I was seeing. Also with the assistance of some of the other post's on this thread - particularly Allessandro's - I was able to develop a solution to properly detect MPEG keyframes so the problems that prompted my initial question are no longer an issue. Thank you very much for your assistance. Joe Flynn - Hide quoted text - - Show quoted text - >-----Original Message----- >Hello Joe, >Thanks very much for your patience. >Does Sameer's reply answer your question? If you have any more concerns on >it, please feel free to post here. I will closely monitor this issue thread. >Best regards, >Yanhong Huang >Microsoft Community Support >Get Secure! 每 www.microsoft.com/security >This posting is provided "AS IS" with no warranties, and confers no rights . - Hide quoted text - - Show quoted text - >. Reply Yan-Hong Huang[MSFT] Jan 7 2004, 5:37 pm show options Newsgroups: microsoft.public.win32.programmer.directx.video From: yhhu...@online.microsoft.com (Yan-Hong Huang[MSFT]) - Find messages by this author Date: Thu, 08 Jan 2004 01:36:38 GMT Local: Wed, Jan 7 2004 5:36 pm Subject: Re: DirectShow MPEG-1 keyframe detection Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse Hi Joe, You are welcome. Thanks very much for your feedback. If there are any more questions, please feel free to post in the group. BTW, you can go to http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nos... &SD=msdn to register a no spam email alias and use it in the community. So we can send you a notification email when there is any update on the issue in the newsgroup. Thanks again for participating the community. Best regards, Yanhong Huang Microsoft Community Support Get Secure! 每 www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights
- Next message: Alessandro Angeli [MVP::DigitalMedia]: "Re: DirectShow MPEG-1 keyframe detection"
- Previous message: DVBPortal: "Re: Windows Media Player 10 does not seek with custom source filter in push mode"
- Next in thread: Alessandro Angeli [MVP::DigitalMedia]: "Re: DirectShow MPEG-1 keyframe detection"
- Reply: Alessandro Angeli [MVP::DigitalMedia]: "Re: DirectShow MPEG-1 keyframe detection"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
