2018-11-24 10:27 GMT+01:00, Igor Derzhavin :
> Do you accept these patches? Or what can I do more?
> We use ffmpeg (libavformat/libavcodec) within our company and came across
> that http url with content type
> "audio/l16;rate=24000;channels=1;endianness=big-endian" incorrectly opens
> as s16le wi
On 11/22/18, Igor Derzhavin wrote:
> Hello!
> A little bunch of fixes for audio/L16 mime type handling:
> 0001 - RFC 2045 says MIME type should be case insensitive;
> 0002 - RFC 2586 says audio/L16 should be in network byte order (aka big
> endian);
> 0003 - though "endiannes" parameter not in RFC
Hello!
Do you accept these patches? Or what can I do more?
We use ffmpeg (libavformat/libavcodec) within our company and came across
that http url with content type
"audio/l16;rate=24000;channels=1;endianness=big-endian" incorrectly opens
as s16le with sample rate 16000.
This patches fixes that.
O
No, I don't now applications that can play pcm streams through HTTP. VLC
misdetect such streams as mp3, and there is a two years old bug
https://trac.videolan.org/vlc/ticket/17229.
On Thu, Nov 22, 2018 at 4:00 PM Carl Eugen Hoyos wrote:
> 2018-11-22 10:16 GMT+01:00, Igor Derzhavin :
>
> > A litt
2018-11-22 10:16 GMT+01:00, Igor Derzhavin :
> A little bunch of fixes for audio/L16 mime type handling:
> 0001 - RFC 2045 says MIME type should be case insensitive;
> 0002 - RFC 2586 says audio/L16 should be in network byte order (aka big
> endian);
> 0003 - though "endiannes" parameter not in RF
Hello!
A little bunch of fixes for audio/L16 mime type handling:
0001 - RFC 2045 says MIME type should be case insensitive;
0002 - RFC 2586 says audio/L16 should be in network byte order (aka big
endian);
0003 - though "endiannes" parameter not in RFC it is widely used;
From e40e9567995042d75f8070d
