Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Yes. Patch aa25198f1b925a464bdfa83a98476f08d26c9209 works to ticket 7572 luckily. To reproduce #7572, need to revert this patch first. As we talked, #7572 has a deeper reason. Mov demuxer consider that fragmented index is completed if a ‘sidx’ point to the end of the file. But there may be other ‘sidx’ for other tracks. If we skip the tail from there, we will missing the last ‘sidx’ and ‘moof’. Then AV_NOPTS_VALUE occurs. On Wed, Mar 6, 2019 at 2:35 AM Anthony Recascino wrote: > the bug that caused the hang is absolutely still present, the fix that was > pushed was only fixing the surface level issue of the hang. > > > > On Mar 5, 2019, at 11:28 AM, Carl Eugen Hoyos > wrote: > > > > 2019-03-05 17:02 GMT+01:00, Charles Liu : > >> 1. organize fragmented information according to the tracks. > >> 2. do NOT skip the last boxes of fragmented info. > > > >> ticket #7572 > > > > Assuming the ticket is not reproducible for you with current > > FFmpeg git head (it wasn't for me two weeks ago), please > > reword this so it is clear you saw an issue looking at this > > ticket (and its fix) but that this commit does not fix a bug > > that is still reproducible with the files and command line(s) > > provided there. > > > > Or do I misunderstand? > > > > Carl Eugen > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Thanks for your reply.
If a track id of the test clip does not appear in its ‘moov’, the do/while
loop cannot exit indeed.
The purpose of this patch is to solve AV_NOPTS_VALUE in the fragment info
structure. Because the original structures is oriented to ‘moof’ boxes in
file. I tried to organize fragment info according to media tracks.
Since the fragment structures has been changed, it fixes two other issues.
One is #7572, which missed the last ‘sidx’ and ‘moof’.
The other is “mov->fragment.stsd_id == 1” in function cenc_filter(). Mov
muxer read all ‘moof’ while reading header. So the current fragment points
to the last ‘moof’. When we read packets/samples from the beginning, the
sample (belongs to the first ‘moof’) and the current fragment info do not
match.
I don’t mind waiting for other options. And we already have a quick fix
aa25198f1b925a464bdfa83a98476f. Though, I will still update the patch to
resolve the endless loop problem.
BTW, I have’t modified other commit messages. The frag index variable is
changed in isom.h.
Thanks again, and sorry for late response.
Regards,
Charles.
On Wed, Feb 27, 2019 at 9:39 PM Michael Niedermayer
wrote:
> On Mon, Feb 25, 2019 at 07:07:27PM +0800, C.H.Liu wrote:
> > Would you mind share your input file? I still can’t reproduce the OOM.
>
> i belive i cannot share this sample, but the patch really needs to be
> fully reviewed not just one bug that was found by chance fixed otherwise
> we might be missing other bugs ...
>
>
> >
> >
> > I have tried several types of mp4.
> >
> > I also tried to create a file like yours. According to the snapshot,
> seems
> > it has no ‘sidx’ box and enable ‘use_mfra_for’.
> >
> > Massif didn’t report update_frag_index() function. I didn’t see an extra
> > heap as big as here, either.
>
> looking at the sample that triggers the OOM the do/while loop you add
> to update_frag_index() is entered and never exits while doing allocations
> in it.
>
> also the patch as is is not ok. You for example have a list of unrelated
> changes in the commit message. Each should be in its own patch
> also changes that are functional should be splited from non functional
> changes. For example here:
>
> // If moof_offset already exists in frag_index, return index to it
> -index = search_frag_moof_offset(&c->frag_index, offset);
> -if (index < c->frag_index.nb_items &&
> -c->frag_index.item[index].moof_offset == offset)
> +index = search_frag_moof_offset(frag_index, offset);
> +if (index < frag_index->nb_items &&
> +frag_index->item[index].moof_offset == offset) {
> +frag_index->current = index;
> return index;
> +}
>
> you change frag_index to a local variable this is non functional and
> should not be in a patch that does a functional change ideally.
> Now sure if a functional change is trivial and clear such things are
> sometimes done together but this patch is not clear, at least its not
> clear to me ...
>
> thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I do not agree with what you have to say, but I'll defend to the death your
> right to say it. -- Voltaire
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Attach one of my massif outputs. The max memory usage is approximately 22.05MB. And the *extra *heap is not too big. The peak snapshot is the 7th. The H.264 decoder is responsible for 86.11% of the memory usage. The update_frag_index is responsible for 78,264 bytes. And the relevant code is at line 1276 instead of line 1257. In my opinion, this is usual. It create fragment items for every ‘moof’. Thanks and Regards, Charles On Mon, Feb 25, 2019 at 7:07 PM C.H.Liu wrote: > Would you mind share your input file? I still can’t reproduce the OOM. > > > I have tried several types of mp4. > > I also tried to create a file like yours. According to the snapshot, seems > it has no ‘sidx’ box and enable ‘use_mfra_for’. > > Massif didn’t report update_frag_index() function. I didn’t see an extra > heap as big as here, either. > > > The code around line 1257 creates an array of fragment indices for each > track. It should be very small. Interesting. > > Sorry for disturbing. > > > Thanks and Regards, > > Charles > > Michael Niedermayer 于2019年2月23日周六 下午5:35写道： > >> On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote: >> > I can’t reproduce the OOM. Is it possible the problem relate to a >> specific >> > clip? >> > >> > Here is my test steps: >> > 1. To ensure that it’s not affected by caches, delete all except the >> .git >> > dir in my code dir. Then checkout again. >> > 2. To ensure that the latest test clips are used. make fate-rsync >> > SAMPLES=fate-suite/ >> > 3. To ensure that OS environment is clean, run test in docker. >> > Below is one of my test logs: >> >> heres some massif output that should show where the exessive allocation >> happens: >> (note the box has 14gb free and the input file is less than 4kb size) >> >> snapshot=70 >> #--- >> time=1856698079 >> mem_heap_B=8487679 >> mem_heap_extra_B=522580313 >> mem_stacks_B=0 >> heap_tree=peak >> n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns, >> etc. >> n2: 8298639 0x12AAF2B: av_malloc (mem.c:87) >> n1: 8294364 0x12AAF59: av_malloc (mem.c:126) >>n1: 8294364 0x12AB24B: av_mallocz (mem.c:238) >> n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195) >> n1: 8294364 0x743749: update_frag_index (mov.c:1257) >> n1: 8294364 0x756174: read_tfra (mov.c:7293) >>n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344) >> n1: 8294364 0x743B01: mov_read_moof (mov.c:1338) >> n1: 8294364 0x754A0C: mov_read_default (mov.c:6841) >> n1: 8294364 0x756596: mov_read_header (mov.c:7385) >>n1: 8294364 0x8254BB: avformat_open_input (utils.c:631) >> n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104) >> n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273) >> n1: 8294364 0x41F7F8: ffmpeg_parse_options >> (ffmpeg_opt.c:3313) >>n0: 8294364 0x43DFC6: main (ffmpeg.c:4869) >> n0: 4275 in 7 places, all below massif's threshold (01.00%) >> n0: 189040 in 8 places, all below massif's threshold (01.00%) >> >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> Its not that you shouldnt use gotos but rather that you should write >> readable code and code with gotos often but not always is less readable >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > massif.out.63483.tar.bz2 Description: BZip2 compressed data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
Would you mind share your input file? I still can’t reproduce the OOM. I have tried several types of mp4. I also tried to create a file like yours. According to the snapshot, seems it has no ‘sidx’ box and enable ‘use_mfra_for’. Massif didn’t report update_frag_index() function. I didn’t see an extra heap as big as here, either. The code around line 1257 creates an array of fragment indices for each track. It should be very small. Interesting. Sorry for disturbing. Thanks and Regards, Charles Michael Niedermayer 于2019年2月23日周六 下午5:35写道： > On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote: > > I can’t reproduce the OOM. Is it possible the problem relate to a > specific > > clip? > > > > Here is my test steps: > > 1. To ensure that it’s not affected by caches, delete all except the .git > > dir in my code dir. Then checkout again. > > 2. To ensure that the latest test clips are used. make fate-rsync > > SAMPLES=fate-suite/ > > 3. To ensure that OS environment is clean, run test in docker. > > Below is one of my test logs: > > heres some massif output that should show where the exessive allocation > happens: > (note the box has 14gb free and the input file is less than 4kb size) > > snapshot=70 > #--- > time=1856698079 > mem_heap_B=8487679 > mem_heap_extra_B=522580313 > mem_stacks_B=0 > heap_tree=peak > n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns, etc. > n2: 8298639 0x12AAF2B: av_malloc (mem.c:87) > n1: 8294364 0x12AAF59: av_malloc (mem.c:126) >n1: 8294364 0x12AB24B: av_mallocz (mem.c:238) > n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195) > n1: 8294364 0x743749: update_frag_index (mov.c:1257) > n1: 8294364 0x756174: read_tfra (mov.c:7293) >n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344) > n1: 8294364 0x743B01: mov_read_moof (mov.c:1338) > n1: 8294364 0x754A0C: mov_read_default (mov.c:6841) > n1: 8294364 0x756596: mov_read_header (mov.c:7385) >n1: 8294364 0x8254BB: avformat_open_input (utils.c:631) > n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104) > n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273) > n1: 8294364 0x41F7F8: ffmpeg_parse_options > (ffmpeg_opt.c:3313) >n0: 8294364 0x43DFC6: main (ffmpeg.c:4869) > n0: 4275 in 7 places, all below massif's threshold (01.00%) > n0: 189040 in 8 places, all below massif's threshold (01.00%) > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Its not that you shouldnt use gotos but rather that you should write > readable code and code with gotos often but not always is less readable > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
I can’t reproduce the OOM. Is it possible the problem relate to a specific clip? Here is my test steps: 1. To ensure that it’s not affected by caches, delete all except the .git dir in my code dir. Then checkout again. 2. To ensure that the latest test clips are used. make fate-rsync SAMPLES=fate-suite/ 3. To ensure that OS environment is clean, run test in docker. Below is one of my test logs: > /ffmpeg_src# valgrind --leak-check=full ./ffmpeg -i issue/dash.mp4 -map 0 > -f null - > > *==8552== Memcheck, a memory error detector* > *==8552== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.* > *==8552== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright > info* > *==8552== Command: ./ffmpeg -i issue/dash.mp4 -map 0 -f null -* > *==8552== * > *ffmpeg version 4.1.git Copyright (c) 2000-2019 the FFmpeg developers* > * built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)* > * configuration: --samples=fate-suite/ --disable-doc --fatal-warnings > --valgrind=VALGRIND* > * libavutil 56. 26.100 / 56. 26.100* > * libavcodec 58. 47.102 / 58. 47.102* > * libavformat58. 26.101 / 58. 26.101* > * libavdevice58. 6.101 / 58. 6.101* > * libavfilter 7. 48.100 / 7. 48.100* > * libswscale 5. 4.100 / 5. 4.100* > * libswresample 3. 4.100 / 3. 4.100* > *Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'issue/dash.mp4':* > * Metadata:* > *major_brand : iso5* > *minor_version : 512* > *compatible_brands: iso6mp41* > *encoder : Lavf58.20.100* > * Duration: 00:00:57.76, start: 0.00, bitrate: 5193 kb/s* > *Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, > smpte170m/bt709/bt709), 1280x720, 5125 kb/s, 25 fps, 25 tbr, 250k tbn, 50 > tbc (default)* > *Metadata:* > * handler_name: VideoHandler* > *Stream #0:1(und): Audio: aac (HE-AAC) (mp4a / 0x6134706D), 44100 Hz, > stereo, fltp, 79 kb/s (default)* > *Metadata:* > * handler_name: SoundHandler* > *Stream mapping:* > * Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))* > * Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))* > *Press [q] to stop, [?] for help* > *Output #0, null, to 'pipe:':ze=N/A time=-577014:32:22.77 bitrate=N/A > speed=N/A* > * Metadata:* > *major_brand : iso5* > *minor_version : 512* > *compatible_brands: iso6mp41* > *encoder : Lavf58.26.101* > *Stream #0:0(und): Video: wrapped_avframe, yuv420p(progressive), > 1280x720, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)* > *Metadata:* > * handler_name: VideoHandler* > * encoder : Lavc58.47.102 wrapped_avframe* > *Stream #0:1(und): Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s > (default)* > *Metadata:* > * handler_name: SoundHandler* > * encoder : Lavc58.47.102 pcm_s16le* > *frame= 1438 fps=5.0 q=-0.0 Lsize=N/A time=00:00:57.68 bitrate=N/A > speed=0.202x* > *video:753kB audio:9904kB subtitle:0kB other streams:0kB global > headers:0kB muxing overhead: unknown* > *==8552== * > *==8552== HEAP SUMMARY:* > *==8552== in use at exit: 0 bytes in 0 blocks* > *==8552== total heap usage: 207,112 allocs, 207,112 frees, 121,288,827 > bytes allocated* > *==8552== * > *==8552== All heap blocks were freed -- no leaks are possible* > *==8552== * > *==8552== For counts of detected and suppressed errors, rerun with: > -v**==8552== > ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)* BTW, below is my dockefile. It show that the installed dependences. And how to configure and test. *FROM ubuntu:18.04* *RUN apt-get update -qq && apt-get dist-upgrade -qy* *RUN apt-get -qy install autoconf automake build-essential cmake libass-dev libfreetype6-dev libtool libvorbis-dev pkg-config texinfo zlib1g-dev \* * libnuma-dev* *RUN apt-get -qy install yasm libx264-dev libx265-dev libfdk-aac-dev* *RUN apt-get -qy install valgrind* *COPY . /ffmpeg_src/* *WORKDIR /ffmpeg_src* *RUN make distclean* *RUN ./configure --samples=fate-suite/ --disable-doc --fatal-warnings --valgrind=VALGRIND* *RUN make -j3 && make fate* *CMD ["/bin/bash"]* Michael Niedermayer 于2019年2月23日周六 上午8:25写道： > On Fri, Feb 22, 2019 at 06:20:40PM +0800, Charles Liu wrote: > > 1. organize fragmented information according to the tracks. > > 2. do NOT skip the last boxes of fragmented info. > > > > ticket #7572 > > > > Signed-off-by: Charles Liu > > --- > > libavformat/isom.h | 10 +- > > libavformat/mov.c | 374 + > > 2 files changed, 181 insertions(+), 203 deletions(-) > > still hitting out of memory and being killed by the kernel > the other issue seems to be fixed though > > thx > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > ___ > ffmpeg-devel mailing list >
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
I have updated a new patch that has passed valgrind as follows: *$ ./configure --samples=fate-suite/ --disable-doc --fatal-warnings --valgrind=VALGRIND* *$ make -j4 && make fate-mov* But I never encountered a ‘stream 0, timescale not set’ log in here. Please let me know if you have any questions. Sorry for the previous trouble. Thanks and Regards, Charles Liu Michael Niedermayer 于2019年2月22日周五 上午9:40写道： > On Wed, Feb 20, 2019 at 11:54:56PM +0800, Charles Liu wrote: > > 1. organize fragmented information according to the tracks. > > 2. do NOT skip the last boxes of fragmented info. > > > > ticket #7572 > > > > Signed-off-by: Charles Liu > > --- > > libavformat/isom.h | 10 +- > > libavformat/mov.c | 375 ++--- > > 2 files changed, 185 insertions(+), 200 deletions(-) > > this causes OOM and crashes > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 0, timescale not set > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] stream 1, timescale not set > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3796f00] error reading header > *** Error in `./ffmpeg': double free or corruption (fasttop): > 0x0379b100 *** > Aborted (core dumped) > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
There was a quick solution at aa25198f1b925a464bdfa83a98476f08d26c9209, which luckily works for #7572. To reproduce issue, you can switch to the commit just before it. As we discussed, #7572 has a deeper reason. We missed the last ‘sidx’ and ‘moof’ boxes. This patch try to fix AV_NOPTS_VALUE in fragmented info structure. It may be caused by missing boxes. Or the fragmented structures are not suitable for separate audio and video ‘moof’. Thanks and Regards, Charles Liu Carl Eugen Hoyos 于2019年2月21日周四 上午7:33写道： > 2019-02-20 16:54 GMT+01:00, Charles Liu : > > 1. organize fragmented information according to the tracks. > > 2. do NOT skip the last boxes of fragmented info. > > > > ticket #7572 > > How can I reproduce the hang with current FFmpeg git head? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
It is lucky that my patch works to ticket 7572. However, #7572 has a deeper
reason.
Mov demuxer consider that fragmented index is completed if a ‘sidx’ point
to the end of the file. But there may be other ‘sidx’ for other tracks. If
we skip the tail from there, we will missing the last ‘sidx’ and ‘moof’.
Then AV_NOPTS_VALUE occurs.
I tried to avoid skipping the tail simply. However, fate-test run failed on
mov-frag-encrypted.mp4.
BTW, I just got back from vacation. I am willing to follow an optimized
solution.
Thanks and Regards,
Chenhui
Carl Eugen Hoyos 于2019年2月11日周一 上午6:24写道：
> 2019-02-10 23:04 GMT+01:00, Marton Balint :
> >
> >
> > On Sun, 3 Feb 2019, Charles Liu wrote:
> >
> >> Binary searching would hang if the fragment items do NOT have timestamp
> >> for the specified stream.
> >>
> >> For example, a fmp4 consists of separated 'moof' boxes for each track,
> and
> >> separated 'sidx' for each segment, but no 'mfra' box.
> >> Then every fragment item only have the timestamp for one of its tracks.
> >>
> >> Signed-off-by: Charles Liu
> >> ---
> >> libavformat/mov.c | 21 -
> >> 1 file changed, 12 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index 9b9739f788..35cb619e9f 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -1266,7 +1266,7 @@ static int64_t get_frag_time(MOVFragmentIndex
> >> *frag_index,
> >> static int search_frag_timestamp(MOVFragmentIndex *frag_index,
> >> AVStream *st, int64_t timestamp)
> >> {
> >> -int a, b, m;
> >> +int a, b, m, m0;
> >> int64_t frag_time;
> >> int id = -1;
> >>
> >> @@ -1282,15 +1282,18 @@ static int
> search_frag_timestamp(MOVFragmentIndex
> >> *frag_index,
> >> b = frag_index->nb_items;
> >>
> >> while (b - a > 1) {
> >> -m = (a + b) >> 1;
> >> -frag_time = get_frag_time(frag_index, m, id);
> >> -if (frag_time != AV_NOPTS_VALUE) {
> >> -if (frag_time >= timestamp)
> >> -b = m;
> >> -if (frag_time <= timestamp)
> >> -a = m;
> >> -}
> >> +m0 = m = (a + b) >> 1;
> >> +
> >> +while (m < b &&
> >> + (frag_time = get_frag_time(frag_index, m, id)) ==
> >> AV_NOPTS_VALUE)
> >> +m++;
> >> +
> >> +if (m < b && frag_time <= timestamp)
> >> +a = m;
> >> +else
> >> +b = m0;
> >> }
> >> +
> >> return a;
> >> }
> >>
> >
> > As this fixes a hang, I will push this version soon.
>
> Please mention ticket #7572 in the commit message.
>
> Thank you, Carl Eugen
> ___
> 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] lavf/mov: fix hang while seek on a kind of fragmented mp4.
I also think it would be better if we store pts-es in different lists for each track. However, it does NOT match the original design of data structures. Several boxes will be affected. So I am trying to commit this patch to discuss with maintainers. At present, I prefer the last version patch(fall back to linear searching only if needed). I could research more later. Thanks and Regards, Charles Liu Marton Balint 于2019年2月5日周二 上午4:42写道： > > > On Mon, 4 Feb 2019, Michael Niedermayer wrote: > > > On Sat, Feb 02, 2019 at 05:03:25PM +0100, Marton Balint wrote: > >> > >> > >> On Sat, 2 Feb 2019, Charles Liu wrote: > >> > >>> Binary searching would hang if the fragment items do NOT have > timestamp for the specified stream. > >>> > >>> For example, a fmp4 consists of separated 'moof' boxes for each track, > and separated 'sidx' for each segment, but no 'mfra' box. > >>> Then every fragment item only have the timestamp for one of its tracks. > >> > >> I don't see why you are changing the search to be linear. Is it > possible the > >> some of the stream fragmens have NOPTS_VALUE but other don't? In this > case > >> you should keep the binary search and only fall back to linear search if > >> binary search finds an AV_NOPTS_VALUE. See similar code in function > >> mxf_absolute_bodysid_offset of libavformat/mxfdec.c. > > > > The point of binary searching is to achieve O(log n) time > > if there is any linear search this is no longer achieved. > > So its not ideal to have any AV_NOPTS_VALUE in the array that is > > searched. It would be better if the unknown entries are not in the > > array that is used for the search or if their value is monotonized > > once for all searches > > that being ideal at least ... > > Yeah that is true, but that would require maintaining a different array > with pts-es, and getting/updating fragment pts-es are complicated as is. > > Considering that this fixes a hang, I'd rather see the last version of the > patch applied than wait for a more complicated, yet faster implementation. > > Regards, > Marton > ___ > 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/hlsenc: fix the duration of m4s segment is unusually smaller than expected.
My test clip is big_buck_bunny_1080p_h264.mov with CMD:
./ffmpeg -i ~/Downloads/conversion/big_buck_bunny_1080p_h264.mov -t 50
-flags +cgop -g 30 -preset superfast -f hls -hls_segment_type fmp4
-hls_playlist_type vod -hls_time 10 issue/pl.m3u8
The original result is:
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="init.mp4"
#EXTINF:10.416667,
pl0.m4s
#EXTINF:1.25,
pl1.m4s
#EXTINF:9.08,
pl2.m4s
#EXTINF:9.791667,
pl3.m4s
#EXTINF:10.00,
pl4.m4s
#EXTINF:9.458333,
pl5.m4s
#EXT-X-ENDLIST
After apply the patch, the result become to:
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="init.mp4"
#EXTINF:10.416667,
pl0.m4s
#EXTINF:10.33,
pl1.m4s
#EXTINF:9.791667,
pl2.m4s
#EXTINF:10.00,
pl3.m4s
#EXTINF:9.458333,
pl4.m4s
#EXT-X-ENDLIST
Seems that the vs→number in function hls_write_packet() was minus once
more. Then “end_pts = hls->recording_time * vs→number;” was too small.
After having enough buffer (av_compare_ts() around line 2189), we generate
the init.mp4 firstly, then the first segment. It should be generate the
second segment, when we DO have enough buffer for the second time, .
However, the end_pts dons’t grow any, because the vs→number was subtracted
1.
Liu Steven 于2018年10月9日周二 下午3:28写道：
>
>
> > 在 2018年10月9日，下午3:17，Liu Steven 写道：
> >
> >
> >
> >> 在 2018年10月9日，下午2:56，Charles Liu 写道：
> >>
> >> In fmp4 mode, the duration of the second m4s segment is unusually
> smaller than the expected segment time.
> >>
> >> Signed-off-by: Charles Liu
> >> ---
> >> libavformat/hlsenc.c | 4
> >> 1 file changed, 4 deletions(-)
> >>
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index 28c2dd62fc..3ccd8756f6 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -2233,10 +2233,6 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> >>}
> >>}
> >>
> >> -if (vs->fmp4_init_mode) {
> >> -vs->number--;
> >> -}
> >
> > No, this is reserve, will be used by byterange mode
>
> Ah, sorry my mistake, it is because the when the init.mp4 is not in the
> sequence, so the start number should be 0.
> >> -
> >>if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> >>if (hls->flags & HLS_SINGLE_FILE) {
> >>ret = flush_dynbuf(vs, &range_length);
> >> --
> >> 2.19.1
> >>
> >> ___
> >> 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
