value of pro res version

[devdev]

hi client has asked me for a pro res file and an mp4 version too from a betacam sp tape

my normal workflow is capture via my advc 100 as an AVI (windows xp). and then convert to mp4 with tmpgenc 7

is there any benefit for the client to have a prores version since i could be wrong but the avi i produce at 12gb an hour plus a decent extra conversion to mp4 sounds quality enough in my humble view.

would appreciate your opinion

[Cornucopia]

Have you told them your view, and your workflow?


Scott

[4kblurayguru]

is there any benefit for the client to have a prores version since i could be wrong but the avi i produce at 12gb an hour plus a decent extra conversion to mp4 sounds quality enough in my humble view.

would appreciate your opinion

give the client what they want, prores
but you should ask for exact specs, prores 422 or 422 hq
what codec for mp4, what bitrate etc.

[devdev]

Have you told them your view, and your workflow?


Scott

no i haven't actually cornocopia

[Cornucopia]

Sorry, I'm trying to say this without any judgement or offense, and understanding that I am a professional, but rarely do conversion myself anymore, if I approached you and wanted work, but found you used DV as a digitzation vehicle, and didn't even describe your workflow, or know in detail about the benefits of digital near-lossless intermediates like prores, I would certainly take my business elsewhere.

Would you use a plumber that didn't understand U-joints and still wanted to use lead pipes?

Scott

[Alwyn]

Obviously it depends on how much is being charged.

[Alwyn]

Anyway, what's wrong with a DV workflow? It's the one used by Video99UK that everybody here loves (or at least refuses to criticise).

[rgr]

hi client has asked me for a pro res file and an mp4 version too from a betacam sp tape

my normal workflow is capture via my advc 100 as an AVI (windows xp). and then convert to mp4 with tmpgenc 7

is there any benefit for the client to have a prores version since i could be wrong but the avi i produce at 12gb an hour plus a decent extra conversion to mp4 sounds quality enough in my humble view.

would appreciate your opinion

Prores is YUV422 (10 bit), MP4 YUV420 (8 bit) (usually), so ProRes is (little) better quality. In further editing it becomes quite important.

[frank_footer]

there are different "flavors" of prores and each supports various pixel formats and bit depth.

prores lt and hq are 10-bit yuv422 but prores 4444xq is a really high quality 10-bit yuva444 variant and more demanding on the system to work with,

[Cornucopia]

Anyway, what's wrong with a DV workflow? It's the one used by Video99UK that everybody here loves (or at least refuses to criticise).

There are a few things quite good about a DV workflow:
1. simple setup, particularly with the computer side of the equipment. with less to need to adjust, there is less to potentially get wrong
2. a quick & straightforward transfer chain (aka convenient)
3. because of quick & straightforward & simple, it is usually quite inexpensive to get hardware
4. codec is easy to accommodate with modern computers, bitrate & complexity-wise

There are also claims that it "fixes" issues with timebase. It doesn't - all it does is move the burden of that task away from the PC and toward the digitizing device. This often has the effect of "locking in" the image, but this could be a good image or a bad image, and it could be in sync or out of sync, depending upon how well the digitizing device handles wild signals. It clearly has a frame buffer on its output, but may not have one on its input. So, once again, we are left with the need - when using anything but rock solid signal timing - of a dedicated true TBC in line in the chain (obviously, upstream of the digitizing).

The downsides of standard DV workflow are already well known (even by Video99UK, I would assume):
1. DCT compression that is visible, noticeable, perhaps even objectionable with artifacts
2. locked in 8 bit color depth, which shows banding on content
3. forced to use 4:2:0 (for PAL) or 4:1:1 (for NTSC) color subsampling
4. locked into an older, less efficient codec format, that is no longer universally playable on devices (if it ever was)

****************

the OP's client has BetacamSP as a source, so luckily it *may* not need TBC assistance (that's another issue), but BetaSP is basically the pinnacle of SD analog quality, and it would be a shame to relegate its content to a middle-of-the-road/mediocre workflow, just because of convenience. And since they specifically asked for ProRes, there is a very good assumption that they intend to do further editing down the road, and that means that DV is by far less optimal quality-wise than ProRes at maintaining the pristine signal provided by BetaSP and expected throughout the workflow.


Scott

[Alwyn]

So, this situation doesn't sound as abhorrent as first made out by some.

The OP usually uses DV. Fair enough. There is no suggestion that the OP has been spivving the client by using DV when they expect something else.

The client has asked for Prores for this Betacam SP tape. Fair enough.

The OP is asking for opinions on DV verses Prores. Fair enough.

The OP could/should capture that tape as requested.

Job done.

Where you get/How you install the Prores I have NFI!

[rgr]

The downsides of standard DV workflow are already well known (even by Video99UK, I would assume):
1. DCT compression that is visible, noticeable, perhaps even objectionable with artifacts
2. locked in 8 bit color depth, which shows banding on content
3. forced to use 4:2:0 (for PAL) or 4:1:1 (for NTSC) color subsampling
4. locked into an older, less efficient codec format, that is no longer universally playable on devices (if it ever was)

1&3. Right.
2. It seems so, but with VHS material it doesn't matter.
4. Yes, but it doesn't matter much because the material needs to be edited anyway.

And there are already recorders that record to H264.

[Cornucopia]

2. As was stated by the OP, this isn't vhs material, it is BetacamSP, so it DOES matter.

4. You don't ever want to compound your losses if you can avoid it, so for best practices of master quality video you should record to uncompressed, lossless, or near lossless (which high quality prores IS), and only after editing do a final lossy encode to your distribution codec of choice (e.g. h264, h265). So yes, it DOES matter.

And yes, recorders that record to h264 are, with few exceptions, not master level quality, either, so also to be avoided.
Contrast those with an AtomOS recorder that IS rated for master recording, and usually does record straight to prores.


Scott

[rgr]

2. As was stated by the OP, this isn't vhs material, it is BetacamSP, so it DOES matter.

Rightly so. But it's still a noisy (although less so) analog input, so it's still marginal.

4. You don't ever want to compound your losses if you can avoid it, so for best practices of master quality video you should record to uncompressed, lossless, or near lossless (which high quality prores IS), and only after editing do a final lossy encode to your distribution codec of choice (e.g. h264, h265). So yes, it DOES matter.

It's obvious that lossless is best. But the conclusion was that the DV codec is a problem, because nothing supports it. It's not a problem, because the material has to be edited anyway.

And yes, recorders that record to h264 are, with few exceptions, not master level quality, either, so also to be avoided.

The main problem with them is that I haven't seen any that can record interlaced material (although support assures that Hauppauge Hd Pvr Pro 60 can do it).
However, my experience with AverMedia ER330 (H.265 12Mbit/s for 576p) indicates that the quality is OK. Even UGREEN HDMI capture (75Mbit for 576p, mjpeg) gives decent quality, although it sucks for other reasons.

Contrast those with an AtomOS recorder that IS rated for master recording, and usually does record straight to prores.

Somewhat for other purposes.

[Cornucopia]

Noisy? Nope. BetacamSP's SNR was at wosrt 48-49, but usually 51-53dB. Which means it was better than consumer DV (49 theoretical max), and not quite the level of pro DVCam (55max) or DVCPro (56max).
Just because something is analog doesn't make it noisy, and neither does that argument hold true just because it's SD.
Sounds like you are going off presumptions & internet anecdotes instead of facts & first-hand experience here.

The conclusion is that DV is a consumer-based compromised format, which isn't likely appropriate for a pro source & workflow.


Scott

[Alwyn]

Speaking of ProRes, where can the encoder be downloaded from or is it propriety to Apple programs?

[Sharc]

Speaking of ProRes, where can the encoder be downloaded from or is it propriety to Apple programs?

You can try your luck here (I didn't):
https://www.winxdvd.com/video-transcoder/prores-codec-for-windows.htm
From there:

[Attachment 80960 - Click to enlarge]

or in ffmpeg:
https://ffmpeg.org/ffmpeg-codecs.html#ProRes
NLEs based on ffmpeg usually include these codecs

[rgr]

Speaking of ProRes, where can the encoder be downloaded from or is it propriety to Apple programs?

I have one, but I don't remember where from.
https://imgur.com/KPw4iFr
However, I suspect that this is a plugin for VD.

[Sharc]

Try according post#2 here:
https://forum.videohelp.com/threads/367446-Virtualdub-External-Encoder-feature#post2348879

Edit: it works here:

[Attachment 80962 - Click to enlarge]

[Alwyn]

However, I suspect that this is a plugin for VD.

It comes with VDub2, but it doesn't work properly. All I get is a corrupted video.

[rgr]

However, I suspect that this is a plugin for VD.

It comes with VDub2, but it doesn't work properly. All I get is a corrupted video.

I've used it a few times, (yesterday, today), it works flawlessly.
Do you know that there are new libraries for VD v.44282?

[Sharc]

However, I suspect that this is a plugin for VD.

It comes with VDub2, but it doesn't work properly. All I get is a corrupted video.

I've used it a few times, (yesterday, today), it works flawlessly.
Do you know that there are new libraries for VD v.44282?

Works nicely here as well.

ffmpeg: Lavc57.104.100

[Alwyn]

Do you know that there are new libraries for VD v.44282?

I did do something to VDub recently; how can I tell?

I also get the same corrupted ProRes mess with Hybrid.

[rgr]

https://github.com/v0lt/avlib_vdplugin/releases/tag/0.7.0

[Alwyn]

That went well... not. All the FFMPEG entries disappeared (including the ProRes)) and now there's no ProRes at all. And what's with all the DLLs?

Pity the people that put this stuff together don't make a quick Readme about what to do with the files in the package.

[Sharc]

Pity the people that put this stuff together don't make a quick Readme about what to do with the files in the package.

??? There is a avlib-1_readme.md in the plugins64 folder of the package

[rgr]

That went well... not. All the FFMPEG entries disappeared (including the ProRes)) and now there's no ProRes at all. And what's with all the DLLs?

Pity the people that put this stuff together don't make a quick Readme about what to do with the files in the package.

Have you tried simply unpacking to a new folder and running it?
If that works, then add the filters from old version (x64).
Notice the dll files in the main folder. (I guess you have new avlib-1.vdplugin but no dll)
Don't copy old avlib-1.vdplugin.

[Alwyn]

Have you tried simply unpacking to a new folder and running it?

I did consider that but have many plugins I didn't want to get overwritten by older versions.

I may have to, given the "new" 44282 version has those DLLs which the "old" 44282 doesn't.

As for ProRes, is that put in via those DLLs because it didn't show up with the new avlib-1 that I could see.

??? There is a avlib-1_readme.md in the plugins64 folder of the package

[Attachment 80963 - Click to enlarge]


[Attachment 80964 - Click to enlarge]

WHERE?

[rgr]

Here. But what for?

[Sharc]

@Alwyn: Your package seems not to be the latest version (if this should matter).
Download the avlib_vdplugin_0.7.093.7z only, keeping your current working Vdub2 as is. Unzip the .7z, and in the plugins64 folder there is the readme.md with the instructions:

# Usage

Copy 'avlib-1.vdplugin' to 'VirtualDub2\plugins64' folder.

Copy FFMpeg DLLs to 'VirtualDub2' folder.
* avcodec-61.dll
* avformat-61.dll
* avutil-59.dll
* swresample-5.dll
* swscale-8.dll

FFMpeg 7.0.1 binaries used: https://www.gyan.dev/ffmpeg/builds/packages/ffmpeg-7.0.1-full_build-shared.7z