Talk:HDV

Untitled

Does anyone know how to do tables in Wikipedia so that you can also put in wiki hyperlinks?

The specification section of the HDV article needs hyperlinks but due to using the html 'pre' tag (in order to acheive two culumns) the hyperlinks are ignored.

Ericross

Hey Mikus, JVC isn't "THE ONLY" manufacturer of 720p cameras

Just thought you should know that. MC Dupree (talk) 15:04, 26 January 2010 (UTC)[reply]

JVC is the only manufacturer of 720p HDV cameras. This article is about HDV, rememeber? Mikus (talk) 18:55, 9 March 2010 (UTC)[reply]

HDV Compression

This section needs a little more data: exactly what is the bitrate of the compressed audio, and is there any sourcing data for the claim that (in the original version) the audio compression fools even people who claim to hear artifacts in 320kbps MP3 or (in my edited version) that the resulting audio is almost identical to the uncompressed audio? Are there any disputes about that? cluth 08:32, 5 February 2006 (UTC)[reply]

I edited the video-compression description because it lacked some important context. Constant bitrate video isn't bad per se ... the problem is that the bitrate is below MPEG-2's sweet-spot for the chosen uncoded pixelrate (1280x720p30, 1440x1080p30.) I'm not sure why the article goes so far to mention "interframe coding" -- that is a feature/characteristic of MPEG-video in general, and seems redundant. I suppose it's significant when doing a side-by-side comparison of HDV with its non-interframe predecessor, DV? —Preceding unsigned comment added by 99.190.167.164 (talk) 02:42, 9 April 2010 (UTC)[reply]

Interframe coding is not required when using MPEG-2. Itraframe coding with MPEG-2 is perfectly legal. Actual uses: Sony IMX, Ikegami 100 Mbit/s MPEG-2, certain formats offered by Focus Enhancements. Same with AVC: you can have interframe AVCHD as well as AVC-Intra. Mikus (talk) 05:29, 25 June 2011 (UTC)[reply]

Horizontal vrs Vertical resolution

"the spatial resolution of the human eye is less sensitive to differences in horizontal resolution than vertical resolution.

Do we have a reference for this? [[[User:Efbasham|Efbasham]] 07:34, 12 October 2007 (UTC)In the field of high pressure house painting, users are told to always finish coat using vertical strokes with the spraygun. The reason given is that the eye becomes accustomed to reading along horizontal lines, and thus searches for them. The inevitable overlap in house painting results in small bands, which when kept vertical normally go un-noticed, while horizontal bands of the same size are quickly picked up by the human eye although no physiological reason exists for this.] I've heard it once before somewhere, but I am skeptical. I thought the reason for dropping horizontal resolution was that the vertical resolution was not truly 1080 due to the effect of interlace, and pixels are used most efficiently if horizontal and vertical resolutions match. (In other words, you won't notice the loss because the picture is already blurred vertically, and 1440 pixels blurs it horizontally to the same extent.) Algr 08:02, 20 February 2006 (UTC)[reply]

I have observed that horizontal resolution is more important than vertical, because most images contain a lot of prominent vertical edges such as grass, trees, fences, etc. The argument for vertical blurring by line structure is no longer valid, now that most (plasma and lcd) displays present a sampled image in both directions. In the old days of the CRT, the picture was presented as samples vertically, but as a continuous function horizontally. This remained true even on digital broadcasts, since the video waveform was reconstructed to a continuous analog waveform by simple filtering before it reached the CRT. Now, resolution is lost in both directions because the image is presented as samples without the reconstruction filtering that is theoretically needed. We will not see the true resolution of HD until displays are available with at least twice the resolution of the signal in both directions (3840 x 2160 pixels) with digital reconstruction filtering, a fact that is not widely recognised. It is for this reason that SD video looks better on modern plasma displays than it ever could on CRT's - the image is finally being digitally reconstruction filtered prior to display, rather than just presented as samples (the samples are not the image, they are, strictly, a mathematical encoding of the image according to Nyquist theory). In practice, many other things (lenses, CCD's, processing circuits) reduce sharpness by causing a roll-off in spatial frequency response (also known as modulation transfer function), such that the full resolution of any video format is rarely realised. This is why movies look better than most video - they are shot to a higher resolution than the video, using the best lenses, and then re-sampled, giving a result with less roll-off in spatial frequency response as well as less aliasing. --Lindosland 12:26, 11 November 2006 (UTC)[reply]

My understanding is that the designers of HDV decided to reduce the horizontal resolution a little in order to stay within the 25Mbits/sec of the DV recording standard. This is acceptable since HDV camcorders do not represent the high-end of HD and so will not have the lenses needed for full 1080 line quality. Reducing both vertical and horizontal resolution to achieve the same end would have effectively created a new standard rather than just requiring simple interpolation in one direction. --Lindosland 12:38, 11 November 2006 (UTC)[reply]

Inclusion of Panasonic HVX200 camera

I refer to the recent reversion, and my attempts to scale down (not entirely exclude) mention of the Panasonic HVX200 camera in the History section.

This camera is NOT an HDV camera. Why then must an entire paragraph be devoted to it in the "history of HDV"? I do believe it is relevant, but only insofar as it shows that a major player in the "prosumer" camera market decided NOT to go for the HDV standard, but try a different approach altogether.

It is relevant, but I think it is confusing to include it as it currently stands, because the average reader may assume that this camera is a slightly different kind of HDV camera.Anselan

The HVX200, if mentioned at all, should be described as an alternative to HDV for entry-level HD production - and hence should not be listed in the section labeled "HDV history." (Kevin Shaw, Aug. 7, 2007)

I also think it's really odd that a P2 card is compared to a MiniDV tape. I am tempted to change or remove the comparison... Burbble (talk) 15:27, 6 July 2008 (UTC)[reply]

HDV vs. brodcast HDTV

The comparison to (ATSC) broadcast HDTV were, in my opinion, off the mark. The bitrate of ATSC is limited to ~19 Mbps, whereas HDV/1080i is 25Mbps. But that is ONE factor out of many more, equally important factors. The HDTV-broadcast chain includes some pre-processing (deinterlacing, spatial filtering, de-noising, etc.), and the broadcast MPEG-encoder operates under a different set of rules (closed GOP, GOP-size, etc.) The conclusion is that while HDV/1080i's bitrate exceeds ATSC, it does not necessarily mean a superior picture.

My intention was to make clear the fact that any motion artefacts on HDV are absolutely negligible compared to the very obvious MPEG artefacts that viewers in the UK are familiar with on SD (Freeview) broadcasts where the bitrate is only 2 to 4Mbits/s. This is partly because any defects on HD will be on a finer scale, but also because the bitrate allocated to these broadcasts tends to be too low. --Lindosland 12:05, 11 November 2006 (UTC)[reply]

A comparison of HDV to HDTV broadcast signals is relevant in the sense that it reveals some similarities between the two, suggesting that HDV is a decent solution for independent video production. If MPEG2 encoding at 19 Mbps is good enough for broadcast HDTV delivery then it ought to be acceptable for recording purposes too - and the fact that HDV cameras are being used for several popular TV shows proves that point. (Kevin Shaw, Aug. 7 2007)

The comments about Apple Intermediate Codec being very lossy and giving no real time performance is simply untrue.

Choosing your ideal HDV Camcorder

Hi I've got an article about choosing an HDV camera for certain purposes: http://www.creativevideo.co.uk/public/articles.php?article=10 Fuutott 09:25, 25 October 2006 (UTC)[reply]

Your article referenced above mixes HDV cameras with the HVX200 and XDCAM HD, neither of which are HDV-based. Also, the HVX200 isn't entirely "better on paper" than HDV alternatives, because its sensor has significantly fewer pixels (960x540) than competing alternatives (960x1080 for Sony, 1280x720 for JVC and 1440x1080 for Canon). This results in measurably less real-world resolution for the HVX200 in detailed tests, although that arguably evens out somewhat when motion artifacts for HDV are taken into account. Also note that Discovery HD (and possibly other networks) has decided to classify the HVX200 with HDV cameras in terms of acceptability of content for HD projects. The HVX200 isn't particularly any better as a *camera* than HDV alternatives, it just uses a more robust recording format. The Sony XDCAM EX due out at the end of 2007 should be technically better than other HD cameras under $10K due to its larger sensor size, but it remains to be seen what the quality of footage it produces will be like. (Kevin Shaw, Aug. 7, 2007)

Deinterlacing and web section

The deinterlacing and web section is rather poorly written to be frank. For example, it claims that PC's don't support interlaced content properly which AFAIK isn't true since a number of options are available for realtime deinterlacing including hardware accelerated. And of course, PC users do have the option of doing non-real time deinterlacing. I don't know how these compare to plasma but they are there. Another problem section:

It is not impossible to achieve good results though, if the correct methods are used to deinterlace the footage. See the examples on this page. The showcase material is of course all from film, and therefore 24p to begin with, avoiding the deinterlace problem.

This appears to be saying it's possible to achieve good results (which isn't a surprise), look at the examples. But wait, the examples weren't actually deinterlaced... Say what?

I actually question whether this section is needed and if it is, in such depth. This appears to be related to HD video and interlacing and the web in general. Not HDV specifically. As such, I would suggest it's best covered in another article Nil Einne 10:54, 23 December 2006 (UTC)[reply]

--

I agree that the deinterlacing section is poorly written. For example, the statement that WMP does a poor job deinterlacing is completely misguided because WMP doesn't actually ever perform deinterlacing on its own - that is the job of the decoder or renderer, not the player. Also, the statement that quality deinterlacing takes a "whole night" is obviously subjective and based on one person's experience on their own computer.

I would suggest that a topic be included which deals with whether all cameras which claim 1080p are equal ? e.g Panasonic AG-HVX200 which claims 720p vs. Panasonic AJ-HDC27H which also claims 1,280 x 720. Is the result the same? If not, why ? These are questions which could be addresed as a separate topic. —Preceding unsigned comment added by 124.43.236.118 (talk) 10:31, 9 February 2008 (UTC)[reply]

Inaccuracies and Redundancies

I have a few suggestions as to how we may make this article even better.

As somebody mentioned above, if a camera is not true HDV, then it should be omitted from the article. e.g. the Panasonic DVCPRO HD cameras.
The discussion on MPEG 2 should only go so far as to say that HDV uses Long GOP MPEG-2 at 25mbps, and any other technical details related to recording MPEG 2 to tape (i.e. tape dropout, etc). Any discussion of MPEG-2 should use the standard MPEG-2 nomenclature, i.e. I frames, B frames, P Frames, where relevant. The term "key frame" should not be used in this article at all, seeing as "Key Frame" has a different meaning depending on the context, and in the context of Video it can refer to animation key frames as well as I frames. The structures and other in-depth technical details of MPEG 2 should be referenced to the article on MPEG 2.
The "Overview" section is probably a little too broad for an overview section. There are several redundancies between that section and the "HDV Compression" section.
Perhaps the "Notes regarding specific camcorder models" section should be expanded to include Canon's 24F and 30F (instead of 24P and 30P) formats on their pro camcorders (XH-A1, XH-G1, XL-H1). Once I get my XH-A1 and have worked with it a while, I will add to this section.
Perhaps we should add a section about HDV in relation to other HD formats such as HDCAM and AVCHD.
I agree that the "Deinterlacing and Web" section should probably be removed, seeing as it has very little to do with actual HDV and more to do with HD Video and Non-linear editing.

These are just some suggestions. Opinions? If there is no feedback on these, I will begin implementing some of them soon.

Dormous 16:15, 12 January 2007 (UTC)[reply]

I agree with Dormous' changes. Perhaps we should consder creating a sort of HD Format disambiguation page. There seems to be alot of splill over from one page to the other and it makes some of the pages pretty confusing. The DV page for example talks about DV, HDV and DVCPROHD all at once even though the later two have thier own pages.

HDV and WMV confusion

The article currently says "HDV has the potential to look extremely good on the Web, using 6 to 8 Mbits/s as demonstrated on the Microsoft WMV HD showcase site". This doesn't make a whole lot of sense to me, since HDV uses older MPEG-2 coding technology while WMV HD is a much more modern codec design. It should therefore be clear that the fact that some level of quality can be achieved with some number of bits per second using WMV HD does not indicate that the same quality can be achieved with HDV (i.e., MPEG-2) at those bit rates. In fact it should probably be taken as evidence that such quality cannot be achieved at those bit rates with HDV. Perhaps the statement is meant to say something else, but I don't know what it was attempting to say. -Pangolin 05:54, 10 May 2007 (UTC)[reply]

Sounds to me like an attempt to point out that HDV source can yield very nice HD web content using more compressed delivery codecs. Given that MPEG4 encoding is considered ~2-3 times as efficient as MPEG2, it makes sense to talk about compressing HDV for web delivery to around 1/3 the bit rate. What's not clear about this is whether any of the content on the Microsoft HD demo site came from HDV cameras. (Kevin Shaw, 8/7/07)

Canon

I have cleaned up the ever-(r)evolving Canon HV-line section: reformatted the text, official product links have been moved to the external links, links have been added to Wiki product pages, added HV40 and removed Vimeo from HV30's 30P references due to the fact that Vimeo's enco0der is locked at 24 fps.Szlevi (talk) 14:56, 6 May 2009 (UTC)[reply]

Product section

I restored the Product section, deleted by KelleyCook without leaving any comment here. He claimed WP:NOTCATALOG but the policy specifically mentions listing things that hasd great influence on the subject or are notable some other way.Szlevi (talk) 05:22, 7 May 2009 (UTC)[reply]

Use in Broadcast Television

Removed references to HDV being a "non-HD" format as described in some broadcast specification documents. While it is true that these documents make such statements, they're poorly worded in that HDV *is* an HD recording format by any sensible definition. It's one thing to say that HDV isn't accepted for some particular purpose and quite another to call it "non-HD" - hence quoting this is a mistake regardless of the source.

Reverted good faith edits

"DV cassette tape" is the official term, see the reflink.
"Direct to disc recording" is a marketing term, while the generic name for storage media is "hard disk drive".
I believe that "on-camera" is more up to the point in this particular case.
No need to empasize "video" tape, it is obvious, we are talking about tape-based video format.
"onto file-based tapeless camcorders" makes no sense at all. The point is recording on tape and onto file-based media on the SAME camcorder, not using several camcorders. Mikus (talk) 05:25, 25 June 2011 (UTC)[reply]

Edits by CDMIKELIS

These comments were added to the article by CDMIKELIS:

--

(*) Most of editing software can't cut exactly as GOP structure is, so recompressing of clip is done even when using only plain cuts. Real life editing requires at least some titles. So recompression is unavoidable in any real life situation and compressing footage again in HDV (22,5:1) degrade quality. Probably hard to see for untrained eyes when footage is made in ideal light, but again most real life siatuation (indoor, etc) with a lot of noise involved, suffers with every compression. Keeping original footage (on HDV tapes, or m2t files on HDD) and edited "project" or EDL, is recommended for later use. It can be always compressed to than needed format, from original; making only ONE(**) generation.

(**) A generation or recompressing is made at every rendering; if multiple filters or titles (or picture in picture) is used, that means so much "generations" of footage. Here is where good intermediate codec is better option: one generation to much less compressed intermediate codec is better than making 5-6 re-compression in MPEG-2 during editing process and final re-compression to even more compressed HDV.

--

First, this is not a forum or an email thread, you cannot throw in your comments like this, you must integrate them in the article and provide sufficient proof.
I integrated your comment about long-GOP nature of HDV. Indeed, even with straight cuts non-destructive editing can be done only by cutting between GOPs. I use Vegas, I don't know whether it is able to do that. On another hand, VirtualDub allows doing just that: it allows skipping over GOPs and cutting out unneeded fragments, then saving back to a stream with no recompression. VirtualDub may not even know much about the encoder, it just cuts out full GOPs from a container file, so all it really has to know is how the container works. Such an editing is lightning fast. tsMuxer has similar functionality too, though I am not sure whether it works on a container level, or on encoder level, it does not explicitly offer "cut on GOP" option, but in my experience trying to cut up to a millisecond does not work, tsMuxer always pads a bit. So I suppose that it works on GOP margins as well. Cannot prove it though.
Your comment on creating a separate generation for each filter if native video is used has no merit. Why MPEG-2 would be re-rendered between the effects, while say Cineform does not? After all, both of these are encoding methods, and any half-decent NLE should work universally with either. From what I know, most decent NLEs decode source video into uncompressed format internally as they go on, then apply ALL filters to this uncompressed video and then either display the result (in preview mode) or send it to a renderer (in render mode). So there is no real benefit for using intermediate codecs besides maybe some speed advantages, and also for sending your half-finished renders to other guys, so whenever multiple re-rendering is actually needed, it would hold better than MPEG-2. Please do not add this controversial (at best, though I think it is simply incorrect) "information" back to the article. If you want to argue, please post your finding here first. Maybe they do hold true for SOME NLEs. Mikus (talk) 21:43, 18 July 2011 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 7 external links on HDV. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 06:06, 27 October 2017 (UTC)[reply]