Hey guys,
the latest revision of the (E-)AC3 spec says:
> The optimum scaling for the dither words is to take a
> uniform distribution of values between –1 and +1, and
> scale this by 0.707, resulting in a uniform distribution
> between +0.707 and –0.707
Currently the AC3 decoder applies a dithe
2013/1/9 Justin Ruggles
> New FATE samples uploaded. Will push in 24 hrs.
Thanks, appreciated.
Best regards, Mathias.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
2011/7/23 Daniel Kang
> I've been working on optimizing 10-bit H.264 decoding
> on x86/x64 for the past months. Before I started, 10-bit
> H.264 HD content was unplayable in real-time, but now,
> with a recent CPU, it is.
> Overall improvements are about 53%. With threading,
> about 61% (with resp
Patch looks "correct" to me, as in that it properly describes
what avcodec_decode_video2() currently does.
I have to say, though, that I find the avcodec_decode_video2()
behaviour pretty bad, with multithreading enabled. I mean, if
I have a buffer with multiple frames in it, and I feed the buffer
2011/8/3 Ronald S. Bultje
> we could just "require" that the full buffer be consumed
> in its entirity
I would like that *a lot*.
Would that work under all circumstances, though?
E.g. even if there are multiple frames in the buffer, or
even if there's only half a frame in the buffer?
Best regar
2011/8/3 Ronald S. Bultje
> Those don't work already anyway. Also, they're hard
> to fix if we allow decoders to consume only half of
> them.
I understand.
So how about the following texts for the header:
* @return On error a negative value is returned, otherwise zero or a
* positive number is
> BTW, the same multithreading "useless return value" problem
> occurs with "av_parser_parse2()", if the codec context of the
> bitstream parser is set to multitheaded.
P.S: I'm not 100% sure on that, but that was my impression on a quick check.
Best regards, Mathias.
2011/8/16 Diego Biurrun
> From: Baptiste Coudurier
> Signed-off-by: Diego Biurrun
Wow, very nice - thanks a lot! :-)
Best regards, madshi.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
> There have been complaints about how ffmpeg/libav
> converts M-bit to N-bit YUV, e.g. see
> http://forum.doom9.org/showthread.php?t=161915 which
> I've been asked to look into.
Glad to see the doom9 thread ending up here!
FWIW, the problem applies to RGB, as well, not just to YUV.
> The curren
2011/8/25 Uoti Urpala
> > Not necessarily. If you upscale like that, smooth
> > gradiants will not be perfectly smooth, anymore.
> Gradients are perfectly smooth for a 8->16 conversion like
> that. You seem to be assuming the special case of a 8->10
> conversion done by shifting out the lowest bit
2011/4/24 Måns Rullgård
> Anyway, why this patch at all if it's temporary?
@Måns, let me ask you a question:
Are you aware of that the proper way to reduce
bitdepth in digital data processing (both video
and audio) includes dithering? If you're not aware
of that, then please do some research.
P
> If you have any ideas on how to speed it up, I'm very
> open to new ideas on how to chase license violators.
The first step should be to contact the violator, and politely ask
him to fix the violation, because I'm pretty sure that violation is
sometimes (not always) accidental. If the violator i
> 2011/5/19 Ronald S. Bultje
> I prefer coding.
Haha! Me, too... ;-)
Just saying, if I did something wrong, without being
aware of that, I'd very much appreciate getting a hint
and a chance to rectify the problem, before being shot
at by lawyers. There's a gigantic difference between
intentiona
> Our lawyers are good people
Is that even possible? Haha! Just kidding...
> that handle in the best interest of both our project
> as well as its users. Without our users, our project
> is pointless. So I assure you the above is taken
> care of by our lawyers.
Ok, in that case all is fine, I gu
> 2011/5/28 Kirill Gavrilov
> WinAPI provides Sleep() function which gets milliseconds
> as argument.
FWIW, here's a function which accepts microseconds as a parameter instead of
milliseconds. Unfortunately, Windows doesn't really do as requested. The
minimum sleep time seems to be >= 1 milliseco
> 2011/6/5 Jason Garrett-Glaser
> NOTE: THIS IS A WORK-IN-PROGRESS PATCH
Wow, didn't expect 4:4:4 decoding anytime soon! :)
May I ask where to get samples for testing from?
Thanks, Mathias.
___
libav-devel mailing list
libav-devel@libav.org
https://l
any colors that are
outside of the sRGB gamut. Because of that it would be nice
if you could alternatively also output DCI-P3 RGB instead of
sRGB.
Best regards, madshi.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
17 matches
Mail list logo
