[PATCH] GSM-MS decoder and encoder
-- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
On Wed, Feb 14, 2007 at 03:29:23PM +0100, Michel Bardiaux wrote:
--- libavcodec/libgsm.c (revision 7975) +++ libavcodec/libgsm.c (working copy) @@ -24,22 +25,35 @@
+// The idiosyncrasies of GSM-in-WAV are explained at http://kbs.cs.tu-berlin.de/~jutta/toast.html
Note: If you are familiar with those idiosyncrasies, they would be a welcome addition to the multimedia Wiki.
--- libavcodec/avcodec.h (revision 7975) +++ libavcodec/avcodec.h (working copy) @@ -227,7 +227,7 @@ CODEC_ID_WESTWOOD_SND1, - CODEC_ID_GSM, + CODEC_ID_GSM, /* As in Berlin toast format */
Commit this right away. Diego
Diego Biurrun wrote:
+// The idiosyncrasies of GSM-in-WAV are explained at http://kbs.cs.tu-berlin.de/~jutta/toast.html
Note: If you are familiar with those idiosyncrasies, they would be a welcome addition to the multimedia Wiki.
I'm not as familiar as they are, so I would end up poaching their text. If the multimedia wiki (url?) needs text on GSM, you should ask Jutta Degener first.
--- libavcodec/avcodec.h (revision 7975) +++ libavcodec/avcodec.h (working copy) @@ -227,7 +227,7 @@ CODEC_ID_WESTWOOD_SND1, - CODEC_ID_GSM, + CODEC_ID_GSM, /* As in Berlin toast format */
Commit this right away.
Just this line or the whole patch? HaND, -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Diego Biurrun wrote:
+// The idiosyncrasies of GSM-in-WAV are explained at http://kbs.cs.tu-berlin.de/~jutta/toast.html
Note: If you are familiar with those idiosyncrasies, they would be a welcome addition to the multimedia Wiki.
I'm not as familiar as they are, so I would end up poaching their text. If the multimedia wiki (url?) http://wiki.multimedia.cx/index.php?title=Main_Page
Ben
On Wed, Feb 14, 2007 at 03:51:16PM +0100, Michel Bardiaux wrote:
Diego Biurrun wrote:
+// The idiosyncrasies of GSM-in-WAV are explained at http://kbs.cs.tu-berlin.de/~jutta/toast.html
Note: If you are familiar with those idiosyncrasies, they would be a welcome addition to the multimedia Wiki.
I'm not as familiar as they are, so I would end up poaching their text. If the multimedia wiki (url?) needs text on GSM, you should ask Jutta Degener first.
What, you don't know the multimedia Wiki? htp://wiki.multimedia.cx/ Any information is welcome, big or little, poached or not.
--- libavcodec/avcodec.h (revision 7975) +++ libavcodec/avcodec.h (working copy) @@ -227,7 +227,7 @@ CODEC_ID_WESTWOOD_SND1, - CODEC_ID_GSM, + CODEC_ID_GSM, /* As in Berlin toast format */
Commit this right away.
Just this line or the whole patch?
I meant just this line. I can't comment on the rest of the patch. Diego
Diego Biurrun wrote:
On Wed, Feb 14, 2007 at 03:51:16PM +0100, Michel Bardiaux wrote:
Diego Biurrun wrote:
+// The idiosyncrasies of GSM-in-WAV are explained at http://kbs.cs.tu-berlin.de/~jutta/toast.html Note: If you are familiar with those idiosyncrasies, they would be a welcome addition to the multimedia Wiki. I'm not as familiar as they are, so I would end up poaching their text. If the multimedia wiki (url?) needs text on GSM, you should ask Jutta Degener first.
What, you don't know the multimedia Wiki?
htp://wiki.multimedia.cx/
Any information is welcome, big or little, poached or not.
Well, I dont poach, so all I would do without a go-ahead from Jutta would be to add a link to their site. And I dont like wikis much either. I dont like things that change all the time.
--- libavcodec/avcodec.h (revision 7975) +++ libavcodec/avcodec.h (working copy) @@ -227,7 +227,7 @@ CODEC_ID_WESTWOOD_SND1, - CODEC_ID_GSM, + CODEC_ID_GSM, /* As in Berlin toast format */ Commit this right away. Just this line or the whole patch?
I meant just this line. I can't comment on the rest of the patch.
I dont see the point, but if you think its useful... -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
On Wed, Feb 14, 2007 at 04:21:49PM +0100, Michel Bardiaux wrote:
Diego Biurrun wrote:
On Wed, Feb 14, 2007 at 03:51:16PM +0100, Michel Bardiaux wrote:
Diego Biurrun wrote:
+// The idiosyncrasies of GSM-in-WAV are explained at http://kbs.cs.tu-berlin.de/~jutta/toast.html Note: If you are familiar with those idiosyncrasies, they would be a welcome addition to the multimedia Wiki. I'm not as familiar as they are, so I would end up poaching their text. If the multimedia wiki (url?) needs text on GSM, you should ask Jutta Degener first.
What, you don't know the multimedia Wiki?
htp://wiki.multimedia.cx/
Any information is welcome, big or little, poached or not.
Well, I dont poach, so all I would do without a go-ahead from Jutta would be to add a link to their site.
That would be helpful already. If you ask Jutta and she's fine with it, even better..
And I dont like wikis much either. I dont like things that change all the time.
You don't like FFmpeg?
--- libavcodec/avcodec.h (revision 7975) +++ libavcodec/avcodec.h (working copy) @@ -227,7 +227,7 @@ CODEC_ID_WESTWOOD_SND1, - CODEC_ID_GSM, + CODEC_ID_GSM, /* As in Berlin toast format */ Commit this right away. Just this line or the whole patch?
I meant just this line. I can't comment on the rest of the patch.
I dont see the point, but if you think its useful...
It's not a big deal, do whatever suits you best. Diego
Diego Biurrun wrote:
On Wed, Feb 14, 2007 at 04:21:49PM +0100, Michel Bardiaux wrote:
Diego Biurrun wrote:
On Wed, Feb 14, 2007 at 03:51:16PM +0100, Michel Bardiaux wrote:
Diego Biurrun wrote:
+// The idiosyncrasies of GSM-in-WAV are explained at http://kbs.cs.tu-berlin.de/~jutta/toast.html Note: If you are familiar with those idiosyncrasies, they would be a welcome addition to the multimedia Wiki. I'm not as familiar as they are, so I would end up poaching their text. If the multimedia wiki (url?) needs text on GSM, you should ask Jutta Degener first. What, you don't know the multimedia Wiki?
htp://wiki.multimedia.cx/
Any information is welcome, big or little, poached or not. Well, I dont poach, so all I would do without a go-ahead from Jutta would be to add a link to their site.
That would be helpful already.
I'll try to find the time.
If you ask Jutta and she's fine with it, even better..
Oh no oh no, I *hate* writing doc!
And I dont like wikis much either. I dont like things that change all the time.
You don't like FFmpeg?
With a passion.
--- libavcodec/avcodec.h (revision 7975) +++ libavcodec/avcodec.h (working copy) @@ -227,7 +227,7 @@ CODEC_ID_WESTWOOD_SND1, - CODEC_ID_GSM, + CODEC_ID_GSM, /* As in Berlin toast format */ Commit this right away. Just this line or the whole patch? I meant just this line. I can't comment on the rest of the patch. I dont see the point, but if you think its useful...
It's not a big deal, do whatever suits you best.
Diego
-- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
On Wed, Feb 14, 2007 at 05:07:14PM +0100, Michel Bardiaux wrote:
Diego Biurrun wrote:
On Wed, Feb 14, 2007 at 04:21:49PM +0100, Michel Bardiaux wrote:
If you ask Jutta and she's fine with it, even better..
Oh no oh no, I *hate* writing doc!
Well, everybody does, but then it never gets done ...
And I dont like wikis much either. I dont like things that change all the time.
You don't like FFmpeg?
With a passion.
You dislike it with a passion? :) Well, now you're helping to make it change all the time ;-p Diego
Hi On Wed, Feb 14, 2007 at 03:29:23PM +0100, Michel Bardiaux wrote: [...]
// gsm.h miss some essential constants #define GSM_BLOCK_SIZE 33 +#define GSM_MS_BLOCK_SIZE 65 #define GSM_FRAME_SIZE 160
static int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000) + if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000)
is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? [...]
@@ -356,6 +357,10 @@ put_le16(pb, 16); /* fwHeadFlags */ put_le32(pb, 0); /* dwPTSLow */ put_le32(pb, 0); /* dwPTSHigh */ + } else if (enc->codec_id == CODEC_ID_GSM_MS) { + put_le16(pb, 2); /* wav_extra_size */ + hdrsize += 2; + put_le16(pb, 320); /* wSamplesPerBlock */
isnt this simply avctx->frame_size ? i mean hardcoding 320 looks a little ugly unless its really needed ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
Michael Niedermayer wrote:
Hi
On Wed, Feb 14, 2007 at 03:29:23PM +0100, Michel Bardiaux wrote: [...]
// gsm.h miss some essential constants #define GSM_BLOCK_SIZE 33 +#define GSM_MS_BLOCK_SIZE 65 #define GSM_FRAME_SIZE 160
static int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000) + if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000)
is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM?
Yes and no. The last 4 bits of each frame are not actually used, they come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate. (A lot of people would have been spared a lot of sweat if ETSI had simply required these 4 bits as mandatory zero padding, and had specified the order of bits in bytes, which proves again that common sense is not an attribute of standardization bodies...)
[...]
@@ -356,6 +357,10 @@ put_le16(pb, 16); /* fwHeadFlags */ put_le32(pb, 0); /* dwPTSLow */ put_le32(pb, 0); /* dwPTSHigh */ + } else if (enc->codec_id == CODEC_ID_GSM_MS) { + put_le16(pb, 2); /* wav_extra_size */ + hdrsize += 2; + put_le16(pb, 320); /* wSamplesPerBlock */
isnt this simply avctx->frame_size ? i mean hardcoding 320 looks a little ugly unless its really needed ...
Right. Changed that. But then you must be very unhappy about the next lines in that source: } else if (enc->codec_id == CODEC_ID_ADPCM_IMA_WAV) { put_le16(pb, 2); /* wav_extra_size */ hdrsize += 2; put_le16(pb, ((enc->block_align - 4 * enc->channels) / (4 * enc->channels)) * 8 + 1); /* wSamplesPerBlock */ which duplicate what is in adpcm_encode_init. Should I change them in another patch (there doesnt seem to be an official maintainer for riff.c) 2 more notes about GSM: I will contact Jutta Degener to have FFMPEG added to their (Berlin's) list of applications using GSM. And I will add the TOAST file format at some point (33-byte frames stored raw). Greetings, -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Hi On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Wed, Feb 14, 2007 at 03:29:23PM +0100, Michel Bardiaux wrote: [...]
// gsm.h miss some essential constants #define GSM_BLOCK_SIZE 33 +#define GSM_MS_BLOCK_SIZE 65 #define GSM_FRAME_SIZE 160
static int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000) + if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000)
is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM?
Yes and no. The last 4 bits of each frame are not actually used, they come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate.
but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ...
(A lot of people would have been spared a lot of sweat if ETSI had simply required these 4 bits as mandatory zero padding, and had specified the order of bits in bytes, which proves again that common sense is not an attribute of standardization bodies...)
fully agree
[...]
@@ -356,6 +357,10 @@ put_le16(pb, 16); /* fwHeadFlags */ put_le32(pb, 0); /* dwPTSLow */ put_le32(pb, 0); /* dwPTSHigh */ + } else if (enc->codec_id == CODEC_ID_GSM_MS) { + put_le16(pb, 2); /* wav_extra_size */ + hdrsize += 2; + put_le16(pb, 320); /* wSamplesPerBlock */
isnt this simply avctx->frame_size ? i mean hardcoding 320 looks a little ugly unless its really needed ...
Right. Changed that. But then you must be very unhappy about the next lines in that source:
} else if (enc->codec_id == CODEC_ID_ADPCM_IMA_WAV) { put_le16(pb, 2); /* wav_extra_size */ hdrsize += 2; put_le16(pb, ((enc->block_align - 4 * enc->channels) / (4 * enc->channels)) * 8 + 1); /* wSamplesPerBlock */
which duplicate what is in adpcm_encode_init. Should I change them in another patch (there doesnt seem to be an official maintainer for riff.c)
simplifications are always welcome ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
Michael Niedermayer wrote:
Hi
On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi [snip]
is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? Yes and no. The last 4 bits of each frame are not actually used, they come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate.
but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont
I think you're talking codec-level padding here, but I wrote of container overhead.
also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ...
AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes. The only reason the muxer 'gets' the padding bits, is because the muxing API is byte-oriented, which is a very useful but not 100% correct assumption. There is also a pragmatic reason to avoid stating 13200 as bitrate for non-MS-GSM: because it is not intuitive, most users will end up asking on -user why it is not the 13000 that everyone expects. Do we need one more FAQ?
[snip] -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Hi On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi [snip]
is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? Yes and no. The last 4 bits of each frame are not actually used, they come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate.
but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont
I think you're talking codec-level padding here, but I wrote of container overhead.
also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ...
AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes.
well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
Michael Niedermayer wrote:
Hi [snip]
well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
Applied. -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michael Niedermayer wrote:
Hi
On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi [snip] is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? Yes and no. The last 4 bits of each frame are not actually used, they come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate. but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont I think you're talking codec-level padding here, but I wrote of container overhead.
also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ... AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes.
well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding. Can I remove it ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Michael Niedermayer wrote:
Hi
On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi [snip] is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? Yes and no. The last 4 bits of each frame are not actually used, they come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate. but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont I think you're talking codec-level padding here, but I wrote of container overhead.
also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ... AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes. well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding.
Can I remove it ?
Oops, forgot I am maintainer for libgsm! Since bitrate is also irrelevant for encoding, what about this? -- Michel Bardiaux http://www.mediaxim.com/
Hi, Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michael Niedermayer wrote:
Hi
On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote: > Hi [snip] > is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? Yes and no. The last 4 bits of each frame are not actually used, they come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate. but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont I think you're talking codec-level padding here, but I wrote of container overhead.
also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ... AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes. well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding.
Can I remove it ?
Oops, forgot I am maintainer for libgsm!
Since bitrate is also irrelevant for encoding, what about this?
------------------------------------------------------------------------
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 12579) +++ libavcodec/libgsm.c (working copy) @@ -36,8 +36,10 @@ #define GSM_FRAME_SIZE 160
static av_cold int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000) + if (avctx->channels > 1 || avctx->sample_rate != 8000) return -1; + if (avctx->bit_rate != 13000) + av_log(avctx, AV_LOG_WARNING, "Bit rate %d instead of expected 13000 - ignored\n");
Well, Im not really ok to annoy user with a false message, when decoding this is irrelevant. What is this check good for, since bitrate is irrelevant ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michael Niedermayer wrote:
Hi
On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote: > Michael Niedermayer wrote: >> Hi [snip] >> is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? > Yes and no. The last 4 bits of each frame are not actually used, they > come on stage only because we (both libgsm and lavc) use a > byte-oriented > API, and files made of bytes. They should be considered as container > overhead in TOAST files, hence not part of the codec bitrate. but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont I think you're talking codec-level padding here, but I wrote of container overhead.
also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ... AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes. well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding.
Can I remove it ?
Oops, forgot I am maintainer for libgsm!
Since bitrate is also irrelevant for encoding, what about this?
------------------------------------------------------------------------
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 12579) +++ libavcodec/libgsm.c (working copy) @@ -36,8 +36,10 @@ #define GSM_FRAME_SIZE 160
static av_cold int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000) + if (avctx->channels > 1 || avctx->sample_rate != 8000) return -1; + if (avctx->bit_rate != 13000) + av_log(avctx, AV_LOG_WARNING, "Bit rate %d instead of expected 13000 - ignored\n");
Well, Im not really ok to annoy user with a false message, when decoding this is irrelevant.
It is not false. IMO a file with any bitrate other than 13000 is corrupted - well, at least it is not strictly according to specs. Yes, this is debatable, but to debate it we need facts, that is a collection of files with that problem. Printing the message will inform us about that.
What is this check good for, since bitrate is irrelevant ?
Remove the message on encoding, and very soon we will have someone complaining that he used -acodec libgsm -ab 26000 but the output file is too small and WMP says it is 13kbits... Greetings, -- Michel Bardiaux http://www.mediaxim.com/
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michael Niedermayer wrote:
Hi
On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote: > Hi > > On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote: >> Michael Niedermayer wrote: >>> Hi [snip] >>> is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? >> Yes and no. The last 4 bits of each frame are not actually used, they >> come on stage only because we (both libgsm and lavc) use a >> byte-oriented >> API, and files made of bytes. They should be considered as container >> overhead in TOAST files, hence not part of the codec bitrate. > but with this argumentation we would have to subtract the padding > bits from > mpeg from the bitrate too and thats something we dont I think you're talking codec-level padding here, but I wrote of container overhead.
> also it would cause > problems for containers which expect the bitrate well to be the > bitrate of > what they get, not to be slightly less due to some padding bits > they dont > know about ... AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes. well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding.
Can I remove it ?
Oops, forgot I am maintainer for libgsm!
Since bitrate is also irrelevant for encoding, what about this?
------------------------------------------------------------------------
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 12579) +++ libavcodec/libgsm.c (working copy) @@ -36,8 +36,10 @@ #define GSM_FRAME_SIZE 160
static av_cold int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000) + if (avctx->channels > 1 || avctx->sample_rate != 8000) return -1; + if (avctx->bit_rate != 13000) + av_log(avctx, AV_LOG_WARNING, "Bit rate %d instead of expected 13000 - ignored\n");
Well, Im not really ok to annoy user with a false message, when decoding this is irrelevant.
It is not false. IMO a file with any bitrate other than 13000 is corrupted - well, at least it is not strictly according to specs. Yes, this is debatable, but to debate it we need facts, that is a collection of files with that problem. Printing the message will inform us about that.
In wav/avi maybe, but this is not the case of aiff/mov, which does not supply bitrates, so this will annoy them everytime. Now IMHO, strictly speaking, a wav header with bit_rate field set to 0 does not necessarly mean that gsm bitstream is corrupted, so again I think this is irrelevant. You could maybe check that bit_rate is actually != 0 && != 13000
What is this check good for, since bitrate is irrelevant ?
Remove the message on encoding, and very soon we will have someone complaining that he used -acodec libgsm -ab 26000 but the output file is too small and WMP says it is 13kbits...
Well, Im not against removing it for encoding, I'd like it removed for decoding :> -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Michel Bardiaux wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michael Niedermayer wrote:
Hi
On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote: > Michael Niedermayer wrote: >> Hi >> >> On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote: >>> Michael Niedermayer wrote: >>>> Hi > [snip] >>>> is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? >>> Yes and no. The last 4 bits of each frame are not actually used, they >>> come on stage only because we (both libgsm and lavc) use a >>> byte-oriented >>> API, and files made of bytes. They should be considered as container >>> overhead in TOAST files, hence not part of the codec bitrate. >> but with this argumentation we would have to subtract the padding >> bits from >> mpeg from the bitrate too and thats something we dont > I think you're talking codec-level padding here, but I wrote of > container overhead. > >> also it would cause >> problems for containers which expect the bitrate well to be the >> bitrate of >> what they get, not to be slightly less due to some padding bits >> they dont >> know about ... > AFAIK currently only some MS containers (AVI, WAV) accept GSM, and > then only MS-GSM, which does not have the problem. The only > container for non-MS-GSM is TOAST (currently not implemented) and > that one knows about the 4 extra bytes. well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding.
Can I remove it ?
Oops, forgot I am maintainer for libgsm!
Since bitrate is also irrelevant for encoding, what about this?
------------------------------------------------------------------------
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 12579) +++ libavcodec/libgsm.c (working copy) @@ -36,8 +36,10 @@ #define GSM_FRAME_SIZE 160
static av_cold int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000) + if (avctx->channels > 1 || avctx->sample_rate != 8000) return -1; + if (avctx->bit_rate != 13000) + av_log(avctx, AV_LOG_WARNING, "Bit rate %d instead of expected 13000 - ignored\n");
Well, Im not really ok to annoy user with a false message, when decoding this is irrelevant. It is not false. IMO a file with any bitrate other than 13000 is corrupted - well, at least it is not strictly according to specs. Yes,
Baptiste Coudurier wrote: this is debatable, but to debate it we need facts, that is a collection of files with that problem. Printing the message will inform us about that.
In wav/avi maybe, but this is not the case of aiff/mov, which does not supply bitrates, so this will annoy them everytime.
Now IMHO, strictly speaking, a wav header with bit_rate field set to 0 does not necessarly mean that gsm bitstream is corrupted, so again I think this is irrelevant.
You could maybe check that bit_rate is actually != 0 && != 13000
What is this check good for, since bitrate is irrelevant ?
Remove the message on encoding, and very soon we will have someone complaining that he used -acodec libgsm -ab 26000 but the output file is too small and WMP says it is 13kbits...
Well, Im not against removing it for encoding, I'd like it removed for decoding :>
Michael has reported 13200 in aiff, do you also see 13200 for mov? Then accepting (OK, silently) 0, 13000 and 13200 when decoding solves your problem while leaving some safety. For encoding, I think forcing 13000 with a message is correct codec-wise. And with just one value from libavcodec, the muxers could easily transform in whatever is needed. What I don't want to do, is to accept silently values that are patently absurd. There are already too many places where ffmpeg does that (bitrate for rawvideo comes to mind). -- Michel Bardiaux http://www.mediaxim.com/
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michael Niedermayer wrote: > Hi > > On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote: >> Michael Niedermayer wrote: >>> Hi >>> >>> On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote: >>>> Michael Niedermayer wrote: >>>>> Hi >> [snip] >>>>> is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? >>>> Yes and no. The last 4 bits of each frame are not actually used, they >>>> come on stage only because we (both libgsm and lavc) use a >>>> byte-oriented >>>> API, and files made of bytes. They should be considered as container >>>> overhead in TOAST files, hence not part of the codec bitrate. >>> but with this argumentation we would have to subtract the padding >>> bits from >>> mpeg from the bitrate too and thats something we dont >> I think you're talking codec-level padding here, but I wrote of >> container overhead. >> >>> also it would cause >>> problems for containers which expect the bitrate well to be the >>> bitrate of >>> what they get, not to be slightly less due to some padding bits >>> they dont >>> know about ... >> AFAIK currently only some MS containers (AVI, WAV) accept GSM, and >> then only MS-GSM, which does not have the problem. The only >> container for non-MS-GSM is TOAST (currently not implemented) and >> that one knows about the 4 extra bytes. > well a grep for gsm shows a hit in aiff.c so it seems it is supported > in a > non toast format currently and as there is no gsm specific code in it > i would > guess it will end with 13200 as bitrate > > anyway i wont fight about this appl the patch, i will remove the > 13000 check > when it breaks something > I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding.
Can I remove it ?
Oops, forgot I am maintainer for libgsm!
Since bitrate is also irrelevant for encoding, what about this?
------------------------------------------------------------------------
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 12579) +++ libavcodec/libgsm.c (working copy) @@ -36,8 +36,10 @@ #define GSM_FRAME_SIZE 160
static av_cold int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000) + if (avctx->channels > 1 || avctx->sample_rate != 8000) return -1; + if (avctx->bit_rate != 13000) + av_log(avctx, AV_LOG_WARNING, "Bit rate %d instead of expected 13000 - ignored\n");
Well, Im not really ok to annoy user with a false message, when decoding this is irrelevant. It is not false. IMO a file with any bitrate other than 13000 is corrupted - well, at least it is not strictly according to specs. Yes,
Baptiste Coudurier wrote: this is debatable, but to debate it we need facts, that is a collection of files with that problem. Printing the message will inform us about that. In wav/avi maybe, but this is not the case of aiff/mov, which does not supply bitrates, so this will annoy them everytime.
Now IMHO, strictly speaking, a wav header with bit_rate field set to 0 does not necessarly mean that gsm bitstream is corrupted, so again I think this is irrelevant.
You could maybe check that bit_rate is actually != 0 && != 13000
What is this check good for, since bitrate is irrelevant ?
Remove the message on encoding, and very soon we will have someone complaining that he used -acodec libgsm -ab 26000 but the output file is too small and WMP says it is 13kbits...
Well, Im not against removing it for encoding, I'd like it removed for decoding :>
Michael has reported 13200 in aiff, do you also see 13200 for mov? Then accepting (OK, silently) 0, 13000 and 13200 when decoding solves your problem while leaving some safety.
Yes. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Michel Bardiaux wrote: [time for a big snip]
Michael has reported 13200 in aiff, do you also see 13200 for mov? Then accepting (OK, silently) 0, 13000 and 13200 when decoding solves your problem while leaving some safety.
Yes.
OK then, my proposition is that on decoding, all 3 are accepted silently, anything else causes a warning (but is accepted); on encoding, anything else than 13000 elicits a warning and is forced to 13000. But I can't find a way to know, in libgsm_init, whether it is called for enc or decoding. My mistake or is there none? -- Michel Bardiaux http://www.mediaxim.com/
Hi, Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote: [time for a big snip]
Michael has reported 13200 in aiff, do you also see 13200 for mov? Then accepting (OK, silently) 0, 13000 and 13200 when decoding solves your problem while leaving some safety. Yes.
OK then, my proposition is that on decoding, all 3 are accepted silently, anything else causes a warning (but is accepted); on encoding, anything else than 13000 elicits a warning and is forced to 13000.
But I can't find a way to know, in libgsm_init, whether it is called for enc or decoding. My mistake or is there none?
You can check with AVCodecContext->AVCodec symbol I think. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote: [time for a big snip]
Michael has reported 13200 in aiff, do you also see 13200 for mov? Then accepting (OK, silently) 0, 13000 and 13200 when decoding solves your problem while leaving some safety. Yes. OK then, my proposition is that on decoding, all 3 are accepted silently, anything else causes a warning (but is accepted); on encoding, anything else than 13000 elicits a warning and is forced to 13000.
Ok with this spec, or is it necessary to tolerate 13200 on encoding too because some muxer sets 13200 before init is called?
But I can't find a way to know, in libgsm_init, whether it is called for enc or decoding. My mistake or is there none?
You can check with AVCodecContext->AVCodec symbol I think.
You mean, compare AVCodecContext->AVCodec->encode vs. NULL, right? -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote: [time for a big snip]
Michael has reported 13200 in aiff, do you also see 13200 for mov? Then accepting (OK, silently) 0, 13000 and 13200 when decoding solves your problem while leaving some safety. Yes. OK then, my proposition is that on decoding, all 3 are accepted silently, anything else causes a warning (but is accepted); on encoding, anything else than 13000 elicits a warning and is forced to 13000.
Ok with this spec, or is it necessary to tolerate 13200 on encoding too because some muxer sets 13200 before init is called?
Well you can check in the code, that is mov and aiff, I guess.
But I can't find a way to know, in libgsm_init, whether it is called for enc or decoding. My mistake or is there none?
You can check with AVCodecContext->AVCodec symbol I think.
You mean, compare AVCodecContext->AVCodec->encode vs. NULL, right?
That is one solution if it works. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote: [time for a big snip]
Michael has reported 13200 in aiff, do you also see 13200 for mov? Then accepting (OK, silently) 0, 13000 and 13200 when decoding solves your problem while leaving some safety. Yes. OK then, my proposition is that on decoding, all 3 are accepted silently, anything else causes a warning (but is accepted); on encoding, anything else than 13000 elicits a warning and is forced to 13000. Ok with this spec, or is it necessary to tolerate 13200 on encoding too because some muxer sets 13200 before init is called?
Well you can check in the code, that is mov and aiff, I guess.
You wrote in another thread (in reply to my proposal to make checks dependednt on strictness):
Yes, and now I'd like your check being done when stricness is explicitly asked :>
That modifies things: Default: encoding: silently accepts 13200. I still think a warning for other values would be good. Strict: encoding: anything else than 13000 and *maybe* 13200 rejected. For 13200, I still have to see in mov and aiff. Default: decoding: accepts anything silently. Strict: decoding: reject others than 13000 13200. Greetings, -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Hi, Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote: [time for a big snip] > Michael has reported 13200 in aiff, do you also see 13200 for mov? Then > accepting (OK, silently) 0, 13000 and 13200 when decoding solves your > problem while leaving some safety. Yes. OK then, my proposition is that on decoding, all 3 are accepted silently, anything else causes a warning (but is accepted); on encoding, anything else than 13000 elicits a warning and is forced to 13000. Ok with this spec, or is it necessary to tolerate 13200 on encoding too because some muxer sets 13200 before init is called? Well you can check in the code, that is mov and aiff, I guess.
You wrote in another thread (in reply to my proposal to make checks dependednt on strictness):
Yes, and now I'd like your check being done when stricness is explicitly asked :>
That modifies things: Default: encoding: silently accepts 13200. I still think a warning for other values would be good. Strict: encoding: anything else than 13000 and *maybe* 13200 rejected. For 13200, I still have to see in mov and aiff. Default: decoding: accepts anything silently. Strict: decoding: reject others than 13000 13200.
Greetings,
Can we please fix this ? http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov Choose whichever solution you prefer, but this sample should play without error message :> -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote: > Michel Bardiaux wrote: [time for a big snip] >> Michael has reported 13200 in aiff, do you also see 13200 for mov? Then >> accepting (OK, silently) 0, 13000 and 13200 when decoding solves your >> problem while leaving some safety. > Yes. OK then, my proposition is that on decoding, all 3 are accepted silently, anything else causes a warning (but is accepted); on encoding, anything else than 13000 elicits a warning and is forced to 13000. Ok with this spec, or is it necessary to tolerate 13200 on encoding too because some muxer sets 13200 before init is called? Well you can check in the code, that is mov and aiff, I guess. You wrote in another thread (in reply to my proposal to make checks dependednt on strictness): Yes, and now I'd like your check being done when stricness is explicitly asked :>
That modifies things: Default: encoding: silently accepts 13200. I still think a warning for other values would be good. Strict: encoding: anything else than 13000 and *maybe* 13200 rejected. For 13200, I still have to see in mov and aiff. Default: decoding: accepts anything silently. Strict: decoding: reject others than 13000 13200.
Greetings,
Can we please fix this ? http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov
Choose whichever solution you prefer, but this sample should play without error message :>
Here is a 'permissive' first patch; 13000, 13200, and 0, are accepted silently. Note that testing that got me to some other problems: ./ffmpeg_g -i sample-gsm-8000.mov -acodec pcm_s16le sample-gsm-8000.wav |& head -30 FFmpeg version SVN-r12949, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --enable-libmp3lame --enable-gpl --enable-x11grab --enable-libgsm libavutil version: 49.6.0 libavcodec version: 51.56.0 libavformat version: 52.13.0 libavdevice version: 52.0.0 built on Apr 25 2008 11:19:51, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x843b434]edit list not starting at 0, a/v desync might occur, patch welcome [mov,mp4,m4a,3gp,3g2,mj2 @ 0x843b434]Could not find codec parameters (Data: rtp / 0x20707472) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x843b434]Could not find codec parameters (Data: rtp / 0x20707472) Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sample-gsm-8000.mov': Duration: 00:03:31.30, start: 0.000000, bitrate: 17 kb/s Stream #0.0(eng): Audio: libgsm, 8000 Hz, mono Stream #0.1(eng): Subtitle: text / 0x74786574 Stream #0.2(eng): Data: rtp / 0x20707472 Stream #0.3(eng): Data: rtp / 0x20707472 Multiple frames in a packet from stream 0 [Repeated many many times] This is in ffmpeg.c:output_packet and seems to be due to weird pts'es from input, hence a problem in the mov demuxer, but I'm wagging here. Anyway, other bug, other thread, no? -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Hi, Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
[...]
Can we please fix this ? http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov
Choose whichever solution you prefer, but this sample should play without error message :>
Here is a 'permissive' first patch; 13000, 13200, and 0, are accepted silently.
Note that testing that got me to some other problems:
./ffmpeg_g -i sample-gsm-8000.mov -acodec pcm_s16le sample-gsm-8000.wav |& head -30 FFmpeg version SVN-r12949, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --enable-libmp3lame --enable-gpl --enable-x11grab --enable-libgsm libavutil version: 49.6.0 libavcodec version: 51.56.0 libavformat version: 52.13.0 libavdevice version: 52.0.0 built on Apr 25 2008 11:19:51, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x843b434]edit list not starting at 0, a/v desync might occur, patch welcome [mov,mp4,m4a,3gp,3g2,mj2 @ 0x843b434]Could not find codec parameters (Data: rtp / 0x20707472) [mov,mp4,m4a,3gp,3g2,mj2 @ 0x843b434]Could not find codec parameters (Data: rtp / 0x20707472) Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sample-gsm-8000.mov': Duration: 00:03:31.30, start: 0.000000, bitrate: 17 kb/s Stream #0.0(eng): Audio: libgsm, 8000 Hz, mono Stream #0.1(eng): Subtitle: text / 0x74786574 Stream #0.2(eng): Data: rtp / 0x20707472 Stream #0.3(eng): Data: rtp / 0x20707472 Multiple frames in a packet from stream 0 [Repeated many many times]
This is in ffmpeg.c:output_packet and seems to be due to weird pts'es from input,
No, packet contains multiple frames, like error message says. This illustrates another problem with libgsm decoder: data_size must be set to 0 before returning if nothing is output. Also if buf_size < avctx->block_align you should return error (-1) here IMHO.
hence a problem in the mov demuxer, but I'm wagging here. Anyway, other bug, other thread, no?
Yes, fixed now. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
[...]
Can we please fix this ? http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov
Choose whichever solution you prefer, but this sample should play without error message :>
Here is a 'permissive' first patch; 13000, 13200, and 0, are accepted silently.
[snip]
Multiple frames in a packet from stream 0
[Repeated many many times]
This is in ffmpeg.c:output_packet and seems to be due to weird pts'es from input,
No, packet contains multiple frames, like error message says.
This illustrates another problem with libgsm decoder: data_size must be set to 0 before returning if nothing is output.
Also if buf_size < avctx->block_align you should return error (-1) here IMHO.
Agreed. New patch for review. -- Michel Bardiaux http://www.mediaxim.com/
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Hi,
[...]
Can we please fix this ? http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov
Choose whichever solution you prefer, but this sample should play without error message :>
Here is a 'permissive' first patch; 13000, 13200, and 0, are accepted silently.
[snip]
Multiple frames in a packet from stream 0
[Repeated many many times]
This is in ffmpeg.c:output_packet and seems to be due to weird pts'es from input,
No, packet contains multiple frames, like error message says.
This illustrates another problem with libgsm decoder: data_size must be set to 0 before returning if nothing is output.
Also if buf_size < avctx->block_align you should return error (-1) here IMHO.
Agreed. New patch for review.
[...]
+ if (avctx->bit_rate != 13000 /* Official */ && + avctx->bit_rate != 13200 /* Very common */ && + avctx->bit_rate != 0 /* Unknown, happens in some MOV */ ) {
Something like: "mov does not set bitrate when decoding" might be clearer.
[...]
static int libgsm_decode_frame(AVCodecContext *avctx, void *data, int *data_size, uint8_t *buf, int buf_size) { - - if(buf_size < avctx->block_align) return 0; - + *data_size = 0; /* In case of error */ + if(buf_size < avctx->block_align) return -1; switch(avctx->codec_id) { case CODEC_ID_GSM: if(gsm_decode(avctx->priv_data,buf,data)) return -1;
This must be in a separate commit. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
[...]
+ if (avctx->bit_rate != 13000 /* Official */ && + avctx->bit_rate != 13200 /* Very common */ && + avctx->bit_rate != 0 /* Unknown, happens in some MOV */ ) {
Something like: "mov does not set bitrate when decoding" might be clearer.
OK.
[...]
static int libgsm_decode_frame(AVCodecContext *avctx, void *data, int *data_size, uint8_t *buf, int buf_size) { - - if(buf_size < avctx->block_align) return 0; - + *data_size = 0; /* In case of error */ + if(buf_size < avctx->block_align) return -1; switch(avctx->codec_id) { case CODEC_ID_GSM: if(gsm_decode(avctx->priv_data,buf,data)) return -1;
This must be in a separate commit.
OK. New (first) patch. -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
[...]
+ if (avctx->bit_rate != 13000 /* Official */ && + avctx->bit_rate != 13200 /* Very common */ && + avctx->bit_rate != 0 /* Unknown, happens in some MOV */ ) {
Something like: "mov does not set bitrate when decoding" might be clearer.
[...]
OK. New (first) patch.
[...]
Looks ok. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
[...]
+ if (avctx->bit_rate != 13000 /* Official */ && + avctx->bit_rate != 13200 /* Very common */ && + avctx->bit_rate != 0 /* Unknown, happens in some MOV */ ) { Something like: "mov does not set bitrate when decoding" might be clearer. [...]
OK. New (first) patch.
[...]
Looks ok.
Applied. Now the 2nd patch.
-- Michel Bardiaux http://www.mediaxim.com/
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
Michel Bardiaux wrote:
Baptiste Coudurier wrote:
[...]
+ if (avctx->bit_rate != 13000 /* Official */ && + avctx->bit_rate != 13200 /* Very common */ && + avctx->bit_rate != 0 /* Unknown, happens in some MOV */ ) { Something like: "mov does not set bitrate when decoding" might be clearer. [...]
OK. New (first) patch.
[...]
Looks ok.
Applied.
Now the 2nd patch.
[...]
Looks ok. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier wrote:
[snip]
Now the 2nd patch.
[...]
Looks ok.
Applied. And in this, I think "Le mieux est l'ennemi du bien" (for English speakers: "No need to gild the lily"). I was unable to justify my proposals for a 'strict' mode from spec documents, so I withdraw them. I think we can close this thread. (Which leaves to each muxer the responsibility to store *its* idea of the correct value for the GSM bitrate). Greetings, -- Michel Bardiaux http://www.mediaxim.com/
Hi On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote: [...]
./ffmpeg_g -i sample-gsm-8000.mov -acodec pcm_s16le sample-gsm-8000.wav |& [...] Stream #0.0(eng): Audio: libgsm, 8000 Hz, mono [...] Multiple frames in a packet from stream 0 [Repeated many many times]
Maybe someone should write a gsm parser which chops these up into individual frames ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
Michael Niedermayer wrote:
Hi
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote: [...]
./ffmpeg_g -i sample-gsm-8000.mov -acodec pcm_s16le sample-gsm-8000.wav |& [...] Stream #0.0(eng): Audio: libgsm, 8000 Hz, mono [...] Multiple frames in a packet from stream 0 [Repeated many many times]
Maybe someone should write a gsm parser which chops these up into individual frames ...
Can we have a generic splitter using avctx->block_align ? It would be simpler and be used for many adpcm variants I think. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
On Fri, Apr 25, 2008 at 06:15:16PM +0200, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
Hi
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote: [...]
./ffmpeg_g -i sample-gsm-8000.mov -acodec pcm_s16le sample-gsm-8000.wav |& [...] Stream #0.0(eng): Audio: libgsm, 8000 Hz, mono [...] Multiple frames in a packet from stream 0 [Repeated many many times]
Maybe someone should write a gsm parser which chops these up into individual frames ...
Can we have a generic splitter using avctx->block_align ? It would be simpler and be used for many adpcm variants I think.
patch welcome [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...]
While you guys are at it, there are still a couple of samples that do not work in ffplay: http://samples.mplayerhq.hu/A-codecs/msgsm/levis.avi http://samples.mplayerhq.hu/A-codecs/msgsm/wernfried_1.avi http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.gsm http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov All of them produce no sound at all. Diego
Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...]
While you guys are at it, there are still a couple of samples that do not work in ffplay:
ffmpeg -i levis.avi -vn -acodec pcm_s16le -y levis.avi.wav FFmpeg version SVN-r13009, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --enable-libmp3lame --enable-gpl --enable-x11grab --enable-libgsm libavutil version: 49.6.0 libavcodec version: 51.56.0 libavformat version: 52.13.0 libavdevice version: 52.0.0 built on Apr 28 2008 12:14:17, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Input #0, avi, from 'levis.avi': Duration: 00:00:44.83, start: 0.000000, bitrate: 352 kb/s Stream #0.0: Video: indeo3, yuv410p, 152x116, 6.00 tb(r) Stream #0.1: Audio: libgsm_ms, 44100 Hz, mono, 71 kb/s Output #0, wav, to 'levis.avi.wav': Stream #0.0: Audio: pcm_s16le, 44100 Hz, mono, 705 kb/s Stream mapping: Stream #0.1 -> #0.0 [libgsm_ms @ 0x8451ff0]Sample rate 8000Hz required for GSM, got 44100Hz Error while opening codec for input stream #0.1 IMHO the codec should not second-guess the demuxer, its the latter that should fix things if the file is obviously corrupted (which this one is!). That is, at the end of get_wav_header (proper patch when there is agreement of the ways and means). Theoretically there is no maintainer for riff.c but since Michael is maintainer for the avi muxdemux I guess he is for riff.c too (should I correct MAINTAINERS?) And whether the demuxer or the codec changes the sample rate, a warning should be issued. OK?
Ditto with 22050Hz.
http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.gsm
This one cant be recognized: [mp3 @ 0x843b514]Could not find codec parameters (Audio: mp2, 8 kb/s) sample-gsm-8000.gsm: could not find codec parameters What format is it?
http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov
This one works for me: ffmpeg -i sample-gsm-8000.mov -vn -acodec pcm_s16le sample-gsm-8000.mov.wav produces a wav with correct sound.
All of them produce no sound at all.
Greetings, -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
On Mon, Apr 28, 2008 at 01:53:56PM +0200, Michel Bardiaux wrote:
Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...]
While you guys are at it, there are still a couple of samples that do not work in ffplay:
ffmpeg -i levis.avi -vn -acodec pcm_s16le -y levis.avi.wav FFmpeg version SVN-r13009, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --enable-libmp3lame --enable-gpl --enable-x11grab --enable-libgsm libavutil version: 49.6.0 libavcodec version: 51.56.0 libavformat version: 52.13.0 libavdevice version: 52.0.0 built on Apr 28 2008 12:14:17, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Input #0, avi, from 'levis.avi': Duration: 00:00:44.83, start: 0.000000, bitrate: 352 kb/s Stream #0.0: Video: indeo3, yuv410p, 152x116, 6.00 tb(r) Stream #0.1: Audio: libgsm_ms, 44100 Hz, mono, 71 kb/s Output #0, wav, to 'levis.avi.wav': Stream #0.0: Audio: pcm_s16le, 44100 Hz, mono, 705 kb/s Stream mapping: Stream #0.1 -> #0.0 [libgsm_ms @ 0x8451ff0]Sample rate 8000Hz required for GSM, got 44100Hz Error while opening codec for input stream #0.1
IMHO the codec should not second-guess the demuxer,
but libgsm.c does exactly that ...
its the latter that should fix things if the file is obviously corrupted (which this one is!).
I see nothing corrupt on the file
That is, at the end of get_wav_header (proper patch when there is agreement of the ways and means). Theoretically there is no maintainer for riff.c but since Michael is maintainer for the avi muxdemux I guess he is for riff.c too (should I correct MAINTAINERS?)
Yes i mainain riff.c, feel free to add me to the list if you like ...
And whether the demuxer or the codec changes the sample rate, a warning should be issued. OK?
Print as many warnings as you like :) but please dont reject streams at random, patch below fixes this file and i suspect others as well, i will apply it in 24h unless you object. Index: libgsm.c =================================================================== --- libgsm.c (revision 13005) +++ libgsm.c (working copy) @@ -41,18 +41,6 @@ avctx->channels); return -1; } - if (avctx->sample_rate != 8000) { - av_log(avctx, AV_LOG_ERROR, "Sample rate 8000Hz required for GSM, got %dHz\n", - avctx->sample_rate); - return -1; - } - if (avctx->bit_rate != 13000 /* Official */ && - avctx->bit_rate != 13200 /* Very common */ && - avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when decoding */ ) { - av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got %dbps\n", - avctx->bit_rate); - return -1; - } avctx->priv_data = gsm_create(); [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
Michael Niedermayer wrote:
On Mon, Apr 28, 2008 at 01:53:56PM +0200, Michel Bardiaux wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...] While you guys are at it, there are still a couple of samples that do not work in ffplay:
http://samples.mplayerhq.hu/A-codecs/msgsm/levis.avi ffmpeg -i levis.avi -vn -acodec pcm_s16le -y levis.avi.wav FFmpeg version SVN-r13009, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --enable-libmp3lame --enable-gpl --enable-x11grab --enable-libgsm
Diego Biurrun wrote: libavutil version: 49.6.0 libavcodec version: 51.56.0 libavformat version: 52.13.0 libavdevice version: 52.0.0 built on Apr 28 2008 12:14:17, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Input #0, avi, from 'levis.avi': Duration: 00:00:44.83, start: 0.000000, bitrate: 352 kb/s Stream #0.0: Video: indeo3, yuv410p, 152x116, 6.00 tb(r) Stream #0.1: Audio: libgsm_ms, 44100 Hz, mono, 71 kb/s Output #0, wav, to 'levis.avi.wav': Stream #0.0: Audio: pcm_s16le, 44100 Hz, mono, 705 kb/s Stream mapping: Stream #0.1 -> #0.0 [libgsm_ms @ 0x8451ff0]Sample rate 8000Hz required for GSM, got 44100Hz Error while opening codec for input stream #0.1
IMHO the codec should not second-guess the demuxer,
but libgsm.c does exactly that ...
Because I was requested to make it so. My position was that only the strictly-according-to-spec 13000 should be allowed, anything else to be corrected by the demuxer. But that was not accepted, people want something like "Mmm, the demuxer says bitrate 0, but it really must mean 13000, so I will assume that".
its the latter that should fix things if the file is obviously corrupted (which this one is!).
I see nothing corrupt on the file
That is, at the end of get_wav_header (proper patch when there is agreement of the ways and means). Theoretically there is no maintainer for riff.c but since Michael is maintainer for the avi muxdemux I guess he is for riff.c too (should I correct MAINTAINERS?)
Yes i mainain riff.c, feel free to add me to the list if you like ...
And whether the demuxer or the codec changes the sample rate, a warning should be issued. OK?
Print as many warnings as you like :) but please dont reject streams at random,
It is *NOT* at random. The spec is very clear: the sample rate for GSM is 8000. Any other value in the RIFF headers is simply wrong and hints that the encoder has screwed up.
patch below fixes this file and i suspect others as well, i will apply it in 24h unless you object.
The change was submitted for review and you didn't object... But if you insist on a quick-and-dirty fix for all those malformed files, patch attached for your consideration. But consider the consequences: FFmpeg version SVN-r13009, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --enable-libmp3lame --enable-gpl --enable-x11grab --enable-libgsm libavutil version: 49.6.0 libavcodec version: 51.56.0 libavformat version: 52.13.0 libavdevice version: 52.0.0 built on Apr 28 2008 12:14:17, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Input #0, avi, from 'levis.avi': Duration: 00:00:44.83, start: 0.000000, bitrate: 352 kb/s Stream #0.0: Video: indeo3, yuv410p, 152x116, 6.00 tb(r) Stream #0.1: Audio: libgsm_ms, 44100 Hz, mono, 71 kb/s Output #0, wav, to 'levis.avi.wav': Stream #0.0: Audio: pcm_s16le, 44100 Hz, mono, 705 kb/s Stream mapping: Stream #0.1 -> #0.0 [libgsm_ms @ 0x8452010]Sample rate 8000Hz required for GSM, got 44100Hz, fixed [libgsm_ms @ 0x8452010]Bitrate 13000bps required for GSM, got 71656bps, fixed Press [q] to stop encoding size= 3861kB time=44.8 bitrate= 705.6kbits/s video:0kB audio:3861kB global headers:0kB muxing overhead 0.001113% If we do ffmpeg -i levis.avi -an -vcodec copy vidonly.avi we get a file size that indicates the audio stream in levis.avi occupies 401066 bytes, or 6170 MSGSM blocks, or 1974400 samples, on 45" that means 43875Hz, hence it is *really* 44100Hz, the encoder fed frames to the library without rate conversion. Do we really want to accept such a file?
Index: libgsm.c =================================================================== --- libgsm.c (revision 13005) +++ libgsm.c (working copy) @@ -41,18 +41,6 @@ avctx->channels); return -1; } - if (avctx->sample_rate != 8000) { - av_log(avctx, AV_LOG_ERROR, "Sample rate 8000Hz required for GSM, got %dHz\n", - avctx->sample_rate); - return -1; - } - if (avctx->bit_rate != 13000 /* Official */ && - avctx->bit_rate != 13200 /* Very common */ && - avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when decoding */ ) { - av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got %dbps\n", - avctx->bit_rate); - return -1; - }
avctx->priv_data = gsm_create();
-- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
On Mon, Apr 28, 2008 at 05:16:21PM +0200, Michel Bardiaux wrote:
Michael Niedermayer wrote: [...]
its the latter that should fix things if the file is obviously corrupted (which this one is!). I see nothing corrupt on the file That is, at the end of get_wav_header (proper patch when there is agreement of the ways and means). Theoretically there is no maintainer for riff.c but since Michael is maintainer for the avi muxdemux I guess he is for riff.c too (should I correct MAINTAINERS?) Yes i mainain riff.c, feel free to add me to the list if you like ... And whether the demuxer or the codec changes the sample rate, a warning should be issued. OK? Print as many warnings as you like :) but please dont reject streams at random,
It is *NOT* at random. The spec is very clear: the sample rate for GSM is 8000. Any other value in the RIFF headers is simply wrong and hints that the encoder has screwed up.
patch below fixes this file and i suspect others as well, i will apply it in 24h unless you object.
The change was submitted for review and you didn't object... But if you insist on a quick-and-dirty fix for all those malformed files, patch attached for your consideration. But consider the consequences:
Your patch does not fix the problem just try to play them with ffplay. My patch works, yours does not. That file does have a sample rate of 44100 not 8000. The easiest solution is simply to remove the code messing with the sample rate. The alternative would be to add a sample_rate field to AVStream so both demuxer and decoder can provide their sample rates to the user app. But this seems really bad design as we know which rate is wrong and which is not. And 2 sample rate fields will just force the user app to duplicate the logic, the situation would be different if we didnt knew what was correct but heres its clear, if the demuser says X its X if the demuxer doesnt say anything its 8000. Most sane would be if(!avctx->sample_rate) avctx->sample_rate= 8000; IMO [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
On Mon, Apr 28, 2008 at 06:56:32PM +0200, Michael Niedermayer wrote:
On Mon, Apr 28, 2008 at 05:16:21PM +0200, Michel Bardiaux wrote:
Michael Niedermayer wrote: [...]
its the latter that should fix things if the file is obviously corrupted (which this one is!). I see nothing corrupt on the file That is, at the end of get_wav_header (proper patch when there is agreement of the ways and means). Theoretically there is no maintainer for riff.c but since Michael is maintainer for the avi muxdemux I guess he is for riff.c too (should I correct MAINTAINERS?) Yes i mainain riff.c, feel free to add me to the list if you like ... And whether the demuxer or the codec changes the sample rate, a warning should be issued. OK? Print as many warnings as you like :) but please dont reject streams at random,
It is *NOT* at random. The spec is very clear: the sample rate for GSM is 8000. Any other value in the RIFF headers is simply wrong and hints that the encoder has screwed up.
patch below fixes this file and i suspect others as well, i will apply it in 24h unless you object.
The change was submitted for review and you didn't object... But if you insist on a quick-and-dirty fix for all those malformed files, patch attached for your consideration. But consider the consequences:
Your patch does not fix the problem just try to play them with ffplay. My patch works, yours does not. That file does have a sample rate of 44100 not 8000. The easiest solution is simply to remove the code messing with the sample rate. The alternative would be to add a sample_rate field to AVStream so both demuxer and decoder can provide their sample rates to the user app. But this seems really bad design as we know which rate is wrong and which is not. And 2 sample rate fields will just force the user app to duplicate the logic, the situation would be different if we didnt knew what was correct but heres its clear, if the demuser says X its X if the demuxer doesnt say anything its 8000.
Most sane would be if(!avctx->sample_rate) avctx->sample_rate= 8000;
IMO
Heres a proper patch for that: Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 13005) +++ libavcodec/libgsm.c (working copy) @@ -41,18 +41,14 @@ avctx->channels); return -1; } - if (avctx->sample_rate != 8000) { - av_log(avctx, AV_LOG_ERROR, "Sample rate 8000Hz required for GSM, got %dHz\n", - avctx->sample_rate); - return -1; + + if(avctx->codec->decode){ + if(!avctx->channels) + avctx->channels= 1; + + if(!avctx->sample_rate) + avctx->sample_rate= 8000; } - if (avctx->bit_rate != 13000 /* Official */ && - avctx->bit_rate != 13200 /* Very common */ && - avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when decoding */ ) { - av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got %dbps\n", - avctx->bit_rate); - return -1; - } avctx->priv_data = gsm_create(); ----- This also makes the raw gsm partially play (needs a parser to be correctly playable) Ill apply the patch above in 24h unless you object. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
Michael Niedermayer wrote:
On Mon, Apr 28, 2008 at 06:56:32PM +0200, Michael Niedermayer wrote:
On Mon, Apr 28, 2008 at 05:16:21PM +0200, Michel Bardiaux wrote:
Michael Niedermayer wrote: [...]
its the latter that should fix things if the file is obviously corrupted (which this one is!). I see nothing corrupt on the file That is, at the end of get_wav_header (proper patch when there is agreement of the ways and means). Theoretically there is no maintainer for riff.c but since Michael is maintainer for the avi muxdemux I guess he is for riff.c too (should I correct MAINTAINERS?) Yes i mainain riff.c, feel free to add me to the list if you like ... And whether the demuxer or the codec changes the sample rate, a warning should be issued. OK? Print as many warnings as you like :) but please dont reject streams at random, It is *NOT* at random. The spec is very clear: the sample rate for GSM is 8000. Any other value in the RIFF headers is simply wrong and hints that the encoder has screwed up.
patch below fixes this file and i suspect others as well, i will apply it in 24h unless you object. The change was submitted for review and you didn't object... But if you insist on a quick-and-dirty fix for all those malformed files, patch attached for your consideration. But consider the consequences: Your patch does not fix the problem just try to play them with ffplay. My patch works, yours does not. That file does have a sample rate of 44100 not 8000.
Which makes it a totally invalid encoding.
The easiest solution is simply to remove the code messing with the sample rate. The alternative would be to add a sample_rate field to AVStream so both demuxer and decoder can provide their sample rates to the user app. But this seems really bad design as we know which rate is wrong and which is not.
No we don't. A sample rate not 8000 can mean that the user forgot the rate conversion *OR* that the user just forgot to store the correct rate in the header.
And 2 sample rate fields will just force the user app to duplicate the logic, the situation would be different if we didnt knew what was correct but heres its clear, if the demuser says X its X if the demuxer doesnt say anything its 8000.
Most sane would be if(!avctx->sample_rate) avctx->sample_rate= 8000;
IMO
Heres a proper patch for that:
Rejected. It would accept, without any warning, completely invalid values for encoding. Unless, of course, if it's an emergency, in that case do zap all the guards. But what we need is an agreed-upon policy. You have stated rather clearly that ffmpeg/ffplay has to be as permissive as possible on decoding; I accept that, but IMNSHO loud warnings are needed. On encoding, the most sane is to reject non-conforming parameters. If codec and muxers disagree, as with MOV wanting to write 13200 in the header, it will be the muxer's job to do the change. Tit for tat. The problem is when you have GSM in *and* out, i.e. inheritance of dubious parameters. If an input avi has been encoded (mistakenly) at 44100, do we want -acodec copy to output that? And if *re*encoding is requested (a bad idea with GSM, but that is besides the point) do we want ffmpeg to produce a file that players would be justified to reject? Greetings, PS: I will be on holiday from Wed May 1st to Sunday. -- Michel Bardiaux http://www.mediaxim.com/
On Tue, Apr 29, 2008 at 11:10:57AM +0200, Michel Bardiaux wrote:
Michael Niedermayer wrote:
On Mon, Apr 28, 2008 at 06:56:32PM +0200, Michael Niedermayer wrote:
On Mon, Apr 28, 2008 at 05:16:21PM +0200, Michel Bardiaux wrote:
Michael Niedermayer wrote: [...]
its the latter that should fix things if the file is obviously corrupted (which this one is!). I see nothing corrupt on the file That is, at the end of get_wav_header (proper patch when there is agreement of the ways and means). Theoretically there is no maintainer for riff.c but since Michael is maintainer for the avi muxdemux I guess he is for riff.c too (should I correct MAINTAINERS?) Yes i mainain riff.c, feel free to add me to the list if you like ... And whether the demuxer or the codec changes the sample rate, a warning should be issued. OK? Print as many warnings as you like :) but please dont reject streams at random, It is *NOT* at random. The spec is very clear: the sample rate for GSM is 8000. Any other value in the RIFF headers is simply wrong and hints that the encoder has screwed up.
patch below fixes this file and i suspect others as well, i will apply it in 24h unless you object. The change was submitted for review and you didn't object... But if you insist on a quick-and-dirty fix for all those malformed files, patch attached for your consideration. But consider the consequences: Your patch does not fix the problem just try to play them with ffplay. My patch works, yours does not. That file does have a sample rate of 44100 not 8000.
Which makes it a totally invalid encoding.
The easiest solution is simply to remove the code messing with the sample rate. The alternative would be to add a sample_rate field to AVStream so both demuxer and decoder can provide their sample rates to the user app. But this seems really bad design as we know which rate is wrong and which is not.
No we don't. A sample rate not 8000 can mean that the user forgot the rate conversion *OR* that the user just forgot to store the correct rate in the header.
Until we find a file (and not a intentionally created one for this) where the demuxer says X but the samplerate is not X but 8000 i think the assumtation that it is always X is pretty good.
And 2 sample rate fields will just force the user app to duplicate the logic, the situation would be different if we didnt knew what was correct but heres its clear, if the demuser says X its X if the demuxer doesnt say anything its 8000.
Most sane would be if(!avctx->sample_rate) avctx->sample_rate= 8000;
IMO
Heres a proper patch for that:
Rejected. It would accept, without any warning, completely invalid values for encoding.
Unless, of course, if it's an emergency, in that case do zap all the guards.
But what we need is an agreed-upon policy. You have stated rather clearly that ffmpeg/ffplay has to be as permissive as possible on decoding; I accept that, but IMNSHO loud warnings are needed.
On encoding, the most sane is to reject non-conforming parameters. If
Yes, but its only the samplerate the bitstream is completely conforming and such bending of the spec is clearly wanted by some people otherwise such files would not exist. GSM could easily be higher quality per bitrate than several other codecs. Also we do have AVCodecContext.strict_std_compliance for the encoder side.
codec and muxers disagree, as with MOV wanting to write 13200 in the header, it will be the muxer's job to do the change. Tit for tat.
The bitrate for GSM at 8000hz is 13200 other bitrates are incorrect. 33byte/block / 160samples/block * 8000samples/sec * 8bit/byte = 13200 bit/sec The bitrate for MS-GSM at 8000hz is 13000 other bitrates are incorrect. 65byte/block / 320samples/block * 8000samples/sec * 8bit/byte = 13000 bit/sec New patch (which i will apply in 24h) below Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 13005) +++ libavcodec/libgsm.c (working copy) @@ -41,9 +41,18 @@ avctx->channels); return -1; } + + if(avctx->codec->decode){ + if(!avctx->channels) + avctx->channels= 1; + + if(!avctx->sample_rate) + avctx->sample_rate= 8000; + }else{ if (avctx->sample_rate != 8000) { av_log(avctx, AV_LOG_ERROR, "Sample rate 8000Hz required for GSM, got %dHz\n", avctx->sample_rate); + if(avctx->strict_std_compliance > FF_COMPLIANCE_INOFFICIAL) return -1; } if (avctx->bit_rate != 13000 /* Official */ && @@ -51,8 +60,10 @@ avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when decoding */ ) { av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got %dbps\n", avctx->bit_rate); + if(avctx->strict_std_compliance > FF_COMPLIANCE_INOFFICIAL) return -1; } + } avctx->priv_data = gsm_create(); [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
Michael Niedermayer wrote: [snip]
Until we find a file (and not a intentionally created one for this) where the demuxer says X but the samplerate is not X but 8000 i think the assumtation that it is always X is pretty good.
As long as you are aware that it is an *assumption* based on absence of evidence...
And 2 sample rate fields will just force the user app to duplicate the logic, the situation would be different if we didnt knew what was correct but heres its clear, if the demuser says X its X if the demuxer doesnt say anything its 8000.
Most sane would be if(!avctx->sample_rate) avctx->sample_rate= 8000;
IMO Heres a proper patch for that:
Rejected. It would accept, without any warning, completely invalid values for encoding.
Unless, of course, if it's an emergency, in that case do zap all the guards.
But what we need is an agreed-upon policy. You have stated rather clearly that ffmpeg/ffplay has to be as permissive as possible on decoding; I accept that, but IMNSHO loud warnings are needed.
On encoding, the most sane is to reject non-conforming parameters. If
Yes, but its only the samplerate the bitstream is completely conforming
I would not say so...
and such bending of the spec is clearly wanted by some people otherwise such files would not exist.
...I rather think they are due to cluelessness...
GSM could easily be higher quality per bitrate than several other codecs.
... but it is indeed worth trying (as long as the warnings are vociferous enough). How does one measure the quality?
Also we do have AVCodecContext.strict_std_compliance for the encoder side.
I had the same idea.
codec and muxers disagree, as with MOV wanting to write 13200 in the header, it will be the muxer's job to do the change. Tit for tat.
The bitrate for GSM at 8000hz is 13200 other bitrates are incorrect. 33byte/block / 160samples/block * 8000samples/sec * 8bit/byte = 13200 bit/sec
This is what started the whole thread, and I have to admit that re-reading the source (of libgsm) shows that the 4-bits padding is prepended by the codec itself, so 13200 it is. What confused me is that the padding is mentioned in the man page for toast (the CLI for libgsm), not the man page for libgsm itself.
The bitrate for MS-GSM at 8000hz is 13000 other bitrates are incorrect. 65byte/block / 320samples/block * 8000samples/sec * 8bit/byte = 13000 bit/sec
New patch (which i will apply in 24h) below
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 13005) +++ libavcodec/libgsm.c (working copy) @@ -41,9 +41,18 @@ avctx->channels); return -1; } + + if(avctx->codec->decode){ + if(!avctx->channels) + avctx->channels= 1; + + if(!avctx->sample_rate) + avctx->sample_rate= 8000; + }else{ if (avctx->sample_rate != 8000) { av_log(avctx, AV_LOG_ERROR, "Sample rate 8000Hz required for GSM, got %dHz\n", avctx->sample_rate); + if(avctx->strict_std_compliance > FF_COMPLIANCE_INOFFICIAL) return -1; } if (avctx->bit_rate != 13000 /* Official */ && @@ -51,8 +60,10 @@ avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when decoding */ ) { av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got %dbps\n", avctx->bit_rate); + if(avctx->strict_std_compliance > FF_COMPLIANCE_INOFFICIAL) return -1; } + }
avctx->priv_data = gsm_create();
Maybe switch on codecID: 0 and 13200 for GSM, 0 and 13000 for GSM MS? But I can do that later. So, OK for me. assuming a patch that results in incorrect identation is OK, I suppose you will follow with a correction?) Greetings, -- Michel Bardiaux http://www.mediaxim.com/
On Tue, Apr 29, 2008 at 02:46:52PM +0200, Michel Bardiaux wrote: [...]
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 13005) +++ libavcodec/libgsm.c (working copy) @@ -41,9 +41,18 @@ avctx->channels); return -1; } + + if(avctx->codec->decode){ + if(!avctx->channels) + avctx->channels= 1; + + if(!avctx->sample_rate) + avctx->sample_rate= 8000; + }else{ if (avctx->sample_rate != 8000) { av_log(avctx, AV_LOG_ERROR, "Sample rate 8000Hz required for GSM, got %dHz\n", avctx->sample_rate); + if(avctx->strict_std_compliance > FF_COMPLIANCE_INOFFICIAL) return -1; } if (avctx->bit_rate != 13000 /* Official */ && @@ -51,8 +60,10 @@ avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when decoding */ ) { av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got %dbps\n", avctx->bit_rate); + if(avctx->strict_std_compliance > FF_COMPLIANCE_INOFFICIAL) return -1; } + }
avctx->priv_data = gsm_create();
Maybe switch on codecID: 0 and 13200 for GSM, 0 and 13000 for GSM MS?
I agree that this would be a good idea if i wasnt that lazy ...
But I can do that later. So, OK for me. assuming a patch that results in incorrect identation is OK, I suppose you will follow with a correction?)
Applied, and indention fixed in subsequent patch. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
On Mon, Apr 28, 2008 at 01:53:56PM +0200, Michel Bardiaux wrote:
Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...]
While you guys are at it, there are still a couple of samples that do not work in ffplay:
http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.gsm
This one cant be recognized:
[mp3 @ 0x843b514]Could not find codec parameters (Audio: mp2, 8 kb/s) sample-gsm-8000.gsm: could not find codec parameters
What format is it?
I would guess it is raw GSM. You're the GSM expert, find out :)
http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov
This one works for me:
ffmpeg -i sample-gsm-8000.mov -vn -acodec pcm_s16le sample-gsm-8000.mov.wav
produces a wav with correct sound.
Hmm, disregard this, works fine now... Diego
Diego Biurrun wrote:
On Mon, Apr 28, 2008 at 01:53:56PM +0200, Michel Bardiaux wrote:
Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...] While you guys are at it, there are still a couple of samples that do not work in ffplay:
http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.gsm This one cant be recognized:
[mp3 @ 0x843b514]Could not find codec parameters (Audio: mp2, 8 kb/s) sample-gsm-8000.gsm: could not find codec parameters
What format is it?
I would guess it is raw GSM. You're the GSM expert, find out :)
Ah, but to-ast or not to-ast, that is the question (I *love* bad puns!) TOAST being the file format that comes with the Berlin implementation known as libgsm. IIRC 4 'magic' bits are prepended (or is it appended?) to every block of 33 bytes minus 4 bits. I really need to know the origin. Strangely http://samples.mplayerhq.hu/A-codecs/GSM/ states this file dates back to 2002-Aug-08, I doubt that very much. Time for sherlocking my list archives...
http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.mov This one works for me:
ffmpeg -i sample-gsm-8000.mov -vn -acodec pcm_s16le sample-gsm-8000.mov.wav
produces a wav with correct sound.
Hmm, disregard this, works fine now...
That is what you get for posting a problem without upgrading then posting your command line and messages :-)
-- Michel Bardiaux http://www.mediaxim.com/
On Mon, Apr 28, 2008 at 01:53:56PM +0200, Michel Bardiaux wrote: [...]
http://samples.mplayerhq.hu/A-codecs/GSM/sample-gsm-8000.gsm
This one cant be recognized:
[mp3 @ 0x843b514]Could not find codec parameters (Audio: mp2, 8 kb/s) sample-gsm-8000.gsm: could not find codec parameters
What format is it?
raw gsm, i assume [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is not what we do, but why we do it that matters.
On Fri, Apr 25, 2008 at 07:49:41PM +0200, Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...]
While you guys are at it, there are still a couple of samples that do not work in ffplay:
This sample still behaves weirdly with ffplay. 2-4 seconds with credits at the are skipped. MPlayer plays the beginning, even with -demuxer lavf. I tried to submit this to roundup, but roundup just spits back Error: 'actor' so I'm reporting this here. Diego
On Wed, Apr 30, 2008 at 11:54:45AM +0200, Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 07:49:41PM +0200, Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...]
While you guys are at it, there are still a couple of samples that do not work in ffplay:
This sample still behaves weirdly with ffplay. 2-4 seconds with credits at the are skipped. MPlayer plays the beginning, even with -demuxer lavf.
I meant that 2-4 seconds with credits at the beginning are skipped. Diego
On Wed, Apr 30, 2008 at 11:54:45AM +0200, Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 07:49:41PM +0200, Diego Biurrun wrote:
On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
[...]
While you guys are at it, there are still a couple of samples that do not work in ffplay:
This sample still behaves weirdly with ffplay. 2-4 seconds with credits at the are skipped. MPlayer plays the beginning, even with -demuxer lavf.
should be fixed in r21590 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
Should the log message have a parameter that corresponds to the %d ?
+ av_log(avctx, AV_LOG_WARNING, "Bit rate %d instead of expected 13000 - ignored\n");
On Fri, Mar 28, 2008 at 1:26 PM, Michel Bardiaux <mbardiaux at mediaxim.be> wrote:
Michael Niedermayer wrote:
Hi
On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote:
Hi
On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
Michael Niedermayer wrote: > Hi [snip] > is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM? Yes and no. The last 4 bits of each frame are not actually used,
come on stage only because we (both libgsm and lavc) use a byte-oriented API, and files made of bytes. They should be considered as container overhead in TOAST files, hence not part of the codec bitrate. but with this argumentation we would have to subtract the padding bits from mpeg from the bitrate too and thats something we dont I think you're talking codec-level padding here, but I wrote of container overhead.
also it would cause problems for containers which expect the bitrate well to be the bitrate of what they get, not to be slightly less due to some padding bits they dont know about ... AFAIK currently only some MS containers (AVI, WAV) accept GSM, and
Baptiste Coudurier wrote: they then
only MS-GSM, which does not have the problem. The only container for non-MS-GSM is TOAST (currently not implemented) and that one knows about the 4 extra bytes. well a grep for gsm shows a hit in aiff.c so it seems it is supported in a non toast format currently and as there is no gsm specific code in it i would guess it will end with 13200 as bitrate
anyway i wont fight about this appl the patch, i will remove the 13000 check when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for decoding (encoding shares the function), IMHO we don't care about bitrate when decoding.
Can I remove it ?
Oops, forgot I am maintainer for libgsm!
Since bitrate is also irrelevant for encoding, what about this?
-- Michel Bardiaux http://www.mediaxim.com/
Index: libavcodec/libgsm.c =================================================================== --- libavcodec/libgsm.c (revision 12579) +++ libavcodec/libgsm.c (working copy) @@ -36,8 +36,10 @@ #define GSM_FRAME_SIZE 160
static av_cold int libgsm_init(AVCodecContext *avctx) { - if (avctx->channels > 1 || avctx->sample_rate != 8000 || avctx->bit_rate != 13000) + if (avctx->channels > 1 || avctx->sample_rate != 8000) return -1; + if (avctx->bit_rate != 13000) + av_log(avctx, AV_LOG_WARNING, "Bit rate %d instead of expected 13000 - ignored\n");
avctx->priv_data = gsm_create();
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
participants (6)
-
baptiste.coudurier＠smartjog.com -
benoit.fouet＠purplelabs.com -
danceguy＠gmail.com -
diego＠biurrun.de -
mbardiaux＠mediaxim.be -
michaelni＠gmx.at