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 t
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 ‘s
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 tra
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 t
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 f
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 othe
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 l
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 a
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 en
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-
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.
S
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 f
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
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 eac
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' for
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
19 matches
Mail list logo