Joining 3GPP

[tomb2]

Did a fair amount of searching and didn't find anything so I thought I would start a thread on this. If I messed up on my search, please forgive this newbie and point me in the right direction. The closest I could come was here (http://forum.doom9.org/showthread.php?s=&postid=589102#post589102). If this is new, here goes...

Most cell phones now have "video" capability although the quality is terrible. This will be increasing soon with 3GPP as some providers start to exploit that.

One of the things that MIGHT help is joining without recompressing these already marginal quality files - but I can find no way to do this. 3GPP uses either MP4 or H.263 for video at 128x96 or 176x144 at around 80/128Kbs with AMR audio at 12.2Kbs. Streaming is limited to about 100Kbs(?) and download to about 150Kbs(?).

Is there a utility or program out there that would do this? If not what are the suggestions for demuxing the clips, joining the video and then the audio and finally remuxing them? Or is there a better way (I hope)?

I have worked with 320x240 PDAs so this resolution and framerate is a major step down for me, but surprisingly, it doesn't look half bad on a Nokia 6230, the size of a small candy bar. At 64Kbs it holds sync but the picture is unwatchable for me. At 100Kbs, it can only support up to three minutes without sync drift (V-85Kbs/A-12.2Kbs - 128x96x10fps).

EDIT: When I say the picture isn't half bad don't expect to watch your favorite widescreen feature film. This is only good for shows with plenty of close-ups. 20th Century mothers used to holler at night "You are going to go blind reading Conan Doyle under the blankets with a flashlight!" In the 21st Century mothers will holler "You are going to go blind watching Conan O'Brien on your Nokia under the blankets!"

[bond]

tools coming to my mind which might be able to join .3gp are
- quicktime pro
- ulead studio8 (with the 3gpp) plugin

[tomb2]

Bond, thanks for your support. I am a tad reluctant to pay for Quicktime Pro (no demo version) or Ulead Studio8 (could not load the plug-ins for the demo) without knowing they will do the job. If anyone could take a look at these for butting 3GPPs and then exporting as a pass-through master 3GPP, I would buy the recommended program and do a full report back here. I know I could find working versions of both programs but I don't want to go that route.

Here is what I found on an Apple board from a member with thousands of posts:

"I did do a little experimenting with QT 6.51 in Windows98SE and I am afraid there is no way using QT to combine 3gp files and save back out as pure 3gp files without re-encoding. What you can do is combine them and then save them (without reencoding) as 3gp files that have a QT .mov wrapper around them. If you are only going to play the combined files in QT Player that is fine but if you need to play them in applications that are expecting pure 3gp files then QT is not the application to use to join them. Unfortunately, I have no idea what would be the proper application for such joining of your 3gp files."

[tomb2]

To continue this information, I was able to talk to an Apple QuickTime Pro Tech in Boston (through a third party) and this is definately not possible right now. In fact the tech said that there would not only be recompression but that Quicktime would wind up dropping the AMR codec. As far as Ulead, it appears their 3GPP plug-in only works with the full program not the demo. If anyone here has the program and plug-in working and can post a report here - please do!

So the simple answer is that there is no commercial solution out there for lossless 3GPP manipulation through butt edit pass-throughs (3GPP joining). Since most cellphones now do video and 3GPP seems to be the format of choice, it seems it might be worth the while of some of the compression pros here to come up with a solution. Since these phones already outdo PDAs in numbers, it would also be good to look at refining compression routines and formulas to produce better looking / sounding 100Kb 3GPP files for mobile playbacks.

[tomb2]

Any ideas?

[bond]

well maybe you will not come around and try the old method: demux the streams to raw, join the raw streams via dos commandline "join", and remux again into .3gp

demux/remux can be done with latest mp4box (part of the gpac project) afaik

[tomb2]

Bond, thanks for your very helpful pointers I will try this tonight. Your compression knowledge is amazing. I have read your posts over the years and your FAQs and posts are very clear and easy to understand in an area that is usually too technical and dense for average readers.

When you get around to it, I have always been confused on a few MPEG issues. First B-frames have always been a part of the MPEG1 standard, yet the earliest ASF and DivX files only used I and P frames yet were 30% smaller then MPEG1 files but 50% more processor intense in decoding. So with no B frames, where was the more efficient compression coming from and why was decoding more complex? Also, there is an apparent contradiction in 3GPP containers which usually wrap H.263 video and AMR audio codecs. However 3GPP is also supposed to support "MP4" video. So what is this the old container in a container trick or is this wrong?

Thanks again for your help - you should start the "Bond College of Compression Sciences!" I know a lot of "experts" who could stand spending some time with you...

[bond]

Originally posted by tomb2
Bond, thanks for your very helpful pointers I will try this tonight. Your compression knowledge is amazing. I have read your posts over the years and your FAQs and posts are very clear and easy to understand in an area that is usually too technical and dense for average readers.thanks a lot :)
but basically i know nothing compared to the gurus around on this board :D

When you get around to it, I have always been confused on a few MPEG issues. First B-frames have always been a part of the MPEG1 standard, yet the earliest ASF and DivX files only used I and P frames yet were 30% smaller then MPEG1 files but 50% more processor intense in decoding.hm i never really dealt with mpeg-1, but b-frames are not the only addition that has been done in mpeg-4. afaik mpeg-1 dealt with fullpixel motion search precision whereas mpeg-4 can go down to quarterpel, four times more precise. also the blocksizes where fixed to 16x16 i think whereas mpeg-4 can also go down additionally to 8x8...
also i am not sure about this, but maybe b-frames were specified for mpeg-1 but not really used (as i said i never really use mpeg-1)?

Also, there is an apparent contradiction in 3GPP containers which usually wrap H.263 video and AMR audio codecs. However 3GPP is also supposed to support "MP4" video. So what is this the old container in a container trick or is this wrong?hm the .3gp container basically is the same as the .mp4 container (not exactly so you cant really simply rename the extensions)
people often mix "mp4" and "mpeg-4". in that case it means that .3gp is also defined by 3gpp for storage of mpeg-4 video (as produced by divx5, xvid...). its not like you store full .mp4 files again in .3gp or so

basically its all a question of what is defined by a standardisation body. technically you can also store amr and h.263 in .mp4 of course, but its not standardised, so hardly anyone does it (i think some mobile phones do)

[tomb2]

Didn't get to run the tests yet, but I found and downloaded mp4box. I am assuming I will be able to find the command strings I will need to demux and mux. I am also thinking with that, I might actually be able to use a program like QuickTime Pro to do a lot of the work and then pull what I need from the mov container and transfer to 3GPP. Does that sound right? I have never used QT.

Bond, don't sell yourself short - your work is very good. My work has been 100% with mobile compressions so 98% of my work has been with MPEG1 over the past five years. I was always interested in MPEG4 because of its compression efficiency, but could never use it because the available hardware would choke at 320x240 until the current generation of PDAs. Most of the cool things you mention for MPEG4 are pretty recent and actually require more information than an MPEG1 system stream. That would nail down higher processor overhead, but still doesn't account for smaller file sizes. That would be interesting to know.

Now we come to a very interesting paradox. MPEG4 has been too much for the relatively beefy processors in PDAs yet it is working on several less sophisticated Symbian cell phones. Part of that is the low resolution and framerate but it is still weird. It makes sense that a lower bitrate drives things in wireless but you REALLY have to tweak your compressions otherwise they look like crap.

BTW - you mention in your FAQ that MPEG4 is open standard. I am not sure that is the right phrase. MPEG1 is 100% open but MPEG2 and MPEG4 are not. In fact part of the confusion about using MPEG4 for me a few years ago was that there was no one to go to pay for a legal commercial use. Later, MPEG LA was set up to levy use fees for the patent license portfolios that make MPEG4 work. End users have not had to pay for this yet, but anyone who manufactures an MPEG4 player or wants to use the "rebel" codec DivX commercially sure does. For what it is worth, one thing I didn't see in your FAQ is info explaining H.263 and H.264.

Finally coming up to speed in a "newer" area of compression is a bit strange. You mentioned other seasoned pros. Who are the players here? One of the hardest things in this area has always been finding the people who really know what they are speaking about. I started out in '97 with the function of P and B frames reversed for several months because MPEG was new and the only info out there was coming from people who sometimes didn't really know. I wasn't kidding about "Bond College!" ;)

[stephanV]

Originally posted by bond
hm i never really dealt with mpeg-1, but b-frames are not the only addition that has been done in mpeg-4. afaik mpeg-1 dealt with fullpixel motion search precision whereas mpeg-4 can go down to quarterpel, four times more precise. also the blocksizes where fixed to 16x16 i think whereas mpeg-4 can also go down additionally to 8x8...
also i am not sure about this, but maybe b-frames were specified for mpeg-1 but not really used (as i said i never really use mpeg-1)?

MPEG1 does have B-frames and they are used. The difference with MPEG1 (+MPEG2 i guess) and MPEG4 is that it has a fixed GOP size and structure. For MPEG1 it is common to have something like this for one GOP:

IBBP BBP BBP BBP BBP

this structure will get constantly repeated throughout the file. For MPEG4 the ordening of frames and selection of frame type is in principle adaptive, so you can have:

IPBP BPBB PPPPBB IBPBPBP I IPPP

in one file. This adaptiveness is probably why it more difficult to implement B-frames. MPEG1 doesnt really "think" where MPEG4 does.

Originally posted by tomb2
BTW - you mention in your FAQ that MPEG4 is open standard. I am not sure that is the right phrase. MPEG1 is 100% open but MPEG2 and MPEG4 are not.
You are confusing "open" with "free". Anyone can create a MPEG4 encoder and distribute as long as they pay for the licensing fees. This is not so for example with VP6 or RV9, only those companies can make those encoders.

BTW - I don't think MPEG1 is free from licensing either, its just that no one seems to care.

[tomb2]

StephanV thanks for the correction on open and free. As far as MPEG1, I have never run into anyone looking for fees. Maybe I was lucky?

You are right on the MPEG1 GOP except that the user can dictate what that is (for instance, IIII - becomes a MS-AVI with no temporal compression). So an adoptive GOP in MPEG4 is actually pretty cool (I didn't know about that). I used to play with that manually in MPEG1 sections as needed for some very small and good quality compressions. One thing that no one mentioned about MPEG1 were the fixed framerates. MPEG4 is really great that way - you can do one frame per second if you want without worrying about skip frames.

The question remains though - what makes MPEG4 files compress so much smaller then MPEG1 at the same framerates? Both systems use discrete cosine transfer and both now use B frames with much finer compression detail for MPEG4. Theoretically, MPEG4 files should actually be larger!

Oh and if you have any thoughts on 3GPP before I dive into that tonight, please post them!

[stephanV]

Originally posted by tomb2
StephanV thanks for the correction on open and free. As far as MPEG1, I have never run into anyone looking for fees. Maybe I was lucky?

No not really, MPEG1 is not really big bussiness for anyone. No one cares what happens with it. I think MPEG-LA is mainly concerned about MPEG2 and MPEG4-AVC (not ASP).


You are right on the MPEG1 GOP except that the user can dictate what that is (for instance, IIII - becomes a MS-AVI with no temporal compression).

yes i know you can do that, but i have no idea what you mean with MS-AVI comment... AVI is a container format...


The question remains though - what makes MPEG4 files compress so much smaller then MPEG1 at the same framerates? Both systems use discrete cosine transfer and both now use B frames with much finer compression detail for MPEG4. Theoretically, MPEG4 files should actually be larger!
It's newer, more advanced technology? It's like asking why a formula 1 car runs faster than racing cars from 40 years ago, while the size of the f-1 engine is probably much smaller.

I think to understand someone would have to give you a review about compression technology, of which im not capable.


Oh and if you have any thoughts on 3GPP before I dive into that tonight, please post them!
I have no thoughts or ideas about 3gpp whatsoever... :D

[gotaserena]

I've tried it. I've used mp4creator for the job (but I imagine MP4Box wouldn't make things different)

It works beautifully with the video, the tracks are appended as they should.

The audio is a different thing. I know very little about amr, but cat'ing the tracks together merges the sound. Trying to be clear: by
cat file1.amr file2.amr > file.amr
the tracks get [b]superimposed[b], and not appended.

Now, one should be able to get around this silly detail easily -- by using the right tool to merge the amr files. It's just that I couldn't do it.

[tomb2]

Gotaserena thanks for the info! I tried using MP4Box last night and could not get it to open the 3GPP files (worked fine with MP4). I am too new in this area to figure out what I did wrong so I will try your suggestion. Have no clue on AMR but will get back to everyone on this thread once I solve this! Thanks to EVERYONE for all the help on this!

EDIT: Gotaserena, my newbiness is really getting in the way here. How in the heck did you demux, join and remux the H.263 video in the 3GPP file? I can't even open 3GPP let alone work on it! :) As far as the audio, what program did you use to Catenate? Are those commands for mp4creator?

[gotaserena]

I created the .3gp files using ffmpeg (they play well in quicktime, so I figure they would on a phone). FFMPEG usually places the video track on "track 1" and the audio track on "track 2" in a .mp4/.3gp file.

If you have mpeg4ip compiled, you can also use "mp4info" ou "mp4creator -list" to list the tracks and their types.

So I just use "mp4creator -extract=1 file.3gp" to get the raw video file and "mp4creator -extract=2 file.3gp" to get the amr file. I joined then the unix way (cat). The DOS command is "copy /b file1.xvid + file2.xvid file.xvid". I don't know how to join .amr files.

After joining, you can use "mp4creator file.xvid -rate=15 -force3GPCompliance file.3gp" and "mp4creator file.amr -force3GPCompliance file.3gp" (same target) to join the files. Or ffmpeg: "ffmpeg -i file.m4v -i file.amr -fps 15 -vcodec copy -acodec copy file.3gp". If you use ffmpeg, please let me know if the resulting movie was playable in your phone. FFMPEG also needs the suffix of the file, so I'd recommend you to stick to "m4v" and "amr".

You need mp4creator version 1.2 to author .3gp files. I believe that celtic_druid has a compile on his page.

[tomb2]

Gotaserena - MAMA! It would have taken me a week to sort all of this out. Thanks for all of your help. It is pretty cool how people help each other out here. Pretty cool! :)