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

FFmpeg 9.0

github.com

Post reply on HN
Print view View original

81–90 of 107 posts

Re: FFmpeg 9.0

#81

Post by gourlaysama »

ihuman wrote: post #74
gyan wrote: post #2

Changelog: - Extend AMF Color Converter (vf_vpp_amf) HDR capabilities - LCEVC track muxing support in MP4 muxer - Playdate video encoder and muxer - Add v360_vulkan filter - HE-AAC 960 decoding (DAB+) - transpose_cuda filter - Add AMF Frame Rate Converter (vf_frc_amf) filter - SMPTE 2094-50 metadata support and passthrough - ProRes RAW VideoToolbox hwaccel - APV Vulkan hwaccel - Animated WebP decoder - Animated WebP…

> Remove ogg/celt parsing Does that mean it doesn't support .ogg files anymore?

No, this only removes parsing CELT inside an ogg container (because CELT itself is going away), not support for ogg itself.

Re: FFmpeg 9.0

#82

Post by asveikau »

ihuman wrote: post #74
gyan wrote: post #2

Changelog: - Extend AMF Color Converter (vf_vpp_amf) HDR capabilities - LCEVC track muxing support in MP4 muxer - Playdate video encoder and muxer - Add v360_vulkan filter - HE-AAC 960 decoding (DAB+) - transpose_cuda filter - Add AMF Frame Rate Converter (vf_frc_amf) filter - SMPTE 2094-50 metadata support and passthrough - ProRes RAW VideoToolbox hwaccel - APV Vulkan hwaccel - Animated WebP decoder - Animated WebP…

> Remove ogg/celt parsing Does that mean it doesn't support .ogg files anymore?

Doubtful. Ogg is a container format. Celt is a specific audio codec.

I believe celt was superseded by opus.

Re: FFmpeg 9.0

#83

Post by beltsazar »

cm2187 wrote: post #50
richardstahl wrote: post #8

Earlier quoted context omitted.

I recommend watching the Lex Fridman interview with Jean-Baptiste Kempf and Kieran Kunhya. Amazing work on and amazing project.

Though there is one part I didn’t understand in that interview. They were complaining of being overwhelmed by AI submitted bug reports (fair), including for obscure codecs that must have been used by a couple of users at most. And therefore implying that securing those codecs is low priority/important. I don’t understand that. To me the severity has nothing to do with how popular is a code path, but whether that code…

> To me the severity has nothing to do with how popular is a code path, but whether that code path is accessible to an attacker.

That's true for targeted attacks. For untargeted attacks, attackers have little incentive to do the exploit.

Re: FFmpeg 9.0

#84

Post by 129486218 »

world2vec wrote: post #15
sparkling wrote: post #9

Not a Lex Friedman fan, but I highly recommend the recent podcast he did with two leading engineers (and founder) from the ffmpeg project: https://www.youtube.com/watch?v=nepKKz-MzFM In a world full of endless AI slop, it is refreshing to see that there are still folks out there hand-rolling assembler code to squeeze out another 5% efficiency.

They used Claude for this release, as stated yesterday in their twitter page.

I hope they just use it for finding bugs and not for writing code. Is a Twitter announcement compulsory for getting that open source deal?

It's a pity that Claude gets free publicity.

Re: FFmpeg 9.0

#85

Post by ar0b »

cm2187 wrote: post #50
richardstahl wrote: post #8

Earlier quoted context omitted.

I recommend watching the Lex Fridman interview with Jean-Baptiste Kempf and Kieran Kunhya. Amazing work on and amazing project.

Though there is one part I didn’t understand in that interview. They were complaining of being overwhelmed by AI submitted bug reports (fair), including for obscure codecs that must have been used by a couple of users at most. And therefore implying that securing those codecs is low priority/important. I don’t understand that. To me the severity has nothing to do with how popular is a code path, but whether that code…

[dead]

Re: FFmpeg 9.0

#86

Post by ryanmcbride »

hbn wrote: post #75
nvme0n1p1 wrote: post #72

Earlier quoted context omitted.

Wouldn't be impossible. I'm old enough to remember the original B+W game boy, and my B+W e-reader refreshes faster.

I've seen some very recent niche tech demoing fast-refresh e-ink screens but pretty much everything until now has required a noticeable flash to clear the entire screen on update. Which is fine for reading books but not for quick animating in an action game. Most e-ink displays do not refresh faster than the original GameBoy which was 60fps.

Would probably be great for like, text adventures, visual novels, turn based strategy games, etc.

But lcd screens are so cheap I don't even know what the advantage of an e-ink screen would be for this. I was just misremembering what the niche part of the playdate screen was.

Edit: And just to continue the nerdier part of the conversation, the dmg-01's refresh rate was indeed ~60, but it's pixel response time was so bad it really made it feel way slower. I remember when the GBC came out how amazed I was at how clear the games looked. dmg-01 felt like a tiger handheld a lot of the time.

Re: FFmpeg 9.0

#87

Post by dylan604 »

selcuka wrote: post #46
vachina wrote: post #38

Earlier quoted context omitted.

Sounds like getting them hooked on LLM so they come back for more.

No wonder both drug dealers and software developers call their customers "users".

only users lose tokens?

only losers use tokens?

both play just similarly to the original phrases

Re: FFmpeg 9.0

#88

Post by latexr »

ryanmcbride wrote: post #73
hbn wrote: post #68

Earlier quoted context omitted.

Playdate's screen isn't e-ink, it's a 1-bit LCD You probably wouldn't want the refresh rate of e-ink for a gaming device.

You're right. I literally have one sitting on my bookshelf I just haven't touched it like, since about a week after it came out.

What made you give up on it? Lack of time, or did you just not find it fun? “Season 2” of games came out last year.

I’d really like the chance to play with one and maybe even try to develop for it. Unfortunately, the price is a bit steep, even more so when considering shipping and taxes to the EU. I kept checking for years (and still do from time to time) to see if they’d sell through a retailer in the EU or if I could get one second-hand here, but it’s looking like that’ll never happen.

Re: FFmpeg 9.0

#89

Post by Auracle »

latexr wrote: post #88
ryanmcbride wrote: post #73

Earlier quoted context omitted.

You're right. I literally have one sitting on my bookshelf I just haven't touched it like, since about a week after it came out.

What made you give up on it? Lack of time, or did you just not find it fun? “Season 2” of games came out last year. I’d really like the chance to play with one and maybe even try to develop for it. Unfortunately, the price is a bit steep, even more so when considering shipping and taxes to the EU. I kept checking for years (and still do from time to time) to see if they’d sell through a retailer in the EU or if I cou…

Not who you responded to but I haven’t really found many games I actually enjoy.

Re: FFmpeg 9.0

#90

Post by dylan604 »

hereonout2 wrote: post #48
ape4 wrote: post #47

Naive question... would it be possible to make a language that describes multimedia formats that could then be automatically converted into code.

Should take a look at some of the ISO specs for various MPEG standards for example. The container formats are defined in a way that could potentially make this possible.

Using good ol' ISO specs (or written specs in general) is such a fun game to play. What the spec says and what hardware/software actually do are not always the same. I worked on a project for a TV manufacturer that provided us the specs for what their chips in their new TV could do. Naturally, we pushed the encoding to the limits of the specs at first, and then had to start dialing things back to what was actually happening. If the spec says max bitrate of Xmpbs, it turns out that it was closer to .85Xmpbs to get decent playback. Or a cable provider's new digital STB that couldn't handle large changes in VBV even thought it was "within spec"
Post reply on HN