Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

Producing objective metrics of the performance of video codecs is notoriously difficult. Or at least it isn't - given enough access, you can calculate a signal-to-noise ratio through the codec, but that sometimes doesn't do a very good job. Wavelet codecs are sort of notorious for producing

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

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

Am 06.08.22 um 20:11 schrieb jatmvp ctf: I thought quality goes in pair with size there *may be* some correlation *but* you have speed/quality/size to assign and can only chose two as you can only have two of cheap/quick/good you need a ton of cpu-usage to squeeze out the last bit of

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

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

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

Am 06.08.22 um 11:25 schrieb david stephen: all implementation is same and from this point on you should be quiet ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

What you have to remember is, things like H.265 and H.265 are standards for DECODING. They're not standards for encoding. Not really. Your encoder can do whatever it likes so long as a decoder that meets the standard can correctly handle the data stream. Encoders can take many different roads,

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

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. ___

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

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

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,

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

> On Aug 6, 2022, at 2:02 AM, jatmvp ctf wrote: > > 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

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

Am 05.08.22 um 18:38 schrieb jatmvp ctf: Different implementation of same standard should not behave way different I assume, or not have same features or performance (at least). says who? H265 has tons of features, optimizations and options as H264 had and in both cases even with the same

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

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

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

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

Re: [FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

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

[FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

Hello, I have problem with understanding why my ffmpeg with nVidia features (as v:c hevc_nvenc) generate way larger file in comparison to libx265. For the case I tried to reencode H.264 video and MP3 to AAC with merging it. video.mp4 is H.264 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from

Re: [FFmpeg-user] Why FFMPEG?

On 2021-08-16T16:15:47+0200, Android PowerUser wrote: > For me, changing apps is quick. If so, you would have practically nothing > to work with. Can you please move this off-topic discussion off-list?! -- Reino ___ ffmpeg-user mailing list

Re: [FFmpeg-user] Why FFMPEG?

Reindl Harald schrieb am Mo., 16. Aug. 2021, 16:07: > > > Am 16.08.21 um 15:58 schrieb Android PowerUser: > > Android PowerUser schrieb am Mo., 16. Aug. 2021, > > 15:56: > > > >> > >> > >> Reindl Harald schrieb am Mo., 16. Aug. 2021, > >> 15:28: > >> > >>> > >>> > >>> Am 16.08.21 um 15:25

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 15:58 schrieb Android PowerUser: Android PowerUser schrieb am Mo., 16. Aug. 2021, 15:56: Reindl Harald schrieb am Mo., 16. Aug. 2021, 15:28: Am 16.08.21 um 15:25 schrieb Android PowerUser: You don't seem to have read the article yet. Better find out more about

Re: [FFmpeg-user] Why FFMPEG?

Android PowerUser schrieb am Mo., 16. Aug. 2021, 15:56: > > > Reindl Harald schrieb am Mo., 16. Aug. 2021, > 15:28: > >> >> >> Am 16.08.21 um 15:25 schrieb Android PowerUser: >> > > You don't seem to have read the article yet. Better find out more about > it before you write about it. Saying

Re: [FFmpeg-user] Why FFMPEG?

Reindl Harald schrieb am Mo., 16. Aug. 2021, 15:28: > > > Am 16.08.21 um 15:25 schrieb Android PowerUser: > > Reindl Harald schrieb am Mo., 16. Aug. 2021, > 15:08: > > > >> > >> > >> Am 16.08.21 um 15:03 schrieb Reindl Harald > >>> how do you imagine having your IDE, mail-lcient, monitorings

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.2021 um 15:28 schrieb Reindl Harald: with you idiotic phone 50% auf my day would be wasted by swiching apps and say "ok, all fine there" can you please continue this discussion off-list Michael ___ ffmpeg-user mailing list

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 15:25 schrieb Android PowerUser: Reindl Harald schrieb am Mo., 16. Aug. 2021, 15:08: Am 16.08.21 um 15:03 schrieb Reindl Harald: child i don't write FRONTEND CRAP - i run the servers, the networks, the backends how do you imagine to maintain a 25 (250k) lines

Re: [FFmpeg-user] Why FFMPEG?

Reindl Harald schrieb am Mo., 16. Aug. 2021, 15:08: > > > Am 16.08.21 um 15:03 schrieb Reindl Harald: > > child i don't write FRONTEND CRAP - i run the servers, the networks, the > > backends > > > > how do you imagine to maintain a 25 (250k) lines codebase on a > > smartphone? > > > > how

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 15:03 schrieb Reindl Harald: child i don't write FRONTEND CRAP - i run the servers, the networks, the backends how do you imagine to maintain a 25 (250k) lines codebase on a smartphone? how do you imagine matain 20 servers at the same time efficient on a smartphone?

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 14:56 schrieb Android PowerUser: Reindl Harald schrieb am Mo., 16. Aug. 2021, 14:26: power-users are working in terminals and the main-usage of a GUI is to have more than one terminal and show the clock For you again the definition of power user:

Re: [FFmpeg-user] Why FFMPEG?

Reindl Harald schrieb am Mo., 16. Aug. 2021, 14:26: > > > > >power-users are working in terminals and the main-usage of a GUI is to > have more than one terminal and show the clock > For you again the definition of power user: https://de.m.wikipedia.org/wiki/Power-User English is apparently not

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 13:22 schrieb Android PowerUser: And that as a Power-User you tend to write more than click with mouse or type on touch displays ... I would probably know that as someone who uses smart devices for an average of 8 hours a day well, how would you given that you are a tap /

Re: [FFmpeg-user] Why FFMPEG?

Reindl Harald schrieb am Mo., 16. Aug. 2021, 09:33: > > > >hopefully i die before i retire because when your generation needs to > pay my rentirement dark days are coming > Perhaps your first social engagement would ever be dying... > ___ ffmpeg-user

Re: [FFmpeg-user] Why FFMPEG?

Reindl Harald schrieb am Mo., 16. Aug. 2021, 09:31: > > >yeah, why ffmpeg on a fucking smartphone - only god knows > So also believe in things that do not exist ... Sure, everyone can believe > what he / she wants, but if you believe in any "beings", you may also > refuse to say that general

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 04:01 schrieb Android PowerUser: Android PowerUser schrieb am Mo., 16. Aug. 2021, 03:54: Ich finde es schade. FFMPEG war für mich super einfach zu benutzen. Einfach ein paar Kommandos die man sogar einfach aus dem netz abschreiben könnte und fertig. Sorry again for the

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 03:54 schrieb Android PowerUser: Carl Zwanzig schrieb am Mo., 16. Aug. 2021, 03:15: (rendering an hour of HD video on a PHONE is just stupid). Yes, that's really annoying when it runs in the background and doesn't bother you ... The question was actually why FFMPEG. Why

Re: [FFmpeg-user] Why FFMPEG?

Android PowerUser schrieb am Mo., 16. Aug. 2021, 03:54: > > Ich finde es schade. FFMPEG war für mich super einfach zu benutzen. > Einfach ein paar Kommandos die man sogar einfach aus dem netz abschreiben > könnte und fertig. > Sorry again for the wrong language. I find it a pity. FFMPEG was

[FFmpeg-user] Why FFMPEG?

Carl Zwanzig schrieb am Mo., 16. Aug. 2021, 03:15: > >(rendering an hour of HD video > on a PHONE is just stupid). > > Yes, that's really annoying when it runs in the background and doesn't bother you ... The question was actually why FFMPEG. Why FFMPEG if I prefer to do it right and I have to

Re: [FFmpeg-user] Why FFMPEG?

On 8/15/2021 5:58 PM, Android PowerUser wrote: And with a PC, I'm tied to one place. I just can't go to the couch. That's why I have a laptop, well, several; and a tablet, and a phone, and two servers- use the right tool for each job (rendering an hour of HD video on a PHONE is just

Re: [FFmpeg-user] Why FFMPEG?

A full backup is always available. I'm not stupid. It would not be a problem if the cell phone broke. Well except that I would need a new one. I don't let the cloud manage my data either. Operation on a computer takes significantly longer. Instead of simply tapping on it, you first have to go

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 01:39 schrieb Android PowerUser: Many have a smartphone and need one, but not everyone has a PC. You can save more money if you give yourself the money instead of for a PC and use your smartphone as a PC right away. Everything on one device is more convenient as there is no

Re: [FFmpeg-user] Why FFMPEG?

Many have a smartphone and need one, but not everyone has a PC. You can save more money if you give yourself the money instead of for a PC and use your smartphone as a PC right away. Everything on one device is more convenient as there is no need to switch or constantly remembering developer

Re: [FFmpeg-user] Why FFMPEG?

On 8/15/2021 4:27 PM, Android PowerUser wrote: I am now trying to use the quoted text. That’s probably at the bottom. As expected with my name, I also write these messages with my smartphone. I write gmail massages on my smartphone (with the email app)- it's not difficult at all to put the

Re: [FFmpeg-user] Why FFMPEG?

I am now trying to use the quoted text. That’s probably at the bottom. As expected with my name, I also write these messages with my smartphone. Ulf Zibis schrieb am Mo., 16. Aug. 2021, 00:57: > > Am 16.08.21 um 00:48 schrieb Android PowerUser: > > Ich muss zugeben die Hardware Anforderungen

Re: [FFmpeg-user] Why FFMPEG?

On 8/15/2021 4:10 PM, Simon Brown wrote: Interesting to know that someone with the surname Zwanzig doesn't speak German. :-) Lots of us don't- our great-grandparents might have. Late,r z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org

Re: [FFmpeg-user] Why FFMPEG?

> > > z! > who doesn't speak German but can occasionally get the meaning (and google > translate does an acceptable job) > > > Interesting to know that someone with the surname Zwanzig doesn't speak German. :-) ___ ffmpeg-user mailing list

Re: [FFmpeg-user] Why FFMPEG?

On 8/15/2021 3:57 PM, Ulf Zibis wrote: Ansonsten wird hier strikt das sogenannte Top-Posting verdammt. Also bevor Du den üblichen Shitstorm kriegst, setzt Deine Antworten besser immer _unter_ den Text, auf den Du antwortest. Also mentioned at

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 00:48 schrieb Android PowerUser: Ich muss zugeben die Hardware Anforderungen sind für Smartphones schnell gestiegen... Ich komm aus einer konservativen Familie. Deshalb habe ich überhaupt erst seit 2015 mobile Geräte. Deswegen ist der Vergleich auch unfair. Ich habe zu wenig

Re: [FFmpeg-user] Why FFMPEG?

I have to admit the hardware requirements for smartphones have increased rapidly ... I come from a conservative family. That's why I've only had mobile devices since 2015. That's why the comparison is unfair. I didn't pay enough attention to the fact that although smartphones are cheaper, their

Re: [FFmpeg-user] Why FFMPEG?

Ich muss zugeben die Hardware Anforderungen sind für Smartphones schnell gestiegen... Ich komm aus einer konservativen Familie. Deshalb habe ich überhaupt erst seit 2015 mobile Geräte. Deswegen ist der Vergleich auch unfair. Ich habe zu wenig beachtet, dass obwohl Smartphones billiger sind, deren

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 00:26 schrieb Android PowerUser: I think if a libaom on the smartphone is not too slow then VVC either. Simply -cpu-used 8 and it's 15 times faster with only a 2% loss of storage efficiency. With 10 times the complexity, one expects 40% more storage efficiency. That without

Re: [FFmpeg-user] Why FFMPEG?

Am 16.08.21 um 00:26 schrieb Android PowerUser: The 2011 PC probably cost more than I've ever spent on smartphones. You will tell us, that you spent less money on smartphones over a period of 10 years than 1 PC? In my experience, the average time of use of smartphones is only 2 - 4 years.

Re: [FFmpeg-user] Why FFMPEG?

I think if a libaom on the smartphone is not too slow then VVC either. Simply -cpu-used 8 and it's 15 times faster with only a 2% loss of storage efficiency. With 10 times the complexity, one expects 40% more storage efficiency. That without cpu-used 8 is like placebo with AVC or HEVC. But with

Re: [FFmpeg-user] Why FFMPEG?

On Sun, 15 Aug 2021, Android PowerUser wrote: The use case is simple: why do we use codecs at all: It's easy, files will simply become incredibly large. Stream would be impossible and send via Whatsapp (16 MB lock). Saving on a low budget device would also not be possible. Then of course

Re: [FFmpeg-user] Why FFMPEG?

On 8/15/2021 1:28 PM, Android PowerUser wrote: I forgot to mention that I am referring to the FFMPEG Android app. A rather large omission; perhaps saying all of that up front would have made quite a different impression. As for platforms, I'd say the vast majority of ffmpeg users are on

Re: [FFmpeg-user] Why FFMPEG?

Am 15.08.21 um 23:01 schrieb Android PowerUser: The use case is simple: why do we use codecs at all: It's easy, files will simply become incredibly large. Stream would be impossible and send via Whatsapp (16 MB lock). Saving on a low budget device would also not be possible. Then of

Re: [FFmpeg-user] Why FFMPEG?

The use case is simple: why do we use codecs at all: It's easy, files will simply become incredibly large. Stream would be impossible and send via Whatsapp (16 MB lock). Saving on a low budget device would also not be possible. Then of course you also want the most memory-efficient. Either

Re: [FFmpeg-user] Why FFMPEG?

Am 15.08.21 um 22:28 schrieb Android PowerUser: I forgot to mention that I am referring to the FFMPEG Android app. Codec2 cannot be used there. On the desktop, of course, yes. Since there is no description of how to integrate this, if that is even possible. And AVC and HEVC can be used

Re: [FFmpeg-user] Why FFMPEG?

I forgot to mention that I am referring to the FFMPEG Android app. Codec2 cannot be used there. On the desktop, of course, yes. Since there is no description of how to integrate this, if that is even possible. And AVC and HEVC can be used natively in FFMPEG in Android and it's super easy. And

Re: [FFmpeg-user] Why FFMPEG?

On Sun, Aug 15, 2021 at 21:28:12 +0200, Android PowerUser wrote: > If FFMPEG is a collection of codecs then why are the most memory efficient > codecs not available. The most memory-efficient waveform encoder xhe-aac, > the most memory-efficient video codec VVC, the most memory-efficient image >

Re: [FFmpeg-user] Why FFMPEG?

Well. since you asked. On 8/15/2021 12:28 PM, Android PowerUser wrote: If FFMPEG is a collection of codecs then why are the most memory efficient codecs not available. Could be than they're not freely available or license-compatible with ffmpeg? (Quite likely, actually.) Or that

[FFmpeg-user] Why FFMPEG?

If FFMPEG is a collection of codecs then why are the most memory efficient codecs not available. The most memory-efficient waveform encoder xhe-aac, the most memory-efficient video codec VVC, the most memory-efficient image codec AVIF (VVC does not seem to offer any image coding options, e.g. via

Re: [FFmpeg-user] why ffmpeg takes lot of cpu?

2017-11-26 22:01 GMT+01:00 Reindl Harald : > > > Am 25.11.2017 um 19:03 schrieb comp4me: >> >> If I will use thread 1 will i get 100% cpu and not 250% cpu? >> but the performance will be the same?(that what i not understand) > > no it will not - the remaining cpu usage is

Re: [FFmpeg-user] why ffmpeg takes lot of cpu?

Am 25.11.2017 um 19:03 schrieb comp4me: If I will use thread 1 will i get 100% cpu and not 250% cpu? but the performance will be the same?(that what i not understand) no it will not - the remaining cpu usage is not just for fun what the hell do you expect from video encoding? "why ffmpeg

Re: [FFmpeg-user] why ffmpeg takes lot of cpu?

El 24/11/2017 a las 09:11, comp4me escribió: I not get you, if i will apply more than 1 thread will i use on less cpu? why? No, he means the opposite. Use 1 thread and you will use less cpu (1 at 100%). ___ ffmpeg-user mailing list

Re: [FFmpeg-user] why ffmpeg takes lot of cpu?

Am 23.11.2017 um 20:21 schrieb comp4me: i run this command on pc with cpu i5 ffmpeg -i rtsp://x.x.x.x -i 2.264 -preset ultrafast -filter_complex "[0]crop=20:20:20:20[a];[a][1] overlay=0:0" http://127.0.0.1/feed.ffm i see how much this process takes me with "top" command(ubuntu) I see that it

Re: [FFmpeg-user] Why FFmpeg provides it's own decoder, but relies on 3rd party encoders?

2016-10-12 0:42 GMT+02:00 Alexey Eromenko : > The important encoders I use myself are libmp3lame, libvpx, libx264, > libx265 and more... > > Except for AAC audio codec, everything else uses 3rd party encoders, Everything? Like mpeg2video, mpeg4 asp, msmpeg4, mp2, ac-3, e-ac-3

Re: [FFmpeg-user] Why FFmpeg provides it's own decoder, but relies on 3rd party encoders?

On 11/10/16 23:42, Alexey Eromenko wrote: The important encoders I use myself are libmp3lame, libvpx, libx264, libx265 and more... Except for AAC audio codec, everything else uses 3rd party encoders, but decoders for ffmpeg are built-in, right ? Why so ? Because encoders improve faster than

[FFmpeg-user] Why FFmpeg provides it's own decoder, but relies on 3rd party encoders?

The important encoders I use myself are libmp3lame, libvpx, libx264, libx265 and more... Except for AAC audio codec, everything else uses 3rd party encoders, but decoders for ffmpeg are built-in, right ? Why so ? Because encoders improve faster than decoders ? Or because encoders are more buggy,

[FFmpeg-user] why ffmpeg reports error when decoding rm or rmvb files

Hi, I'm using the following command to decode some rm and rmvb files, and ffmpeg reports error as shown below: [root@PT-18376 test-clips]# ffmpeg -i hanma.rm -xerror -f null /dev/null ffmpeg version 2.8.3 Copyright (c) 2000-2015 the FFmpeg developers built with icc (ICC) 14.0.2 20140120

[FFmpeg-user] why ffmpeg reports error when decoding rm or rmvb files

Hi, I'm using the following command to decode some rm and rmvb files, and ffmpeg reports error as shown below: [root@PT-18376 test-clips]# ffmpeg -i hanma.rm -xerror -f null /dev/null ffmpeg version 2.8.3 Copyright (c) 2000-2015 the FFmpeg developers built with icc (ICC) 14.0.2 20140120