Re: [FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]
On 2020-08-20 14:03 -0700, Jim DeLaHunt wrote: > On 2020-08-20 09:03, Alexander Strasser wrote: > > > I will bring up a point that has become clear to me. > > > > Good documentation in general and especially for software is > > incredibly hard to write and get right! > > I very much agree: it is incredibly hard. > > An important companion observation: it is valuable. It multiplies the value > of the executable code, because it makes users and other developers able to > get more value from the existing executable code by using it better. I very much agree too. There has probably never been a widely successful software without the critical amount of docs needed. That docs weren't always written in the software projects themselves, but it has always been written AFAICT. So yes, good documentation is very valuable in multiple ways! > > In general you have to be a good writer and have sufficient > > insight into the tech you are documenting. And this means for > > FFmpeg you need to understand C enough, so you can roughly > > read the code and are able to ask the right questions. > > > > You need to have enough multimedia knowledge and experience > > so you can try things yourself and write things in sufficiently > > understood language. > > > True, but also don't underestimate the power of collaboration. A subject > matter expert can empower a writer (or a software developer for that matter) > who is not expert, through suggestion of introductory reading material on > the subject, through explaining the subject, and through reading draft > documentation (or reviewing proposed code changes). Someone who is both > subject matter expert and writer (developer) is a bit of a unicorn, but with > collaboration you don't have to wait for unicorns to appear. > > Also, you need a project which sees documentation as a necessary and > valuable part of the complete product. You need champions who will support > the writers in making their contribution and will review patches. You need > patch-review gatekeepers who will not veto better documentation. You need > general project agreement that better will be different than current, and > that different is OK. Good point. I intended to mention collab initially, but seems I ditched it to keep my reply short. I have occasionally seen this model work for some time, but it's nothing to be taken for granted. Especially in a big distributed open source project environment. > > You need to cope with (gradual and sometimes sweeping) change and > > especially for projects like FFmpeg that means big restructurings > > in the documentation every so often. > > > True, but I believe this is no different than preserving runtime > performance, or memory use, or avoidance of memory leaks, or avoidance of > functionality regressions. Coping boils down to insisting that contributions > need to be more than just code which compiles and runs. They need to have > unit tests, they need to pass functionality and memory tests, they need to > have documentation. And the project needs to track technical debt in > documentation, and be prepared to pay it down from time to time. No disagreement in general. Though trade-offs are always needed. > How does the FFmpeg project cope with these other desirable features? How > well does it work? Mostly good I would say. In short FFmpeg isn't used in such a wide variety of software on different hardware by so many users for such a long time for no reason. Is FFmpeg perfect? No, it isn't for sure. Is FFmpeg's documentation perfect? Surely not. I hope the documentation can be improved for good. There is always tension in a project like FFmpeg and there is no one voice of the project, which is actually not bad thing. The FFmpeg documenation isn't exactly bad, and it has been rather gracefully extended over the years. So help in improving the docs is welcome, just don't expect it to be easy or all proposed changes to be immediately accepted. The FFmpeg project insists very much on review of patches and therefore things may need some arguing and iterations, or sometimes will be dropped. Best regards, Alexander ___ 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] "documented implicitly" part 2 [was: Re: Problem while converting DNG sequnece to video file]
On 2020-08-21 12:28 +0200, Nicolas George wrote: [...] > > They belong in an introduction chapter, with links from places where it > is relevant. If you do it that way, and the contents makes sense, it > will be accepted. I agree on this in principle. We use AVOptions implementation for interpreting this input mostly everywhere. I think for filters and probably everywhere else where AVOptions are used we should add a *linked* type information. Readers can immediately recognize what possible inputs are or if they don't they can quickly follow the link and read it up. [...] Alexander ___ 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] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]
On 2020-08-19 22:14 -0400, Mark Filipak wrote: > On 08/19/2020 01:43 PM, Jim DeLaHunt wrote: > > On 2020-08-19 07:34, Paul B Mahol wrote: > > > You are deeply confused about our filters. > > > Any filter can change pixel formats to one that they accepts thus gbrp > > > is picked instead of packed rgb, this is already documented > > > implicitly. > > > > Wow, "documented implicitly". This is such a classic FFmpeg project > > statement. The role of documentation is to explain, explicitly, at a > > suitable level of detail. What does "documented implicitly" even mean? > > > > I think this thread points out is that FFmpeg documentation is > > inadequate. It is hard to prove a negative, but I suspect that the term > > "pixel format" is not actually defined in the FFmpeg documentation. I > > suspect that the statement, "Any filter can change pixel formats" is not > > stated either. Certainly the maskedmerge filter documentation[1] doesn't > > mention pixel formats at all, much less say what pixel formats the > > filter sets for its output. > > > > I have attempted to improve the documentation, to make it explain > > explicitly instead of fail to document. I encountered a great deal of > > resistance to those patches, because they make the documentation more > > explicit, because they have more words, and because documentation has so > > little value in this project relative to executable code. > > > > And yet "You are deeply confused about our filters". In other words, the > > documentation has failed to explain to you what FFmpeg does, the project > > has failed to write or welcome improved documentation, you do not > > understand how FFmpeg works — and somehow this is your fault. > > > > [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge There are some good points mentioned above. > I have a theory, Jim. I think the developers don't document things (or > comment their code) for 2 reasons: 1, They want to be able to change methods > and behaviors without having to maintain documentation, and 2, They want to > make money doing consulting jobs for people who commit ffmpeg for their > projects, then give up trying to write ffmpeg command lines. This conclusion however is way to unbalanced. I will bring up a point that has become clear to me. Good documentation in general and especially for software is incredibly hard to write and get right! In general you have to be a good writer and have sufficient insight into the tech you are documenting. And this means for FFmpeg you need to understand C enough, so you can roughly read the code and are able to ask the right questions. You need to have enough multimedia knowledge and experience so you can try things yourself and write things in sufficiently understood language. You need to cope with (gradual and sometimes sweeping) change and especially for projects like FFmpeg that means big restructurings in the documentation every so often. Alexander ___ 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] libx265 a lot slower
On 2020-08-19 15:06 +0200, Moritz Barsnick wrote: > On Mon, Aug 17, 2020 at 22:53:12 +0200, Cecil Westerhof wrote: > > Maybe I am just dumb and I use the wrong questions, but when I > > searched I got a lot of hits that explained I needed tot switch > > because the space needed would be halved > > Well, if you're driving a compact, and someone writes "you need to > switch to a Jeep, because it can pull your trailer out of the mud", do > you buy a Jeep? ;-) > > I'm trying to say: Try to understand the benefits and the > disadvantages, and check against your requirements. > > Do you need less space? Are you willing to sacrifice encoding speed? Is > H.265 the right codec for your type of videos? As Mick Finn pointed > out, H.265 is more designed for higher resolutions and bit depths > (IIUC). Can your target players even decode H.265? (Does the Jeep even > fit into your parking spaces? Do your feet reach the pedals?) > > There's no matter of "must", "need to" - just of considerations. I > believe whatever you read, implied some other details, or forgot to > tell about them. > > BTW, if someone does magic hacking, or even more optimized GPUs emerge, > x265/H.265 *may* become "faster" than x264/H.264. It isn't right now. > > > (what is not true, I did see 'only' a 2/3) > > It depends on the material. I'm sure there are tons of comparisons out > there. > > > and a few explained that you could not use h265 > > everywhere, so you should evaluate if it was a good idea to switch. > > Absolutely! Even if I could encode my material to H.265, I probably > wouldn't, except when targetting a very specific player (modern smart > phones?). My PVR/STB, my TV, ..., cannot decode it. Possibly even my PC > doesn't have enough compute/GPU power to decode it in full HD. > > > In none of the hits I saw anything about a performance hit. Especially > > not a hit up to a factor three. > > They should. ;) Maybe also an interesting question to ask (I try to extend the car example): Do the cars available to you master the inclusion of new tech in a way that compares favourably to existing cars? Are you fine with the new feature - cost balance comparing to other cars? Are you willing to accept higher space and fuel usage of the big jeep for its extra features? Or without cars: Is there an encoder available to you that creates significantly smaller same quality output in less space while not taking ages to encode? Of course there are other similar questions to ask and it may depend on your use case. E.g. like Moritz mentioned which devices do you target or what is the enconding situation? (E.g. how much delay/energy usage can you accept?) Alexander ___ 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] Compression is a lot smaller
Hi Cecil! On 2020-08-15 16:25 +0200, Cecil Westerhof wrote: > Simon Roberts writes: > > > On Sat, Aug 15, 2020 at 5:01 AM Cecil Westerhof wrote: > > > >> Through scripts I use ffmpeg for cutting and compressing videos and > >> sometimes adding a watermark. Nothing fancy, but handy. > >> > >> In the past the original file was between 4 to 13 times bigger as the > >> compressed file. Today I compressed a few files again. The compression > >> was almost non existing to less as three. > >> > > > > [...] > > > > > >> > > > > What could be happening here? > > > > > > The most immediate thought is that zoom improved their compression > > algorithm and now there's not so much room left for a secondary > > improvement. > > > > You might want to take a look at the original, perhaps using ffprobe, to > > determine what codec was used, and what bitrate it started out with. > > No, that is not the case. These where videos I shot with my Sony > handycam. So uncompressed files. > But maybe I should have described it a bit clearer. Did I misread your logs? |Input #0, mpegts, from '00039.MTS': | Duration: 00:02:49.02, start: 1.04, bitrate: 22533 kb/s | Program 1 |Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], |+25 fps, 50 tbr, 90k tbn, 50 tbc |Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 256 kb/s |Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090), 1920x1080 |Stream mapping: | Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) The input doesn't look uncompressed to me. [...] Alexander ___ 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] Putting in a picture half-way through the video
On 2020-08-15 16:20 +0200, Cecil Westerhof wrote: > Simon Roberts writes: > > > On Sat, Aug 15, 2020 at 4:07 AM Cecil Westerhof wrote: > > > >> I have to publish the video's from our Zoom meetings. Something went > >> wrong. Halfway a recording the recording went from the speaker to the > >> overview screen. I like to change the part of the video with the > >> overview screen (people do not know they are being recorded and not > >> everything is very flattering) with a static picture. Is this doable? > >> (Without to much work.) > >> > > > > This (and the audio sync issue you describe elsewhere) seems to me to be a > > job far better suited to an actual video editor since you can perform these > > actions interactively. > > > > Lightworks (lwks.com) is extremely powerful, free for output 720 or lower, > > and works on Linux, Mac, and PC. There are many others that are free too > > for the various platforms. > > I really do not like to use file editing tools. Until now I managed > quit sufficiently with scripts that called ffmpeg, but maybe it is > time to bite the bullet. I think if the use case is as simple as it sounds, a video editor is not really needed. If you re-encode the video anyway, there should be multiple easy ways to achieve your goal with filters. If you don't want to re-encode the complete video, than it will require quite a stunt, which potentially can be achieved with ffmpeg, but ffmpeg won't be helping you to achieve it. The risks of errors might be to high to try that. Maybe there are other tools or video editors that support this, but I just don't know. Alexander ___ 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] Last frame with wrong duration - video from images
On 2020-06-22 21:55 +, Leonardo via ffmpeg-user wrote: > >> $ mplayer > >> MPlayer 1.3.0 (Debian), built with gcc-8 (C) 2000-2016 MPlayer Team>>That > >> is too old unfortunately :(>>The timing fix was implemented in SVN > >> revision 37936 and first>released in version 1.4.0 .>> I'd advise to build > >> current development (SVN) version of MPlayer. > I did it. But still didn't help > $ mplayer > MPlayer SVN-r38192-8 (C) 2000-2020 MPlayer Team > I opened the file video.mp4 in OpenShot, and the video has only 5 seconds > (maybe 5.1s because of second image being show very quickly). > So, I thouth it could be a problem with ffmpeg (too old perhaps). OK. This time there seems to be at least a problem with FFmpeg's filtering. It might be, that the specific mplayer fix I mentioned isn't needed here. To find out you would have to test a video generated with the mentioned workaround and test if it plays out correctly with both mplayer versions. Anyway, good you have at least way to create a correct video now. [...] Alexander ___ 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] Last frame with wrong duration - video from images
On 2020-06-22 19:22 +, Leonardo via ffmpeg-user wrote: > $ mplayer > MPlayer 1.3.0 (Debian), built with gcc-8 (C) 2000-2016 MPlayer Team That is too old unfortunately :( The timing fix was implemented in SVN revision 37936 and first released in version 1.4.0 . I'd advise to build current development (SVN) version of MPlayer. If you get into trouble building MPlayer, that would be off-topic for this list. But regarding that you can post on the mplayer-users mailing list to get help. Or ask on #mplayer on freenode IRC. Please don't top-post here. If you don't know what it is, look it up please. Best regards, Alexander > and > $ vlc --version > VLC media player 3.0.11 Vetinari (revision 3.0.11-0-gdc0c5ced72) > > I'm running debian 10 > > > On Monday, June 22, 2020, 4:18:12 PM GMT-3, Alexander Strasser > wrote: > > Hi! > > On 2020-06-22 17:34 +, Leonardo via ffmpeg-user wrote: > > I have two images named figur001.png and figur002.png that I want to make a > > video of 10 seconds, each figure being displayed for 5 seconds. > > > > After command > > > > ffmpeg -framerate 1/5 -i figur%03d.png -c:v libx264 -pix_fmt yuv420p -r 30 > > -vf scale=1920:1080 video.mp4 > > > > It seems that the full duration is 10 seconds because ffmpeg displays this: > > > > Duration: 00:00:10.00, start: 0.00, bitrate: N/A > > > > However, using mplayer or vlc to play the video, the first image is showed > > during 5 seconds (as it should be) but the second image no. > > The second image is displayed by less than a second (0.1s maybe) > > If you test with MPlayer, please make sure you have a recent build. > > I believe the duration of the last frame wasn't respected in old > versions of MPlayer. Sorry, I can't remember the date when it was > added on top of my head. If you post the version output of mplayer, > I will look it up. > > > [...] > > Alexander ___ 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] Last frame with wrong duration - video from images
Hi! On 2020-06-22 17:34 +, Leonardo via ffmpeg-user wrote: > I have two images named figur001.png and figur002.png that I want to make a > video of 10 seconds, each figure being displayed for 5 seconds. > > After command > > ffmpeg -framerate 1/5 -i figur%03d.png -c:v libx264 -pix_fmt yuv420p -r 30 > -vf scale=1920:1080 video.mp4 > > It seems that the full duration is 10 seconds because ffmpeg displays this: > > Duration: 00:00:10.00, start: 0.00, bitrate: N/A > However, using mplayer or vlc to play the video, the first image is showed > during 5 seconds (as it should be) but the second image no. > The second image is displayed by less than a second (0.1s maybe) If you test with MPlayer, please make sure you have a recent build. I believe the duration of the last frame wasn't respected in old versions of MPlayer. Sorry, I can't remember the date when it was added on top of my head. If you post the version output of mplayer, I will look it up. [...] Alexander ___ 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] Is there a bulk mode for ffprobe
Hi Mike! On 2020-01-17 08:59 -0800, Carl Zwanzig wrote: > On 1/17/2020 3:32 AM, Mike Martin wrote: > > Thats what I am doing atm (via perl open3) and I am only getting about 4.7 > > files per second. (30160 in 105 minutes) > > This is what I am passing > > "ffprobe", '-hide_banner', '-loglevel','0','-show_format', > > '-show_streams','-print_format','flat', '-sexagesimal', "$file" > > Any ideas to speed this up > > I think you need to actually time some invocations of ffmpeg and possibly > profile them (to know where the time is going). > > With that many files, are they on local disk or network storage (NFS or > CIFS?)? > Is it memory or processor constrained? > How fast can anything open files on this system? > > Consider rolling up a program or script that simply opens a file, reads the > first couple k bytes, and closes it. See how fast that can open all of those > files. I'll guess it's not much faster than the 4.7/sec. > > (There are also other media analysis tools to try, I often use MediaInfo.) > > And please don't top-post on this mailing list. You might also try parallizing the task by starting multiple ffprobe processes at once. For some first experiments you could prepare a list of files and use xargs: time 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] Change filters in runtime
Hi, On 2019-08-07 15:07 -0300, Music Br wrote: > I need to change an overlay image on the video and resize the video while > running ffmpeg. It is possible? If so, how to proceed? while ffmpeg doesn't support changing the filter graph, the behaviour of some filters can be changed at runtime. If you look at the documentation of the filters some have a section named commands. There are basically 3 ways to send commands when running ffmpeg: 1. interactively (press ? while ffmpeg is running, you should spot the two entries related to sending commands to filters) 2. sendcmd filter 3. zeromq (see documentation of the zmq filter) Number 3 would the best fit for your use case I guess. To be honest I think not enough filters support commands sufficiently to make most use cases possible. From a quick glance the use case you described seems not possible with current ffmpeg. If you can't contribute to ffmpeg development, I fear that filter commands won't work out for you. So looking for another software that supports your use case out of the box (possibly letting you use FFmpeg for the encoding) might be more promising for quick success. No idea in particular though, I don't have such a use case myself and can't recommend any software. Also your description was a bit terse and therefore some of my assumptions may be plain wrong. I'm mostly only answering because I think the feature of sending commands down the filter graph isn't widely known. Alexander ___ 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] [CLT2017] FFmpeg at Chemnitzer Linux-Tage
Hi! FFmpeg has been accepted for CLT 2017, a FOSS event in Chemnitz, Germany! This "Chemnitzer Linux Tage" will take place from 11th to 12th of March. You can find more details here: https://chemnitzer.linux-tage.de/2017/en/ Thus once again, we will man a booth, happily waiting for users and fellow developers to get in touch with us! We would like to encourage everyone visiting CLT to bring sample files and/or command lines that show suspicious or buggy behavior -- see it as chance to get your bug fixed right away! :) See you in Chemnitz! Best regards, Alexander ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] [CLT2015] FFmpeg at Chemnitzer Linux-Tage
We happily announce that FFmpeg will be represented at Chemnitzer Linux-Tage (CLT) in Chemnitz, Germany. The event will take place on 21st and 22nd of March. More information can be found here: https://chemnitzer.linux-tage.de/2015/en/ We demonstrate usage of FFmpeg, answer your questions and listen to your problems and wishes. If you have media files that cannot be processed correctly with FFmpeg, be sure to have a sample with you so we can have a look! For the first time in our CLT history, there will be an FFmpeg workshop: https://chemnitzer.linux-tage.de/2015/de/programm/beitrag/209 The workshop is targeted at FFmpeg beginners. First the basics of multimedia will be covered. Thereafter you will learn how to use that knowledge and the FFmpeg CLI tools to analyse and process media files. The workshop is in German language only and prior registration is necessary. The workshop will be on Saturday starting at 10 o'clock. We are looking forward to meet you (again)! pgposRID1mSn6.pgp Description: PGP signature ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
