PDA

View Full Version : Proposal for Open Source Compressed Domain Mpeg-2 Transcoder


int 21h
28th January 2003, 19:48
Most of us have heard of DVD2One. Basically it uses a process called Compressed Domain Mpeg-2 transcoding to reduce the size of a MPEG-2 stream so that you can author that stream later. I was unfamiliar with this process until the tool came out, but have now found a wealth of information about it.

Is anyone interested in a project, perhaps modifying an existing application (like DVD2AVI) to preform this process? It doesn't seem to be exceedingly complicated. Here are the links I've found so far:


http://www.cs.cornell.edu/zeno/papers/transcode/transcode.pdf
http://www.hpl.hp.com/personal/Susie_Wee/PAPERS/hpidc97/hpidc97.html
http://www.ee.princeton.edu/~minwu/public_paper/icip00_transcd.pdf

mpucoder
28th January 2003, 20:21
Judging from what I've seen and heard, DVD2one gets excellent results. We all knew there was an easier way than decoding and encoding to reduce the bitrate, now someone has done it.
I don't know about modifying an existing program, unless it was designed for mpeg in and out. I think a standalone app along the lines of ReMPEG2 (which this would replace) would be more acceptable.
I'm in. First thing to do is get webspace. SourceForge is a good place for this, as long as the project is open source, it will be welcome there. I can also supply webspace if that's not enough (we're upgrading the mpucoder servers now to be co-located, and IfoEdit interest is tapering off, so there's plenty of bandwidth)

Olebrumm71
28th January 2003, 20:25
Here is another interesting web-page on the subject of transcoding of MPEG2 videostreams:

http://www.bbc.co.uk/atlantic/transcoding.html

int 21h
28th January 2003, 21:29
Well, I can code C/C++, I just get lost in some of the more complex MPEG operations that go on (DCT, etc.). I will look into getting some space at Sourceforge a little later today. I would definitely want this to stay opensource and free as in beer, otherwise there's no point ;)

IdentDee
30th January 2003, 17:06
Originally posted by int 21h
Well, I can code C/C++, I just get lost in some of the more complex MPEG operations that go on (DCT, etc.). I will look into getting some space at Sourceforge a little later today. I would definitely want this to stay opensource and free as in beer, otherwise there's no point ;)

Perhaps we can use libvideocoding as far as i know it has everything but the bit allocation at transrating what we need.

rate control is the main problem. The activity in the macroblock must be derived from the dct coefficents. DVD2one seems to use a bitrate reduction factor on the quantization leading to lower perceived quality since it gives a damn on the activity in the macroblock.

http://rachmaninoff.informatik.uni-mannheim.de/libvideocoding/index.html

Nic
30th January 2003, 17:20
Id love to help in this, but I just dont think ill have the time at present :( But -h is finishing his MS-MPEG-4 -> MPEG-4 converter, so maybe you can rope him in ;) (sorry -h ;) )

Ill pay close attention and help when ever I can :)

Cheers,
-Nic

-h
30th January 2003, 18:00
Yeah, not too surprisingly I've had my days off chewed up by other activities, so the convertor will have to wait until next Tuesday.

But yes I've been mulling over creating an MPEG-1/MPEG-2 encoder/decoder, and a side-effect of that would be creating some transcoding modes. There are a few ways it can be done, the fastest looking the worst of course, but that's what trial and error is for.

I've no idea when I can start working on it, so I may not be much use to this project :)

-h

Ookami
31st January 2003, 14:45
Aren't there two moderators, here, who worked (work?) on a free MPEG 1/2 encoder? Maybe they could/would help?

*cough* *cough*

As for alpha/beta testers, I think that should really be no problem :) .

Good luck and hopefully it will succeed.

Cheers,

Mijo.

int 21h
24th February 2003, 05:56
What if we could take bbMpeg and modify/optimize it? It already accepts Mpeg-2 input.. all we would need to do is make it smarter (& faster), to intelligently reduce our streams....

Nic
24th February 2003, 10:48
bbmpeg's code is a bit of a nightmare, decoding the mpeg-2 parts won't be a problem as the standard MSSG code or dvd2avi's code can be used to decode the bits we'd need, the writing of the bistream back out could be a bit fiddly. Then theres all the bits inbetween. Its not really everso hard, the main thing is its no minor task.

Unfortunatly I dont think any of us want to give up our free time to make a piece of free software which has already been created and making quite a lot of money for those who created it. :( Its a sad shame :(

Cheers,
-Nic

ps
mjpeg.sf.net mpeg-2 encoding source is a bit easier to read for me anyway...

int 21h
24th February 2003, 17:45
Let's make commercial software then :p

Ookami
24th February 2003, 19:59
Isn't this a more promising and interesting project than the n-th automated encoding app etc.? I understand that it is way more complicated, but no one says that it has to be done in a few weeks/months.

I just want to show that this project would be very interesting and wanted. Surely others (who don't read this forum, BTW), would agree.

Just look how VirtualDub has changed in the last few years. From a little and unknown GPL video app, it's now for sure the most important/best freeware application in this area.

If this ever starts (int21h, have you looked in the Sourceforge webspace?), you can count me in for beta testing.

Cheers,

Mijo.

int 21h
24th February 2003, 20:56
The SF space is no problem, We've gotten in the past for other stuff (Save-OE, Nandub, etc.), but no point in getting the space if I have nothing to put up on the space...

Nic
24th February 2003, 21:41
Isn't this a more promising and interesting project than the n-th automated encoding app etc.? I understand that it is way more complicated, but no one says that it has to be done in a few weeks/months.

Rarely is a truer word said. So you've convinced me, ive started to look into it. I dont know if ill just hit a brick wall, but ill look through and at least put some code down to pass a MPEG-2 and get some of the parts we need out of it :)

-Nic

Nic
24th February 2003, 21:46
http://www.cs.wayne.edu/~dil/research/mdc/

Ok some parts of that download might be useful...
from the readme:
ompressed domain feature extraction, such as motion vector extraction,
DCT components extraction.

I think some stuff could be learnt from the code there, but maybe im being too optimistic, ill report back after ive scurried through the code :)

Cheers,
-Nic

ps
Ahhh, the zip does not contain all the source code, ill email the author

pps
doh! its from 1999, the chances of getting a reply are slim. back to the drawing board.

ppps
On the libmpeg2 dev mailing list someone asked about dvd2one, it will be nice if the mighty walken responds :)

int 21h
24th February 2003, 21:46
:)

int 21h
24th February 2003, 21:52
It contains all of the header files and the MDC.lib.. what else is needed?

A thought occured to me though... Does DVD2One pay the MPEG-LA patent fees?

Ookami
24th February 2003, 22:40
Yay! Great news, thanks to both of you...

Now, let's see if mpucoder and the others who've already showed interest, will contribute too. Not to mention that many new people could and probably will contribute too.

Can't wait to see the first Sourceforge steps (this will get me to update my programmers corner after a very long time :) )...

A happy wolf :) .

Cheers,

Mijo.

Nic
26th February 2003, 13:43
http://nic.dnsalias.com/MPEG2Enc.zip

Just for fun, while im doing "research" into it. Here's a Commandline MPEG-1/2 encoder that encodes from Avisynth AVS files.
(based on mjpegtools)

Tell me how it goes for you,

Cheers,
-Nic

Ookami
26th February 2003, 18:01
@Nic regarding MPEG2Enc

Umm, I doesn't work for me at all (at least in the short testings I've done)... What have I done wrong?

OS: Windows XP Pro SP1

Source: 768x576 25 FPS Huffyuv 2.1.1. CCE patch (no audio)

See the attached pix for the error report of the program (when selecting MPEG2 output). After I've selected MPEG1 for output, I've got a 383 KB file wich produces, on playback, just a green screen.

After choosing a Xvid AVI 640x480 (with audio), the program does nothing at all (mpeg1 and 2)...

Same when choosing a DV AVI (720x576).

Thanks for your researching :) .

Cheers,

Mijo.

Nic
26th February 2003, 18:13
Doh! Well DaveEl needs to verify the attachment (where's a supermod when you need one eh? :) )

I assume when you say your trying with an xvid file, your creating a AVS file like:
AviSource("d:\myxvid.avi")

and not feeding it the avi file directly, (as that would definitely crash it)

Also I assume you have a CPU capable of SSE Integer (Celeron 1000Mhz + )

Ill put up a build later that, has a bug fix
(my assembler was causing a bug in the motionsearch)

It works really well for me, slow, but the qualitys quite good :)

Cheers,
-Nic

ps
Hmmm, the attachements there now.
You are using YUY2 colorspace as well I assume... :confused:
Thats a real shame as its working great here...ill look into it

pps
Ok, ive put the new version up anyway:
http://nic.dnsalias.com/MPEG2Enc.zip
This should/probably work on just MMX processors too
(just tested it on a P2 and it works fine)

ppps
Make sure you can play your avs files in windows media player to make sure they dont cause an exception.

SILICON
26th February 2003, 22:55
If I am not wrong, mpeg2 have several process:

1 - Divide the image in BLOCKs of 8x8 pixels.
2 - iDCT of Blocks, giving 8x8 matrix
3 - Quantification of Matrix
4 - RLE & huffman matrix compression

We can resize the mpeg2 make only the 3 and 4 steeps. The process:

1 - RLE y huffman decompress (using the mpeg2dec code)
2 - Requant the matix, Droping the last values and/or dividing all values.
3 - RLE & huffman matrix compression. (using the bbmpeg code)

It is hard to code?

DaveEL
26th February 2003, 23:51
Originally posted by Nic
Doh! Well DaveEl needs to verify the attachment (where's a supermod when you need one eh? :) )


Sorry was asleep anyway it seems to have been done already if you need approval of stuff quickly drop me an e-mail cos i check that more often then the attatchments.

DaveEL

Nic
27th February 2003, 00:08
@Dave: :) Just joking :) If I really needed something validated I'd shout Swede, he's almost always on MSN :)

@SILICON: Pretty much, the basic idea. But a bit more complex then that though. but yes its that kind of thing, for I-frames at least.

I was going to use code from other projects, but instead going to write it from scratch. The chances of me ever getting it done into a working state with the time I have is slim. So I may as well as make it a learning process rather than hack bits of other code together. bbmpeg & dvd2avi/mpeg2dec code is awful to look at & use anyway. But im sure much can be taken from looking thru the code.

-Nic

DaveEL
27th February 2003, 00:17
Originally posted by SILICON

We can resize the mpeg2 make only the 3 and 4 steeps. The process:

1 - RLE y huffman decompress (using the mpeg2dec code)
2 - Requant the matix, Droping the last values and/or dividing all values.
3 - RLE & huffman matrix compression. (using the bbmpeg code)

It is hard to code?

Not so from what i understand

I-frames can be done with the above but if a P-frame "A" predicts from a frame "B" when you requant frame B the image changes. So now you need to recompress frame A predicted from the new version of frame B.

In order to do that you need to decompress the whole of both frames (the new B and the original A) then (assuming you take the motion vectors from the original) re DCT , quant and compress all the blocks.

DaveEL

Ookami
27th February 2003, 08:38
@Nic regarding MPEG2Enc

Should I, in the future, use a new thread or e-mail for OT bug reports? Or is this on topic?

>I assume when you say your trying with an xvid file, your creating a >AVS file like:
>AviSource("d:\myxvid.avi")

Yep, in all cases. Not all files were Xvid, from DV to Xvid several codecs.

>Also I assume you have a CPU capable of SSE Integer

P IV 2,4 GHz

>ppps
>Make sure you can play your avs files in windows media player to >make sure they dont cause an exception

Also, always done.

>You are using YUY2 colorspace as well I assume...

Aha, there you have it! Never thought that this could be the reason! ConvertToYUY2()did the trick, Nic :D . I've only, tried the DV file (as it was for sure RGB), will report back when I try some more...

BTW, wasn't able to reconstruct the error from the attached picture.

Anyway, thanks all for your contributions! BTW, take a look at the number "views" :) .

Cheers,

Mijo.

ChristianHJW
27th February 2003, 16:18
We could found an opensource project on corecodec.org for this, CVS is working fine now ... just a quick suggestion, dont jump on me if you dont like it. I could help with project administration if you allowed me to do so.

Christian

int 21h
28th February 2003, 05:01
Can you post the source of the ported mpeg2enc? :D

int 21h
28th February 2003, 07:41
Even if we can't develop some sort of DVD2One-like program, it would be neat if we could figure out a working solution for reproducing multi-PGC titles using a 3rd-party encoder...and not using Scenarist

Nic
28th February 2003, 10:10
@int21: Sure ill post the source tonight or tomorrow. Youll need the intel compiler to compile it. :) It was a real pain to compile, ive also got pthreads added now as a static library, so ill post that in the source too.

@Dave El: Yup, motion screws everything up. ;) But it should be all good fun :) Im starting from the very basics though (parsing all the startcodes, reading in seq headers, etc), so it will be a time before I get to the fun parts.

@ookie: Ill make a YV12 version too ;) did you download it again from the second link? That should stop weird errors and a bug in the motion comp.

@Chris: :) That would be helpful, but lets wait till we've actually got some sort of a project going before we worry about webspace, admin, etc. Thanx for the offer :)

Cheers,
-Nic

Ookami
28th February 2003, 10:12
Originally posted by Nic
I was going to use code from other projects, but instead going to write it from scratch. The chances of me ever getting it done into a working state with the time I have is slim. So I may as well as make it a learning process rather than hack bits of other code together. bbmpeg & dvd2avi/mpeg2dec code is awful to look at & use anyway. But im sure much can be taken from looking thru the code.

-Nic

Oh, almost missed that one :) . I certainly hope that you will not be the only one working on this project... A few dedicated programmers and testers can do wonders, we all know that.

But, even fu2k had his first FairUse version ready after a few years (!) of hard work by himself, so you could use that approach :) .

All the best and lets get this rolling...

Cheers,

Mijo.

Nic
28th February 2003, 10:42
I certainly hope that you will not be the only one working on this project

Whys that...Dont think im upto it? ;) (just kidding :) )

No, Ill definitely want as many people working on it as possible. At present, im not really working on it, just doing research into it. all the code im writing now will probably be thrown away, but it helps me to understand how matrices are read in sometimes from a sequence header, how groups of pictures are ordered, etc.

-Nic

int 21h
28th February 2003, 18:48
That's why I was thinking an interim step in this would be figuring out how to transfer timecodes and sequence headers from one stream to another (wouldn't this be all (or at least the bulk) that is needed to make a multi-pgc stream?)

Intel Compiler, no problem.

mpucoder
1st March 2003, 01:44
Just to let you guys know I haven't lost interest. Yes, timecodes and sequence headers need to be transfered, but what makes a stream uniquely DVD is the NAV pack. This is where the VOBid and CELLid are kept.

Another thing to think about is angles. If the transcoding needs no temporal information than this doesn't matter. But if P and especially B frames do need information from other frames then it becomes necessary to provide for up to 9 threads.

Nic
2nd March 2003, 18:19
Im getting somewhere slowly, lol. Now that im getting into it, just writing code now to get decode the macroblocks (i.e. undo the VLC and iDCT). My main aim is to just re-quant the first I-Frame's DCT coefficients (is that the right word ;) ) and then fdct, vlc and write it back out again.

If I can do that in a few days, ill be happy, but time is so short, ive only really spent a couple of hours on it so far (research and all :( )

Cheers,
-Nic

ps
Ill look into the MPEG2Enc code today, and try to tidy up and release it.

jj59
4th October 2003, 22:41
Could this be of any help
http://www.heise.de/newsticker/data/vza-25.09.03-000/

jj

RB
7th October 2003, 00:25
I think so. I've ported this to Win32 so it compiles in MSVC++, see http://forum.doom9.org/showthread.php?s=&threadid=62849 . Your turn, guys :)