[FFmpeg-devel] [PATCH 0/4] V12 - SCTE-35 support

[Marton Balint]

On Tue, 4 Oct 2016, Josh de Kock wrote:

> On 01/10/2016 18:27, Carlos Fernandez Sanz wrote:
>> - Addresses new comments such as like idx value checking and filename 
> checking
>>
>> Carlos Fernandez (4):
>>   Adding SCTE-35 CUI codec
>>   SCTE-35 extraction from mpegts
>>   SCTE-35 support in hlsenc
>>   Correct Indentation
>>
>>  libavcodec/avcodec.h    |   2 +
>>  libavcodec/codec_desc.c |   6 +
>>  libavformat/Makefile    |   2 +-
>>  libavformat/hlsenc.c    | 120 ++++++++---
>>  libavformat/mpegts.c    |  48 ++++-
>>  libavformat/scte_35.c   | 527 
> ++++++++++++++++++++++++++++++++++++++++++++++++
>>  libavformat/scte_35.h   |  86 ++++++++
>>  7 files changed, 764 insertions(+), 27 deletions(-)
>>  create mode 100644 libavformat/scte_35.c
>>  create mode 100644 libavformat/scte_35.h
>>
>
> There's been a fair amount of opposition to this set by a few other 
> developers. The main concerns were regarding the timestamps,and how in 
> STCE35 the PTS/DTS can represent both future video packets and others 
> which signify the beginning of the commercial.
>
> The other thing which was fairly ambiguous was how it would work with 
> FFmpeg's timestamps due to how the AVPacket would not contain valid 
> timestamps (how they'd only be in the data). There may be any number of 
> timestamp values within in the AVPacket data stream, and while this may 
> work for one stream, if you add more than one stream there would be no 
> way to sync streams.
>

I don't understand the timestamp issue. SCTE packet PTS/DTS values do not 
represent the cue points. They represent the position of the incoming 
SCTE sections compared to the PCR.

> Putting SCTE35 support in another library like Upipe was suggested as 
> well.

Which functionality? Getting SCTE data from mpegts as a data stream 
totally makes sense IMHO.

Regards,
Marton