| Message ID | 868dffee-b6d8-82bc-0e35-176de16c7946@vivanet.hu |
|---|---|
| State | Superseded |
| Headers | show |
2017-01-03 19:41 GMT+08:00 Bodecs Bela <bodecsb@vivanet.hu>: > > > 2017.01.03. 11:42 keltezéssel, Moritz Barsnick írta: > >> On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote: >> >>> doc/muxers.texi | 19 ++++++++++++++++++- >>> 1 file changed, 18 insertions(+), 1 deletion(-) >>> >> You should probably squash this with the other patch, into one commit. >> >> -Makes it possible to use segment indexes as %%d besides date/time values >>> when use_localtime is on. >>> +Makes it possible to use segment indexes as %%d in hls_segment_filename >>> expression besides date/time values when use_localtime is on. To get fixed >>> width numbers with trailing zeroes, %%0xd format is available where x is >>> the required width. >>> >> You could break these lines (texinfo formatting will handle the real >> representation later), but I'm not sure it's totally necessary. >> >> +@example >>> +./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 \ >>> + -f lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac >>> -cutoff 20000 -ac 2 -ar 44100 -ab 192k \ >>> + -f hls -hls_time 3 -hls_list_size 5 \ >>> >> a) replace ./ffmpeg with ffmpeg (as most users would expect to use it), >> b) please use simpler syntax for the stuff not related to what you are >> trying to document; i.e.: ffmpeg -i input.mov -f hls -hls_time 3 >> -hls_list_size 5 [...] >> >>> +This will produce segments like this: >>> +@file{segment_20170102194334_0003_00122200_0000003000000.ts}, >>> @file{segment_20170102194334_0004_00120072_0000003000000.ts} etc. >>> >> I have made the suggested modifications. > > The rest seems fine to me! >> >> Moritz >> _______________________________________________ >> 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 > > make to commit into one commit, like this: doc/muxers.texi | 19 ++++++++++++++++++- libavformat/hlsenc.c | 180 ++++++++++++++++++++++++++++++++++++++++++++++++--- in one commit. make one patch.
2017.01.03. 12:48 keltezéssel, Steven Liu írta: > 2017-01-03 19:41 GMT+08:00 Bodecs Bela <bodecsb@vivanet.hu>: > >> >> 2017.01.03. 11:42 keltezéssel, Moritz Barsnick írta: >> >>> On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote: >>> >>>> doc/muxers.texi | 19 ++++++++++++++++++- >>>> 1 file changed, 18 insertions(+), 1 deletion(-) >>>> >>> You should probably squash this with the other patch, into one commit. >>> >>> -Makes it possible to use segment indexes as %%d besides date/time values >>>> when use_localtime is on. >>>> +Makes it possible to use segment indexes as %%d in hls_segment_filename >>>> expression besides date/time values when use_localtime is on. To get fixed >>>> width numbers with trailing zeroes, %%0xd format is available where x is >>>> the required width. >>>> >>> You could break these lines (texinfo formatting will handle the real >>> representation later), but I'm not sure it's totally necessary. >>> >>> +@example >>>> +./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 \ >>>> + -f lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac >>>> -cutoff 20000 -ac 2 -ar 44100 -ab 192k \ >>>> + -f hls -hls_time 3 -hls_list_size 5 \ >>>> >>> a) replace ./ffmpeg with ffmpeg (as most users would expect to use it), >>> b) please use simpler syntax for the stuff not related to what you are >>> trying to document; i.e.: ffmpeg -i input.mov -f hls -hls_time 3 >>> -hls_list_size 5 [...] >>> >>>> +This will produce segments like this: >>>> +@file{segment_20170102194334_0003_00122200_0000003000000.ts}, >>>> @file{segment_20170102194334_0004_00120072_0000003000000.ts} etc. >>>> >>> I have made the suggested modifications. >> The rest seems fine to me! >>> Moritz >>> _______________________________________________ >>> 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 >> >> > make to commit into one commit, > like this: > > doc/muxers.texi | 19 ++++++++++++++++++- > > libavformat/hlsenc.c | 180 > ++++++++++++++++++++++++++++++++++++++++++++++++--- > > in one commit. make one patch. I have technical difficulties to merge them into one commit. I am not a git expert. This muxers.texi patch is based on my earlier accepted, but yet not applied doc patch on this same file. I created the related code patch in a different local git branch. Now I tried to merge the two local branches into one but a terrible result occured when I created a common patch file. Is it a problem to remain two seperate patches? > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Tue, Jan 03, 2017 at 13:38:44 +0100, Bodecs Bela wrote: > I have technical difficulties to merge them into one commit. I am not a > git expert. > This muxers.texi patch is based on my earlier accepted, but yet not > applied doc patch on this same file. > I created the related code patch in a different local git branch. Now I > tried to merge the two local branches into one > but a terrible result occured when I created a common patch file. I usually work on a local branch: feature-soandso.01 If I want to rearrange the patches, I create a new branch from master: $ git checkout master $ git pull $ git checkout -b feature-soandso.02 then I can e.g. reintegrate those two commits as one: $ git cherry-pick --no-commit <hash of first commit from feature-soandso.01> $ git cherry-pick --no-commit <hash of second commit from feature-soandso.01> $ git commit # don't forget to re-edit the now merged commit messages and then I (re-)submit that last commit from this new branch to the mailing list. (Untested, from memory.) Good luck. > Is it a problem to remain two seperate patches? I don't declare the recommendations on this list, I just interpret them. ;-) Generally, there's no use in separating the doc from the feature commit. Moritz
2017-01-03 20:52 GMT+08:00 Moritz Barsnick <barsnick@gmx.net>: > On Tue, Jan 03, 2017 at 13:38:44 +0100, Bodecs Bela wrote: > > I have technical difficulties to merge them into one commit. I am not a > > git expert. > > This muxers.texi patch is based on my earlier accepted, but yet not > > applied doc patch on this same file. > > I created the related code patch in a different local git branch. Now I > > tried to merge the two local branches into one > > but a terrible result occured when I created a common patch file. > > I usually work on a local branch: feature-soandso.01 > If I want to rearrange the patches, I create a new branch from master: > > $ git checkout master > $ git pull > $ git checkout -b feature-soandso.02 > > then I can e.g. reintegrate those two commits as one: > > $ git cherry-pick --no-commit <hash of first commit from > feature-soandso.01> > $ git cherry-pick --no-commit <hash of second commit from > feature-soandso.01> > $ git commit # don't forget to re-edit the now merged commit messages > > and then I (re-)submit that last commit from this new branch to the > mailing list. > > (Untested, from memory.) Good luck. > > > Is it a problem to remain two seperate patches? > > I don't declare the recommendations on this list, I just interpret > them. ;-) Generally, there's no use in separating the doc from the > feature commit. > > Moritz > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > try Moritz's way, and test base the attachement file maybe better.
From 4d12c80ad8db7040053a2dbf52a7634fe7fca960 Mon Sep 17 00:00:00 2001 From: Bela Bodecs <bodecsb@vivanet.hu> Date: Tue, 3 Jan 2017 09:34:38 +0100 Subject: [PATCH] doc/muxers: hls second_level_segment_duration, second_level_segment_size Documentation of new feature of hlsenc to include segment size and duration in their name. Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu> --- doc/muxers.texi | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/doc/muxers.texi b/doc/muxers.texi index 018f289..b4a107c 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -584,7 +584,29 @@ seeking. This flag should be used with the @code{hls_time} option. Generate @code{EXT-X-PROGRAM-DATE-TIME} tags. @item second_level_segment_index -Makes it possible to use segment indexes as %%d besides date/time values when use_localtime is on. +Makes it possible to use segment indexes as %%d in hls_segment_filename expression +besides date/time values when use_localtime is on. +To get fixed width numbers with trailing zeroes, %%0xd format is available where x is the required width. + +@item second_level_segment_size +Makes it possible to use segment sizes (counted in bytes) as %%s in hls_segment_filename +expression besides date/time values when use_localtime is on. +To get fixed width numbers with trailing zeroes, %%0xs format is available where x is the required width. + +@item second_level_segment_duration +Makes it possible to use segment duration (calculated in microseconds) as %%t in hls_segment_filename +expression besides date/time values when use_localtime is on. +To get fixed width numbers with trailing zeroes, %%0xt format is available where x is the required width. + +@example +ffmpeg -i sample.mpeg \ + -f hls -hls_time 3 -hls_list_size 5 \ + -hls_flags second_level_segment_index+second_level_segment_size+second_level_segment_duration \ + -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename "segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8 +@end example +This will produce segments like this: +@file{segment_20170102194334_0003_00122200_0000003000000.ts}, @file{segment_20170102194334_0004_00120072_0000003000000.ts} etc. + @end table -- 2.5.3.windows.1