I am using wmp in my windows application. I want to change the rate of the play speed.
It is possible for some type of files e.g; avi. But its not possible for some types, eg; wmv,mpeg etc. Is there any other way to change rate. Please, its urgent. Thanx in advance
Its possible, but your choice of using windows media player will limit your choices. Windows media player uses a very simple graphfilter to control playback. This will make it impossible to change the rate for formats which require more complex filters. The general way to change the rate is to either repeat or drop frames in the video.
I am not sure about wmv, but if memory serves me right, wmv is just a container format like AVI, so the graphfilter that is used varies from file to file.
mpeg has 3 kinds of frames. only the i frame is complete. the p and b frames are not so you cant really repeat or drop the frames easily.
Dont know how to help you with this, but you will have better choices if your using directshow so that you can change graphfilters to duplicate/drop frames.
Related
Normally seek commands are executed on a filter graph, get called on the renderers in the graph and calls are passed upstream by filters until a filter that can handle the seek does the actual seek operation.
Could an individual filter seek the upstream filters connected to one or more of its input pins in the same way without it affecting the downstream portion of the graph in unexpected ways? I wouldn't expect that there wouldn't be any graph state changes caused by calling IMediaSeeking.SetPositions upstream.
I'm assuming that all upstream filters are connected to the rest of the graph via this filter only.
Obviously the filter would need to be prepared to handle the resulting BeginFlush, EndFlush and NewSegment calls coming from upstream appropriately and distinguish samples that arrived before and after the seek operation. It would also need to set new sample times on its output samples so that the output samples had consistent sample presentation times. Any other issues?
It is perfectly feasible to do what you require. I used this approach to build video and audio mixer filters for a video editor. A full description of the code is available from the BBC White Papers 129 and 138 available from http://www.bbc.co.uk/rd
A rather ancient version of the code can be found on www.SourceForge.net if you search for AAFEditPack. The code is written in Delphi using DSPack to get access to the DirectShow headers. I did this because it makes it easier to handle com object lifetimes - by implementing smart pointers by default. It should be fairly straightforward to transfer the ideas to a C++ implementation if that is what you use.
The filters keep lists of the sub-graphs (a section of a graph but running in the same FilterGraph as the mixers). The filters implement a custom version of TBCPosPassThru which knows about the output pins of the sub-graph for each media clip. It handles passing on the seek commands to get each clip ready for replay when its point in the timeline is reached. The mixers handle the BeginFlush, EndFlush, NewSegment and EndOfStream calls for each sub-graph so they are kept happy. The editor uses only one FilterGraph that houses both video and audio graphs. Seeking commands are make by the graph on both the video and audio renderers and these commands are passed upstream to the mixers which implement them.
Sub-graphs that are not currently active are blocked by the mixer holding references to the samples they have delivered. This does not cause any problems for the FilterGraph because, as Roman R says, downstream filters only care about getting a consecutive stream of sample and do not know about what happens upstream.
Some key points you need to make sure of to avoid wasted debugging time are:
Your decoder filters need to be able to queue to the exact media frame or audio time. Not as easy to do as you might expect, especially with compressed formats such as mpeg2, which was designed for transmission and has no frame index in the files. If you do not do this, the filter may wait indefinitely to get a NewSegment call with the correct media times.
Your sub graphs need to present a NewSegment time equal to the value you asked for in your seek command before delivering samples. Some decoders may seek to the nearest key frame, which is a bit unhelpful and some are a bit arbitrary about the timings of their NewSegment and the following samples.
The start and stop times of each clip need to be within the duration of the file. Its probably not a good idea to police this in the DirectShow filter because you would probably want to construct a timeline without needing to run the filter first. I did this in the component that manages the FilterGraph.
If you want to add sections from the same source file consecutively in the timeline, and have effects that span the transition, you need to have two instances of the sub-graph for that file and if you have more than one transition for the same source file, your list needs to alternate the graphs for successive clips. This is because each sub graph should only play monotonically: calling lots of SetPosition calls would waste cpu cycles and would not work well with compressed files.
The filter's output pins define the entire seeking behaviour of the graph. The output sample time stamps (IMediaSample.SetTime) are implemented by the filter so you need to get them correct without any missing time stamps. and you can also set the MediaTime (IMediaSample.SetMediaTime) values if you like, although you have to be careful to get them correct or the graph may drop samples or stall.
Good luck with your development. If you need any more information please contact me through StackOverflow or DTSMedia.co.uk
I was using a callback mechanism to grab the webcam frames in my media application. It worked, but was slow due to certain additional buffer functions that were performed within the callback itself.
Now I am trying the other way to get frames. That is, call a method and grab the frame (instead of callback). I used a sample in CodeProject which makes use of IVMRWindowlessControl9::GetCurrentImage.
I encountered the following issues.
In a Microsoft webcam, the Preview didn't render (only black screen) on Windows 7. But the same camera rendered Preview on XP.
Here my doubt is, will the VMR specific functionalities be dependent on camera drivers on different platforms? Otherwise, how could this difference happen?
Wherever the sample application worked, I observed that the biBitCount member of the resulting BITMAPINFOHEADER structure is 32.
Is this a value set by application or a driver setting for VMR operations? How is this configured?
Finally, which is the best method to grab the webcam frames? A callback approach? Or a Direct approach?
Thanks in advance,
IVMRWindowlessControl9::GetCurrentImage is intended for occasional snapshots, not for regular image grabbing.
Quote from MSDN:
This method can be called at any time, no matter what state the filter
is in, whether running, stopped or paused. However, frequent calls to
this method will degrade video playback performance.
This methods reads back from video memory which is slow in first place. This methods does conversion (that is, slow again) to RGB color space because this format is most suitable for for non-streaming apps and gives less compatibility issues.
All in all, you can use it for periodic image grabbing, however this is not what you are supposed to do. To capture at streaming rate you need you use a filter in the pipeline, or Sample Grabber with callback.
I'm using two custom push filters to inject audio and video (uncompressed RGB) into a DirectShow graph. I'm making a video capture application, so I'd like to encode the frames as they come in and store them in a file.
Up until now, I've used the ASF Writer to encode the input to a WMV file, but it appears the renderer is too slow to process high resolution input (such as 1920x1200x32). At least, FillBuffer() seems to only be able to process around 6-15 FPS, which obviously isn't fast enough.
I've tried increasing the cBuffers count in DecideBufferSize(), but that only pushes the problem to a later point, of course.
What are my options to speed up the process? What's the right way to do live high res encoding via DirectShow? I eventually want to end up with a WMV video, but maybe that has to be a post-processing step.
You have great answers posted here to your question: High resolution capture and encoding too slow. The task is too complex for the CPU in your system, which is just not fast enough to perform realtime video encoding in the configuration you set it to work.
What exactly does the scan media features values progressive and interlace do exactly in simple terms? And are these the only values available for the scan feature?
They have to do with the output method of the screen of the device.
Describes the scanning process of television output devices.
Source.
progressive and interlace are the only two possible values.
Progressive Scan
Progressive (or noninterlaced scanning) is a way of displaying, storing, or transmitting moving images in which all the lines of each frame are drawn in sequence.
Source.
Interlaced Scan
Interlaced video is a technique of doubling the perceived frame rate of a video signal without consuming extra bandwidth. Since the interlaced signal contains the two fields of a video frame shot at two different times, it enhances motion perception to the viewer and reduces flicker by taking advantage of the persistence of vision effect.
Source.
It is used in style sheets for television. More info (book excerpt) here. If Interlaced and progressive videos interest you in some way, you can read about it here.
I got a CD from the hospital that is a head CD scan.
I am completely new to medical imaging. What I would like to do perform a volume rendering of the CT scan.
It is in DICOMDIR format. How and where would I start?
From messing about with various tools I get the feeling that I need to extract each series into DICOM format. Is this correct and if so how would I do it?
Unless you were given the volume data your rendering will be disappointing at best. Many institutions still acquire head CT's in separate "step-slices", and not as volumes so here you will have significant 'stepping' artifact.
Even if it was acquired with volume data, unless they transferred all the data to your CD, you will still be stuck with only the processed 'slab' or 'slice' images.
The best way to do a volume rendering is to actually have the volume data. "Slice image" data has most of the information dumbed down and removed. You are just getting 20 or 30 images in 256 x 256 x (8 or 16 bit greyscale) array data.
If you have a mac try OsiriX - it's free, open source and will do everything you need and more. If you don't, and this is a one time thing, you could always sign up for a free demo of a commercial grade DICOM viewer. Medical image viewing software is insanely expensive and would be impossible to sell without demos. Just claim to be working for a clinician and you'll have no problem getting working software.
I believe ImageJ will open any of the files in the DICOMDIR for you. I'm not entirely sure it can open the entire study from the DICOMDIR, but I'm fairly certain it will handle any individual files you need to open. It should also offer the option to export the images to various other formats. If you need more info, feel free to post a comment.
You can also try MevisLab (http://www.mevislab.de/) it is free but a bit more complex to use and maybe it requires two steps to get the rendering of your dicom images.
Most probably you have to use one of the widgets they provide to convert the image and then to load the converted image and render it.
I have done with ImageJ but ImageJ not support compress dicom files at that time you have create your own logic to read compress dicom file.
Fiji and VolumeJ are also Good Option for Volume Rendering
Try Real3d VolViCon which is an advanced application for reconstruction of computed tomography (CT), magnetic resonance (MR), ultrasound, and x-rays images. It gives features for exporting 3D surfaces or volume as triangular mesh files for creating physical models using 3D printing technologies. It also provides high-quality visualization, linear and angular measurement tools, and various type of markups. It takes a single raw volume file or a sequence of 2D (i.e., DICOM) files and reconstructs 3D volume (voxels) and mesh (surfaces) models.