PDA

View Full Version : making xvid output "native" mpeg-4 streams


bond
28th September 2003, 13:36
hi guys!

i searched a little bit around the last days if it is possible to create "native" mpeg-4 streams with xvid. i mean xvid and divx5 uses some hacks to put b-frames into avi and i dont think thats the way the mpeg-4 standards expect them to be stored in a file ;)

as it seems that there is no way till now to make xvid output streams in which the frames are stored as defined by the mpeg-4 standard, i thought that perhaps it would be usefull if there could be an option which makes xvid to do so (dunno if that is possible in vfw but perhaps in directshow? or is there a commandline xvid encoder?)...

that way it could be possible to produce mpeg-4 compliant streams in containers that can handle that, like .mp4, .mkv (and perhaps .ogm?) files (no need for the avi hack anymore imho)...

edit: of course it is important to note that tools like mp4creator (mp4ui) dont correct the avi hack

a mpeg4ip devel pointed me to their mp4v2 library, which should be easy to implement in xvid he said:
"Both divx and xvid can have access to our mp4v2 library - it is very simple to use. It would take them less than 1 day to implement with, and it is Mozilla License, so it wouldn't be a problem license-wise. faac has used our library for a while"...

celtic_druid
28th September 2003, 14:43
How about xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003?

Output options:
-save: save mpeg4 raw stream

sysKin
28th September 2003, 14:45
XviD itself is an encoding library - it doesn't care about the container you're going to use. Just use it with whatever you want.

In particular, xvid_encraw is a very simple program that will output a pure video elementary stream - .m4v . The program itself is not really usable (requires decompressed input), but it's a good example how easy using xvid really is.


Originally posted by bond
that way it could be possible to produce mpeg-4 compliant streams in containers that can handle that, like .mp4, .mkv (and perhaps .ogm?) files (no need for the avi hack anymore imho)....mp4, which is mpeg-4 part one, needs to be implemented. XviD is an implementation of part two, not part one - you just need another project. They do exist of course :).

All other containers you mentioned don't offer support to non-VfW video (yet).

Radek

bond
28th September 2003, 15:22
first i have to say: plz excuse my dumbness :D

Originally posted by sysKin
XviD itself is an encoding library - it doesn't care about the container you're going to use. Just use it with whatever you want.what change has to be done in the vfw xvid.dll to make it output video streams the way, they are meant to be in the mp4 container or in matroska "native mode" (should be the same way afaik)?
would it be possible to implement an option for that (to get rid of these hacks introduced for avi support)?

bond
28th September 2003, 18:40
ok, i now had a long discussion with syskin about that matter (thanks a lot :) ) and here is a small summary:

xvid (vfw) with b-frames enabled and backed bitsream disabled produces no dummy and no delay frames (and because of that no packed frame at the end with the delayed frames) and (of course) no packed bitstream in avi when used in virtualdub(mod)! the frames are stored in coding order

ChristianHJW
30th September 2003, 11:13
Originally posted by bond
ok, i now had a long discussion with syskin about that matter (thanks a lot :) ) and here is a small summary:

xvid (vfw) with b-frames enabled and backed bitsream disabled produces no dummy and no delay frames (and because of that no packed frame at the end with the delayed frames) and (of course) no packed bitstream in avi when used in virtualdub(mod)! the frames are stored in coding order

Yes, thats nice, but the frame order is not everything as still the stupid VfW API doesnt tell us what frames are what, and this is what we need to write native MKV files, as matroska has its own internal frame referncing system and needs to know the frame type and what other frames its referencing to, at least in native mode ( not in AVI compat mode ). Thats why DaveEL's AVS2Matroska ( unfortunately he introduced a stupid bug and since then development got stuck :( ) was using dev API4 instead, as this interface gives us the necessary info about the frame types and frame references, similar to what your frame reader can do for us if we make native files from AVI / OGM / b0rked MP4 files ....

symonjfox
30th September 2003, 14:14
Instead, what about creating a kind of standalone MPEG4 encoder? For example I saw that MPEG1 and MPEG2 only have standalone encders (TMPGEnc CCE and so on), so why MPEG4 just have DirectShow and VFW codecs?

I don't know about licensing, but if we take Xvid sources for video, FAAC and LAME for audio, MP4IP and Matroska as containers, is it possible to create an all-in-one program? I'm not talking about Gknot or similar software, I mean a real standalone, like MPEG1 and 2 have.

RadicalEd
30th September 2003, 17:18
I'm all for that. Even just a simple GUI should be able to combine at least encraw, faac, and mp4creator in a standalone interface, though a combined source standalone couldn't hurt. I thought about doing the GUI idea a few months ago but (like everything) it fell off the list of priorities.
But it would definitely be cool to have an all in one open mpeg 4 solution, if that's even legal :O

droolian01
1st October 2003, 10:25
Hi there.

The solution to making xvid encoded raw video streams is really easy, it's so easy that i have probably missunderstood the question totally (if that is so please correct me!)

Use ffmpeg with a command line such as

c:\>ffmpeg -i inputxvid.avi -vcodec same outputraw.m4v

this gives you your raw .m4v file which can be muxed with .aac audio with the ibm toolkit for mpeg4

So you have xvid encoded .mp4 files

i said it was easy:)

ChristianHJW
1st October 2003, 11:59
Guys, DaveEL's avs2matroska was exactly that, it accepted avs scripts on the input and was outputting native MKV, and the proggie was working, i even have a working binary on my HDD !

It had XviD statically linked, so there was no VfW or DShow API involved as XviD was not used as a plugin, but became a fixed part of the program ( BTW, this was devAPI3, not 4 as i wrote above ). The codec took the settings from the registry, so i had to fire up Vdub, make my xvid settings, close the Vdub config panel and was then starting avs2matroska.exe from CLI, and i could produce valid files with it at this time.

Unfortunately, robux4 and Mosu introduced some new elements into libmatroska then to improve the frame referencing system for native files ( IIRC this was necessary to make RV9 in MKV more efficient ). This was possible as there was no tool released by then that would produce native files, so it could easily be improved without breaking backwards compatibility. Now, when DaveEL was trying to update his working code to match the new lib version and write the correct frame refernces, he b0rked something heavily, and since then he could not find the bug and gave up on the project :( .....

I dont know if DaveEL will ever find the motivation again to start working on avs2matroska, but this tool was exactly what you are describing above, and even a avs2mp4 should be possible based on it, using MPEG4IP. Maybe if we all start bugging Dave :D ??

Also, there is VFRE (http://corecodec.org/projects/vfre) somewhere down the road, and jcsston is working hard on it .....

mf
1st October 2003, 13:49
Originally posted by ChristianHJW
I dont know if DaveEL will ever find the motivation again to start working on avs2matroska, but this tool was exactly what you are describing above, and even a avs2mp4 should be possible based on it, using MPEG4IP. Maybe if we all start bugging Dave :D ??
Not necessary. Afaik B-frame markers are in the video bitstream (m4v) and not in the container part (mp4). So as sysKin said, you only need xvid_encraw and something that takes an m4v file and an audio file, and muxes it into an MP4.

sysKin
1st October 2003, 14:56
How much work would it need to make VDubMod output clean m4v stream? Nothing I guess - we just want all frames to be sticked together in one big file, the end.

Cyrius? RobUx4? :)

Radek

ChristianHJW
1st October 2003, 14:57
Originally posted by mf Not necessary. .... mf, you probably forgot to add 'IMHO' ?? How will you feed your MPEG2 sources to _encraw ? Dont you agree that using AVS scripts and getting a final MP4 or MKV file is a better way to do it ?

ChristianHJW
1st October 2003, 15:00
Originally posted by sysKin How much work would it need to make VDubMod output clean m4v stream? .... a complete rewrite of the program sysKIn. VdubMod is fully relying on the VfW framework of Virtualdub if it comes to encoding, and thus can only use VCM codecs. I know this because i was trying to bug Cyrius about linking XviD statically into VdubMod to write native MKV files already :D ....

celtic_druid
1st October 2003, 16:58
Couldn't you pipe MPEG2 into encraw using ffmpeg?

sysKin
1st October 2003, 17:40
Originally posted by ChristianHJW
.... a complete rewrite of the program sysKIn. VdubMod is fully relying on the VfW framework of Virtualdub if it comes to encoding, and thus can only use VCM codecs.Yes sure, but once VCM codec is used, I just want it to encode a frame and append it (byte-by-byte) to some output file. Looks like 4 lines of code to me.
Actually, I was thinking about demuxing them from existing AVI, but what the heck, it would work just as well for encoding.

Let's see, what the lines of code are...
(in C):
{
FILE * hamster = fopen("file.es","ab");
fwrite(frame_data, frame_size, 1, hamster);
fclose(hamster);
}
...somewhere when frame is available. DO NOT take this code seriously LOL! but this is pretty close to what is needed.

Let me think, I was able to compile VDM 1.4.something - I might try that :) ;) :cool: :p

Radek

Suiryc
1st October 2003, 17:55
You mean a clean m4v stream is just a RAW video stream ?

Sorry for my n00biness but I don't know that much about MPEG in general (except for Mpeg Audio headers, and about IPB frames ;p).

But then what would be the purpose of outputing this RAW stream in a file ?

mf
2nd October 2003, 14:25
I shall quote myself from IRC:

15:53 <@mf> bond: just add 3 extra frames which are guaranteed to be scenechanges (eg if your movie ends with black then add a white and a black and a white frame), and then encode with xvid in vdm, then cut out those last frames (be absolutely sure that you cut at keyframe), and all will be ok
15:54 <@mf> that's my theory anyway
15:55 <@mf> bond: you'll cut out the last GOV which'll be packed so then you'll have a 100% non-packed stream
15:55 <@mf> sysKin: am i correct?
15:55 <@sysKin> mf: I think so
15:56 <@mf> hm, in fact, vdm should be able to do this automagically >;D
15:59 < bond> sorry to bug you again, would there much to change in xvid.dll to make it output no such hacked b-frames into matroska for example in vdm?
16:01 <@mf> bond: like i said, you'd need vdm to feed xvid some last frames and then cut them out again - the only way to resolve VfW's one-frame-in-one-frame-out nightmare
16:01 <@mf> bond: and that'd be AVI/MKV/OGM independant, it works for all

sysKin
2nd October 2003, 16:02
Originally posted by Suiryc
You mean a clean m4v stream is just a RAW video stream ?
As far as I understand xvid_encraw - yes, that would make a real .m4v elementary stream.
But then what would be the purpose of outputing this RAW stream in a file ?Well, droolian01 said: this gives you your raw .m4v file which can be muxed with .aac audio with the ibm toolkit for mpeg4so as far as I understand, .m4v can be useful.

I myself don't really care for .mp4 , I'm just waiting for matroska native streams ;)

Radek

ChristianHJW
5th October 2003, 00:11
Originally posted by sysKin I myself don't really care for .mp4 , I'm just waiting for matroska native streams ;) . Radek

Can i post this on our homepage Radek ? 'Even most important XviD developers prefer MKV over other containers today ...' :D :D ???? LOL ....

mf
5th October 2003, 20:54
Originally posted by ChristianHJW
Can i post this on our homepage Radek ? 'Even most important XviD developers prefer MKV over other containers today ...' :D :D ???? LOL ....
Tut tut tut. It's not plural: "Even a very important XviD developer prefers MKV over MP4." Don't twist reality ehh ;).