|
|
| fccHandler |
 Posted: Jan 10 2003, 07:03 AM |
 |
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
First, let me say that I am not trying to compete with jcsston or the VirtualDubMod developers. I've had this code for years and I've finally made a decision to release it into the wild, with the hope that perhaps those developers might benefit from it.
It's an internal upgrade of VirtualDub's MPEG decoder, and only the source code is being made available. DO NOT ask me for a compiled version. (Do it yourself.)
Anyway, you are free to use the code as you wish, modify it all you want, and make it your own. In turn, I absolve myself of any responsibility, and if it doesn't work for you, too bad.
Instructions:
Replace your existing VirtualDub 1.4.13 source files with these:
http://home.attbi.com/~blade66/Mpeg.cpp
http://home.attbi.com/~blade66/mpeg_decode.cpp
Rebuild VirtualDub, and you'll be able to open MPEG-2 content directly.
AC3 support is disabled in this version. If there is any interest, I can tell you what you need to do to enable it.
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Jan 10 2003, 08:38 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Oww... that bit read function is painful. You should be able to use something like this:
| QUOTE |
static long __declspec(naked) __fastcall show_bits(int bits) {
__asm {
xor eax, eax
or ecx, ecx
jle xit
push ecx
mov eax, bitpos
mov ecx, eax
and ecx, 7
shr eax, 3
mov edx, bitarray
mov edx, [eax+edx]
xor eax, eax
bswap edx
shl edx, cl
pop ecx
shld eax, edx, cl
xit:
ret
}
}
|
Routines like this are useful for layer II audio decoding, but not as much for layer III or MPEG video because Huffman decoding needs to hit the bitheap pretty often, and Visual C++ lacks both a bswap intrinsic and decent 64-bit code generation (shld). Intel C/C++ has both, so it might be viable on that compiler.
As for buffer read limiting (totbits), it's easier and faster just to wrap the whole decoder in a __try/__finally block, and take error concealment actions at the end.
|
|
| fccHandler |
| Posted: Jan 10 2003, 10:43 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
@phaeron:
You are literally the last person I expected to comment on this, but I couldn't have asked for a better critic. Thank you for your interest! I admit that the whole module can stand improvement (I'm no master coder). I guess in many ways, it's still a work in progress. But it's functional, and that was my primary goal at the time.
Hmm. Error concealment is easier and faster than error prevention. I did wrap a __try block around the motion compensation code, but never considered it for the bits-getting function...
--------------------
May the FOURCC be with you... |
|
| ChristianHJW |
| Posted: Jan 10 2003, 02:06 PM |
|
|
Advanced Member
Group: Moderators
Posts: 1768
Member No.: 2
Joined: 7-July 02
|
fcchandler !!!
What a surprise, your code. I had no idea you were working on a MPEG2 decoder for Vdub.
Please allow me to beg you about something very important for the future of the matroska container :
Is it possible to mux the MPEG2 into matroska instead of decoding it ? You are certainly aware that we are testing a modified version of VirtualdubMod with an old version of libmcf being statically linked into it. Suiryc made this version in very short time, although a few bugs in the old libmcf were hindering him quite a bit.
I had hopes that pulco-citron, the man who added MPEG2 parsing and decoding to VdubMod, could look into this, but he didnt reply to my posts on the VdubMod mailing lists.
May i beg you about it  ???
The code for VdubMod_MCF can be found on the CVS tree on the project page http://sf.net/projects/virtualdubmod , you will need WinCVS and putty to be able to load it though. If you are interested looking into that you could use the 'annoncvs' function of sourceforge, as you are not a dev member of the project yet.
Its not a trivial thing to do at all, because of these very reasons :
- Alex 'Foogod' Stewart, the founder of UCI, explained the general structure of MPEG container a bit when we were discussing how exactly this muxing process should be looking like. If i understood him correctly the MPEG container is built around a number of different 'layers' or 'levels', and the important question is how to strip these infos from the MPEG container, and what infos to use and not. Read here for more from Alex :
http://article.gmane.org/gmane.comp.video....o.mcf.devel/643
http://article.gmane.org/gmane.comp.video....o.mcf.devel/683
As he was pointing out in his last email to the mcf-devel list it wont be possible to strip just the data themselfes out and use the matroska header elements to describe the track properties, but some of them have to stay and be copied with the data itself.
As a conclusion ( i hope i dont tell nonsense here ), the main question is what layers should be put into the trash and what layers have to be copied from the MPEG stream into the matroska stream, and where should they be stored then ?
- For decoding the Dshow based matroskaparser.dll generally speaking has 2 possibilities :
1. calling an existing Dshow filter ( this is used in VfW/AVI/Dshow compatibility mode ) in the graph
2. Calling an UCI decoder and outputting raw, decoded picture or audio data ( preferred way, standard for most native matroska streams
While both MPEG1 and MPEG2 are so called 'native' matroska compression formats using a specific matroska ID, they may be amongst the few that can not be decoded in the 2. way, as we will maybe run into licensing probs if we have to provice a UCI based MPEG2 decoder. So it may be a wise decision to call a Dshow filter from the parser.
To be able to do so its important to know what kind of MPEG streams these accept, as this will have a huge influence on what layers can be stripped from the stream, and what have to be kept by all means so that external decoders accept the data.
In principal it should be possible to 'restore' some layers on the fly in the matroska parser ( like building a kind of MPEG muxer into the parser for this specific, but important codec ), but i am not sure if this is a nice and clean solution at all.
Interested ????
More Info here :
http://article.gmane.org/gmane.comp.video....o.mcf.devel/582
http://article.gmane.org/gmane.comp.video....o.mcf.devel/583
--------------------
Visit the unofficial Virtualdub support forum on http://forums.virtualdub.org - help to reduce the big number of emails Avery Lee is getting every day !!
Support matroska as container and Gstreamer as the only truely open, x-platform multimedia platform .... |
|
| fccHandler |
| Posted: Jan 10 2003, 06:40 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (ChristianHJW @ Jan 10 2003, 10:06 AM) | | I had no idea you were working on a MPEG2 decoder for Vdub. |
I'm not. The bulk of the work was done a couple of years ago. I still fiddle with it now and then, but that's about it.
| QUOTE | | Is it possible to mux the MPEG2 into matroska instead of decoding it ? |
Honestly, I doubt it (especially after reading what Alex had to say). Anyway, I don't really understand why anyone would want to put MPEG-2 content into a different container. What would you gain from this? The MPEG format is an international standard. All sorts of applications now depend on it, and I think it will be around for a very long time.
| QUOTE | | ... the MPEG container is built around a number of different 'layers' or 'levels', and the important question is how to strip these infos from the MPEG container, and what infos to use and not. |
Again, the MPEG system is the best container for MPEG content, and trying to strip the streams out and mux them into something else doesn't sound like a good idea to me.
| QUOTE | - For decoding the Dshow based matroskaparser.dll generally speaking has 2 possibilities :
1. calling an existing Dshow filter ( this is used in VfW/AVI/Dshow compatibility mode ) in the graph
2. Calling an UCI decoder and outputting raw, decoded picture or audio data ( preferred way, standard for most native matroska streams
While both MPEG1 and MPEG2 are so called 'native' matroska compression formats using a specific matroska ID, they may be amongst the few that can not be decoded in the 2. way, as we will maybe run into licensing probs if we have to provice a UCI based MPEG2 decoder. So it may be a wise decision to call a Dshow filter from the parser. |
AFAIK DirectShow doesn't have any filters for decoding MPEG-2 content, other than a splitter, and it's not possible to decode MPEG-2 on a Windows system without first installing some kind of DVD software (or Nimo, he he).
--------------------
May the FOURCC be with you... |
|
| ChristianHJW |
| Posted: Jan 11 2003, 04:21 AM |
|
|
Advanced Member
Group: Moderators
Posts: 1768
Member No.: 2
Joined: 7-July 02
|
| QUOTE | | fcchandler Honestly, I doubt it (especially after reading what Alex had to say). Anyway, I don't really understand why anyone would want to put MPEG-2 content into a different container. What would you gain from this? The MPEG format is an international standard. All sorts of applications now depend on it, and I think it will be around for a very long time.. |
1. MPEG is pain in the ass to edit. The only kind-of-freeware program i know that allows you to cut out certain parts from an MPEG container is TMPEGencoder, and its not at all nice to handle.
matroska is not perfect for streaming ( like Ogg ) but designed for easy and powerful editing from the very start. It should well be possible to mux MPEG into matroska, edit everything with matroskadub ( cut out ads, etc ) and mux back to MPEG if necessary.
2. You are bound about the audio codecs you can use in MPEG ( mainly MP2/3 ). matroska will allow you to use any audio codec and any number of audio and subtitles stream with your MPEG 1/2 video tracks, including AC3, and its streamable by default without having to convert into a MPEG transport stream first.
| QUOTE | | AFAIK DirectShow doesn't have any filters for decoding MPEG-2 content, other than a splitter, and it's not possible to decode MPEG-2 on a Windows system without first installing some kind of DVD software (or Nimo, he he) |
Win2k SP3 is coming with a M$ MPEG2 decoder, same will do SP2 for XP. In any case, the DShow filters from other suppliers are easy to get for the user, and we dont run into licensing probs ....
Sorry you dont like the idea though  .... the capability to contain MPEG video was mainly seen as a very strong advantage for matroska from most of the people i was asking ....
--------------------
Visit the unofficial Virtualdub support forum on http://forums.virtualdub.org - help to reduce the big number of emails Avery Lee is getting every day !!
Support matroska as container and Gstreamer as the only truely open, x-platform multimedia platform .... |
|
| phaeron |
| Posted: Jan 11 2003, 05:14 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | You are literally the last person I expected to comment on this, but I couldn't have asked for a better critic. Thank you for your interest! I admit that the whole module can stand improvement (I'm no master coder). I guess in many ways, it's still a work in progress. But it's functional, and that was my primary goal at the time.
|
Just because I have no interest in writing an MPEG-2 decoder doesn't mean I'm not interested in how they work. 
| QUOTE | 1. MPEG is pain in the ass to edit. The only kind-of-freeware program i know that allows you to cut out certain parts from an MPEG container is TMPEGencoder, and its not at all nice to handle.
matroska is not perfect for streaming ( like Ogg ) but designed for easy and powerful editing from the very start. It should well be possible to mux MPEG into matroska, edit everything with matroskadub ( cut out ads, etc ) and mux back to MPEG if necessary.
|
Erm, the difficulty in editing MPEG is due to the IPB structure and the need for precise control over an encoder to recompress the surrounding frames. Replacing the container isn't going to make MPEG-2 edits easier.
| QUOTE |
Win2k SP3 is coming with a M$ MPEG2 decoder, same will do SP2 for XP.
|
Oh, just great.
The last time Microsoft decided to throw in a decoder was the MJPEG filter that came with DirectX 8. It could not decode faster than 15 fps on a PII-300, swapped fields, used a higher priority than the AVI Decompressor so it locked out all VFW MJPEG codecs, and was bundled into one of the DirectShow DLLs so it couldn't be disabled. Their other attempt was the DV codec that would not decode larger than quarter size unless you QueryInterface()'d it for a special interface and forced it to decode full size, which is what Avisynth ended up doing.
No thanks.
|
|
| fccHandler |
| Posted: Jan 11 2003, 07:18 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (ChristianHJW @ Jan 11 2003, 12:21 AM) | | 1. MPEG is pain in the ass to edit. |
MPEG was never designed to be editable. ("editable," is that a word?) My impression has always been that that the format was intended to represent the "final print." Once you compress to MPEG, there's no going back.
| QUOTE (phaeron @ Jan 10 2003, 04:38 AM) | | Oww... that bit read function is painful. You should be able to use something like this: |
Oww, I plopped your code in and it doesn't work. It doesn't crash, just shows a black screen. Still, you've given me some ideas about how to improve the code. Thanks so much.
--------------------
May the FOURCC be with you... |
|
| ChristianHJW |
| Posted: Jan 11 2003, 12:55 PM |
|
|
Advanced Member
Group: Moderators
Posts: 1768
Member No.: 2
Joined: 7-July 02
|
| QUOTE (phaeron @ Jan 11 2003, 07:14 AM) | Oh, just great.
The last time Microsoft decided to throw in a decoder was the MJPEG filter that came with DirectX 8. It could not decode ..... etc. ...
No thanks. |
Guess why SP3 hasnt found its way onto my PC until today ...
In any case, the interested user will know how to get a working MPEG2 DShow filter if he wants one, the others can use the M$ filter as a kind of fallback so they cant watch thier movies.
Of course, i would be much more interested in having a UCI based MPEG2 decoder, but i dont think anybody in the matroska team will ever have the necessary money to pay the MPAA decoder llicense cap ... and distributing such a UCI based decoder via p2p or enforcing this is no option for the matroska team, we want to stay inside allowed limits ...
--------------------
Visit the unofficial Virtualdub support forum on http://forums.virtualdub.org - help to reduce the big number of emails Avery Lee is getting every day !!
Support matroska as container and Gstreamer as the only truely open, x-platform multimedia platform .... |
|
| DeXT |
| Posted: Jan 11 2003, 08:31 PM |
|
|
Unregistered
|
@fccHandler: Sweet, that's the best word I can find about your great Mod.
I found the current MPEG2 support through DVD2AVI in VirtualDubMod embarrassing at best, with no direct AC3 decoding support and generating these ugly vdd2v files... However with your Mod and having AC3 activated, I could load a VOB directly in VirtualDub, play it in realtime (while listening at the AC3 track), and get an accurate MPEG2 file information (such as bitrate, format etc) through the well known File Information menu item. In sum, a perfect VirtualDub-MPEG2-AC3 integration!
I think maybe the VDubMod developers should consider dropping the current VOB support through DVD2AVI engine in favour of this one.
A note to fccHandler, though: please use the new liba52 instead of the old libac3, because it was a pain in the ass finding an old one which worked against your code (ac3dec-0.6.1), and then adapt it to compile on VC++. The latest liba52 has built-in support for win32 and has improved much since then. And of course support for multiple AC3 tracks would be nice, too 
Keep the good work!
|
|
| fccHandler |
| Posted: Jan 11 2003, 08:55 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (DeXT @ Jan 11 2003, 04:31 PM) | | A note to fccHandler, though: please use the new liba52 instead of the old libac3, because it was a pain in the ass finding an old one which worked against your code (ac3dec-0.6.1), and then adapt it to compile on VC++. |
So you enabled the AC3 support yourself? Then surely you're knowledgable enough to upgrade Mpeg.cpp for liba52.
Truth is, I didn't use any libs. I downloaded GPL'd ac3dec source by Aaron Holtzman and integrated it into the project, then wrote Mpeg.cpp to call the ac3dec routines for AC3 audio. And yes it's old because it was a few years ago when I did all that.
| QUOTE | | And of course support for multiple AC3 tracks would be nice, too |
It does allow you to choose from multiple audio streams (but not multiple video streams!)
--------------------
May the FOURCC be with you... |
|
| DeXT |
| Posted: Jan 11 2003, 11:45 PM |
|
|
Unregistered
|
| QUOTE | | So you enabled the AC3 support yourself? Then surely you're knowledgable enough to upgrade Mpeg.cpp for liba52. |
Well I wouldn't say so... enabling it just implied uncommenting a #define line, and putting the missing libac3. Nothing compared to what you did. And unfortunately I'm afraid I'm not skilled enough at this time (seems liba52 changed most of its API).
| QUOTE | | Truth is @ I didn't use any libs. I downloaded GPL'd ac3dec source by Aaron Holtzman and integrated it into the project, then wrote Mpeg.cpp to call the ac3dec routines for AC3 audio. And yes it's old because it was a few years ago when I did all that. |
OK I understand, I thought you wrote it recently.
| QUOTE | | It does allow you to choose from multiple audio streams (but not multiple video streams! |
Sorry I missed this 
I suppose you did it already, but in case you didn't, I think you should submit this wonderful Mod to Avery Lee, provided there are no legal issues of course.
Just a question. Why did you disabled AC3 support? Perhaps isn't it working right yet? Or maybe are just these legal concerns...
|
|
| fccHandler |
| Posted: Jan 12 2003, 12:56 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (DeXT @ Jan 11 2003, 07:45 PM) | | ... I think you should submit this wonderful Mod to Avery Lee, provided there are no legal issues of course. |
Avery knows about it
But there may be licensing issues, which is why I'm only linking to the source code (source code is kind of like "free speech" in the USA). Anyhow, Avery has said on other occasions that he does not favor using third-party code in VirtualDub (mine or Aaron Holtzman's, for example), and that he is not interested in writing MPEG-2 support for VirtualDub.
| QUOTE | | Why did you disabled AC3 support? |
To keep it simple. Otherwise I'd have to link to the ac3dec code and explain to people how to integrate the files into the project. (I see a lot of people have trouble just getting VirtualDub to build in the first place.)
Obviously, experienced C++ developers will figure out how to enable it on their own (as you did).
--------------------
May the FOURCC be with you... |
|
| ChristianHJW |
| Posted: Jan 12 2003, 09:47 PM |
|
|
Advanced Member
Group: Moderators
Posts: 1768
Member No.: 2
Joined: 7-July 02
|
Thanks for offering the code fcchandler.
VdubMod Team will test it for sure ....
--------------------
Visit the unofficial Virtualdub support forum on http://forums.virtualdub.org - help to reduce the big number of emails Avery Lee is getting every day !!
Support matroska as container and Gstreamer as the only truely open, x-platform multimedia platform .... |
|
| pulco-citron |
| Posted: Jan 13 2003, 08:12 AM |
|
|
Unregistered
|
>>ChristianHJW
Sorry, I must confess I do not read the mailing lists...
My opinion about MPEG2 in a different container is like fccHandler's. I can't see the point.
>>DeXT
I agree with you : the current MPEG2 support in VirtualDubMod is not very user-friendly and lacks some basic features.
However, I coded it this way keeping in mind what was my (personal) first preoccupation : speed (more precisely : speed for DVD->DivX conversions). This implies that I'd want any replacement implementation to support 1) YV12 color space 2) a "pre-virtualdub" resizing (that avoids "full processing mode" and all the related color space conversions : MPEG2 frames, at least taken from vobs, often have a wrong aspect ratio)
Note that I say this without having tried fccHandler's version... |
|
|
