Re: [FFmpeg-devel] [PATCH 10/12] avcodec: add MediaCodec encoder
>That’s the case from my test on Google Pixel 3. There is no ‘csd’ inside >MediaFormat returned by ff_AMediaCodec_getOutputFormat(), until a frame >has been sent. It may depends on the device and OS. Hello there, if it can help concerning the csd your asumption is right and not only on Pixel 3. When I wrote my encoder (only using the NDK) I have to manually add csd in extradata after encoding the first frame. I study a lot the Android AOSP source code especially media framework and libstagefright. Here is what I did in one of my project that use the encoder https://github.com/olivierayache/xuggle-xuggler-android/blob/dbc8eaca734684b1763399da12ecdffa2508cc89/xuggler-android-extensions/src/main/java/com/xuggle/xuggler/record/MediaRecorder.kt#L420 At the time I worked on that I didn't do it directly in FFmpeg but it seems interesting to store the CSD when the first frame is encoded. Olivier Ayache On Sat, Nov 19, 2022 at 6:13 PM "zhilizhao(赵志立)" wrote: > > > > On Nov 19, 2022, at 17:15, Aman Karmani wrote: > > > > > > > > On Sun, Oct 23, 2022 at 8:17 PM Zhao Zhili > wrote: > > From: Zhao Zhili > > > > Signed-off-by: Zhao Zhili > > --- > > Changelog | 1 + > > configure | 4 + > > libavcodec/Makefile | 2 + > > libavcodec/allcodecs.c | 2 + > > libavcodec/mediacodec_wrapper.c | 102 ++- > > libavcodec/mediacodec_wrapper.h | 8 + > > libavcodec/mediacodecenc.c | 495 > > libavcodec/version.h| 4 +- > > 8 files changed, 611 insertions(+), 7 deletions(-) > > create mode 100644 libavcodec/mediacodecenc.c > > > > diff --git a/Changelog b/Changelog > > index 9e203833aa..9e39a35972 100644 > > --- a/Changelog > > +++ b/Changelog > > @@ -19,6 +19,7 @@ version : > > - DTS to PTS reorder bsf > > - ViewQuest VQC decoder > > - MediaCodec decoder via NDKMediaCodec > > +- MediaCodec encoder > > > > > > > > version 5.1: > > diff --git a/configure b/configure > > index ee2e3ba6ac..5114cda13f 100755 > > --- a/configure > > +++ b/configure > > @@ -3193,6 +3193,8 @@ h264_cuvid_decoder_select="h264_mp4toannexb_bsf" > > h264_mediacodec_decoder_deps="mediacodec" > > h264_mediacodec_decoder_extralibs="-landroid" > > h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_parser" > > +h264_mediacodec_encoder_deps="mediacodec" > > +h264_mediacodec_encoder_extralibs="-landroid" > > h264_mf_encoder_deps="mediafoundation" > > h264_mmal_decoder_deps="mmal" > > h264_nvenc_encoder_deps="nvenc" > > @@ -3212,6 +3214,8 @@ hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf" > > hevc_mediacodec_decoder_deps="mediacodec" > > hevc_mediacodec_decoder_extralibs="-landroid" > > hevc_mediacodec_decoder_select="hevc_mp4toannexb_bsf hevc_parser" > > +hevc_mediacodec_encoder_deps="mediacodec" > > +hevc_mediacodec_encoder_extralibs="-landroid" > > hevc_mf_encoder_deps="mediafoundation" > > hevc_nvenc_encoder_deps="nvenc" > > hevc_nvenc_encoder_select="atsc_a53" > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > > index 90c7f113a3..7d0b513eec 100644 > > --- a/libavcodec/Makefile > > +++ b/libavcodec/Makefile > > @@ -393,6 +393,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o > h264_cabac.o h264_cavlc.o \ > > OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o > > OBJS-$(CONFIG_H264_CUVID_DECODER) += cuviddec.o > > OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o > > +OBJS-$(CONFIG_H264_MEDIACODEC_ENCODER) += mediacodecenc.o > > OBJS-$(CONFIG_H264_MF_ENCODER) += mfenc.o mf_utils.o > > OBJS-$(CONFIG_H264_MMAL_DECODER) += mmaldec.o > > OBJS-$(CONFIG_H264_NVENC_ENCODER) += nvenc_h264.o nvenc.o > > @@ -417,6 +418,7 @@ OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o > hevc_mvs.o \ > > OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o > > OBJS-$(CONFIG_HEVC_CUVID_DECODER) += cuviddec.o > > OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o > > +OBJS-$(CONFIG_HEVC_MEDIACODEC_ENCODER) += mediacodecenc.o > > OBJS-$(CONFIG_HEVC_MF_ENCODER) += mfenc.o mf_utils.o > > OBJS-$(CONFIG_HEVC_NVENC_ENCODER) += nvenc_hevc.o nvenc.o > > OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec.o > > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodec
Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec encoder and NDK MediaCodec support
Hello here is the work I have pushed in a fork of FFmpeg integrated in source code of xuggler (a Java/C++ wrapper of FFmpeg) https://github.com/olivierayache/xuggle-xuggler/commit/98469ebea59c921f46a114bd954f7a27a7c95a41 For the limitations of NDK I agree with you and that is why I have made some backport to be able to support all needed features for FFmpeg (when I worked on that it was FFmpeg 3.4.x version). This backport allows support to these functions for Android devices since API 21 (which is more than 99% of devices). - AMediaCodec_createInputSurface - AMediaCodec_setParameters - ANativeWindow_toSurface For testing reviewing the patch I will make it as soon as I update FFmpeg to the current version. I will be able to do it this week. Olivier Le dim. 13 nov. 2022, 12:49, Zhao Zhili a écrit : > > > From: ffmpeg-devel On Behalf Of > Olivier Ayache > > Sent: 2022年11月12日 18:00 > > To: FFmpeg development discussions and patches > > Cc: matthieu.bou...@stupeflix.com; a...@tmm1.net > > Subject: Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec > encoder and NDK MediaCodec support > > > > Hello there I implemented that few years ago in > > https://github.com/olivierayache/xuggle-xuggler/ > > I can't find where is the patch or source code of FFmpeg. > > > And when I tried to submit a patch to FFmpeg for add support for NDK I > had > > received this answer. > > I think using NDK directly rather than JNI can be better in case of > > developing native application on Android. > > NDK is still missing some important features, and some features only > supported recently. > So the NDK implementation doesn't meant to be a replacement of the JNI > version: > 1. JNI version has more features and supports more devices > 2. NDK implementation combined with some JNI functions has almost the same > feature > As JNI version on new devices. > 3. In the environment where JVM is unavailable, the NDK version is the > only choice. > > > If I can help on these subjects I would be really happy > > Welcome to review and/or test the patch. > > > > > Olivier Ayache > > > > > > > > -- Forwarded message - > > From: Olivier Ayache > > Date: Sun, Jun 28, 2020 at 2:48 PM > > Subject: Re: [FFmpeg-devel] [PATCH] add support to Android ndk MediaCodec > > for encoding/decoding > > To: > > > > > > Thank for your replies I choose the NDK approach in order to be able to > be > > independant from the JVM, to maximize performance and to be sure to > detect > > compatibility issues (using JNI approach can compile and crash at > runtime). > > Concerning the version of Android it is compatible from API 21 (94% of > > devices) > > I agree that JNI overhead is not big but in combinaison with Xuggler it > > seems to me a little weird because Xuggler (Java part) already use JNI to > > interact with Xuggler (C++) and FFmpeg. If FFmpeg uses JNI in the other > way > > (from c to Java) it seems to me an anti pattern. > > > > If you think it is better to begin to use JNI I could transform my > encoder > > and we could discuss about NDK after > > > > Olivier > > > > > > > > Le sam. 27 juin 2020 à 20:55, Martin Storsjö a écrit > : > > > > > On Sat, 27 Jun 2020, Olivier Ayache wrote: > > > > > > > Hi everyone this is the first time I post on this mailing list. I am > > > > working since several years on a fork of Xuggler for manipulating > ffmpeg > > > > API with Java/Kotlin. > > > > This work leads me to develop encoder and decoder based on Android > NDK > > > > MediaCodec. > > > > > > > > This work can be found on my Github repository > > > > > > > > https://github.com/olivierayache/xuggle-xuggler > > > > > > > > > > > > I know that FFmpeg already integrate MediaCodec for decoding via Jni > > > > wrappers since version 3.1. I began this work on FFmpeg 2.8.x and I > > > choose > > > > the NDK in order to achieve optimum performance. > > > > > > If you mean you used the NDK MediaCodec API, I'd suggest you use the > same > > > JNI wrappers as ffmpeg has already, for consistency. The overhead of a > few > > > JNI calls per encoded frame is generally negligible. If it, at a later > > > time, is decided to drop support for older versions at some point, it > > > should be straightforward to convert it to use the NDK MediaCodec API > > > instead. > > > > > > //
Re: [FFmpeg-devel] Consulting Request
Thank you for your answer. I am sad not to have seen it before. Anyway as I already replied this morning on the thread it would be a pleasure to help in FFmpeg project if needed. Olivier Ayache Le sam. 12 nov. 2022, 12:58, Matthieu Bouron a écrit : > Hello, > > This work has been submitted to the ml recently, see: > http://ffmpeg.org/pipermail/ffmpeg-devel/2022-November/303847.html > > Matthieu > > On Sat, Nov 12, 2022 at 11:13 AM Olivier Ayache > wrote: > > > Hello and sorry for my late answer but few years ago I have implemented > > this kind of feature. > > Here is a repo containing my work > > https://github.com/olivierayache/xuggle-xuggler. > > In my current company we use it in production for implementing a media > > studio on Android with HW acceleration support. > > > > Olivier Ayache > > > > On Fri, Jun 3, 2022 at 5:02 PM Samuel Raposo Vieira Mira < > > samuel.m...@qt.io> > > wrote: > > > > > Hi all, > > > > > > We are Qt (www.qt.io), a global software company with a strong > presence > > > in more than 70 industries and is the leading independent technology > > behind > > > 1+ billion devices and applications. > > > > > > Now we are working on integrating the FFmpeg library into our > Multimedia > > > module as one of the possible backends. > > > Android is one of our target platforms, and we now face the issue of > > > lacking Hardware Acceleration for Encoding for Android. > > > > > > We are evaluating the possibility of hiring a consulting service to > > > implement the Mediacodec Hardware encoder in FFmpeg. > > > So we would like to know if any developer would be interested in taking > > on > > > this consulting project. > > > > > > Regards, > > > Samuel Mira > > > Senior Software Developer > > > The Qt Company > > > Tutkijantie 4C > > > FI-90590 Oulu > > > Finland > > > samuel.m...@qt.io<mailto:samuel.m...@qt.io> > > > www.qt.io<https://www.qt.io> > > > [signature_1385223811]<https://www.qt.io/> > > > [signature_2378664325]<https://www.facebook.com/qt/> > > > [signature_2256736393]<https://twitter.com/qtproject> > > > [signature_2852832549]< > https://www.linkedin.com/company/the-qt-company/> > > > [signature_228390225]<https://www.youtube.com/QtStudios> > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > To unsubscribe, visit link above, or email > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Consulting Request
Hello and sorry for my late answer but few years ago I have implemented this kind of feature. Here is a repo containing my work https://github.com/olivierayache/xuggle-xuggler. In my current company we use it in production for implementing a media studio on Android with HW acceleration support. Olivier Ayache On Fri, Jun 3, 2022 at 5:02 PM Samuel Raposo Vieira Mira wrote: > Hi all, > > We are Qt (www.qt.io), a global software company with a strong presence > in more than 70 industries and is the leading independent technology behind > 1+ billion devices and applications. > > Now we are working on integrating the FFmpeg library into our Multimedia > module as one of the possible backends. > Android is one of our target platforms, and we now face the issue of > lacking Hardware Acceleration for Encoding for Android. > > We are evaluating the possibility of hiring a consulting service to > implement the Mediacodec Hardware encoder in FFmpeg. > So we would like to know if any developer would be interested in taking on > this consulting project. > > Regards, > Samuel Mira > Senior Software Developer > The Qt Company > Tutkijantie 4C > FI-90590 Oulu > Finland > samuel.m...@qt.io<mailto:samuel.m...@qt.io> > www.qt.io<https://www.qt.io> > [signature_1385223811]<https://www.qt.io/> > [signature_2378664325]<https://www.facebook.com/qt/> > [signature_2256736393]<https://twitter.com/qtproject> > [signature_2852832549]<https://www.linkedin.com/company/the-qt-company/> > [signature_228390225]<https://www.youtube.com/QtStudios> > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec encoder and NDK MediaCodec support
Hello there I implemented that few years ago in https://github.com/olivierayache/xuggle-xuggler/ And when I tried to submit a patch to FFmpeg for add support for NDK I had received this answer. I think using NDK directly rather than JNI can be better in case of developing native application on Android. If I can help on these subjects I would be really happy Olivier Ayache -- Forwarded message - From: Olivier Ayache Date: Sun, Jun 28, 2020 at 2:48 PM Subject: Re: [FFmpeg-devel] [PATCH] add support to Android ndk MediaCodec for encoding/decoding To: Thank for your replies I choose the NDK approach in order to be able to be independant from the JVM, to maximize performance and to be sure to detect compatibility issues (using JNI approach can compile and crash at runtime). Concerning the version of Android it is compatible from API 21 (94% of devices) I agree that JNI overhead is not big but in combinaison with Xuggler it seems to me a little weird because Xuggler (Java part) already use JNI to interact with Xuggler (C++) and FFmpeg. If FFmpeg uses JNI in the other way (from c to Java) it seems to me an anti pattern. If you think it is better to begin to use JNI I could transform my encoder and we could discuss about NDK after Olivier Le sam. 27 juin 2020 à 20:55, Martin Storsjö a écrit : > On Sat, 27 Jun 2020, Olivier Ayache wrote: > > > Hi everyone this is the first time I post on this mailing list. I am > > working since several years on a fork of Xuggler for manipulating ffmpeg > > API with Java/Kotlin. > > This work leads me to develop encoder and decoder based on Android NDK > > MediaCodec. > > > > This work can be found on my Github repository > > > > https://github.com/olivierayache/xuggle-xuggler > > > > > > I know that FFmpeg already integrate MediaCodec for decoding via Jni > > wrappers since version 3.1. I began this work on FFmpeg 2.8.x and I > choose > > the NDK in order to achieve optimum performance. > > If you mean you used the NDK MediaCodec API, I'd suggest you use the same > JNI wrappers as ffmpeg has already, for consistency. The overhead of a few > JNI calls per encoded frame is generally negligible. If it, at a later > time, is decided to drop support for older versions at some point, it > should be straightforward to convert it to use the NDK MediaCodec API > instead. > > // Martin > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". On Sat, Nov 12, 2022 at 6:07 AM Zhao Zhili wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Chema > Gonzalez > > Sent: 2022年11月12日 0:55 > > To: FFmpeg development discussions and patches > > Cc: matthieu.bou...@stupeflix.com; a...@tmm1.net > > Subject: Re: [FFmpeg-devel] [Internet][PATCH 00/12] Add MediaCodec > encoder and NDK MediaCodec support > > > > On Thu, Nov 10, 2022 at 7:36 PM "zhilizhao(赵志立)" > wrote: > > > > > > Ping for review. > > > > > > > On Oct 24, 2022, at 11:16, Zhao Zhili > wrote: > > > > > > > > From: Zhao Zhili > > > > > > > > Firstly, some bugs were fixed (patch 1-4). > > > > > > > > Patch 5 and 6 make mediacodec_wrapper support Java MediaCodec and NDK > > > > MediaCodec. The use case I'm considering is run FFmpeg on cmdline > without JVM, > > > > for example, run FFmpeg inside of termux (an Android terminal > emulator). It's > > > > well known that NDK MediaCodec missing some important functions, > like get the > > > > list of codecs, but still useable. > > > > > > > > Patch 7 add NDK MediaCodec decoder support. It can be enabled via > options, > > > > and enabled automatically if no JVM is available. > > > > > > > > Patch 8 add ANativeWindow support to hwcontext_mediacodec. It can be > set by > > > > user, and can be created via AMediaCodec_createPersistentInputSurface > > > > automatically. This is a preparation for encoder. > > > > > > > > Patch 9 makes MediaCodec decoder to support ANativeWindow directly. > It worth > > > > to note that AVMediaCodecContext has only surface. Although we > provided > > > > av_mediacodec_alloc_context(), we didn't strictly prevent users to > allocate > > > > AVMediaCodecContext on stack. I'm not sure if it's OK to add new > f
Re: [FFmpeg-devel] FFmpeg for android
Hi, I am not sure this mailing list is the right place to discuss about that but I am actively work with FFmpeg and Android since multiple years. My work is based on this project https://github.com/olivierayache/xuggle-xuggler which is fully working with Android and support HW encoding/decoding Best Olivier Ayache Le mer. 30 sept. 2020 à 10:15, shaheer cs a écrit : > Hi, > Greetings of the day, > > > Iam an android developer. And iam currently working on video streaming > platform when user can do video compression,video trim etc. So I found that > by using FFmpeg I can achieve most of my application functionality(Thanks > for being best tool for developer like me) I have done POC with prebuild > FFmpeg binaries which is developed by some people and I face > Some difficulties like to support 32bit and 64 bit for android, lack of > codec etc.. so I have finalize that should build FFmpeg and JNI class > myself. Now I am facing lack of tutorial, examples and documentation where > how to build ourself. So here I request you to help me on this by providing > any above. > > I looking forward to reply from you. > > Thanking you > Shaheer cs > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] working with file descriptors on Android
When you close IContainer with InputStream. It will be automatically close. You can see Implementation here https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/InputOutputStreamHandler.java For the JNI overhead it must be measured but normally by working with native byte buffers it should be limited. Best Olivier Le lun. 27 juil. 2020 à 17:02, Alex Cohn a écrit : > Yes, I would definitely be glad to join forces. > > That's true that the fd will be closed with the stream, or when the > owning ParcelFileDescritpor is closed. But what decides when the > stream/ParcelFileDescritpor can be closed? With `file:` protocol, it's > very natural that avformat closes the fd when it's done with it. Here, > we must manage the timespan of a Java object… Not nice, IMO. > > I wonder what overhead Java implementation of AVIOContext introduces, > but crossing the JNI border for every `read_packet()` may not be > negligible. > > I believe that the performance price of AVIOContext 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 you to try IContainer.open with InputStream/OutputStream. > If > > you use a FileInputStream created from the file descriptor retrieved with > > > https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT > > Normally fd will be automatically closed by the stream. > > > > If you're interested we could work together on this because I also need > to > > implement this type of feature for my projects. > > > > Best > > > > Olivier > > > > Le lun. 27 juil. 2020 à 14:46, Alex Cohn a > > écrit : > > > > > Thanks Olivier, > > > > > > Custom IO looks like a nice way to work around the protocol > > > limitations. Unfortunately, it cannot work with avio_open(), so the > > > API becomes trickier for end users. > > > > > > Also, just like with pipes, I cannot reliably close the file > > > descriptor when ffmpeg execution is over, can I? > > > > > > BR, > > > 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 > > > > implementing > > > > > > > > https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/IURLProtocolHandler.java > > > > > > > > I currently maintain a fork which is fully working on Android (work > in > > > > progress for iOS with Kotlin multiplatform). > > > > > > > > https://github.com/olivierayache/xuggle-xuggler > > > > > > > > Best > > > > > > > > Olivier Ayache > > > > > > > > Le dim. 26 juil. 2020 à 23:16, Alex Cohn > a > > > > écrit : > > > > > > > > > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Without having too much opinion on the JNI stuff (direct access > to > > > > > > content:// urls might be convenient, but on the other hand, it's > not > > > > > > really something you'd end up with if using the command line > tool on > > > its > > > > > > own - if you have one of those you most probably have some java > code > > > for > > > > > > getting it anyway - as far as I remember...) > > > > > > > > > > > > > > > You are more than right, Martin. > > > > > > > > > > None of these approaches can work with a command line tool. Worse, > > > > > running a command line tool in the context of an Android app is > > > > > becoming trickier with every new release of the platform, and in > this > > > > > case I cannot blame it on poor engineering. This happens because > > > > > Google tries to tighten the security on Android just as much as > > > > > possible. > > > > > > >
Re: [FFmpeg-devel] working with file descriptors on Android
You're welcome. Can I suggest you to try IContainer.open with InputStream/OutputStream. If you use a FileInputStream created from the file descriptor retrieved with https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT Normally fd will be automatically closed by the stream. If you're interested we could work together on this because I also need to implement this type of feature for my projects. Best Olivier Le lun. 27 juil. 2020 à 14:46, Alex Cohn a écrit : > Thanks Olivier, > > Custom IO looks like a nice way to work around the protocol > limitations. Unfortunately, it cannot work with avio_open(), so the > API becomes trickier for end users. > > Also, just like with pipes, I cannot reliably close the file > descriptor when ffmpeg execution is over, can I? > > BR, > 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 > > implementing > > > https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/IURLProtocolHandler.java > > > > I currently maintain a fork which is fully working on Android (work in > > progress for iOS with Kotlin multiplatform). > > > > https://github.com/olivierayache/xuggle-xuggler > > > > Best > > > > Olivier Ayache > > > > Le dim. 26 juil. 2020 à 23:16, Alex Cohn a > > écrit : > > > > > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö > wrote: > > > > > > > > Hi, > > > > > > > > Without having too much opinion on the JNI stuff (direct access to > > > > content:// urls might be convenient, but on the other hand, it's not > > > > really something you'd end up with if using the command line tool on > its > > > > own - if you have one of those you most probably have some java code > for > > > > getting it anyway - as far as I remember...) > > > > > > > > > You are more than right, Martin. > > > > > > None of these approaches can work with a command line tool. Worse, > > > running a command line tool in the context of an Android app is > > > becoming trickier with every new release of the platform, and in this > > > case I cannot blame it on poor engineering. This happens because > > > Google tries to tighten the security on Android just as much as > > > possible. > > > > > > There is a nice cross-platform alternative, though. > > > https://github.com/tanersener/mobile-ffmpeg provides Java and > > > Objective-C APIs to run ffmpeg shared library "as if it were an > > > executable": it can receive the input as a string which mimics the > > > ffmpeg (and ffprobe) command line, and the output to stdout and stderr > > > is captured and passed back to the mobile app. In this scenario, it's > > > easy to get a `content:` URI by conventional Android SAF (structured > > > access framework) API in Java and pass it as string or as a derived > > > file descriptor (converted to string) to the command line parser that > > > will eventually call protocol->url_open(). > > > > > > The latest release (Android 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 > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > To unsubscribe, visit link above, or email > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] working with file descriptors on Android
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 implementing https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/IURLProtocolHandler.java I currently maintain a fork which is fully working on Android (work in progress for iOS with Kotlin multiplatform). https://github.com/olivierayache/xuggle-xuggler Best Olivier Ayache Le dim. 26 juil. 2020 à 23:16, Alex Cohn a écrit : > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö wrote: > > > > Hi, > > > > Without having too much opinion on the JNI stuff (direct access to > > content:// urls might be convenient, but on the other hand, it's not > > really something you'd end up with if using the command line tool on its > > own - if you have one of those you most probably have some java code for > > getting it anyway - as far as I remember...) > > > You are more than right, Martin. > > None of these approaches can work with a command line tool. Worse, > running a command line tool in the context of an Android app is > becoming trickier with every new release of the platform, and in this > case I cannot blame it on poor engineering. This happens because > Google tries to tighten the security on Android just as much as > possible. > > There is a nice cross-platform alternative, though. > https://github.com/tanersener/mobile-ffmpeg provides Java and > Objective-C APIs to run ffmpeg shared library "as if it were an > executable": it can receive the input as a string which mimics the > ffmpeg (and ffprobe) command line, and the output to stdout and stderr > is captured and passed back to the mobile app. In this scenario, it's > easy to get a `content:` URI by conventional Android SAF (structured > access framework) API in Java and pass it as string or as a derived > file descriptor (converted to string) to the command line parser that > will eventually call protocol->url_open(). > > The latest release (Android 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 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] libavcodec/flacenc: Possible bug
Thank you for your reply, I am already sending frames with exactly the same number of frames to the encoder. Olivier On Fri, Jul 3, 2020 at 12:47 PM Hendrik Leppkes wrote: > On Fri, Jul 3, 2020 at 11:24 AM Olivier Ayache > wrote: > > > > I am currently working with FLAC encoder and I think I found a bug on pts > > setted on AVPacket. > > In flac_encode_frame function the pts provided is frame's pts, if we > feed > > the encoder with small frames, an encoded packet will be valid after > > several frames and the pts of the first packet won't be 0. > > > > Encoders have a fixed frame size (avctx->frame_size), sending anything > but the correct number of audio samples to an encoder is not using it > correctly - unless it is specifically marked as variable frame size > (AV_CODEC_CAP_VARIABLE_FRAME_SIZE), which flacenc is not. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] libavcodec/flacenc: Possible bug
I am currently working with FLAC encoder and I think I found a bug on pts setted on AVPacket. In flac_encode_frame function the pts provided is frame's pts, if we feed the encoder with small frames, an encoded packet will be valid after several frames and the pts of the first packet won't be 0. avpkt->pts = frame->pts; avpkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples); avpkt->size = out_bytes; s->next_pts = avpkt->pts + avpkt->duration; I think a better code would be avpkt->pts = s->next_pts; avpkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples); avpkt->size = out_bytes; s->next_pts = avpkt->pts + avpkt->duration; I can push a patch if you agree with my analysis. Olivier Ayache ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] add support to Android ndk MediaCodec for encoding/decoding
Thank for your replies I choose the NDK approach in order to be able to be independant from the JVM, to maximize performance and to be sure to detect compatibility issues (using JNI approach can compile and crash at runtime). Concerning the version of Android it is compatible from API 21 (94% of devices) I agree that JNI overhead is not big but in combinaison with Xuggler it seems to me a little weird because Xuggler (Java part) already use JNI to interact with Xuggler (C++) and FFmpeg. If FFmpeg uses JNI in the other way (from c to Java) it seems to me an anti pattern. If you think it is better to begin to use JNI I could transform my encoder and we could discuss about NDK after Olivier Le sam. 27 juin 2020 à 20:55, Martin Storsjö a écrit : > On Sat, 27 Jun 2020, Olivier Ayache wrote: > > > Hi everyone this is the first time I post on this mailing list. I am > > working since several years on a fork of Xuggler for manipulating ffmpeg > > API with Java/Kotlin. > > This work leads me to develop encoder and decoder based on Android NDK > > MediaCodec. > > > > This work can be found on my Github repository > > > > https://github.com/olivierayache/xuggle-xuggler > > > > > > I know that FFmpeg already integrate MediaCodec for decoding via Jni > > wrappers since version 3.1. I began this work on FFmpeg 2.8.x and I > choose > > the NDK in order to achieve optimum performance. > > If you mean you used the NDK MediaCodec API, I'd suggest you use the same > JNI wrappers as ffmpeg has already, for consistency. The overhead of a few > JNI calls per encoded frame is generally negligible. If it, at a later > time, is decided to drop support for older versions at some point, it > should be straightforward to convert it to use the NDK MediaCodec API > instead. > > // Martin > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] add support to Android ndk MediaCodec for encoding/decoding
Hi everyone this is the first time I post on this mailing list. I am working since several years on a fork of Xuggler for manipulating ffmpeg API with Java/Kotlin. This work leads me to develop encoder and decoder based on Android NDK MediaCodec. This work can be found on my Github repository https://github.com/olivierayache/xuggle-xuggler I know that FFmpeg already integrate MediaCodec for decoding via Jni wrappers since version 3.1. I began this work on FFmpeg 2.8.x and I choose the NDK in order to achieve optimum performance. Recently I thank that I could reverse my work on FFmpeg main repository. Could someone give me some advice to do it correctly ? Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
