Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg 4.4

ffmpeg.org

Post reply on HN
Print view View original

51–60 of 135 posts

Re: FFmpeg 4.4

#51

Post by godmode2019 »

imbusy111 wrote: post #42
bhargavauvinox wrote: post #35

Shameless plug: While working with ffmpeg over the years, i always thought that FFmpeg should have a simple to use UI. I have recently started working on a desktop(electron) tool that wraps ffmpeg script in easy to use interface Here is a video showing the tool in action https://www.youtube.com/watch?v=qqqiK6YnJu8 https://auvinox.com

The use cases are so diverse that adding a UI for all use cases is near impossible. I also built a UI for ffmpeg, but mine was geared towards creating and applying video filters - much like Lightroom presets.

Sounds cool is it on github?

Re: FFmpeg 4.4

#52

Post by rpastuszak »

godmode2019 wrote: post #13

I think everyone was a txt file on their computer filled with FFmpeg commands. Care to share yours?

Here's one that generates AppStore previews with correct sizes and metadata. (iTunes Connect can be really picky about this sometimes.)

  # 1. Record your device using QuickTime 
  #  (File->New Movie Recording->Select your phone)
  # 2. Run `$ app-preview your-recording.mov`

  function app-preview() {
      echo "name $1"
      ffmpeg -i $1 -vf scale=1080:1920,setsar=1 -c:a copy "out_$1"
  }

Re: FFmpeg 4.4

#53

Post by adriancr »

traspler wrote: post #31
phh wrote: post #23

Earlier quoted context omitted.

Looking at the comments in that ticket, I can understand why ffmpeg developers don't want to help those people, and the devs probably spoiled more time answering this annoying person than it would take to have fixed the issue, making them lose all motivation to work on that issue.

wow, this is crazy. I would never have imagined this level of a shitshow when you said "annoying"... But what to do with such a person if you can't/won't ban them from posting? Delete his comments? Don't engage until he tires himself out?

you weren't kidding... I'm surprised developers engaged the troll...

This is doubled by the fact that a script was available as workaround...

Also, I see it eventually got some support in spite of discussion so kudos to ffmpeg devs.

Re: FFmpeg 4.4

#54

Post by dncornholio »

traspler wrote: post #31
phh wrote: post #23

Earlier quoted context omitted.

Looking at the comments in that ticket, I can understand why ffmpeg developers don't want to help those people, and the devs probably spoiled more time answering this annoying person than it would take to have fixed the issue, making them lose all motivation to work on that issue.

wow, this is crazy. I would never have imagined this level of a shitshow when you said "annoying"... But what to do with such a person if you can't/won't ban them from posting? Delete his comments? Don't engage until he tires himself out?

> But what to do with such a person if you can't/won't ban them from posting?

How about ignoring details and only focus about the technicality?

Looking at that way too long thread, both sides seem to be blamed on way or another. From what I can see, HDR support missing is actually an issue. Instead of letting him know they accept the bug, they are feeding him with rhetorical questions .

Developers should not worry about this people. They should not take pride in making people happy but take it from knowing millions and millions of people will benefit from your code. No matter how much of an asshole the bug reporter is, a bug / missing feature is just that.

Re: FFmpeg 4.4

#55

Post by Athas »

Wowfunhappy wrote: post #41
MrGilbert wrote: post #10

> Rayman 2 APM muxer > LEGO Racers ALP (.tun & .pcm) muxer Maybe that just shows off my ignorance, but reading the changelogs (current and past), I never realized that ffmpeg contains so many "niche" features.

It’s a lot like how Linux supports the N64, right? If someone wants to write and maintain the code, it can get upstreamed.

But what are the odds that obscure formats like this will be implemented (and maintained) without security holes? I vaguely remember an exploit where the GNOME file viewer would automatically preview samples of any audio file that (I think) gstreamer could recognise, and one of those formats was something like a NES audio format, whose implementation had some buffer overflows in it. Are there similar concerns with ffmpeg?

Re: FFmpeg 4.4

#56

Post by adriancr »

dncornholio wrote: post #54
traspler wrote: post #31

Earlier quoted context omitted.

wow, this is crazy. I would never have imagined this level of a shitshow when you said "annoying"... But what to do with such a person if you can't/won't ban them from posting? Delete his comments? Don't engage until he tires himself out?

> But what to do with such a person if you can't/won't ban them from posting? How about ignoring details and only focus about the technicality? Looking at that way too long thread, both sides seem to be blamed on way or another. From what I can see, HDR support missing is actually an issue. Instead of letting him know they accept the bug, they are feeding him with rhetorical questions . Developers should not worry ab…

It was accepted as bug / missing feature.

Then the OP started complaining... that it's taking too long to fix, that ffmpeg developers are not paying attention to his bug... etc, all while ignoring everything said to him

That person is causing all the pointless animosity.

Re: FFmpeg 4.4

#57

Post by vbezhenar »

Athas wrote: post #55
Wowfunhappy wrote: post #41

Earlier quoted context omitted.

It’s a lot like how Linux supports the N64, right? If someone wants to write and maintain the code, it can get upstreamed.

But what are the odds that obscure formats like this will be implemented (and maintained) without security holes? I vaguely remember an exploit where the GNOME file viewer would automatically preview samples of any audio file that (I think) gstreamer could recognise, and one of those formats was something like a NES audio format, whose implementation had some buffer overflows in it. Are there similar concerns with ff…

You can't expect absence of security holes. ffmpeg is an extremely complex piece of software written with unsafe C and unsafe assembler. It's full of security holes, that's for sure. If that's of concern to you, use additional security measures to mitigate that threat.

Re: FFmpeg 4.4

#58

Post by TomSwirly »

Athas wrote: post #55
Wowfunhappy wrote: post #41

Earlier quoted context omitted.

It’s a lot like how Linux supports the N64, right? If someone wants to write and maintain the code, it can get upstreamed.

But what are the odds that obscure formats like this will be implemented (and maintained) without security holes? I vaguely remember an exploit where the GNOME file viewer would automatically preview samples of any audio file that (I think) gstreamer could recognise, and one of those formats was something like a NES audio format, whose implementation had some buffer overflows in it. Are there similar concerns with ff…

> But what are the odds that obscure formats like this will be implemented (and maintained) without security holes?

Extremely high?

I wrote a stand-alone commercial DSP app which seems to still be sold ten years later. There might be security issues, there probably are since it hasn't been recompiled in years as far as I know, but I'm certain they aren't in the DSP parts.

DSP code involves large blocks of numbers which you translate into other numbers. If you're writing a format or facility within ffmpeg, you aren't directly reading or writing to files, or connecting to the Internet. It's probably that the whole API you write to is just blocks of numbers and some sort of data description.

ffmpeg as a whole might have security violations in it but adding new plug-ins or format won't necessarily increase those chances.

Re: FFmpeg 4.4

#59

Post by TomSwirly »

vbezhenar wrote: post #57
Athas wrote: post #55

Earlier quoted context omitted.

But what are the odds that obscure formats like this will be implemented (and maintained) without security holes? I vaguely remember an exploit where the GNOME file viewer would automatically preview samples of any audio file that (I think) gstreamer could recognise, and one of those formats was something like a NES audio format, whose implementation had some buffer overflows in it. Are there similar concerns with ff…

You can't expect absence of security holes. ffmpeg is an extremely complex piece of software written with unsafe C and unsafe assembler. It's full of security holes, that's for sure. If that's of concern to you, use additional security measures to mitigate that threat.

> It's full of security holes, that's for sure.

You have a funny usage of the word "sure".

Without any review of the code, I personally wouldn't be able to guess how secure it was.

Re: FFmpeg 4.4

#60

Post by j16sdiz »

TomSwirly wrote: post #59
vbezhenar wrote: post #57

Earlier quoted context omitted.

You can't expect absence of security holes. ffmpeg is an extremely complex piece of software written with unsafe C and unsafe assembler. It's full of security holes, that's for sure. If that's of concern to you, use additional security measures to mitigate that threat.

> It's full of security holes, that's for sure. You have a funny usage of the word "sure". Without any review of the code, I personally wouldn't be able to guess how secure it was.

Just look at the CVEs. Most of them come from codecs
Post reply on HN