[FFmpeg-trac] #380(avfilter:new): Mistake in ffmpeg's docs for yadif
FFmpeg
trac at avcodec.org
Wed Aug 3 00:17:29 CEST 2011
#380: Mistake in ffmpeg's docs for yadif
----------------------+--------------------------
Reporter: pshchelo | Type: defect
Status: new | Priority: normal
Component: avfilter | Version: unspecified
Keywords: | Blocked By:
Blocking: | Reproduced: 0
Analyzed: 0 |
----------------------+--------------------------
== Docs describe the values for yadif's parity parameter the other way
around. ==
'''ffmpeg version''': N-31706-g335bbe4
I've checked main git branch and docs are still like in the version I've
used.
== Test file ==
Attached test file: dv-bff.avi
This is a short sample of video captured from JVC camcorder through
IEEE1394 with the help of Windows Import Video on Windows Vista. This is
DV video and it must be interlaced with bottom-field-first (BFF) field
order as stated in many places, e.g here
[http://avisynth.org/mediawiki/Interlaced_fieldbased#About_DV_.2F_DVD_in_relation_to_field_dominance].
== How to test for error: ==
apply yadif with BFF (according to ffmpeg's yadif docs), field separation
and doubling the framerate:
ffmpeg -i dv-bff.avi -vf yadif=1:0 -r 50 output.avi
You will get a jagged video, although by applying yadif=1:1 (which,
according to the docs, is top-field-first) you get a smooth playback.
== Reasoning ==
I have tripple-checked the parity with other tools. GSpot video analysis
software reports it to be BFF. If you play tricks similar to the one above
with !VirtualDub and mplayer, the results also point that the video is
BFF. In fact, applying the same yadif parameters in mplayer and ffmpeg
results in the same behaviour, athough according to their respective docs
the meaning of parity values 0 or 1 is exactly opposite. The auto parity
recognition of ffmpeg works fine though - video encoded with yadif=1:-1
plays smoothly.
I have also checked this with DVD interlaced source, which, according to
this[http://avisynth.org/mediawiki/Interlaced_fieldbased#About_DV_.2F_DVD_in_relation_to_field_dominance],
must be top-field-first. The result is similar to DV case - Gspot reports
TFF, mplayer's yadif plays it nice with TFF, but ffmpeg's yadif plays it
nice with BFF as per docs.
As summary I strongly suspect the mistake in ffmeg's docs for yadif filter
- there the explanations of meanings for the field parity parameter should
be swapped. I made a corresponding patch to filters.texi file and attached
it here.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/380>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list