Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/01/2017 02:54 PM, Jorge Ramirez-Ortiz wrote: diff --git a/libavcodec/Makefile b/libavcodec/Makefile index f55bd90..0fbd10a 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -6,6 +6,7 @@ HEADERS = avcodec.h \ avfft.h \ d3d11va.h \ dirac.h \ argh, this is wrong (there is not such a v4l2.h)! it breaks the installwill fix it in v3 (hopefully the last version of the patchset) sorry about it. + v4l2.h\ dv_profile.h \ dxva2.h \ jni.h \ @@ -101,7 +102,8 @@ OBJS-$(CONFIG_LZF) += lzf.o OBJS-$(CONFIG_MDCT)+= mdct_fixed.o mdct_float.o mdct_fixed_32.o OBJS-$(CONFIG_ME_CMP) += me_cmp.o OBJS-$(CONFIG_MEDIACODEC) += mediacodecdec_common.o mediacodec_surface.o mediacodec_wrapper.o mediacodec_sw_buffer.o -OBJS-$(CONFIG_V4L2)+= v4l2-common.o +OBJS-$(CONFIG_V4L2)+= v4l2-fmt.o v4l2-buffers.o +OBJS-$(CONFIG_V4L2_M2M)+= v4l2_m2m.o OBJS-$(CONFIG_MPEG_ER) += mpeg_er.o OBJS-$(CONFIG_MPEGAUDIO) += mpegaudio.o OBJS-$(CONFIG_MPEGAUDIODSP)+= mpegaudiodsp.o\ @@ -320,6 +322,8 @@ OBJS-$(CONFIG_H261_ENCODER)+= h261enc.o h261data.o h261.o OBJS-$(CONFIG_H263_DECODER)+= h263dec.o h263.o ituh263dec.o \ mpeg4video.o mpeg4videodec.o flvdec.o\ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: > From: Alexis Ballier > > This patchset enhances Alexis Ballier's original patch and validates > it using Qualcomm's Venus hardware (driver recently landed upstream > [1]). > > This has been tested on Qualcomm's DragonBoard 410c and 820c > > Tested decoders: >- h264 >- mpeg4 >- vp8 >- vp9 >- hevc > > Tested encoders: >-h264 >-h263 >-mpeg4 > > Tested transcoding (concurrent encoding/decoding) > > Some of the changes introduced: > - v4l2: code cleanup. > - v4l2: follow the decode api. > - v4l2: fix display size for NV12 output pool. > - v4l2: handle EOS. > - v4l2: vp8 and mpeg4 decoding. > - v4l2: hevc and vp9 support. > - v4l2: generate EOF on dequeue errors. > - v4l2: h264_mp4toannexb filtering. > - v4l2: import compat/v4l2 header files. > > [1] https://lwn.net/Articles/697956/ > > Reviewed-by: Jorge Ramirez > Reviewed-by: Alexis Ballier > Tested-by: Jorge Ramirez > --- > Changelog |3 +- > compat/v4l2/v4l2-common.h | 107 ++ > compat/v4l2/v4l2-controls.h | 987 + > compat/v4l2/videodev2.h | 2402 > + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. On a system with a recent enough kernel to run this, you would also have matching headers, so IMHO this should behave like any external library dependency and just check that the headers are recent enough to build our code, and just skip building the module otherwise. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: From: Alexis Ballier This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Tested decoders: - h264 - mpeg4 - vp8 - vp9 - hevc Tested encoders: -h264 -h263 -mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup. - v4l2: follow the decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: import compat/v4l2 header files. [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog |3 +- compat/v4l2/v4l2-common.h | 107 ++ compat/v4l2/v4l2-controls.h | 987 + compat/v4l2/videodev2.h | 2402 + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. Hi Hendrik, but what is wrong with convenience? as a matter of fact, this will not add any 'major' maintenance task. Only when the ffmpeg v4l2 support is modified to add a more recent call (or some new fourcc) these headers will have to be updated accordingly (ie do a copy paste for files that are easily avaialable) IMO, this seems much easier, less error prone - and consistent - than modifying configure every time looking for what needs to be checked before building. On a system with a recent enough kernel to run this, you would also have matching headers, so IMHO this should behave like any external library dependency and just check that the headers are recent enough to build our code, and just skip building the module otherwise. but what if the user is running of vendor trees with some hacked versions of these files in the rootfs? this way at least he'll know exactly what he is building. And if wishes some custom behavior, we are enforcing that he changes the UAPI v4l2 in the ffmpeg _tree_ Seems coherent to me. also notice, that having a recent enough kernel does allows the user to build, will not guarantee that we will be able to run these encoders/decoders (the user will need actual hardware support for that and the v4l2 driver in the kernel) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 02:43 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez wrote: On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: From: Alexis Ballier This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Tested decoders: - h264 - mpeg4 - vp8 - vp9 - hevc Tested encoders: -h264 -h263 -mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup. - v4l2: follow the decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: import compat/v4l2 header files. [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog |3 +- compat/v4l2/v4l2-common.h | 107 ++ compat/v4l2/v4l2-controls.h | 987 + compat/v4l2/videodev2.h | 2402 + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. Hi Hendrik, but what is wrong with convenience? as a matter of fact, this will not add any 'major' maintenance task. Only when the ffmpeg v4l2 support is modified to add a more recent call (or some new fourcc) these headers will have to be updated accordingly (ie do a copy paste for files that are easily avaialable) IMO, this seems much easier, less error prone - and consistent - than modifying configure every time looking for what needs to be checked before building. You could bring that argument for every single external library/API we support, and that is just not something we should be doing. We require headers to be available in the system for practically every other external API/library with only very few exceptions which have extraordinary circumstances beyond "I don't want to maintain configure checks". but that is not a reason I have given - ie not wanting to maintain "configure", that is some interpretation of the conclusion.. (I think you got causation the other way around on this :)) The way I see it maintaining configure for V4L2 API just seems less efficient and more error prone - and more work for everyone with no real gains. Let me try highlighting some benefits IMHO of importing the V4L2 API (also notice that this is the linux kernel API - we are not talking about some HW vendor specs that we want to import through some backdoor, these files are well maintained) 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the future since it will import many other updates. -> You can't say the same about maintaining configure. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. So no, we should not be doing this. could you help me understand why what I am proposing is a no-go on ffmpeg? what are the benefits of 'configure' checking for the kernel API in the build environment? Anyhow, if this set in stone by the maintainers, just let me know and I will just update configure. I hate wasting people's time :) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez wrote: > On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: >> >> On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz >> wrote: >>> >>> From: Alexis Ballier >>> >>> This patchset enhances Alexis Ballier's original patch and validates >>> it using Qualcomm's Venus hardware (driver recently landed upstream >>> [1]). >>> >>> This has been tested on Qualcomm's DragonBoard 410c and 820c >>> >>> Tested decoders: >>> - h264 >>> - mpeg4 >>> - vp8 >>> - vp9 >>> - hevc >>> >>> Tested encoders: >>> -h264 >>> -h263 >>> -mpeg4 >>> >>> Tested transcoding (concurrent encoding/decoding) >>> >>> Some of the changes introduced: >>> - v4l2: code cleanup. >>> - v4l2: follow the decode api. >>> - v4l2: fix display size for NV12 output pool. >>> - v4l2: handle EOS. >>> - v4l2: vp8 and mpeg4 decoding. >>> - v4l2: hevc and vp9 support. >>> - v4l2: generate EOF on dequeue errors. >>> - v4l2: h264_mp4toannexb filtering. >>> - v4l2: import compat/v4l2 header files. >>> >>> [1] https://lwn.net/Articles/697956/ >>> >>> Reviewed-by: Jorge Ramirez >>> Reviewed-by: Alexis Ballier >>> Tested-by: Jorge Ramirez >>> --- >>> Changelog |3 +- >>> compat/v4l2/v4l2-common.h | 107 ++ >>> compat/v4l2/v4l2-controls.h | 987 + >>> compat/v4l2/videodev2.h | 2402 >>> + >> >> As commented on IRC before, I'm not a fan of importing Linux kernel >> headers for the only reason because its convenient to always have >> recent headers available. > > Hi Hendrik, > > but what is wrong with convenience? as a matter of fact, this will not add > any 'major' maintenance task. > Only when the ffmpeg v4l2 support is modified to add a more recent call (or > some new fourcc) these headers will have to be updated accordingly (ie do a > copy paste for files that are easily avaialable) > > IMO, this seems much easier, less error prone - and consistent - than > modifying configure every time looking for what needs to be checked before > building. > (Re-send because I didn't send it to the List by accident) You could bring that argument for every single external library/API we support, and that is just not something we should be doing. We require headers to be available in the system for practically every other external API/library with only very few exceptions which have extraordinary circumstances beyond "I don't want to maintain configure checks". So no, we should not be doing this. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Wed, Aug 2, 2017 at 3:30 PM, Jorge Ramirez wrote: > On 08/02/2017 02:43 PM, Hendrik Leppkes wrote: >> >> On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez >> wrote: >>> >>> On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: > > From: Alexis Ballier > > This patchset enhances Alexis Ballier's original patch and validates > it using Qualcomm's Venus hardware (driver recently landed upstream > [1]). > > This has been tested on Qualcomm's DragonBoard 410c and 820c > > Tested decoders: > - h264 > - mpeg4 > - vp8 > - vp9 > - hevc > > Tested encoders: > -h264 > -h263 > -mpeg4 > > Tested transcoding (concurrent encoding/decoding) > > Some of the changes introduced: > - v4l2: code cleanup. > - v4l2: follow the decode api. > - v4l2: fix display size for NV12 output pool. > - v4l2: handle EOS. > - v4l2: vp8 and mpeg4 decoding. > - v4l2: hevc and vp9 support. > - v4l2: generate EOF on dequeue errors. > - v4l2: h264_mp4toannexb filtering. > - v4l2: import compat/v4l2 header files. > > [1] https://lwn.net/Articles/697956/ > > Reviewed-by: Jorge Ramirez > Reviewed-by: Alexis Ballier > Tested-by: Jorge Ramirez > --- >Changelog |3 +- >compat/v4l2/v4l2-common.h | 107 ++ >compat/v4l2/v4l2-controls.h | 987 + >compat/v4l2/videodev2.h | 2402 > + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. >>> >>> Hi Hendrik, >>> >>> but what is wrong with convenience? as a matter of fact, this will not >>> add >>> any 'major' maintenance task. >>> Only when the ffmpeg v4l2 support is modified to add a more recent call >>> (or >>> some new fourcc) these headers will have to be updated accordingly (ie do >>> a >>> copy paste for files that are easily avaialable) >>> >>> IMO, this seems much easier, less error prone - and consistent - than >>> modifying configure every time looking for what needs to be checked >>> before >>> building. >>> >> You could bring that argument for every single external library/API we >> support, and that is just not something we should be doing. >> We require headers to be available in the system for practically every >> other external API/library with only very few exceptions which have >> extraordinary circumstances beyond "I don't want to maintain configure >> checks". > > > but that is not a reason I have given - ie not wanting to maintain > "configure", that is some interpretation of the conclusion.. (I think you > got causation the other way around on this :)) The way I see it maintaining > configure for V4L2 API just seems less efficient and more error prone - and > more work for everyone with no real gains. > > Let me try highlighting some benefits IMHO of importing the V4L2 API (also > notice that this is the linux kernel API - we are not talking about some HW > vendor specs that we want to import through some backdoor, these files are > well maintained) > > 1. reduction in the frequency of the maintenance tasks. > When they need to be performed (ie new format or fourcc or whatever), the > user will be updating for the future since it will import many other > updates. > -> You can't say the same about maintaining configure. > > 2. the build environment is always sane no matter where you build. > This translates in more extensive testing since it enables building on more > environments. > -> You can't say the same about checking against whatever API was installed > in the build environment (could be 8 years old) > > 3. you can build encoders natively on a 14.04 server running a 3.3 kernel > and execute them on a target running a recent kernel > -> that can't be done the way you propose > > And since the kernel guarantees that will not break userspace, there is zero > risk to the users if we import the V4L2 API just as other projects have > done. > The key argument for me is: What makes V4L2 so special that it warrants doing this, while practically every other library or API on Linux did not propose importing its headers for "conevenience"? I do not see any reason that makes this any more special then any other API we support. All your reasons come down to the same conclusion for me - its just "easier" to not worry about it, which isn't really a reason to copy hundreds of lines of headers into our codebase. You yourself say that these files are well maintained, which is even less reason to import them, since the system is going to have this well-maintained version. All the three points you listed could be named for every other external library a
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 04:34 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 3:30 PM, Jorge Ramirez wrote: On 08/02/2017 02:43 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez wrote: On 08/02/2017 09:33 AM, Hendrik Leppkes wrote: On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz wrote: From: Alexis Ballier This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Tested decoders: - h264 - mpeg4 - vp8 - vp9 - hevc Tested encoders: -h264 -h263 -mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup. - v4l2: follow the decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: import compat/v4l2 header files. [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog |3 +- compat/v4l2/v4l2-common.h | 107 ++ compat/v4l2/v4l2-controls.h | 987 + compat/v4l2/videodev2.h | 2402 + As commented on IRC before, I'm not a fan of importing Linux kernel headers for the only reason because its convenient to always have recent headers available. Hi Hendrik, but what is wrong with convenience? as a matter of fact, this will not add any 'major' maintenance task. Only when the ffmpeg v4l2 support is modified to add a more recent call (or some new fourcc) these headers will have to be updated accordingly (ie do a copy paste for files that are easily avaialable) IMO, this seems much easier, less error prone - and consistent - than modifying configure every time looking for what needs to be checked before building. You could bring that argument for every single external library/API we support, and that is just not something we should be doing. We require headers to be available in the system for practically every other external API/library with only very few exceptions which have extraordinary circumstances beyond "I don't want to maintain configure checks". but that is not a reason I have given - ie not wanting to maintain "configure", that is some interpretation of the conclusion.. (I think you got causation the other way around on this :)) The way I see it maintaining configure for V4L2 API just seems less efficient and more error prone - and more work for everyone with no real gains. Let me try highlighting some benefits IMHO of importing the V4L2 API (also notice that this is the linux kernel API - we are not talking about some HW vendor specs that we want to import through some backdoor, these files are well maintained) 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the future since it will import many other updates. -> You can't say the same about maintaining configure. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. The key argument for me is: What makes V4L2 so special that it warrants doing this, while practically every other library or API on Linux did not propose importing its headers for "conevenience"? I am probably not the best person to discuss why other libraries/codecs are managed the way they are(I lack the background and I would probably be spawning discussions that have been already had); If they use configure I _suppose_ it might be because those "apis" do not risk/benefit from being extended with every single kernel version (I used the word extended intentionally - API open for extension, closed for modification)...so they wont leverage the kernel's development cycle. Really I can only comment on why I think V4L2 should be handled the way I propose. And that is what I tried to justify. I am hoping the maintainers to provide me with a reason for not doing it this way. I do not see any reason that makes this any more special then any other API we support. All your reasons come down to the same conclusion for me - its just "easier" to not worry about it, which isn't rea
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
Le quintidi 15 thermidor, an CCXXV, Jorge Ramirez a écrit : Could at least one of you trim their mail once in a while please? > I am probably not the best person to discuss why other libraries/codecs are > managed the way they are(I lack the background and I would probably be > spawning discussions that have been already had); We could ask it the other way around: do you propose that every single application that wants to use v4l should duplicate its headers? And, for that matter, the headers of all the libraries it uses? > If they use configure I _suppose_ it might be because those "apis" do not > risk/benefit from being extended with every single kernel version (I used > the word extended intentionally - API open for extension, closed for > modification)...so they wont leverage the kernel's development cycle. If the new v4l APIs are so unstable that they break compatibility at every single kernel version, then maybe they are not yet mature enough for programs like FFmpeg. And if they are, we can just use the installed headers. > but sure, all my reasons lead to the same conclusion (isn't that how is > supposed to be in any coherent argument?). Exactly. And since the conclusions are obviously wrong, you can deduce the reasons are invalid. > but sure whatever system will have a well maintained version. > Only thing is, servers will have old copies of the API preventing users from > building (think kernel 3.13?) > > is this what the project wants? Only being able to build in a system that > "might" be able to run? It is better than duplicating the Universe. Regard, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
I am probably not the best person to discuss why other libraries/codecs are managed the way they are(I lack the background and I would probably be spawning discussions that have been already had); We could ask it the other way around: do you propose that every single application that wants to use v4l should duplicate its headers? And, for that matter, the headers of all the libraries it uses? how can I propose that "every single application duplicate headers" without knowing their use cases? that sort of generalization seems silly to me. there is no silver bullet to these kind of problems as you probably know. having said that, all the relevant applications that I know in fact do (ie, GStreamer, and other proprietary ones in the automotive industry) If they use configure I _suppose_ it might be because those "apis" do not risk/benefit from being extended with every single kernel version (I used the word extended intentionally - API open for extension, closed for modification)...so they wont leverage the kernel's development cycle. If the new v4l APIs are so unstable that they break compatibility at every single kernel version, then maybe they are not yet mature enough for programs like FFmpeg. nope, non sequitur. since when open for extension and closed for modification is unstable? is actually the opposite...and exactly the sort of thing I am asking that we take advantage of. And if they are, we can just use the installed headers. but sure, all my reasons lead to the same conclusion (isn't that how is supposed to be in any coherent argument?). Exactly. And since the conclusions are obviously wrong, you can deduce the reasons are invalid. :) why? I am still waiting for some actual reasoning on this matter. but sure whatever system will have a well maintained version. Only thing is, servers will have old copies of the API preventing users from building (think kernel 3.13?) is this what the project wants? Only being able to build in a system that "might" be able to run? It is better than duplicating the Universe. it depends...duplicating the Universe might serve its purpose (you seem to go blindly against duplication...dont you have two lungs?) anyway, if you and other maintainers want to simply use the "authority" card fine by me. lets save time and I will just modify configure (is a 5 minutes job) I just think is wrong and I am a bit surprised we could have no real argument on the matter. but please do confirm and I will amend the commit. Regard, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez wrote: > > I just think is wrong and I am a bit surprised we could have no real > argument on the matter. > I've asked for your arguments on why v4l2 is so special that it warrants special treatment above any other external library/headers, and I have not heard any that would differentiate v4l2 from anything else. If you can provide any, we can discuss those. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 07:40 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez wrote: I just think is wrong and I am a bit surprised we could have no real argument on the matter. I've asked for your arguments on why v4l2 is so special that it warrants special treatment above any other external library/headers, and I have not heard any that would differentiate v4l2 from anything else. If you can provide any, we can discuss those. [paste from previous exchange] 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the _future_ since it will import many other updates. -> You can't say the same about maintaining configure. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. (do you have this guarantee with all the other APIs that you are using?) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 02.08.2017, at 19:53, Jorge Ramirez wrote: > On 08/02/2017 07:40 PM, Hendrik Leppkes wrote: >> On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez >> wrote: >>> I just think is wrong and I am a bit surprised we could have no real >>> argument on the matter. >>> >> I've asked for your arguments on why v4l2 is so special that it >> warrants special treatment above any other external library/headers, >> and I have not heard any that would differentiate v4l2 from anything >> else. >> If you can provide any, we can discuss those. > > [paste from previous exchange] > > 1. reduction in the frequency of the maintenance tasks. > When they need to be performed (ie new format or fourcc or whatever), the > user will be updating for the _future_ since it will import many other > updates. > -> You can't say the same about maintaining configure. Unless you know that the v4l2 headers never, ever, in any circumstance will have bug fixes, it is a HUGE maintenance effort: namely someone must continuously monitor upstream for such fixes and import them. Besides that I thought that importing files was commonly accepted to be a horrible practice. > 2. the build environment is always sane no matter where you build. > This translates in more extensive testing since it enables building on more > environments. > -> You can't say the same about checking against whatever API was installed > in the build environment (could be 8 years old) The flip side is it will be enabled and look to be available on systems where it CANNOT work. > 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and > execute them on a target running a recent kernel > -> that can't be done the way you propose Generally the solution is to have a proper cross-compile setup (or if you are really so lucky that everything else is close enough in versions, by adding an extra include path). > And since the kernel guarantees that will not break userspace, there is zero > risk to the users if we import the V4L2 API just as other projects have done. Only if the header is guaranteed bug-free. > (do you have this guarantee with all the other APIs that you are using?) Every library SHOULD have such guarantee as long as the major version is not being bumped, so in theory it's nothing special (though admittedly in practice most libraries are a lot more careless than kernel). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/02/2017 10:51 PM, Reimar Döffinger wrote: On 02.08.2017, at 19:53, Jorge Ramirez wrote: On 08/02/2017 07:40 PM, Hendrik Leppkes wrote: On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez wrote: I just think is wrong and I am a bit surprised we could have no real argument on the matter. I've asked for your arguments on why v4l2 is so special that it warrants special treatment above any other external library/headers, and I have not heard any that would differentiate v4l2 from anything else. If you can provide any, we can discuss those. [paste from previous exchange] 1. reduction in the frequency of the maintenance tasks. When they need to be performed (ie new format or fourcc or whatever), the user will be updating for the _future_ since it will import many other updates. -> You can't say the same about maintaining configure. Unless you know that the v4l2 headers never, ever, in any circumstance will have bug fixes, it is a HUGE maintenance effort: namely someone must continuously monitor upstream for such fixes and import them. Besides that I thought that importing files was commonly accepted to be a horrible practice. well this is not the case. 2. the build environment is always sane no matter where you build. This translates in more extensive testing since it enables building on more environments. -> You can't say the same about checking against whatever API was installed in the build environment (could be 8 years old) The flip side is it will be enabled and look to be available on systems where it CANNOT work. unfortunately we will _always_ have that with the v4linux codecs. Only at runtime the user will discover if the codecs can be run in their platform 3. you can build encoders natively on a 14.04 server running a 3.3 kernel and execute them on a target running a recent kernel -> that can't be done the way you propose Generally the solution is to have a proper cross-compile setup (or if you are really so lucky that everything else is close enough in versions, by adding an extra include path). sure but why not have it without requiring a cross compiler if we can get it for free... And since the kernel guarantees that will not break userspace, there is zero risk to the users if we import the V4L2 API just as other projects have done. Only if the header is guaranteed bug-free. ok, I feel like I am wasting everyones time (so I must be wrong then when this is so evident to everyone else...I must be getting old :) )...I will simply amend the commit and move on. thanks for you comments btw! (do you have this guarantee with all the other APIs that you are using?) Every library SHOULD have such guarantee as long as the major version is not being bumped, so in theory it's nothing special (though admittedly in practice most libraries are a lot more careless than kernel). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
Le quintidi 15 thermidor, an CCXXV, Jorge Ramirez a écrit : > how can I propose that "every single application duplicate headers" without > knowing their use cases? that sort of generalization seems silly to me. > there is no silver bullet to these kind of problems as you probably know. You said yourself: the same reasons lead to the same conclusions. Since all reasons you have given in this discussion apply equally to all libraries and all applications, therefore the same conclusions should apply too. Since this is completely ridiculous, you have to understand that there is something flawed in your reasoning. > >If the new v4l APIs are so unstable that they break compatibility at > >every single kernel version, then maybe they are not yet mature enough > >for programs like FFmpeg. > nope, non sequitur. Good. > since when open for extension and closed for modification is unstable? Have you noticed that my sentence starts with "if"? You told the condition was not meant, and I assume you know how an if/else clause works, so you know that you should have answered to the next paragraph and not this one: > >And if they are, we can just use the installed headers. Unfortunately, you neglected to answer that. > it depends...duplicating the Universe might serve its purpose Yes, indeed: to shift a little burden from your shoulders into somebody else's, hugely inflating it at the same time as Reimar explained. You will forgive us for not being receptive. > (you seem to > go blindly against duplication...dont you have two lungs?) I hope burning these straw men keeps you warm during these cold summer days. > anyway, if you and other maintainers want to simply use the "authority" card > fine by me. I still hope you can be convinced to understand proper design principles. But if that cannot be achieved,then authority it is. > 1. reduction in the frequency of the maintenance tasks. > When they need to be performed (ie new format or fourcc or whatever), the > user will be updating for the _future_ since it will import many other > updates. > -> You can't say the same about maintaining configure. I can say the same about any other library and any other application using them. You have not proven, as Hendrik requested, that V4L was exceptional. > 2. the build environment is always sane no matter where you build. > This translates in more extensive testing since it enables building on more > environments. > -> You can't say the same about checking against whatever API was installed > in the build environment (could be 8 years old) I can say the same about any other library and any other application using them. You have not proven, as Hendrik requested, that V4L was exceptional. > 3. you can build encoders natively on a 14.04 server running a 3.3 kernel > and execute them on a target running a recent kernel > -> that can't be done the way you propose I can say the same about any other library and any other application using them. You have not proven, as Hendrik requested, that V4L was exceptional. > And since the kernel guarantees that will not break userspace, there is zero > risk to the users if we import the V4L2 API just as other projects have > done. > (do you have this guarantee with all the other APIs that you are using?) Libraries following a disciplined development cycle do guarantee that indeed. Since you have not proven that V4L was special, we will assume it is not and treat it as any other library. configure checks and no headers duplication please. > unfortunately we will _always_ have that with the v4linux codecs. > Only at runtime the user will discover if the codecs can be run in their > platform That can be said of any device: sample rates supported by ALSA devices, resolutions supported by broadcast cards, etc. It is entirely normal. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 08/03/2017 11:22 AM, Nicolas George wrote: I still hope you can be convinced to understand proper design principles. But if that cannot be achieved,then authority it is. if it is ok with you, let's move on. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
