[FFmpeg-devel] SCTE-35 development
anshul.ffmpeg at gmail.com
Tue Jan 13 07:25:43 CET 2015
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
>> 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
>>>> 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.
> forgot to signoff.
> attached another
in that previous patch av_bprintf did not worked.
Attached another patch
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 16342 bytes
Desc: not available
More information about the ffmpeg-devel