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
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
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
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
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.
800, 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 ag
, 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 mig
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
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
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
10 matches
Mail list logo
