Adam Roach wrote:
On 6/13/19 5:28 PM, Eric Shepherd (Sheppy) wrote: >> to be prepared. My experiements suggest that even where there are
codecs>> that have a lossless or near-lossless feature in the spec, they
tend >> not to>> be implemented, especially in browsers. So I guess
that’ll be a big
Eric Shepherd (Sheppy) wrote:
Once that’s done, these will be key articles in our media documentation, so
I want to be sure they’re accurate.
When would you like to have feedback by?
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists
raycarino--- via dev-media wrote:
1. How does a high sample rate decoded at a lower sample rate behave? Example:
will decode(48kHz.ogg 16kHz) === decode(16kHz.ogg, 16kHz), or can audio
artifacts be expected?
They won't give bit-identical results, but with some hand-waving about
the version e
raycarino--- via dev-media wrote:
I have a follow on question. What's the best way to determine an Ogg Opus
file's encoded sample rate?
Opus is a lossy codec. The sample rate is something that is lost as part
of the lossy encoding. The original sample rate in the header gives you
a hint as t
raycarino--- via dev-media wrote:
I'm on firefox 59. My microphone records audio at a sample rate of 44.1khz.
However, MediaRecorder outputs OGG Opus audio at 48khz.
This is what you wanted, right?
Thank you for the quick reply!
Sorry, for the typo. Expected: 48kHz output. Actual is 44.1kHz.
raycarino--- via dev-media wrote:
Hi, I'm attempting to record audio via MediaRecorder at 48khz regardless of my
microphone's sample rate.
Okay.
I'm on firefox 59. My microphone records audio at a sample rate of 44.1khz.
However, MediaRecorder outputs OGG Opus audio at 48khz.
This is what
Robert O'Callahan wrote:
them. It's a bit tricky to remove them after the decoder. Could I just
Why? You can treat the return value exactly the same as a return value
of 0. I.e., you can still call th_decode_ycbcr_out(), it will just
return a buffer with the same contents as the last call.
Paul Adenot wrote:
(or computed at all). I think it can be handled just outside the graph
without much problems and less complexity:
MSG already has a tendency to push complexity out into its clients,
making every source/sink handle it independently (silence frames are a
good example, see bug
Adam Roach wrote:
Now, revocation is inherently state that we need to store; but
revocation events should be infrequent. Nonetheless, we don't want to
I assume you've thought about just using time-based expiration instead?
___
dev-media mailing list
Robert Kaiser wrote:
widely enough. Apart from that, every line of code adds a maintenance,
stability and security risk to our product, and codec are usually
millions of lines of code, therefore large risks in those terms. For
For reference, sloccount in media/libtheora says 12,594 LOC, and in
Maire Reavy wrote:
from Tuesday at 9am Pacific to Thursday or Friday morning. If anyone who
is planning to attend has a preferred day or time, let me know. I'll
Friday works better for me, since I'm traveling Thursday.
___
dev-media mailing list
dev
Chris Pearce wrote:
The Ogg backend has always ignored invalid streams in files and played
the valid, and I'd just followed that precedent.
We've supported this approach in the Xiph libraries and applications
because at various times things like Skeleton and subtitles were treated
as "unknown
Ralph Giles wrote:
implementing an exception handler. Without 'goto' cleanup code has to be
duplicated for every fatal error check, and using macros instead is even
harder to keep track of when reading the code. As long as the jump
I don't think this is true. I haven't found a use of goto that
For the record, see https://bugzilla.mozilla.org/show_bug.cgi?id=709883
Marco Chen wrote:
Dear Rob,
For method 1:
[...]
Result: After phone call, user will find the time is already
shifted later or even the music is jumped to another one.
This is what happens if you mute the audio outpu
Robert O'Callahan wrote:
recordings in for B2G, and you suggested AAC. I think it might make more
sense to record in Opus format instead --- http://www.opus-codec.org/ ---
To paraphrase EKR, "I'm derf and I approve this message" (sorry, it is
election season in the US).
The only downside I
Mike Ressler wrote:
The choppiness is occurring throughout. ffmpeg2theora is reporting the bitrate
of the video is 5888.682129, which I assume is KB/s. It's a 2.3 GB file, which
I've shared on my webserver. Let me know if you'd like to DL the file and I'll
post the link here.
Can you test
Robert O'Callahan wrote:
There is one other piece that needs to be added to the infrastructure:
we should also have a mode flag for SourceMediaStream so that while it's
blocked, we throw away buffered data. I think that's what Randell wanted
originally.
I guess I'm confused as to how that's dis
Randell Jesup wrote:
So, I think what should be happening here is that a mediastream (at
least one with a realtime source) should throw away at the output if the
consumer doesn't consume.
The way this was originally designed, a MediaInput to a
ProcessedMediaStream has blockInput and blockOutpu
Maire Reavy wrote:
I think we should remove the "full getUserMedia backend working on
Android" goal for Q3. (I've quoted the current goal list below for
reference.)
I think this makes sense.
___
dev-media mailing list
dev-media@lists.mozilla.org
http
Randell Jesup wrote:
What will be the clock rate for input audio streams? Will we resample
to the output clock rate?
I think this makes the most sense. You can't really have more than one
clock inside the MediaStream graph without introducing a lot of
complexity. Maybe someday, but I don't t
Randell Jesup wrote:
3rd tranche: (June 29)
SCTP/DataChannel (netwerk)
transport service (ICE/TURN and p2p transport from EKR)
This is going to need an NSS update, so someone will have to coordinate
that.
---
Reviews needed:
We will be doing normal line-by-line review
21 matches
Mail list logo
