search

Dash-Industry-Forum / FFmpeg

Tracking DASH related existing issues and desired features
0 stars 0 forks source link

Which DASH-IF IOP feature(s) should we add to FFmeg? #1

Open irajs opened 4 years ago

nicoweilelemental commented 4 years ago

I think we need to focus on what is realistic from a FFmpeg architecture perspective, which means leveraging signaling in the source signal to get specific output features. Trying to leverage one single input format is better as it will prevent to use multiple workflows for multiple output features. I would prioritize RTP/TS over any other input formats as it doesn't require an intermediary server to feed FFmpeg (like RTMP does require) and because this is the broadcast industry standard.

  1. Multiperiod support, for ad insertion experimentations in low latency mode. RTP with SCTE markers works great for that.

  2. Timed Metadata Track support. RTP with SCTE markers would probably work also, but we would need to choose one segmentation type as there is no specific type for such messages in the SCTE-35 spec. I would pick the Content Identification segmentation type as it is kinda generic. A backup plan, if RTP/SCTE is too complex for this purpose, is to use a RTMP source with AMF metadata / cue points.

  3. IMSC1 Text profile subtitles support. RTP/DVB-Text would probably be the best source approach.

  4. Trickplay support. A RTP source works also great here, for thumbnails extraction (not sure we want to output a low framerate track in the video adaptation set)

wilaw commented 4 years ago

I like this list but would also prioritize Resync elements (type = 2) as I think that could lead to better performing lower latency pretty quickly and we can’t build a player for these until we have an encoder/packager that creates them.

Cheers Will

From: Nicolas Weil notifications@github.com Reply-To: Dash-Industry-Forum/FFmpeg reply@reply.github.com Date: Wednesday, April 29, 2020 at 10:30 AM To: Dash-Industry-Forum/FFmpeg FFmpeg@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [Dash-Industry-Forum/FFmpeg] Which DASH-IF IOP feature(s) should we add to FFmeg? (#1)

I think we need to focus on what is realistic from a FFmpeg architecture perspective, which means leveraging signaling in the source signal to get specific output features. Trying to leverage one single input format is better as it will prevent to use multiple workflows for multiple output features. I would prioritize RTP/TS over any other input formats as it doesn't require an intermediary server to feed FFmpeg (like RTMP does require) and because this is the broadcast industry standard.

  1. Multiperiod support, for ad insertion experimentations in low latency mode. RTP with SCTE markers works great for that.
  2. Timed Metadata Track support. RTP with SCTE markers would probably work also, but we would need to choose one segmentation type as there is no specific type for such messages in the SCTE-35 spec. I would pick the Content Identification segmentation type as it is kinda generic. A backup plan, if RTP/SCTE is too complex for this purpose, is to use a RTMP source with AMF metadata / cue points.
  3. IMSC1 Text profile subtitles support. RTP/DVB-Text would probably be the best source approach.
  4. Trickplay support. A RTP source works also great here, for thumbnails extraction (not sure we want to output a low framerate track in the video adaptation set)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Dash-2DIndustry-2DForum_FFmpeg_issues_1-23issuecomment-2D621355169&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=e0yMfkRK2AS_S_3SIVaLI_59C0GNuT5u0Q7sq7HH-bs&s=9bZg9YZl6wOo64PK1k0wQ6Q4kcrzYLLbMl5JUrpM-2c&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAVCMCR6FWEJFZWC6M6LGODRPBP5BANCNFSM4MQIEWDQ&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=e0yMfkRK2AS_S_3SIVaLI_59C0GNuT5u0Q7sq7HH-bs&s=llK-BmcMvnydCNuAXasblQJZrj3u-wmeV7RSgRTU3o0&e=.

nicoweilelemental commented 4 years ago

Correct, I had forgotten the Resync type 2, this is truly very important at this stage !

irajs commented 4 years ago

I suggest we separate the input support vs the output support, like multiperiod support.

I have a question regarding the input support. Where does the DASH Ingest fit here if any?

nicoweilelemental commented 4 years ago

DASH Ingest is an output from the FFmpeg perspective.

We can also request the implementation of DASH-IF ingest interfaces in Nginx, in order to propose the end-to-end solution as open source. That would make sense.

irajs commented 4 years ago

That would be good.

Overall, similar to the overall architecture diagram we have in our IOP document, it would be good we have an architecture diagram for our testbed (I think at one point you had a blueprint), with the list of currently supported relevant formats/protocols at each interface. Then we can create a shortlist of features for each module, trying to align the necessary support for each feature end-to-end for the relevant components.