Hi, I'd like to suggest the attached patch for demuxing D-Cinema audio. It's not exactly beautiful since it does something like decoding (changing the bit order), but I though it to be the easier solution over adding a special decoder (since it isn't used anywhere else). The smil file that came with it said it was of the format "audio/302m", and I assume it is SMPTE 302M uncompressed audio, but I don't have the specs. Please tell me what you think about it... Oh, some samples (I already extended the MPlayer mpeg demuxer to play the gxf file): Address: ftp://www.ropa-net.de Username: web49f4 Password: 123456 Greetings, Reimar D?ffinger
Hi On Sat, Aug 27, 2005 at 05:08:38PM +0200, Reimar D?ffinger wrote:
Hi, I'd like to suggest the attached patch for demuxing D-Cinema audio. It's not exactly beautiful since it does something like decoding (changing the bit order), but I though it to be the easier solution over adding a special decoder (since it isn't used anywhere else). The smil file that came with it said it was of the format "audio/302m", and I assume it is SMPTE 302M uncompressed audio, but I don't have the specs. Please tell me what you think about it...
uhm, well, messy ... too messy, and we have enough messy code aleady ... [...] -- Michael
Hi, On Wed, Aug 31, 2005 at 03:33:13AM +0200, Michael Niedermayer wrote:
On Sat, Aug 27, 2005 at 05:08:38PM +0200, Reimar D?ffinger wrote:
I'd like to suggest the attached patch for demuxing D-Cinema audio. It's not exactly beautiful since it does something like decoding (changing the bit order), but I though it to be the easier solution over adding a special decoder (since it isn't used anywhere else). The smil file that came with it said it was of the format "audio/302m", and I assume it is SMPTE 302M uncompressed audio, but I don't have the specs. Please tell me what you think about it...
uhm, well, messy ... too messy, and we have enough messy code aleady ...
Hmm... what would be an acceptable solution? Just moving the 24bit weird audio -> "normal" 32bit audio conversion to libavcodec/pcm.c? I would then have to "invent" a new format ID for MPlayer though. Or which part of it is messy? Greetings, Reimar D??ffinger
Hi, On Wed, Aug 31, 2005 at 09:54:19AM +0200, Reimar D?ffinger wrote:
On Wed, Aug 31, 2005 at 03:33:13AM +0200, Michael Niedermayer wrote:
uhm, well, messy ... too messy, and we have enough messy code aleady ...
Hmm... what would be an acceptable solution? Just moving the 24bit weird audio -> "normal" 32bit audio conversion to libavcodec/pcm.c? I would then have to "invent" a new format ID for MPlayer though. Or which part of it is messy?
Ok, I did a quick hack to show what I am thinking about. It is not finished and will not yet work, but before spending more time on it I want to get some comments. Greetings, Reimar D??ffinger
Hi, On Wed, Aug 31, 2005 at 12:55:32PM +0200, Reimar D?ffinger wrote:
Ok, I did a quick hack to show what I am thinking about. It is not finished and will not yet work, but before spending more time on it I want to get some comments.
No reply :-(. Well, I finished it. If you have better suggestions for the names, please go ahead. Any other suggestions for improvement are welcome, too. The macros I introduced in pcm.c are just a suggestion too, especially since the one for encoding do not set the lower bits to 0 for the the 24 and 32 bit formats. Greetings, Reimar D??ffinger
Hi On Thu, Sep 01, 2005 at 07:13:58PM +0200, Reimar D?ffinger wrote:
Hi, On Wed, Aug 31, 2005 at 12:55:32PM +0200, Reimar D?ffinger wrote:
Ok, I did a quick hack to show what I am thinking about. It is not finished and will not yet work, but before spending more time on it I want to get some comments.
No reply :-(.
well, that was because i wasnt entirely happy with it as it converts everything to 16bit in the decoder, we really should finish at least 32bit integer and 32bit float audio support ... but i dont see any disadvantage in it in principle (its better to support these formats by convertng to 16bit then not to support them at all ...)
Well, I finished it. If you have better suggestions for the names, please go ahead. Any other suggestions for improvement are welcome, too.
maybe use av_get_packet() it would make the code 1 or 2 lines shorter
The macros I introduced in pcm.c are just a suggestion too, especially
IMHO they should be changed to inline functions, as thats cleaner, unless of course its slower, that brings us to the next point, it must be benchmarked to ensure its not significantly slower
since the one for encoding do not set the lower bits to 0 for the the 24 and 32 bit formats.
uninitalized bytes are not acceptable, they could messup the regression tests [...] -- Michael
Hi, On Thu, Sep 01, 2005 at 09:59:10PM +0200, Michael Niedermayer wrote:
On Thu, Sep 01, 2005 at 07:13:58PM +0200, Reimar D?ffinger wrote:
No reply :-(.
well, that was because i wasnt entirely happy with it as it converts
No problem, I just like to know if I'm on the right track...
everything to 16bit in the decoder, we really should finish at least 32bit integer and 32bit float audio support ...
I agree, though if you want conversion between all formats you either need lots of conversions or it will be slow :-(. MPlayer tries a compromise by having special functions for conversions that are needed often and a slow function for everything else.
maybe use av_get_packet() it would make the code 1 or 2 lines shorter
I knew I missed something. I was just copying from wav.c, so I guess that could be improved as well (line 341).
The macros I introduced in pcm.c are just a suggestion too, especially
IMHO they should be changed to inline functions, as thats cleaner, unless of course its slower, that brings us to the next point, it must be benchmarked to ensure its not significantly slower
I guess that will depend a lot on the compiler, unfortunately.
uninitalized bytes are not acceptable, they could messup the regression tests
The best way I could thing of was unfortunately doing if (bps > 2) memset(dst, 0, ...). Or not using a macro/inline function, but that makes it a huge mess IMO (though more huge than mess). Not really nice :-( Greetings, Reimar
Hi, On Thu, Sep 01, 2005 at 10:21:57PM +0200, Reimar D?ffinger wrote:
IMHO they should be changed to inline functions, as thats cleaner, unless of course its slower, that brings us to the next point, it must be benchmarked to ensure its not significantly slower
Did that, but did it the lazy way for benchmarking: left the old code and only used the function for the new code. Hope that's acceptable, I mess things up anyway when I try to benchmark things...
uninitalized bytes are not acceptable, they could messup the regression tests
The best way I could thing of was unfortunately doing if (bps > 2) memset(dst, 0, ...).
Did it like that. Awaiting another round of comments. Greetings, Reimar D??ffinger
Hi On Fri, Sep 02, 2005 at 12:08:11AM +0200, Reimar D?ffinger wrote: [...]
uninitalized bytes are not acceptable, they could messup the regression tests
The best way I could thing of was unfortunately doing if (bps > 2) memset(dst, 0, ...).
Did it like that. Awaiting another round of comments.
please use 4 space indention / keep indention consistant within each file [...]
+ short **samples, uint8_t **dst, int n) { + if (bps > 2) + memset(*dst, 0, n * bps); + if (le) *dst += bps - 2; + for(;n>0;n--) { + register int v = *(*samples)++; + if (us) v += 0x8000; + (*dst)[le] = v >> 8; + (*dst)[1 - le] = v & 0xff;
isnt the & 0xff redundant here? [...]
+ for (i = 0; i < 16; i++) { + tmp2 <<= 1; + tmp2 |= (tmp & 1); + tmp >>= 1; + }
should be ff_reverse[tmp>>8] + (ff_reverse[tmp&0xFF]<<8) [...] -- Michael
Hi, On Fri, Sep 02, 2005 at 01:02:36AM +0200, Michael Niedermayer wrote:
please use 4 space indention / keep indention consistant within each file
Right. I'm so used to using 2 spaces it's hard to do it differently.
+ (*dst)[1 - le] = v & 0xff;
isnt the & 0xff redundant here?
Yes, missed the fact that the destination was only one byte big anyway *g*
[...]
+ for (i = 0; i < 16; i++) { + tmp2 <<= 1; + tmp2 |= (tmp & 1); + tmp >>= 1; + }
should be ff_reverse[tmp>>8] + (ff_reverse[tmp&0xFF]<<8)
Wow. Nice. And fast. Though including bistream.h looks a bit weird. Thanks for all the help, it really looks a lot nicer than the first version. Is it close to being acceptable now? Greetings, Reimar
Hi On Fri, Sep 02, 2005 at 11:18:56AM +0200, Reimar D?ffinger wrote:
Hi, On Fri, Sep 02, 2005 at 01:02:36AM +0200, Michael Niedermayer wrote:
please use 4 space indention / keep indention consistant within each file
Right. I'm so used to using 2 spaces it's hard to do it differently.
+ (*dst)[1 - le] = v & 0xff;
isnt the & 0xff redundant here?
Yes, missed the fact that the destination was only one byte big anyway *g*
[...]
+ for (i = 0; i < 16; i++) { + tmp2 <<= 1; + tmp2 |= (tmp & 1); + tmp >>= 1; + }
should be ff_reverse[tmp>>8] + (ff_reverse[tmp&0xFF]<<8)
Wow. Nice. And fast. Though including bistream.h looks a bit weird. Thanks for all the help, it really looks a lot nicer than the first version. Is it close to being acceptable now?
yes, feel free to apply it [...] -- Michael
Hi, On Fri, Sep 02, 2005 at 01:00:40PM +0200, Michael Niedermayer wrote:
yes, feel free to apply it
Unfortunately found a few bugs in final testing with ffmpeg. Changes against last patch: 1) size_out and frame_size calculation for new formats (ffmpeg.c and libavformat/utils.c). 2) make libavutil/wav.c recognize the new formats 3) fixes to the en/decode_from/to16 function (a missing () and "fixing" the dst and src pointers after processing for little-endian). Greetings, Reimar D??ffinger
Hi On Fri, Sep 02, 2005 at 08:24:59PM +0200, Reimar D?ffinger wrote:
Hi, On Fri, Sep 02, 2005 at 01:00:40PM +0200, Michael Niedermayer wrote:
yes, feel free to apply it
Unfortunately found a few bugs in final testing with ffmpeg. Changes against last patch: 1) size_out and frame_size calculation for new formats (ffmpeg.c and libavformat/utils.c). 2) make libavutil/wav.c recognize the new formats 3) fixes to the en/decode_from/to16 function (a missing () and "fixing" the dst and src pointers after processing for little-endian).
all ok, apply it [...] -- Michael
Michael Niedermayer wrote:
Hi
On Fri, Sep 02, 2005 at 08:24:59PM +0200, Reimar D?ffinger wrote:
Hi, On Fri, Sep 02, 2005 at 01:00:40PM +0200, Michael Niedermayer wrote:
yes, feel free to apply it
Unfortunately found a few bugs in final testing with ffmpeg. Changes against last patch: 1) size_out and frame_size calculation for new formats (ffmpeg.c and libavformat/utils.c). 2) make libavutil/wav.c recognize the new formats 3) fixes to the en/decode_from/to16 function (a missing () and "fixing" the dst and src pointers after processing for little-endian).
there is abug in decode_to16 documentation : us description is missing
Hi, On Fri, Sep 02, 2005 at 09:02:01PM +0200, matthieu castet wrote:
there is abug in decode_to16 documentation : us description is missing
You scared me when I saw "bug" *g*. Anyway, added documentation for that (also for encode_from16). Greetings, Reimar
Hi On Wed, Aug 31, 2005 at 09:54:19AM +0200, Reimar D?ffinger wrote:
Hi, On Wed, Aug 31, 2005 at 03:33:13AM +0200, Michael Niedermayer wrote:
On Sat, Aug 27, 2005 at 05:08:38PM +0200, Reimar D?ffinger wrote:
I'd like to suggest the attached patch for demuxing D-Cinema audio. It's not exactly beautiful since it does something like decoding (changing the bit order), but I though it to be the easier solution over adding a special decoder (since it isn't used anywhere else). The smil file that came with it said it was of the format "audio/302m", and I assume it is SMPTE 302M uncompressed audio, but I don't have the specs. Please tell me what you think about it...
uhm, well, messy ... too messy, and we have enough messy code aleady ...
Hmm... what would be an acceptable solution? Just moving the 24bit weird audio -> "normal" 32bit audio conversion to libavcodec/pcm.c? I would then have to "invent" a new format ID for MPlayer though. Or which part of it is messy?
everything, you dont even know if its SMPTE 302M, its just a guess from "302M" or did i miss something? further note, the title of 302M is "Television- Mapping of AES3 Data into MPEG-2 Transport Stream" so its supposed to be in a MPEG-TS, how can your proposed "convert it to 32bit" demuxer ever work with that? also note, AES3 specs can be downloaded freely from http://www.aes.org/publications/standards/ [...] -- Michael
Hi, On Wed, Aug 31, 2005 at 01:10:29PM +0200, Michael Niedermayer wrote:
everything, you dont even know if its SMPTE 302M, its just a guess from "302M" or did i miss something?
Yes, a guess from the mime type of the playlist file. I had to give it _some_ name after all (and hoped that maybe somebody here knows the facts). Unless you don't want it to be supported at all I just need a point to start fixing it, this is my first attempt at this anyway...
so its supposed to be in a MPEG-TS, how can your proposed "convert it to 32bit" demuxer ever work with that?
Looks like it's something else.
also note, AES3 specs can be downloaded freely from http://www.aes.org/publications/standards/
Thanks will have a look at that, though the description sounds like something completely different... Greetings, Reimar D??ffinger
Hi Michael Niedermayer wrote:
Hi
On Wed, Aug 31, 2005 at 09:54:19AM +0200, Reimar D?ffinger wrote:
Hi, On Wed, Aug 31, 2005 at 03:33:13AM +0200, Michael Niedermayer wrote:
On Sat, Aug 27, 2005 at 05:08:38PM +0200, Reimar D?ffinger wrote:
I'd like to suggest the attached patch for demuxing D-Cinema audio. It's not exactly beautiful since it does something like decoding (changing the bit order), but I though it to be the easier solution over adding a special decoder (since it isn't used anywhere else). The smil file that came with it said it was of the format "audio/302m", and I assume it is SMPTE 302M uncompressed audio, but I don't have the specs. Please tell me what you think about it... uhm, well, messy ... too messy, and we have enough messy code aleady ... Hmm... what would be an acceptable solution? Just moving the 24bit weird audio -> "normal" 32bit audio conversion to libavcodec/pcm.c? I would then have to "invent" a new format ID for MPlayer though. Or which part of it is messy?
everything, you dont even know if its SMPTE 302M, its just a guess from "302M" or did i miss something? further note, the title of 302M is "Television- Mapping of AES3 Data into MPEG-2 Transport Stream"
so its supposed to be in a MPEG-TS, how can your proposed "convert it to 32bit" demuxer ever work with that?
also note, AES3 specs can be downloaded freely from http://www.aes.org/publications/standards/
[...]
OK Im one year late. I actually got a TS containing 302M audio and indeed the sample Reimar refers to is the PES stream extracted from a TS. That file is 20 bit per sample AES3 stream, containing LPCM. Then I think it would be better to rename daud.c to s302m.c (or aes3.c) That file could contain some functions needed to extract sample from bitstream AVBitStreamFilter ?, and codec/sample rate/bits per sample infos. Im trying to implement an AES3 stream parser/filter for my ts file and my mxf files containing AES3. I guess AVBitstreamFilter is the best option, how could it be automatically activated when I detect such a stream ? Samples in AES are LSB first, maybe PCM_S24DAUD should be renamed to PCM_S20LSBF ? What do you guys think ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
participants (4)
-
baptiste.coudurier＠smartjog.com -
castet.matthieu＠free.fr -
michaelni＠gmx.at -
Reimar.Doeffinger＠stud.uni-karlsruhe.de