View Full Version : DirectShowSource and M2V problem.....
DrPhill
25th January 2012, 17:05
I am sorry if this is a common problem, can someone please point me to a solution? I am not even sure what to search the forums for.
I am using HCGui to create a m2v file. When I try to read it with DirectShowSource I get a complaint:
DirectShowSource: RenderFile, the filter graph manager won't talk to me
The m2v file plays fine in other media players......
Taurus
25th January 2012, 18:45
Works fine here.
WinXp32bit ->Avisynth Script -> Directshowsource("test.m2v") ->
mpeg2splitter -> ffdshow -> Media Player Classic HC.
Why you want the m2v decoded by directshowsource?
Mpeg2source or ffvideosource shoud be more suitable for avisynth..
DrPhill
25th January 2012, 19:25
Works fine here.
WinXp32bit ->Avisynth Script -> Directshowsource("test.m2v") ->
mpeg2splitter -> ffdshow -> Media Player Classic HC.
Why you want the m2v decoded by directshowsource?
Mpeg2source or ffvideosource shoud be more suitable for avisynth..
Thanks Taurus, that is the sort of pointer I need. I used DirectShowSource as it was the only appropriate looking internal filter.
I am running windoze 64 bit - that may be part of the problem.
I will hunt down one of those two plugins.
Phill
Emulgator
25th January 2012, 19:31
Win7 Directshow/MediaFoundation is more complicated to control than WinXP:
I suggest to get Win7 Preferred Filter Tweaker and control decoder preferences from there.
http://www.codecguide.com/windows7_preferred_filter_tweaker.htm
DrPhill
25th January 2012, 20:23
'Oh no' I feel that I am getting a bit lost and sidetracked here.
Is the two step DGIndex/DGDecode really the simplest way to go? Especially when I cannot see how to get round the fact that the output is no longer on one plane.
All I want to do is load a clip (mpg to mpg using AVISynth). Maybe I should not be using HCEncode?
I am happy to work in mpg (my data files are mpg) so how do I convert avs --> mpg (preferably for free)?
And I apologise if I sound like a gormless newbie - but there is a reason for that! (yes the obvious reason)
Phill
Emulgator
25th January 2012, 20:56
Heads up, HC works beautifully. Just do the Two Step ;-)
(I do the same for every H.262/MPEG-2 and H.264/MPEG-4 source on almost daily basis.)
DGIndex/DGDecode is the perfect sourcefilter for frameserving, is free,
and a frameserver is what a decent encoder (HC, x264) needs as a frontend.
DrPhill
25th January 2012, 22:30
Heads up, HC works beautifully. Just do the Two Step ;-)
(I do the same for every H.262/MPEG-2 and H.264/MPEG-4 source on almost daily basis.)
DGIndex/DGDecode is the perfect sourcefilter for frameserving, is free,
and a frameserver is what a decent encoder (HC, x264) needs as a frontend.
OK I will keep trying. How do I reduce the clip to one plane? Remember I am still blundering around in the gloom, so make it simple, please.......
Thanks,
Phill
Guest
25th January 2012, 22:32
How do I reduce the clip to one plane? That makes no sense. What are you talking about?
DrPhill
26th January 2012, 10:23
That makes no sense. What are you talking about?
oooooops. The error message is issued by my code, but I have no idea what it means..... I inherited it from the example code that I started with. Maybe I could remove it and all would work fine, but the only time I have seen it is when dealing with the output from DG stuff.
The code that issues the error:
AVS_Clip * new_clip = avs_new_c_filter(env, &fi, avs_array_elt(args, 0), 1);
if (avs_is_planar(&fi->vi)) {
v = avs_new_value_error("Video must be on a single plane");
}
...........
return v;
Any clues to what this means, whether it is important, or how to get round it would be welcome. I will have an experiment later to see if it is protecting me from something I that would mess up my algorithm.
Thanks
Phill
Gavino
26th January 2012, 10:51
Basically, it means your filter does not support planar input formats.
http://avisynth.org/mediawiki/Planar
So, for example it does not support YV12.
A YV12 source (eg from a DVD) must be converted in the script (to RGB probably, depending on what the rest of your code supports) before calling your filter.
DrPhill
26th January 2012, 10:58
Basically, it means your filter only supports planar input formats.
http://avisynth.org/mediawiki/Planar
So, for example it does not support RGB24, RGB32 or YUY2.
A source in those formats must be converted (eg to YV12) in the script before calling your filter.
That makes sense except that I am treating my video data as RGB32. Perhaps it means that I only support non-planar formats?
So the problem with the clips I am getting from my DGDecode is that it is not the right format? Well that can be solved easily enough........ So simple that I am embarrassed. I will give that a try later.
Thanks Gavino, sometimes I need a kick.
Gavino
26th January 2012, 11:05
That makes sense except that I am treating my video data as RGB32. Perhaps it means that I only support non-planar formats?
Yes, I had my post the wrong way round at first.
I quickly corrected it, but I wasn't quick enough before you read it. :)
Taurus
26th January 2012, 11:26
Show us your workflow.
Your avisynth script.
And /or a snippet of a source file.
HCenc is supporting only YV12 and YUY2 input for 4:2:0 chroma output format.
And only YUY2 input for 4:2:2 chroma output format.
Make sure your script stays in one of the formats.
Mpeg2 indexed with DGIndex normally is in YV12.
So as a test just load your source with:
mpeg2source("test.d2v") -> HCenc.
Another test:
Feed the test.d2v directly -> HCenc.
Yes, HCenc can open d2v's :D
DrPhill
26th January 2012, 11:40
Show us your workflow.
Your avisynth script.
And /or a snippet of a source file.
HCenc is supporting only YV12 and YUY2 input for 4:2:0 chroma output format.
And only YUY2 input for 4:2:2 chroma output format.
Make sure your script stays in one of the formats.
Mpeg2 indexed with DGIndex normally is in YV12.
So as a test just load your source with:
mpeg2source("test.d2v") -> HCenc.
Another test:
Feed the test.d2v directly -> HCenc.
Yes, HCenc can open d2v's :D
I start with mpg from my camera, and read it into a script where I handle it as RGB32.
I use RGB32 as I can understand the memory layout for this.
I want to store my intermediate results as video data to save processing time later.
HCEncoder was recommended as a good encoder at a good price.
In order to use HCEncoder I convert the output from my script to YUY2 (convertToYuY2()).
HCEncoder gives me an m2v file as an output.
When I want to manipulate my intermediate results I need to read them into AVISynth.
DirectShowSource() does not like the m2v. (This may mean I have to configure DirectShow by messing with the register or something, but that worries me because it is another step to remember if I ever have to set my machine up again)
I use DGIndex/DGDecode to create a d2v file, which I can read in, but my code detects that it is 'planar' and complains.
I am sure that this is more complicated than it need be - and that my blundering ignorance is causing the complexity, but I do not really understand the world of video formats etc. I am attempting to achieve a task, and learning as I go.
Gavino
26th January 2012, 11:56
If you don't want to extend your filter to handle YV12, just call ConvertToRGB32() in your script before calling the filter (and ConvertToYV12() after if you want to pass the output on to HCEnc).
DrPhill
26th January 2012, 12:06
If you don't want to extend your filter to handle YV12, just call ConvertToRGB32() in your script before calling the filter (and ConvertToYV12() after if you want to pass the output on to HCEnc).
OK, will do. I can understand that.
Is YV12 a good general-purpose format? I can read up on it and make the filter work with it if it is worth the effort. I would have to learn the memory format of the data first.
Thank you for your help - it is easing my learning curve and problem mountain very effectively.
librarian
26th January 2012, 13:33
As usual Gavino's responses are right and accurate.
This is the script I used to try your filter, with no troubles:
Load_Stdcall_Plugin("Watermark.dll")
# Pixel type must be RGB32
# Watermark must be same size as video.
# Watermark only needs one frame
# Watermark should be black (for mark) and white (for background)
myVideo = mpeg2Source("D9-Sample_11012012.d2v").converttorgb32()
myVideo = Trim(myVideo, 0, 57)
myVideo = BilinearResize(myVideo, 640, 480)
myWatermark = ImageSource("ExampleText.jpg", end = 10, pixel_type = "RGB32")
myWatermark = BilinearResize(myWatermark, 640, 480)
return Watermark(myVideo, watermark = myWatermark, displace = 10, light = 3, depth = 10)
Since your filter is quite peculiar, it will be, probably, the one or the last used in the filter chain. IMO there is no need to worry about different colourspaces. Much more simply the user can add the necessary conversion.
DrPhill
26th January 2012, 13:41
As usual Gavino's responses are right and accurate.
I have not been around this forum long, but that is becoming obvious.
I am glad that I do not need to worry about YV12 and such - the format looks a little daunting. And the fact that my filter is designed to be the last (or close to last) used helps excuse me from learning other colour-space formats.
As always I am grateful for the patience of and the help from those who know far more than I.
Phill
Guest
26th January 2012, 16:34
YV12 is not difficult to handle. One might argue it is easier than RGB.
You will force unnecessary color space conversions with your limitation, degrading quality somewhat, if the final target is MPEG2 in YV12 (4:2:0).
Filters don't support YV12 just for fun. :)
DrPhill
26th January 2012, 16:43
YV12 is not difficult to handle. One might argue it is easier than RGB.
You will force unnecessary color space conversions with your limitation, degrading quality somewhat, if the final target is MPEG2 in YV12 (4:2:0).
Filters don't support YV12 just for fun. :)
I did ponder the degradation of multiple conversions, but my original idea for the watermark was a last step before YouTube so that I could deter 'reuse'. A small degradation would not matter under that scenario.
However, your point is valid, and I may have to consider learning to handle YV12. It is just not highest on my list at present (too many exciting possibilities have just opened up by making my watermark dynamic). Any references to memory layout would help.
Thanks Phill
Gavino
26th January 2012, 17:11
Any references to memory layout would help.
http://avisynth.org/mediawiki/Filter_SDK/Working_with_images
http://avisynth.org/mediawiki/Filter_SDK/Data_storage
http://avisynth.org/mediawiki/Color_spaces
DrPhill
26th January 2012, 17:22
http://avisynth.org/mediawiki/Filter_SDK/Working_with_images
http://avisynth.org/mediawiki/Filter_SDK/Data_storage
http://avisynth.org/mediawiki/Color_spaces
Thanks, Gavino. That stuff looks a bit complex for a simpleton like me - I think I will stick to RGB32 for the present. I can understand the theory, follow the maps, but I am also sure I can louse up the code big-time.
Guest
26th January 2012, 18:15
There are lots of YV12-capable filters with source code available. You don't have to re-invent the wheel.
You can look here:
http://forum.doom9.org/showthread.php?t=48261
Be sure to grab the latest version from late in the thread.
Or you can look at source at my web page, and the pages of other filter developers.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.