[FFmpeg-trac] #6577(undetermined:new): mkv vs encoding interlacement mismatch
FFmpeg
trac at avcodec.org
Fri Aug 11 08:43:37 EEST 2017
#6577: mkv vs encoding interlacement mismatch
-------------------------------------+-------------------------------------
Reporter: dericed | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: git-master | undetermined
Keywords: matroska | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by Zenitram):
Replying to [comment:1 heleppkes]:
> If you want to set the global field order in the files header, you need
to use the -field_order option. the lavfi filter only affects individual
frames, not the header option.
In that case, what is the source of Matroska metadata?
If the source is not the frames content, metadata should be not set to an
arbitrary value.
Note that if "setfield=tff" is replace by "setfield=bff", the Matroska
metadata is changed accordingly so it appears that the global field order
in the files header is impacted by "setfield".
Replying to [ticket:6577 dericed]:
> The interlacement data between an encoded ffv1 stream and the mkv
container appear to contradict each other.
Dave, I think your example is wrong, because ffv1 stream does **not**
store field order or interlaced/progressive with your command.
If you replace 9A 81 01 9D 81 09 by EC 81 00 EC 81 00 (interlace metadata
replaced by void), you see that your ffprobe command says 0 everywhere
i.e. progressive.
You need to add "-level 3" in order to store such metadata and check any
mismatch.
But it does not change the question.
Actually, it is a more global issue, if I try with a MOV you'll get same
issue, the issue is about the meaning of the different values from
QuickTime specs: how it is stored (separate fields or interleaved fields),
temporary order and store order.
***
I already got such debate few years ago, with difficulties to understand
specs compared to real world files.
What I understood is that:
1 is for separate fields and T stored/displayed first
6 is for separate fields and B stored/displayed first
9 is for interleaved fields and T stored/displayed first
14 is for interleaved fields and B stored/displayed first
this corresponds to current FFmpeg behavior with FFV1 as FFV1 stores only
interleaved fields.
with:
./ffmpeg -f lavfi -i mandelbrot -vf setfield=bff -vframes 1 -c:v ffv1
-level 3 -y test.mov
You get with MediaInfo:
Scan type : Interlaced
Scan type, store method : Interleaved fields
Scan order : Bottom Field First
which seems the expected result (FFV1 stores interleaved fields and you
want BFF)
with:
./ffmpeg -f lavfi -i mandelbrot -vf setfield=tff -vframes 1 -c:v ffv1
-level 3 -y test.mov
You get with MediaInfo:
Scan type : Interlaced
Scan type, store method : Interleaved fields
Scan order : Top Field First
which seems the expected result (FFV1 stores interleaved fields and you
want TFF)
Note: MI is missing "store method" line for Matroska, I'll add it (same
way as with MOV).
From my point of view the spec is slightly misleading, and there no really
stored vs displayed (I am curious of usefulness of storing first a field
temporary later, but everything may exist...) but more separate fields /
interleaved fields and TFF / BFF cases. I am not 100% sure, only empirical
tests, and MediaInfo is implemented from theses empirical tests. But if
this analysis about fieldorder value is right, the interlacement data
between an encoded ffv1 stream and the mkv container do not contradict
each other with current FFmpeg.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/6577#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list