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

FFmpeg merges WebRTC support

git.ffmpeg.org

Post reply on HN
Print view View original

31–40 of 204 posts

Re: FFmpeg merges WebRTC support

#31

Post by rvz »

MrThoughtful wrote: post #4

I know there are JavaScript ports of FFmpeg and I would love to use them. But so far, I never got it working. I tried it with AI and this prompt: Make a simple example of speeding up an mp4 video in the browser using a version of ffmpeg that runs in the browser. Don't use any server side tech like node. Make it a single html file. But so far every LLM I tried failed to come up with a working solution.

> But so far every LLM I tried failed to come up with a working solution.

Maybe you need to actually learn how it works instead of deferring to LLMs that have no understanding of what you are specifically requesting.

Just read the fine documentation.

Re: FFmpeg merges WebRTC support

#32

Post by kairosisme »

jsheard wrote: post #19
tyre wrote: post #3

Interesting I keep getting blocked by the bot detection on iOS safari, both from our work WiFi and cellular data. Anubis let me go

Are you getting the "access denied" page, or an infinite challenge loop?

FWIW I also can’t pass the Anubis pass on iOS Safari, even though I can on any other site. I see the Anubis success screen for a moment before it switches to the “invalid response” screen.

edit: Trying again a few minutes later worked

Re: FFmpeg merges WebRTC support

#33

Post by Sean-Der »

qwertox wrote: post #30
bigfishrunning wrote: post #5

Earlier quoted context omitted.

It means that programs that use the FFmpeg libraries (looks like libavformat specifically) can consume webrtc streams

So it's only the receiving part of WebRTC, now being able to use WHIP in order to ask a server for a stream?

Currently only the sending part!

WHIP is 'pushing media via WebRTC' - https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html

WHEP is 'pulling media via WebRTC' - https://github.com/wish-wg/webrtc-http-egress-protocol/blob/...

WHEP isn't standardized/still changing a bit. After it lands I will try and get it into OBS/FFmpeg (and more)

Re: FFmpeg merges WebRTC support

#34

Post by mort96 »

MrThoughtful wrote: post #4

I know there are JavaScript ports of FFmpeg and I would love to use them. But so far, I never got it working. I tried it with AI and this prompt: Make a simple example of speeding up an mp4 video in the browser using a version of ffmpeg that runs in the browser. Don't use any server side tech like node. Make it a single html file. But so far every LLM I tried failed to come up with a working solution.

You know there's ... documentation, right?

Re: FFmpeg merges WebRTC support

#35

Post by rafram »

kairosisme wrote: post #32
jsheard wrote: post #19

Earlier quoted context omitted.

Are you getting the "access denied" page, or an infinite challenge loop?

FWIW I also can’t pass the Anubis pass on iOS Safari, even though I can on any other site. I see the Anubis success screen for a moment before it switches to the “invalid response” screen. edit: Trying again a few minutes later worked

[flagged]

Re: FFmpeg merges WebRTC support

#37

Post by maxmcd »

Sean-Der wrote: post #20

I am so incredibly excited for WebRTC broadcasting. I wrote up some reasons in the Broadcast Box[0] README and the OBS PR [1] Now that GStreamer, OBS and FFmpeg all have WHIP support we finally have a ubiquitous protocol for video broadcasting for all platforms (Mobile, Web, Embedded, Broadcasting Software etc...) I have been working on Open Source + WebRTC Broadcasting for years now. This is a huge milestone :) [0]…

Thanks for all your work Sean! It's been a delight to use your webrtc libs and see your impact across a broad range of technical efforts.

Re: FFmpeg merges WebRTC support

#38

Post by gruez »

globie wrote: post #29
Sean-Der wrote: post #23

Earlier quoted context omitted.

What security flaws? This implementation is very small. I feel 100% confident we are giving users the best thing possible.

I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right. Of course, you're right that this implementation is very small. It's very different than a typical client implementation, I don't share the same concerns. It's also only the WHIP po…

>I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right.

Like what? I did a quick search and most seem to be stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg.

Re: FFmpeg merges WebRTC support

#39

Post by mschuster91 »

autoexec wrote: post #11

Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. WebRTC security flaws are responsible for a lot of compromises. It's one of the first things I disable after installing a browser

> Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems.

ffmpeg has had so many issues in the past [1], it's best practice anyway to keep it well contained when dealing with user input. Create a docker image with nothing but ffmpeg and its dependencies installed and do a "docker run" for every transcode job you got. Or maybe add ClamAV, OpenOffice and ImageMagick in the image as well if you also need to deal with creating thumbnails of images and document.

And personally, I'd go a step further and keep the servers that deal with user-generated files in more than accepting and serving them in their own, heavily locked down VLAN (or Security Group if you're on AWS).

That's not a dumbass criticism of any of these projects mentioned by the way. Security is hard, especially when dealing with binary formats that have inherited a lot of sometimes questionably reverse engineered garbage. It's wise to recognize this before getting fucked over like 4chan was.

[1] https://ffmpeg.org/security.html

Re: FFmpeg merges WebRTC support

#40

Post by vel0city »

Matheus28 wrote: post #27
MrThoughtful wrote: post #22

Earlier quoted context omitted.

The problem is that they don't provide the full code that can run in the browser. I have not managed to get the function they show in the first example to run in the browser.

You don’t need an LLM to do that. The code in there is almost complete…

Listen buddy, I need an LLM to tie my shoes, don't be so judgemental.
Post reply on HN