PDA

View Full Version : Quality issues with DGDecode->ffmpeg vs. VOB->ffmpeg


Redmondman
4th January 2007, 10:21
This is one of those posts that could go anywhere, due to the combination of tools. I'll start here and you should feel free to point me in the right direction.

Goal: main title (movie) rip from DVD transcoded to MPEG with video at ~2Mbps.

Two scenarios, both start exactly the same (second scenario has the additional eventual goal of adding subtitles): RipIt4Me->DVD Shrink to create a single VOB containing a movie. This movie VOB is the input to the two processes below.

Process 1: Direct transcode of VOB to MPEG with FFMPEG (I'll supply full commands and output below). Very good quality output video.

Process 2: VOB->DGIndex, d2v goes in AviSynth script as DGDecode/Mpeg2source, ac3 goes in AviSynth script as NicAudio/NicAC3source. AVS script is fed to FFMPEG. Quality of output video noticeably worse than process #1.

Question: something I'm doing wrong? Natural artifact of the extra processing in step 2? Also, what's the deal with the 59.94 fps reported by ffmpeg in process #1?

Process #1:

C:\apps>ffmpeg.exe -y -i "C:\Movie 2 ch\VIDEO_TS\vts_01_1.vob" -vcodec mpeg2video -s 720x480 -r 29.97 -b 2097152 -aspect 16:9 -ac 2 -ab 192 -f vob "C:\outputdir\test-vob.mpg"
FFmpeg version SVN-r7375, Copyright (c) 2000-2006 Fabrice Bellard, et al.
built on Dec 26 2006 18:15:30, gcc: 4.0.3

Seems stream 0 codec frame rate differs from container frame rate: 29.97 (30000/1001) -> 59.94 (60000/1001)
Input #0, mpeg, from 'C:\Movie 2 ch\VIDEO_TS\vts_01_1.vob':
Duration: 01:19:40.2, start: 0.233567, bitrate: 6681 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480, 9800 kb/s, 59.94 fps(r)
Stream #0.1[0x82]: Audio: ac3, 48000 Hz, stereo, 192 kb/s
Output #0, vob, to 'C:\outputdir\test-vob.mpg':
Stream #0.0: Video: mpeg2video, yuv420p, 720x480, q=2-31, 2097 kb/s, 29.97 fps(c)
Stream #0.1: Audio: mp2, 48000 Hz, stereo, 192 kb/s

Process 2:
C:\apps>ffmpeg.exe -y -i "C:\Movie 2 ch\VIDEO_TS\movie.avs" -vcodec mpeg2video -s 720x480 -r 29.97 -b 2097152 -aspect 16:9 -ac 2 -ab 192 -f vob "C:\outputdir\test-avs.mpg"
FFmpeg version SVN-r7375, Copyright (c) 2000-2006 Fabrice Bellard, et al.
built on Dec 26 2006 18:15:30, gcc: 4.0.3
Input #0, avs, from 'C:\Movie 2 ch\VIDEO_TS\movie.avs':
Duration: 01:19:43.8, start: 0.000000, bitrate: N/A
Stream #0.0: Video: rawvideo, yuv420p, 720x480, 124291 kb/s, 29.97 fps(r)
Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, 1536 kb/s
Output #0, vob, to 'C:\outputdir\test-avs.mpg':
Stream #0.0: Video: mpeg2video, yuv420p, 720x480, q=2-31, 2097 kb/s, 29.97 fps(c)
Stream #0.1: Audio: mp2, 48000 Hz, stereo, 192 kb/s

I can't put my finger on it, but I have the feeling that the AviSynth/DGDecode codepath is, in reality, providing half the video information as compared with the direct VOB; that the 59.94 fps framerate being reported by ffmpeg in Process #1 is somehow relevant, and that it has something to do with interlacing on the input side. But I admit I'm speculating.

neuron2
4th January 2007, 14:41
Quality of output video noticeably worse What do you mean by "noticeably worse"?

You haven't told me anything at all about your DGIndex settings, your Avisynth script, etc.! You could have done something wrong.

Finally, a short clip of the unprocessed source material with good motion will help me to properly guide you.

Redmondman
4th January 2007, 17:12
Sure. Here's the AviSynth script in its entirety:

-------------------------------------------------

LoadPlugin("C:\Program Files\AviSynth2\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth2\plugins\VSFilter.dll")
LoadPlugin("C:\Program Files\AviSynth2\plugins\NicAudio.dll")

# SOURCE
video = mpeg2source("C:\Movie 2 ch\VIDEO_TS\VTS_01_1.d2v")
audio = NicAC3Source("C:\Movie 2 ch\VIDEO_TS\VTS_01_1 T03 2_0ch 192Kbps DELAY 0ms.ac3")
AudioDub(video, audio)

# SUBTITLES
#TextSub("c:\Movie 2 ch\VIDEO_TS\Movie.srt")

------------------------------------------

Here are the DGIndex settings:

DVD2AVI_Version=DGIndex 1.4.8
Window_Position=252,153
iDCT_Algorithm=6
YUVRGB_Scale=1
Field_Operation=0
Output_Method=2
Track_Number=1
DR_Control=2
DS_Downmix=0
SRC_Precision=0
Norm_Ratio=100
Process_Priority=2
Playback_Speed=3
Force_Open_Gops=0
Correct_Field_Order=1
AVS_Template_Path=
Full_Path_In_Files=1
Use_Overlay=1
Fusion_Audio=0

------------------------
and the first portion of the D2V file:

---------------------

DGIndexProjectFile13
1
C:\Movie 2 ch\VIDEO_TS\VTS_01_1.VOB

Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=720x480
Field_Operation=0
Frame_Rate=29970 (30000/1001)
Location=0,0,0,1DBF4B

<stuff>

FINISHED 99.95% FILM

-----------------------------

In terms of quality "noticeably worse", I'll follow up this post with attachments so that I can show you rather than tell you, but I'll say the following:

1. Ultimate playback is on a TV set via TivoToGo.
2. Quality difference appears in scenes with high motion.
3. Here's an interesting difference that I'm not sure how to capture (or describe): when pausing (still frame) the "good" video (on the TV set), the picture is still. When pausing the "lower quality" video, the picture actually "vibrates" as if trying to decide between one frame or another.

I'll now go work on extracting clips so that I can more precisely convey the visual difference I'm seeing.

neuron2
4th January 2007, 18:04
Try it again with Field Operation = Force Film. You have pure 3:2 pulldown, and you are not doing IVTC in your script.

Redmondman
4th January 2007, 18:30
Yes, that's the ticket. Now clearly, I have more homework to do. I didn't go in that direction because the input VOB appeared to have a 29.97 fps framerate (based on Process #1 output from ffmpeg), so I didn't think inverse telecine was required. But you saw pure 3:2 pulldown somewhere -- where?

EDIT: I see where now. Reading the links from the manual. -- thanks again.

EDITEDIT: for others. RTFM. >95%FILM, you may need Force Film. But do read the manual, there's much information there and in the linked material.

Thank you very much.

jpsdr
8th January 2007, 13:12
Try IDCT algorithm IEEE-1180 Reference.
(Wich is algorithm 5 i think).
The IDCT algorithm may also make a difference in
quality ouput.
The IEEE-1180 Reference, is the one which produce
the best quality output, as far as i know.

neuron2
8th January 2007, 13:35
The IDCT choice has an insignificant effect on quality. If you can demonstrate such an effect, then there is a bug that you need to tell me about. Can you demonstrate it?

jpsdr
8th January 2007, 14:29
It's juste something i've noticed a long time ago, with
the mpeg2avi program.
With the same mpeg2 input file, i've noticed that the choice
of the idct algorithm have a noticeable impact in the quality of
the ouput. The IEEE-1180 reference compliant was "clean", but
the 32bit MMX idct presented more mosquito artefacts.
As the choices of the idct algorithm on DGMPEG have very
similar name, i've conclued, maybe at wrong, that it will work
in the same way.

BTW, for what i know, DGMPEG is taken from DVD2AVI.

Is this potentiel bug, still in the air ?
http://arbor.ee.ntu.edu.tw/~jackeikuo/dvd2avi/refidct/

neuron2
9th January 2007, 22:43
That bug was fixed long ago.

omadawn
16th February 2007, 16:20
i've noticed that the choice
of the idct algorithm have a noticeable impact in the quality of
the ouput. The IEEE-1180 reference compliant was "clean", but
the 32bit MMX idct presented more mosquito artefacts.
http://arbor.ee.ntu.edu.tw/~jackeikuo/dvd2avi/refidct/

Does the above makes any sense these days?

neuron2
16th February 2007, 18:01
It does not make any sense to me. The bug was fixed long ago and the IDCT choice makes an imperceptible difference. It certainly cannot affect the amount of mosquito noise.