[FFmpeg-devel] SCTE-35 development

[Anshul]

On 01/12/2015 06:26 PM, Anshul wrote:
> 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
in that previous patch av_bprintf did not worked.
Attached another patch

-Anshul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adding-rollup-functionality.patch
Type: text/x-patch
Size: 16342 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150113/88f9cd8a/attachment.bin>