PDA

View Full Version : @nic , @milan : Xvid decoder to accept new frame order ?


ChristianHJW
21st February 2003, 23:09
Hi Nic, hi Milan,

it seems there will be no UCI codec API available for the next months, so we cant make our native matroska MPEG4 decoder plugins using UCI codec API.

For the moment this means we have to mux all files using our so-called AVI compatibility mode. The matroska codec ID will be set as 'V_MS/VFW/FOURCC' and the complete BITMAPINFOHEADER structure from the AVI be copied into the KaxCodecPrivateData matroska element. That way we can use any normal DShow filter on playback, the filter will simply not notice the video stream is not coming from an AVI. Moritz 'mosu' Bunkus was not at all happy about this, its pain in the ass for him to get his hands on the BITMAPINFOHEADER in his Linux muxer, he even had to stress a completely different AVIfile lib than he is normally using.

This mode was originally only planned to be able to support all elder VfW codecs, as we wont be making UCI plugins for all the old, seldom used stuff also. But for MPEG4 our plans were to avoid this and to encourage using our native modes. Now it seems we are forced to use it even for MPEG4, at least until UCI will be here :( ...

Main difference between the two is that there wont be dummy frames as 'placeholders' for b-frames in matroska's MPEG4 native mode. Both will use coding order ( makes sense ), so we dont have any major difference there. But matroska can mark b-frames as such, while AVI can not.

Now my question to you guys was :

Do you see any chance that you could modify your XviD DShow filters such that we could feed you with native matroska MPEG4 streams for decoding ?

I am trying to break down where the main differences are ( explanation : [chunk of data]; = placeholder for I/P-frames, dummy frames ) :

Presentation order :

[I][B][B][P][B][P][I]

AVI :

[I][P;B][B] [P;B] [I] etc.

matroska ( = coding order ) :

[I][P][B][B][P][B][I]

Could you filters handle that, hopefully with small modifications ? We could create a new, unique GUID to be able to call the filters in the right mode ? Or use the same GUID as normal XviD, but set a flag somewhere ?

What do you guys think ?

Nic
22nd February 2003, 12:00
Im afraid milan and I, might need more evidence that matroska is actually going to "come to life" in the near future before we start changing our software. Also, shouldn't matroska's AVI compatability mode be able to cope with this? If it already does then release that working and once "its taken off" ill definitely look into it for you. :)

Good luck! :) Its a helluva project you and your team are undertaking...

-Nic

ChristianHJW
22nd February 2003, 12:15
Originally posted by Nic Im afraid milan and I, might need more evidence that matroska is actually going to "come to life" in the near future before we start changing our software

Nic, Milan, check PM .. you find a link to the version of matroskadub ( based on VdubMod ) we are currently alpha testing. libmatroska is more or less finished, we have some memory leaks that are obviously a bit hard to find and robux4 is finishing seeking, but thats it.

The version in the link needs a valid installation of VdubMod, simply replace the .exe with the new one.

More important :

I wasnt asking you guys to change your filters NOW. All the matroska files being created now are definitely made in AVI compatibility mode, so they will work fine with the normal DShow filters, at least on Windows. But these files are pain in the ass to support on Linux, and matroska was always ment to be x-platform, so this is not an option for us for the future.

What my question was about :

Would you guys be willing to modify your filters ( at least one of them ) to accept the new frame order if we could create tools that took an AVI and reordered frames such that they are 'native' MPEG4 streams ? This wont happen any time soon, so no reason to panic and stop all other work, but i have to know that now or i have to find other options to ensure playback of those streams.

Hope this was more clear than my first posting ;) ....

sysKin
23rd February 2003, 12:37
Hi,
I just dropped in to tell that my harddrive just witnessed its first matroska file ;) and I'm REALLY impressed.

Firstly, I don't know how, but the muxing speed (in 'direct stream copy') is faster by over 50% compared to avi or ogm.

Secondly, the resulting filesize is smaller by almost 1% compared to ogm. This is what I call being _useful_.

I wasn't really in favour of new containers, especially after this mcf/matroska fight... But I am impressed at this moment. Good work, developers!

OK, just wanted to share my revelation. Thanks for reading.

Good luck for the developers, I can't wait for a final release,

Radek

Suiryc
23rd February 2003, 14:02
@sysKin

Thanks for your input :)
Well I am not sure the +50% speed you experienced is a general case ;) (in my tests generally Matroska muxing is slower than OGM muxing, but this only really matters in 'Direct Stream Copy').
As for the filesize I am happy to know it seems to be smaller than OGM :) (in one of my tests - with video only - the Matroska file size was the same then the AVI one, while OGM size was 2MB higher). But keep in mind that the seeking entries aren't yet written in the file (well there aren't in OGM either, so it is still good).
I can't say how much room it will take since robUx4 is still coding on this part ...

Bye

robUx4
24th February 2003, 13:09
I'm very very close to finish the seeking part. It will be a matter of days (hours?) now.
I'm very glad that this alpha code already seem to be fast.
For the size, I hoped that it would be smaller or equal to AVI/OGM. Right now there is no protection (ECC/EDC) in the files. But it won't change a lot the overall size.

robUx4
24th February 2003, 13:11
Oh and something you might be happy to know : the matroska files you're creating now will be 100% compatible with beta and release versions of the code :)
(as long as there is no bug on that part ;)

Nic
24th February 2003, 13:21
I know we're getting quite off topic for this forum, but out of my own personal curiosity; how close are you to having a completed matroska DirectShow splitter?

Cheers,
-Nic

ChristianHJW
24th February 2003, 13:57
Originally posted by Nic how close are you to having a completed matroska DirectShow splitter? Cheers, -Nic

No good news here i am afraid to say :( ... our DShow parser developer Jan 'myFUN' Schlenker has started to rewrite his complete parser filter from the old version ( that was linked to old libmcf still ), but is now on vacation for 3 weeks, so we cant expect anything working here in the next weeks. As he also hasnt been uploading what he has got today, nobody else can work on it in the meantime.

In the meantime you guys will have to switch to Linux and use Moritz 'mosu' Bunku's mplayer patch, or wait for Ronald 'BBB' Bultje to finish his gstreamer plugin ( Linux also ).

If spyder would finally concentrate on his EBML4java code instead of making AVISynth filters, we could at least try to save us over the waiting time with a working JMF parser ;) ....

robUx4
24th February 2003, 15:01
Well, I think an AVISynth filter is more than needed ! Who uses JMF and who uses AVISynth ?
And we'll need this filter sooner or later (sooner than later).

MatroskaSourceA() and MatroskaSourceV() ? That could be great :)

spyder
24th February 2003, 15:09
I was thinking about an avisynth filter for reading these files too... It would need VfW to decode for the moment but it's better than nothing :)

Spyder

Nic
24th February 2003, 15:13
Im going to move this thread to the New Formats forum, so we can discuss it more and properly there.

IMHO your efforts should really be to push for the DShow parser/splitter filter, you cant release matroska properly without it unfortunatly. :(

-Nic

robUx4
24th February 2003, 16:47
You're right twice :
- You can move the discussion
- We will wait for a working (basic) DSF before the official launch of the format (ie time when people can use it to test it in all possible cases and report bugs/request features).

ChristianHJW
24th February 2003, 17:24
ahem, guys, can i please point to the original question of this thread ^___^ ... :D :D ??

Nic, irrespective of the delayed matroska Dshow parser ( i have to plan a bit into the nearer future ):

Is it possible to modify your decoder filter such that it will accept matroska's 'native' frame order for MPEG4, being coding order ?

I currently have an offer from somebody who wants to start working on a tool to convert video streams transmuxed in AVI compatibility mode into 'native' streams. Its not a huge task, as all the app had to do is to accept matroska files ( later also AVIs ) on its input, ask the codec what frame is a P or B frame ( I frames are tagged in AVI anyway, so these are set in matroska also in AVI compatibility mode ), change the frame order, cut out ( drop ) the 'dummy' frames and set the matroska element flag for B-frames on those frames that are reported from the codec to be such.

Now, if the job is done, and lets suggest we have a working DShow parser also by that time, how long would it probably take to make your decoder accept the new 'native' frame order ?
Is it possible at all ?
Did we have to use a new GUID for that ( i recommend to use 'V_MPEG4ISO_SAP' , being the native matroska codec ID for MPEG 4 ISO Simple Advanced Profile ) ?

Thanks for a quick answer. I promise i wont bother you than anymore :D !!

Nic
24th February 2003, 18:14
Christian, get a DirectShow parser, and then Ill begin to think about how to take your native streams. ;)

Just kidding ;) Ill have to look into it, because at present it just takes in chunks of data and deals with it accordingly, there is nothing in the DShow thats asking for specific frames/ordering.

The source code for my filter is on my site, so feel free to play around with it or wait till your DShow guy gets back to you :)

Cheers,
-Nic