[FFmpeg-user] Capture from USB Dazzle: Interlaced or not interlaced. FFV1 level3 vs h264
MrNice
wxcvbn2006 at iol.ie
Sat Oct 31 12:03:09 CET 2015
On 30/10/15 17:09, MrNice wrote:
>
> On 29/10/15 20:09, Andy Furniss wrote:
>> Carl Eugen Hoyos wrote:
>>> MrNice <wxcvbn2006 <at> iol.ie> writes:
>>>
>>>> When I capture some video with the CL ./ffmpeg -debug 1 -f v4l2 -ts
>>>> mono2abs -channel 1 -video_size 720x576 -pix_fmt yuyv422
>>>> -thread_queue_size 512 -i /dev/video0 -c:v ffv1 -level 3 -g 1
>>>> -aspect 4:3 -pix_fmt yuv422p /Store3/Test/t_`date
>>>> +%Y%m%d_%H%M`.mkv -aspect 4:3 -f sdl "Dazzle output"
>>>
>>>> from a S-VHS tape and Dazzle DVC100, I was thinking to get an
>>>> interlaced video file.
>>>
>>> Why? I mean: How is FFmpeg (or the FFV1 encoder) supposed to know
>>> that your v4l input is interlaced?
>>
>> Hopefully the device/v4l would pass on this information.
>>
>>> (And why shouldn't your S-VHS recording be low-resolution
>>> progressive?) Maybe I miss something but in this case please
>>> explain.
>>
>> I thought s-vhs was like vhs = one field per stripe on the tape.
>>
>> Maybe if what was recorded was progressive you wouldn't care assuming
>> v4l outputs weaved frames - but a lot of tape contains interlaced so you
>> would need the field dominance info for that.
>>
>> Random thought - as it's analogue field input, I wonder if it's possible
>> that even with a progressive recorded as interlaced you could end up
>> with weaved frames that don't "line up".
>> _______________________________________________
>
>
> Carl Eugen said on Dec 19, 2012: "To the best of my knowledge, only
> visual inspection tells you, ..."
> so, what I did and all the 4 files, (FFV1/h264, with/without -flags
> +ilme+ildct) are definitely interlaced without any doubt.
>
> However tags are not consistent:
> FFV1 with -flags: interlaced_frame=0, top_field_first=0
> FFV1 without -flags: interlaced_frame=0, top_field_first=0
> h264 with -flags: interlaced_frame=1, top_field_first=0
> h264 without -flags: interlaced_frame=0, top_field_first=0
>
> Questions:
> - How to get interlaced_frame=1 with FFV1?
> - Could you confirm top_field_first=0 means bff and really what is in
> the file?
> - BTW I have read bff is the usual setting for DV, do you agree I should
> keep it like that?
>
The above interlaced dtection was done withg the CL
./ffprobe -show_frames filename.mkv
When I use the following CL, I get:
./ffmpeg -filter:v idet -frames:v 100 -an -f rawvideo -y /dev/null -i
filename.mkv
FFV1 with -flags: Repeated Fields: Neither: 100 Top: 0 Bottom: 1
Single frame detection: TFF: 101 BFF: 0 Progressive: 0 Undetermined: 0
Multi frame detection: TFF: 101 BFF: 0 Progressive: 0 Undetermined: 0
FFV1 without -flags: same
h264 with -flags: Repeated Fields: Neither: 100 Top: 1 Bottom: 0
Single frame detection: TFF: 98 BFF: 3 Progressive: 0 Undetermined: 0
Multi frame detection: TFF: 96 BFF: 5 Progressive: 0 Undetermined: 0
h264 without -flags: Repeated Fields: Neither: 101 Top: 0 Bottom: 0
Single frame detection: TFF: 101 BFF: 0 Progressive: 0 Undetermined: 0
Multi frame detection: TFF: 101 BFF: 0 Progressive: 0 Undetermined: 0
When I use the following CL, I get:
./ffmpeg -i filename.mkv -vf idet -f null /dev/null 2>&1 | grep Parsed_idet
FFV1 with -flags: Repeated Fields: Neither: 436 Top: 0 Bottom: 1
Single frame detection: TFF: 437 BFF: 0 Progressive: 0 Undetermined: 0
Multi frame detection: TFF: 437 BFF: 0 Progressive: 0 Undetermined: 0
FFV1 without -flags: Repeated Fields: Neither: 455 Top: 0 Bottom: 1
Single frame detection: TFF: 456 BFF: 0 Progressive: 0 Undetermined: 0
Multi frame detection: TFF: 456 BFF: 0 Progressive: 0 Undetermined: 0
h264 with -flags: Repeated Fields: Neither: 444 Top: 1 Bottom: 0
Single frame detection: TFF: 441 BFF: 4 Progressive: 0 Undetermined: 0
Multi frame detection: TFF: 440 BFF: 5 Progressive: 0 Undetermined: 0
h264 without -flags: Repeated Fields: Neither: 565 Top: 0 Bottom: 0
Single frame detection: TFF: 565 BFF: 0 Progressive: 0 Undetermined: 0
Multi frame detection: TFF: 565 BFF: 0 Progressive: 0 Undetermined: 0
I'd guess ffmpeg doesn't analyse the same object.
There are really inconsistencies regarding BFF and TFF with the 3 CL.
More information about the ffmpeg-user
mailing list