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

video/filter: Restore the previously removed tfields filter. #532

Closed
wants to merge 1 commit into from

Conversation

munousha
Copy link

@munousha munousha commented Feb 8, 2014

I disagree with the conclusion of Issue #19 since afaict none of the libpostproc filters provide deinterlacing which doubles the frame rate to match the field rate of the stream. Yadif is just too CPU hungry for HD content for my machine to keep up with.

Since I will be using the tfields filter myself I might as well send the patch upstream.

Compared to the original version it has been updated with code from yadif to use the real delta when calculating the PTS for extra frames instead of using a hardcoded value.

Please pull!

Updated with code from vf_yadif.c to use the real delta when calculating
the PTS for extra frames instead of using a hardcoded value.
@ghost
Copy link

ghost commented Feb 8, 2014

Can you check that there is no libavfilter (via vf_lavfi) filter that can do what you want?

Does the MMX asm actually help? The asm would be the biggest argument against readding this filter, because it's a maintenance nightmare.

@munousha
Copy link
Author

munousha commented Feb 9, 2014

There are no other filters available that can be compared function/performance wise to this in libpostproc or lavfi.

Since you asked I tried to use the _C equivalents of the _MMX* functions. CPU usage goes up 2.5 times, making the filter unusable for me.

Note that many of the other video filters also have asm functions (for obvious reasons).

@ghost
Copy link

ghost commented Feb 9, 2014

More things to check:

  • Are you using vdpau or vaapi? These have builtin deinterlacers.
  • Try --vf=lavfi=[kerndeint]
  • Try --vf=lavfi=[separatefields,setdar=16/9] (separatefields doesn't do scaling, but adjusting the pixel aspect can make the VO do the scaling - this assumes input is 16:9, probably needs adjustment if it isn't)

@ghost
Copy link

ghost commented Feb 9, 2014

  • Try --vf=lavfi=[yadif=mode=send_field_nospatial] (unlike normal yadif, this doubles the frame rate, but the option also makes it faster by skipping certain checks)

@ghost
Copy link

ghost commented Feb 9, 2014

Merged, with subject modified to contain "vo_opengl:" prefix.

@ghost ghost closed this Feb 9, 2014
@ghost
Copy link

ghost commented Feb 9, 2014

Damn, wrong pull request. Sorry.

@ghost ghost reopened this Feb 9, 2014
@ghost
Copy link

ghost commented Feb 9, 2014

  • Try --vf=lavfi=[w3fdif]

Some more remarks: if vf_tfields gets added back, it should be part of ffmpeg libavfilter.

@munousha
Copy link
Author

munousha commented Feb 9, 2014

No vdpau or vaapi here, sorry.

  • kerndeint doesn't give each field its own frame. It is a great deinterlacer otherwise but this is about getting N fps output from N fields per second content.
  • separatefields leaves as you said the scaling to the VO. I tried it earlier and it is performance wise ok but the picture moves 1px up and down every frame since the empty lines are discarded instead of interpolated from the surrounding lines.
  • yadif is 3.5 times slower than tfields, player can't keep up.
  • w3fdif is 2.5 times slower than tfields, player can't keep up.

@ghost
Copy link

ghost commented Feb 9, 2014

Can you port the filter to libavfilter? Yes, that's part of ffmpeg.

@ghost
Copy link

ghost commented Feb 17, 2014

Ping?

Porting the filter to libavfilter would be the best (even if it requires some effort).

I can also just merge vf_tfields as-is, but since it contains evil inline assembly, it might not be so long until I remove the filter again. (We plan to replace almost all filters with libavfilter equivalents, and the inline asm is a major pain - most of it isn't even correct, or has weird regressions with some compiler versions.)

@ghost
Copy link

ghost commented Apr 8, 2014

Hm, no reaction. Anyway, rejected.

@ghost ghost closed this Apr 8, 2014
This pull request was closed.
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

Successfully merging this pull request may close these issues.

1 participant