Live data from Hacker News

FFmpeg to WebRTC

github.com

41–50 of 50 posts

Re: FFmpeg to WebRTC

#41
post #34
post #23

[help request] I created a commercial product Video Hub App and have been trying for a year to get streaming a video from a PC to an iPhone working (through a PWA, not a dedicated iOS app) and have had 0 success. I could get the video stream to play on a separate laptop through Chrome, but iOS Safari kicks my ass. Does anyone have suggestions / ideas? https://github.com/whyboris/Video-Hub-App https://github.com/whybo…

What's this? You have a server component in the PC, with access to local videos, then you want to play those videos back remotely on the iPhone?

Correct! I've even tried transcoding via FFmpeg - successful video playback on PC over WiFi but not on iPhone - https://github.com/whyboris/Video-Hub-App/pull/611

Re: FFmpeg to WebRTC

#42

I personally use this project to proxy IP camera RTSP stream via Web Sockets as fragmented MP4 - https://github.com/deepch/RTSPtoWSMP4f I'm not affiliated with the project, it's just really performant and reliable.

[deleted]

Re: FFmpeg to WebRTC

#43

Earlier quoted context omitted.

Would you mind sharing the paid packages you use?

Wowza. We put an open source nginx cache layer in front, and cloudfront in front of that. It’s a pretty cool setup, but I feel I could do most of the HLS in nginx+ffmpeg.

I am also exploring the webrtc(ingest)-to-llhls. FFMPEG doesn't seem to support llhls now, as it requires web server intelligence. For the webrtc, mediasoup is nice being node based.

Re: FFmpeg to WebRTC

#44
post #23

[help request] I created a commercial product Video Hub App and have been trying for a year to get streaming a video from a PC to an iPhone working (through a PWA, not a dedicated iOS app) and have had 0 success. I could get the video stream to play on a separate laptop through Chrome, but iOS Safari kicks my ass. Does anyone have suggestions / ideas? https://github.com/whyboris/Video-Hub-App https://github.com/whybo…

Easy thing: iOs on iPhone does not support MediaFileExtensions, so you can't use tag with dynamic source. You can however go the way described in the post: instead of requesting data though the data channel, you can initiate video/audio channels and make your streaming work pretty much like google hangouts, having your streamer as a participant. It is not the recommended way though. But no other way for iOs anyways.

I don't understand, why not use webrtc or hls, on iOS Safari?

Re: FFmpeg to WebRTC

#46
post #40
post #35

My all time question about FFmpeg is what are all those timestamp correction flags and synchronization options for: * -fflags +genpts, +igndts, +ignidx * -vsync * -copyts * -use_wallclock_as_timestamps 1 * And more that you find even when you thought you had seen all flags that might be related. FFmpeg docs are a strange beast, they cover a lot of topics, but are extremely shallow in most of them, so the overall qual…

Think of ffmpeg as a universal translator. There are 100s of languages in use around the world, with their own syntax, vocabulary, writing system, formal and informal conventions ..etc. A universal translator framework cannot provide a bespoke translation engine for all possible permutations of source and target language. Instead it provides a common engine which is meant to be suitable enough for the most common tra…

Thank you; I understand what you mean with the translator metaphor. The project still needs to pick some very common usage scenarios and discuss them in depth (kind of "let's pick English and Spanish, two very commonly used languages, and talk about all quirks and translation techniques", in your own example).

You already provided better lines for some of the options than what their docs state, although I'd still miss a small commentary about some example instances where some of them would be useful.

For example: "igndts will unset dts if packet's pts is set"... OK but why would anyone want to do that? DTS is for Decoding, PTS is for Presentation, so wouldn't mixing them cause presentation issues?

As mentioned I'm interested in storing UDP RTP as-is, and for that I'm using "-fflags +genpts+igndts -use_wallclock_as_timestamps 1" because intuitively it makes sense to me that potentially broken incoming timestamps should be ignored and new ones written from scratch, but now that you mention it, maybe "+genpts" is doing nothing in this scenario?

Re: FFmpeg to WebRTC

#47
post #41
post #34

Earlier quoted context omitted.

What's this? You have a server component in the PC, with access to local videos, then you want to play those videos back remotely on the iPhone?

Correct! I've even tried transcoding via FFmpeg - successful video playback on PC over WiFi but not on iPhone - https://github.com/whyboris/Video-Hub-App/pull/611

Yes, if your mobile app is a PWA, you would definitely need to transcode most videos. I'm not sure of how you did that so far, but in my experience, all web browsers support some specific codecs, and nothing else. Same for container formats. For example I haven't been able to open a Matroska (MKV) video with either Firefox or Chrome. And if those browsers have their limitations, I can only assume iOS Safari is even more strict with what it can consume!

I think your idea was the safest one: transcode the file in the main PC, then send it out to a tag in the phone; I'm surprised that didn't work. What protocol is the transfer done with? Maybe iOS Safari doesn't support it, or if it's plain and simple HTTP, it might silently fail if the source is not HTTPS with a proper certificate.

You could try WebRTC. Safari supports it, and it's well tested at this point. It's more complex, having to send SDP messages back and forth, and having to care about browser limitations (e.g. videos cannot autoplay if they have audio, things like that). If you decide to go that route, this project might be just what you needed for this task ;-)

Re: FFmpeg to WebRTC

#48
post #46
post #40

Earlier quoted context omitted.

Think of ffmpeg as a universal translator. There are 100s of languages in use around the world, with their own syntax, vocabulary, writing system, formal and informal conventions ..etc. A universal translator framework cannot provide a bespoke translation engine for all possible permutations of source and target language. Instead it provides a common engine which is meant to be suitable enough for the most common tra…

Thank you; I understand what you mean with the translator metaphor. The project still needs to pick some very common usage scenarios and discuss them in depth (kind of "let's pick English and Spanish, two very commonly used languages, and talk about all quirks and translation techniques", in your own example). You already provided better lines for some of the options than what their docs state, although I'd still mis…

> You already provided better lines for some of the options than what their docs state

I wrote the docs section you refer to :)

They are meant to be narrow and to the point, not didactic, not least because the codepath leading up to an option and following that option depend on internal evaluations and other options.

> why would anyone want to do that?

Because the input has weird or unreliable DTS. One would have to check code history to see why an option was initially added. Many of ffmpeg options are there to deal with edge cases or weird inputs.

> -fflags +genpts+igndts -use_wallclock_as_timestamps 1

In theory, igndts is unsetting wallclock dts set by the last option. genpts should have no effect, again due to the third option.

Re: FFmpeg to WebRTC

#49
post #48
post #46

Earlier quoted context omitted.

Thank you; I understand what you mean with the translator metaphor. The project still needs to pick some very common usage scenarios and discuss them in depth (kind of "let's pick English and Spanish, two very commonly used languages, and talk about all quirks and translation techniques", in your own example). You already provided better lines for some of the options than what their docs state, although I'd still mis…

> You already provided better lines for some of the options than what their docs state I wrote the docs section you refer to :) They are meant to be narrow and to the point, not didactic, not least because the codepath leading up to an option and following that option depend on internal evaluations and other options. > why would anyone want to do that? Because the input has weird or unreliable DTS. One would have to…

> They are meant to be narrow and to the point, not didactic

And that's understandable, but I believe some are crossing a thin line between "this is not the place where you should be learning about the technicalities of this option" and "this was added for some obscure and undocumented reason and nobody will really know for sure why it's useful".

> [why would anyone want to do use +igndts?] Because the input has weird or unreliable DTS.

> In theory, igndts is unsetting wallclock dts set by the last option. genpts should have no effect, again due to the third option.

These 2 are perfect examples of concise clarifications that would help users a lot

> I wrote the docs section you refer to :)

And I personally thank you for it; it's much better some documentation, even if IMHO a bit too short on details, than no docs at all... and writing proper docs is hard, I know it very well from the project I'm maintainer of! :)

Post reply on HN