Future of XviD

[Nil Einne]

Does anyone have any idea what the current future plans for XviD are? Although I could be wrong, I don't see that much that can be added feature wise (unless we're talking about AVC). Speed wise and quality wise, maybe things could be improved a bit but how much? I don't know for sure but personally I wonder whether it can improve that much.

One option would be for XviD to start to include h.264/MPEG4 AVC. This is the logical step forward. However it is a good question, should the AVC be a part of XviD? Since it bears little relation to advanced simple profile, maybe it should be a seperate project anyway? (e.g. the x263 project).

Comments anyway (esp Koepi etc)? And have the other developers been saying?

[MfA]

Still lots of room for improvement.

Personally I think h.264 is a bit of a mess, dont see why anyone would be anxious to work on it for fun. MPEG-4 was comparitively simple, and it helped that Michael made a nice codebase to build from (ffmpeg is one hell of a great piece of software ... but the type of programmers who feel comfortable with the codebase are rare, and if the xvid developers were among them xvid wouldnt exist).

I hope the xvid developers will like Dirac enough to contribute to that, but I kinda doubt it :)

I think xvid will survive as an active project and a pure MPEG-4 codec for the near future.

[LostMP4]

Originally posted by MfA
Still lots of room for improvement.

Personally I think h.264 is a bit of a mess, dont see why anyone would be anxious to work on it for fun. MPEG-4 was comparitively simple, and it helped that Michael made a nice codebase to build from (ffmpeg is one hell of a great piece of software ... but the type of programmers who feel comfortable with the codebase are rare, and if the xvid developers were among them xvid wouldnt exist).

I hope the xvid developers will like Dirac enough to contribute to that, but I kinda doubt it :)

I think xvid will survive as an active project and a pure MPEG-4 codec for the near future.

MPEG-4 ASP is pure and AVC not... why?

[MfA]

It is tacked on, it replaced the entirety of MPEG-4 visual ... the reason for making it part of MPEG-4 in name is more political than anything else.

But Ill rephrase, xvid will almost certainly remain a pre-AVC MPEG-4 visual codec and actively developed for the near future.

[RadicalEd]

Originally posted by MfA
it replaced the entirety of MPEG-4 visual

Not at all. The ingenuity of MPEG-4 visual lies largely in its still-untapped potential as the only existing object based video coding standard. MPEG-4 was meant to be an evolution out of purely rectangular video. AVC has the much smaller scope of perfecting that area. Perhaps AVC is replacing ASP, but there is still plenty of room for MPEG-4 Visual in the future IMO.

[SeeMoreDigital]

I too think there's room for improvement in Mpeg4.

I feel sure more visual information can be squeezed out of Mpeg4 SP, before visiting any of the ASP features!

As for h.264/AVC, this only became "a bit of a mess" because some codec manufacturers insisted on muxing the video stream into the .avi and .mpg containers!

In my opinion AVC belongs either in it's raw stream state (which is fine for 'video only' testing), or in .MP4


Cheers

[DanielSun]

As Nvidia has released his NV40 GPU,a new feature has been added.
That is a programble video processor,that can hold 60% of encoding job and 90% of decodeing which should be done by CPU in the old time.

Should Xvid do someting to support this feature?

Then encoding a movie will be much faster.

[Hiro2k]

Yeah but only people with 6800's would benefit from it. :(

[DanielSun]

Originally posted by Hiro2k
Yeah but only people with 6800's would benefit from it. :(

6600 and 6600GT have that feature too,am i right?:confused:

[Nil Einne]

I too think there's room for improvement in Mpeg4.

I feel sure more visual information can be squeezed out of Mpeg4 SP, before visiting any of the ASP features!

As for h.264/AVC, this only became "a bit of a mess" because some codec manufacturers insisted on muxing the video stream into the .avi and .mpg containers!

In my opinion AVC belongs either in it's raw stream state (which is fine for 'video only' testing), or in .MP4


Okay I'm confused. Why is it more wrong/messy then ASP (and SP)? Given that codec manufacturers and people who use those codecs (including XviD) also insist on muxing the video stream into .avi or .mpg (and now .ogm and .mkv since you seem to think only .mp4 is okay? Didn't XviD start partly because people were originally using a hacked Microsoft MPEG4 codec [DivX 3.11 ;-) ] which they put into an AVI stream (and this MPEG4 codec wasn't even properly compatible to the standard)? Heck if I recall isn't the XviD only recently (thinking recent versions) started to be 100% compatible with the standard?

Actually while I personally still doubt there can be that much more improvement in quality (thinking of best quality 2 pass VBR here) I may have been wrong in terms of speed. Also I think there is another area for improvement I didn't quite think of. Improvement for 1 pass constant Q, VBR and CBR and also especially development of a real time option!

[stephanV]

Originally posted by SeeMoreDigital
In my opinion AVC belongs either in it's raw stream state (which is fine for 'video only' testing), or in .MP4


Why only MP4? When support is written for it, it could just as well go into MKV and OGM too... It would probably even work in AVI in DirectShow. Only MP4 is at the least a little bit limiting, not in the least for development. The advancements on the MP4 container are IMO tragically slow... H.264 developers did not really insist on muxing it into AVI, they didn't have much of a choice.

As for the future of XviD... perhaps the developers would like to shed a light on their plans?

[SeeMoreDigital]

Originally posted by Nil Einne
Okay I'm confused. Why is it more wrong/messy then ASP (and SP)? Given that codec manufacturers and people who use those codecs (including XviD) also insist on muxing the video stream into .avi or .mpg (and now .ogm and .mkv since you seem to think only .mp4 is okay? .MP4 is the native container for Mpeg4 (as we now it today).

To understand more about this subject please read bonds MPEG-4 Information (including AVC/H.264) (http://forum.doom9.org/showthread.php?s=&threadid=73022). Oh, and as far as I know, nobody has ever insisted on muxing Mpeg4 into .mpg

Much as I like using the AVI container, one can't escape from the fact that it's old. Sure, people like Alex Noe (the creator of the excellent AVI-mux tool) are constantly adding functionality to the container in an effort to keep it up to date. But arguably, some past implementations/hacks have damaged Mpeg4. The main one being, how B-VOP's are read!

And in my opinion, when DivX decided to implement packed bit-stream (PBS) for their DivX Certified products in April 2002, this is when the entire B-VOP in AVI situation became a complete mess...

Should I use packed bit-stream, should I not use packed bit-stream? Will my "non" DivX Certified stand-alone cope with 1B-VOP + PBS or without? How do I know what's best for me and my stand-alone? Jeez the Doom9 forum is full of this sort of stuff!

Originally posted by Nil Einne
Actually while I personally still doubt there can be that much more improvement in quality (thinking of best quality 2 pass VBR here) I may have been wrong in terms of speed. Also I think there is another area for improvement I didn't quite think of. Improvement for 1 pass constant Q, VBR and CBR and also especially development of a real time option! Well we all have our opinions. There are some who say, there's a lot more improvement to be had out of Mpeg2... so why not Mpeg4?

You've only have to generate "simple profile" comp tests with, DivX, 3ivx, XviD and Nero (at the same bit-rate/file size), to understand that each codec manufacturer has very different opinions with regard to performance!

Originally posted by stephanV
Why only MP4? When support is written for it, it could just as well go into MKV and OGM too... It would probably even work in AVI in DirectShow. AVC works already in AVI, but in order for all of AVC's implementation to work correctly, I can't help feeling "hacks" will have to be made! And we don't want another B-VOP mess do we?

Originally posted by stephanV
Only MP4 is at the least a little bit limiting, not in the least for development. The advancements on the MP4 container are IMO tragically slow... H.264 developers did not really insist on muxing it into AVI, they didn't have much of a choice.Of course developements are "tragically slow".

This is because we've spent two and a half years longer than we should have supporting and using AVI. Look at how far .MP4 has come in the nine months since Nero/Ahead/Ateme got involved. Bobololo has even hinted at an possible AVC release before the end of the year. That's not bad going for a years work ;)

And there's really no reason why you can't have say, AC3 and DTS audio streams in there either, as the use of "private streams" is permissible in MP4.... All we need are some clever people to create the muxing tools :)

But back to XviD. There's no denying that it's the preferable Mpeg4 encoding option for most of us. I like it because it does not restrict the user.

The next logical step for Mpeg4 is AVC. But before that I would like to see XviD being used more in stand-alones and the end of DivX Certification, so that XviD can be allowed to breathe more easily :D


Cheers

[stephanV]

Originally posted by SeeMoreDigital
And there's really no reason why you can't have say, AC3 and DTS audio streams in there either, as the use of "private streams" is permissible in MP4.... All we need are some clever people to create the muxing tools :)

Practically, a private stream for MP4 will probably not be any better than a hack for AVI, perhaps even worse. Private streams would probably need private splitters and thus breaks the strong point of MP4: interoperability. Even if a splitter would say, ignore a private stream (and not crash on the file) a movie without sound is not quite the same thing. Matroska, or even OGM and AVI are much more sensible for combining a video stream with an audio stream. Firstly, because they already support it quite well and secondly, because MP4 developers already seem to have trouble enough muxing MPEG streams in MP4. So let them focus on that first.

[SeeMoreDigital]

Originally posted by stephanV
Practically, a private stream for MP4 will probably not be any better than a hack for AVI, perhaps even worse. Private streams would probably need private splitters and thus breaks the strong point of MP4: interoperability. I doubt something that's permissible would be worse than an hack... But I guess we'll have to wait and see!

The trouble with hacks is, people soon forget that they are, exactly that! Some even moan when the "hacks" don't work correctly!

With the right effort "private streams" can be made to work correctly... anyone who's generated say, some Apple AAC lossless encodes in MP4, understands this.


Cheers

[ChristianHJW]

Originally posted by SeeMoreDigital The trouble with hacks is, people soon forget that they are, exactly that! Some even moan when the "hacks" don't work correctly! .. so right, oh so right. Most people still believe that DivX AVIs with MP3 are an 'official standard' and moan against people releasing stuff as OGMs or MKVs .... LOL ...

[gamaD]

Support the future of video and audio encoding : matroska as container, USF as subtitles standard and CoreAPI as codec interface API in future If you are a developer and plan to contribute to any of the projects, pls. visit us on irc.corecodec.com , #matroska , as a user pls. turn to the Doom9 Guides or to the Matroska Support Pages to get more information on how to use matroska and USF for your encodings

Why matroska, why not OGM? :sly:

[RadicalEd]

Originally posted by gamaD
Why matroska, why not OGM? :sly:

Because it's a hack.
UH OH.

[SeeMoreDigital]

Originally posted by RadicalEd
Because it's a hack.
UH OH. I rest my case :D

[celtic_druid]

Maybe because Matroska is still being activly developed and ogm hasn't been touched for years.

The future = something that hasn't been worked on in years? Doesn't make much sense to me.

[SanatClaus]

I think there is sill a lot to do regading on the fly encoding (1-pass realtime encoding). Just think of all home theater equipment that starts to fill the market. I my self am trying to replaced my VCR with this technique. I think this will be an very important field in the near future. In my exerience Mpeg2 requires some 5-10 times more disk space for comparable quality, so that is not an option if you want to store video for more than a short time.

I find that the quality of 1-pass endcoding is much inferior to that of 2-pass and can only partly understand that (lots of high quantiziser frames and not so good de-interlacing). When recoding, my box is dedicated to only that, so the entire (1GB) is free to be used for example a look-ahead buffer. Could not such a huge (or in the near future even bigger) buffer partly replace the second pass? I would be supprised if there where not a lot of optimization possiblilities in 1-pass encoding still could be explored.

/Regards SantaClaus

[Mug Funky]

a big buffer isn't all that's needed... you'd still need to encode frames, put them in the buffer, then keep going until the buffer is full (and you've got a fair amount of encoding stats) and then start using the gathered stats to begin encoding the first bits again. it'd be not much different from 2-pass encoding.

however, i think there are some things that could be done in 1-pass encoding as it is now. basically making intelligent assumtions about where the low quants should go, and where the high quants should go.

but realtime encoding has traditionally been the territory of dedicated hardware. such hardware is slowly making it onto the market.

besides, commercial applications still use 2-pass encoding, even in hardware. mpeg-4 will be no different, i suspect.

[SanatClaus]

a big buffer isn't all that's needed... you'd still need to encode frames, put them in the buffer, then keep going until the buffer is full (and you've got a fair amount of encoding stats) and then start using the gathered stats to begin encoding the first bits again. it'd be not much different from 2-pass encoding.

Precisely. The idea would be to produce the hi quality 1-pass encoding in real-time. This of course, is what the hardware encoders must do. A home theatre user, most likely expect real-time behaviour and will use his video recording equipment much like he will today’s VCR's or he will use it as a time shift (simultaneous encode and decode) device. If 2-pass would be employed, the second pass must be done in background and the recording will not be available for a considerable time. I don't think this will be acceptable.

There is no major difference between a hardware and software codecs, except that the hardware one may take advantage of a dedicated signal processor and may therefore be able to do the job quicker. But the general-purpose processors become more and more powerful and real-time software encoding is doable today (with for example Xvid of ) at an acceptable quality (I have some 300 GB brodcasted material on disk today).

I think this may be quite a interesting niche for coming Xvid versions, either on a home theatre device (which most likely contains a full operating system and therefore needs a general purpose processor) or on embedded devices, like PDA's.