1. organize fragmented information according to the tracks.
2. do NOT skip the last boxes of fragmented info.
ticket #7572
To reproduce #7572, need to revert commit
aa25198f1b925a464bdfa83a98476f08d26c9209 first. That commit works for ticket
7572 luckily. However, #7572 has a deeper reason.
2019-03-06 8:46 GMT+01:00, C.H.Liu :
> 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
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
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
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
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
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 | 378 +
2 files changed, 185 insertions(+), 203
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
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
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
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
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
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
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.
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
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
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
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
___
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
On Sun, 10 Feb 2019, Carl Eugen Hoyos wrote:
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
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
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'
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
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
24 matches
Mail list logo
