#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:2 by , 7 years ago
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.
comment:3 by , 7 years ago
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 by , 7 years ago
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.
comment:5 by , 7 years ago
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.
comment:6 by , 7 years ago
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.
follow-up: 8 comment:7 by , 7 years ago
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 by , 7 years ago
@heleppkes
- 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?
- 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 somethingI 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 by , 7 years ago
it would be great if ffmpeg will support it. Also low latency efficient streaming it the way to 4k )
comment:10 by , 7 years ago
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:21 by , 7 years ago
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:23 by , 7 years ago
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:25 by , 7 years ago
@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~
comment:26 by , 7 years ago
Streaming H265 over FLV is entirely worthless.
A bunch of fake votes won't make us waste our time for you.
comment:27 by , 7 years ago
@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.
comment:28 by , 7 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → 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.
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 by , 7 years ago
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 by , 7 years ago
There is no sockpuppet accounts, none of them is FAKE.
And my grandma is Hillary Clinton.
comment:31 by , 7 years ago
@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 by , 7 years ago
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 to push Adobe to upgrade 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?
comment:33 by , 7 years ago
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.
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).