Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: AAC in AVI container (Read 59342 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AAC in AVI container

Reply #100 –
Quote
MOV is the worst for PC users, i do not care for mac users.

Maybe you should respect other people like Mac users! You only think that mov sucks because nobody has programmed a good Windows program for handling .mov files. I don't believe that something could suck on ly because it lacks general support. The structure of mov files is almost the same as the structure of mpeg-4 files. So if you believe that mpeg-4 is great or at least it works, you just can't say that Quicktime files suck. If you say so you are contradicting yourself!

Lets end this container war immediately! If somebody has something to say about muxing aac to avi then post here. Otherwise create a new topic for your flame war!

AAC in AVI container

Reply #101 –
Quote
it isn't possible with the downloadable version, you can only download version 4.5 on the 3ivx website.
where did you get that 4.5.1 alpha3 ?

That's not the point. Point is that you should
1. Stop posting things like these: "the only good video container are .avi, .mpg and .mp4. avi is the best and .mov is the worst, i hope Matroska will die." (For your own sake, because many people know that .mov and .mp4 are technically almost the same)

2. Stop posting incorrect information as a fact, like ".mp4 are not seekable by frames", when you obviously don't have better knowledge.


If you have to know how I got the version, I'm one the (many) people who have access to 3ivx's alphas.
Juha Laaksonheimo

AAC in AVI container

Reply #102 –
Quote
i hope Matroska will die

Your statement normally doesnt deserve an answer, but i decided to tell you we wont do you the favour  ....

We have

- MPEG1/2 video ( MPEG1 works already half way )
- control tracks ( specs are just being discussed on the ML )
- native MPEG4 ( pretty soon it seems )
- MPC SV 7.5 muxing ( depending on Frank of course )
- menues, compliant with DVD, microDVD and MPEG4 menues
- automated VFR file creation from avisynth
- independant codec API ( based on spyder's MILK )
- USF muxing on binary level, for better hardware support
- Wavpack4 support, for lossles audio editing in VdubMod

all to come within the next 3 months ( for menues and the API i'll add a 'hopefully'  ), so you better prepare to watch matroska grow my friend  ....

AAC in AVI container

Reply #103 –
Quote
Stop posting incorrect information as a fact, like ".mp4 are not seekable by frames", when you obviously don't have better knowledge.
If you have to know how I got the version, I'm one the (many) people who have access to 3ivx's alphas.

i do not post incorrect information, most people do not have this special version

AAC in AVI container

Reply #104 –
Now, look - MPEG-4 as defined by international standard  does not have any problem with frame-based seeking.  The fact that one 3-party implementation had this particular problem is not a big concern, because it is fixed already, and most other implementations do not have this issue.

So, there is nothing wrong in the MP4 files,  but in a particular, already old, version of MP4 file parser (implementation of MPEG-4 file format)

AAC in AVI container

Reply #105 –
Quote
this is a very stupid comment !
i do not post incorrect information, most people do not have this special version

You posted the info like it was general .mp4 related thing. Anyway, I suggest you leave this thread now.
Juha Laaksonheimo

AAC in AVI container

Reply #106 –
It was a bug... jeez

3ivx D4 4.5 supports microsecond accurate seeking, which is frame accurate. (or is it 100th of a microsecond? i forget... its a lot of zeroes anyway)

BUT there was a bug in the "frame based" seeking (ie asking for frame 100,000 would fail)

Yes, it was fixed pretty much immediately after the bug was first discovered.

Yes, the fix will be in the next update

Yes, there is a 4.5.1a3

No, its not available for public download

AAC in AVI container

Reply #107 –
Quote
I see two outcomes to this:

-alexnoe will fail his intent - either by creating unseekable AVIs or unplayable ones. People will laugh at him and noone will use his hack.
-alexnow will fulfill his intent, creating seekable and playable AVIs. People will start using his hack, and Ivan, Christian & etc. will have to swallow their prides.

Moving back to the topic, I think you missed the point of everyone's concern.  The third (most likely) outcome is that he will produce AAC in AVI that are seekable in some players, but not in all.

Nobody wants a bunch of AVI's floating around that will only work in half of the players out there.  There are several other containers that would be able to play back fine in all players with the proper DS filters.

AAC in AVI container

Reply #108 –
If you only think of DirectShow, then i'm almost sure that it works with *all* filters. If I were you, I would worry about systems not using DirectShow, especially those which even b0rk with MP3.
Quote
all to come within the next 3 months ( for menues and the API i'll add a 'hopefully'  ), so you better prepare to watch matroska grow my friend  ....
Only a crystal orb could tell a non-coder when some coding stuff will be finished. Why did you buy yours?

AAC in AVI container

Reply #109 –
AAC in AVI using AviMux-GUI indeed works.
But I would call it an half-success at the moment. Why ? For the following reasons :

1. As for MP3 VBR it uses a little hack to prevent (at least try) out-of-sync issues when seeking. This means that theorically every system working with the MP3 VBR hack should handle AAC in AVI almost out of the box.
That also means that systems that don't handle it will sure have troubles (at worst they will crash).

2. Unlike the MP3 case when you treat the file with tools that can't handle VBR at all (VDub - it could handle VBR but Avery Lee prefers to ensure the audio is treated as CBR, i.e. according to its average byterate, and thus stick to the official M$ AVI specs) or that handle VBR only for specific cases (VirtualDubMod e.g., which handles MP3 VBR using the Nandub trick, but will behave like VirtualDub for any other VBR stream - including AAC) then the output AVI will be unplayable.
Indeed those tools when dealing with the file will break the 'one ADTS frame per chunk' rule and thus you won't find whole RAW data blocks per chunk.
I dunno if it's a limitation of the current decoder (faad) or something almost impossible to deal with but in this case even starting to play the file from the beginning (i.e. serving data as they come, but thus not necessarily full RAW data blocks) make the player (WiMP) crash.
Even if it would work there could be some issues when seeking. Unlikely to MP3, AC3 or DTS the sync headers (ADTS) have been stripped (the same way than in MP4). So when seeking you will start decoding from somewhere you don't know in the RAW AAC stream (and generally not right on a RAW data block, if this matters of course). And there is no more headers to wait for synching. So the decoder have to handle decoding from anywhere in the RAW stream.
Of course I don't know a lot about AAC. So maybe RAW data blocks have no 'real' meaning and maybe you can start decoding from any point in the RAW stream, but right now what I know is that it just crashes.
(AAC gurus can maybe enlighten us here )

AAC in AVI container

Reply #110 –
Quote
Nobody wants a bunch of AVI's floating around that will only work in half of the players out there.

Ah, so you plan on sharing AVIs with AAC? I understand...

AAC in AVI container

Reply #111 –
Quote
Ah, so you plan on sharing AVIs with AAC? I understand...

Nope.  But if I obtain a video clip from somewhere, I don't want to have to try 3 different players before I find one that works.  Or, be called up by a friend that can't get it to work.  It would just mean more trouble for me.

AAC in AVI container

Reply #112 –
It seems that there is a problem of understanding. There is a few different way to perform seeking in DirectShow graphs either based :
- on TIME (100 nano-second units)
- audio SAMPLES
- video FRAMES
- video FIELDS
- bitstream BYTES

It's up to the splitter (or parser or demuxer or source) filter to support whatever method it wants. The default method is TIME, and the 3ivx 4.5 splitter supports it perfectly (this was massively broken in 4.04) i.e. you can ask to seek to a precise time and it will seek to the nearest frame and keep the audio in sync. If the "Use Frame Accurate seeking" is unchecked, the splitter will seek to the nearest keyframe instead of the nearest frame thus enabling very fast seeking.

After that, the 3ivx 4.5 version claims to support FRAME seeking but it doesn't. The 4.5.1a3 version almost does (there are still a couple of problems tho). This FRAME seeking is NOT mandatory at all and a LOT of splitters don't support it (I think M$ .avi and mpeg-1 splitter are the only one to really support it) and a LOT of players don't use it. This FRAME seeking mode is used for example when stepping backward with MPC.

Hope this will make things clearer.

AAC in AVI container

Reply #113 –
Spyder just confirmed that Christian's 3 months are utter nonsense

AAC in AVI container

Reply #114 –
Quote
I dunno if it's a limitation of the current decoder (faad) or something almost impossible to deal with but in this case even starting to play the file from the beginning (i.e. serving data as they come, but thus not necessarily full RAW data blocks) make the player (WiMP) crash.
...
So the decoder have to handle decoding from anywhere in the RAW stream.

To tell the truth I am quite sure that the decoder can (and actually should) handle decoding from anywhere inside the AAC stream. Otherwise I guess you would have troubles with the ADIF system (which only have one header at the beginning of the file and just RAW data afterwards).
But as I said currently the player crashes. So either it's a current problem with the decoder (which will be fixed later) or somehting else (a bug in the DShow filter ? who knows ...).

AAC in AVI container

Reply #115 –
Quote
To tell the truth I am quite sure that the decoder can (and actually should) handle decoding from anywhere inside the AAC stream. Otherwise I guess you would have troubles with the ADIF system (which only have one header at the beginning of the file and just RAW data afterwards).
But as I said currently the player crashes. So either it's a current problem with the decoder (which will be fixed later) or somehting else (a bug in the DShow filter ? who knows ...).

faad2 requires the data passed to be the beginning of a frame.
In aac it is impossible to find a frame boundary unless there is some kind of seektable (MP4) or ADTS headers with syncwords.

And AFAIK you can pretty much feed faad2 random data without crashing it. It will give errors though.

Menno

AAC in AVI container

Reply #116 –
Quote
faad2 requires the data passed to be the beginning of a frame.
In aac it is impossible to find a frame boundary unless there is some kind of seektable (MP4) or ADTS headers with syncwords.

And AFAIK you can pretty much feed faad2 random data without crashing it. It will give errors though.

OK so the decoder have troubles when you start decoding from somehwhere else than the beginning of a frame. But can it somehow synch again when the next frame boudary (even without knowing it is the next frame beginning) is reached ? Or are the next decoded data doomed to be invalid ?

AAC in AVI container

Reply #117 –
Quote
Quote
faad2 requires the data passed to be the beginning of a frame.
In aac it is impossible to find a frame boundary unless there is some kind of seektable (MP4) or ADTS headers with syncwords.

And AFAIK you can pretty much feed faad2 random data without crashing it. It will give errors though.

OK so the decoder have troubles when you start decoding from somehwhere else than the beginning of a frame. But can it somehow synch again when the next frame boudary (even without knowing it is the next frame beginning) is reached ? Or are the next decoded data doomed to be invalid ?

Depends if you put in the ADTS headers. If so, make the frontend for the library seek the next syncword (12 bits 0xFFF) and pass the data from there.

Menno

AAC in AVI container

Reply #118 –
That would somehow mean that ADIF files can't work (at least easily) with faad right ?
Since those files don't have ADTS headers the parser alone can't guarantee to give full RAW blocks. On the other hand the decoder won't decode properly the data if it doesn't get those full RAW blocks.
So in the best case the parser would have to ask the library to decode from the beginning (first RAW block) and get the size of this RAW block (if possible of course) to know where starts the next RAW block, then give this next RAW block, ask again the library its size ...
That would mean that seeking would be a no-go with ADIF, right ?

AAC in AVI container

Reply #119 –
Quote
That would somehow mean that ADIF files can't work (at least easily) with faad right ?
Since those files don't have ADTS headers the parser alone can't guarantee to give full RAW blocks. On the other hand the decoder won't decode properly the data if it doesn't get those full RAW blocks.
So in the best case the parser would have to ask the library to decode from the beginning (first RAW block) and get the size of this RAW block (if possible of course) to know where starts the next RAW block, then give this next RAW block, ask again the library its size ...
That would mean that seeking would be a no-go with ADIF, right ?

The decoder always returns the number of used bytes after decoding a frame.

And yes, ADIF and RAW AAC files can only be seeked by decoding to that point in the file.

Menno

AAC in AVI container

Reply #120 –
Thanks for all the explanations