Re: [FFmpeg-user] More Liberal Licensing
Am 28.11.23 um 07:28 schrieb Suminda Sirinath Salpitikorala Dharmasena: - You cannot just borrow some code than using the library thanks god ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
For a project like this, forking into a private or proprietary code base with substantial modifications is not feasible as maintaining it will be difficult and keeping up and modifying upstream changes will be very difficult. Also maintaining a private hard fork will be very costly. > copyleft so everyone actually improves it Being copyleft does not mean everyone improves it though many believe so. Increase in the number of users is what will drive improvements. Usable improvements are generally what gets actually upstreamed. Beyond a certain threshold, keeping private improvements has a larger cost than upstreaming it for large projects and when the modifications become extensive. *GPL means that all forks need to be public, not that the modifications need to be upstreamed. LGPL encourages to use a library as is without modification when used in proprietary code. Encouraging modifications and adaptation even in proriotery context will increase potential contributors who are familiar with the code base. Even if a project they work on is proprietary they can very well become contributors when those working on it in their own time. *GPL reduces local improvements either local, private or public from commential users and also subsequently upstreaming of the changes once the changes become substatial. Once a library project grows beyond a critical mass LGPL hurts the project more than helps. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
On Tue, 28 Nov 2023, at 11:23, Suminda Sirinath Salpitikorala Dharmasena wrote: > changes once the changes become substatial. Once a library project grows > beyond a critical mass LGPL hurts the project more than helps. Let me introduce you to a small project: http://kernel.org/ -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
This is not meant to be used as a library. This is an application. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
In application software fragmentation can hurt. *GPL reduces the risk of fragmentation. This is how the Linux Kernel succeeded. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
This is the reason OpenJDK is successful though at this point of time they are very well at a point they can change the license. GPL nature of the license prevented fragmentation by de-incentivising competing incompatible hard forks. > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
Am 28.11.23 um 11:32 schrieb Suminda Sirinath Salpitikorala Dharmasena: This is the reason OpenJDK is successful though at this point of time they are very well at a point they can change the license. GPL nature of the license prevented fragmentation by de-incentivising competing incompatible hard forks. leave us in peace - a license change won't happen even if it would be possible but it isn't case closed ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
Please unsubscribe. I have sent numerous requests. On Tue, Nov 28, 2023 at 5:34 AM Reindl Harald wrote: > > > Am 28.11.23 um 11:32 schrieb Suminda Sirinath Salpitikorala Dharmasena: > > This is the reason OpenJDK is successful though at this point of time > they > > are very well at a point they can change the license. > > > > GPL nature of the license prevented fragmentation by de-incentivising > > competing incompatible hard forks. > > leave us in peace - a license change won't happen even if it would be > possible but it isn't > > case closed > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
Noted. No worries. Just asked to see if it is a possibility. On Tue, 28 Nov 2023 at 16:04, Reindl Harald wrote: > > > Am 28.11.23 um 11:32 schrieb Suminda Sirinath Salpitikorala Dharmasena: > > This is the reason OpenJDK is successful though at this point of time > they > > are very well at a point they can change the license. > > > > GPL nature of the license prevented fragmentation by de-incentivising > > competing incompatible hard forks. > > leave us in peace - a license change won't happen even if it would be > possible but it isn't > > case closed > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
Am 28.11.23 um 11:35 schrieb David Bernat: Please unsubscribe. I have sent numerous requests. what is your problem? nobody needs another 10 mails within minutes in the style of "This is not meant to be used as a library. This is an application" it's not possible to change the license, it won't happen and both where statet clearly - so no reason to ride the dead horse in another 10 mails On Tue, Nov 28, 2023 at 5:34 AM Reindl Harald wrote: Am 28.11.23 um 11:32 schrieb Suminda Sirinath Salpitikorala Dharmasena: This is the reason OpenJDK is successful though at this point of time they are very well at a point they can change the license. GPL nature of the license prevented fragmentation by de-incentivising competing incompatible hard forks. leave us in peace - a license change won't happen even if it would be possible but it isn't case closed ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
Licensing is not the issue. Show of force required. On Tue, Nov 28, 2023 at 5:41 AM Reindl Harald wrote: > > > Am 28.11.23 um 11:35 schrieb David Bernat: > > Please unsubscribe. I have sent numerous requests. > > what is your problem? > > nobody needs another 10 mails within minutes in the style of "This is > not meant to be used as a library. This is an application" > > it's not possible to change the license, it won't happen and both where > statet clearly - so no reason to ride the dead horse in another 10 mails > > > On Tue, Nov 28, 2023 at 5:34 AM Reindl Harald > > wrote: > > > >> > >> Am 28.11.23 um 11:32 schrieb Suminda Sirinath Salpitikorala Dharmasena: > >>> This is the reason OpenJDK is successful though at this point of time > >> they > >>> are very well at a point they can change the license. > >>> > >>> GPL nature of the license prevented fragmentation by de-incentivising > >>> competing incompatible hard forks. > >> > >> leave us in peace - a license change won't happen even if it would be > >> possible but it isn't > >> > >> case closed > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
As has been stated, it seems vanishingly unlikely there will be a relicense. However, it seems there is a misconception about the GPL here: On Tue, 28 Nov 2023 at 10:24, Suminda Sirinath Salpitikorala Dharmasena wrote: >*GPL means that all forks need to be public, not that the modifications need to > be upstreamed. The GPL does not require "all forks need to be public". A private entity (company, organisation) can use a GPL'd project internally and they never have to release their code. [0] This comes up so frequently it has a FAQ: https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic Of course, if the product is released, users have the right to request a copy of the source to the product. That is of course the point of copyleft- if you build on the freely-available work of other people, others should be able to use your work freely too. Cheers, Rob -- [0]: Note that another option would be calling an ffmpeg binary from a (publically-released) proprietary program, but naturally the source of ffmpeg (including any modifications) would need to be available on request; and if the two programs had sufficient shared state, they may be considered as a single program and so again covered by the GPL. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
As has been said, it would be essentially impossible to track down everyone who's contributed to a project the size of ffmpeg and gain permission of each to alter the licence, so the discussion is effectively moot. Another reason it's moot is that open source is effectively a religion to a lot of people, Stallman is one of its prophets, and the licence he originated is one of its sacred texts. The question being asked here is perhaps a little naïve but that explains the vehemence of the response. Asking people to give up GPL is like pissing on their sainted aunt. The thing that always makes me laugh about this is a piece written years ago for O'Reilly in which it was argued that the GPL is unnecessarily confusing, and the person making that argument had been senior in the Perl community. When Perl people are criticising something for being impenetrable, it's probably time to take note. The thing which makes all this a bit difficult is whether it's possible (or easy) to prove that a given distributed binary is actually compiled from the source code one is offering. I'm not sure that this has ever been tested in court - most of the (L)GPL stuff hasn't, much - but it's not obvious to how someone could prove that if there were ever a dispute. It would be difficult to create a build system which would create a bit-identical binary twice from the same source tree, and other approaches (use of the strings command is often suggested) are obviously far from conclusive and tremendously easy to fake. In the end, most open source licences work because people mostly obey the spirit of them and, I suspect, for no other reason. I suspect many of them are broken constantly and it's okay because nobody's reading the program flash out of most of the world's shipped SoCs and trying to figure out what's in there. P On Tuesday, 28 November 2023 at 11:40:39 GMT, Rob Hallam wrote: As has been stated, it seems vanishingly unlikely there will be a relicense. However, it seems there is a misconception about the GPL here: On Tue, 28 Nov 2023 at 10:24, Suminda Sirinath Salpitikorala Dharmasena wrote: >*GPL means that all forks need to be public, not that the modifications need to > be upstreamed. The GPL does not require "all forks need to be public". A private entity (company, organisation) can use a GPL'd project internally and they never have to release their code. [0] This comes up so frequently it has a FAQ: https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic Of course, if the product is released, users have the right to request a copy of the source to the product. That is of course the point of copyleft- if you build on the freely-available work of other people, others should be able to use your work freely too. Cheers, Rob -- [0]: Note that another option would be calling an ffmpeg binary from a (publically-released) proprietary program, but naturally the source of ffmpeg (including any modifications) would need to be available on request; and if the two programs had sufficient shared state, they may be considered as a single program and so again covered by the GPL. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] does ffmpeg support MVC (3D BluRays)?
On Mon, Nov 27, 2023 at 11:31 PM Philippe Cerfon wrote: > Hey there. > > I couldn't find a definitive answer on this. > Some Wikipedia articles and stackoverflow questions claim ffmpeg would > not support playback of MVC (and thus 3D BluRays). > > IIRC MVC in h264 is not supported. > I don't have a 3D projector or anything the likes yet, but still > wanted to check whether some Videos would actually contain 3D > information. > > So basically I though via ffmpeg's stereo3d filter > (https://trac.ffmpeg.org/wiki/Stereoscopic) I might be able to get the > 3D BluRay into a side-by-side picture, which should then be similar > but of course a bit different. > > However, when doing so the results are not really as I'd expect them: > Each side is only roughly half of the full picture. And the same > happens also when I do it on a BluRay that for sure has no 3D. > stereo3d filter is for anaglyph presentation of decoded 3d frames and some other minor features. supporting alternating, top/bottom, left/right etc. But as usual: - missing ffmpeg version - missing full uncut ffmpeg command line and its output - missing input files > > > I further saw that there are probably some OpenSource MVC decoders: > https://github.com/carrardt/h264-tools > > https://github.com/Britz/FFmpeg (was a master thesis with H.264 MVC > support for ffmpeg) > > > > So should that work already, or could I open a feature request somewhere? > :-) > IIRC H.264 MVC is alternating frames 3d format. > > > Thanks, > Philippe > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
On 11/28/2023 4:09 AM, Phil Rhodes via ffmpeg-user wrote: The thing which makes all this a bit difficult is whether it's possible (or easy) to prove that a given distributed binary is actually compiled from the source code one is offering. I'm not sure that this has ever been tested in court - most of the (L)GPL stuff hasn't, much - but it's not obvious to how someone could prove that if there were ever a dispute. FWIW, BusyBox has taken on some commercial organizations to court and prevailed, search "busybox copyright lawsuit" and you'll get things like https://softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/ https://arstechnica.com/information-technology/2010/08/court-rules-gpl-part-of-a-well-pleaded-case/ (summary judgement) https://www.computerworld.com/article/2537947/open-source-legal-group-strikes-again-on-busybox--suing-verizon.html So whether or not you agree with the current licensing structure, if you want to use ffmpeg components you have to play by those rules. Later, z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] More Liberal Licensing
> So whether or not you agree with the current licensing structure, if you> >want to use ffmpeg components you have to play by those rules. Well, of course, but that's not really my concern: it's more that even if you were playing by the rules, it might actually be quite difficult to prove that. Someone could claim that the source code being distributed was not the source code used to compile the binary in question, and it would be next to impossible to prove otherwise - especially as you'd be trying to persuade a court full of people who are not software engineers and have only the haziest understanding of what code and compiled objects even are. This is not a problem specific to ffmpeg, it's just a piece of software that seems especially likely to be targeted for this sort of thing, given what it does. P ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] drawtext filter missing
Hello, I ran into this problem with the current Debian testing build, so I thought I would try the static build. Both are compiled with --enable-libfreetype but both barf on a drawtext filter. I am attaching the log file from the static build. According to: https://ffmpeg.org/ffmpeg-all.html#drawtext-1 the libfreetype library should be sufficient. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056597 https://trac.ffmpeg.org/ticket/10705#ticket Leo ffmpeg started on 2023-11-28 at 14:38:33 Report written to "ffmpeg-20231128-143833.log" Log level: 48 Command line: ./ffmpeg -y -report -f lavfi -i "testsrc=duration=5.1:size=hd720:rate=10" -f mpegts out.ts ffmpeg version 6.1-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2023 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libfribidi --enable-libass --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat60. 16.100 / 60. 16.100 libavdevice60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc57. 3.100 / 57. 3.100 Splitting the commandline. Reading option '-y' ... matched as option 'y' (overwrite output files) with argument '1'. Reading option '-report' ... matched as option 'report' (generate a report) with argument '1'. Reading option '-f' ... matched as option 'f' (force format) with argument 'lavfi'. Reading option '-i' ... matched as output url with argument 'testsrc=duration=5.1:size=hd720:rate=10'. Reading option '-f' ... matched as option 'f' (force format) with argument 'mpegts'. Reading option 'out.ts' ... matched as output url. Finished splitting the commandline. Parsing a group of options: global . Applying option y (overwrite output files) with argument 1. Applying option report (generate a report) with argument 1. Successfully parsed a group of options. Parsing a group of options: input url testsrc=duration=5.1:size=hd720:rate=10. Applying option f (force format) with argument lavfi. Successfully parsed a group of options. Opening an input file: testsrc=duration=5.1:size=hd720:rate=10. [AVFilterGraph @ 0xdad98c0] Setting 'duration' to value '5.1' [AVFilterGraph @ 0xdad98c0] Setting 'size' to value 'hd720' [AVFilterGraph @ 0xdad98c0] Setting 'rate' to value '10' detected 8 logical cores [Parsed_testsrc_0 @ 0xdada8c0] size:1280x720 rate:10/1 duration:5.10 sar:1/1 [AVFilterGraph @ 0xdad98c0] query_formats: 2 queried, 1 merged, 0 already done, 0 delayed [lavfi @ 0xdad92c0] All info found Input #0, lavfi, from 'testsrc=duration=5.1:size=hd720:rate=10': Duration: N/A, start: 0.00, bitrate: N/A Stream #0:0, 1, 1/10: Video: wrapped_avframe, rgb24, 1280x720 [SAR 1:1 DAR 16:9], 10 fps, 10 tbr, 10 tbn Successfully opened the file. Parsing a group of options: output url out.ts. Applying option f (force format) with argument mpegts. Successfully parsed a group of options. Opening an output file: out.ts. [out#0/mpegts @ 0xdadb700] No explicit maps, mapping streams automatically... [vost#0:0/mpeg2video @ 0xdade600] Created video stream from input stream 0:0 [file @ 0xdae2140] Setting default whitelist 'file,crypto,data' Successfully opened the file. Stream mapping: Stream #0:0 -> #0:0 (wrapped_avframe (native) -> mpeg2video (native)) Press [q] to stop, [?] for help [graph 0 input from stream 0:0 @ 0xdae3400] Setting 'video_size' to value '1280x720' [graph 0 input from stream 0:0 @ 0xdae3400] Setting 'pix_fmt' to value '2' [graph 0 input from stream 0:0 @ 0xdae3400] Setting 'time_base' to value '1/10' [graph 0 input from stream 0:0 @ 0xdae3400] Setting 'pixel_aspect' to value '1/1' [graph 0 input from stream 0:0 @ 0xdae3400] Setting 'frame_rate' to value '10/1' [graph 0 input from stream 0:0 @ 0xdae3400] w:1280 h:720 pixfmt:rgb24 tb:1/10 fr:10/1 sar:1/1 [format @ 0xdae39c0] Setting 'pix_fmts' to value 'yuv420p|yuv422p' [auto_scale
Re: [FFmpeg-user] drawtext filter missing
On Tue, Nov 28, 2023 at 9:40 PM Leo Butler via ffmpeg-user < ffmpeg-user@ffmpeg.org> wrote: > Hello, > > I ran into this problem with the current Debian testing build, so I > thought I would try the static build. Both are compiled with > --enable-libfreetype but both barf on a drawtext filter. I am attaching > the log file from the static build. > > According to: > > https://ffmpeg.org/ffmpeg-all.html#drawtext-1 > > the libfreetype library should be sufficient. > > Citation from that link: To enable compilation of this filter, you need to configure FFmpeg with --enable-libfreetype and --enable-libharfbuzz. To enable default font fallback and the font option you need to configure FFmpeg with --enable-libfontconfig. To enable the text_shaping option, you need to configure FFmpeg with --enable-libfribidi. So your statements are invalid. > See also: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056597 > https://trac.ffmpeg.org/ticket/10705#ticket > > Leo > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] does ffmpeg support MVC (3D BluRays)?
Hey Paul. On Tue, Nov 28, 2023 at 4:51 PM Paul B Mahol wrote: > IIRC MVC in h264 is not supported. What a pity. I've filed https://trac.ffmpeg.org/ticket/10706 in case someone is ever going to work on this. > stereo3d filter is for anaglyph presentation of decoded 3d frames and some > other minor features. > supporting alternating, top/bottom, left/right etc. I'm really new to 3D, so may be completely wrong: but as far as I understood, quite some end devices (e.g. 3D capable projectors or so) expect e.g. side-by-side input, too (i.e. than cannot cope with MVC either). Also, it would have been nice to convert the MVC to a side-by-side version and see whether it actually works. Seems so far, there are only few ways to decode this. Most people apparently use BD3D2MK3D[0], but that's windows only, and as far as I can see not open. > But as usual: Well I guess the following are not really useful, if it anyway doesn't support MVC, but here they are: > - missing ffmpeg version $ ffmpeg -version ffmpeg version 6.1-4 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 13 (Debian 13.2.0-6) configuration: --prefix=/usr --extra-version=4 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librist --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --disable-sndio --enable-libjxl --enable-pocketsphinx --enable-librsvg --enable-libvpl --disable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libsvtav1 --enable-libx264 --enable-libplacebo --enable-librav1e --enable-shared libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat60. 16.100 / 60. 16.100 libavdevice60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc57. 3.100 / 57. 3.100 > - missing full uncut ffmpeg command line and its output I merely tried on some MKV (which was generated from a BluRay): $ ffplay -i a2.mkv -vf stereo3d=sbsr:sbsr and various oher outbuts. But obviously, the MVC stream is not any of the input formats that the filter supports. > - missing input files That might be difficult, I mean these are from BluRays, so the material is a) super big, b) copyrighted. > IIRC H.264 MVC is alternating frames 3d format. As far as I understood it, it's rather that the H264 contains two streams: a "normal" (AVC) one, which I think it s the left eye, and the MVC stream, which is like a diff from the left to the right eye. Thanks, Philippe. [0] https://download.videohelp.com/r0lZ/BD3D2AVS/index.html ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
