ffmpeg/libx264 does not observe interlace field order!

[timmus]

Just when I thought I had ffmpeg cranking out great x264 output, I come to find that some of my videos are in BFF (bottom field first) interlace mode, which is ignored by ffmpeg/libx264!!

I tried -top 0 and -top 1 as options and it just continues to come back with interlaced=tff in the job window, and motion in the resulting videos looks like garbage. All this with ffmpeg SVN-r25493 (Dec 14 2010). Argh!

Obviously this means that there can be major problems trying to use ffmpeg to convert NTSC over. What now? Are there any alternatives for producing AVI/DV -> MP4/H.264 video that will actually observe interlace field order? I'd use AVIDemux but I've already pointed out in another thread that it doesn't support AVI/DV Type 1. I have Sony Vegas Pro 8.0... is this a viable means for making decent MP4/h264's?

[Chris K]

The -top command only works in combination with -flags ildct+ilme

You could try to add it to the flags already on the command line but I don't know if it works for x264.

something like; -top 0 -flags ildct+ilme+other flags.

[timmus]

No, it's broken. Shown below is an attempt to use -top 0, -top 1, and just for the heck of it, -top -1 and -top 2. No change, the response is always interlaced=tff. I even tried moving the -top and -flag parameters to the end of the list (after the vcodec options). FFmpeg serves up a heck of a way to ruin 480i video.

ffmpeg -y -i vhs-012.10-12-13_16-08.00.avi -t 0:00:01 -top 0 -flags ildct+ilme -acodec aac -strict experimental -ac 2 -ab 128k -vcodec libx264 -fpre "c:\APP\ffmpeg\presets\libx264-slow.ffpreset" -b 3000k -f mp4 -r 29.970 -s 720x480 -aspect 4:3
 mp4\temp-test.mp4

[libx264 @ 03e60b60] 264 - core 110 r1820 fdcf2ae - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me
=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=tff constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=0 keyint=250 keyint_min=25
scenecut=40 intra_refresh=0 rc_lookahead=50 rc=abr mbtree=1 bitrate=3000 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.41 aq=1:1.00

ffmpeg -y -i vhs-012.10-12-13_16-08.00.avi -t 0:00:01 -top 1 -flags ildct+ilme -acodec aac -strict experimental -ac 2 -ab 128k -vcodec libx264 -fpre "c:\APP\ffmpeg\presets\libx264-slow.ffpreset" -b 3000k -f mp4 -r 29.970 -s 720x480 -aspect 4:3
 mp4\temp-test.mp4

[libx264 @ 03d80b60] 264 - core 110 r1820 fdcf2ae - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me
=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=tff constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=0 keyint=250 keyint_min=25
scenecut=40 intra_refresh=0 rc_lookahead=50 rc=abr mbtree=1 bitrate=3000 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.41 aq=1:1.00

ffmpeg -y -i vhs-012.10-12-13_16-08.00.avi -t 0:00:01 -top 2 -flags ildct+ilme -acodec aac -strict experimental -ac 2 -ab 128k -vcodec libx264 -fpre "c:\APP\ffmpeg\presets\libx264-slow.ffpreset" -b 3000k -f mp4 -r 29.970 -s 720x480 -aspect 4:3
 mp4\temp-test.mp4

[libx264 @ 03e80b60] 264 - core 110 r1820 fdcf2ae - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me
=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=tff constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=0 keyint=250 keyint_min=25
scenecut=40 intra_refresh=0 rc_lookahead=50 rc=abr mbtree=1 bitrate=3000 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.41 aq=1:1.00


ffmpeg -y -i vhs-012.10-12-13_16-08.00.avi -t 0:00:01 -top -1 -flags ildct+ilme -acodec aac -strict experimental -ac 2 -ab 128k -vcodec libx264 -fpre "c:\APP\ffmpeg\presets\libx264-slow.ffpreset" -b 3000k -f mp4 -r 29.970 -s 720x480 -aspect 4:
3 mp4\temp-test.mp4

[libx264 @ 03df0b60] 264 - core 110 r1820 fdcf2ae - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me
=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=tff constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=0 keyint=250 keyint_min=25
scenecut=40 intra_refresh=0 rc_lookahead=50 rc=abr mbtree=1 bitrate=3000 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.41 aq=1:1.00

[intracube]

You could try to add it to the flags already on the command line but I don't know if it works for x264.

'If you need to specify the field order then FFmpeg will need hacking to pass this to x264'
in the comments section here:
http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/comment-page-2/#comments

I don't know if the situation has changed in the last few months.

[timmus]

Well, considering that problem, I'm starting to wonder whether buying the DivX Plus codec package is a good idea if I want to do h264.

So far I've learned:
* Can't use ffmpeg/libx264 because it doesn't observe BFF interlace order (which comes from a LOT of packages as this link indicates).
* Can't use mencoder because it won't import Type 1 AVI/DV.
* Can't use AVIDemux because it won't import Type 1 AVI/DV.
* Can't use VirtualDub because it won't output an MP4.
* Can't use Type 2 AVI/DV because of gradual audio drift (if obtained from the source player).
* Can't (realistically) convert Type 1 to Type 2 AVI/DV because it doubles the time and is another reprocessing step.

[poisondeathray]

Well, considering that problem, I'm starting to wonder whether buying the DivX Plus codec package is a good idea if I want to do h264.

what's wrong with x264 cli ? or any of the dozen gui's for it . The syntax is --tff or --bff

you can use it with avisynth as well , the main build is compiled with avs support, so no problems with type I or type 2 if you have a VFW decoder installed e.g. cedocida

AVISource("video.avi")

But you probably don't even need avisynth, the main build is compiled with ffms support and should accept almost anything natively

Can't use VirtualDub because it won't output an MP4.

not entirely true anymore. There is an external encoder function (you can call x264.exe for example) , or x264vfw within vdub can output .mp4 ,.mkv, .flv, .264

[timmus]

Thanks... I was looking under "codecs" in the Tools area instead of "video encoders" and really had no idea what else was out there. I'll give x264 a try.

[poisondeathray]

Yes I just tested it on a type-1 DV-AVI clip , works fine, field order is correct , no need for avisynth. It even automatically detects AR and puts the --sar value (e.g. I used a 4:3 AR clip, and it correctly used --sar 8:9, even though I didn't enter sar value)

e.g.

x264 --crf 20 --bff -o output.mp4 input.avi

Other x264 builds have audio support compiled too (I don't think the main build has it yet) , so you could do audio also and batch encode everything

[timmus]

OK, I'm running with MeGUI and x264... I feel like I'm in a whole different realm now. Glad to see MeGUI is highly attentive to interlace configuration. I seem to be having no problems encoding now. Still sorting out a problem though with MeGUI not recognizing AVI/DV Type 1 audio (it says the audio stream is missing, though I can hear it fine in VirtualDub), so I've installed the Cedocida DV driver and will try to make Type 2 sources to see if it fixes any of the A/V sync issues.

[timmus]

poisondeathray: are you getting audio streams with your Type 1 DV clips? I have to go back to Type 1 since I'm still getting sync errors with Type 2, but MeGUI doesn't recognize any audio from my Type 1 DV AVIs, and x264.exe did not produce any audio either. The audio is plain old PCM... I don't know why these decoders are having so much trouble with them.

EDIT: Looks like you're quite the DV expert... I found your helpful advice in this thread https://forum.videohelp.com/threads/293945-camcorder-dv-to-h-264 so I'm gonna follow it tomorrow morning and see if I can get Type 1 audio working.

[Gavino]

I have to go back to Type 1 since I'm still getting sync errors with Type 2, but MeGUI doesn't recognize any audio from my Type 1 DV AVIs, and x264.exe did not produce any audio either. The audio is plain old PCM... I don't know why these decoders are having so much trouble with them.

Is the input done via an Avisynth script?
AviSource() does not produce audio with Type 1 DV files, you need to use DirectShowSource().

Also, I don't see any reason why you should get sync errors with Type 2.
You can convert easily from one type to another using a tool like
http://www.ulead.com/download/dvconverter/download.htm
This is fairly quick (no re-encoding, simply copying) and will not double your work time (as you suggested in another thread).

[timmus]

Actually I did get AVI/DV Type 1 working fine in MeGUI. But I have not had to resort to DirectShowSource()... the AVISynth script MeGUI is using looks like this:
AVISource("D:\_TEMP\capture\type1.avi", audio=false)

However in audio encoder configuration I did have to check "Use DirectShow" (in addition to the VFW changes PoisonDeathRay suggested in the thread I linked to earlier). I don't know exactly how this is working, but since the AVISource() call had audio=false and I am getting audio anyway, I think due to Use Directshow being checked, MeGUI was doing an internal DirectShowSource() call of some kind to handle the audio. I have not had to do any hand-edits at all in the AVISynth script.

It appears all is working fine for now, so as long as no A/V sync drift problems crop up then I may be good to go. I'll report back as I work with this some more.

[timmus]

Also, I don't see any reason why you should get sync errors with Type 2.

Me either, but DV Type 2 has always resulted in A/V desync problems for me... I found that out 7 years ago when I started messing around with DV capture. I am using a Sony TRV Handycam as video passthrough to WinDV. I even tried capturing again into Type 2 after installing the Cedocida drivers and A/V desync is still there. I did find something interesting, though: while experimenting last week I used VirtualDub to convert 2 hours of already-captured VHS footage to DV Type 2, and the resulting file had no desync problems. That tells me that the desync is originating in the camcorder hardware or in the Firewire connection... and the desync even happens when WinDV reports 0 dropped frames, so packets are getting lost or corrupted somewhere in the camcorder or in the Firewire connection.

I have avoided the idea of doing a Type 1 -> Type 2 conversion as my mantra is not to add more steps of lossy encoding, and HuffYUV is too bloated as some of my files are 6 hours of VHS in SLP mode. Conversion also takes too much time as I'm working with a lot of tapes. So I'm crossing my fingers that I succeed with Type 1 DV in MeGUI, otherwise it's back to VirtualDub and xvid.

[timmus]

Well, MeGUI and x264 is a failure, as it suffers from the "gradual A/V desync" issue (video lag increasing to 1 second by the end of a 2-hour clip). I guess it's back to trusty VirtualDub and xvid.