aften-devel Mailing List for Aften
Status: Beta
Brought to you by:
jbr79
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(58) |
Sep
(45) |
Oct
(76) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(102) |
Feb
(93) |
Mar
(58) |
Apr
(2) |
May
(14) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(4) |
Oct
(4) |
Nov
(19) |
Dec
(12) |
2008 |
Jan
(9) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Grozdan <neu...@gm...> - 2013-10-23 20:37:21
|
Hi, I noticed Justin posted back in 2008 a patch for E-AC-3 support. Can someone tell me when this will be added to Aften? |
From: Kip W. <ki...@th...> - 2012-06-11 01:43:25
|
On Fri, 2010-07-09 at 15:25 +0200, Klaus Schnass wrote: > Some time ago I ported the alsa a52 plugin to libaften. The port can be found > at [1]. Raw aplay output should work fine but recently a few problems with the > new openal software from [2] have cropped up and i did not yet have the time > to debug. > > best regards, > Klaus > > [1] http://git.devilshawk.net/a52_plugin/ > get all with 'git clone git://devilshawk.net/a52_plugin' > [2] http://kcat.strangesoft.net/openal.html Hey Klauss, Thanks for the heads up. One thing I am confused about is how the devilshawk git repository you pointed me to relates to this one, <git://aften.git.sourceforge.net/gitroot/aften/aften>. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com |
From: Klaus S. <de...@st...> - 2010-07-09 13:46:16
|
On Friday, July 09, 2010 03:51:21 am Kip Warner wrote: > Hey gang. I'm working on a free commercial game called Avaneya > (https://www.avaneya.com). I'd like to be able to have users enjoy > surround sound when they have an A52 capable receiver, such as like > those found in the Logitech Z-5500. > > If you scroll down to the "Audio Hardware" section, you'll find the > dilemna I am confronted with. > > https://www.avaneya.com/faq.html#sysreq > > OpenAL will be doing the mixing, and, assuming I can get a raw output > LPCM stream coming out of it, I will be able to pass that through an > external library A52 encoder for S/PDIF passthrough. Since there are > likely experienced and knowledgeable people here, I'd like advice on > which library and anything else they might recommend for doing this. > > Also, do to patent issues, this feature would be disabled by default and > have to be enabled manually at ./configure time. Some time ago I ported the alsa a52 plugin to libaften. The port can be found at [1]. Raw aplay output should work fine but recently a few problems with the new openal software from [2] have cropped up and i did not yet have the time to debug. best regards, Klaus [1] http://git.devilshawk.net/a52_plugin/ get all with 'git clone git://devilshawk.net/a52_plugin' [2] http://kcat.strangesoft.net/openal.html |
From: Prakash P. <pr...@pu...> - 2009-12-07 19:32:27
|
Am Donnerstag 03 Dezember 2009 20:24:20 schrieb P. Hotz: > Hello, > > I've got a problem concerning Aften: > > I downloaded and installed the current svn snapshot of Aften. So > according to the outputs of cmake and make Aften has been successfuly > compiled and installed. However when I try to compile AC3Jack I get the > following error: > > checking aften/aften.h usability... yes > checking aften/aften.h presence... yes > checking for aften/aften.h... yes > checking for aften_encode_init in -laften... no > configure: error: 'Could not find libaften! Is it installed?' > > I already copied libaften_static.a to /usr/local/lib/. Hi, I haven't scanned through the logs yet, but how did you "install" aften? Did you copy also libaften.so* to above location? I am actually not sure whether /usr/local/lib lib belongs to the default search path. libaften_static.a won't help you - unless you rename it to libaften.a. Cheers, Prakash |
From: P. H. <p....@on...> - 2009-12-03 19:24:46
|
Hello, I've got a problem concerning Aften: I downloaded and installed the current svn snapshot of Aften. So according to the outputs of cmake and make Aften has been successfuly compiled and installed. However when I try to compile AC3Jack I get the following error: checking aften/aften.h usability... yes checking aften/aften.h presence... yes checking for aften/aften.h... yes checking for aften_encode_init in -laften... no configure: error: 'Could not find libaften! Is it installed?' I already copied libaften_static.a to /usr/local/lib/. I am no linux geek and found nothing helpful on the internet so I'd be very glad if someone could assist me. I added CMakeError.log and CMakeOutput.log as attachments in case the are helpful to identify the problem. I am using the 32 bit varian of Ubuntu 9.04. Thanks in advance Regards Peter |
From: Ihar H. <iha...@gm...> - 2009-08-30 22:40:54
|
Hello! I propose the following patch to link aften binary with libaften.so shared library if it's compiled. Shared linkage can lower memory footprint when several programs use the same libaften functions. Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 843) +++ CMakeLists.txt (working copy) @@ -283,7 +283,11 @@ # When linking to static aften, dllimport mustn't be used SET_TARGET_PROPERTIES(aften_exe PROPERTIES COMPILE_FLAGS -DAFTEN_BUILD_LIBRARY) ENDIF(WIN32) -TARGET_LINK_LIBRARIES(aften_exe aften_pcm aften_static) +IF(SHARED) + TARGET_LINK_LIBRARIES(aften_exe aften_pcm aften) +ELSE(SHARED) + TARGET_LINK_LIBRARIES(aften_exe aften_pcm aften_static) +ENDIF(SHARED) ADD_EXECUTABLE(wavinfo util/wavinfo.c) TARGET_LINK_LIBRARIES(wavinfo aften_pcm) |
From: Justin R. <jus...@gm...> - 2008-10-18 19:07:11
|
Hi, I added a feature which changed the API. AftenEncParams.params.expstr_fast is now AftenEncParams.expstr_search. I changed the commandline option from -fes to -exps which has a value from 1 to 32. This gives finer control over speed vs. quality. The new list of choices for exponent strategy sets are the same as those in the E-AC-3 spec (A/52B table E2.14). I ran tests on many source files to come up with a priority list of the most commonly used sets. -Justin |
From: Jose A. P. <jap...@te...> - 2008-02-21 03:27:50
|
Testing NicAudio decoder I found some bugs with channelmapping in Aften: aften -acmod 4 -lfe 1 211.wav 211.ac3 aften -acmod 6 -lfe 0 220.wav 220.ac3 aften -acmod 6 -lfe 1 221.wav 221.ac3 2/1.1 produce L, R, S, LFE (LFE <-> S) 2/2.0 produce L, R, SR, empty_channel 2/2.1 produce L, R, SR, LFE, SL instead (LFE, SL, SR) All other acmod/lfe combinations work fine. Verified with Sonic Foundry SoftEncode Tebasuna |
From: Justin R. <jus...@be...> - 2008-02-02 22:29:30
|
Prakash Punnoor wrote: > Hi, > > I merged the needed infrastructure into aften, though I still might need to > make some API changes and additional clean-up. Attached are the missing > (rough) files (still w/o proper (c) ;-) which won't get merged until EAC-3 > support is in so that license is clean LGPL. Great. I'll have a look at it. > I would like to get rid of ffmpeg bitsream stuff as it is an unmaintainable > nightmare. I haven't looked closely at the bitio stuff. Can it do the job? Do > I need the version from flake? Or is bitstream reading missing? At least the > aften one doesn't seem to be able to read bits. The one in Flake is essentially the same as in Aften. I like the libvorbis bitstream reader better than the FFmpeg one. That's what I use in some of my other projects. -Justin |
From: Prakash P. <pr...@pu...> - 2008-02-02 18:08:54
|
On the day of Saturday 02 February 2008 Prakash Punnoor hast written: > Hi, > > I merged the needed infrastructure into aften, though I still might need = to > make some API changes and additional clean-up. Attached are the missing > (rough) files (still w/o proper (c) ;-) which won't get merged until EAC-3 > support is in so that license is clean LGPL. > > I would like to get rid of ffmpeg bitsream stuff as it is an unmaintainab= le > nightmare. I haven't looked closely at the bitio stuff. Can it do the job? > Do I need the version from flake? Or is bitstream reading missing? At lea= st > the aften one doesn't seem to be able to read bits. > I forgot to mention that by generalizing the infrastructure threaded=20 transcoding works, but last time I checked I get different md5sum with 1 vs= 2=20 threads. I don't know whether some bugs are left in the decoder, or whether= =20 the encoder is still not bitidentical in threaded mode - or some of the glu= e=20 code misses something... Cheers, =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Prakash P. <pr...@pu...> - 2008-02-02 18:06:14
|
Hi, I merged the needed infrastructure into aften, though I still might need to make some API changes and additional clean-up. Attached are the missing (rough) files (still w/o proper (c) ;-) which won't get merged until EAC-3 support is in so that license is clean LGPL. I would like to get rid of ffmpeg bitsream stuff as it is an unmaintainable nightmare. I haven't looked closely at the bitio stuff. Can it do the job? Do I need the version from flake? Or is bitstream reading missing? At least the aften one doesn't seem to be able to read bits. Cheers, -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V |
From: Justin R. <jus...@be...> - 2008-01-20 04:54:22
|
Prakash Punnoor wrote: > Hi, > > I noticed you changed something about the exp processing. Please run a check > with valgrind, as I am getting > > Conditional jump or move depends on uninitialised value(s) > ==28702== at 0x429E23: sse2_process_exponents > > I haven't investigated further as I was busy checking in the common code. ;-) thanks for the info. it is fixed. -Justin |
From: Prakash P. <pr...@pu...> - 2008-01-19 11:30:16
|
Hi, I noticed you changed something about the exp processing. Please run a chec= k=20 with valgrind, as I am getting Conditional jump or move depends on uninitialised value(s) =3D=3D28702=3D=3D at 0x429E23: sse2_process_exponents I haven't investigated further as I was busy checking in the common code. ;= =2D) Cheers, =2D-=20 (=C2=B0=3D =3D=C2=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Justin R. <jus...@be...> - 2008-01-14 05:29:48
|
Justin Ruggles wrote: > E-AC3 TODO list > --------------- > better VBR (don't need to stick to AC3 frame sizes) Here is a new version of the patch which takes advantage of E-AC3's ability to use incremental frame sizes. This leads to an extremely accurate and constant snr offset when using VBR encoding mode. -Justin |
From: Justin R. <jus...@be...> - 2008-01-14 05:00:06
|
Hi, Here is a patch to add E-AC3 encoding to Aften. It's only basic support right now. The only metadata that is written is dialnorm and drc. Also, it only supports 6-block encoding, so the bitrate is limited. But it's still more than AC3. You can go up to 1024kbps @ 48kHz. I haven't tested it extensively, but it seems to be working well for everything I've tried so far. I'm not sure if this should be added to Aften quite yet though. I really want to get coupling added in Aften before things get anymore complex. E-AC3 TODO list --------------- support fewer blocks for higher bitrates better VBR (don't need to stick to AC3 frame sizes) figure out how reduced samplerates work using Nero decoder add option to write metadata more channels (7.1) AHT encoding (VQ and GAQ quantization) -Justin |
From: Justin R. <jus...@be...> - 2008-01-13 23:26:29
|
Prakash Punnoor wrote: > On the day of Sunday 13 January 2008 Justin Ruggles hast written: >> Justin Ruggles wrote: >>> Prakash Punnoor wrote: >>>> BTW, why do we encode all blocks in one shot instead of one after th= e >>>> other like the decoder does? This could save us some memory footprin= t. >>> For encoding, bit allocation has to be done at the frame level, not t= he >>> block level. For decoding you don't have to worry about it because t= he >>> parameters are already there in the bitstream. >> I was thinking a bit more about this. If we wanted to do everything a= t >> the block level, there is a way to do it. The quality would probably >> suffer slightly, but memory requirements would go down a lot. > [...] >> I don't know if it would be possible to make this an option or if the >> whole encoder would just have to change. Also, I don't know if it wou= ld >> even be worth it. But it's worth some thought anyway. >=20 > Hi, it is an interesting idea, but I really don't think it is worth it,= unless=20 > you want to have aften run on your cellphone. ;-) True, but if it can be done simply... The exponent part is already in-place with the -fes option. I'll add it to the TODO list so I can remember to experiment with it someday. :) > Anyways, I wanted to ask how far the eac3 merging is? I cleaned up=FC m= y patch a=20 > lot by replaceing stuff from bitalloc.c with the common code. I also th= ink I=20 > have eliminated most of the table dupes. It's very close. In fact, it's about ready, I just need to do the time-consuming task of making a set of clean patches and going through the review process. Unfortunately, the decoder is not feature complete due to lack of samples which use enhanced coupling and spectral extension= =2E > Is there any special naming you prefer? I want to get rid of the ff_ac3= _blah.=20 > Esp ac3 should be replaced with a52 to be consistent. I think the commo= n code=20 > has no license problems? I could then start pushing this first and fina= lly=20 > the decoder one the license issue is sorted out. There are only a few things which use the ff_ac3_blah...just shared functions and tables. Putting a52_ in front instead would be fine. The shared bit allocation code is very solidly LGPL. It was part of the FFmpeg AC3 encoder long ago, and was just adapted for use with the AC3 decoder. -Justin |
From: Prakash P. <pr...@pu...> - 2008-01-13 21:31:34
|
On the day of Sunday 13 January 2008 Justin Ruggles hast written: > Justin Ruggles wrote: > > Prakash Punnoor wrote: > >> BTW, why do we encode all blocks in one shot instead of one after the > >> other like the decoder does? This could save us some memory footprint. > > > > For encoding, bit allocation has to be done at the frame level, not the > > block level. For decoding you don't have to worry about it because the > > parameters are already there in the bitstream. > > I was thinking a bit more about this. If we wanted to do everything at > the block level, there is a way to do it. The quality would probably > suffer slightly, but memory requirements would go down a lot. [...] > I don't know if it would be possible to make this an option or if the > whole encoder would just have to change. Also, I don't know if it would > even be worth it. But it's worth some thought anyway. Hi, it is an interesting idea, but I really don't think it is worth it, unl= ess=20 you want to have aften run on your cellphone. ;-) Anyways, I wanted to ask how far the eac3 merging is? I cleaned up=FC my pa= tch a=20 lot by replaceing stuff from bitalloc.c with the common code. I also think = I=20 have eliminated most of the table dupes. Is there any special naming you prefer? I want to get rid of the ff_ac3_bla= h.=20 Esp ac3 should be replaced with a52 to be consistent. I think the common co= de=20 has no license problems? I could then start pushing this first and finally= =20 the decoder one the license issue is sorted out. bye, =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Justin R. <jus...@be...> - 2008-01-13 18:54:31
|
Justin Ruggles wrote: > Prakash Punnoor wrote: >> BTW, why do we encode all blocks in one shot instead of one after the other >> like the decoder does? This could save us some memory footprint. > > For encoding, bit allocation has to be done at the frame level, not the > block level. For decoding you don't have to worry about it because the > parameters are already there in the bitstream. I was thinking a bit more about this. If we wanted to do everything at the block level, there is a way to do it. The quality would probably suffer slightly, but memory requirements would go down a lot. First issue is determining exponent strategy. Currently, we compare exponents from block-to-block to see when reusing them is better in order to transmit them more frequently. Well, if we only want to encode a block at a time, we can just choose a middle-of-the-road strategy such as [D25 R R D25 R R]. Second issue is bit allocation. We will always know the number of header bits, and if we have a fixed exponent strategy, we will always know the number of exponent bits. For mantissa bits, we could just divide them up evenly between blocks. Then for each block, the leftover bits would go back into the pool to divide up for the next block. block 0 gets 1/6 of remaining bits block 1 gets 1/5 of remaining bits block 2 gets 1/4 of remaining bits block 3 gets 1/3 of remaining bits block 4 gets 1/2 of remaining bits block 5 gets all remaining bits I don't know if it would be possible to make this an option or if the whole encoder would just have to change. Also, I don't know if it would even be worth it. But it's worth some thought anyway. -Justin |
From: Justin R. <jus...@be...> - 2008-01-01 18:35:57
|
Hi, Prakash Punnoor wrote: > Hi and happy new year, Happy New Year!! >> merged so that we can have the ability to transcode from E-AC3 to AC3. > > Yes, that was my isea as well, as simple ac3 to ac3 transcoding is not that > useful (unless some p2p pirates ;-) want to keep ac3 sound but reduce > bitrate....) It could also be useful to modify metadata. >> I like the concept, but I'm not too sure about the API. Maybe it is >> okay, but definitely needs to handle not getting a full frame. > > I know, but if I am not totally mistaken, I made it that way by the return > type and the "wanted_bytes" parameter you can extract that information. I > know the parameter name sucks, as in successful case the naming is wrong, > because then it has the meaning of how much of input buffer was used... > Perhaps I should just name it to framesize, then it fits the bill in > successful and unsuccessful case. It's still not quite right, but I can't think of anything better. > We probably should provide an enum of error codes (something the encoder needs > as well). Furthermore we should provide means of hooking in a logger, as > writing to stdout/stderr is not very useful for GUIs. I whole-heartedly agree. > The basic mode of operation we have to decide on is: > > a) (Like now) The decoder barfs if not enough data is fed into it and asks for > more and the user has to refed it with more data. > > b) (Like LAME does, afaik) ... user has to provide ADDITIONAL data, ie, every > date once fed is kept in an internal fifo (like I also do with C# bindings > for aften). I think this mode is more natural to use. It looks to me like LAME uses a form of (a) with the added option of setting the buffer size to 0 to indicate not to check the size. I think we should do something similar, but maybe just skip the check if it is >= 4096 since that will hold any AC3 or E-AC3 frame. >> This can >> be determined with just the first 5 bytes of the frame, and it should be >> very easy to write a small function that takes 5 bytes and outputs the >> frame size. > > This is even more important for threaded transcoding. The main thread has to > determine the framesize to be able to feed the appropriate pieces of data to > the worker threads. So the initial bits of parsing have to be somewhat > factored out. The AC3 parser in FFmpeg pretty much does the same. >> The bit allocation functions would probably be the only duplicated code. > > OK, so seems like some work to do. :-) Yeah, not too much though. The functions should be exactly the same, we might just have to change the function arguments to work with either encoding or decoding. >> Another reason to wait until E-AC3 support is added is the license. I >> noticed you stripped out the GPL header from ac3dec.c. ;) > > It was the other way round. ;-) I forgot to add it, as for the main file I > started with an empty file and copied to needed functions and fields > iteratively. > >> That file is >> GPL because the student who started the decoder last summer used liba52 >> as a reference without anyone knowing it. > > Yes I once read about it in the ffmpeg devel list, so OK, sounds very > reasonable to wait for eac3 support out of licensing issues. But I suggest > the first commit shouldn't need to have eac3 support for transcoding. This > could be added at a later stage. I don't like working off tree for long > periods of time and then resync to it every then and now... That's fine, but if we mix in GPL code into Aften, even temporarily, we need to provide a way to disable it and have the rest of the program still work. >> P.S. you'll need to get rid of the hard tabs too :) > > Yes, I know. It is my default and only before I commit I replace them with > spaces. No commiting, no replacing. ;-) ok. -Justin |
From: Prakash P. <pr...@pu...> - 2008-01-01 13:06:44
|
Hi and happy new year, > For encoding, bit allocation has to be done at the frame level, not the > block level. For decoding you don't have to worry about it because the > parameters are already there in the bitstream. Ah, OK that explains it, thx. > merged so that we can have the ability to transcode from E-AC3 to AC3. Yes, that was my isea as well, as simple ac3 to ac3 transcoding is not that= =20 useful (unless some p2p pirates ;-) want to keep ac3 sound but reduce=20 bitrate....) > I like the concept, but I'm not too sure about the API. Maybe it is > okay, but definitely needs to handle not getting a full frame. I know, but if I am not totally mistaken, I made it that way by the return= =20 type and the "wanted_bytes" parameter you can extract that information. I=20 know the parameter name sucks, as in successful case the naming is wrong,=20 because then it has the meaning of how much of input buffer was used...=20 Perhaps I should just name it to framesize, then it fits the bill in=20 successful and unsuccessful case. We probably should provide an enum of error codes (something the encoder ne= eds=20 as well). Furthermore we should provide means of hooking in a logger, as=20 writing to stdout/stderr is not very useful for GUIs. The basic mode of operation we have to decide on is: a) (Like now) The decoder barfs if not enough data is fed into it and asks = for=20 more and the user has to refed it with more data. b) (Like LAME does, afaik) ... user has to provide ADDITIONAL data, ie, eve= ry=20 date once fed is kept in an internal fifo (like I also do with C# bindings= =20 for aften). I think this mode is more natural to use. > This can=20 > be determined with just the first 5 bytes of the frame, and it should be > very easy to write a small function that takes 5 bytes and outputs the > frame size. This is even more important for threaded transcoding. The main thread has t= o=20 determine the framesize to be able to feed the appropriate pieces of data t= o=20 the worker threads. So the initial bits of parsing have to be somewhat=20 factored out. > The bit allocation functions would probably be the only duplicated code. OK, so seems like some work to do. :-) > Another reason to wait until E-AC3 support is added is the license. I > noticed you stripped out the GPL header from ac3dec.c. ;) It was the other way round. ;-) I forgot to add it, as for the main file I= =20 started with an empty file and copied to needed functions and fields=20 iteratively. > That file is=20 > GPL because the student who started the decoder last summer used liba52 > as a reference without anyone knowing it. Yes I once read about it in the ffmpeg devel list, so OK, sounds very=20 reasonable to wait for eac3 support out of licensing issues. But I suggest= =20 the first commit shouldn't need to have eac3 support for transcoding. This= =20 could be added at a later stage. I don't like working off tree for long=20 periods of time and then resync to it every then and now... > P.S. you'll need to get rid of the hard tabs too :) Yes, I know. It is my default and only before I commit I replace them with= =20 spaces. No commiting, no replacing. ;-) =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Justin R. <jus...@be...> - 2007-12-31 23:08:26
|
Hi, Prakash Punnoor wrote: > It is just a Proof of Concept for now, so it needs some major cleaning up > (probably API wise, as well). At least it works and is blazing fast compared > to regular decoding and reencoding, as I can skip imdct and mdct. For now not > much of the output stream can be configured, except bitrate and the like. I like the concept, but I'm not too sure about the API. Maybe it is okay, but definitely needs to handle not getting a full frame. This can be determined with just the first 5 bytes of the frame, and it should be very easy to write a small function that takes 5 bytes and outputs the frame size. > So I would like to get it merged somehow after some cleanup iterations. Any > major objections? If not, I guess we should try to minimize code duplication > between encoder and decoder... The bit allocation functions would probably be the only duplicated code. Another reason to wait until E-AC3 support is added is the license. I noticed you stripped out the GPL header from ac3dec.c. ;) That file is GPL because the student who started the decoder last summer used liba52 as a reference without anyone knowing it. Then when I was about half done cleaning up the code, I noticed. So at that point it was already a mixture of the student's own work, GPL code from liba52, and my modifications/additions. Michel Lespinasse has agreed to allow relicensing to LGPL if the decoder is modified to include E-AC3 support, and like I said earlier, that won't be too long. That said, we'll also have to treat the E-AC3 a little differently when transcoding to AC3. Since it can use 1, 2, 3, or 6 blocks per frame, they will have to be grouped together into frame sets with 6 total blocks. This should be easy though, and is already built into the E-AC3 bitstream format. The FFmpeg E-AC3 decoder doesn't pay any attention to this since it doesn't really care how many blocks are in the frame. Thanks, Justin P.S. you'll need to get rid of the hard tabs too :) |
From: Justin R. <jus...@be...> - 2007-12-31 11:17:23
|
Prakash Punnoor wrote: > Hi, > > out of curiosity I played with the ac3 decoder in ffmpeg and loosely > integrated it into aften for transcoding support. Attached is my hacked > together version. There is no support in the aften exe, but in the lib. A > test.c file shows the suggested usage. The contents of the archive must go > into libaften/decoder. The diff in the dir must be applied at aften root. > > It is just a Proof of Concept for now, so it needs some major cleaning up > (probably API wise, as well). At least it works and is blazing fast compared > to regular decoding and reencoding, as I can skip imdct and mdct. For now not > much of the output stream can be configured, except bitrate and the like. > > It is single threaded as well, but I guess it shouldn't be very hard to > parallelize it, I guess. > > So I would like to get it merged somehow after some cleanup iterations. Any > major objections? If not, I guess we should try to minimize code duplication > between encoder and decoder... Great! I'll have a look after work today. > BTW, why do we encode all blocks in one shot instead of one after the other > like the decoder does? This could save us some memory footprint. For encoding, bit allocation has to be done at the frame level, not the block level. For decoding you don't have to worry about it because the parameters are already there in the bitstream. I've been working very diligently on adding E-AC3 decoding support to the FFmpeg AC3 decoder. So I think this should wait until that is merged so that we can have the ability to transcode from E-AC3 to AC3. Should be within a week or so if I'm lucky. -Justin |
From: Prakash P. <pr...@pu...> - 2007-12-31 09:06:02
|
Hi, out of curiosity I played with the ac3 decoder in ffmpeg and loosely integrated it into aften for transcoding support. Attached is my hacked together version. There is no support in the aften exe, but in the lib. A test.c file shows the suggested usage. The contents of the archive must go into libaften/decoder. The diff in the dir must be applied at aften root. It is just a Proof of Concept for now, so it needs some major cleaning up (probably API wise, as well). At least it works and is blazing fast compared to regular decoding and reencoding, as I can skip imdct and mdct. For now not much of the output stream can be configured, except bitrate and the like. It is single threaded as well, but I guess it shouldn't be very hard to parallelize it, I guess. So I would like to get it merged somehow after some cleanup iterations. Any major objections? If not, I guess we should try to minimize code duplication between encoder and decoder... BTW, why do we encode all blocks in one shot instead of one after the other like the decoder does? This could save us some memory footprint. -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V |
From: Cameron C. <ca...@so...> - 2007-12-19 16:52:14
|
Hi, On 12/18/07 7:30 PM, "Justin Ruggles" <jus...@be...> wrote: > Hi, > > Cameron Christensen wrote: >> Hi, >> >> I'm trying to create a universal binary of aften for use with Mac OSX. I am >> using an intel machine and I'm unable to build for ppc (just builds an i386 >> binary) or for both platforms (I believe it fails while building the ppc >> portion). >> >> I'm not very familiar with cmake, and searching the internet and >> documentation hasn't helped me much in regard to this problem. >> >> To control which architecture is built, I set >> CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386 in CMakeCache.txt (or pass -D >> CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386 to cmake initially). >> >> The output when building ppc (CMAKE_OSX_ARCHITECTURES:STRING=ppc) looks >> normal except that it appears to build the files in the x86 directory. >> >> The output when both architectures are chosen shows an error when building >> the x86 files and an error from lipo. >> >> Both outputs are included below: > > Could you provide "make VERBOSE=1" output for compiling both? > After investigating this issue further, I have discovered that cmake doesn't yet support cross-compiling: http://www.cmake.org/Wiki/CMake_Cross_Compiling. There does appear to be some preliminary support for creating universal binaries, as indicated from these entries in the VTK FAQ: http://www.cmake.org/Wiki/VTK_FAQ#Can_VTK_be_built_as_a_Universal_Binary_on_ Mac_OS_X.3F and http://www.cmake.org/Wiki/Cocoa_VTK. However, they indicate that bugs do appear in the binaries for the alternate platform. On a positive note, I am able to build a ppc binary with no trouble when using a ppc machine, and also I can use lipo to create a universal binary from the ppc and i386 binaries. With all this in mind, I'm inclined to wait for cmake to improve their cross compiling support before attempting to get this working. Cheers, Cameron |
From: Justin R. <jus...@be...> - 2007-12-19 02:30:30
|
Hi, Cameron Christensen wrote: > Hi, > > I'm trying to create a universal binary of aften for use with Mac OSX. I am > using an intel machine and I'm unable to build for ppc (just builds an i386 > binary) or for both platforms (I believe it fails while building the ppc > portion). > > I'm not very familiar with cmake, and searching the internet and > documentation hasn't helped me much in regard to this problem. > > To control which architecture is built, I set > CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386 in CMakeCache.txt (or pass -D > CMAKE_OSX_ARCHITECTURES:STRING=ppc;i386 to cmake initially). > > The output when building ppc (CMAKE_OSX_ARCHITECTURES:STRING=ppc) looks > normal except that it appears to build the files in the x86 directory. > > The output when both architectures are chosen shows an error when building > the x86 files and an error from lipo. > > Both outputs are included below: Could you provide "make VERBOSE=1" output for compiling both? Thanks, Justin |