mkvextract - real content - when?

[hubereevez]

Hi,
i asked this a long time ago....
When can we extract real media video?
Like a member said here before, matroska is suppose to be a container, not a safe....
Other member did ask this too....for editing or resampling media video .....
Please Mosu....you said it was not your prio, but that it would not be so difficult.....
Or if someone could make a tool like this.....
Thanks
hubhub

[ChristianHJW]

I am not sure when Mosu said this wouldnt be difficult, but in fact its not as easy as it sounds.

The main reason for this is, that there is no existing RealMedia muxer code under the GPL license, only demuxers. The Helix code for that is under the RSPL, and thus cant be used AFAIK from mkvmerge ( Karl, please correct me if i'm wrong ).

EDIT : Just to make this clear, i am backing up your request by 100%, and in fact i would be very very happy if this could be done, one way or another, pls. dont misunderstand me ......

[Mosu]

Maybe (!!) I'll look into it this weekend. But that's a pretty big maybe. (which is German for 'not very likely')

[hubereevez]

:rolleyes:
it depends from the region (in baden würtenberg "vielleicht" means "very likely"). I hope you're from this region :p ....
To be serious, check with karl, there's perhaps an easy way to do this....
hubhub

[karl_lillevold]

I agree completely. This is a much needed feature. MKV is great, I use it frequently myself, but for RealNetworks' codecs it is currently a one-way-street to MKV and not back, which is not good for anyone. The problem is that it was decided to not make available the RM writer code in open source. I don't agree with this personally, I have been trying to change it, and will continue, but no luck so far.

The RM file format is pretty well known by now. Mosu and Gabest probably know it better than most engineers at RealNetworks. Even though it would be a tough challenge to implement a stand-alone RM writer from scratch, it is certainly possible for someone with container format experience, and who knows the RM format ;) I don't myself, being 100% codec-centric, but if any questions are sent this way, it is not impossible I could figure out the answers.

[hubereevez]

:D
Yeah,
send question Mosu. I can't imagine, that this feature will not be released, with such a drem team
Thanks both of you two
:)
hubhub

[Mosu]

The good news is that I've decided to work on this now. I've started writing my own 'RealMedia file format access library' based on my own knowledge/source code. It'll replace some of the code I've written for mkvmerge's own Real demuxer. But it will also have a muxing API so that I can easily enhance mkvextract for this. The 'problematic' bits are:

1) I only have mplayer to play back RM files on Linux. The older Linux versions of the RealPlayer don't really support the new features. Maybe I will have to download the Helix player for that? Karl, I guess that the Helix player can also play the newest RM files on Linux?

2) In Matroska RealVideo frames are grouped together. In mkvextract I'll have to re-create those sub-packets. This will probably take most of the time.

3) I don't know how to handle 'logical-fileinfo' tracks and 'INDX' chunks. The latter is probably easy to understand from mplayer's sources (it's not needed for linear reading, but I'll have to write an index with mkvextract), but I don't even know what the former is for.

Anyway, so far I've probably spent over six hours on this, and reading seems to work correctly now. Next will be the integetration of this library into mkvmerge instead of the built-in RealMedia demuxer. Then I can go and write some RM writer routines. But this will take time. So don't expect it to happen too soon. I hope to be able to finish this during the next two or three weeks, but definitely not earlier than that.

BTW: In ffmpeg's libavformat there's a RealMedia muxer. So far I've only taken a quick look at it, but that's where I'll start when I'll be coding my own muxer.

[karl_lillevold]

Mosu: That's great news!

There are some problematic areas in how small video frames and B frames are handled, as I am sure you know from the reader code...

I have not yet tried the Helix Player for Linux myself, but I recently converted my server box at home to SuSE, so I will. It is available for download here pre-compiled (https://helixcommunity.org/beula/download/), and here is the project homepage (https://player.helixcommunity.org/). It is supposed to be able to play all the latest RealMedia formats, but when checking out the source, the codecs are binary only, and I am afraid the RM reader may be as well.

[Mosu]

Originally posted by karl_lillevold
I have not yet tried the Helix Player for Linux myself, but I recently converted my server box at home to SuSE, so I will. It is available for download here pre-compiled (https://helixcommunity.org/beula/download/), and here is the project homepage (https://player.helixcommunity.org/). It is supposed to be able to play all the latest RealMedia formats, but when checking out the source, the codecs are binary only, and I am afraid the RM reader may be as well.

What I need is a player. I also need source code, but that I can figure out myself. But I need some app to test the files I will write, and having only mplayer would not suffice. That's why I want the Helix player - not for its source, but for its playback capabilities.

[ChristianHJW]

Question :

What about a MKV demuxer for Helix ?

[Atamido]

Originally posted by karl_lillevold
The problem is that it was decided to not make available the RM writer code in open source. The funny thing is that RM isn't even a particularly good container format. The design hasn't ever changed and is still in version 1.0. Looking at the specs, its pretty obvious to even me how some bytes could be shaved off here and there.

Perhaps we could just extract it to AVI instead. :p

[Mosu]

I've got something for you guys ;)

Karl: The library I've talked about: here it is. If you want to know what I've written then please take a look at http://www.bunkus.org/videotools/librmff/index.html

Other than that I know have implemented extraction of RealAudio and RealVideo tracks into RealMedia files. mkvextract can create those files. Example from the man page:


Another example. Let's assume you have a Matroska file with one
RealVideo v10 track, one Vorbis audio track and one RealAudio (COOK)
track. The identification output might look like this:

$ mkvmerge -i movie2.mkv
File 'movie2.mkv': container: Matroska
Track ID 1: video (V_REAL/RV40)
Track ID 2: audio (A_VORBIS)
Track ID 3: audio (A_REAL/COOK)

Let's further assume you want only need the video and the RealAudio
track but both in the same output file. This is possible for RealMedia
files by using the same output name for those tracks that you want to
end up in the same file:

$ mkvextract tracks movie2.mkv 1:extracted.rm 3:extracted.rm


Here's the current build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.8.6-build20040321-1.rar

Please report any bugs you find. The files I've created here play fine with mplayer and the Helix DNA player, but I have no other apps I can test them with. There's also the problem that mplayer segfaults after playing my files which may be a problem in either application (mplayer or mine).

[hubereevez]

:) :) :) :)
i'll test it....
when i have time

++
hubhub

[karl_lillevold]

Mosu: that's fantastic news, and very promising! I tried the new mkvextract, and it does create semi-playable RM files. I extracted AC3 and RMVB from two sample MKV files. In my short test case, the resulting RM plays OK in MPC, with a little hickup at the start, but RealPlayer refuses to display any video. I have seen this behavior before with a "suspicious" RM file I have from before (captured with Offline Explorer, I think). So something is not quite right, but I can not say exactly what. I will look into it. Something about keyframes and timestamps perhaps.

In the long test case (1.75 GB total filesize before extract), the resulting RM has the same no video problem in RealPlayer, but also MPC has problems and buffers forever, taking up more and more memory until I have to kill it. This same suspicious RM file that I have from before has the same long MPC buffering, which is odd, since MPC never seems to buffer for local files.

[Mosu]

Originally posted by karl_lillevold
Mosu: that's fantastic news, and very promising! I tried the new mkvextract, and it does create semi-playable RM files. I extracted AC3 and RMVB from two sample MKV files.

At the moment only tracks with a CodecID of V_REAL/* and A_REAL/* are put into a RM container - AC3 would be saved into a .ac3 file. I should have made that clearer in the documentation.

If you have any (not so big) Matroska files that you could upload for me somewhere I'd appreciate it. Like I said, the few test files I've tried here do work, but as mplayer's segfault at the end shows there's still work to be done.

[Atamido]

Originally posted by karl_lillevold
which is odd, since MPC never seems to buffer for local files. MPC will buffer Matroska files that don't contain an index. But who in their right mind would make one of those? ;)

[karl_lillevold]

Mosu: Re: AC3. Yes, I expected AC3 to be put into .ac3. That's the format it originally came from, and is why I used MKV, since I don't think RealPlayer can play AC3 if wrapped in RM (even though an older codec is "AC3-like").

Re: buffering. This happens with the RM file, as extracted from the MKV file. I will see what I can find out what is not quite right about the extracted RM file, that causes this to happen.

[Mosu]

Here's a new build. I've changed how some fields are set, and I've also used the proper MIME type for RealAudio files... Karl, please test this. I don't think it'll make it work, but I won't have time to test on a 'real' Windows installation until tomorrow evening (I only have a Windows running on VMWare at the moment).

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.8.6-build20040322-2.rar

[Mosu]

Ok, back with a fresh Windows XP installation, RealPlayer 10, MPC, RealMediaSplitter etc. I get pretty mixed results.

File 1 is a trailer for Blade 2 (RV40, COOK). File 2 is an old LotR trailer (RV30, COOK). File 3 is a Matroska file that Karl has provided (RV40, AC3).

File 1, original RM: MPC plays without buffering, RM player plays it, too. File 1, muxed to Matroska, then de-muxed back to RM (both tracks in one file): MPC buffers and plays, RM player plays it back instantly and perfectly.

File 2, original RM: MPC and RM play it back instantly and perfectly. Muxed to Matroska, then de-muxed back to RM (both tracks in one file): MPC buffers. Both players play instantly and perfectly.

File 3, de-muxed from Matroska, only the video track: MPC buffers then plays it back. RM player starts playing, resizes the window appropriately but only shows a black window.

[Mosu]

With a little help from my friend Karl I've got some issues ironed out. So if you want to test, make sure you use the latest build available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (which is 20040324-1 at the moment). All the older ones had problems of one kind or the other.

[karl_lillevold]

Mosu has done a great job -- congratulations! I tried to break his latest version with both high and low bitrates, small and large packet sizes, but so far no luck. The extracted RM files are playable in RealPlayer :D Please give it a try on your own Matroska content with Real codecs, because there are a lot of RM variations out there...

[karl_lillevold]

It is really good to have MKV to RM working. However, since there is no RM muxer, it is not yet possible to convert fully back to the original RM. For instance, RV10 + AAC will be extracted to RV10.rm + AAC.aac. It is possible to convert AAC.aac to AAC.rm with dtdrive (new binary release) (http://forum.doom9.org/showthread.php?s=&threadid=73279) but not mux them together (yet).

[Mosu]

Originally posted by karl_lillevold
It is really good to have MKV to RM working. However, since there is no RM muxer, it is not yet possible to convert fully back to the original RM.

For AAC this is true, for other RealAudio codecs (mostly this means COOK) this is false ;) mkvextract accepts the same file name multiple times if the tracks are A_REAL/* or V_REAL/*. So if you have V_REAL/RV40 + A_REAL/COOK in a Matroska file you can use 'mkvextract tracks input.mkv 1:file_output.rm 2:file_output.rm'.

For AAC I'd like to implement this, but I'm not 100% sure about the frame format used. In RM AAC is packaged meaning that several AAC frames are put together into one RM 'frame' (meaning container frame). The format looks like this:

AAAAAAAA BBBBCCCC DDDDDDDD DDDDDDDD ...

with:
- A, eight bits: unknown
- B, four bits: the number of AAC packets in this frame
- C, four bits: unknown
- D, 16 bits: size of an AAC packet, big endian, repeat B times
- Rest: the AAC frames

The As and Cs are what I need to know about :)

[S_O]

Another format can also not be converted back: AC3 (DolbyNET). Unfortuantely the Real Decoder cannot play all kinds of AC3, it is very limited. Only some bitrates are excepted etc. The only thing that is quite sure, bitrate has to be <= 80 kbps and channels <= 2.
- D, 16 bits: size of an AAC packet, big endian, repeat B timesDoes one packet mean one frame? Does that mean VBR AAC is not possible in rmvb? Or is it allowed to have only one frame each block?

[Mosu]

Originally posted by S_O
Another format can also not be converted back: AC3 (DolbyNET). Unfortuantely the Real Decoder cannot play all kinds of AC3, it is very limited. Only some bitrates are excepted etc. The only thing that is quite sure, bitrate has to be <= 80 kbps and channels <= 2.

I know. I probably won't support demuxing AC3 to RM (which would then be DNET).

Does one packet mean one frame? Does that mean VBR AAC is not possible in rmvb? Or is it allowed to have only one frame each block?

The important thing is: 'repeat B times'. Meaning that you have the length of each AAC frame in bytes. Therefore VBR AAC is possible, and you can have up to 15 AAC frames in one RM frame.

Some pseudo (!) code for reading this:

unsigned char *data, *ptr;
int num_packets;
uint16_t aac_frame_lengths[];

num_packets = data[1] >> 4;
ptr = &data[2];
for (i = 0; i < num_packets; i++) {
aac_frame_lengths = read_uint16_big_endian(ptr);
ptr += 2;
}
for (i = 0; i < num_packets; i++) {
// Current AAC frame starts at ptr with length aac_frame_lenghts[i]
ptr += aac_frame_lengths[i];
}

[S_O]

I know. I probably won't support demuxing AC3 to RM (which would then be DNET).Why? If Karl cannot provide us with details about what formats can be decoded (at least all combinations from the AudienceDefaults.xls (where to get an up-to-date version?) should be playable, but I know some other combinations are also possible) mkvextract could simply output a warning that the file might not be playable.
The important thing is: 'repeat B times'.
Ok, then it´s fine, I didn´t read it correctly, I thought you mean D is there only one time and after that packets of size D are repeated B times. Now, if it´s possible to have VBR AAC in rmvb, does Real´s implementation handle that correctly? If not, hopefully they can fix that in Real Player 10 final.

[karl_lillevold]

For AAC this is true, for other RealAudio codecs (mostly this means COOK) this is false mkvextract accepts the same file name multiple times if the tracks are A_REAL/* or V_REAL/*.
Excellent! I did not know, and it works fine on one of my test files. Hopefully Mosu will figure out those unknown bits to also make it work for AAC in RM ;)

Unfortuantely the Real Decoder cannot play all kinds of AC3, it is very limited. Only some bitrates are excepted etc.
This is limited by Dolby licensing. And the dnet decoder is no longer supported in our encoding tools, and not distruted by default in RealPlayer either. It has to auto-update to get it. So in general AC3 in RM is not well supported, which is why I have used Matroska when I have needed to use RealVideo with AC3.

Now, if it´s possible to have VBR AAC in rmvb, does Real´s implementation handle that correctly? If not, hopefully they can fix that in Real Player 10 final.
Yes, VBR AAC in RM plays in RealPlayer. I just verified this using dtdrive to convert one of my Nero VBR AAC streams from M4A to RM. It turns on RealMediaSplitter does not understand all flavors of AAC in RM though, so the dtdrive converted RM files do not currently play with RMSplitter.

[S_O]

Yes, VBR AAC in RM plays in RealPlayer. I just verified this using dtdrive to convert one of my Nero VBR AAC streams from M4A to RM. It turns on RealMediaSplitter does not understand all flavors of AAC in RM though, so the dtdrive converted RM files do not currently play with RMSplitter.
Yust tested it, but without success: File could be played, but length is shown wrong (11 seconds instead of 13) and playback is stuttering at the end. The last 2 seconds are missing completly. Maybe it is fixed with new player, I still have beta installed. I´m waiting for a german version (there is still RealOne to download!).
This is limited by Dolby licensing.
How is it limited?

[karl_lillevold]

Originally posted by S_O
Yust tested it, but without success: File could be played, but length is shown wrong (11 seconds instead of 13) and playback is stuttering at the end. The last 2 seconds are missing completly. Maybe it is fixed with new player, I still have beta installed. I´m waiting for a german version (there is still RealOne to download!).

Is there any way you can PM me a link to this file so I can test it with RealPlayer 10 Gold? If not, I can also provide an upload URL. Thanks!

Originally posted by S_O
How is it limited?
A product that legally wants to play back normal AC3 needs an expensive license from Dolby, and free players need to minimize such costs.

[S_O]

Is there any way you can PM me a link to this file so I can test it with RealPlayer 10 Gold? If not, I can also provide an upload URL. Thanks!
I uploaded the aac-files:
RM: hs_solo.rm (280KB) (http://l.b.oltmanns.bei.t-online.de/hs_solo.rm)
ADTS: hs_solo.aac (273KB) (http://l.b.oltmanns.bei.t-online.de/hs_solo.aac)
File is encoded with FAAC 1.23.5 and plays perfect as normal adts-aac in foobar2000.
A product that legally wants to play back normal AC3 needs an expensive license from Dolby, and free players need to minimize such costs.That´s clear, but how is it limited? What are the rescritions? What ac3 can be decoded (is allowed to be decoded) with your decoder? I know maximum bitrate is 80kbps, but what about samplerates, channels etc.?

[karl_lillevold]

S_O: If you add a few options to dtdrive, it converts the file correctly:

dtdrive +d hs_solo.aac -S 1 -W hs_solo2.rm

d = if writing a file, recompute duration

-S 1 should always be used when writing out RM file, but in this case it is the +d which is really needed to convert the file correctly. I will add this to the dtdrive thread. Thanks.

I don't know exactly how dnet is limited. Sorry.

[achtungfeuer]

thx mosu and it's a really good job!!;)

[hubereevez]

yep thanks
doing some test
:D
hubhub

edit : wow it's even working :) greatttttt!!!!! thanks