Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#6389 closed task (invalid)

Support H.265 over Adobe HTTP-FLV or RTMP

Reported by: winlin Owned by:
Priority: normal Component: avformat
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

FFMPEG is a great project, thank everyone's awesome work!

Adobe HTTP-FLV or RTMP is the defacto protocol for live streaming over internet and almost all encoders support pushing stream to server or CDN over RTMP protocol, while player like Adobe Flash or Android ExoPlayer? or FFMPEG also support HTTP-FLV.

Although H.265 is supported by HLS and TS, we can also delivery H.265 over HTTP-TS for realtime live streaming service, but CDNs are more friendly to RTMP/HTTP-FLV. For example, all, that's all, not some, all live streaming service in China now are using RTMP/HTTP-FLV for 3-5s latency, none of them chooses HLS for its large latency.

Maybe realtime live streaming is not popular in the US, but I think it's only because the CDN is not very good at delivery RTMP/HTTP-FLV. I know some friends in the UK and US are now build the realtime CDN themselves, some use [NGINX-RTMP](https://github.com/arut/nginx-rtmp-module) like facebook, others using [SRS](https://github.com/ossrs/srs) to delivery realtime live streaming:

Encoder ====RTMP====> SRS(Cluster) ====RTMP/HTTP-FLV====> Player

Now, it work very good for H.264+AAC over RTMP/HTTP-FLV for 3-5s realtime live streaming service, what about H.265? Is there any plan to support H.265 over HTTP-FLV/RTMP?

Change History (33)

comment:1 follow-up: Changed 4 months ago by JEEB

HEVC over FLV (and thus RTMP) is not defined nor supported. And unless Adobe specifies it, we should not support it. We have enough hacks inside FFmpeg as it is.

Not to mention that there are alternatives out there are properly specified for newer formats such as VP9 or HEVC that can be utilized instead for both ingest to a media server as well as something the actual playback clients get. I mean, even plain MPEG-TS or fragmented ISOBMFF over HTTP would be achievable easily. And while things like HLS or MPEG-DASH are usually used with relatively high latency (often in order to improve compression ratios), they can also be used so that the latency would be within those parameters you mention, so that sort of latency limitation is not really a limitation per se (considering the ingest to a media server that handles the packaging is done in a relatively sane way and that the encoder in the very beginning of the chain is configured accordingly latency-wise).

edit:
Just to reiterate my point: The pure passing of MPEG-TS or fragmented ISOBMFF over HTTP and HLS/MPEG-DASH are two completely separate themes in my paragraph. The latter I only bring up because you noted that such low latency on the content distribution side of things would be impossible according to you. Of course for ingest to a media server you would not utilize such a format, as it clearly is not a single push or pull type of a format (and usually for publishing you want the encoder to push to a media server, not the other way due to that being less of a PITA NAT-wise etc).

Last edited 4 months ago by JEEB (previous) (diff)

comment:2 Changed 4 months ago by winlin

Unfortunately, HLS/DASH doesn't work in 3-5s low latency live streaming service.
That's why facebook migrate from HLS to RTMP and that's why none use HLS/DASH in China where the live businesses are very hot.

Last edited 4 months ago by winlin (previous) (diff)

comment:3 Changed 4 months ago by JEEB

HLS IIRC requires the client to buffer three segments. Make those segments short enough and bam! You have a lower latency. MPEG-DASH has its own limitations and ways of improving latency. So within your idea of "low" latency those are a-OK for the end user.

That said, please for the love of god actually read my post which presents multiple alternatives to an Adobe-specific format/protocol which most likely will not get extended any more by Adobe. I know there's a lot of tech already built around RTMP as ingest but as you can clearly see that is going to be a problem if you want to utilize it for anything that was created since.

comment:4 Changed 4 months ago by winlin

Neither HLS nor DASH can get 1-3s latency.I don't want to waste time to argue with you. Show me the solution or example if DASH can make it. Talking is cheap, show me the example or demo.

Last edited 4 months ago by winlin (previous) (diff)

comment:5 Changed 4 months ago by winlin

I think you just a "thinker", you think when you make segments of HLS short enough, you can get a low latency?
You think DASH is new, DASH is better, so DASH can be used in 1-3s latency use scenarios?
Show me the demo, OK? Stop cheating yourself please.

Last edited 4 months ago by winlin (previous) (diff)

comment:6 Changed 4 months ago by winlin

For HTTP-FLV/RTMP, the benchmark is [here](https://github.com/ossrs/srs/wiki/v2_EN_LowLatency#benchmark-1).
I don't want to talk with you util you can give me a example or demo or even a picture.

comment:7 follow-up: Changed 4 months ago by heleppkes

It makes no difference what you believe, but we're not going to support "custom" extensions of the FLV format - its not our format to extend.

If you want to convince someone, then convince Adobe to extend the FLV specification to include HEVC.

comment:8 in reply to: ↑ 7 Changed 4 months ago by winlin

@heleppkes

  1. If, if Adobe is dead, I means if Adobe is dead or Apple is dead, do you means FFMPEG will never support RTMP/FLV/HLS? Only DASH? What about the user of FFMPEG? Are you really care about your user? Or just care about Adobe or Apple?Isn't FFMPEG live for user? Doesn't FFMPEG care about the user?
  2. It's not something believe, ok? H.265 over TS/HLS is ok for 10s+ live user, but for 1-3s user there are no choices except RTMP/HTTP-FLV. It's not something I believe, it's the fact, can't you see it? I have show you the link about latency of RTMP/HTTP-FLV, can't you show a link of HLS/DASH latency?

comment:9 Changed 4 months ago by jiegokoji

it would be great if ffmpeg will support it. Also low latency efficient streaming it the way to 4k )

comment:10 Changed 4 months ago by canalshare

i think it is very intresting if ffmpeg could support the h265 on flv in order be able to play h265 stream on rtmp format .

comment:11 Changed 4 months ago by seven

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:12 Changed 4 months ago by flhcd

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:13 Changed 4 months ago by torylinux

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:14 Changed 4 months ago by coolfat

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:15 Changed 4 months ago by lazyc

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:16 Changed 4 months ago by leif

H.265 is better

comment:17 Changed 4 months ago by icamera66

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:18 Changed 4 months ago by qingkouwei

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:19 Changed 4 months ago by Johnny

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:20 Changed 4 months ago by antbao

+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:21 Changed 4 months ago by begeekmyfriend

I think it is not only business of Adobe but also the industry of live stream including Facebook, Periscope, Musical.ly and so on. RTMP is the defacto protocol supported by CDN. FLV is the defacto container for live stream. And H.264 is the current (while H.265 would be the future) defacto codec format for almost all of the devices including prevailing ARM codec chips. So I strongly support H.265 over FLV into the trunk. FFmpeg should keep track with the need of industry.

comment:22 Changed 4 months ago by xym808

++ great+1
It's great for FFMEPG to support 265+FLV/RTMP.
I support it.

comment:23 Changed 4 months ago by liuguodong

It will be interesting if ffmpeg support 265+flv/rtmp.flv/rtmp is the defacto protocol/container supported by CDN,h264 is default video codec now in the industry of live stream,but the future will be h265,so i support h265 over flv or rtmp into the trunk.

comment:24 Changed 4 months ago by gavin

ffmpeg will support 265+flv/rtmp?
I'm looking forward to this feature

Last edited 4 months ago by gavin (previous) (diff)

comment:25 Changed 4 months ago by winlin

@JEEB I'm sorry, I wanna apologize for my rude, it's a wrong way to communicate.
Would you please offer some example for HLS/DASH to get low latency by decreasing the segment and buffer time? Because I have tested the HLS, and I used very smaller segments(<1s), but the latency is still very large.

@heleppkes This issue is not about the latency of FLV/RTMP, but it's the key point that why many users use RTMP/FLV. For some interactive live streaming, the protocol is very important, especially there's a CDN between encoder and player. So for H.265, it's also important to support RTMP/FLV in this situation.

Sure, I think you're right, I should push Adobe to upgrade the RTMP/FLV for H.265, IT IS the right way(But it's impossible for me to push Adobe, what do you think about it?). So, even if FFMPEG decided to reject this issue, I think it's reasonable. It just upset some users who are doing businesses in 1-3s interactive live streaming, which is interesting and useful.

FFMPEG, the GOD of live streaming industry, please help us~

Last edited 4 months ago by winlin (previous) (diff)

comment:26 Changed 4 months ago by gjdfgh

Streaming H265 over FLV is entirely worthless.

A bunch of fake votes won't make us waste our time for you.

comment:27 Changed 4 months ago by winlin

@gjdfgh So do you means all these votes are fake? It's not the truth.

What about these "FAKE" votes to ask Adobe to support H.265 in FlashPlayer?:
https://forums.adobe.com/thread/1340207
https://tracker.adobe.com/#/view/FP-3650828

What will happen if it's not JUST my requirement?
How can you say that, man? If there is no one to vote, you will say "it's just a issue of you". If there are some votes, you will say "they are fake votes"?

FFMPEG can choose to not to support this feature, but you can't say it's FAKE votes.
It's not fair.

Last edited 4 months ago by winlin (previous) (diff)

comment:28 in reply to: ↑ 1 Changed 4 months ago by llogan

  • Resolution set to invalid
  • Status changed from new to closed

All of these fake comments from the sockpuppet accounts certainly do not help.

Closing as per comments:

JEEB:

HEVC over FLV (and thus RTMP) is not defined nor supported. And unless Adobe specifies it, we should not support it. We have enough hacks inside FFmpeg as it is.

heleppkes:

It makes no difference what you believe, but we're not going to support "custom" extensions of the FLV format - its not our format to extend.

If you want to convince someone, then convince Adobe to extend the FLV specification to include HEVC.

comment:29 Changed 4 months ago by winlin

You can close it, but you can never change the truth.
There is no sockpuppet accounts, none of them is FAKE.
It's not fair.

comment:30 Changed 4 months ago by gjdfgh

There is no sockpuppet accounts, none of them is FAKE.

And my grandma is Hillary Clinton.

comment:31 Changed 4 months ago by winlin

@gjdfgh I believe in you, please show me a evidence or even a picture?
We should never take responsibility of what we said, right?

comment:32 Changed 4 months ago by winlin

I linked this issue to [SRS #465](https://github.com/ossrs/srs/issues/465#issuecomment-301959445), a issue which was filed almost 2 years ago. Similar to yesterday, I share similar message to the users of SRS and I encourage them to vote only if their businesses require this feature. I don't think this is cheating and all these votes are from sockpuppet accounts, right?

I think it's very important to get response from user. Maybe some Chinese users don't know how to express in English, they just repeat what others said, but they are not my sockpuppet accounts and they vote only when their business really need this feature.

I agree that the RIGHT way to fix this issue is after Adobe upgraded the RTMP/FLV, I'll try to email Adobe about it.

There's no streaming protocol support H.265, so media server or CDN is possible to support it.
Will this issue reopen? Or closed forever?

Last edited 4 months ago by winlin (previous) (diff)

comment:33 Changed 4 months ago by heleppkes

Its closed forever. It doesn't matter how many people vote for it, unless Adobe does something.

The FLV format specification does not support H.265, and even more so it doesn't use a flexible FourCC system or any other extensible system to support arbitrary codec ids, which means without an official specification for H.265, you basically create unreadable files.

Note: See TracTickets for help on using tickets.