Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>Shoot, then the original code was incorrect :).
>
>I will take a final look at your patches next week.
>
>Regards,
>Marton

Thanks. And I forgot to mention a thing. Some parts of that code in this patch 
was started from VLC’s source code. Source link here 
https://fossies.org/linux/vlc/modules/access/sdi.c
That code is also in LGPL license, hence I think it is fine to copy it. But I 
am just giving a disclaimer, so that neither ffmpeg nor the company I represent 
gets into any legal trouble because of that.
I am not a legal expert here, but do you think I should also add those 
copyright lines from sdi.c in this patch as well.

Regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>Then please add the relevant copyright line to the file you changed.
>(Probably "Rafaël Carré" but please verify yourself)
>
>Carl Eugen

Thanks for the clarification. I have added the copyright line as you have 
advised. (Yes, I have verified that that “Rafaël Carré” was the original author 
of that code).

Regards,
Karthick


0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions

[Jeyapal, Karthick]

Thanks for your comments. Please find the patch attached as per your comments.

Regards,
Karthick


0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

Hi Marton,

Thanks a lot for your comments. I have modified the patch as per all your 
comments, except the below one.

>> +tgt = teletext_data_unit_from_ancillary_packet(buf, buf + 1920, 
>> tgt, cctx->teletext_lines, 0);
>
>this should be
>tgt = teletext_data_unit_from_ancillary_packet(buf, buf + len, 
> tgt, cctx->teletext_lines, 1);
>

I have modified it as

tgt = teletext_data_unit_from_ancillary_packet(buf, buf + len, tgt, 
cctx->teletext_lines, 0);

That was just to be in consistency with the existing code. Because current code 
passes allow_multipacket as 0. Let me know if my understanding here is correct.

Please find the patch attached.

Regards,
Karthick





0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Jeyapal, Karthick]

Hi Steven,

I am restarting this discussion, just to conclude this thread one way or the 
other. Maybe I am not thinking correctly. Here is detailed thinking, on why I 
think this patch will not violate HLS spec.

>if (target_duration <= en->duration)
>target_duration = (hls->flags & HLS_ROUND_DURATIONS) ?
>lrint(en->duration) : get_int_from_double(en->duration);

As per the above code, target duration will be maximum of all 
lrint(en->duration) when HLS_ROUND_DURATIONS is set.

>if (hls->flags & HLS_ROUND_DURATIONS)
>avio_printf(out, "#EXTINF:%ld,\n",  lrint(en->duration));
>else
>avio_printf(out, "#EXTINF:%f,\n", en->duration);

As per this code #EXTINF duration will be lrint(en->duration) when 
HLS_ROUND_DURATIONS is set.

>https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.3.1
>
>4.3.3.1.  EXT-X-TARGETDURATION
>
>   The EXT-X-TARGETDURATION tag specifies the maximum Media Segment
>   duration.  The EXTINF duration of each Media Segment in the Playlist
>   file, when rounded to the nearest integer, MUST be less than or equal
>   to the target duration; longer segments can trigger playback stalls
>   or other errors.  It applies to the entire Playlist file.  Its format
>   is:
>
>   #EXT-X-TARGETDURATION:
>
>   where s is a decimal-integer indicating the target duration in
>   seconds.  The EXT-X-TARGETDURATION tag is REQUIRED.

As rightly pointed by you, spec says “The EXTINF duration of each Media Segment 
in the Playlist file, when rounded to the nearest integer, MUST be less than or 
equal to the target duration”. With this patch this is always true, and hence 
there is no violation of spec.

Maybe I misunderstood and missing out something very obvious. Could you let me 
know the situation in which this code will generate target duration lesser than 
the EXTINF duration? Thanks for your help.

Regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

Thanks.

Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Jeyapal, Karthick]

>On 9/6/17, 12:37 PM, "Steven Liu" 
>> wrote:
>segment1.ts   duration = 4.88
>ROUND is 5, not 4,  is it?
>if its duration = 4.04
>ROUND is 4,   the real segment1.ts duration is 4.04,
>
>the safe one is TARGETDURATION = 5, the get_int_from_ double API can
>make the truely,

Yes, when duration of segment1.ts is 4.04, EXTINF duration is 4 when 
HLS_ROUND_DURATIONS is set. After this patch EXT-X-TARGETDURATION will also be 
4(instead of 5), which will be equal to the EXTINF duration and hence there is 
no violation of spec. And when another segment has duration of 4.88 both 
the EXTINF and duration and EXT-X-TARGETDURATION will be 5, still in line with 
the HLS specification. What is reason to be safe when we know deterministically 
that EXTINF duration will always be lesser than or equal to 
EXT-X-TARGETDURATION?

>yes, your patch can make 4.88 to 5, and make 4.04 to 4, all
>solution's TARGETDURATION is INT, but just make safe, i know the lrint
>API, so that is why have not use it, not i don't know lrint.

lrint was already being used for EXTINF duration when HLS_ROUND_DURATIONS is 
set. And this patch kicks in only when HLS_ROUND_DURATIONS is set. It still 
uses the get_int_from_double API otherwise. This patch still doesn’t affect the 
default path when EXTINF is not rounded.

Thanks and Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Jeyapal, Karthick]

>On 9/6/17, 3:43 PM, "Steven Liu" 
><lingjiujia...@gmail.com<mailto:lingjiujia...@gmail.com>> wrote:
>
>>2017-09-06 16:46 GMT+08:00 Jeyapal, Karthick 
>><kjeya...@akamai.com<mailto:kjeya...@akamai.com>>:
>>>On 9/6/17, 12:37 PM, "Steven Liu" >>gmail.com<http://ffmpeg.org/mailman/listinfo/ffmpeg-devel><mailto:lingjiujianke
>>> at gmail.com<http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>> wrote:
>>>segment1.ts   duration = 4.88
>>>ROUND is 5, not 4,  is it?
>>>if its duration = 4.04
>>>ROUND is 4,   the real segment1.ts duration is 4.04,
>>>
>>>the safe one is TARGETDURATION = 5, the get_int_from_ double API can
>>>make the truely,
>>
>> Yes, when duration of segment1.ts is 4.04, EXTINF duration is 4 when 
>> HLS_ROUND_DURATIONS is set. After this patch EXT-X-TARGETDURATION will also 
>> be 4(instead of 5), which will be equal to the EXTINF duration and hence 
>> there is no violation of spec. And when another segment has duration of 
>> 4.88 both the EXTINF and duration and EXT-X-TARGETDURATION will be 5, 
>> still in line with the HLS specification. What is reason to be safe when we 
>> know deterministically that EXTINF duration will always be lesser than or 
>> equal to EXT-X-TARGETDURATION?
>>
>>>yes, your patch can make 4.88 to 5, and make 4.04 to 4, all
>>>solution's TARGETDURATION is INT, but just make safe, i know the lrint
>>>API, so that is why have not use it, not i don't know lrint.
>>
>> lrint was already being used for EXTINF duration when HLS_ROUND_DURATIONS is 
>> set. And this patch kicks in only when HLS_ROUND_DURATIONS is set. It still 
>> uses the get_int_from_double API otherwise. This patch still doesn’t affect 
>> the default path when EXTINF is not rounded.

>when 4.04, the after ROUND  EXTINF value is lesser than segment duration.

Thanks for the reply. Yes, that is true. But as per the HLS spec in 
https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#page-21 
specifies “The EXTINF duration of each Media Segment in the Playlist file, when 
rounded to the nearest integer, MUST be less than or equal to the target 
duration;” for target duration. Please note that phrase “when rounded to the 
nearest integer” in that line. HLS specification allows you to specify target 
duration as maximum of segment duration “after rounding to the nearest integer”.

Just to add a little more justification, we have been running Apple’s 
mediastreamvalidator in our daily regression tests with this patch, and it has 
never warned about the target duration. While I agree Apple’s 
mediastreamvalidator is not a conformance tool to check all kinds of HLS 
errors, but they definitely have quite a few checks in place that flags several 
duration related errors.

>>
>> Thanks and Regards,
>> Karthick
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org<http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>On 9/29/17, 7:36 AM, "James Almer"  wrote:
>>  
>> +static inline uint16_t parity (uint16_t x)
>> +{
>> +uint16_t i;
>> +for (i = 4 * sizeof (x); i > 0; i /= 2)
>> +x ^= x >> i;
>> +return x & 1;
>> +}
>
>Can't you use av_parity() instead?

Yes, I can. Thanks for pointing it out. But that patch has been submitted 
already. Hence, I have attached a fresh patch with this suggested change.

Regards,
Karthick



0001-avdevice-decklink_dec-Used-av_parity-instead-of-dupl.patch
Description: 0001-avdevice-decklink_dec-Used-av_parity-instead-of-dupl.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>Applied the series, thanks!
>
>Marton

Thanks a lot!

Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>Sorry, still not quite there... Here are some further comments:
Thanks for your comments and patience. Please find the updated patch attached, 
with all the comments taken.
Also, I have rebased this patch with the latest ffmpeg, as avcodec version 
numbers have changed in the meantime.

>Also please test your patches with real CC data before posting them, I
>know it is tedious work with all the patch iterations, but I do the same
>with teletext.
Sorry about that. I did test that patch with real CC data and corrected the 
inverted checks, but I forgot and attached the older patch in a hurry.
Sorry for wasting your time there.

>Fingers crossed for the next patch version :)
Well, me too :)

Thanks and Regards,
Karthick


0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>Sorry for the late reply, the last was busy week. Here are some more
>comments:

Thanks for your comments. Please find the updated patch attached with your 
comments incorporated.

Regards,
Karthick


0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/decode: Pass on the Closed Captions Side Data

[Jeyapal, Karthick]

>Maybe this should be handled somewhere in generic code? This is hardly
>a v210 property at all.

Yes, I agree. It is better to handle it in the generic code. Have attached a 
patch, where the same is handled in decode.c

Thanks and regards,
Karthick


0004-avcodec-decode-Pass-on-the-Closed-Captions-Side-Data.patch
Description: 0004-avcodec-decode-Pass-on-the-Closed-Captions-Side-Data.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

>On 9/1/17, 5:36 PM, "Steven Liu"  wrote:
>> Please find the patch attached.
>>
>> Regards,
>> Karthick
>>
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>FFmpeg has support it yet, you can use http method.

>
>liuqideMBP:dash liuqi$ ./ffmpeg -v debug -user_agent "StevenLiu" -i
>http://192.168.0.202/stream999_low.m3u8 -c copy -f mpegts a.ts

Hi Steven,

Thanks for the reply. The above method for setting User-Agent works only HLS 
demuxer. It doesn’t work for HLS muxer. The patch that was attached was meant 
for HLS muxer.

Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

>On 9/4/17, 12:41 PM, "Steven Liu" 
>> wrote:
>
>Hi Karthick,
>set user_agent better than user-agent, because the user-agent is
>duplicate with user_agent, and the user-agent will be deprecated in
>new version, refer to :
>https://ffmpeg.org/ffmpeg-protocols.html#http
>
>   BTW, the patch is ok, if modify the user-agent to user_agent

Hi Steven,

Thanks for the reply. I am not using ‘user-agent’. I was using 
‘http_user_agent’. Do you want me to rename ‘http_user_agent’ to ‘user_agent’?
I used ‘http_user_agent’ just to indirectly infer that it is http-specific 
option. But I am OK to rename it to ‘user_agent’ if you insist.

Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

>On 9/4/17, 1:36 PM, "Steven Liu" 
>> wrote:
>+if (c->user_agent)
>+av_dict_set(options, "user-agent", c->user_agent, 0);
>
>should be
>av_dict_set(options, "user_agent", c->user_agent, 0);

Oh! OK Got it. Sorry for the confusion. Have attached the patch with user_agent 
being set.

Thanks,
Karthick


0001-avformat-hlsenc-Added-configuration-to-override-HTTP.patch
Description: 0001-avformat-hlsenc-Added-configuration-to-override-HTTP.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avformat/dash: move reused API to common file and header file

[Jeyapal, Karthick]

>Pushed.
>
>Thanks

FYI. FATE is failing after this push. It is due to the missing copyright header 
in dash.c

Thanks and Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/decode: Pass on the Closed Captions Side Data

[Jeyapal, Karthick]

>Actually in ff_init_buffer_info is a mapping of packet sidedata to
>frame sidedata, if you just add the new CC sidedata type there, the
>existing code should already handle it, from what i can tell.
>
>- Hendrik
Thanks for that guidance. It makes perfect sense to handle it in 
ff_init_buffer_info. Please excuse my limited knowledge on ffmpeg. Please find 
the updated patch attached.

Regards,
Karthick



0004-avcodec-decode-Pass-on-the-Closed-Captions-Side-Data.patch
Description: 0004-avcodec-decode-Pass-on-the-Closed-Captions-Side-Data.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Jeyapal, Karthick]

>2017-09-01 18:32 GMT+08:00 Steven Liu 
>>:
>Sorry, my mistake.
>
>the target_duration must large or equal to the en->duration, can not
>small than en->duration from HLS version 3.

When “round_durations” is enabled “en->duration” also gets rounded(lrint). So 
in the playlist, the target duration will never be lesser than any of the 
segment durations. It will still be in compliance to the HLS spec.
Otherwise we see an output where all segment durations are ‘n’ seconds, and the 
target duration is ‘n+1’ seconds when round_durations is enabled. This behavior 
causes some players to misbehave and add more latency unnecessarily.

Thanks,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled

[Jeyapal, Karthick]

>The hls_time is set to the segments duration, not target duration, and
>the hls_time just a reference value, so the target duration is +1.
>anyway, this patch can not catch the point.

>The spec clearly says it has to be greater or equal. So rounding it up
>is perfectly legal and might even safeguard against some poor player
>implementations.

I think there is a misunderstanding here. Sorry if I was not clear. I mean to 
say, even with this patch EXT-X-TARGETDURATION will always be greater than or 
equal to the EXTINF duration of all the segments in the playlist. Hence it is 
compliant with the HLS spec.

Regards,
Karthick





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

Please find the patch attached.

Regards,
Karthick




0001-avformat-hlsenc-Added-configuration-to-override-HTTP.patch
Description: 0001-avformat-hlsenc-Added-configuration-to-override-HTTP.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [WARNING! RECEIVED FROM EXTERNAL SENDER] Re: [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions

[Jeyapal, Karthick]

Overlooked a “signed vs unsigned comparison” compilation warning in the 
previous patch. Sorry about that. Please use this updated patch(attached) for 
review.

Regards,
Karthick


0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions

[Jeyapal, Karthick]

>On 9/3/17, 4:48 PM, "Marton Balint" > 
>wrote:

>That may well be true, but SMPTE 334M recommands to use lines "from
>the second line after the line specified for switching to the last line
>preceding active video, inclusive", so I'd skip at least the lines up to
>the switching line, in order not to decode stuff which in fact belongs to
>another source... And since we already keeping track of VANC line
>numbers for each mode, it's almost no extra code to do this properly.

>Instead of all the getter functions, I think it is simpler to create
>struct for a mode/field combination, and use an array to store the mode
>line settings. Then you can loop through the array and find your settings.

Hi Marton,

Thanks for your comments. Please find the patch attached, incorporating both 
the above suggestions.

Regards,
Karthick


0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions

[Jeyapal, Karthick]

Overlooked a “signed vs unsigned comparison” compilation warning in the 
previous patch. Sorry about that. Please use this updated patch(attached) for 
review.

Regards,
Karthick

P.S : I had sent the same reply sometime back, but a new thread got created. 
Please ignore that. I am using Outlook on Mac as my mail client and it doesn’t 
really work along with mailing lists, with extra corporate-level securities in 
our mail servers. Hope this reply doesn’t create a new thread again :)


0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] avdevice/decklink_dec: Extraction of luma from V210 VANC modularized

[Jeyapal, Karthick]

>On 9/3/17, 5:18 PM, "Marton Balint" > 
>wrote:
>
>I think we only have vanc numbers until resolution of 1920 width, so that
>should be enough. Probably better to add an av_assert which checks if
>frame width is less or equal to FF_ARRAY_ELEMS(luma_vanc).
Done. Please find the patch attached. Have handled that 1920 limit, little 
different from your suggested method. Hope it is fine.

Regards,
Karthick


0002-avdevice-decklink_dec-Extraction-of-luma-from-V210-V.patch
Description: 0002-avdevice-decklink_dec-Extraction-of-luma-from-V210-V.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>On 9/3/17, 8:19 PM, "Marton Balint" > 
>wrote:

>Why don't use you simply use uint16_t here as well? I think we typically
>try to avoid unsigned as a type.
Done. Changed it to uint16_t.

>This VANC parser does not seem right. VANC header can appear multiple
>times, you seem to parse only the first DID. Also, you should simply
>ignore unknown DID-s, ffmpeg will not be able to parse all types there
>are, there is no need to warn.
Thanks for pointing it out. Have handled it now. Also changed the warning log 
to debug log.

Please find the patch attached.

Regards,
Marton



0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/tcp: enable TCP_NODELAY by default

[Jeyapal, Karthick]

>On 11/14/17, 11:11 PM, "Aman Gupta" <a...@tmm1.net on behalf of 
>ffm...@tmm1.net> wrote:
>
>From: Aman Gupta <a...@tmm1.net>
>
>This can reduce latency and increase throughput, particularly on high
>latency networks.
>
>Signed-off-by: Aman Gupta <a...@tmm1.net>
>Reviewed-by: Jeyapal, Karthick <kjeya...@akamai.com>
---
I forgot to mention last time. You would also need to update the 
doc/protocols.texi
documentation explaining this new option.

Regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

[Jeyapal, Karthick]

>On 11/15/17, 10:32 AM, "Aman Gupta"  wrote:
>
>From: Aman Gupta 
>
>Signed-off-by: Aman Gupta 
>---
> libavformat/http.c | 1 +
> libavformat/tls.c  | 1 +
> 2 files changed, 2 insertions(+)

Again, do want to hardcode tcp_nodelay at http and tls level? Because there 
could be other muxers 
that send data in very small chunks where setting this option would actually 
increase the tcp overhead
severely for such use-cases.

I thought it would be better if the http plugin exposed this as an option and 
hls or dash muxers enable it, 
after we make sure that the relevant TS and MOV muxers used in hls and dash 
plugins writes data as 
big chunks(atleast one frame at a time or some kind of size limit). I think 
movenc already handles it with
dynbuf avio and pushes it only at the end of the segment. But same can’t be 
said about the mpd file or
m3u8 file posts. I think we need to examine the tcpdump logs(or wireshark) to 
make sure that the number
of tcp packets doesn’t increase unexpectedly after this change. 

I am only saying this from muxer point of view. Similarly, we need think from 
demuxer point of view and
make sure that enabling this doesn’t add any unnecessary tcp overhead there as 
well.

My suggestion is to add tcp_nodelay as an option for http and tls and push this 
change.
Later we can modify the hls and dash plugins separately to enable this 
optimization.

Thanks and regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

[Jeyapal, Karthick]

Since Vishwanath is on leave today, I have made the changes required and have 
sent patchset v2.

On 11/23/17, 4:11 PM, "Carl Eugen Hoyos"  wrote:

>2017-11-23 4:37 GMT+01:00  :
>> From: Vishwanath Dixit 
>>
>> Signed-off-by: Karthick J 
>> ---
>>  libavformat/hlsenc.c | 67 
>> +++-
>>  1 file changed, 66 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 9fed6a3..32246c4 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1065,6 +1065,52 @@ static int get_relative_url(const char *master_url, 
>> const char *media_url,
>>  return 0;
>>  }
>>
>> +static void get_codec_str(AVStream *vid_st, AVStream *aud_st, char *vcodec,
>> +  char *acodec, int vcodec_len, int acodec_len) {
>
>> +if (vcodec_len > 0)
>> +vcodec[0] = '\0';
>> +else
>> +return;
>> +
>> +if (acodec_len > 0)
>> +acodec[0] = '\0';
>> +else
>> +return;
>
>What are these supposed to do?
>Actually: Please add a line below to avoid these.
Made it based on av_malloc inside the function and caller has to free it. 
Now the code has become much simpler
>
>> +
>> +if (!vid_st && !aud_st) {
>> +av_log(NULL, AV_LOG_WARNING, "Atleast one stream shoud be valid\n");
>> +return;
>> +}
>
>This looks like the wrong place for such a check.
I have removed the warning, as it is a wrong place. 
Retaining the sanity check tough.
>
>> +
>> +if (vid_st && vid_st->codecpar->profile != FF_PROFILE_UNKNOWN &&
>> +vid_st->codecpar->level != FF_LEVEL_UNKNOWN &&
>> +vid_st->codecpar->codec_id == AV_CODEC_ID_H264) {
>> +snprintf(vcodec, vcodec_len, "avc1.%02x00%02x",
>> +vid_st->codecpar->profile, vid_st->codecpar->level);
>> +}
>
>The rfc does not specify a string for unknown profile?
Couldn’t find any explicit mention for unknown profile. 
https://tools.ietf.org/html/rfc6381

>
>> +
>> +if (aud_st) {
>> +if (aud_st->codecpar->codec_id == AV_CODEC_ID_MP2) {
>> +snprintf(acodec, acodec_len, "mp4a.40.33");
>> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_MP3) {
>> +snprintf(acodec, acodec_len, "mp4a.40.34");
>> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_AAC) {
>
>> +/* TODO : For HE-AAC, HE-AACv2, the last digit needs to be set 
>> to 5 and 29 respectively */
>
>Yes.
>Is this the only special case already known?
No. Also we are not setting constrained_set flags of H264 properly. Have added 
a TODO there also.
>
>> +snprintf(acodec, acodec_len, "mp4a.40.2");
>> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_AC3) {
>> +snprintf(acodec, acodec_len, "mp4a.A5");
>> +} else if (aud_st->codecpar->codec_id == AV_CODEC_ID_EAC3) {
>> +snprintf(acodec, acodec_len, "mp4a.A6");
>> +}
>> +}
>> +
>> +// either provide codec string for both active streams or for none
>> +if (vid_st && aud_st && (!strlen(vcodec) || !strlen(acodec))) {
>> +acodec[0] = vcodec[0] = '\0';
>> +av_log(NULL, AV_LOG_INFO, "Codec string not available for audio or 
>> video stream\n");
>> +}
>
>This needs a context and maybe a higher verbosity.
>
>> +}
>> +
>>  static int create_master_playlist(AVFormatContext *s,
>>VariantStream * const input_vs)
>>  {
>> @@ -1075,7 +1121,7 @@ static int create_master_playlist(AVFormatContext *s,
>>  AVDictionary *options = NULL;
>>  unsigned int i, j;
>>  int m3u8_name_size, ret, bandwidth;
>> -char *m3U8_rel_name;
>> +char *m3U8_rel_name, vcodec[32], acodec[32];
>
>I suspect you should initialize the first byte here to
>avoid the check on top.
>
>>
>>  input_vs->m3u8_created = 1;
>>  if (!hls->master_m3u8_created) {
>> @@ -1203,6 +1249,25 @@ static int create_master_playlist(AVFormatContext *s,
>>  avio_printf(master_pb, ",RESOLUTION=%dx%d", 
>> vid_st->codecpar->width,
>>  vid_st->codecpar->height);
>>
>> +get_codec_str(vid_st, aud_st, vcodec, acodec, sizeof(vcodec),
>> +  sizeof(acodec));
>
>Imo, use defines instead of sizeof() here.
>
>> +if (strlen(vcodec) || strlen(acodec))
>
>Even if not speed-critical code, checking the first byte
>may be simpler.
>
>Using "{" here simplifies the code below.
>

regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

[Jeyapal, Karthick]

On 11/24/17, 4:41 PM, "Carl Eugen Hoyos"  wrote:

>2017-11-23 4:37 GMT+01:00  :
>> From: Vishwanath Dixit 

>> +// either provide codec string for both active streams or for none
>> +if (vid_st && aud_st && (!strlen(vcodec) || !strlen(acodec))) {
>> +acodec[0] = vcodec[0] = '\0';
>> +av_log(NULL, AV_LOG_INFO, "Codec string not available for audio or 
>> video stream\n");
>
>What happened to this check?

It has been handled indirectly in the new function.
In the new function will hit the else condition and “goto fail”
+} else {
+goto fail;
+}

regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

On 11/24/17, 3:40 PM, "刘歧" <l...@chinaffmpeg.org> wrote:

>> 在 2017年11月24日，18:02，Jeyapal, Karthick <kjeya...@akamai.com> 写道：
>> 
>> On 11/22/17, 1:27 PM, "Jeyapal, Karthick" <kjeya...@akamai.com> wrote:
>> 
>>>> On 11/22/17, 9:32 AM, "刘歧" <l...@chinaffmpeg.org> wrote:
>>>> 
>>>> This patch is ok, but i see it need an API: ffio_geturlcontext
>>>> 
>>>> it in the other patch, i see it have some thing need talk? If that is ok, 
>>>> this patch should be apply.
>Is this ok?
Yes, ffio_geturlcontext has already been accepted by Nicolas.
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220014.html
He had concerns on calling prot->url_write directly from hlsenc, which has been 
removed on new patchset(v2).
Also av_assert0 has been added as suggested by him
>
>Thanks
>>> Thanks for the reply. 
>>> All concerns raised by Nicolas has been addressed in this latest patch set.
>>> Let us wait for few days to check if anyone still has any objections.
>> Looks like nobody has anymore objections to this patchset. 
>> Well, it has already passed through multiple rounds of reviews.
>> Could somebody please push this to the master. 
>> I have few more patches waiting to be submitted, dependent on this feature.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Added context to av_log calls

[Jeyapal, Karthick]

On 11/24/17, 4:36 PM, "Carl Eugen Hoyos"  wrote:

>2017-11-24 12:03 GMT+01:00 Moritz Barsnick :
>> On Fri, Nov 24, 2017 at 15:42:30 +0530, Karthick J wrote:
>>>  if (av_strncasecmp(master_url, media_url, base_len)) {
>>> -av_log(NULL, AV_LOG_WARNING, "Unable to find relative url\n");
>>>  return AVERROR(EINVAL);
>>
>> Was it intention to remove this one?
Thanks for that question.
Yes, it was removed intentionally, as the calling function was also printing 
the same log, with ERROR.
>
>If yes, please mention in the commit message that this was
>not a useful warning (or make it a separate commit).
I have amended the commit message and have sent a new patch v2.

Thanks and regards,
Karthick



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

I have rebased the below patch for latest master and have sent a new patch v3.

Regards,
Karthick

On 11/22/17, 2:50 PM, "Karthick J"  wrote:

---
 libavformat/hlsenc.c | 237 +++
 libavformat/hlsenc.h |  67 +++
 2 files changed, 193 insertions(+), 111 deletions(-)
 create mode 100644 libavformat/hlsenc.h

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3c47ced..d5b1b98 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -45,6 +45,7 @@
 
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsenc.h"
 #include "internal.h"
 #include "os_support.h"
 
@@ -73,35 +74,11 @@ typedef struct HLSSegment {
 struct HLSSegment *next;
 } HLSSegment;
 
-typedef enum HLSFlags {
-// Generate a single media file and use byte ranges in the playlist.
-HLS_SINGLE_FILE = (1 << 0),
-HLS_DELETE_SEGMENTS = (1 << 1),
-HLS_ROUND_DURATIONS = (1 << 2),
-HLS_DISCONT_START = (1 << 3),
-HLS_OMIT_ENDLIST = (1 << 4),
-HLS_SPLIT_BY_TIME = (1 << 5),
-HLS_APPEND_LIST = (1 << 6),
-HLS_PROGRAM_DATE_TIME = (1 << 7),
-HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in 
segment filenames when use_localtime  e.g.: %%03d
-HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
-HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) 
in segment filenames when use_localtime  e.g.: %%014s
-HLS_TEMP_FILE = (1 << 11),
-HLS_PERIODIC_REKEY = (1 << 12),
-} HLSFlags;
-
 typedef enum {
 SEGMENT_TYPE_MPEGTS,
 SEGMENT_TYPE_FMP4,
 } SegmentType;
 
-typedef enum {
-PLAYLIST_TYPE_NONE,
-PLAYLIST_TYPE_EVENT,
-PLAYLIST_TYPE_VOD,
-PLAYLIST_TYPE_NB,
-} PlaylistType;
-
 typedef struct VariantStream {
 unsigned number;
 int64_t sequence;
@@ -206,6 +183,113 @@ typedef struct HLSContext {
 unsigned int master_publish_rate;
 } HLSContext;
 
+void ff_hls_write_playlist_version(AVIOContext *out, int version) {
+if (!out)
+return;
+avio_printf(out, "#EXTM3U\n");
+avio_printf(out, "#EXT-X-VERSION:%d\n", version);
+}
+
+void ff_hls_write_stream_info(AVStream *st, AVIOContext *out,
+  int bandwidth, char *filename) {
+if (!out || !filename)
+return;
+
+if (!bandwidth) {
+av_log(NULL, AV_LOG_WARNING,
+"Bandwidth info not available, set audio and video 
bitrates\n");
+return;
+}
+
+avio_printf(out, "#EXT-X-STREAM-INF:BANDWIDTH=%d", bandwidth);
+if (st && st->codecpar->width > 0 && st->codecpar->height > 0)
+avio_printf(out, ",RESOLUTION=%dx%d", st->codecpar->width,
+st->codecpar->height);
+avio_printf(out, "\n%s\n\n", filename);
+}
+
+void ff_hls_write_playlist_header(AVIOContext *out, int version, int 
allowcache,
+  int target_duration, int64_t sequence,
+  uint32_t playlist_type) {
+if (!out)
+return;
+ff_hls_write_playlist_version(out, version);
+if (allowcache == 0 || allowcache == 1) {
+avio_printf(out, "#EXT-X-ALLOW-CACHE:%s\n", allowcache == 0 ? "NO" : 
"YES");
+}
+avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
+avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
+av_log(NULL, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
+
+if (playlist_type == PLAYLIST_TYPE_EVENT) {
+avio_printf(out, "#EXT-X-PLAYLIST-TYPE:EVENT\n");
+} else if (playlist_type == PLAYLIST_TYPE_VOD) {
+avio_printf(out, "#EXT-X-PLAYLIST-TYPE:VOD\n");
+}
+}
+
+void ff_hls_write_init_file(AVIOContext *out, char *filename,
+int byterange_mode, int64_t size, int64_t pos) {
+avio_printf(out, "#EXT-X-MAP:URI=\"%s\"", filename);
+if (byterange_mode) {
+avio_printf(out, ",BYTERANGE=\"%"PRId64"@%"PRId64"\"", size, pos);
+}
+avio_printf(out, "\n");
+}
+
+void ff_hls_write_file_entry(AVIOContext *out, int insert_discont,
+int byterange_mode, uint32_t flags, double 
duration,
+int64_t size, int64_t pos, //Used only if 
HLS_SINGLE_FILE flag is set
+char *baseurl, //Ignored if NULL
+char *filename, double *prog_date_time) {
+if (!out || !filename)
+return;
+
+if (insert_discont) {
+avio_printf(out, "#EXT-X-DISCONTINUITY\n");
+}
+if (flags & HLS_ROUND_DURATIONS)
+avio_printf(out, "#EXTINF:%ld,\n",  lrint(duration));
+else
+avio_printf(out, "#EXTINF:%f,\n", duration);
+if (byterange_mode)
+avio_printf(out, "#EXT-X-BYTERANGE:%"PRId64"@%"PRId64"\n", size, pos);
+
+if ((flags & HLS_PROGRAM_DATE_TIME) && prog_date_time) {
+time_t tt, wrongsecs;
+

Re: [FFmpeg-devel] [PATCH v3 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

>On 11/24/17, 9:44 AM, "刘歧"  wrote:
>
>
>> 在 2017年11月24日，11:55，Karthick J  写道：
>> 
>> ---
>> libavformat/hlsenc.c | 238 
>> +++
>> libavformat/hlsenc.h |  68 +++
>> 2 files changed, 194 insertions(+), 112 deletions(-)
>> create mode 100644 libavformat/hlsenc.h
>[…]
>I suggest move the ff_ functions to a common file, because the hlsenc file 
>modify frequently,
>there have risk to be modify by other contributor, these functions maybe need 
>design clearly,
>it is used only by hlsenc and dashenc, i cannot sure it be used by other 
>module future, 
>so modify it is hard work for the modules after this commit.
>Move them to segment_common.c or a good filename.c maybe better than in hlsenc.
>What about your mind?
Thanks for the reply. 
I have segregated ff_ functions into a separate .c file as you suggested, in 
patchset v4.

>
>Thanks

regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/libx264:setting profile and level in avcodec context

[Jeyapal, Karthick]

On 11/23/17, 8:34 PM, "Carl Eugen Hoyos" <ceffm...@gmail.com> wrote:

>2017-11-23 13:56 GMT+01:00 Jeyapal, Karthick <kjeya...@akamai.com>:
>>
>> On 11/23/17, 5:33 PM, "Carl Eugen Hoyos" <ceffm...@gmail.com> wrote:
>>
>>>2017-11-23 12:47 GMT+01:00 Jeyapal, Karthick <kjeya...@akamai.com>:
>>>> On 11/23/17, 4:21 PM, "Carl Eugen Hoyos" <ceffm...@gmail.com> wrote:
>>>>
>>>>>2017-11-23 4:37 GMT+01:00  <vdi...@akamai.com>:
>>>>
>>>>>> +s = x264_encoder_headers(x4->enc, , );
>>>>>> +if (avctx->profile == FF_PROFILE_UNKNOWN)
>>>>>> +avctx->profile = nal->p_payload[5];
>>>>>> +if (avctx->level == FF_LEVEL_UNKNOWN)
>>>>>> +avctx->level = nal->p_payload[7];
>>>>>
>>>>>Why are these conditional?
>>>> We didn’t want to overwrite profile and level, if user had already set it.
>>>
>>>So if x264 changes these values because of contradicting user
>>>requests, we write the wrong values into the hls header?
>>
>> Yes, that is true.
>
>> We were afraid to set profile and level unconditionally, because we
>> thought it could get rejected by maintainers
>
>Very smart, you have learned quickly!
Oh yeah :) Quite a learning experience working with you folks!
>(I wish that wouldn't be the message we send to new contributors...)
>
>> (due to that comment in avcodec.h).
>
>I sent a patch.
Thanks.
>
>> Now, if you suggest us to remove those conditions, we would be
>> happy to do it.
>
>I believe other encoders already overwrite it and I believe in this
>case it would be a particularly bad idea not to overwrite it.
Sure. Will do it.

Regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: Refactor an inconsistent variable name

[Jeyapal, Karthick]

Thanks for pushing this patchset.

Regards,
Karthick

On 11/22/17, 1:43 PM, "刘歧"  wrote:


> 在 2017年11月22日，16:08，Karthick J  写道：
> 
> ---
> libavformat/hlsenc.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 525605b..611cc99 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1074,7 +1074,7 @@ static int create_master_playlist(AVFormatContext *s,
> AVDictionary *options = NULL;
> unsigned int i, j;
> int m3u8_name_size, ret, bandwidth;
> -char *m3U8_rel_name;
> +char *m3u8_rel_name;
> 
> input_vs->m3u8_created = 1;
> if (!hls->master_m3u8_created) {
> @@ -1108,14 +1108,14 @@ static int create_master_playlist(AVFormatContext *s,
> vs = &(hls->var_streams[i]);
> 
> m3u8_name_size = strlen(vs->m3u8_name) + 1;
> -m3U8_rel_name = av_malloc(m3u8_name_size);
> -if (!m3U8_rel_name) {
> +m3u8_rel_name = av_malloc(m3u8_name_size);
> +if (!m3u8_rel_name) {
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> -av_strlcpy(m3U8_rel_name, vs->m3u8_name, m3u8_name_size);
> +av_strlcpy(m3u8_rel_name, vs->m3u8_name, m3u8_name_size);
> ret = get_relative_url(hls->master_m3u8_url, vs->m3u8_name,
> -   m3U8_rel_name, m3u8_name_size);
> +   m3u8_rel_name, m3u8_name_size);
> if (ret < 0) {
> av_log(NULL, AV_LOG_ERROR, "Unable to find relative URL\n");
> goto fail;
> @@ -1145,7 +1145,7 @@ static int create_master_playlist(AVFormatContext *s,
> if (!bandwidth) {
> av_log(NULL, AV_LOG_WARNING,
> "Bandwidth info not available, set audio and video 
> bitrates\n");
> -av_freep(_rel_name);
> +av_freep(_rel_name);
> continue;
> }
> 
> @@ -1153,14 +1153,14 @@ static int create_master_playlist(AVFormatContext *s,
> if (vid_st && vid_st->codecpar->width > 0 && vid_st->codecpar->height 
> > 0)
> avio_printf(master_pb, ",RESOLUTION=%dx%d", 
> vid_st->codecpar->width,
> vid_st->codecpar->height);
> -avio_printf(master_pb, "\n%s\n\n", m3U8_rel_name);
> +avio_printf(master_pb, "\n%s\n\n", m3u8_rel_name);
> 
> -av_freep(_rel_name);
> +av_freep(_rel_name);
> }
> fail:
> if(ret >=0)
> hls->master_m3u8_created = 1;
> -av_freep(_rel_name);
> +av_freep(_rel_name);
> ff_format_io_close(s, _pb);
> return ret;
> }
> -- 
> 1.9.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

patchset LGTM



Thanks





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/avcodec: Allow libavcodec to overwrite profile and level

[Jeyapal, Karthick]

On 11/24/17, 5:17 AM, "Carl Eugen Hoyos"  wrote:

>2017-11-23 22:58 GMT+01:00 Michael Niedermayer :
>> On Thu, Nov 23, 2017 at 04:01:06PM +0100, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> The (external) encoders may overwrite level and profile because of
>>> requested encoding properties, allowing libavcodec to (also) overwrite
>>> them in the context makes sense (and is already done in some cases
>>> afaict).
>>>
>>> Please comment, Carl Eugen
>>
>> If a user needs to generate a file with a specific profile/level
>> for example because its for broadcast, some specification or a hw
>> decoder.
>> How could he after this patch ensure that exactly the needed profile
>> is used?
There is no way of ensuring the same even without this patch.

>Afair, x264 does change profile and / or level depending on properties
>set by the user. Currently there is no way for the libavcodec user to
>know that libx264 changed something.
>With this change the user can know that he does not get the
>requested values.
>
>Or am I wrong and libx264 never overwrites requested values
>for level and / or profile?
>

I just tested x264 by giving contradicting profiles and levels. 
Following are the results:
Case 1:
Input : 1080p30, 420p
Config : Set level wrongly to 1.1
Output : Throws some warnings, but level is still written wrongly as 1.1 is the 
SPS header.
Impact of overwrite : None. Both the user set value and header’s value are same.

Case 2:1080p30, 422p
Config : Set profile wrongly to baseline
Output : Throws errors, doesn’t encode
Impact of overwrite : None. 

Case 3:1080p30, 420p
Config : Set profile wrongly to high422
Output : No warnings or errors. Automatically switches to high profile. SPS 
header also has high profile.
Impact of overwrite : User will get to know the correct profile being encoded.

Regards,
Karthick



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: Added option to add EXT-X-INDEPENDENT-SEGMENTS tag

[Jeyapal, Karthick]

On 11/24/17, 4:31 AM, "Steven Liu"  wrote:

>Pushed
Thanks.
>
>
>Thanks

regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

Oops. Sorry about that. Have sent a new patch v5 that fixes this.

Regards,
Karthick

On 11/25/17, 1:31 AM, "Michael Niedermayer"  wrote:

On Fri, Nov 24, 2017 at 10:57:45AM +0530, Karthick J wrote:
> ---
>  libavformat/Makefile  |   2 +-
>  libavformat/hlsenc.c  | 115 +++
>  libavformat/hlsplaylist.c | 136 
> ++
>  libavformat/hlsplaylist.h |  51 +
>  4 files changed, 209 insertions(+), 95 deletions(-)
>  create mode 100644 libavformat/hlsplaylist.c
>  create mode 100644 libavformat/hlsplaylist.h

breaks build with mingw64

src/libavformat/hlsplaylist.c: In function ‘ff_hls_write_file_entry’:
src/libavformat/hlsplaylist.c:109:9: error: implicit declaration of function 
‘localtime_r’ [-Werror=implicit-function-declaration]
 tm = localtime_r(, );
 ^
src/libavformat/hlsplaylist.c:109:12: warning: assignment makes pointer from 
integer without a cast [enabled by default]
 tm = localtime_r(, );
^
src/libavformat/hlsplaylist.c:113:13: error: implicit declaration of function 
‘gmtime_r’ [-Werror=implicit-function-declaration]
 tm = gmtime_r(, );
 ^
src/libavformat/hlsplaylist.c:113:16: warning: assignment makes pointer from 
integer without a cast [enabled by default]
 tm = gmtime_r(, );
^
cc1: some warnings being treated as errors

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

>On 11/22/17, 2:18 PM, "Hendrik Leppkes" <h.lepp...@gmail.com> wrote:

>>On Wed, Nov 22, 2017 at 9:35 AM, Jeyapal, Karthick <kjeya...@akamai.com> 
>>wrote:
>>>On 11/22/17, 1:47 PM, "刘歧" <l...@chinaffmpeg.org> wrote:
[…]
>>> move the APIs to an C source file, and use ff_ prefix, refer to: 
>>> https://ffmpeg.org/developer.html#toc-Naming-conventions
>> Thanks for the reply.
>> I am not adding it to the API or a global function.
>> Those are just ‘static’ utility functions, to allow code reuse.
>> The scope will be limited only to those files including hlsenc.h.
>> Developer guide states “For file-scope variables and functions declared as 
>> static, no prefix is required”.
>> For example, oggdec.h has two static functions without ff_ prefix.
>>
>
>Regardless, having a bunch of complex functions in a header is not the
>preferred way (because their code gets duplicated), its usually
>reserved for extremely simple functions or special cases. Instead, put
>them into a .c file and give them the ff_ prefix, like most common
>shared code we use.
Thanks for the clarification. 
I have uploaded newer patch set v2 with those functions in .c file 
>
>- Hendrik

regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

>On 11/22/17, 1:47 PM, "刘歧"  wrote:
>
>> 在 2017年11月22日，14:53，Karthick J  写道：
>> 
>> ---
>> libavformat/hlsenc.c | 130 +++---
>> libavformat/hlsenc.h | 158 
>> +++
>> 2 files changed, 177 insertions(+), 111 deletions(-)
>> create mode 100644 libavformat/hlsenc.h
>> 
[…]
> move the APIs to an C source file, and use ff_ prefix, refer to: 
> https://ffmpeg.org/developer.html#toc-Naming-conventions
Thanks for the reply.
I am not adding it to the API or a global function. 
Those are just ‘static’ utility functions, to allow code reuse. 
The scope will be limited only to those files including hlsenc.h. 
Developer guide states “For file-scope variables and functions declared as 
static, no prefix is required”.
For example, oggdec.h has two static functions without ff_ prefix.

Regards,
Karthick






___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

>On 11/22/17, 9:32 AM, "刘歧"  wrote:
>
>This patch is ok, but i see it need an API: ffio_geturlcontext
>
>it in the other patch, i see it have some thing need talk? If that is ok, this 
>patch should be apply.
Thanks for the reply. 
All concerns raised by Nicolas has been addressed in this latest patch set.
Let us wait for few days to check if anyone still has any objections.
>
>Thanks

regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Option to generate hls playlist as well

[Jeyapal, Karthick]

On 11/22/17, 9:06 PM, "Michael Niedermayer"  wrote:

>On Wed, Nov 22, 2017 at 02:50:12PM +0530, Karthick J wrote:
>>  
>> +static void get_hls_playlist_name(char *playlist_name, const char 
>> *base_url, int id) {
>> +if (base_url)
>> +sprintf(playlist_name, "%smedia_%d.m3u8", base_url, id);
>> +else
>> +sprintf(playlist_name, "media_%d.m3u8", id);
>> +}

>please always use snprint, not sprintf as it can overwrite the array
Thanks for the comments. I have uploaded a new patch(v3) with snprintf.

>[...]
>-- 
>Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>Everything should be made as simple as possible, but not simpler.
>-- Albert Einstein

regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Added option to add EXT-X-INDEPENDENT-SEGMENTS tag

[Jeyapal, Karthick]

On 11/23/17, 4:13 PM, "Carl Eugen Hoyos"  wrote:
>
>2017-11-23 6:05 GMT+01:00 Karthick J :
>
>> +if (hls->flags & HLS_SPLIT_BY_TIME) {
>> +// Independent segments cannot be guaranteed when splitting by time
>> +hls->flags &= ~HLS_INDEPENDENT_SEGMENTS;
>
>Shouldn't this show a warning?
Thanks for your comments.
I have added the warning in the new patch v2 as you have rightly suggested.
>
>Carl Eugen

regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

[Jeyapal, Karthick]

>From: Aman Gupta 

>On Wed, Nov 22, 2017 at 7:38 PM  wrote:
>>From: Vishwanath Dixit 
>>
>>Signed-off-by: Karthick J 
>
>LGTM.
>
>Have you looked at adding HEVC support?

Thanks for the reply. 
From our side, there are no immediate plans to add HEVC support.
But after this patch, it should be very simple to add the same.

Regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: Added option to add EXT-X-INDEPENDENT-SEGMENTS tag

[Jeyapal, Karthick]

On 11/23/17, 4:56 PM, "Carl Eugen Hoyos"  wrote:
>
>2017-11-23 12:21 GMT+01:00 Karthick J :
>
>> +if (hls->flags & HLS_SPLIT_BY_TIME) {
>> +// Independent segments cannot be guaranteed when splitting by time
>> +hls->flags &= ~HLS_INDEPENDENT_SEGMENTS;
>> +av_log(s, AV_LOG_WARNING,
>> +   "'split_by_time' and 'independent_segments' cannot be 
>> enabled together. "
>> +   "Disabling 'independent_segments' flag\n");
>> +}
>
>I did not read the code (so this comment may be wrong) but I would
>have expected "if (flags & BY_TIME && flags & INDEPENDENT)".
Oops. My mistake. Have corrected it in PATCH v3.
>
>Carl Eugen

regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/libx264:setting profile and level in avcodec context

[Jeyapal, Karthick]

On 11/23/17, 4:21 PM, "Carl Eugen Hoyos"  wrote:

>2017-11-23 4:37 GMT+01:00  :
>
>> +s = x264_encoder_headers(x4->enc, , );
>> +if (avctx->profile == FF_PROFILE_UNKNOWN)
>> +avctx->profile = nal->p_payload[5];
>> +if (avctx->level == FF_LEVEL_UNKNOWN)
>> +avctx->level = nal->p_payload[7];
>
>Why are these conditional?
We didn’t want to overwrite profile and level, if user had already set it.
Comments in avcodec.h mentioned, ‘encoding: Set by user’, for profile and level.
>
>(Do we really guarantee that our profile and level
>fields contain the exact same values as the nal
>payload?)
There is no guarantee. 
But instead of unknown profile and level, setting profile and level whenever 
possible could enhance feature-set of certain muxers, like hlsenc.
>
>Carl Eugen

regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/libx264:setting profile and level in avcodec context

[Jeyapal, Karthick]

On 11/23/17, 5:33 PM, "Carl Eugen Hoyos" <ceffm...@gmail.com> wrote:

>2017-11-23 12:47 GMT+01:00 Jeyapal, Karthick <kjeya...@akamai.com>:
>> On 11/23/17, 4:21 PM, "Carl Eugen Hoyos" <ceffm...@gmail.com> wrote:
>>
>>>2017-11-23 4:37 GMT+01:00  <vdi...@akamai.com>:
>>
>>>> +s = x264_encoder_headers(x4->enc, , );
>>>> +if (avctx->profile == FF_PROFILE_UNKNOWN)
>>>> +avctx->profile = nal->p_payload[5];
>>>> +if (avctx->level == FF_LEVEL_UNKNOWN)
>>>> +avctx->level = nal->p_payload[7];
>>>
>>>Why are these conditional?
>> We didn’t want to overwrite profile and level, if user had already set it.
>
>So if x264 changes these values because of contradicting user
>requests, we write the wrong values into the hls header?

Yes, that is true. 
We were afraid to set profile and level unconditionally, because we thought it 
could get rejected by maintainers(due to that comment in avcodec.h).
Now, if you suggest us to remove those conditions, we would be happy to do it. 
Please advise.

Thanks and regards,
Karthick



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

On 11/29/17, 12:04 PM, "刘歧"  wrote:


>Patchset pushed!
Thanks a lot!

Regards,
Karthick
>
>
>Thanks



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

On 11/24/17, 3:49 PM, "Jeyapal, Karthick" <kjeya...@akamai.com> wrote:
>
>On 11/24/17, 3:40 PM, "刘歧" <l...@chinaffmpeg.org> wrote:
>
>>> 在 2017年11月24日，18:02，Jeyapal, Karthick <kjeya...@akamai.com> 写道：
>>> 
>>> On 11/22/17, 1:27 PM, "Jeyapal, Karthick" <kjeya...@akamai.com> wrote:
>>> 
>>>>> On 11/22/17, 9:32 AM, "刘歧" <l...@chinaffmpeg.org> wrote:
>>>>> 
>>>>> This patch is ok, but i see it need an API: ffio_geturlcontext
>>>>> 
>>>>> it in the other patch, i see it have some thing need talk? If that is ok, 
>>>>> this patch should be apply.
>>Is this ok?
>Yes, ffio_geturlcontext has already been accepted by Nicolas.
>http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220014.html
>He had concerns on calling prot->url_write directly from hlsenc, which has 
>been removed on new patchset(v2).
>Also av_assert0 has been added as suggested by him
A gentle reminder. 
7 days have gone by since the last version of this patchset was submitted. And 
no objections so far.
Could this patchset be pushed, please? Thanks.
>>
>>Thanks
>>>> Thanks for the reply. 
>>>> All concerns raised by Nicolas has been addressed in this latest patch set.
>>>> Let us wait for few days to check if anyone still has any objections.
>>> Looks like nobody has anymore objections to this patchset. 
>>> Well, it has already passed through multiple rounds of reviews.
>>> Could somebody please push this to the master. 
>>> I have few more patches waiting to be submitted, dependent on this feature.



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

On 11/29/17, 11:41 AM, "刘歧" <l...@chinaffmpeg.org> wrote:

>> 在 2017年11月29日，12:05，Jeyapal, Karthick <kjeya...@akamai.com> 写道：
>> 
>> A gentle reminder. 
>> 7 days have gone by since the last version of this patchset was submitted. 
>> And no objections so far.
>> Could this patchset be pushed, please? Thanks.
>Can you resubmit a new version of this patchiest, There have too many version 
>and ignore version patches.

Thanks for the reply. 
I have resent the patches as new version v3 for the sake of clarity.

>Thanks

regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

On 11/25/17, 9:16 AM, "Karthick J"  wrote:

>---
> libavformat/Makefile  |   2 +-
> libavformat/hlsenc.c  | 115 +++---
> libavformat/hlsplaylist.c | 138 ++
> libavformat/hlsplaylist.h |  51 +
> 4 files changed, 211 insertions(+), 95 deletions(-)
> create mode 100644 libavformat/hlsplaylist.c
> create mode 100644 libavformat/hlsplaylist.h
[…]
This patch(v5) does not apply on latest master (merge conflicts).
Have rebased and sent a new patch v6.
-- 
1.9.1



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

On 11/29/17, 5:16 PM, "刘歧"  wrote:
>
>Where can i find the v6 2/2 ?
Patch 2/2 didn’t change since v4. 
So didn’t repost it. You have to use v4 2/2.

I am sorry. I was not sure what is the normal practice here. I didn’t repost 
it, so that the people don’t waste time in re-reviewing it.
Is it customary to repost the all patches(even if unchanged) in a patchset, 
when posting new versions of a particular patch?
Please advise. I will follow accordingly from next time onwards. 

Thanks and regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Option to generate hls playlist as well

[Jeyapal, Karthick]

Please ignore the below patch and use v2.
Sorry for the inconvenience. 

Regards,
Karthick

On 11/29/17, 8:47 PM, "Karthick J"  wrote:

This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
 doc/muxers.texi   |   3 ++
 libavformat/Makefile  |   2 +-
 libavformat/dashenc.c | 103 --
 3 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 8ec48c2..3d0c7bf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. Default 
is "chunk-stream$Rep
 URL of the page that will return the UTC timestamp in ISO format. Example: 
"https://time.akamai.com/?iso;
 @item -http_user_agent @var{user_agent}
 Override User-Agent field in HTTP header. Applicable only for HTTP output.
+@item -hls_playlist @var{hls_playlist}
+Generate HLS playlist files as well. The master playlist is generated with the 
filename master.m3u8.
+One media playlist file is generated for each stream with filenames 
media_0.m3u8, media_1.m3u8, etc.
 @item -adaptation_sets @var{adaptation_sets}
 Assign streams to AdaptationSets. Syntax is "id=x,streams=a,b,c 
id=y,streams=d,e" with x and y being the IDs
 of the adaptation sets and a,b,c,d and e are the indices of the mapped streams.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index fd8b9f9..4bffdf2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -135,7 +135,7 @@ OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
 OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
-OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
+OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o hlsplaylist.o
 OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
 OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0fee3cd..efc2012 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -36,6 +36,7 @@
 #include "avc.h"
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsplaylist.h"
 #include "internal.h"
 #include "isom.h"
 #include "os_support.h"
@@ -101,6 +102,8 @@ typedef struct DASHContext {
 const char *media_seg_name;
 const char *utc_timing_url;
 const char *user_agent;
+int hls_playlist;
+int master_playlist_created;
 } DASHContext;
 
 static struct codec_string {
@@ -217,6 +220,14 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 }
 
+static void get_hls_playlist_name(char *playlist_name, int string_size,
+  const char *base_url, int id) {
+if (base_url)
+snprintf(playlist_name, string_size, "%smedia_%d.m3u8", base_url, id);
+else
+snprintf(playlist_name, string_size, "media_%d.m3u8", id);
+}
+
 static int flush_init_segment(AVFormatContext *s, OutputStream *os)
 {
 DASHContext *c = s->priv_data;
@@ -262,7 +273,8 @@ static void dash_free(AVFormatContext *s)
 av_freep(>streams);
 }
 
-static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c)
+static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c,
+int representation_id, int final)
 {
 int i, start_index = 0, start_number = 1;
 if (c->window_size) {
@@ -322,6 +334,55 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 }
 avio_printf(out, "\t\t\t\t\n");
 }
+if (c->hls_playlist && start_index < os->nb_segments)
+{
+int timescale = os->ctx->streams[0]->time_base.den;
+char temp_filename_hls[1024];
+char filename_hls[1024];
+AVIOContext *out_hls = NULL;
+AVDictionary *http_opts = NULL;
+int target_duration = 0;
+const char *proto = avio_find_protocol_name(c->dirname);
+int use_rename = proto && !strcmp(proto, "file");
+
+get_hls_playlist_name(filename_hls, sizeof(filename_hls),
+  c->dirname, representation_id);
+
+snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
+
+set_http_options(_opts, c);
+avio_open2(_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
_opts);
+av_dict_free(_opts);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+double duration = (double) seg->duration / timescale;
+if (target_duration <= duration)
+target_duration = hls_get_int_from_double(duration);
+}
+
+

Re: [FFmpeg-devel] [PATCH v6 2/2] avformat/dashenc: Option to generate hls playlist as well

[Jeyapal, Karthick]

On 11/29/17, 7:43 PM, "Steven Liu"  wrote:

>> +target_duration = lrint((double) target_duration / timescale);
>What value will set when the target_duration is 1.023 ? I think we
>have talk about the value and the specification describe the standard
>process way.
>You can move the function get_int_from_double to the common file and use that.

Thanks for reminding me. I have corrected it and sent a fresh patchset as you 
suggested.
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221317.html

regards,
Karthick 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/hlsenc: Refactored 'get_int_from_double' function to allow reuse

[Jeyapal, Karthick]

On 11/30/17, 8:47 AM, "Steven Liu"  wrote:
[..]
>Patchset pushed
Thanks.

>
>
>Thanks

regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

[Jeyapal, Karthick]

>On 12/14/17, 8:24 PM, "Steven Liu"  wrote:
>
>
>> 在 2017年12月14日，下午6:55，vdi...@akamai.com 写道：
>> […] 
>> +libavformat/reverse.c
>
>this need double check for a better way
The better way of doing this is to share ff_reverse function.
But such a patch submitted recently was not pushed due to several objections. 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221472.html
Hence, we are left with only this option. Moreover like same approach was used 
for avcodec and avdevice(to add reverse.c), as well. So, extending the same 
approach for avformat shouldn’t deviate from ffmpeg’s principles.

Regards,
Karthick
>
>[…]
>Thanks
>
>
>Steven



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 3/3] avformat/hlsenc:addition of CODECS attribute in the master playlist

[Jeyapal, Karthick]

>On 12/15/17, 4:45 AM, "Liu Steven" <l...@chinaffmpeg.org> wrote:
>
>
>> 在 2017年12月15日，上午6:28，Liu Steven <l...@chinaffmpeg.org> 写道：
>> 
>>> 
>>> 在 2017年12月15日，上午12:29，Jeyapal, Karthick <kjeya...@akamai.com> 写道：
>>> 
>>>> On 12/14/17, 8:24 PM, "Steven Liu" <l...@chinaffmpeg.org> wrote:
>>>> 
>>>> 
>>>>> 在 2017年12月14日，下午6:55，vdi...@akamai.com 写道：
>>>>> […] 
>>>>> +libavformat/reverse.c
>>>> 
>>>> this need double check for a better way
>>> The better way of doing this is to share ff_reverse function.
>> No I don’t think that is a better way here.
>>> But such a patch submitted recently was not pushed due to several 
>>> objections. 
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221472.html
>>> Hence, we are left with only this option. Moreover like same approach was 
>>> used for avcodec and avdevice(to add reverse.c), as well. So, extending the 
>>> same approach for avformat shouldn’t deviate from ffmpeg’s principles.
>> I think there have better way, Please don’t define the ffmpeg’s principles 
>> to every place. you are duplicate the code from libavcodec//reverse.c to 
>> libavformat, IMHO, that is not a good option.
>I need some time to think about that.
Oh sure. Thanks. 
In that case, could you please merge PATCH v6 1/3 alone, since that is a 
relatively independent feature.
>
>Thanks
>
>Steven
>> 
>> Thanks
>> 
>> Steven
>>> 
>>> Regards,
>>> Karthick
>>> 
>>> […]
>>> Thanks
>>> 
>>> 
>>> Steven





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/5] avformat/http: ff_http_do_new_request() returns EINVAL if re-used with different hostname

[Jeyapal, Karthick]

>On 12/13/17, 6:05 AM, "Aman Gupta" ffm...@tmm1.net> wrote:
>
>From: Aman Gupta 
>
>This will prevent improper use of ff_http_do_new_request() if the user
>tries to send a request for a different host to a previously connected
>persistent http/1.1 connection.
>---
> libavformat/http.c | 16 
> 1 file changed, 16 insertions(+)
>
>diff --git a/libavformat/http.c b/libavformat/http.c
>index cf86adc617..a3c36423fc 100644
>--- a/libavformat/http.c
>+++ b/libavformat/http.c
>@@ -306,6 +306,22 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
> HTTPContext *s = h->priv_data;
> AVDictionary *options = NULL;
> int ret;
>+char hostname1[1024], hostname2[1024], proto1[10], proto2[10];
>+int port1, port2;
>+
>+av_url_split(proto1, sizeof(proto1), NULL, 0,
>+ hostname1, sizeof(hostname1), ,
>+ NULL, 0, s->location);
>+av_url_split(proto2, sizeof(proto2), NULL, 0,
>+ hostname2, sizeof(hostname2), ,
>+ NULL, 0, uri);
>+if (port1 != port2 || strncmp(hostname1, hostname2, sizeof(hostname2)) != 
>0) {
>+av_log(h, AV_LOG_ERROR, "Cannot reuse HTTP connection for different 
>host: %s:%d != %s:%d\n",
>+hostname1, port1,
>+hostname2, port2
>+);
>+return AVERROR(EINVAL);
>+}
Nice check!
It will prevent some bad server side errors/crashes, due to any misuse.
> 
> ret = http_shutdown(h, h->flags);
> if (ret < 0)
>-- 
>2.14.3 (Apple Git-98)



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

[Jeyapal, Karthick]

>On 11/16/17, 4:43 PM, "Nicolas George"  wrote:

Thanks for the reply.

>I think that would work, thanks.
>
>But I see that in the other patches you call ffio_geturlcontext()
>without checking its return value. That is not good at all, and that
>would make Coverity squirm.
>
>If you are sure that you are always calling it with a real URLContext,
>then make the test an av_assert0(). I think it is the case. Otherwise,
>you need to check the return value.

I have done the change as suggested. Please find the new patch attached.

>Also, I see the other patch calling prot->url_write directly: I think it
>should call ffurl_write() instead.

I need to send ‘0’ byte http packet to indicate close.
But ffurl_write doesn’t call http_write for a 0 byte packet.
Hence, I am calling prot->url_write directly. 

>Regards,
>
>-- 
>  Nicolas George

Regards,
Karthick



0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
Description: 0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/tcp: enable TCP_NODELAY by default

[Jeyapal, Karthick]

>On 11/14/17, 2:47 AM, "Aman Gupta"  wrote:
>
>>On Mon, Nov 13, 2017 at 12:37 PM, Nicolas George  wrote:
>>
>> Why?
>>
>
>To potentially reduce latency, particularly when using a protocol that
>builds on top of tcp like http.
Yes. Apart from the latency, overall throughput could also
increase in a high latency network with TCP_NODELAY
>
>I can disable this option by default if that makes the patch more
>palatable. That would preserve the existing behavior, and let users enable
>the option if they decide Nagle's algorithm is not a good fit for their use
>case.
I think, it is safer to set default as disable. We should modify its callers 
like 
http or hls etc., to enable this option as per the use-case. 
>
>Aman
>
>
>>
>> Regards,
>>
>> --
>>   Nicolas George
>>


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/dashenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

>On 11/20/17, 1:01 PM, "刘歧"  wrote:
>> 在 2017年11月8日，17:22，Karthick J  写道：
>> +{ "http_user_agent", "override User-Agent field in HTTP header", 
>> OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>What about dash_user_agent？ The reason is http_user_agent maybe get mean HTTP 
>Protocol user_agent, but this is used in dashenc.

I kept http_user_agent to maintain uniformity with hlsenc option. 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215642.html

In that way, irrespective of hls or dash output format, http_user_agent would 
apply for both.

Regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Jeyapal, Karthick]

>On 11/20/17, 12:39 AM, "Marton Balint"  wrote:

>Thanks, there is one more thing I still don't get:

[...]
>> +// 1 second timeout
>> +for (i = 0; i < 10; i++) {
>> +av_usleep(10);
>> +// Sometimes VideoInputFrameArrived is called before 
>> VideoInputFormatChanged
>> +// So don't break for bmd_mode == AUTODETECT_DEFAULT_MODE

>Even if you get a frame for the default mode, and 
>VideoInputFrameArrived is called early, the bmdFrameHasNoInputSource 
>flag should be set, so ctx->bmd_mode remains unknown, therefore you don't 
>have to handle it specially.
>
>Are you saying that the Decklink drivers are buggy, and there are cases 
>where you get a frame without the bmdFrameHasNoInputSource flag, and then 
>a VideoInputFormatChanged callback later?

Yes, there are cases where you get a frame without the bmdFrameHasNoInputSource
flag, and then a VideoInputFormatChanged called later. And it is random.
But I don’t know if it could be called as a driver bug, since the getWidth and 
getHeight would return the correct values.
During my testing, I observed a 1080p30 would randomly get detected as,
AUTODETECT_DEFAULT_MODE because of VideoInputFrameArrived called early.
Hence I added that extra condition to handle it specially.

>> +if (ctx->bmd_mode != bmdModeUnknown &&
>> +ctx->bmd_mode != AUTODETECT_DEFAULT_MODE)
>> +break;
>> +}
>> +

[...]

>Regards,
>Marton

regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

[Jeyapal, Karthick]

>On 11/17/17, 4:31 PM, "Nicolas George" <geo...@nsup.org> wrote:
>
>Le sextidi 26 brumaire, an CCXXVI, Jeyapal, Karthick a écrit :
>> I have done the change as suggested. Please find the new patch attached.
>
>Sorry, but I still have doubts about it.
>
>To begin with, -1 is not an acceptable error code.
>
>But what bothers me most is that on the two uses, one has an assert, the
>other has an error return, the inconsistency looks suspicious.
>
>I think, at least, it should include a comment at both places to
>indicate why the test is done like that.
>
>> I need to send ‘0’ byte http packet to indicate close.
>> But ffurl_write doesn’t call http_write for a 0 byte packet.
>> Hence, I am calling prot->url_write directly. 
>
>Let me see if I understand correctly: are you saying that it is not
>possible to perform multiple requests using only public APIs? I find it
>suspicious, since multiple_requests is a public option. If that is true,
>then it needs fixing.

Thanks for your reply. I have sent a new patch set v2 addressing your concerns.
Yes, http multiple_requests option is not working as expected. 
Few days back a fix was done for read 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219746.html
As per your suggestion, I have added fix to the public api of http for write.
Now hlsenc does not call prot->url_write directly in this new patch set.

Thanks and regards,
Karthick



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/3] libavformat/http: Handled multiple_requests option during write

[Jeyapal, Karthick]

Please ignore the below patch, and use the updated patch attached. 
Forgot to reset the end_chunked_post variable in the below patch.
Sorry for the inconvenience caused.

Regards,
Karthick

On 11/21/17, 10:24 AM, "Karthick J"  wrote:

---
 libavformat/http.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 056d5f6..45c0e72 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -171,6 +171,7 @@ static int http_connect(URLContext *h, const char *path, 
const char *local_path,
 const char *hoststr, const char *auth,
 const char *proxyauth, int *new_location);
 static int http_read_header(URLContext *h, int *new_location);
+static int http_shutdown(URLContext *h, int flags);
 
 void ff_http_init_auth_state(URLContext *dest, const URLContext *src)
 {
@@ -306,6 +307,10 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
 AVDictionary *options = NULL;
 int ret;
 
+ret = http_shutdown(h, h->flags);
+if (ret < 0)
+return ret;
+
 s->chunkend  = 0;
 s->off   = 0;
 s->icy_data_read = 0;
-- 
1.9.1





0002-libavformat-http-Handled-multiple_requests-option-du.patch
Description: 0002-libavformat-http-Handled-multiple_requests-option-du.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avformat/dashenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

Looks like nobody has any objection for the below patch. Can somebody please 
push this.

Regards,
Karthick

On 11/8/17, 2:53 PM, "Karthick J"  wrote:

---
 doc/muxers.texi   |  2 ++
 libavformat/dashenc.c | 22 +++---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 91bbe67..412fede 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -247,6 +247,8 @@ DASH-templated name to used for the initialization segment. 
Default is "init-str
 DASH-templated name to used for the media segments. Default is 
"chunk-stream$RepresentationID$-$Number%05d$.m4s"
 @item -utc_timing_url @var{utc_url}
 URL of the page that will return the UTC timestamp in ISO format. Example: 
"https://time.akamai.com/?iso;
+@item -http_user_agent @var{user_agent}
+Override User-Agent field in HTTP header. Applicable only for HTTP output.
 @item -adaptation_sets @var{adaptation_sets}
 Assign streams to AdaptationSets. Syntax is "id=x,streams=a,b,c 
id=y,streams=d,e" with x and y being the IDs
 of the adaptation sets and a,b,c,d and e are the indices of the mapped streams.
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 7813f44..a68f7fb 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -100,6 +100,7 @@ typedef struct DASHContext {
 const char *init_seg_name;
 const char *media_seg_name;
 const char *utc_timing_url;
+const char *user_agent;
 } DASHContext;
 
 static struct codec_string {
@@ -210,6 +211,12 @@ static int flush_dynbuf(OutputStream *os, int 
*range_length)
 return avio_open_dyn_buf(>ctx->pb);
 }
 
+static void set_http_options(AVDictionary **options, DASHContext *c)
+{
+if (c->user_agent)
+av_dict_set(options, "user_agent", c->user_agent, 0);
+}
+
 static int flush_init_segment(AVFormatContext *s, OutputStream *os)
 {
 DASHContext *c = s->priv_data;
@@ -575,16 +582,19 @@ static int write_manifest(AVFormatContext *s, int final)
 int use_rename = proto && !strcmp(proto, "file");
 static unsigned int warned_non_file = 0;
 AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
+AVDictionary *opts = NULL;
 
 if (!use_rename && !warned_non_file++)
 av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
may lead to races and temporary partial files\n");
 
 snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
"%s", s->filename);
-ret = s->io_open(s, , temp_filename, AVIO_FLAG_WRITE, NULL);
+set_http_options(, c);
+ret = s->io_open(s, , temp_filename, AVIO_FLAG_WRITE, );
 if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n", 
temp_filename);
 return ret;
 }
+av_dict_free();
 avio_printf(out, "\n");
 avio_printf(out, "http://www.w3.org/2001/XMLSchema-instance\"\n;
 "\txmlns=\"urn:mpeg:dash:schema:mpd:2011\"\n"
@@ -768,9 +778,11 @@ static int dash_init(AVFormatContext *s)
 ff_dash_fill_tmpl_params(os->initfile, sizeof(os->initfile), 
c->init_seg_name, i, 0, os->bit_rate, 0);
 }
 snprintf(filename, sizeof(filename), "%s%s", c->dirname, os->initfile);
-ret = s->io_open(s, >out, filename, AVIO_FLAG_WRITE, NULL);
+set_http_options(, c);
+ret = s->io_open(s, >out, filename, AVIO_FLAG_WRITE, );
 if (ret < 0)
 return ret;
+av_dict_free();
 os->init_start_pos = 0;
 
 if (!strcmp(os->format_name, "mp4")) {
@@ -974,12 +986,15 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 }
 
 if (!c->single_file) {
+AVDictionary *opts = NULL;
 ff_dash_fill_tmpl_params(filename, sizeof(filename), 
c->media_seg_name, i, os->segment_index, os->bit_rate, os->start_pts);
 snprintf(full_path, sizeof(full_path), "%s%s", c->dirname, 
filename);
 snprintf(temp_path, sizeof(temp_path), use_rename ? "%s.tmp" : 
"%s", full_path);
-ret = s->io_open(s, >out, temp_path, AVIO_FLAG_WRITE, NULL);
+set_http_options(, c);
+ret = s->io_open(s, >out, temp_path, AVIO_FLAG_WRITE, );
 if (ret < 0)
 break;
+av_dict_free();
 if (!strcmp(os->format_name, "mp4"))
 write_styp(os->ctx->pb);
 } else {
@@ -1188,6 +1203,7 @@ static const AVOption options[] = {
 { "init_seg_name", "DASH-templated name to used for the initialization 
segment", OFFSET(init_seg_name), AV_OPT_TYPE_STRING, {.str = 
"init-stream$RepresentationID$.m4s"}, 0, 0, E },
 { "media_seg_name", "DASH-templated name to used for the media segments", 
OFFSET(media_seg_name), AV_OPT_TYPE_STRING, {.str = 
"chunk-stream$RepresentationID$-$Number%05d$.m4s"}, 0, 0, E },
 { "utc_timing_url", "URL of the page that will return the UTC timestamp in 
ISO format", OFFSET(utc_timing_url), AV_OPT_TYPE_STRING, { 0 }, 0, 

Re: [FFmpeg-devel] [PATCH 1/1] avformat/dashenc: Added configuration to override HTTP User-Agent

[Jeyapal, Karthick]

>On 11/20/17, 1:47 PM, "刘歧" <l...@chinaffmpeg.org> wrote:


>> 在 2017年11月20日，15:59，Jeyapal, Karthick <kjeya...@akamai.com> 写道：
>> 
>>> On 11/20/17, 1:01 PM, "刘歧" <l...@chinaffmpeg.org> wrote:
>>>> 在 2017年11月8日，17:22，Karthick J <kjeya...@akamai.com> 写道：
>>>> +{ "http_user_agent", "override User-Agent field in HTTP header", 
>>>> OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>>> What about dash_user_agent？ The reason is http_user_agent maybe get mean 
>>> HTTP Protocol user_agent, but this is used in dashenc.
>> 
>> I kept http_user_agent to maintain uniformity with hlsenc option. 
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215642.html
>> 
>> In that way, irrespective of hls or dash output format, http_user_agent 
>> would apply for both.
>that should modify to hls_user_agent too. because that is clarified the option 
>is used in dash or hls, isn’t it?

Sure. I am ok with dash_user_agent as well. 
I have attached a new patch with the option renamed to dash_user_agent.

Thanks and regards,
Karthick






0001-avformat-dashenc-Added-configuration-to-override-HTT.patch
Description: 0001-avformat-dashenc-Added-configuration-to-override-HTT.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Jeyapal, Karthick]

>On 11/22/17, 5:06 AM, "Marton Balint"  wrote:
>
>Ok, applied the series with some minor whitespace/comment fixes.
Great! Thanks.
>
>Thanks,
>Marton

Regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

>On 11/21/17, 8:24 PM, "Steven Liu"  wrote:
>
[…]
>> +if (*pb == NULL || !http_base_proto || !hls->http_persistent) {
>What about !*pb ?

Thanks for your comments. 
I have modified the patch as per your suggestion and have attached the same.

Regards,
Karthick




0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
Description: 0003-libavformat-hlsenc-Persistent-HTTP-connections-suppo.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Jeyapal, Karthick]

>On 11/16/17, 1:11 AM, "Marton Balint"  wrote:

Thanks for the reply.

>For the first patch, I think you forgot to call ff_decklink_set_configs in 
>decklink_enc.
ff_decklink_set_configs is not doing anything related to decklink_enc
In any case I have added the same and have attached the new patch

>For the second patch here are some comments:
I have done all suggested modifications and the new patch is attached.

>Regards,
>Marton

Regards,
Karthick



0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch
Description: 0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch


0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
Description: 0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

[Jeyapal, Karthick]

>On 11/15/17, 6:34 PM, "Nicolas George"  wrote:

>This is rather fragile. Some kind of check that is is actually a real
>URLContext would be a very good idea.

Thanks for the feedback. I have a relevant condition check so that
only a real URLContext is returned.
Please find the new patch attached.

Regards,
Karthick

>Regards,
>
>-- 
>  Nicolas George




0001-libavformat-avio-Utility-function-to-return-URLConte.patch
Description: 0001-libavformat-avio-Utility-function-to-return-URLConte.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

[Jeyapal, Karthick]

>Hmm, I guess if we want this to propagate down we need to add the option to 
>the tls protocol as well, then pass it down when it instantiates the tcp 
>protocol. Then add the same option to hls/dash, and again propagate it >down 
>to tls or tcp.
>
>This is turning into a much bigger change than I anticipated, and I don't 
>really care enough about it to continue. If someone else wants to take over 
>this patchset, they are more than welcome to it.
>
>Aman

Well, I would suggest you could push the first tcp patch and leave the http/tls 
patch for somebody else to take it up later.

Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: Utility function to return URLContext

[Jeyapal, Karthick]

>>On Tue, Nov 7, 2017 at 2:34 AM Karthick J  wrote:
>>---
>> libavformat/avio_internal.h | 8 
>> libavformat/aviobuf.c       | 8 
>> 2 files changed, 16 insertions(+)
>
>LGTM. This would make my hls demuxer keepalive patch simpler as well.
>
>I know there were some concerns earlier about exposing URLContext, but since 
>this is internal I think it should be okay.
>
>Any objections?
>
>Aman

Well more than a week has passed by. It looks like there are no objections from 
anyone. 
If that is the case, could somebody push this patchset to mainline. I don’t 
have push permissions.

Regards,
Karthick



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] libavformat/tcp: Added an option to reuse sockets

[Jeyapal, Karthick]

>On 11/3/17, 2:18 PM, "Nicolas George"  wrote:

>I strongly oppose this: we do not want new global state.
I also agree. I am open to suggestions, and I would be happy re-implement this 
feature without new global state.

>Also, I am very doubtful about the feature itself. It is public, and as
>such should be usable for many uses, but I do not see it useful for
>anything but patches 3 and 4. 
Well beyond patch 3 and 4, this feature is usable for HLS player, DASH player 
and DASH encoder. 
Any other segmented streaming standard would also benefit from this feature.
With internet streaming having moved towards segmented streaming standards, I 
would think this feature is very useful.
Right now, the performance of hlsenc, dashenc etc., suffers terribly for http 
output with lower segment sizes.
Also, this feature could be extended for HTTPS/TLS connections as well.

>Furthermore, it is a break of abstraction,
>sockets lose their simple and clear API, they are not really closed when
>they are closed, etc.
Technically it doesn’t break any abstraction. Internally reusing socket 
connections,
could be thought of as an implementation level detail to improve performance. 
For example, android HTTP APIs reuse the sockets internally to improve 
performance
without affecting the abstraction.
https://developer.android.com/reference/java/net/HttpURLConnection.html
 
>If you are trying to implement keepalive HTTP for HLS, then most of the
>code should be in http.c and hls*.c, not tcp.c.
That’s a very good point. I had also thought in similar lines. Here is an 
approach that I could think of. 
- Open just one http connection from hlsenc.c
- Somehow call http_shutdown instead of http_close during end of segments/file
- For opening a new segment/file hlsenc calls http_write (with relevant http 
headers 
composed by hlsenc) instead of a fresh http_open
If ffmpeg maintainers agree to the above approach, I am willing to implement it 
that way. 

Or if anybody proposes a better approach, I am willing to consider that as well.

>Regards,
>
>-- 
>  Nicolas George


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] libavformat/tcp: Added an option to reuse sockets

[Jeyapal, Karthick]

>On 11/3/17, 9:44 PM, "Aman Gupta"  wrote:
>
>I recently implemented keepalive support in the hls demuxer, and have been
>using it with a lot of success. See my patchset:
>http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217353.html
>
>Aman

Thanks a lot for your excellent suggestion. 
I was not aware of the global function ff_http_do_new_request.
Now I will attempt to re-implement this feature along similar lines of your 
patch.

Regards,
Karthick 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Jeyapal, Karthick]

>On 11/6/17, 6:19 AM, "Marton Balint" <c...@passwd.hu> wrote:
>
>>On Fri, 27 Oct 2017, Jeyapal, Karthick wrote:
>
>> Please find the patch attached.
>>
>
>Thanks, below some comments:

Thanks a lot for your detailed comments. I have incorporated all your comments 
in this new patch(es).
Also, I have split it as two patches as you suggested. Please find them 
attached.

Regards,
Karthick




0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch
Description: 0001-libavdevice-decklink-Refactored-ff_decklink_set_form.patch


0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
Description: 0002-libavdevice-decklink_dec-Autodetect-the-video-input-.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] libavformat/tcp: Added an option to reuse sockets

[Jeyapal, Karthick]

>On 11/7/17, 10:45 AM, "Jeyapal, Karthick" <kjeya...@akamai.com> wrote:
>
>>On 11/3/17, 9:44 PM, "Aman Gupta" <ffm...@tmm1.net> wrote:
>>
>>I recently implemented keepalive support in the hls demuxer, and have been
>>using it with a lot of success. See my patchset:
>>http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217353.html
>>
>>Aman
>
>Thanks a lot for your excellent suggestion. 
>I was not aware of the global function ff_http_do_new_request.
>Now I will attempt to re-implement this feature along similar lines of your 
>patch.
>
>Regards,
>Karthick 

Well, usage of global function ff_http_do_new_request made it much simpler.
Have submitted a completely new patch series for the same feature.
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219301.html
Hope the new approach is acceptable :)

Regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] WebM in dashenc

[Jeyapal, Karthick]

On 5/3/18 10:11 PM, Jan Ekström wrote:
> On Fri, Apr 27, 2018 at 3:51 AM, Jan Ekström  wrote:
>> Personally I would be for removal of the WebM muxing feature in dashenc
>> altogether, since the dashenc feature has never seemingly worked, and
>> since there is a whole separate WebM-specific DASH meta muxer in
>> webmdashenc.
>>
>> But these patches should at least make the thing not crash, and put it
>> under FF_COMPLIANCE_EXPERIMENTAL strictness. That way nobody should be
>> accidentally utilizing it.
>>
>
> For the record, I wrote this at around 4AM under the impression that
> the "WebM DASH" muxer was actually what you would expect from its
> name.. (and by quickly checking that it seemed to be writing a DASH
> manifest)
>
> It most certainly is not that, it just writes a DASH manifest. Does
> not actually mux anything. So yes, dashenc is the thing to poke for
> both ISOBMFF and WebM DASH.
OMG! I was also not aware of that. Oops! 
Thanks for the info.
>
> Accordingly, I have found out that someone actually utilized WebM dash
> for audio, and they mentioned that it worked for them on Chromium,
> Firefox and Edge. The muxer seems to have worked without crashing at
> least during release/3.4. I asked them to verify some video as well,
> and if it works then the FF_COMPLIANCE_EXPERIMENTAL limitation can be
> removed.
I have sent a new patch to make the output format configurable as suggested by 
you sometime back.
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/229436.html
I have tested the WebM output with the following results
VP8 - Works both in Chrome and Firefox
Opus - Works both in Chrome and Firefox
VP9 - Works in Chrome. But not in Firefox.
Since most of it working I have also removed the FF_COMPLIANCE_EXPERIMENTAL 
limitation and replaced it with just a warning in case of segment extension 
mismatch.  
>
> Kind of glad adding that made someone notice something, and report
> that they were actually utilizing the feature. They seemed to be happy
> about the thing no longer crashing, as well as the pass-through of
> compliance mode to the sub-muxer.
Yes, that is a really useful feature. 
>
> Best regards,
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Added option for Segment file format

[Jeyapal, Karthick]

On 5/12/18 8:47 PM, Jan Ekström wrote:
> On Fri, May 4, 2018 at 9:32 AM, Karthick J  wrote:
>> From: Karthick Jeyapal 
>>
>> Right now segment file format is chosen to be either mp4 or webm based on 
>> the codec format.
>> This patch makes that choice configurable by the user, instead of being 
>> decided by the muxer.
>> ---
>>  doc/muxers.texi   |  8 
>>  libavformat/dashenc.c | 48 ++--
>>  2 files changed, 30 insertions(+), 26 deletions(-)
>>
>
> Hi,
>
> Sorry for getting to this so late, been busy on various things (as
> usual). Thanks for prodding me.
Thanks for your reply.
>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 6f03bba..2429f8e 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -282,6 +282,14 @@ corrects that index value.
>>  Typically this logic is needed in live streaming use cases. The network 
>> bandwidth
>>  fluctuations are common during long run streaming. Each fluctuation can 
>> cause
>>  the segment indexes fall behind the expected real time position.
>> +
>> +@item dash_segment_type @var{dash_segment_type}
>> +Possible values:
>> +@item mp4
>> +If this flag is set, the dash segment files will be in in ISOBMFF format. 
>> This is the default format.
>> +
>> +@item webm
>> +If this flag is set, the dash segment files will be in in WebM format.
>>  @end table
>>
>>  @anchor{framecrc}
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 1dd6333..412f074 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -48,6 +48,11 @@
>>  #include "vpcc.h"
>>  #include "dash.h"
>>
>> +typedef enum {
>> +SEGMENT_TYPE_MP4,
>> +SEGMENT_TYPE_WEBM,
>> +} SegmentType;
>> +
>
I agree with all your comments below. 
Please find the newer patch in 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/229998.html which tries to 
address most of them.
> Ah yes, an enum :) I really like the checks being equality/inequality
> now. I've seen things like SEGMENT_TYPE_NB used for the stopper so
> that in the AVOption you can then set the maximum to *_NB - 1 instead
> of then having to change it if it ever gets anything added to it.
>
> Maybe consider making something like the `codecs[]` array for formats
> and make the thing in DASHContext as a char pointer, so that you can
> just point the string pointer to its value in init() instead of doing
> a run-time strncpy.
>
> This does remove the "dynamicness" of  the per-stream selection, which
> possibly should be mentioned. But at least personally I think this is
> what people actually wanted with WebM vs ISOBMFF DASH selection ;) ,
> as in not having surprises between streams.
>
> Otherwise this patch generally looks alright, leaving just the segment
> file name part not automatical just yet :) (I feel like we need to
> have separate options for the general template and the extension).
>
> Best regards,
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/dashenc: Added option for Segment file format

[Jeyapal, Karthick]

On 5/14/18 11:55 AM, Gyan Doshi wrote:
>
>
> On 5/14/2018 11:41 AM, Karthick J wrote:
>
>> Right now segment file format is chosen to be either mp4 or webm based on 
>> the codec format.
>> This patch makes that choice configurable by the user, instead of being 
>> decided by the muxer.
>
> Can you update the docs to reflect on the differences between using the
> dash muxer for WebM and the webm_dash_manifest + webm_chunk muxers?
That's a good question. 
I have never worked/used webm_dash_manifest + webm_chunk muxer, and hence I 
don't know the difference.
If somebody knows the difference, then patches welcome (
>
> Thanks,
> Gyan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Add documentation for http method option

[Jeyapal, Karthick]

Pushed.
On 5/7/18 9:23 AM, Karthick J wrote:
> From: Karthick Jeyapal 
>
> ---
>  doc/muxers.texi | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 2429f8e..ea80296 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -252,6 +252,8 @@ DASH-templated name to used for the initialization 
> segment. Default is "init-str
>  DASH-templated name to used for the media segments. Default is 
> "chunk-stream$RepresentationID$-$Number%05d$.m4s"
>  @item -utc_timing_url @var{utc_url}
>  URL of the page that will return the UTC timestamp in ISO format. Example: 
> "https://time.akamai.com/?iso;
> +@item method @var{method}
> +Use the given HTTP method to create output files. Generally set to PUT or 
> POST.
>  @item -http_user_agent @var{user_agent}
>  Override User-Agent field in HTTP header. Applicable only for HTTP output.
>  @item -http_persistent @var{http_persistent}


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: configuring container format options

[Jeyapal, Karthick]

Pushed.

On 5/7/18 3:28 PM, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
>
> ---
>  doc/muxers.texi   | 4 
>  libavformat/dashenc.c | 7 +++
>  2 files changed, 11 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index db81901..e9082a4 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -282,6 +282,10 @@ corrects that index value.
>  Typically this logic is needed in live streaming use cases. The network 
> bandwidth
>  fluctuations are common during long run streaming. Each fluctuation can cause
>  the segment indexes fall behind the expected real time position.
> +@item -format_options @var{options_list}
> +Set container format (mp4/webm) options using a @code{:} separated list of
> +key=value parameters. Values containing @code{:} special characters must be
> +escaped.
>  @end table
>  
>  @anchor{framecrc}
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 1dd6333..e27b61c 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -125,6 +125,7 @@ typedef struct DASHContext {
>  int streaming;
>  int64_t timeout;
>  int index_correction;
> +char *format_options_str;
>  } DASHContext;
>  
>  static struct codec_string {
> @@ -1017,6 +1018,11 @@ static int dash_init(AVFormatContext *s)
>  av_dict_free();
>  os->init_start_pos = 0;
>  
> +if (c->format_options_str) {
> +ret = av_dict_parse_string(, c->format_options_str, "=", 
> ":", 0);
> +if (ret < 0)
> +return ret;
> +}
>  if (!strcmp(os->format_name, "mp4")) {
>  if (c->streaming)
>  av_dict_set(, "movflags", 
> "frag_every_frame+dash+delay_moov", 0);
> @@ -1538,6 +1544,7 @@ static const AVOption options[] = {
>  { "streaming", "Enable/Disable streaming mode of output. Each frame will 
> be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E 
> },
>  { "timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
> AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
>  { "index_correction", "Enable/Disable segment index correction logic", 
> OFFSET(index_correction), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
> +{ "format_options","set list of options for the container format 
> (mp4/webm) used for dash", OFFSET(format_options_str), AV_OPT_TYPE_STRING, 
> {.str = NULL},  0, 0, E},
>  { NULL },
>  };
>  


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/3] avformat/movenc: creating producer reference time (PRFT) box

[Jeyapal, Karthick]

Pushed Patchset.

Regards,
Karthick

On 5/7/18 3:27 PM, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
>
> The producer reference time box supplies relative wall-clock times
> at which movie fragments, or files containing movie fragments
> (such as segments) were produced.
> The box is mainly useful in live streaming use cases. A media player
> can parse the box and utilize the time fields to measure and improve
> the latency during real time playout.
> ---
>  doc/muxers.texi  | 10 ++
>  libavformat/movenc.c | 50 ++
>  libavformat/movenc.h |  9 +
>  3 files changed, 69 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 6f03bba..db81901 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1329,6 +1329,16 @@ be negative. This enables the initial sample to have 
> DTS/CTS of zero, and
>  reduces the need for edit lists for some cases such as video tracks with
>  B-frames. Additionally, eases conformance with the DASH-IF interoperability
>  guidelines.
> +@item -write_prft
> +Write producer time reference box (PRFT) with a specified time source for the
> +NTP field in the PRFT box. Set value as @samp{wallclock} to specify 
> timesource
> +as wallclock time and @samp{pts} to specify timesource as input packets' PTS
> +values.
> +
> +Setting value to @samp{pts} is applicable only for a live encoding use case,
> +where PTS values are set as as wallclock time at the source. For example, an
> +encoding use case with decklink capture source where @option{video_pts} and
> +@option{audio_pts} are set to @samp{abs_wallclock}.
>  @end table
>  
>  @subsection Example
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 0b44fd6..7e616e8 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -98,6 +98,9 @@ static const AVOption options[] = {
>  { "encryption_kid", "The media encryption key identifier (hex)", 
> offsetof(MOVMuxContext, encryption_kid), AV_OPT_TYPE_BINARY, .flags = 
> AV_OPT_FLAG_ENCODING_PARAM },
>  { "use_stream_ids_as_track_ids", "use stream ids as track ids", 
> offsetof(MOVMuxContext, use_stream_ids_as_track_ids), AV_OPT_TYPE_BOOL, {.i64 
> = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>  { "write_tmcd", "force or disable writing tmcd", offsetof(MOVMuxContext, 
> write_tmcd), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, 
> AV_OPT_FLAG_ENCODING_PARAM},
> +{ "write_prft", "Write producer reference time box with specified time 
> source", offsetof(MOVMuxContext, write_prft), AV_OPT_TYPE_INT, {.i64 = 
> MOV_PRFT_NONE}, 0, MOV_PRFT_NB-1, AV_OPT_FLAG_ENCODING_PARAM, "prft"},
> +{ "wallclock", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> MOV_PRFT_SRC_WALLCLOCK}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM, "prft"},
> +{ "pts", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = MOV_PRFT_SRC_PTS}, 0, 0, 
> AV_OPT_FLAG_ENCODING_PARAM, "prft"},
>  { NULL },
>  };
>  
> @@ -4514,6 +4517,49 @@ static int mov_write_sidx_tags(AVIOContext *pb, 
> MOVMuxContext *mov,
>  return 0;
>  }
>  
> +static int mov_write_prft_tag(AVIOContext *pb, MOVMuxContext *mov, int 
> tracks)
> +{
> +int64_t pos = avio_tell(pb), pts_us, ntp_ts;
> +MOVTrack *first_track;
> +
> +/* PRFT should be associated with at most one track. So, choosing only 
> the
> + * first track. */
> +if (tracks > 0)
> +return 0;
> +first_track = &(mov->tracks[0]);
> +
> +if (!first_track->entry) {
> +av_log(mov->fc, AV_LOG_WARNING, "Unable to write PRFT, no entries in 
> the track\n");
> +return 0;
> +}
> +
> +if (first_track->cluster[0].pts == AV_NOPTS_VALUE) {
> +av_log(mov->fc, AV_LOG_WARNING, "Unable to write PRFT, first PTS is 
> invalid\n");
> +return 0;
> +}
> +
> +if (mov->write_prft == MOV_PRFT_SRC_WALLCLOCK) {
> +ntp_ts = ff_get_formatted_ntp_time(ff_ntp_time());
> +} else if (mov->write_prft == MOV_PRFT_SRC_PTS) {
> +pts_us = av_rescale_q(first_track->cluster[0].pts,
> +  first_track->st->time_base, AV_TIME_BASE_Q);
> +ntp_ts = ff_get_formatted_ntp_time(pts_us + NTP_OFFSET_US);
> +} else {
> +av_log(mov->fc, AV_LOG_WARNING, "Unsupported PRFT box configuration: 
> %d\n",
> +   mov->write_prft);
> +return 0;
> +}
> +
> +avio_wb32(pb, 0);   // Size place holder
> +ffio_wfourcc(pb, "prft");   // Type
> +avio_w8(pb, 1); // Version
> +avio_wb24(pb, 0);   // Flags
> +avio_wb32(pb, first_track->track_id);   // reference track ID
> +avio_wb64(pb, ntp_ts);  // NTP time stamp
> +avio_wb64(pb, first_track->cluster[0].pts); //media time
> +return update_size(pb, pos);
> +}
> +
>  static int mov_write_moof_tag(AVIOContext *pb, MOVMuxContext *mov, int 
> tracks,
>int64_t mdat_size)
>  {
> @@ -4528,6 

Re: [FFmpeg-devel] [PATCH 1/1] avfilter/drawtext: present 'hms' formatted 'pts' in 24h format

[Jeyapal, Karthick]

Pushed.

>On 5/7/18, 6:47 PM, "vdi...@akamai.com"  wrote:
>
>From: Vishwanath Dixit 
>
>HMS is formatted as HH:MM:SS.mmm, but, HH part is not limited to
>24 hours. For example, the the drawn text may look like this:
>243029:20:30.342. To present the timestamp in more readable and
>user friendly format, this patch provides an additional option
>to limit the hour part in the range 0-23.
>
>Note: Actually the above required format can be obtained with
>format options 'localtime' and 'gmtime', but,  milliseconds part
>is not supported in those formats.
>---
> doc/filters.texi  | 4 
> libavfilter/vf_drawtext.c | 8 
> 2 files changed, 12 insertions(+)
>
>diff --git a/doc/filters.texi b/doc/filters.texi
>index 33e27e1..6e306f1 100644
>--- a/doc/filters.texi
>+++ b/doc/filters.texi
>@@ -8134,6 +8134,10 @@ local time zone time.
> 
> The second argument is an offset added to the timestamp.
> 
>+If the format is set to @code{hms}, a third argument @code{24HH} may be
>+supplied to present the hour part of the formatted timestamp in 24h format
>+(00-23).
>+
> If the format is set to @code{localtime} or @code{gmtime},
> a third argument may be supplied: a strftime() format string.
> By default, @var{-MM-DD HH:MM:SS} format will be used.
>diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
>index e8905a4..3affa73 100644
>--- a/libavfilter/vf_drawtext.c
>+++ b/libavfilter/vf_drawtext.c
>@@ -916,6 +916,14 @@ static int func_pts(AVFilterContext *ctx, AVBPrint *bp,
> sign = '-';
> ms = -ms;
> }
>+if (argc >= 3) {
>+if (!strcmp(argv[2], "24HH")) {
>+ms %= 24 * 60 * 60 * 1000;
>+} else {
>+av_log(ctx, AV_LOG_ERROR, "Invalid argument '%s'\n", 
>argv[2]);
>+return AVERROR(EINVAL);
>+}
>+}
> av_bprintf(bp, "%c%02d:%02d:%02d.%03d", sign,
>(int)(ms / (60 * 60 * 1000)),
>(int)(ms / (60 * 1000)) % 60,
>-- 
>1.9.1
>

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Added a warning for incorrect segment name extension

[Jeyapal, Karthick]

Pushed Patchset.

On 5/4/18 12:02 PM, Karthick J wrote:
> From: Karthick Jeyapal 
>
> Applicable only to webm output format.
> By default all the segment filenames end with .m4s extension.
> When someone chooses webm output format, we recommend they also override the 
> relevant segment name options to end with .webm extension. This patch will 
> issue a warning for he same.
> ---
>  libavformat/dashenc.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 412f074..bd374e2 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -177,6 +177,16 @@ static void dashenc_io_close(AVFormatContext *s, 
> AVIOContext **pb, char *filenam
>  }
>  }
>  
> +static int check_file_extension(const char *filename, const char *extension) 
> {
> +char *dot;
> +if (!filename || !extension)
> +return -1;
> +dot = strrchr(filename, '.');
> +if (dot && !strcmp(dot + 1, extension))
> +return 0;
> +return -1;
> +}
> +
>  static void set_vp9_codec_str(AVFormatContext *s, AVCodecParameters *par,
>AVRational *frame_rate, char *str, int size) {
>  VPCC vpcc;
> @@ -967,6 +977,14 @@ static int dash_init(AVFormatContext *s)
>  
>  if (c->segment_type == SEGMENT_TYPE_WEBM) {
>  snprintf(c->format_name, sizeof(c->format_name), "webm");
> +if ((!c->single_file && check_file_extension(c->init_seg_name, 
> c->format_name) != 0) ||
> +(!c->single_file && check_file_extension(c->media_seg_name, 
> c->format_name) != 0) ||
> +(c->single_file && check_file_extension(c->single_file_name, 
> c->format_name) != 0)) {
> +av_log(s, AV_LOG_WARNING,
> +   "One or many segment file names doesn't end with 
> .webm. "
> +   "Override -init_seg_name and/or -media_seg_name 
> and/or "
> +   "-single_file_name to end with the extension 
> .webm\n");
> +}
>  } else if (c->segment_type == SEGMENT_TYPE_MP4) {
>  snprintf(c->format_name, sizeof(c->format_name), "mp4");
>  } else {


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/3] WebM in dashenc

[Jeyapal, Karthick]

On 4/27/18 6:21 AM, Jan Ekström wrote:
> Personally I would be for removal of the WebM muxing feature in dashenc
> altogether, since the dashenc feature has never seemingly worked, and
> since there is a whole separate WebM-specific DASH meta muxer in
> webmdashenc.
>
> But these patches should at least make the thing not crash, and put it
> under FF_COMPLIANCE_EXPERIMENTAL strictness. That way nobody should be
> accidentally utilizing it.
>
> Jan Ekström (2):
>   lavf/dashenc: require experimental mode to be enabled for WebM
>   lavf/dashenc: pass standards compliance value to the internal context
>
> Rodger Combs (1):
>   lavf/dashenc: don't call flush_init_segment before
> avformat_write_header
>
>  libavformat/dashenc.c | 33 ++---
>  1 file changed, 22 insertions(+), 11 deletions(-)
>
Pushed the patchset. Thanks for your guidance.

Regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

[Jeyapal, Karthick]

On 4/23/18 11:40 AM, Karthick J wrote:
> From: Karthick Jeyapal 
>
> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in 
> DASH.
> Hence in this muxer we will focus on supporting VP9 in MP4
> Have verified playout support of VP9+MP4 in Chrome and Firefox.
> ---
>  libavformat/dashenc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index a5f58d4..211ef23 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
>  if (!ctx)
>  return AVERROR(ENOMEM);
>  
> -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
> otherwise
> +// choose muxer based on codec: webm for VP8 and opus, mp4 otherwise
>  // note: os->format_name is also used as part of the mimetype of the
>  //   representation, e.g. video/
>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>  snprintf(os->format_name, sizeof(os->format_name), "webm");

Pushed the patchset

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

[Jeyapal, Karthick]

On 4/27/18 3:05 AM, Jan Ekström wrote:
> On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick <kjeya...@akamai.com> 
> wrote:
>>
>>
>> On 4/23/18 11:40 AM, Karthick J wrote:
>>> From: Karthick Jeyapal <kjeya...@akamai.com>
>>>
>>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in 
>>> DASH.
>>> Hence in this muxer we will focus on supporting VP9 in MP4
>>> Have verified playout support of VP9+MP4 in Chrome and Firefox.
>>> ---
>>>  libavformat/dashenc.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>> index a5f58d4..211ef23 100644
>>> --- a/libavformat/dashenc.c
>>> +++ b/libavformat/dashenc.c
>>> @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
>>>  if (!ctx)
>>>  return AVERROR(ENOMEM);
>>>
>>> -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
>>> otherwise
>>> +// choose muxer based on codec: webm for VP8 and opus, mp4 
>>> otherwise
>>>  // note: os->format_name is also used as part of the mimetype of 
>>> the
>>>  //   representation, e.g. video/
>>>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
>>> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>>>  snprintf(os->format_name, sizeof(os->format_name), "webm");
>>
>> Pushed the patchset
>>
>
> Hi,
>
> First of all, I would prefer the patch to actually mention what it is
> doing. It is removing the webm override from the muxer for VP9. There
> is as far as I know no option to switch between modes in current git,
> so the commit message is blindly misleading at best and just plain
> trying to look harmless (in order to get a free pass) if taken the
> wrong way. Not saying you meant it that way, but the commit message
> does not say what it does as far as I can see.
>
> Also the patch does not mention the reason why it is doing this other
> than the fact that there's a separate webm DASH muxer. That is true,
> but the real reason you were switching this default is because the
> WebM mode does not work. Now, fixing segfaults is good. And, for the
> record, I actually agree with the change since with the profile string
> it works in dash.js on various browsers (Firefox, Chromium, Edge).
>
> But begesus... If it is done like this you might as well be honest and
> just remove the WebM mode! Because right now you left it there to
> segfault for VP8, Opus, Vorbis. Another alternative would have been to
> apply the small change to Rodger Combs's patch
> (https://patchwork.ffmpeg.org/patch/7984/), which you even commented
> on before! Maybe it still doesn't work in browsers, but at least it
> would have gotten to that point.
I am sorry, if the commit comments are misleading and wrong. Yes, I agree that 
this patch was meant to solve the segfault issue but didn't mention it 
forthright in the commit message.(which I will correct next time). But I still 
think that this is the right approach to fix that problem. I had provided the 
justifications for this approach in my earlier reply 
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228479.html . Since you 
didn't reply for 1 week, I assumed that you are convinced with the 
justifications and pushed this patch. Just to re-iterate the justifications,
1. Solving segfault with VP9+webm didn't get the playout working in browsers. 
2. There is a separate webm DASH muxer meant for this exact purpose. Repeating 
the same here is a waste of time and effort.
3. There was no muxer to support VP9+MP4. So, this patch is also a feature 
addition. And MP4 is a more widely supported than WebM.
4. Removing WebM support immediately in a single commit is little drastic. I 
don't know if someone wants WebM with dashenc.c instead of webmdashenc.c for 
some specific reason. Hence, I wanted to give some time, before removing it 
completely.
I was thinking to move VP8, Opus and Vorbis to MP4 after this patch gets 
pushed, to solve this segfault issue for other codecs. 
>
> Really, I am thankful that you are contributing, but I really do not
> want to see things like these after long days of work when I have not
> noticed or wasn't able to write a long reply. You waited for two days,
> and pushed without reviews even though I had shown interest in the
> patch in its first iter

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/dashenc: Set mp4 as the default format for VP9

[Jeyapal, Karthick]

On 4/27/18 4:26 AM, Michael Niedermayer wrote:
> On Fri, Apr 27, 2018 at 12:35:42AM +0300, Jan Ekström wrote:
>> On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick <kjeya...@akamai.com> 
>> wrote:
>>>
>>>
>>> On 4/23/18 11:40 AM, Karthick J wrote:
>>>> From: Karthick Jeyapal <kjeya...@akamai.com>
>>>>
>>>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in 
>>>> DASH.
>>>> Hence in this muxer we will focus on supporting VP9 in MP4
>>>> Have verified playout support of VP9+MP4 in Chrome and Firefox.
>>>> ---
>>>>  libavformat/dashenc.c | 3 +--
>>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>>> index a5f58d4..211ef23 100644
>>>> --- a/libavformat/dashenc.c
>>>> +++ b/libavformat/dashenc.c
>>>> @@ -959,11 +959,10 @@ static int dash_init(AVFormatContext *s)
>>>>  if (!ctx)
>>>>  return AVERROR(ENOMEM);
>>>>
>>>> -// choose muxer based on codec: webm for VP8/9 and opus, mp4 
>>>> otherwise
>>>> +// choose muxer based on codec: webm for VP8 and opus, mp4 
>>>> otherwise
>>>>  // note: os->format_name is also used as part of the mimetype of 
>>>> the
>>>>  //   representation, e.g. video/
>>>>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
>>>> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>>>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>>>>  s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>>>>  snprintf(os->format_name, sizeof(os->format_name), "webm");
>>>
>>> Pushed the patchset
>>>
>>
>> Hi,
>>
>> First of all, I would prefer the patch to actually mention what it is
>> doing. It is removing the webm override from the muxer for VP9. There
>> is as far as I know no option to switch between modes in current git,
>> so the commit message is blindly misleading at best and just plain
>> trying to look harmless (in order to get a free pass) if taken the
>> wrong way. Not saying you meant it that way, but the commit message
>> does not say what it does as far as I can see.
>>
>> Also the patch does not mention the reason why it is doing this other
>> than the fact that there's a separate webm DASH muxer. That is true,
>> but the real reason you were switching this default is because the
>> WebM mode does not work. Now, fixing segfaults is good. And, for the
>> record, I actually agree with the change since with the profile string
>> it works in dash.js on various browsers (Firefox, Chromium, Edge).
>>
>> But begesus... If it is done like this you might as well be honest and
>> just remove the WebM mode! Because right now you left it there to
>> segfault for VP8, Opus, Vorbis. Another alternative would have been to
>> apply the small change to Rodger Combs's patch
>> (https://patchwork.ffmpeg.org/patch/7984/), which you even commented
>> on before! Maybe it still doesn't work in browsers, but at least it
>> would have gotten to that point.
>>
>> Really, I am thankful that you are contributing, but I really do not
>> want to see things like these after long days of work when I have not
>> noticed or wasn't able to write a long reply. You waited for two days,
>> and pushed without reviews even though I had shown interest in the
>> patch in its first iteration. If you are interested in getting quick
>> comments from someone (including me when I am awake and available),
>> please join the IRC channel #ffmpeg-devel if only possible. Even if it
>> is just for pokes and links to patchwork towards someone who has shown
>> interest to related patches before. I try as much as possible to poke
>> relevant people when I post patches, and I would prefer it if others
>> would do that as well. We're not perfect and issues can and do go
>> through peoples' eyes (esp. if the change set is of the larger size
>> issues tend to get hidden in plain sight, unfortunately), but let's
>> try to make this work.
>>
>> Best regards,
>> Jan
>>
>> P.S. I am sorry if my way of speech came out bad, it is just past
>> midnight here and I was trying to get a reply to this written after
>> noticing this mail.
>
> I can 

[FFmpeg-devel] [PATCH 1/1] avdevice/decklink_dec: Autodetect the video input format

[Jeyapal, Karthick]

Please find the patch attached.

Regards,
Karthick




0001-avdevice-decklink_dec-Autodetect-the-video-input-for.patch
Description: 0001-avdevice-decklink_dec-Autodetect-the-video-input-for.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: Signal http end of chunk explicitly during hlsenc_io_close()

[Jeyapal, Karthick]

>On 12/22/17, 2:06 PM, "刘歧"  wrote:
>
>> On 22 Dec 2017, at 15:04, Karthick J  wrote:
>> 
>> From: Karthick Jeyapal 
>> 
>> Currently http end of chunk is called implicitly in hlsenc_io_open().
>> This mean playlists http writes would have to wait upto a segment duration 
>> to signal end of chunk causing delays.
>> This patch will fix that problem and improve performance.
>> […]
>LGTM, if the libavformat/http no problem.
Thanks for the comments.
I have sent a new patch v2 to address the http issue raised by wm4

Regards,
Karthick
>
>
>thanks
>
>Steven



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/http: Added a library-internal API for signalling end of chunk

[Jeyapal, Karthick]

On 12/22/17, 1:13 PM, "wm4"  wrote:
>
>On Fri, 22 Dec 2017 12:34:41 +0530
>Karthick J  wrote:
>
>> From: Karthick Jeyapal 
>> 
>> Right now there is no explicit way to signal end of chunk, when 
>> http_multiple is set.
>> ff_http_do_new_request() function implicitly signals end of chunk. But that 
>> could be too late for certain applications.
>> Hence added a new function ff_http_signal_end_of_chunk() which could be used 
>> internally within libavformat.
>> ---
>>[…]
>
>I'd really prefer if this HTTP stuff would be added in a much cleaner
>way, such as making it part of the AVIO API, or at least the
>URLContext API. (Why are there 2 APIs anyway...)

Thanks for your comments. 
I am now using the ffurl* API as you suggested, in the new patch v2.

Regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: improve compute target_duration way

[Jeyapal, Karthick]

On 12/23/17 8:02 PM, Steven Liu wrote:
>
>
>> 在 2017年12月23日，下午6:38，Jeyapal, Karthick <kjeya...@akamai.com> 写道：
>>
>>
>>> On 12/23/17 4:59 AM, Steven Liu wrote:
>>> just use lrint(lrint(duration * 10.0) / 10.0)
>>> fix ticket: 6915
>>>
>>> Suggested-by: beloko
>>> Signed-off-by: Steven Liu <l...@chinaffmpeg.org>
>>> ---
>>> libavformat/dashenc.c | 2 +-
>>> libavformat/hlsenc.c  | 2 +-
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>> index 5368a2334c..102558d17e 100644
>>> --- a/libavformat/dashenc.c
>>> +++ b/libavformat/dashenc.c
>>> @@ -358,7 +358,7 @@ static void output_segment_list(OutputStream *os, 
>>> AVIOContext *out, DASHContext
>>> Segment *seg = os->segments[i];
>>> double duration = (double) seg->duration / timescale;
>>> if (target_duration <= duration)
>>> -target_duration = lrint(duration);
>>> +target_duration = lrint(lrint(duration * 10.0) / 10.0);
>> This will just move the move the corner case from x.5 to x.45(x.46 depending 
>> on the double precision errors). Will not solve the original issue.
>> For example, right now 1.5 is a corner case, as lrint(1.5) = 2, and 
>> lrint(1.49) = 1.
>> After this patch, 1.46 will become the corner case. For example 
>> lrint(lrint(1.45 * 10.0) / 10.0) = 1 and lrint(lrint(1.46 * 10.0) / 10.0) = 2
>> When someone chooses a segment duration of 1.46, this issue will again 
>> resurface.
> maybe you are right, and I use mediastreamvalidator check again, I focus the 
> error, when the media_0.m3u8 media_1.m3u8 EXT-X-TARGETDURATION different, it 
> no error of the two playlist, I think Roger response is right, maybe our 
> focus is not right. Look at your lrint patch, the test error context is not 
> target duration different error, and I have test use the code before your 
> patch , no target duration error of two playlist. Just fragment duration 
> error to target duration, look it again.
As I said earlier, we need not focus on segment size being 1.5 or 1.45, as it 
is not a valid use-case. Even hlsenc does support only integral number of 
seconds as a configuration option(hls_time).
According to me, right now there is no issue in ffmpeg w.r.t target duration as 
integer segment sizes are handled correctly. We can come back to this problem, 
when it really becomes a use-case and somebody reports this as an issue.

As you might know, the older spec allowed only integer EXTINF durations as 
well. Later they added floating point duration as video and audio segments 
cannot always be cut at exactly at integral multiple of seconds, which was 
leading to accumulation of errors causing unexpected player behavior. My guess 
is floating point duration was added to avoid error accumulation, and not for 
supporting fractional segment sizes as a feature. As far I am aware, no popular 
video streaming service is using HLS with fractional segment durations like 
1.5, 2.5 etc., All of them are using integral multiple of seconds as segment 
sizes. 
>>
>> Thanks and regards,
>> Karthick
>>> }
>>>
>>> ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 0095ca4339..bf6f1d9253 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -1235,7 +1235,7 @@ static int hls_window(AVFormatContext *s, int last, 
>>> VariantStream *vs)
>>>
>>> for (en = vs->segments; en; en = en->next) {
>>> if (target_duration <= en->duration)
>>> -target_duration = lrint(en->duration);
>>> +target_duration = lrint(lrint(en->duration * 10.0) / 10.0);
>>> }
>>>
>>> vs->discontinuity_set = 0;
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: improve compute target_duration way

[Jeyapal, Karthick]

On 12/23/17 4:59 AM, Steven Liu wrote:
> just use lrint(lrint(duration * 10.0) / 10.0)
> fix ticket: 6915
>
> Suggested-by: beloko
> Signed-off-by: Steven Liu 
> ---
>  libavformat/dashenc.c | 2 +-
>  libavformat/hlsenc.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 5368a2334c..102558d17e 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -358,7 +358,7 @@ static void output_segment_list(OutputStream *os, 
> AVIOContext *out, DASHContext
>  Segment *seg = os->segments[i];
>  double duration = (double) seg->duration / timescale;
>  if (target_duration <= duration)
> -target_duration = lrint(duration);
> +target_duration = lrint(lrint(duration * 10.0) / 10.0);
This will just move the move the corner case from x.5 to x.45(x.46 depending on 
the double precision errors). Will not solve the original issue.
For example, right now 1.5 is a corner case, as lrint(1.5) = 2, and lrint(1.49) 
= 1.
After this patch, 1.46 will become the corner case. For example 
lrint(lrint(1.45 * 10.0) / 10.0) = 1 and lrint(lrint(1.46 * 10.0) / 10.0) = 2
When someone chooses a segment duration of 1.46, this issue will again 
resurface.

Thanks and regards,
Karthick
>  }
>  
>  ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 0095ca4339..bf6f1d9253 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1235,7 +1235,7 @@ static int hls_window(AVFormatContext *s, int last, 
> VariantStream *vs)
>  
>  for (en = vs->segments; en; en = en->next) {
>  if (target_duration <= en->duration)
> -target_duration = lrint(en->duration);
> +target_duration = lrint(lrint(en->duration * 10.0) / 10.0);
>  }
>  
>  vs->discontinuity_set = 0;


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Dont write stream info for agroup

[Jeyapal, Karthick]

On 1/18/18 6:53 PM, Brendan McGrath wrote:
> I tried your suggestion and it still didn't work. So I took another look at 
> the spec and it looks like what was originally there was correct (as seen in 
> the below example):
> https://tools.ietf.org/html/rfc8216#section-8.6
>
> In that example - english-audio.m3u8 appears in both a MEDIA and STREAM-INF 
> entry with the STREAM-INF entry including an AUDIO tag that references back 
> to itself.
>
> So I believe this patch can be dropped.
>
> What I did discover was that it worked when I added a CODECS tag to the 
> STREAM-INF variant of the audio stream. The spec just says:
> Every EXT-X-STREAM-INF tag SHOULD include a CODECS attribute
>
> So I guess this is a bug in iOS.
I agree. But, there is a patch available 
https://patchwork.ffmpeg.org/patch/7000/ to add CODECS tag. 
You could check if applying that patch solves your issue. 
>
> On 18/01/18 21:59, Dixit, Vishwanath wrote:
>>
>> On 1/18/18 2:39 PM, Brendan McGrath wrote:
>>> When using an 'agroup' within var_stream_map - the audio stream is
>>> being added to the master playlist file as both an audio rendition
>>> and an individual stream (with an AUDIO reference back to itself).
>>>
>>> This patch ensures an audio rendition does not also appear within
>>> the stream info list.
>>>
>>> What follows is an example of the command to create this issue and
>>> the contents of the master playlist before and after this patch is
>>> applied:
>>>
>>> ffmpeg -i in.ts -b:a:0 128k -b:v:0 1800k -b:v:1 1024k -map 0:a \
>>> -map 0:v -map 0:v -f hls -var_stream_map "a:0,agroup:audio_0 "\
>>> "v:0,agroup:audio_0 v:1,agroup:audio_0" -master_pl_name \
>>> tv_hls.m3u8 tv_hls_%v.m3u8
>>>
>>> Before:
>>>   #EXTM3U
>>>   #EXT-X-VERSION:3
>>>   
>>> #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_audio_0",NAME="audio_0",DEFAULT=YES,URI="tv_hls_0.m3u8"
>>>   #EXT-X-STREAM-INF:BANDWIDTH=140800,AUDIO="group_audio_0"
>>>   tv_hls_0.m3u8
>>>
>>>   
>>> #EXT-X-STREAM-INF:BANDWIDTH=2120800,RESOLUTION=1920x1080,AUDIO="group_audio_0"
>>>   tv_hls_1.m3u8
>>>
>>>   
>>> #EXT-X-STREAM-INF:BANDWIDTH=1267200,RESOLUTION=1920x1080,AUDIO="group_audio_0"
>>>   tv_hls_2.m3u8
>>>
>>> After:
>>>   #EXTM3U
>>>   #EXT-X-VERSION:3
>>>   
>>> #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_audio_0",NAME="audio_0",DEFAULT=YES,URI="tv_hls_0.m3u8"
>>>   
>>> #EXT-X-STREAM-INF:BANDWIDTH=2120800,RESOLUTION=1920x1080,AUDIO="group_audio_0"
>>>   tv_hls_1.m3u8
>>>
>>>   
>>> #EXT-X-STREAM-INF:BANDWIDTH=1267200,RESOLUTION=1920x1080,AUDIO="group_audio_0"
>>>   tv_hls_2.m3u8
>>>
>>> Signed-off-by: Brendan McGrath 
>>> ---
>>>
>> Some use cases may need audio only variant streams. Ex: when bandwidth is 
>> too low. Also, I think the playback issue you are seeing, is because of 
>> AUDIO referencing back to itself, but, not because of audio only variant 
>> stream. So, instead of completely removing the audio only variant streams, 
>> you can just remove the self-referencing attribute (AUDIO=) from the 
>> #EXT-X-STREAM-INF tag’s attribute list, for the audio only variant streams.
>> #EXTM3U
>> #EXT-X-VERSION:3
>> #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="group_audio_0",NAME="audio_0",DEFAULT=YES,URI="tv_hls_0.m3u8"
>> #EXT-X-STREAM-INF:BANDWIDTH=140800
>> tv_hls_0.m3u8
>>
>> #EXT-X-STREAM-INF:BANDWIDTH=2120800,RESOLUTION=1920x1080,AUDIO="group_audio_0"
>> tv_hls_1.m3u8
>>
>> #EXT-X-STREAM-INF:BANDWIDTH=1267200,RESOLUTION=1920x1080,AUDIO="group_audio_0"
>> tv_hls_2.m3u8
>>
>>
>>> Pre-patch - the hls stream I was testing would not play on the iOS devices 
>>> I was testing with.
>>>
>>> With the patch applied - they now play the stream
>>>
>>>   libavformat/hlsenc.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index e36120c..a75853b 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -1172,6 +1172,9 @@ static int create_master_playlist(AVFormatContext *s,
>>>   for (i = 0; i < hls->nb_varstreams; i++) {
>>>   vs = &(hls->var_streams[i]);
>>>   +if (!vs->has_video && !vs->has_subtitle && vs->agroup)
>>> +continue;
>>> +
>>>   m3u8_name_size = strlen(vs->m3u8_name) + 1;
>>>   m3u8_rel_name = av_malloc(m3u8_name_size);
>>>   if (!m3u8_rel_name) { 
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Signal http end of chunk(http_shutdown) explicitly

[Jeyapal, Karthick]

On 1/2/18 1:49 PM, Karthick J wrote:
> From: Karthick Jeyapal 
>
> Currently http end of chunk is signalled implicitly in dashenc_io_open().
> This mean playlists http writes would have to wait upto a segment duration to 
> signal end of chunk causing delays.
> This patch will fix that problem and improve performance.
> ---
>  libavformat/dashenc.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 2e4ff67..c9cc389 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -149,7 +149,10 @@ static void dashenc_io_close(AVFormatContext *s, 
> AVIOContext **pb, char *filenam
>  ff_format_io_close(s, pb);
>  #if CONFIG_HTTP_PROTOCOL
>  } else {
> +URLContext *http_url_context = ffio_geturlcontext(*pb);
> +av_assert0(http_url_context);
>  avio_flush(*pb);
> +ffurl_shutdown(http_url_context, AVIO_FLAG_WRITE);
>  #endif
>  }
>  }

Patchset pushed.

Regards,
Karthick



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] hls BANDWIDTH field in master playlist

[Jeyapal, Karthick]

On 2/1/18 3:12 PM, Amit Kale wrote:
> Hi All,
>
> When emitting a master playlist, BANDWIDTH field is computed in
> libavformat/hlsenc.c by adding video and audio stream bitrates and then
> adding 10% to account for container overhead. However HLS specification
> (RFC8216) says that BANDWIDTH represents the peak segment bit rate.
> AVERAGE-BANDWIDTH on the other hand represents the average segment bit
> rate. If this is correct, I would like to send a patch to fix it.
Yes, you are right. Ofcourse, you are welcome to send a patch to fix it.
But please keep the following in mind, while sending the patch
- BANDWIDTH is mandatory parameter and AVERAGE-BANDWIDTH is optional parameter.
- Master playlist gets created at the beginning of encode during which time we 
neither know the peak bitrate or the average bitrate of the stream. Right now, 
we are just using the codec’s bitrate parameter which could be way different 
from the actual bitrate of the stream.  So the master playlist should get 
created initially with BANDWIDTH as codec bitrate(to handle live encode). At 
the end of encoding, master playlist should be updated again with the true peak 
bitrate and true average bitrate(for AVERAGE-BANDWIDTH).
- The definition for BANDWIDTH changed to peak bitrate only in v7 of the HLS 
spec. Earlier BANDWIDTH was mentioned as overall bitrate. So, there should be 
an option to turn on or turn off peak bitrate calculation.
>
> Thanks.
> -Amit
>


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] Add a new hls_flag peak_segment_bw

[Jeyapal, Karthick]

On 2/12/18 2:24 PM, Amit Kale wrote:
> If this flag is set, BANDWIDTH value in a master playlist entry will be set to
> the peak segment bandwidth.
Thanks for sending the patch. Here are some comments.
> ---
>  doc/muxers.texi  |  4 
>  libavformat/hlsenc.c | 29 +
>  2 files changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index d9a5cc03dc..e2c9cbfa2f 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -741,6 +741,10 @@ subdirectories.
>  Possible values:
>
>  @table @samp
> +@item peak_segment_bw
> +If this flag is set, BANDWIDTH value in a master playlist entry will be
> +set to the peak segment bandwidth.
> +
>  @item single_file
>  If this flag is set, the muxer will store all segments in a single MPEG-TS
>  file, and will use byte ranges in the playlist. HLS playlists generated with
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 9970c4c575..f40cd0b98f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -98,6 +98,7 @@ typedef enum HLSFlags {
>  HLS_TEMP_FILE = (1 << 11),
>  HLS_PERIODIC_REKEY = (1 << 12),
>  HLS_INDEPENDENT_SEGMENTS = (1 << 13),
> +HLS_PEAK_SEGMENT_BW = (1 << 14),
Also set the version number as 7 when this flag is set. Maybe in hls_window.
Maybe something like
if (hls->flags & HLS_PEAK_SEGMENT_BW) {
hls->version = 7;
}
>  } HLSFlags;
>
>  typedef enum {
> @@ -1168,7 +1169,8 @@ static int get_relative_url(const char *master_url, 
> const char *media_url,
>  }
>
>  static int create_master_playlist(AVFormatContext *s,
> -  VariantStream * const input_vs)
> +  VariantStream * const input_vs,
> +  int last)
>  {
>  HLSContext *hls = s->priv_data;
>  VariantStream *vs, *temp_vs;
> @@ -1185,7 +1187,7 @@ static int create_master_playlist(AVFormatContext *s,
>  for (i = 0; i < hls->nb_varstreams; i++)
>  if (!hls->var_streams[i].m3u8_created)
>  return 0;
> -} else {
> +} else if (!last) {
>   /* Keep publishing the master playlist at the configured rate */
>  if (>var_streams[0] != input_vs || !hls->master_publish_rate ||
>  input_vs->number % hls->master_publish_rate)
> @@ -1292,11 +1294,21 @@ static int create_master_playlist(AVFormatContext *s,
>  }
>
>  bandwidth = 0;
> -if (vid_st)
> -bandwidth += vid_st->codecpar->bit_rate;
> -if (aud_st)
> -bandwidth += aud_st->codecpar->bit_rate;
> -bandwidth += bandwidth / 10;
> +if (last && hls->flags & HLS_PEAK_SEGMENT_BW) {
> +HLSSegment *hs = vs->segments;
> +while (hs) {
> +int64_t segment_bandwidth = hs->size * 8 / hs->duration;
> +if (bandwidth < segment_bandwidth)
> +bandwidth = segment_bandwidth;
> +hs = hs->next;
> +}
I guess, this may not work in case AV streams as separate renditions.
In such a case, only video’s peak bitrate is getting calculated here. 
Audio stream’s peak bandwidth is missed out. Please correct me, if I am wrong 
here.
> +} else {
> +if (vid_st)
> +bandwidth += vid_st->codecpar->bit_rate;
> +if (aud_st)
> +bandwidth += aud_st->codecpar->bit_rate;
> +bandwidth += bandwidth / 10;
> +}
>
>  ccgroup = NULL;
>  if (vid_st && vs->ccgroup) {
> @@ -1437,7 +1449,7 @@ fail:
>  ff_rename(temp_filename, vs->m3u8_name, s);
>
>  if (ret >= 0 && hls->master_pl_name)
> -if (create_master_playlist(s, vs) < 0)
> +if (create_master_playlist(s, vs, last) < 0)
>  av_log(s, AV_LOG_WARNING, "Master playlist creation failed\n");
>
>  return ret;
> @@ -2753,6 +2765,7 @@ static const AVOption options[] = {
>  {"fmp4",   "make segment file to fragment mp4 files in m3u8", 0, 
> AV_OPT_TYPE_CONST, {.i64 = SEGMENT_TYPE_FMP4 }, 0, UINT_MAX, E, 
> "segment_type"},
>  {"hls_fmp4_init_filename", "set fragment mp4 file init filename", 
> OFFSET(fmp4_init_filename),   AV_OPT_TYPE_STRING, {.str = "init.mp4"},
> 0,   0, E},
>  {"hls_flags", "set flags affecting HLS playlist and media file 
> generation", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E, 
> "flags"},
> +{"peak_segment_bw",   "sets bandwidth in master play list to peak 
> segment bandwidth", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_PEAK_SEGMENT_BW }, 0, 
> UINT_MAX,   E, "flags"},
>  {"single_file",   "generate a single media file indexed with byte 
> ranges", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX,   E, 
> "flags"},
>  {"temp_file", "write segment to temporary file and rename when 
> complete", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX,   E, 
> 

Re: [FFmpeg-devel] [PATCH] DASH muxer: add option to change HTTP method

[Jeyapal, Karthick]

On 2/23/18 3:30 PM, Serhii Marchuk wrote:
> ---
>  libavformat/dashenc.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 0f6f4f22fa..28ff288fca 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -105,6 +105,7 @@ typedef struct DASHContext {
>  const char *init_seg_name;
>  const char *media_seg_name;
>  const char *utc_timing_url;
> +const char *method;
>  const char *user_agent;
>  int hls_playlist;
>  int http_persistent;
> @@ -256,6 +257,8 @@ static int flush_dynbuf(OutputStream *os, int 
> *range_length)
>  
>  static void set_http_options(AVDictionary **options, DASHContext *c)
>  {
> +if (c->method)
> +av_dict_set(options, "method", c->method, 0);
>  if (c->user_agent)
>  av_dict_set(options, "user_agent", c->user_agent, 0);
>  if (c->http_persistent)
> @@ -1376,6 +1379,7 @@ static const AVOption options[] = {
>  { "init_seg_name", "DASH-templated name to used for the initialization 
> segment", OFFSET(init_seg_name), AV_OPT_TYPE_STRING, {.str = 
> "init-stream$RepresentationID$.m4s"}, 0, 0, E },
>  { "media_seg_name", "DASH-templated name to used for the media 
> segments", OFFSET(media_seg_name), AV_OPT_TYPE_STRING, {.str = 
> "chunk-stream$RepresentationID$-$Number%05d$.m4s"}, 0, 0, E },
>  { "utc_timing_url", "URL of the page that will return the UTC timestamp 
> in ISO format", OFFSET(utc_timing_url), AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
> +{ "method", "set the HTTP method", OFFSET(method), AV_OPT_TYPE_STRING, 
> {.str = NULL}, 0, 0, E },
>  { "http_user_agent", "override User-Agent field in HTTP header", 
> OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>  { "http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
> media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> E },

Thanks for sending the patch. The patch looks fine. 
But, please change the commit message’s prefix from “DASH muxer” to 
“avformat/dashenc”, in order to maintain the uniformity with other commit 
messages.

Regards,
Karthick

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avformat/dashenc: chunk streaming support for low latency use cases

[Jeyapal, Karthick]

On 2/19/18 11:25 AM, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
>
> ---
>  doc/muxers.texi   |  3 +++
>  libavformat/dashenc.c | 26 +++---
>  2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index d9a5cc0..c156ec0 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -254,6 +254,9 @@ Use persistent HTTP connections. Applicable only for HTTP 
> output.
>  @item -hls_playlist @var{hls_playlist}
>  Generate HLS playlist files as well. The master playlist is generated with 
> the filename master.m3u8.
>  One media playlist file is generated for each stream with filenames 
> media_0.m3u8, media_1.m3u8, etc.
> +@item -streaming @var{streaming}
> +Enable (1) or disable (0) chunk streaming mode of output. In chunk streaming
> +mode, each frame will be a moof fragment which forms a chunk.
>  @item -adaptation_sets @var{adaptation_sets}
>  Assign streams to AdaptationSets. Syntax is "id=x,streams=a,b,c 
> id=y,streams=d,e" with x and y being the IDs
>  of the adaptation sets and a,b,c,d and e are the indices of the mapped 
> streams.
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 0eb4b25..d6474f3 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -81,6 +81,7 @@ typedef struct OutputStream {
>  char bandwidth_str[64];
>  
>  char codec_str[100];
> +int written_len;
>  char filename[1024];
>  char full_path[1024];
>  char temp_path[1024];
> @@ -114,6 +115,7 @@ typedef struct DASHContext {
>  int master_playlist_created;
>  AVIOContext *mpd_out;
>  AVIOContext *m3u8_out;
> +int streaming;
>  } DASHContext;
>  
>  static struct codec_string {
> @@ -250,7 +252,8 @@ static int flush_dynbuf(OutputStream *os, int 
> *range_length)
>  // write out to file
>  *range_length = avio_close_dyn_buf(os->ctx->pb, );
>  os->ctx->pb = NULL;
> -avio_write(os->out, buffer, *range_length);
> +avio_write(os->out, buffer + os->written_len, *range_length - 
> os->written_len);
> +os->written_len = 0;
>  av_free(buffer);
>  
>  // re-open buffer
> @@ -960,7 +963,10 @@ static int dash_init(AVFormatContext *s)
>  os->init_start_pos = 0;
>  
>  if (!strcmp(os->format_name, "mp4")) {
> -av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 0);
> +if (c->streaming)
> +av_dict_set(, "movflags", 
> "frag_every_frame+dash+delay_moov", 0);
> +else
> +av_dict_set(, "movflags", 
> "frag_custom+dash+delay_moov", 0);
>  } else {
>  av_dict_set_int(, "cluster_time_limit", c->min_seg_duration 
> / 1000, 0);
>  av_dict_set_int(, "cluster_size_limit", 5 * 1024 * 1024, 
> 0); // set a large cluster size limit
> @@ -1155,7 +1161,7 @@ static int dash_flush(AVFormatContext *s, int final, 
> int stream)
>  }
>  
>  if (!c->single_file) {
> -if (!strcmp(os->format_name, "mp4"))
> +if (!strcmp(os->format_name, "mp4") && !os->written_len)
>  write_styp(os->ctx->pb);
>  } else {
>  snprintf(os->full_path, sizeof(os->full_path), "%s%s", 
> c->dirname, os->initfile);
> @@ -1318,6 +1324,19 @@ static int dash_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  av_dict_free();
>  }
>  
> +//write out the data immediately in streaming mode
> +if (c->streaming && !strcmp(os->format_name, "mp4")) {
> +int len = 0;
> +uint8_t *buf = NULL;
> +if (!os->written_len)
> +write_styp(os->ctx->pb);
> +avio_flush(os->ctx->pb);
> +len = avio_get_dyn_buf (os->ctx->pb, );
> +avio_write(os->out, buf + os->written_len, len - os->written_len);
> +os->written_len = len;
> +avio_flush(os->out);
> +}
> +
>  return ret;
>  }
>  
> @@ -1394,6 +1413,7 @@ static const AVOption options[] = {
>  { "http_user_agent", "override User-Agent field in HTTP header", 
> OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>  { "http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
> media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> E },
> +{ "streaming", "Enable/Disable streaming mode of output. Each frame will 
> be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E 
> },
>  { NULL },
>  };
>  
Patchset pushed.

Regards,
Karthick


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel