[FFmpeg-devel] SCTE-35 development

[Anshul]

On 01/12/2015 05:59 PM, Anshul wrote:
> On 01/12/2015 02:48 AM, Michael Niedermayer wrote:
>> On Mon, Jan 12, 2015 at 01:09:11AM +0530, Anshul wrote:
>>> On 12/31/2014 07:13 PM, Michael Niedermayer wrote:
>>>> So SCTE-35 is basically about segmenting a video timewise (primarely
>>>> to mark Ads but not always) We already have a API to segment videos
>>>> timewise, its AVFormatContext.chapters that may need some changes to
>>>> handle incrementally added (and on the muxer side incrementally
>>>> stored) data or we might even choose a different system entirely than
>>>> that AVChapter array for such incrementally stored segments but i dont
>>>> think data decoders with a completely opaque input and output are a
>>>> reasonable API for communicating such temporal segmenting [...]
>>> I have not looked at it yet, due to some disadvantage told me on irc,
>>> sry but I have forgotten those disadvantage of chapters.
>> It would be better if the reasons behind a design decission are
>> understood and documented
>>
> Yes, I studied the document of AVChapter, just now its only used
> for mostly header and sometimes trailer.
> Its structure match very much to interface of scte_35, but it is not
> sufficient
> I have to have locking mechanism there, so that I would know whether I
> am still
> using it or not.
> These chapters also look very static, I did not find any logic to cancel
> the event
> at last moment.
>
> modification to my previous patch were possible with AVChapter, but now
> I feel
> i don't require to communicate from demuxer or decoder, because I have
> written a
> parser in AVFormat and only used in hls muxer.
> and If later I would use that parser in filter, ubitux gave me idea to
> use ff_ap
>  
>>> if any one here still believe that chapters approach will be better,  I
>>> will look at it.
>>>
>>> Though I have done some new implementation, it is out of avcodec folder.
>>> I have tweaked slightly AVFormat public structure.
>>>
>>> for details please review attached draft patch.
>>>
>>> I would appreciate, if someone pinpoint architecture issue first.
>>> I really get demoralized when I have to throw all my work after
>>> considering all review comments.
>>> then at last some architecture comments.
>>>
>>> lots of memory leakage are still there, please ignore it for time being,
>>> i am working on it.
>>>
>>> follwing is the command which is also added in commit message to use
>>> this patch
>>> ./ffmpeg_g -vsync 0 -copyts -i ~/test_videos/mpegwithscte35.ts
>>> -hls_list_size 1000 -dcodec copy  tmp/some.m3u8
>>>
>>> -Anshul
>>>  ffmpeg.c                |    6 +++++-
>>>  ffmpeg_opt.c            |   10 ++++++++++
>>>  libavcodec/avcodec.h    |    1 +
>>>  libavcodec/codec_desc.c |    6 ++++++
>>>  libavformat/Makefile    |    1 +
>>>  libavformat/avformat.h  |   17 +++++++++++++++++
>>>  libavformat/format.c    |    2 ++
>>>  libavformat/hlsenc.c    |   39 +++++++++++++++++++++++++++++++++++----
>>>  libavformat/mpegts.c    |   45 +++++++++++++++++++++++++++++++++++++++------
>>>  libavformat/utils.c     |    1 +
>> theres some file missing
>> libavformat/hlsenc.c:39:21: fatal error: scte_35.h: No such file or directory
> I always forget this if I don't check the ffmpeg codec checklist.
> hope i will gradually get into this habit.
> and I am sorry for being so annoying to all.
>
> attached new patch.
> -Anshul
>
forgot to signoff.
attached another

-Anshul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adding-SCTE-35-implementation-in-avformat.patch
Type: text/x-patch
Size: 30452 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150112/a4a8ff3c/attachment.bin>