[FFmpeg-devel] SCTE-35 development
Anshul
anshul.ffmpeg at gmail.com
Mon Jan 12 13:29:35 CET 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adding-SCTE-35-implementation-in-avformat.patch
Type: text/x-patch
Size: 30392 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150112/df819ab5/attachment.bin>
More information about the ffmpeg-devel
mailing list