hD Student in Computer Science*
> Georgia Institute of Technology
> North Ave NW, Atlanta, GA 30332, USA
IMO, the x2 speed boost is a positive result, depending on the GOP
size. Decoding a series of P frames is much faster than for the same
amount of I frames. I don't believe some
xt which simply calls
read(), write(), and lseek() on an `fd` is minimal, but even this must
be measured carefully to compare with the original `file:` protocol.
Sincerely,
Alex Cohn
On Mon, Jul 27, 2020 at 4:45 PM Olivier Ayache wrote:
>
> You're welcome.
>
> Can I suggest
,
Alex Cohn
On Mon, Jul 27, 2020 at 11:01 AM Olivier Ayache
wrote:
>
> A good alternative to work with FFmpeg on Android is Xuggler, it presents
> FFmpeg's API directly to Java/Kotlin.
>
> To deal with fd you can declare and implement your own IO handler by
> implementi
d Q a.k.a. Android 10, also API 29) made yet
another small step in this direction and caused lots of problems for
apps that rely upon file access by path. This was the incentive for me
to work on the ways to teach avformat to work with the `content:` URIs
correctly.
BR,
Alex Cohn
_
On Sat, Jul 25, 2020 at 9:37 PM Matthieu Bouron
wrote:
>
> On Wed, Jul 22, 2020 at 2:38 PM Alex Cohn
wrote:
>
> > Usually, we employ the `pipe:` protocol to deal with the numerical
> > file descriptors, and this answers all our needs. On Android, there is
> > a
ther way
adds a `content://` protocol and does all heavy lifting (calling
system Java API through JNI) itself.
I would like to submit my contribution to ffmpeg-devel, but I am in
doubt which of the two approaches may better fit the ffmpeg
development paradigm, if any.
Best Reg
