Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fps incorrectly detected on Sony interlaced file #898

Open
j-b-m opened this issue Apr 4, 2023 · 2 comments
Open

Fps incorrectly detected on Sony interlaced file #898

j-b-m opened this issue Apr 4, 2023 · 2 comments

Comments

@j-b-m
Copy link
Contributor

j-b-m commented Apr 4, 2023

Fps is incorrectly guessed on some camcorder files. A sample video can be downloaded from here:
https://files.kde.org/kdenlive/media-samples/C0437.MXF

This is an interlaced video file. Fps is incorrectly guessed as 12.5 fps instead of 25 fps. Looking at it, the problem is that MLT uses the stream's avg_frame_rate to determine the fps.

Here are the stream data for this file:
avg_frame_rate = 25/2
r_frame_rate = 25/1
time_base = 1/25

I guess simply switching from avg_frame_rate to r_frame_rate would hurt other files, so my proposal (but I am by far not an expert here), would be to compare the time_base with both avg_frame_rate and r_frame_rate to decide which one is correct.

Here is a basic patch fixing fps detection and playback for me:
master...j-b-m:mlt:work/fps-fix

Let me know if you want me to make other tests.

Another problem is that we cannot simply fix the problem of this clip by setting force_fps=25, because this incorrectly modifies the video_time_base here:
https://github.com/mltframework/mlt/blob/master/src/modules/avformat/producer_avformat.c#L2631

So currently there is no way to play this file correctly.

@ddennedy
Copy link
Member

ddennedy commented Apr 4, 2023

One option is to do nothing special for weird files like this and require transcode to use. We already have enough special frame rate logic as it is at this location. It seems ffmpeg defaults to using r_frame_rate when using it to transcode. One could argue that is what we should use as well, but I worry about that big of a change in this area after 19 years of evolution. Plus, it would make some things that appear variable frame rate today (strange fps value) as perfectly normal when perhaps they should be used with caution.

@bmatherly
Copy link
Member

bmatherly commented Apr 4, 2023

Maybe you should look into why FFMpeg reports avg_frame_rate = 25/2. Perhaps it is incorrectly interpreting the frame rate as field rate and dividing by 2.

Here is the output from FFProbe:


Input #0, mxf, from 'c:\Users\Owner\Downloads\C0437.MXF':
  Metadata:
    operational_pattern_ul: 060e2b34.04010101.0d010201.01010900
    uid             : ea043194-8ff9-11ed-b95c-080046986465
    generation_uid  : ea04319e-8ff9-11ed-9886-080046986465
    company_name    : Sony
    product_name    : Mem
    product_version : 2.00
    product_uid     : cede1104-8280-11de-8a39-08004678031c
    modification_date: 2023-01-09T08:45:05.000000Z
    material_package_umid: 0x060A2B340101010501010D43130000009D4F595D539905D80800460202986465
    timecode        : 08:45:05:05
  Duration: 00:00:05.36, start: 0.000000, bitrate: 42098 kb/s
  Stream #0:0: Video: h264 (High 4:2:2), yuv422p10le(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 12.50 fps, 25 tbr, 25 tbn

It reports "12.50 fps". Let's fix that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants