[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