Hello there,
I transferred several MiniDV tapes (PAL, SD) to my PC. The video files's specs are: 720x576, 1:33:1, 25fps, 25Mbit, interlaced.
I wanted to convert them to 768x576, 1:42:1, 50fps, 12Mbit, progressive.
Should I use Topaz Video Ai or are there settings within Handbrake or AviDemux, etc. that would do a similar job just faster? Would love to hear your ideasbecause
Topaz (often) brings great results, but takes far too long (1fps working speed).
People ask me why I don't leave the files as is and watch the originals without further converting.
Playing these interlaced 25fps videos looks bad (VLC, Potplayer, MPC, etc.) - Is this only happening to me? Shouldn't one convert those videos for the framerate, for the aspect ratio, for the resolution?
Am I wrong when I say that 720x576 isn't the correct aspect when watching a 4:3 video? When I watch one of these 720 videos the picture is squeezed. When converted to 768 the picture looks fine (same as on the preview screen on my camera). This correct video is in 1:42:1 aspect. So when you look at my screenshot of my 3 different results (Topaz) I assume that the aspect is maybe something to look into. Again, maybe I am on a wrong track here. But look for yourselves.
[Attachment 68564 - Click to enlarge]
[Attachment 68565 - Click to enlarge]
The first example shows a video with the aspect of 1:33:1, squeezed picture. The second example shows 1:42:1, but instead of stretching the picture to the correct aspect, it I got black borders at the sides (in Topaz I checked "Original Pixeltype" and "Letterbox/Pillarbox". The third example shows (in my opinion) the correct aspect ratio, 1:42:1 without the artificial borders (sorry for the german interface).
How should I proceed? What would you do to get the best quality out of these little SD videos? And am I doing/thinking something wrong here?
+ Reply to Thread
Results 1 to 30 of 31
-
Last edited by ChrisKron; 5th Jan 2023 at 17:52. Reason: added image
-
The image at the top left looks to me like it should be closer to 16:9, not 4:3 or 1.42:1. I cropped the frame down to 704x576 and resized to 1024x576:
[Attachment 68566 - Click to enlarge]Last edited by jagabo; 5th Jan 2023 at 18:52.
-
Chris, a few comments:
-You need a new calculator.720x576 is 1.25:1 (5:4) and 768x576 is 1.3333:1 (or 4:3). If your frame size is 720x576, it needs a 4:3 flag to tell players to stretch it to be the equivalent of 768x576. The "standard" SD video is 720x576 with a 4:3 flag or display aspect ratio. You could use 768x576, also with a 4:3 flag, if you're worried about a player not respecting the flag.
-Could you elaborate on "transferred"? If you did a DV "transfer" via Firewire (the preferred method for mini-DV) the resulting DV-AVI files (720x576) should have had the 4:3 flag inserted by the transfer software and they should play correctly in VLC player.
If you captured them via analogue (Composite or S-Video cabling), they will be 720x576 with no flag in an analogue AVI format (eg codecs HUFFYUV, Lagarith), which is why they look squeezed. They will need to be re-encoded to a more useable format such as MP4 and flagged to 4:3.
It would help us greatly if you could give us the Medinifo readout of one of your captured files. Open the file in Mediainfo, choose View>Tree, and copy and paste all the text into a post here. That will reveal what you're dealing with as far as frame sizes, codecs and flags go. -
For analog sources, especially with those ~16 pixels of black left and right, a DAR of 15:11 instead of 4:3 should be used if the frame size is 720x576. Alternatively, crop to a width of 704 first and then use a DAR of 4:3.
I agree with jagabo about the scene in the top left corner. It looks like it was (accidentally?) shot in 16:9 mode which a few camcorders had by the end of the 90's. -
Code:
dir/b/s *.avi >mp4list.txt @REM filter curve BT601 !!! for /F "delims=;" %%F in (mp4list.txt) do ffmpeg.exe -n -i "%%F" -vf "scale=in_range=full:out_range=full,yadif=1,vaguedenoiser,curves=master='0.0625/0 1/1'" -map 0:v -map 0:a -map 0:s? -c:v libx264 -crf 19 -pix_fmt yuvj420p -c:a aac -b:a 192k "%%~dF%%~pF%%~nF (full range+yadif+H264).mp4" del mp4list.txt pause
The vanguedenoiser filter does a slight denoising and the yadif deinterlaces.
I see no point in changing the resolution. For what?
In VLC you probably have to force deinterlace manually. So I gave up VLC in favor of MPC with MPC Renderer. -
-
[Attachment 68564 - Click to enlarge]
But these recordings don't look like miniDV tapes -- usually there is no such noise at the bottom of the picture... -
-
We can do with our videos whatever we please, not that I would say someone what to do, but as a general advice, not sure if I recommend to actually stretch videos on histogram to full 0-255 for YUV. Even if you flag it as full range later. Do all media players follow full range flag to convert 0-255YUV to 0-255 in RGB instead of regular 16-235 YUV to 0-255 RGB? Better would seam to be to pull those highlights down a tiny bit. I think you saw images in some other thread. It is becoming a norm to have a chance to export a custom LUT from NLE (camcorder custom LUT) and used it in Avisynth or vapoursynth if needed. Or using perhaps ffmpeg, as you do.
-
There is a mixed bag of at least two formats, analog and digital. Each has to be dealt with separately, add to that there is some 16/9 scenes, those also have to be dealt with separately.
Here is what I would do:
- For the analog sources (assuming they are all 4:3) de-interlace using QTGMC and crop to 704x576 then resize to 1440x1080 and encode to h.264.
- For digital sources 4:3, De-interlace and resize from 720x576 to 1440x1080 then encode to h.264.
- For digital sources 16:9, De-interlace and resize to 1920x1080 then encode to h.264.
Keep the original files and delete all the intermediate resulting files.
If you must put 16:9 files and 4:3 in the same video, in the first two tasks, instead of resizing to 1440x1080 add black pillars or frosted edges or whatever you like to get a 1920x1080. -
Unless it was shot by a DV camcorder (MiniDV/Digital8), where the same procedure as for analog sources would apply.
At least it is like that for all the standard definition camcorders I ever held in my hands (Sony, Panasonic, JVC). Or to put it into numbers: DV 720x576 —> DAR 15:11 (not 4:3). -
What do you think I meant by digital sources and analog sources?
-
Originally Posted by DellsamOriginally Posted by Skiller
Why do we persist with 720? Why not just export at 768x576, like we do with 1440x1080 or 1920x1080?Last edited by Alwyn; 9th Jan 2023 at 00:06.
-
Because analog tapes have blanking space on the sides of the frame, If you don't crop it off it will cause the aspect ratio to be off by 16 pixels, Not a big deal, most people don't notice it but if those total 16 pixels are part of the extra junk why not take advantage and remove them.
-
@Dellsam, I appreciate that, thanks, I'm just wondering about the use of the "15:11" Skiller mentions in the whole process.
-
In numbers:
The sampling raster of DV camcorders follow as per DVCAM specification the Rec.601 standard. The luminance signal is sampled at 13.5MHz (for NTSC and PAL), which gives for NTSC a PAR (PixelAspectRatio)=10/11=0.909091 in very good approximation.
Therefore the DAR (DisplayAspetcRatio) of the recorded 720/480 frame (for NTSC) will become 10/11*720/480=1.363636=15:11.
Edit:
and similar for PAL:
PAR=12/11=1.090909 -> DAR=12/11*720/576=1.363636=15:11.Last edited by Sharc; 9th Jan 2023 at 03:42.
-
@Sharc thanks, but where is "15:11" actually used? I put 4:3 in my editor to export SD correctly, but Virtual Dub2's x264 encoder looks like it needs these ratios in the SAR boxes to output 4:3 SD video correctly. is it only in VDub (and possibly AVISynth) that these numbers are relevant?
For example, if I resize my PAL SD to 768x576 then export using a SAR of 1:1 in x264, a perfect 4:3 is the result. -
Either your player FORCES the 4:3 playback, squeezing the picture slightly, (e.g. when played back via HDMI). The ~2% error is not noticed by most people. A circle test will clarify.
or
The native digital source (e.g. on DVD without left/right small borders) has a PAR of 16/15 rather than 12/11. In this case DAR=16/15*720/576=1.3333.
You will only find the truth by means of circle tests (or other known shapes). Sometimes it's difficult to find out what it is actually.
Also, you can't always blindly trust the tools. They may calculate a quantity based on other (known) quantities and own assumptions.
You may also want to take a look here:
https://forum.videohelp.com/threads/406656-4-3-DVDs-with-Different-DARs/page2#post2665540Last edited by Sharc; 9th Jan 2023 at 04:25.
-
Well you probably meant or included DV sources when you wrote digital, but that would be wrong for DV sources.
Because...
And it's exactly what I found in my own tests some ~15 years ago, filming a square sheet of paper and then applying a 4:3 DAR and a 15:11 DAR to the 720x576 DV frame. 15:11 was always the one which resulted in correct proportions (despite there being no 16 pixels of blanking). -
Yes, DV follows the rec.601 spec. The 4:3 frame is contained in a ~704x480 portion of the 720x480 frame. That makes the full frame slightly wider than 4:3. If you do the math you'll see it's 15:11 (1.363636...:1). This is the same for natively shot DV and for DV recordings of 4:3 analog NTSC sources. Several people have verified this in theory and in practice.
DVD is also "digital". And by the DVD spec the entire 720x480 frame comprises the 4:3 image. But we all know that analog tapes are often captured via the rec.601 spec (704x480 4:3 video padded out to a 720x480 frame) and then encoded as MPEG 2 flagged as 4:3 DAR -- without compensating for the difference between the rec.601 spec and the MPEG 2 spec. -
Originally Posted by Skiller
-
15:11 is the shape of the pixel, or SAR, sample aspect ratio a.k.a pixel aspect ratio.
It's debatable, I've had mixed results doing circle tests, I guess it all comes down to the camcorder design and how the imaging sensor aspect ratio is implemented, If I may guess I would say the first generation DV and D8 camcorders followed the rec.601, later generations followed the second part of DVD standard for full screen resolution. -
@Alwin: All the scalings are within pixel accuracy, integer rounded and sometimes mod2. Nevertheless I would have expected 1.36 vs 1.33 in your case, rather than 1.35 vs 1.33.
-
Nope. 15:11 is the DAR (Display Aspect Ratio) of the DV frame. The SAR (aka PAR) of a "4:3" NTSC DV is 10/11 and for a PAL DV is 12/11. See post#16.
If I may guess I would say the first generation DV and D8 camcorders followed the rec.601, later generations followed the second part of DVD standard for full screen resolution.Last edited by Sharc; 9th Jan 2023 at 13:44.
-
I didn't follow what the number 15:11 refers to, I just know DAR is 4:3 and SAR is another ratio so I had assumed it was 15:11, Sorry for the confusion.
The 2x8 pixels padding black side bars have just been substituted by extra picture content, eventually making the DAR 1.3636 rather than 1.3333. The SAR (aka PAR) always remained the same, i.e. 10/11 for NTSC and 12/11 for PAL. -
-
-
So what is the final PAR for PAL DV? 16:15 or 12:11? I followed the discussion but it seems stuck.
(Wikipedia gives 16:15 for digital recordings)
-
This has been discussed and investigated in some other thread(s) which I don't find right now.
The conclusion was that according to the original DVCAM spec the SAR (aka PAR) is 12:11, based on the luma sampling rate of 13.5MHz, same as Rec.601:
The sampling raster of the DVCAM is the same as that of the ITU-R Rec.601.
Luminance video signals are sampled at 13.5 MHz, .....
The frame width may however be padded with extra picture content to extend the 704 to 720 pixels rather than using left and right black borders, but the SAR (aka PAR) is still 12:11, means DAR (Display Aspect Ratio) becomes 1.36 rather than 1.33 in that case.
Later camera models which support DAR 16:9 and 4:3 however ignored the original spec and used 720x576 with SAR (akla PAR) of 16:15 for DAR 4:3.
To find out what applies in the particular case one may have to do the "circle test" or accept an ~2% uncertainty.Last edited by Sharc; 16th Jun 2023 at 09:09.