Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?
One thing I noticed when comparing x264/x265 to Nvidia counterparts is the Nvidia encoder tended to get rather ugly in the chroma as you leaned towards smaller files a lot sooner than x264/x265 would, and not by a small margin. During tests where I was using VMAF results to compare I could get files from each encoder to have the same VMAF score but the Nvidia file would look much, much worse. Could even contain very nasty macroblocking that nobody would overlook, not even laymen with no video encoder knowledge at all because it was so bad and so obvious, but the x264/x265 file with the same VMAF score would look way better. Then I re-read the VMAF docs again and noticed that it only examined luma, and I was surprised I missed that the first time I had read through. So the Nvidia encoder seemed to be focused on luma quality a lot more than chroma, and the amount of corner-cutting they were doing in the chroma department was glaringly obvious. I think for video game streamers it is a very nice thing to have, an encoder that uses none of their CPU, but for nearly all other uses it is probably going to be better to spend a bit more time doing a CPU encode, as it is possible to get much better results with fewer bits. On Sat, Aug 6, 2022 at 11:11 AM jatmvp ctf wrote: > Thank you all for your responses!!! :) > > Thank you Gabri Shally, and I must say that I was both surprised and > astonished too, about those quality score and size output. > I thought quality goes in pair with size. I got quality 36 (higher is > better, yup?) on libx265 and it looks better when I watch it, and 19 > (lower) hevc_nvenc. The size is smaller when achieving higher quality... > Maybe this depends on many "static" scenes (where only little of picture is > having non-zero spatial differentiation of picture) and the encoding > algorithm indeed! Or CPU capabilities (I have quite decent CPU I think..) > If so, I would then stick and always use the CPU version because of this > 2-4x penalty of encoding time is nothing in comparison of output size and > quality I get :) Good job and kudos for everyone who was involved in > achieving this in ffmpeg code! :) Not only getting great output (metered > for quality and data density), but also while low latency preparation on > decoding is set up. > > It is probably related to some things Clayton Macleod said about encoders > are not standardized as well as decoders are (and as I understood, they do > not have to, so why :) ), the setup of nvidia encoder I not have made maybe > (or not available on Windows platform nowadays - would find ) with > comments from Mick Finn (would read doc, thanks!) & Harald Reindl, and some > issues about which David Stephen wanted to tell, but the response of the > last FFMPEG User I've mentioned is not yet understood by me well I think, > but still David thanks for your input and understood your emotions between > OSS and closed /proprietary one. > > I use the msi manufacturer RTX 3080, supplied from a stable power source > with 3 independent power lane sockets, so should be okey. Should I attach > the version of GPU always here? :) > Sorry for not mentioning it earlier, I read some messages here, but I have > a lot of knowledge to assess :) > > I take your point Clayton Macleod, and thanks for elaboration on this. I > think that was also what Harald Reindl wanted to tell me but I was not > knowing about nVidia encoder goal "in mind". Must rethink and would test + > query if have other ideas/results/benchmarks (maybe helpful for someone) to > share. > > Also, thanks Harald Reindl for sharing your look on my interpretation and > ease on my (not to-the-point) valid assumptions. > Of course, I agree implementation (code) is highly different as for CUDA > cores and the whole GPU ecosystem processing is done differently than on > CPU + RAM + MB, and they are different in architecture, silicon et al. > Would learn more before asking next things. > > btw. I seen many of you run it not with cuda nor dxva2. > Mine available are "Hardware acceleration methods: cuda dxva2 d3d11va" > Is that bad? I cannot find nvenc/nvdec there > > Any sources I should read from begin to end you think? Or some ffmpeg code > source part? > > Really appreciate any further and presented help! :) > > sob., 6 sie 2022 o 13:21 Gabri Shally napisał(a): > > > on both command, you didn't give any option about bitrate or quality > > target, so the implementation may freely choose those. > > > > if you see output near the end, nvidia give quality of 19 while libx265 > > give 36, so the size would be different wildly. > > ___ > > ffmpeg-user mailing list > > ffmpeg-user@ffmpeg.org > > https://
Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?
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". > -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?
David Stephen, you really do not have any idea of what you're talking about. All encoders are not the same. Encoders differ a very large amount. On Sat, Aug 6, 2022 at 2:59 AM david stephen wrote: > dont believe such thing like this more fast than this. what all terms exist > it just marketing. like say implementation h265 from nvidia more fast. > implementation h265 from other company more slow and good size. all > implementation is same. its about default config that set into preset like > CUDA, QuickSync. i already test such thing. what the different one to > other. its about parallel in using resource. like preset CUDA can enable > proc and gpu in same time. while like ffmpeg cant. > > its just about business. new gpu from nvidia will lock such thing. so > ffmpeg will lose to nvidia cause cant optimize nvidia preset. > > Pada tanggal Sab, 6 Agu 2022 pukul 02.02 jatmvp ctf < > justanotherteamm...@gmail.com> menulis: > > > Maybe my question is not correct. If both encode H.265 but I thought the > > performance ability (to create compression ratio) should be the same or > at > > least comparable. > > > > That means CUDA version is only for some purposes and traditional open > > libx265 version for others? I guess, the CUDA is only for streaming, but > > then the decrease size of frames ( so increased compression ratio) to > > produce fast > > > > Harald, could you elaborate about those because I am really excited to > know > > about it. Maybe I have compiled something wrong. I've been looking at it > > from yesterday so maybe I missed something in documentation :) > > > > Best regards. > > > > pt., 5 sie 2022 o 18:38 jatmvp ctf > > napisał(a): > > > > > Different implementation of same standard should not behave way > different > > > I assume, or not have same features or performance (at least). > > > > > > Could you describe a little more or at least give source? > > > > > > What are you suggesting by different implementation exactly then? > > > > > > I guess from your short message that CPU is OK and nVidia's is bad, > > saying > > > - "it is different" but for me it is not metrics when you not give > facts > > > > > > pt., 5 sie 2022 o 17:46 Reindl Harald > > napisał(a): > > > > > >> > > >> > > >> Am 05.08.22 um 17:02 schrieb jatmvp ctf: > > >> > I have problem with understanding why my ffmpeg with nVidia features > > (as > > >> > v:c hevc_nvenc) generate way larger file in comparison to libx265 > > >> > > >> because it's a different implementation > > >> ___ > > >> 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". > > > ___ > 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". > -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] Disparity in VMAF scores
I'm not familiar with that tool, but one thing I have noticed with some 3rd-party VMAF tools is the scores they generate aren't always accurate if the material in question is not 1080p for the standard model, or 4k in the case of the 4k model. So if your source is smaller than 1080p I wouldn't trust the score. The official vmaf.exe has you tell it what the resolution of the source is and the calculations get adjusted accordingly. You can end up with a wildly different score if the resolution isn't taken into account during the score calculation, and some 3rd-party tools seem to get this part wrong somehow and you end up with a score such as you're seeing, somewhere in the 70s, when with the official tool and the proper resolution set it would probably give you something in the 90s. I noticed this when I was testing one day with some 4k stuff, some 1080p stuff, and some 480p stuff with a DVD source. The DVD stuff was returning scores in the 70s even when encoded with x264 and CRF 16 or 17, which seemed very strange to me. So instead I used ffmpeg to dump to yuv and then used vmaf.exe on those files to double check and the scores came back in the upper mid 90s, which made much more sense. Since VMAF determines your viewing distance with a multiple of the file's vertical resolution as one of the factors it is necessary that the calculations be fed the proper information with regard to the file's resolution or the score will be incorrect. I'm not saying your 3rd-party tool in particular is making this mistake for sure, but it is possible and is worth double checking with the official tool just to be sure you're getting sane scores. I've seen some online VMAF guides written by random people that state something like "You should expect lower scores for lower resolution files such as DVD." The actual case is whatever tool they're using to get their scores isn't handling resolution properly and that's why their lower resolution files are resulting in lower scores. On Mon, May 9, 2022 at 10:35 AM Kamaldeep Tumkur wrote: > On Mon, 9 May 2022 at 21:49, Clayton Macleod > wrote: > > > Using the official VMAF.exe is a bit more of a pain since you have to > > convert to yuv first, but being able to examine the results file is > > sometimes helpful. 75 sounds like something may still be off if the files > > don’t appear drastically different to your eye. > > > > -- > > Clayton Macleod > > If no one comes from the future to stop you from doing it, then how bad > of > > a decision can it really be? > > > > > On May 9, 2022, at 1:14 AM, Kamaldeep Tumkur < > kamaldeep.tum...@gmail.com> > > wrote: > > > > > > So my question is, does libvmaf implementation do any kind of > detection > > of > > > audio in the distorted asset before computing a perceptual video > quality > > > score. > > > > > > > > >> On Mon, 9 May 2022 at 13:37, Kamaldeep Tumkur < > > kamaldeep.tum...@gmail.com> > > >> wrote: > > >> > > >> @Clayton, thanks for your response. > > >> > > >> It turned out that the external encoder was adding an audio track to > the > > >> encode. This was throwing the libvmaf scores off. On removing the > audio > > >> track and checking the encode, the score jumped from 25 to 77.64. > > >> > > >> Now there is basis to compare the ffmpeg and the external encode. > > >> > > >> Regards > > >> Kamaldeep > > >> > > >> > > >> > > >> On Sun, 8 May 2022 at 15:37, Kamaldeep Tumkur < > > kamaldeep.tum...@gmail.com> > > >> wrote: > > >> > > >>> Hello, > > >>> > > >>> I'm new to the computation of VMAF scores using libvmaf in ffmpeg. > > While > > >>> trying out generating scores through libvmaf, I have an issue that I > > cannot > > >>> seem to find an explanation for. > > >>> > > >>> I encoded the 'crowd_run' HQ MP4 with two different encoders. The > > >>> resulting files were compared with the same source (original). > > >>> > > >>> VMAF score of ffmpeg encoded clip: > > >>> > > >>> [libvmaf @ 0x7fc5d8f2cb00] VMAF score: 90.644028 > > >>> > > >>> > > >>> Command used: > > >>> > > >>> ffmpeg -i crowd_run_1080p50.mp4 -c:v libx264 -g 100 -keyint_min 100 > > >>> -sc_threshold 0 -b:v 12000k -maxrate 15000k -bufsize 15000k -c:a copy > > -f > > >>> mpegts pass2.ts > > >>> > &
Re: [FFmpeg-user] Disparity in VMAF scores
Using the official VMAF.exe is a bit more of a pain since you have to convert to yuv first, but being able to examine the results file is sometimes helpful. 75 sounds like something may still be off if the files don’t appear drastically different to your eye. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? > On May 9, 2022, at 1:14 AM, Kamaldeep Tumkur > wrote: > > So my question is, does libvmaf implementation do any kind of detection of > audio in the distorted asset before computing a perceptual video quality > score. > > >> On Mon, 9 May 2022 at 13:37, Kamaldeep Tumkur >> wrote: >> >> @Clayton, thanks for your response. >> >> It turned out that the external encoder was adding an audio track to the >> encode. This was throwing the libvmaf scores off. On removing the audio >> track and checking the encode, the score jumped from 25 to 77.64. >> >> Now there is basis to compare the ffmpeg and the external encode. >> >> Regards >> Kamaldeep >> >> >> >> On Sun, 8 May 2022 at 15:37, Kamaldeep Tumkur >> wrote: >> >>> Hello, >>> >>> I'm new to the computation of VMAF scores using libvmaf in ffmpeg. While >>> trying out generating scores through libvmaf, I have an issue that I cannot >>> seem to find an explanation for. >>> >>> I encoded the 'crowd_run' HQ MP4 with two different encoders. The >>> resulting files were compared with the same source (original). >>> >>> VMAF score of ffmpeg encoded clip: >>> >>> [libvmaf @ 0x7fc5d8f2cb00] VMAF score: 90.644028 >>> >>> >>> Command used: >>> >>> ffmpeg -i crowd_run_1080p50.mp4 -c:v libx264 -g 100 -keyint_min 100 >>> -sc_threshold 0 -b:v 12000k -maxrate 15000k -bufsize 15000k -c:a copy -f >>> mpegts pass2.ts >>> >>> >>> VMAF score for externally encoded clip: >>> >>> [libvmaf @ 0x7fc53d729500] VMAF score: 25.168431 >>> >>> >>> >>> I just don't know how to explain this disparity in generated scores when >>> framerates and resolution of the source were retained. The second clip >>> doesn't seem to show such a degradation expected through the score. >>> Attaching both the encoded clips here for analysis. >>> >>> >>> Could anyone point me to why the external encoder generates an output >>> with low VMAF score. Anything in the frame structure? >>> >>> >>> ffmpeg encode: >>> >>> >>> https://drive.google.com/file/d/15-9YyNhYWJoTMxdmESkc7b0mPKKUMqG7/view?usp=sharing >>> >>> >>> external encode: >>> >>> >>> https://drive.google.com/file/d/1Mt2jP51KZ4vTG7SYPnJkCG1uMWqOadid/view?usp=sharing >>> >>> >>> >>> Thank you. >>> >> > ___ > 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] Disparity in VMAF scores
I haven't looked at your files as I don't have the source file you're using. I presume this is some public domain test file, is that right? Anyway, if you use the official vmaf.exe you can output the comparison results to a file to examine what the score was for each frame. Scrolling quickly through those results I suspect you will find that at some point the frames will no longer be in sync with each other and you will begin to see a bunch of frames that have a score of zero. At least that's what I saw in a project of my own when concatenating several files and using ffmpeg to do the mkv muxing. When I started using mkvmerge to do the muxing my issue went away. I also had to eliminate all streams except the video stream to make sure things worked properly. The presence of audio or subtitles would sometimes screw things up. I'm not sure why that is. Something similar may or may not be happening with your .ts files, but I don't know. You can check using ffprobe to see whether or not the total frame counts match, also. Naturally, if the total number of frames differs then something is happening. On Sun, May 8, 2022 at 3:07 AM Kamaldeep Tumkur wrote: > Hello, > > I'm new to the computation of VMAF scores using libvmaf in ffmpeg. While > trying out generating scores through libvmaf, I have an issue that I cannot > seem to find an explanation for. > > I encoded the 'crowd_run' HQ MP4 with two different encoders. The resulting > files were compared with the same source (original). > > VMAF score of ffmpeg encoded clip: > > [libvmaf @ 0x7fc5d8f2cb00] VMAF score: 90.644028 > > > Command used: > > ffmpeg -i crowd_run_1080p50.mp4 -c:v libx264 -g 100 -keyint_min 100 > -sc_threshold 0 -b:v 12000k -maxrate 15000k -bufsize 15000k -c:a copy -f > mpegts pass2.ts > > > VMAF score for externally encoded clip: > > [libvmaf @ 0x7fc53d729500] VMAF score: 25.168431 > > > > I just don't know how to explain this disparity in generated scores when > framerates and resolution of the source were retained. The second clip > doesn't seem to show such a degradation expected through the score. > Attaching both the encoded clips here for analysis. > > > Could anyone point me to why the external encoder generates an output with > low VMAF score. Anything in the frame structure? > > > ffmpeg encode: > > > https://drive.google.com/file/d/15-9YyNhYWJoTMxdmESkc7b0mPKKUMqG7/view?usp=sharing > > > external encode: > > > https://drive.google.com/file/d/1Mt2jP51KZ4vTG7SYPnJkCG1uMWqOadid/view?usp=sharing > > > > Thank you. > ___ > 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". > -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] FFMPEG loudnorm - linear normalization
On Thu, Mar 10, 2022 at 8:17 AM CMG DiGiTaL wrote: > Ok boys each one has its truth and the sum of them, makes us reach > excellence!... but in the end, > we must be faithful to what seems most correct to us. > > Yeah, this place seems kind of strange. Attacking people is ok, but don't you dare top post! Heh. > I understand what Clayton said about the volume on the amplifier, but > imagine the situation of having friends for a party and having to keep > turning > the amplifier volume up and down for each song that is playing!... I want > to be able to enjoy the party without having to worry about it! > I don't think you did understand what I said if this is what you are replying with. You can volume match without turning files up. You simply choose a target that only involves turning loud files down to the same volume as quieter files. Then you use the amplifier to make all the volume-matched songs as loud as you please during playback. My whole library is matched in this way. Anyway, I've already said everything you need to know on the topic. You can get things working exactly as you wish with that knowledge. Whether or not you let it sink in and use that knowledge is up to you. I don't think I'll be participating here any longer. People attacking each other for no reason is ridiculous. Something should be done about that rather than worrying about whether or not someone top posts. Hitting reply in an email client and then replying typically results in a top post. That's how email works, give or take. Forcing people to abandon how most email clients work because it is what you're used to is pathetic. Who the hell still uses mailing lists as a way to discuss things anyways? Forums exist. Heh. Bye. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] FFMPEG loudnorm - linear normalization
On Wed, Mar 9, 2022 at 8:26 PM CMG DiGiTaL wrote: > > OK mark, very nice to hear about your audio experience!...I love it, it > makes me feel free and alive! > > With this internet audio standardization movement, I'm paying more > attention to this type of LUFS standardization > because my commercial jingles have to be platform compliant. I'm also a fan > of compression and, as today everything > has to be very fast, I'm creating a normalization batch so I don't have to > spend unnecessary money on something that > I can try to do myself, testing a lot beforehand of course!...for this > reason I'm trying to understand where the +7.2 Trim > that the plugin finds in the test audio is applied, to try to make the > batch as correct as possible. > Claman, probably the best advice you could receive is some I've already given. Which is, perhaps you should reexamine your choice of target volume. If most or all of your source files require being turned up you are better off using your volume knob on the amplifier. Seriously. There is no better way to adjust the volume than that volume control on the amplifier. That is its sole reason for existing. Perhaps you need a different tool. If you're actually just dealing with music files you should snag foobar2000 and use it for this job instead. It uses the same R128 algorithm. It is made for dealing with music, being a music player. And you can load up your entire library and analyze it all without having to adjust anything. You will be able to see all your required adjustments in the UI before touching your file data. This will let you see all the adjustment data at a glance, better allowing you to determine what a good target value will be for your entire library. A good target value will be one that ensures all your file data will have to be turned down rather than up. For that matter, you can have the player make the adjustments on the fly during playback so you don't even have to alter your file data at all. ffmpeg really isn't the right tool for this job. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] FFMPEG loudnorm - linear normalization
> > > Two decades ago I was heavily involved in a music restoration project of > live concert performances > (with the approval of the band). I used compression extensively. Most > commercial recordings are > compressed, meaning: the peaks are made uniform without clipping, so > volume is made uniform -- I'm > trying hard to not use the word "equalize" here because the word > "equalization" is so misused. > > Try compression. It's what the professionals use. > > That said, I don't know what FFmpeg means by "compression". Is it what > audio engineers mean by > "compression"? I don't know. > Further compressing audio that's already been mastered by a professional mastering engineer is usually unwise. Typically they will have already done many things to make the audio sound as good as they could make it sound, including judicious use of compression, and have a much better trained ear than the average person. They are professional mastering engineers, after all. Throwing even more compression on just to adjust the playback volume doesn't make much sense. Chances are very good that you're only going to make it sound worse. Amplifiers have volume knobs for a reason. I'm not sure why this last statement seems to be ignored. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] FFMPEG loudnorm - linear normalization
On Wed, Mar 9, 2022 at 12:13 PM CMG DiGiTaL wrote: > ok Clayton, > > I understood everything you said... I mentioned the plugin, because I used > it in some audio and it was really satisfactory, > as it is an evaluation product, that is, it will lose its functions in a > few days, I tried to make a batch to being able to use it, > sporadically, in some music that I need to normalize. > > That's why I wanted to know where the plugin applies the gain it generates > when analyzing the music, so that I can improve > my batch file. > > From your experience, the gain that the plugin generates and uses in the > music, which in my batch reaches the maximum > of -15.0 LUFS, is applied where to generate the -10 LUFS that the plugin > can achieve? > I think it is fairly safe to assume that the plugin is using compression to increase the volume further, as that's really all you can do. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] FFMPEG loudnorm - linear normalization
On Wed, Mar 9, 2022 at 3:15 AM CMG DiGiTaL wrote: > is > it compromising the audio to achieve what > I defined as a target? > You cannot increase the volume of a file that is already near/at full scale without compromising it no matter what tool you are using. If adjusted linearly it will introduce clipping in all locations where the data is pushed beyond full scale. In order to avoid clipping you will need to compress/limit it. Clipping and compression both compromise the audio. Usually you want to avoid clipping at all costs. Whether or not compression is an acceptable compromise is up to you. If we were talking about a music library my earlier advice would likely be more desirable, finding out all the required adjustments in advance and then selecting a target that only results in *lowering* the volume so that peaks are left alone and all operations are linear. If we are talking about videos of some kind then compression may not be an issue and may be an acceptable solution. Or movies, perhaps not an issue either. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] FFMPEG loudnorm - linear normalization
On Mon, Mar 7, 2022 at 7:15 PM CMG DiGiTaL wrote: > Input Integrated:*-12.9* LUFS > Input True Peak: *+0.1* dBTP > ... I want (*-10.0* LUFS and *-0.5* True peak) to normalize the file. > Yeah, this is what I suspected. You've got source files that are below your desired target volume, and they're already near/at/beyond the clipping point. This means it is impossible to turn the volume up with a simple linear operation and not have clipping. To meet your -10 target you need to turn that -12.9 source up by 2.9 dB (nearly a 100% increase!) and the source appears to already be clipping, given what the TP value is in this example. The only way to make this louder is to use dynamic compression in the process, and thus your dynamic range will be reduced. That's just part of the deal. You can't compress peaks without reducing dynamic range. Compressing peaks reduces dynamic range by definition. If your goal here is to match volumes so you never have to adjust the volume on your amplifier you'll have to come up with a target volume that is lower so that most/all of your sources will have to be turned down rather than trying to turn some of them up. At least, if you want to avoid having to use dynamic compression in the process. Turning things down a little bit in the file isn't a big deal since you can (presumably) compensate in the playback system by turning the amplifier up. You'll lose less than you will by turning things up in the file and using dynamic compression in the process. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] FFMPEG loudnorm - linear normalization
I haven't looked at this in ffmpeg, but in other audio circles whenever you're talking about normalizing you have to be aware of what needs to be done in order to meet your goals. If you need to turn the volume up and the source is already near clipping, and you need to turn it up such that the audio would then be pushed into clipping, then you cannot turn the volume up without compression to avoid clipping. By definition this would reduce LRA, no? Seems to me that linear normalization would probably usually only be used when you wish to turn the volume down. Typically audio gets mastered so that it is somewhat close to clipping so that you're not wasting dynamic range. And if you've already got a source that's somewhat close to clipping and you're trying to turn the volume up then you have no choice but to resort to compression, which may be undesirable, or simply accept clipping, which is bad. Nobody wants clipping. At least, nobody should want clipping. So, my guess is that you are trying to make things louder than the original source. Unless the source has an unusually low peak you're not going to be able to adjust the volume in a linear fashion, or else the peaks will be chopped off, leaving you with clipping audio. And so, the alternative is a dynamic operation that will preserve peaks at the cost of dynamics. When looking at this from a music library standpoint, if one were trying to match volumes of their entire library, the thing to do would be to analyze the entire library and select a target volume that would only involve an adjustment in the lower direction. That way you'd never alter the peaks of any of the music, and thus never have to worry about changing the dynamics or causing clipping. And once you have a suitable target then you would proceed to analyze and apply the required adjustments to meet that target. You would never adjust it in the higher direction. You'd use the volume knob on your amplifer to turn things up. On Mon, Mar 7, 2022 at 10:32 AM CMG DiGiTaL wrote: > hi, > > About loudnorm normalization: Normalization in Dual-pass mode. > > Rules for normalization to be linear: > > 1 - Values entry: > LUFS_TARGET (user entry) > LRA (get input file - Pass 1 loudnorm) > TP_TARGET (user entry) > THRESH (get input file - Pass 1 loudnorm) > OFFSET (get input file - Pass 1 loudnorm) > > 2 - The destination LRA must NOT BE LESS than the source LRA: > LRA_OUT >= LRA_IN > > 3 - The destination TP must NOT BE GREATER than the target TP: > TP_OUT <= TP_TARGET > > If these conditions are met, normalization will be done in linear mode > and, if there is any divergence, normalization will be done in dynamic > mode. > > These rules are never met... I normalized more than 20 audio files and > in none of them the linear rule was executed, only the dynamic rule! > > In all my FLAC audios, the destination LRA's are always lower than the > source LRA's! > > Has anyone managed to do the normalization in linear mode... what do I > have to do to get linear normalization? > > thanks > Clamarc > ___ > 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". > -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] muxing confusion
On Fri, Mar 4, 2022 at 12:27 AM Clayton Macleod wrote: > > > Well, I think I've solved this on my own. > I take that back. I've now encountered an example where I know for sure my input file is closed GOP and using ffmpeg to split the input file and later merge the output files does not work properly and I get a bad file, and again if I take the same output files and merge them with mkvmerge that output file is good. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] muxing confusion
On Mon, Feb 21, 2022 at 2:40 PM Clayton Macleod wrote: > I've written a batch file to split up a source file into individual files > by GOP. > Well, I think I've solved this on my own. I believe the issue with some of the sources I have been testing with is that things are crumbling when they are open GOP. I've taken some of the failed test subjects and done a lossless encode on them with closed GOP set and things are now working as they should with those previous failures. It only seems to have issues with open GOP files. This makes perfect sense, though I wish I knew of a quick and easy way to determine if a file was open or closed GOP. At first, the thought that it might be a GOP issue didn't even occur to me. At any rate, I'm pretty sure I've got this problem licked, seeing as how a reencode with closed GOP seems to do the trick. Thanks anyway. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] Fwd: Get sample rate in mp3 files
> hi Clayton, That wasn't me. That was Reino. I guess they're strict about formatting rules around here. I just joined yesterday, so don't ask me. Seems a little arbitrary to me, but if those are the rules and that's what they want, alrighty... I forgot to mention, you'll need to change one more thing in your loop. Anywhere you previously referenced %%G in the loop will have to be changed to reference temporary.mp3 instead, since you'll be renaming %%G to temporary.mp3 at the start of the loop. -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] Fwd: Get sample rate in mp3 files
No need to make it any more complicated than need be. You only need to add two lines to the existing FOR loop. The variable %%G contains the current filename throughout the entire time the loop runs. As this is the case, you can simply rename it before you do any of the actual processing in the loop, and then rename it back once you are finished processing it. The variable %%G will still have the current filename assigned to it until the loop goes through the next iteration. Take a random group of 10 mp3 files and copy them into their own directory to do a little test. Make a renametest.cmd batch file that contains this, put it in the test directory with the mp3 files and run it. You'll see that as the loop runs each time it renames a single file to temporary.mp3 and then back again. It will execute a dir command and then pause so you can see what all the filenames currently are at each step. @echo off for %%G in (*.mp3) do ( dir echo About to rename %%G to temporary.mp3. pause ren "%%G" temporary.mp3 dir echo ... echo You should see %%G is now missing from the list, replaced by temporary.mp3. echo About to rename temporary.mp3 back to %%G. pause ren temporary.mp3 "%%G" dir echo You should now see %%G has returned. pause ) And since that works the way it does, you can simply insert this line at the start of your loop: ren "%%G" temporary.mp3 which will rename the current file you're working on. And then before the end of your loop you can insert this line to change the name back to the original one: ren temporary.mp3 "%%G" -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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] Fwd: Get sample rate in mp3 files
quot; %1.txt') do
> > (set
> > > *OT*=%B)
> >
> > You don't seem to be using these variables in the final FFmpeg call, so
> > why extract them?
> >
> > I'd recommend this for a Batch-file:
> >
> > @ECHO off
> > SET vluf=-10.0
> > SET vpeak=-0.0
> > SETLOCAL ENABLEDELAYEDEXPANSION
> > FOR %%A IN (*.mp3) DO (
> > ffmpeg -hide_banner -i "%%A" -af
> > "loudnorm=I=-15:TP=-1.5:LRA=11:print_format=summary" -f null NUL 2>
> > "%%~nA.log"
> > @FOR /F "tokens=3" %%B IN ('FINDSTR /C:"Input Integrated" "%%~nA.log"')
> > DO (SET II=%%B)
> > ECHO !II! is the Input Integrated
> > @FOR /F "tokens=4" %%B IN ('FINDSTR /C:"Input True Peak" "%%~nA.log"')
> > DO (SET ITP=%%B)
> > ECHO !ITP! is the Input True Peak
> > @FOR /F "tokens=3" %%B IN ('FINDSTR /C:"Input LRA" "%%~nA.log"') DO
> (SET
> > ILRA=%%B)
> > ECHO !ILRA! is the Input LRA
> > @FOR /F "tokens=3" %%B IN ('FINDSTR /C:"Input Threshold" "%%~nA.log"')
> > DO (SET IT=%%B)
> > ECHO !IT! is the Input Threshold
> > @FOR /F "tokens=3" %%B IN ('FINDSTR /C:"Target Offset" "%%~nA.log"') DO
> > (SET TO=%%B)
> > ECHO !TO! is the Target Offset
> > FOR /F "delims=" %%B IN ('ffprobe -v 0 -show_entries stream^=bit_rate
> > -of default^=nk^=1:nw^=1 "%%A"') DO ffmpeg -hide_banner -i "%%A" -af
> >
> "loudnorm=linear=true:I=!vluf!:LRA=11:tp=!vpeak!:measured_I=!II!:measured_LRA=!ILRA!:measured_tp=!ITP!:measured_thresh=!IT!:offset=!TO!:print_format=summary"
> > -c:a libmp3lame -b:a %%B "..\Áudios LUFS ORI\%%~nA_LUFS_CONVERTED.mp3"
> > )
> > ENDLOCAL
> >
> > --
> > Reino
> >
> > ___
> > 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".
>
--
Clayton Macleod
If no one comes from the future to stop you from doing it, then how bad of
a decision can it really be?
___
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] muxing confusion
-01-30-git-1530b3f566-full_build-www.gyan.dev Copyright (c) 2007-2022 the FFmpeg developers built with gcc 11.2.0 (Rev7, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 57. 19.100 / 57. 19.100 libavcodec 59. 20.100 / 59. 20.100 libavformat59. 17.101 / 59. 17.101 libavdevice59. 5.100 / 59. 5.100 libavfilter 8. 26.101 / 8. 26.101 libswscale 6. 5.100 / 6. 5.100 libswresample 4. 4.100 / 4. 4.100 libpostproc56. 4.100 / 56. 4.100 Input #0, matroska,webm, from 'finalresult.ffmpeg.VMAF 47.014416 WTF.mkv': Metadata: ENCODER : Lavf59.17.101 Duration: 01:57:31.80, start: 0.00, bitrate: 3243 kb/s Stream #0:0: Video: hevc (Main), yuv420p(tv, smpte170m/smpte170m/bt709, progressive), 720x480 [SAR 32:27 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn Metadata: ENCODER : Lavc59.20.100 libx265 DURATION: 01:57:31.79500 They're showing as different durations for some reason. And I'm not sure why the one that's been merged via ffmpeg doesn't display as much info via ffprobe. All I know is the ffmpeg version seems to start comparing in VMAF ok but at some point during the comparison it just falls off the rails as if the data suddenly has fallen out of step, akin to comparing two completely different video streams after that point. (Phantom frames making their way in somehow? Both VMAF output files list the same number of frames, though, so I guess not.) I've been trying to find something in ffmpeg's command line options that I could change or add, but so far I haven't seen anything obvious to me that I should do. Is there something I should have in this merging command that I'm missing, or am I simply stuck having to manually merge it with the mkvmerge GUI? Thanks. (Yes, I'm aware of av1an. Couldn't get it to do what I'd like under Windows, and I don't feel like setting up linux just for this task in hopes of the linux av1an package behaving better. I'm hitting my VMAF target within 0.1 already, and just hope I can sort out this merging automation issue.) -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be? ___ 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".
