SCTE-35 implementation already (bounty)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

SCTE-35 implementation already (bounty)

Dennis
Looking for SCTE-35 pass through implementation:

1. Extract SCTE-35 from MPEG-TS.
2. Translate timing of the original SCTE-35 events to match timing in the
output file appropriately or keep timing as is.
3. Signal encoder to force key frames at the boundaries of the SCTE-35
event.
4. Inject SCTE-35 messaging into output MP4 files as emsg and into MPD and
M3U8 manifests if/as needed.

More info:
https://www.w3.org/TR/media-timed-events/#scte-35
https://www.tvtechnology.com/opinions/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world

source TS file with SCTE-35 also saved as ES and XML:
https://www.mediafire.com/folder/zv20csqeo1ixt/

Bounty of $2,500.00 USD (up to Oct 2020)
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: [FFmpeg-devel] SCTE-35 implementation already (bounty)

Brainiarc7
On Wed, 2 Sep 2020 at 07:29, MediaStream <[hidden email]> wrote:

> Looking for SCTE-35 pass through implementation:
>
> 1. Extract SCTE-35 from MPEG-TS.
> 2. Translate timing of the original SCTE-35 events to match timing in the
> output file appropriately or keep timing as is.
> 3. Signal encoder to force key frames at the boundaries of the SCTE-35
> event.
> 4. Inject SCTE-35 messaging into output MP4 files as emsg and into MPD and
> M3U8 manifests if/as needed.
>
> More info:
> https://www.w3.org/TR/media-timed-events/#scte-35
>
> https://www.tvtechnology.com/opinions/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world
>
> source TS file with SCTE-35 also saved as ES and XML:
> https://www.mediafire.com/folder/zv20csqeo1ixt/
>
> Bounty of $2,500.00 USD (up to Oct 2020)
>
>
Hello there,

Please contact Devin Heitmueller (copied herein) for more on the same.
There's a branch with the SCTE-35 fix-ups here:
https://github.com/LTNGlobal-opensource/FFmpeg-ltn/commits/ltn_thumbnailer
Though its' based on an FFmpeg code-base from ~2 years ago. To get it to
run, try a minimalist build with the bare essentials enabled, as some
(newer) libraries such as libfdk-aac will give you trouble.

What I can confirm is that indeed, the SCTE-35 payloads can be passed
through and re-timed in mpegts muxer. So task (1) and (2) are *mostly*
complete. Let Devin confirm that for you.
There's also a generic bitstream filter you can use to dump the SCTE-35
messages.
See:
1.
https://github.com/LTNGlobal-opensource/FFmpeg-ltn/commit/f91fa5cc67b43183cf0bd6dab3b468bd2b94056d
2.
https://github.com/LTNGlobal-opensource/FFmpeg-ltn/commit/a04d2bbbc9829a5332472d86d5b86e69d1f7ec5d
3.
https://github.com/LTNGlobal-opensource/FFmpeg-ltn/commit/2f6fea5f86ee816b01e05840999bffc706a9af04

Porting these upstream (to ffmpeg master's git tip) will not be a trivial
task, but its' definitely doable.

Regards,

BR.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: SCTE-35 implementation already (bounty)

andrei ka
In reply to this post by Dennis
btw, tsduck suite can extract pts of scte35, chances are you could make
filter_complex_script with these pos to insert kframes
&rei


On Wed, Sep 2, 2020 at 6:36 AM MediaStream <[hidden email]> wrote:

> Looking for SCTE-35 pass through implementation:
>
> 1. Extract SCTE-35 from MPEG-TS.
> 2. Translate timing of the original SCTE-35 events to match timing in the
> output file appropriately or keep timing as is.
> 3. Signal encoder to force key frames at the boundaries of the SCTE-35
> event.
> 4. Inject SCTE-35 messaging into output MP4 files as emsg and into MPD and
> M3U8 manifests if/as needed.
>
> More info:
> https://www.w3.org/TR/media-timed-events/#scte-35
>
> https://www.tvtechnology.com/opinions/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world
>
> source TS file with SCTE-35 also saved as ES and XML:
> https://www.mediafire.com/folder/zv20csqeo1ixt/
>
> Bounty of $2,500.00 USD (up to Oct 2020)
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: SCTE-35 implementation already (bounty)

Brainiarc7
On Tue, 22 Sep 2020, 13:12 andrei ka, <[hidden email]> wrote:

> btw, tsduck suite can extract pts of scte35, chances are you could make
> filter_complex_script with these pos to insert kframes
> &rei
>
>
> On Wed, Sep 2, 2020 at 6:36 AM MediaStream <[hidden email]> wrote:
>
> > Looking for SCTE-35 pass through implementation:
> >
> > 1. Extract SCTE-35 from MPEG-TS.
> > 2. Translate timing of the original SCTE-35 events to match timing in the
> > output file appropriately or keep timing as is.
> > 3. Signal encoder to force key frames at the boundaries of the SCTE-35
> > event.
> > 4. Inject SCTE-35 messaging into output MP4 files as emsg and into MPD
> and
> > M3U8 manifests if/as needed.
> >
> > More info:
> > https://www.w3.org/TR/media-timed-events/#scte-35
> >
> >
> https://www.tvtechnology.com/opinions/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world
> >
> > source TS file with SCTE-35 also saved as ES and XML:
> > https://www.mediafire.com/folder/zv20csqeo1ixt/
> >
> > Bounty of $2,500.00 USD (up to Oct 2020)
>

So can gstreamer's mpegts muxer implementation.

>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: SCTE-35 implementation already (bounty)

Brainiarc7
On Tue, 22 Sep 2020, 13:43 Dennis Mungai, <[hidden email]> wrote:

> On Tue, 22 Sep 2020, 13:12 andrei ka, <[hidden email]> wrote:
>
>> btw, tsduck suite can extract pts of scte35, chances are you could make
>> filter_complex_script with these pos to insert kframes
>> &rei
>>
>>
>> On Wed, Sep 2, 2020 at 6:36 AM MediaStream <[hidden email]> wrote:
>>
>> > Looking for SCTE-35 pass through implementation:
>> >
>> > 1. Extract SCTE-35 from MPEG-TS.
>> > 2. Translate timing of the original SCTE-35 events to match timing in
>> the
>> > output file appropriately or keep timing as is.
>> > 3. Signal encoder to force key frames at the boundaries of the SCTE-35
>> > event.
>> > 4. Inject SCTE-35 messaging into output MP4 files as emsg and into MPD
>> and
>> > M3U8 manifests if/as needed.
>> >
>> > More info:
>> > https://www.w3.org/TR/media-timed-events/#scte-35
>> >
>> >
>> https://www.tvtechnology.com/opinions/scte10435-and-beyond-a-look-at-ad-insertion-in-an-ott-world
>> >
>> > source TS file with SCTE-35 also saved as ES and XML:
>> > https://www.mediafire.com/folder/zv20csqeo1ixt/
>> >
>> > Bounty of $2,500.00 USD (up to Oct 2020)
>>
>
> So can gstreamer's mpegts muxer implementation.
>

To clarify: Devin's ffmpeg branch (linked above) delivers the first two
objectives. However, these patches need to be forward-ported to git master,
as they also require significant fix-ups to be applied to the mpegts muxer.

That way, a downstream packager can use the SCTE-35 payloads to insert the
relevant splices to the HLS and DASH manifests.

>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: SCTE-35 implementation already (bounty)

Devin Heitmueller-2
Hi there,

On Tue, Sep 22, 2020 at 7:23 AM Dennis Mungai <[hidden email]> wrote:
> To clarify: Devin's ffmpeg branch (linked above) delivers the first two
> objectives. However, these patches need to be forward-ported to git master,
> as they also require significant fix-ups to be applied to the mpegts muxer.

To expand on this a bit, the patches are off a branch I did a couple
of years ago which I am running in production.  The patches can be
forward ported to master, but they are dependent on a few other
commits earlier in that branch.  This includes some changes to the
MPEG-TS demux, a change to stash the source PTS value as AVPacket side
data, and some changes to libavformat/mux.c to treat SCTE-35 packets
as sparse so that the mux framework doesn't stall waiting for packets.
There might be a couple of other misc patches in there as well which
would need to be ported, but I haven't looked in a while so I might
not be thinking of them.

> That way, a downstream packager can use the SCTE-35 payloads to insert the
> relevant splices to the HLS and DASH manifests.

It's worthwhile to note that the patch series today doesn't require
any actual parsing of the SCTE-35 payload beyond modifying the
pts_adjust field (which is at a fixed offset of every packet).  In
order to construct HLS manifests containing SCTE-35 you would have to
actually decode the SCTE-35 payload to extract certain fields
(depending on which form of SCTE-35 over HLS is being implemented --
IIRC there are at least three different methods).  In-house we do this
with libklscte35 and my long term thought would be to get that library
merged upstream as a dependency (as we did for libklvanc), but there
is cleanup required on the library API itself before any patches using
it in ffmpeg would be accepted upstream.

It's probably also worth noting that the patch series Dennis
referenced has a minor bug in the math that results in the splice
point being off by 1-2 frames, even if not transcoding the actual
video.  It's probably fine for most applications but it's on my TODO
list to go through the math and chase that down.

Regarding the ability to force a keyframe at the splice point, this is
harder than one might expect.  We've implemented the code to adjust
the PTS of the SCTE-35 packet as a BSF on the output side, but in
order to influence the behavior of the encoder we would have to
implement a feedback mechanism to notify the encoder (which is further
upstream in the pipeline) on which frame to force the keyframe.  The
ffmpeg frameworks don't really provide an easy way to propagate
information from a BSF back to an upstream video filter (in general
metadata only flows downstream).   My thought was to implement a video
filter which listens on a UDP socket, and then have the BSF do the
math to calculate the actual PTS of the splice point, and then send an
out-of-band message via UDP back to the video filter to set the
appropriate AVFrame flags to force a key frame when appropriate. **

** Note, I haven't actually prototyped this part yet, so don't know if
it will actually work or if there are some unexpected gotcha related
to what the PTS values are at various points in the pipeline.

Devin

--
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: [hidden email]
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".