DV-AVI best format for viewing on a TV

[SkyBlues2021]

Thanks jagabo & Alwyn. I appreciate the advice. I'm a little nervous about the doing the first one it's been 18 months in the making! You have put my mind at rest. Thank you.

[SkyBlues2021]

I finally started encoding last week. I've been saving the videos in Virtualdub2 as MP4 (MPEG-4 Part14) noticed that there is also a MP4 + faststart just checking I've been using the correct MP4 Thanks.

[jagabo]

faststart places the keyframe index and metadata at the start of the file rather than at the end. That's good for online streaming or for playing files while they are downloading. For local playback it's not a big issue.

[SkyBlues2021]

Thanks jagabo. So am I probably best staying with MP4 (MPEG-4 Part14) as I'm going to put them on a hard drive and watch them through a TV? The encodes are going well they are taking approx. 3 times longer than the video's length to encode as I'm doing them at CRF 12 but no problems yet! Thanks.

[SkyBlues2021]

I've been encoding my DV videos with virtualdub2 SAR WIDTH 12 SAR HEIGHT 11 but I just read something that states DV SAR is SAR 16 HEIGHT SAR 15 WIDTH? I'm hoping I've not got this wrong? Thanks.

[jagabo]

I've been encoding my DV videos with virtualdub2 SAR WIDTH 12 SAR HEIGHT 11 but I just read something that states DV SAR is SAR 16 HEIGHT SAR 15 WIDTH? I'm hoping I've not got this wrong? Thanks.

The fact that you haven't noticed anything until now tells you something: nobody notices the difference.

The specification for 4:3 DV follows the ITU spec. The 4:3 image is contained in a 704x480 (SAR=10:11) or 704x576 (SAR=12:11) portion of the frame. So the full 720 pixel wide frame is slightly wider than 4:3. When used to digitize analog 4:3 sources the extra pixels are black borders (because that's what those analog recordings have there). But when recorded from the camera's sensor the extra pixels contain extra picture. From what I've seen early DV devices followed that spec. At least some later HDV devices appear to have gone with the MPEG spec where the DAR is from the full frame (720x480 SAR=8:9, 720x576 SAR=16:15).

The whole industry pretty much ignores the differences between the two specs.

[SkyBlues2021]

Thanks jagabo. Do you think it best I carry on with 12:11? I think what your saying is that the differences are negligible and the DV videos SAR is probably exactly the same as analogue video anyway? I've been frantically reading as much about SAR as I can today, but it can be quite contradictory. Thank you for the advice.

[Sharc]

ffprobe reports the SAR of your DV samples as 16:15. This is however no proof, as tools sometimes report these figures incorrectly, based on some assumptions.
The only way to verify is would be to do a "circle test". If you still have your camera make a shot of a perfect circular shape (e.g. a round clock, Disc, wheel or similar). Take the shot perpendicular, means straight from the front in order not to distort the circle to an oval. Then play the video with your player and take a (pixel) ruler to check if the circle is an exact circle or slightly squashed. Or upload your test clip here so someone may check.
You could also take a shot of an other object of known shape, like an exact square.
But as jagabo said it may not be worth the effort because the aspect ratio error between 16:15 and 12:11 is about 2% only, hardly noticed by anyone.

[SkyBlues2021]

Thanks Sharc. Sadly I haven't got that camcorder anymore. I believe that was our third camcorder and was probably used the least, as teenagers they were not so cute! I feel happier knowing that I'm at least not making a catastrophic error encoding 12:11. You and jagabo have put my mind at rest, I really appreciate that. Thanks.

[jagabo]

You might be able to find something in one of the tapes to use as a reference. A round clock in the background, a ball, a bicycle wheel, a square window, etc. The bigger the better, as it's easier to see the difference between say 300 vs .306 pixels vs 30 and 30.6 pixels.

[SkyBlues2021]

Thanks jagabo. I was able to find bicycles. On the first clip I've encoded both, one SAR 12/11 and one 16/15. I've also added another couple of clips but I felt the first clip is probably the best as the bicycle is stationary. I've watch both videos and I couldn't really tell any differences.

[jagabo]

I'd be more confident if the wheels were closer to the center of the frame. But I'd say those were SAR 12:11 (ITU 704x768 = 4:3 DAR). Here's a square box overlaid onto one of the wheels after resizing to square pixels, frame 267 after:

LWLibavVideoSource("TAPE 31 clip 3.avi") 
Bob()
Crop(8,0,-8,-0)
Spline36Resize(1536, 1152)

[Attachment 72107 - Click to enlarge]

[SkyBlues2021]

Thanks jagabo. What a clever way of finding out. My wife and I have viewed the clips 12/11 and 16/15 quite a few times now and we couldn't see any noticeable difference whatsoever, which in itself is comforting. I will stick with 12/11. I appreciate you figuring that out for me. Another random thing I noticed, on my smart tv whilst watching the encoded MP4 movies sometimes we get a audio blip. The MP4 and the AVI version both play fine on my computer WMP & VLC and another TV with a USB port. The only device this happens on is the smart tv hence the reason I've upload a mobile clip (It happens at approx. 20 seconds in). It's no big deal as the videos look fantastic but I just wondered if you may know why this happens. Thanks.

[jagabo]

I don't know the cause but there is an audible drop in volume at that point:


[Attachment 72109 - Click to enlarge]

[Alwyn]

Skyblues, I have been following this topic with interest as I have a soft spot for DV. Something I have noticed with your captures is that I can't open them in my NLE, Magix Movie Studio (or earlier versions) despite the files being the ubiquitous DVSD. There are only minor differences in the Mediainfo data, as follows:


[Attachment 72111 - Click to enlarge]

I "captured" mine with Scenalyzer. Nothing I did, swapping the codec to another and back to DVSD, would make your files readable, which is highly unusual as Magix has never had a problem with DV.

It appears that Virtual Dub is encoding the files with something that is making them unreadable in Magix.

I suggest that you make some enquiries with other NLEs to make sure that you can open your files in them. If you catch the bug and decide to go into making better videos eg with titles or reassembling them, you will need to be able to open them preferably without a transcode.

[SkyBlues2021]

Thanks jagabo. It has the same audio blip on my son's Samsung tv. I've done another copy of just that clip which plays ok on my smart TV. I would say the audio blip happens every couple of minutes throughout a 1 hour video. I will encode the full video again and see if this rectifies the problem. Strangely it doesn't happen on all the videos I have encoded.

[SkyBlues2021]

Thanks Alwyn. I captured mine with WinDV then I saved them to a separate drive from my OS. Then with the help of everyone here I was eventually able to do a simple script and encode with Virtualdub 2. I haven't done anything else to the files I haven't changed any codec, maybe I should have? Hopefully I'm doing everything correct but it does seem odd they are unreadable in your system.

[jagabo]

The only significant difference I see is a lack of an ODML extension header on SkyBlues2021's file. If that's the problem it's a bug in your software. AVI files less than 4 GB (some programs use 2 GB as the limit) don't require an ODML header.

By the way, VirtualDub adds ODML headers once the output AVI file exceeds 2 GB. It has an option to change that threshold to 1 GB.

[Sharc]

..... Something I have noticed with your captures is that I can't open them in my NLE, Magix Movie Studio (or earlier versions) ....

Alwyn: I just tried out of curiosity. Same here. These files don't open in MAGIX Movie Studio.

Btw. They open in other SW including the ffmpeg/libavcodec based NLE Shotcut which I am using for basic (actually all I need) NLE tasks mainly for the reasons discussed here

[SkyBlues2021]

Thanks jagabo & Sharc. I will encode another copy tomorrow and hopefully the audio blips will be ok. It's a minor thing anyway. I watched a copy that I had made on a DVD recorder approx. 16 years ago of Tape 38 and the quality difference was striking. It makes the weekends and evenings holed up in the spare room more than worth it. Thank you for all the great advice.

[SkyBlues2021]

I need to trim one of my DV AVI files but I wasn't sure of the placement of trim in my script as I've previously only used trim on interlaced scripts. I didn't know if it went before or after QTGMC. Also is ++ better than + for trim. Thanks.

[jagabo]

You can Trim() anywhere you want. But keep in mind that QTGMC doubles the number of frames. So Trim(5, 300) would equate to Trim(2.5, 150) if you did it before QTGMC. But Trim only supports integers so you would have to Trim(2,150) or Trim(3,150), the nearest options. The resulting video will have one extra field, or one fewer fields (frames after QTGMC).

Aligned splice (++) aligns audio properly even if there are gaps in the audio in some clips, regular splice (+) doesn't. I don't think it matters with your script because everything comes from one source and nothing you are doing will cause alignment changes. But it doesn't hurt to use ++ anyway. But in general, the audio and video in A/V files may not start at the same time and may not be the same length. For example, a clip may have audio that's one second shorter than the video:

v1 = WhateverSource("file1.ext") # 30 seconds video, 29 seconds audio, both start at t=0
v2 = WhateverSource("file2.ext") # 30 seconds video, 30 seconds audio, both start at t=0

v1+v2 will give you a video with 60 seconds of video and 59 seconds of audio. The audio from the second part will start at t=29, not t=30 -- so the audio of the second part will be out of sync by a second. v1++v2 will cause AviSynth to add 1 seconds of silent audio between the two clips, resulting in 60 seconds of video and 60 seconds of audio, with everything in sync.

[SkyBlues2021]

Thanks jagabo. It took a few reads but I think I understand. I've changed that trim to (6,300) and I will keep future trims so they can be divided but finish on a whole number. I guessing it better that I do the trim before QTGMC as I have already recorded the times of the cuts and after deinterlacing I will have twice as many frames.

On a previous script on another post I used AviSource("C:\Users\Dell\Desktop\opening presents 1.avi")++Avisource("C:\Users\Dell\Desktop\opening presents 2.avi") is the v1+v2 an alternative to this or would you use both in the same script. Thanks.

[jagabo]

I think you still don't understand. The trim numbers are the frame numbers at the point in the script at which trim is called, not the original frame numbers. After QTGMC you have twice as many frames as before it. So if you had 500 frames in the original video (frames numbered 0 to 499) you have 1000 frames after QTGMC (frames numbered 0 to 999). After QTGMC there's no reason you can't trim at odd frame numbers.

[SkyBlues2021]

Thanks jagabo. Just when I thought I understood I don't! Sorry, I can now see what I did wrong with my Trim, it should have been Trim(3,150)++Trim(155,242) if I did it before QTGMC. But if I did it after QTGMC would I then have to save the script watch it and find the new frames to cut after it's been deinterlaced or would it be Trim(12,600)++Trim(620,970) Sorry if this sounds crude. Thanks.

[jagabo]

Thanks jagabo. Just when I thought I understood I don't! Sorry, I can now see what I did wrong with my Trim, it should have been Trim(3,150)++Trim(155,242) if I did it before QTGMC.

I believe that's the case but haven't seen what your doing. I'll take your word that 3-150 and 155-242 are the portions of the original video you want to keep.

But if I did it after QTGMC would I then have to save the script watch it and find the new frames to cut after it's been deinterlaced or would it be Trim(12,600)++Trim(620,970)

No the frame numbers are doubled after QTGMC. So you trims would be 6 to 300 and 310 to 484.

Actually, I forgot about this earlier, but the last frame numbers aren't right, they should be 301 and 485. Consider a cut list from frames 0 to 1. That's two frames before QTGMC, 0 and 1 , and will become four frames after, 0, 1, 2, 3. The last number of the trim has to be the second value from before the trim times two, plus 1. To get exactly the same sequence. Ie, Trim(0,2) is only three frames. You need Trim(0,3) to get all four.

For checking frame numbers after QTGMC you can open the script in an editor that supports AVS as input and shows frame numbers -- like VirtualDub (the original or version 2). Then go through the video and decide where you want to cut (VitualDub shows you the frame numbers, or you can use ShowFrameNumber() in your script (after QTGMC) to stamp frame numbers onto the frames). This has the advantage of being able to cut at any field (now a frame). Finally, add the Trim after QTGMC with the frame numbers you got. Since QTGMC is slow I often use Bob() while doing this. Then change to QTGMC when I'm ready to render (with one last check to be sure).

Of course, if you already have a cut-list without QTGMC you should probably just go with it and Trim before QTGMC.

[SkyBlues2021]

Thanks jagabo. Thank you for your patience. I will do both methods tomorrow and post both. The clip I'm using is just to experiment with. I have changed the cut figures as I'm confusing myself. Just to clarify before I mess up again, if I wanted to cut from the video frames 1-7, 321-339, 481-485 and it was interlaced my script would be Trim (8,320)++Trim(340,480)
But as it's deinterlaced if I placed the trim before QTGMC in the script I would use the code Trim(4,160)++Trim(170,240) Sorry in advance if I've got this wrong again. Thanks.

[jagabo]

if I wanted to cut from the video frames 1-7, 321-339, 481-485 and it was interlaced my script would be Trim (8,320)++Trim(340,480)

Yes.

But as it's deinterlaced if I placed the trim before QTGMC in the script I would use the code Trim(4,160)++Trim(170,240)

I'm not sure what you're asking here. If you mean you determined the frame numbers after a double frame rate deinterlace (bob(), QTGMC(), Yadif(mode=1), etc), but you need to Trim before deinterlacing for some reason, yes, you need to divide the frame numbers by two. But why bother? You can just Trim() with the numbers you have after the deinterlace.

[SkyBlues2021]

Thanks jagabo. Hopefully this time I've got it correct. My cut reference point is when my sons fingers leave the book and it starts again when his chin appears in the left hand corner. Thanks.

[jagabo]

That looks right. I first see his chin at frame 306. But you can start anywhere you want.