search

tanersener / mobile-ffmpeg

FFmpeg for Android, iOS and tvOS. Not maintained anymore. Superseded by FFmpegKit.
https://tanersener.github.io/mobile-ffmpeg
GNU General Public License v3.0
3.85k stars 787 forks source link

Progress starts at 80% #648

Closed hudek closed 3 years ago

hudek commented 3 years ago

Description

Hello, I'm cutting 1 second video from 5 minute video using "-y -i [input_file] -ss 0.0 -t 1.0 ..." and the progress is gives wrong values.

Expected behavior

The progress (statistics.getTime()) should return eg 0, 200, 450, 600, 850, 1000 (millis).

Current behavior

The progress (statistics.getTime()), starts at 0. However first non zero time 832 (millis). After that it keeps in this value until progress is 1. If I use shorter input video (15s e.g.), the progress is working great.

Logs

x265 [info]: HEVC encoder version 3.4 x265 [info]: build info [Mac OS X][clang 7.3.0][32 bit][noasm] 8bit x265 [info]: using cpu capabilities: NEON x265 [info]: Main profile, Level-4 (Main tier) x265 [info]: Thread pool created using 2 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 1 / wpp(34 rows) x265 [info]: Coding QT: max CU size, min CU size : 32 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 1 / 2 x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 0 x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0 x265 [info]: References / ref-limit cu / depth : 1 / off / off x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1 x265 [info]: Rate Control / qCompress : CRF-24.0 / 0.60 x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp x265 [info]: tools: fast-intra strong-intra-smoothing lslices=6 deblock

x265 [info]: frame I: 1, Avg QP:27.47 kb/s: 4711.96 x265 [info]: frame P: 6, Avg QP:27.79 kb/s: 1653.32 x265 [info]: frame B: 17, Avg QP:31.12 kb/s: 322.95
x265 [info]: consecutive B-frames: 14.3% 0.0% 14.3% 71.4%

encoded 24 frames in 7.36s (3.26 fps), 838.42 kb/s, Avg QP:30.14

Environment

Thank you

HonzaR commented 3 years ago

Hi guys,

I'm experiencing this issue too, please can someone advice us. Thank you.

Honza

HonzaR commented 3 years ago

Hi all, any update on this bug? @tanersener would you mind to check this please?

tanersener commented 3 years ago

I don't have enough information to make a comment about this issue. See #132.

hudek commented 3 years ago

Hi, i just edited the question. Thank you

tanersener commented 3 years ago

Expected behavior

The progress (statistics.getTime()) should return eg 0, 200, 450, 600, 850, 1000 (millis).

Your expected behaviour is not correct. StatisticsCallback is called whenever ffmpeg generates a report for your execution. If ffmpeg doesn't generate a report you will not receive a new Statistics entry. This is what happens there. There are only two reports generated for your command. One at time=0 and one at time=0.8.

Technically, print_report method in fftools_ffmpeg.c is responsible of generating a report. As you can see from the source code, it is called after each transcode_step and you can not force ffmpeg to generate a new report in the middle of the transcoding.

tanersener commented 3 years ago

This project will be retired. Please consider switching to FFmpegKit.