#7565 closed defect (needs_more_info)
Duplicate framre count in analyze_interlaced_flag option of idet filtrer
| Reported by: | ponpon | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | undetermined |
| Version: | unspecified | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
LL. 288-294 of vf_idet.c
if (idet->last_type == PROGRESSIVE) {
idet->interlaced_flag_accuracy --;
idet->analyze_interlaced_flag --;
} else if (idet->last_type != UNDETERMINED) {
idet->interlaced_flag_accuracy ++;
idet->analyze_interlaced_flag --;
}
Is this a duplicate count of a progressive frame because else if (idet->last_type != UNDETERMINED includes idet->last_type == PROGRESSIVE.
If so, I have a patch for it. Is it needed?
Change History (4)
comment:1 by , 8 years ago
| Resolution: | → needs_more_info |
|---|---|
| Status: | new → closed |
follow-up: 3 comment:2 by , 8 years ago
Sorry for not enough explanation.
The parameter, interlaced_flag_accuracy, is used in accuracy that frames are interlaced or progressive.analyze_interlaced_flag is used to count down frames to research which they are interlaced or progressive.
I think idet offsets accuracy in
if (idet->last_type == PROGRESSIVE) {
idet->interlaced_flag_accuracy --;
and
} else if (idet->last_type != UNDETERMINED) {
idet->interlaced_flag_accuracy ++;
and duplicately counts down frames in
idet->analyze_interlaced_flag --;
and
idet->analyze_interlaced_flag --;
This is because idet->last_type != UNDETERMINED means idet->last_type == PROGRESSIVE, last_type == TFF, or idet->last_type == BFF.
Before my patch (speed=77.6x) is faster than after it (69.5x). Does this means idet terminates researches by double count down? My misunderstanding?
Source: https://media.xiph.org/video/derf/y4m/football_422_ntsc.y4m
Before the patch
ffmpeg -i football_422_ntsc.y4m -vf setfield=tff,idet=intl_thres=1.35:analyze_interlaced_flag=500 -f null -
ffmpeg version N-92499-gfe9b990ec9 Copyright (c) 2000-2018 the FFmpeg developers
built with clang version 5.0.2 (tags/RELEASE_502/final)
configuration: --prefix= --cc=clang-mp-5.0 --cxx=clang++-mp-5.0
libavutil 56. 23.101 / 56. 23.101
libavcodec 58. 39.100 / 58. 39.100
libavformat 58. 22.100 / 58. 22.100
libavdevice 58. 6.100 / 58. 6.100
libavfilter 7. 46.100 / 7. 46.100
libswscale 5. 4.100 / 5. 4.100
libswresample 3. 4.100 / 3. 4.100
Input #0, yuv4mpegpipe, from 'football_422_ntsc.y4m':
Duration: 00:00:12.00, start: 0.000000, bitrate: 167963 kb/s
Stream #0:0: Video: rawvideo (Y42B / 0x42323459), yuv422p(progressive), 720x486, SAR 4320:4379 DAR 6400:4379, 30 fps, 30 tbr, 30 tbn, 30 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf58.22.100
Stream #0:0: Video: wrapped_avframe, yuv422p, 720x486 [SAR 4320:4379 DAR 6400:4379], q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc
Metadata:
encoder : Lavc58.39.100 wrapped_avframe
frame= 360 fps=0.0 q=-0.0 Lsize=N/A time=00:00:12.00 bitrate=N/A speed=77.6x
video:188kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[Parsed_idet_1 @ 0x7fe3dd5004c0] Repeated Fields: Neither: 360 Top: 0 Bottom: 0
[Parsed_idet_1 @ 0x7fe3dd5004c0] Single frame detection: TFF: 0 BFF: 0 Progressive: 342 Undetermined: 18
[Parsed_idet_1 @ 0x7fe3dd5004c0] Multi frame detection: TFF: 0 BFF: 0 Progressive: 360 Undetermined: 0
Before the patch
ffmpeg -i football_422_ntsc.y4m -vf setfield=tff,idet=intl_thres=1.35:analyze_interlaced_flag=500 -f null -
ffmpeg version N-92499-gfe9b990ec9 Copyright (c) 2000-2018 the FFmpeg developers
built with clang version 5.0.2 (tags/RELEASE_502/final)
configuration: --prefix= --cc=clang-mp-5.0 --cxx=clang++-mp-5.0
libavutil 56. 23.101 / 56. 23.101
libavcodec 58. 39.100 / 58. 39.100
libavformat 58. 22.100 / 58. 22.100
libavdevice 58. 6.100 / 58. 6.100
libavfilter 7. 46.100 / 7. 46.100
libswscale 5. 4.100 / 5. 4.100
libswresample 3. 4.100 / 3. 4.100
Input #0, yuv4mpegpipe, from 'football_422_ntsc.y4m':
Duration: 00:00:12.00, start: 0.000000, bitrate: 167963 kb/s
Stream #0:0: Video: rawvideo (Y42B / 0x42323459), yuv422p(progressive), 720x486, SAR 4320:4379 DAR 6400:4379, 30 fps, 30 tbr, 30 tbn, 30 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf58.22.100
Stream #0:0: Video: wrapped_avframe, yuv422p, 720x486 [SAR 4320:4379 DAR 6400:4379], q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc
Metadata:
encoder : Lavc58.39.100 wrapped_avframe
frame= 360 fps=0.0 q=-0.0 Lsize=N/A time=00:00:12.00 bitrate=N/A speed=69.5x
video:188kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[Parsed_idet_1 @ 0x7fb3f3d0ea80] Repeated Fields: Neither: 360 Top: 0 Bottom: 0
[Parsed_idet_1 @ 0x7fb3f3d0ea80] Single frame detection: TFF: 0 BFF: 0 Progressive: 342 Undetermined: 18
[Parsed_idet_1 @ 0x7fb3f3d0ea80] Multi frame detection: TFF: 0 BFF: 0 Progressive: 360 Undetermined: 0
My patch
diff --git a/libavfilter/vf_idet.c b/libavfilter/vf_idet.c
index 02ae2edcb9..8c355ee2f9 100644
--- a/libavfilter/vf_idet.c
+++ b/libavfilter/vf_idet.c
@@ -285,12 +285,14 @@ static int filter_frame(AVFilterLink *link, AVFrame *picref)
if (idet->cur->interlaced_frame) {
idet->cur->interlaced_frame = 0;
filter(ctx);
- if (idet->last_type == PROGRESSIVE) {
- idet->interlaced_flag_accuracy --;
- idet->analyze_interlaced_flag --;
- } else if (idet->last_type != UNDETERMINED) {
- idet->interlaced_flag_accuracy ++;
- idet->analyze_interlaced_flag --;
+ if (idet->last_type != UNDETERMINED) {
+ if (idet->last_type == PROGRESSIVE) {
+ idet->interlaced_flag_accuracy --;
+ idet->analyze_interlaced_flag --;
+ } else {
+ idet->interlaced_flag_accuracy ++;
+ idet->analyze_interlaced_flag --;
+ }
}
if (idet->analyze_interlaced_flag == 1) {
ff_filter_frame(ctx->outputs[0], av_frame_clone(idet->cur));
follow-up: 4 comment:3 by , 8 years ago
Replying to ponpon:
This is because
idet->last_type != UNDETERMINEDmeansidet->last_type == PROGRESSIVE,last_type == TFF, oridet->last_type == BFF.
It is inside of an else clause, so does not apply to idet->last_type == PROGRESSIVE.
Even in the output you provided, the change had no impact on the counts. It is expected that the speed will vary on every run.
comment:4 by , 8 years ago
Replying to MarkZV:
Thank you for your reply.
I think you are right in else {foo}. In the master, not else {foo} but else if (idet->last_type != UNDETERMINED) is used.
I think this results in early termination and a decrease in accuracy.



Please test current FFmpeg git head, provide the complete, uncut console output, an input sample and explain what is wrong about idet's output.