FFprobe - field_order: unknown

[FFtvuser]

Hi, I did a smaill script to transcode video files, and it is using FFprobe.exe to get video details before the render. I need to know the field order to do a proper encoding, but some interlaced videos returns a "field_order: unknown".

The most common values are "bb" or "tt", but these videos are 50i and the field order is no provided. There are some way to get the order using another of the returned data?

Here is an example of one of these 50i videos:

-STREAM-
index=0
codec_name=mpeg2video
codec_long_name=MPEG-2 video
profile=Main
codec_type=video
codec_time_base=1/25
codec_tag_string=mp4v
codec_tag=0x7634706d
width=1920
height=1080
coded_width=0
coded_height=0
closed_captions=0
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=16:9
pix_fmt=yuv420p
level=4
color_range=tv
color_space=bt709
color_transfer=bt709
color_primaries=bt709
chroma_location=left
field_order=unknown
timecode=N/A
refs=1
id=N/A
r_frame_rate=25/1
avg_frame_rate=25/1
time_base=1/25000
start_pts=0
start_time=0.000000
duration_ts=648000
duration=25.920000
bit_rate=34053205
max_bit_rate=35000000
bits_per_raw_sample=N/A
nb_frames=648
nb_read_frames=N/A
nb_read_packets=N/A
DISPOSITION:default=1
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
TAG:creation_time=2021-04-09T13:42:49.000000Z
TAG:language=eng
TAG:handler_name=Video Media Handler
-SIDE_DATA-
side_data_type=CPB properties

[poisondeathray]

width=1920
height=1080

By convention, "HD" video is top field first. You might include some logic in your script - something like if height>576

[emcodem]

width=1920
height=1080

By convention, "HD" video is top field first. You might include some logic in your script - something like if height>576

576 might be not the correct value but >608 (608 is SD in broadcasters formats, e.g. IMX).
But besides that, @poisondeathray it seems that i am missing something here, why you say HD can only be top field? I mean besides it can be progressive, where did you read about that "interlaced HD" can only be TFF?
Again, sorry if i miss something here...`

@FFtvuser
if i didnt miss any previous discussions or implications, some info about the container would be good

[FFtvuser]

Thanks poisondeathray, as last resource I can do that.

emcodem, is a MP4 container, recorded by a videocamera. Here is the ffmpeg -i :

[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000000432780] st: 0 edit list: 1 Missing key frame while searching for timestamp: 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000000000432780] st: 0 edit list 1 Cannot find an index entry before timestamp: 0.
Guessed Channel Layout for Input Stream #0.1 : mono
Guessed Channel Layout for Input Stream #0.2 : mono
Guessed Channel Layout for Input Stream #0.3 : mono
Guessed Channel Layout for Input Stream #0.4 : mono
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'd:\TRANSC~2\2021\04ABRI~1\12\TEST-FTP\DAN-00~1.MP4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42
creation_time : 2021-04-09T13:42:49.000000Z
Duration: 00:00:25.92, start: 0.000000, bitrate: 37278 kb/s
Stream #0:0(eng): Video: mpeg2video (Main) (mp4v / 0x7634706D), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 34053 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default)
Metadata:
creation_time : 2021-04-09T13:42:49.000000Z
handler_name : Video Media Handler
Side data:
cpb: bitrate max/min/avg: 35000000/0/0 buffer size: 9781248 vbv_delay: N/A
Stream #0:1(eng): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, mono, s16, 768 kb/s (default)
Metadata:
creation_time : 2021-04-09T13:42:49.000000Z
handler_name : Sound Media Handler
Stream #0:2(eng): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, mono, s16, 768 kb/s (default)
Metadata:
creation_time : 2021-04-09T13:42:49.000000Z
handler_name : Sound Media Handler
Stream #0:3(eng): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, mono, s16, 768 kb/s (default)
Metadata:
creation_time : 2021-04-09T13:42:49.000000Z
handler_name : Sound Media Handler
Stream #0:4(eng): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, mono, s16, 768 kb/s (default)
Metadata:
creation_time : 2021-04-09T13:42:49.000000Z
handler_name : Sound Media Handler

That video is top field first, but I don't know that until I render it and verify that it looks correct.

[emcodem]

Thanks poisondeathray, as last resource I can do that.
Stream #0:0(eng): Video: mpeg2video (Main) (mp4v / 0x7634706D), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 34053 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc

Ok thats really bad as nothing in the container or in the video is interlaced (nor progressive). MPEG2 in mp4 is not really the best match hehe...
Your options are getting thinner on that.

field_order=unknown

In your video indicates that something is strange. I didnt look up the condition in ffmpeg source code for that but if it was definitely progressive, you should see that indication at this point.
You might want to tell us here what your overall workflow looks like as there are options like to use the ffmpeg idet filter which decodes and checks the actual video content to get out the actual interlacing...

[poisondeathray]

width=1920
height=1080

By convention, "HD" video is top field first. You might include some logic in your script - something like if height>576

576 might be not the correct value but >608 (608 is SD in broadcasters formats, e.g. IMX).
But besides that, @poisondeathray it seems that i am missing something here, why you say HD can only be top field? I mean besides it can be progressive, where did you read about that "interlaced HD" can only be TFF?
Again, sorry if i miss something here...`

I mean interlaced HD is TFF not BFF, by convention

All interlaced HD cameras, all interlaced HD broadcast are TFF.



You can have non-conventional user "errors" - like BFF for HD because of some workflow error, but they are rare. 99.999999% of the time for interlaced HD, it will be TFF

(Of course a video can be native progressive content too, or progressive content encoded interlaced, or even a mixture such as MBAFF)


Just like if a video is flagged "TFF" and read as "TFF" by ffprobe it could be actually BFF. FFProbe doesn't determine the actual content field order .

-vf idet scans file but it's not necessarily accurate either. Human eyes, separating fields is the most accurate.

[emcodem]

[QUOTE=poisondeathray;2617579][QUOTE=emcodem;2617570]

You can have non-conventional user "errors" - like BFF for HD because of some workflow error, but they are rare. 99.999999% of the time for interlaced HD, it will be TFF

Ok thanks for that, i really thought i missed something here. In that case i support you on the opinion that it might be extremely uncommon to have bottom field in HD. In case that a HD file actually was BFF and it does not indicate that in the container or codec, thats a HUGE mistake by the manufacturer then.

Also i second your opinion theoretically that it is a good idea to just assume top field for FullHD. But with one exception:
My logic for a non professional script/program would probably look like this:
if (ffprobe.stream.fieldorder == "unknown" && ffrobe.stream.height > 608){
//in this case, we force top fiel first.
}

To get it more dirty, actually we could just always assume that the input is tff by default and apply the deinterlacing because on progressive video it will not influence the output quality but just slowdown the processing a little bit. The only exception is when the video is actively flagged as progressive or bff, this should cover most cases at the best result.

But in the end it depends on the usecase... so tell us more @FFtvuser

[poisondeathray]

To get it more dirty, actually we could just always assume that the input is tff by default and apply the deinterlacing because on progressive video it will not influence the output quality but just slowdown the processing a little bit. The only exception is when the video is actively flagged as progressive or bff, this should cover most cases at the best result.

If you deinterlace progressive content, it will degrade the output quality

[emcodem]

If you deinterlace progressive content, it will degrade the output quality

Depending on the usecase (e.g. no Greenbox, color grade etc...) the visual degrade might not be visble/noticeable

[FFtvuser]

I didn't know the Idet filter. I have tried it and it works, although sometimes it takes a long time to find the result.

At the end it returns something like this:
[Parsed_idet_0 @ 0000000002e2c700] Multi frame detection: TFF: 3821 BFF: 6 Progressive: 0 Undetermined: 0

and what I do is see which number is higher to determine the order of the fields.

The command I use is:
ffmpeg -hide_banner -i FILE -vf idet -f null -

I'm thinking of speeding up the process with known files, but I don't trust it. For example there are files that shows 25 fps, and they can be 25 progressive or 50 interlaced. With Idet I can get out of doubts.

Thank you both for your help.

[emcodem]

Sounds good to me. Maybe you want to make it a little more accurate and check the 3 values in a way that when the sum of the 3 values is 100%, ONE value should be at least like 99.9% or such, so you have a chance to get notified if you face a mixed sequence. Possibility to have mixed depends a little what kind of material you are looking at.

[FFtvuser]

It's a good idea. At the moment everything I have found has one of the values always much higher than the rest.

I'm thinking of trying analyze_interlaced_flag (value), but I don't know what is the syntax. Testing this:

ffmpeg -i (FILE) -vf idet analyze_interlaced_flag 1000 -f null -

returns an error:

analyze_interlaced_flag: Invalid argument

You know the correct syntax?

[poisondeathray]

It's a good idea. At the moment everything I have found has one of the values always much higher than the rest.

I'm thinking of trying analyze_interlaced_flag (value), but I don't know what is the syntax. Testing this:

ffmpeg -i (FILE) -vf idet analyze_interlaced_flag 1000 -f null -

returns an error:

analyze_interlaced_flag: Invalid argument

You know the correct syntax?

-vf idet=analyze_interlaced_flag=1000

Note there are cases where idet gets confused; an example is field shifted material - this is not very common but it occurs in some camcorders, some broadcasts

eg.
https://forum.videohelp.com/threads/397615-De-interlacing-30p-60i-AVCHD-from-Panasonic...G7#post2585999


[Parsed_idet_0 @ 000000b31f51a840] Repeated Fields: Neither: 104 Top: 2 Bottom: 0
[Parsed_idet_0 @ 000000b31f51a840] Single frame detection: TFF: 106 BFF: 0 Progressive: 0 Undetermined: 0
[Parsed_idet_0 @ 000000b31f51a840] Multi frame detection: TFF: 106 BFF: 0Progressive: 0 Undetermined: 0

This is completely wrong - it's actually progressive content

[Selur]

You know the correct syntax?

Isn't it the same syntax as basically all FFmpeg filters with parameters?
My guess is you probably want something along the lines of:

-vf setfield=tff,idet=intl_thres=1.35:analyze_interlaced_flag=500

poisondeathray was faster with an example,...

[FFtvuser]

Thanks, it works (but I think the speed is the same...).

I have tested with the Panasonic file and seems correct to me.

FFprobe returns: field_order=tt

and idet: [Parsed_idet_0 @ 00000000044d8400] Multi frame detection: TFF: 106 BFF: 0 Progressive: 0 Undetermined: 0

and playing the video with VLC and deactivating the deinterlacing, I can see that it is a interlaced video.

[poisondeathray]

Thanks, it works (but I think the speed is the same...).

I have tested with the Panasonic file and seems correct to me.

FFprobe returns: field_order=tt

and idet: [Parsed_idet_0 @ 00000000044d8400] Multi frame detection: TFF: 106 BFF: 0 Progressive: 0 Undetermined: 0

and playing the video with VLC and deactivating the deinterlacing, I can see that it is a interlaced video.

It's not interlaced content, it's field shifted (or phase shifted). If you deinterlace, you will essentially reduce the resolution in half - this reduces quality. Read the other posts in the thread

You see combing because the fields are misaligned, but it's actually progressive

This type of field shifting occurs in the "wild" with some cameras, some broadcasts, but its not common

[FFtvuser]

Yes, the movement is blurry, if it were 60i it would look better.

Does it also happen with 25p or 50i? Here in Spain we use 50i for tv.

[poisondeathray]

Yes, the movement is blurry, if it were 60i it would look better.

Does it also happen with 25p or 50i? Here in Spain we use 50i for tv.

But the content is 29.97p - that's what it was shot at. The point is it's actually progressive, and a casual glance or vf idet will make the mistake and think it's "interlaced" . Another clue is if you double rate deinterlace in VLC or similar (such as bob or yadif 2x), each frame is doubled or duplicated when you go frame by frame. There are not individual different unique frames - thus it's 29.97p content, not double rate deinterlaced to 59.94p

It happens with some ITV (and other station) broadcasts, so yes, some 25p broadcast as "50i" are sometimes field shifted. It's not common, but there are examples around