#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 _______________________________________________ FFmpeg-trac mailing list FFmpeg-trac@avcodec.org http://ffmpeg.org/mailman/listinfo/ffmpeg-trac