VideoHelp Forum

+ Reply to Thread
Page 4 of 4
FirstFirst ... 2 3 4
Results 91 to 113 of 113
Thread
  1. Originally Posted by Skiller View Post
    DV is always BFF no matter the source (native or from analog). Show me one device that does not comply with this. It is correct to automatically assume BFF with DV.
    Try capturing analog video into a DV with VirtualDub. All the dongles I have produce TFF, and VirtualDub records it as TFF. If you can help me producing DVCPRO50/BFF from VirtualDub so that it could be correctly opened by Vegas, I would be thankful. I wanted to standardize on DVCPRO50 as my capture/storage/edit format, but either the field order comes out wrong, or the file cannot be opened in Vegas (there are issues with aspect ratio as well).
    Quote Quote  
  2. Member DB83's Avatar
    Join Date
    Jul 2007
    Location
    United Kingdom
    Search Comp PM
    (ignoring the above which is blatant topic hi-jacking....)

    I looked through my files for a NTSC DV sample and the only one I have is shown below - I would have linked to the actual topic but I can not recall it right now. The only issue here is that there is no sound but from a test point of view that should not be an issue
    Image Attached Files
    Quote Quote  
  3. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    Originally Posted by ConsumerDV View Post
    Try capturing analog video into a DV with VirtualDub. All the dongles I have produce TFF, and VirtualDub records it as TFF.
    Right, that's because the raw input into VirtualDub is TFF with just about any YUY2 capture device, and it doesn't touch it of course, so when encoded into DV it is still actually TFF. But that is a special case. This would never happen with actual DV hardware. You could just use any other lossy or lossless codec instead to get around this and have no issues in Vegas. I would not want to deal with DV unless that is what the hardware natively spits out via Firewire.

    Anyways, you can manually swap the parity during capture in VirtualDub by enabling filters.
    Use "Null transform" to crop a single line at the top, followed by the resize filter without any resizing but with "Letterbox/crop to size" set to the original capture height (such as 480 or 576). This adds a single black line at the bottom. Voilą, parity swapped.

    Image
    [Attachment 65037 - Click to enlarge]
    Quote Quote  
  4. Originally Posted by Skiller View Post
    Originally Posted by ConsumerDV View Post
    Try capturing analog video into a DV with VirtualDub. All the dongles I have produce TFF, and VirtualDub records it as TFF.
    Right, that's because the raw input into VirtualDub is TFF with just about any YUY2 capture device, and it doesn't touch it of course, so when encoded into DV it is still actually TFF. But that is a special case.
    It is as special as any other case of digitizing analog video, and this is exactly what I meant when I wrote: "Video digitized from analog into DV is often TFF".
    Originally Posted by Skiller View Post
    You could just use any other lossy or lossless codec instead to get around this and have no issues in Vegas. I would not want to deal with DV unless that is what the hardware natively spits out via Firewire.
    Well, I don't want to use just any other codec
    Originally Posted by Skiller View Post
    Anyways, you can manually swap the parity during capture in VirtualDub by enabling filters. Use "Null transform" to crop a single line at the top, followed by the resize filter without any resizing but with "Letterbox/crop to size" set to the original capture height (such as 480 or 576). This adds a single black line at the bottom. Voilą, parity swapped.
    I would rather remove a line on the bottom, in the head switching area, than on the top. Can I do that?
    After I do this and save, the file still seems to have wrong metadata, or is it my ancient (version 14) Vegas that cannot read it properly? In fact, out of two data points - aspect ratio and field order - Vegas 13 reads one correctly, Vegas 14 reads both incorrectly. And, to add injury to the insult, it does not show the video, it shows just black screen. Ok, this is my problem, I apologize to hijack the thread. We already have gone through this with DB83. After all, Purple2112 wants MPEG-2 or AVC, not DVCPRO
    Quote Quote  
  5. Originally Posted by ConsumerDV View Post
    Try capturing analog video into a DV with VirtualDub. All the dongles I have produce TFF, and VirtualDub records it as TFF.
    That's simply an error on your part. You created a file that's not to spec. DV from a DV camcorder or a DV capture device will always be BFF.
    Quote Quote  
  6. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    Originally Posted by ConsumerDV View Post
    It is as special as any other case of digitizing analog video, and this is exactly what I meant when I wrote: "Video digitized from analog into DV is often TFF".
    I get that (now), but please realize that you are probably the only one on the planet to capture with non-DV hardware but still choose a DV codec in VirtualDub. It is special.


    Originally Posted by ConsumerDV View Post
    I would rather remove a line on the bottom, in the head switching area, than on the top. Can I do that?
    I tried that out of curiosity, but there is no means of changing the default behavior that adds a single black line always at the bottom first. So the answer is no. This is pretty much a cumbersome hack anyways.
    Quote Quote  
  7. Originally Posted by ConsumerDV View Post
    • native DV is BFF
    • Video digitized from analog into DV is often TFF, which throws NLEs off because they expect BFF, but this is not your case.
    • MPEG-2 is TFF, and good software makes sure to convert DV/BFF to MPEG-2/TFF behind the scenes.

    I apologize for forgetting that you don't want to burn a DVD or BD, your mentioning of an Oppo player threw me off. I get it now that you want to use the Oppo as a network player, and it cannot play DV-AVI. This sucks, few players can.

    I have no idea why H.264 looks less sharp. Can be related to bitrate, to levels, to interlacing... With everything being equal, MPEG-2 is no worse than DV and H.264 is no worse than MPEG-2, and usually they are better at the same bitrate or as good as DV at lower bitrate, this was the whole point of developing new codecs.

    The original is DV 25 Mbit/s intraframe, so MPEG-2 10 Mbit/s interframe or H.264 5 Mbit/s will be visually about as good (I don't think there is a lot of difference between frames in your content, neither I think there is a lot of high-frequency detail). I pulled these numbers from thin air, if you really care you can output logs from an encoder and figure out how close the encoded video is to the original by analyzing encoder statistics, although I am not sure how this can be done if you change scanning type from interlaced to progressive... OTOH, they do compare deinterlacers somehow, so I guess this can be done. I have never done this myself and have only a vague understanding what numbers to look at. People who upload to torrent sites use such analysis religiously. I either set bitrate that I feel is sufficient, or use a CRF value.

    I don't see the point of increasing bit depth to 10 if the original is only 8.

    There is a reason to use 4:2:2 to preserve as much chroma as possible, but in real life you won't notice the difference. If it looks faded to you, you can boost color a little bit. You can also verify that the levels are correct.

    Since you are not going to upload it on YouTube, you can keep it interlaced, the Oppo has one of the best deinterlacers.
    I'm not using the Oppo as a network player, using it as a bd/media file player connected directly to my TV.

    I'm not changing the Color Bit Depth, DC Component Precision is not the same thing as Color bit Depth. See Settings
    Image
    [Attachment 65151 - Click to enlarge]

    I'll probably end up encoding all the videos to H.264 instead of Mpeg2 anyway so I might not ever even use that setting.

    Yes, I will be keeping the encoded videos as interlaced.
    Quote Quote  
  8. Originally Posted by DB83 View Post
    (ignoring the above which is blatant topic hi-jacking....)

    I looked through my files for a NTSC DV sample and the only one I have is shown below - I would have linked to the actual topic but I can not recall it right now. The only issue here is that there is no sound but from a test point of view that should not be an issue
    Thank you
    Quote Quote  
  9. Okay Guys, I need to start winding this thread down. At this point, I would like to know about the H.264 Advanced Settings and then I'll try and take it from there. I'll post one Advanced Settings photo at a time. 1st, I need to know if I can uncheck the (Encode Keyframes into I Frames) AFAIK this is only used if there are chapters or cuts made in the video. 2nd, can I go ahead and set the (P Frame Relative Quality) to 2X being the max. I going to try and use only I Frames in the GOP, but would still like to know about all the Advanced Settings. This is what the SW Help Files states about the (P Frame Relative Quality)
    Image
    [Attachment 65152 - Click to enlarge]

    Advanced Settings Photo
    Image
    [Attachment 65153 - Click to enlarge]
    Quote Quote  
  10. Member DB83's Avatar
    Join Date
    Jul 2007
    Location
    United Kingdom
    Search Comp PM
    To be frank, this is possibly not the thread to be discussing advance AVC settings since only those who have already contributed will actually look in.

    A new topic specifically about AVC advance settings should not be amiss and should grab the attention of those who know about these things.


    Personally, and since these go over my head, I just leave them at the default and concentrate on bitrate on, in the context of AVC, CRF value which in my own experience should be in the range of 18-20.
    Last edited by DB83; 2nd Jun 2022 at 12:24. Reason: typo correction
    Quote Quote  
  11. Originally Posted by DB83 View Post
    To be frank, this is possibly not the thread to be discussing advance AVC settings since only those who have already contributed will actually look in.

    A new topic specifically about AVC advance settings should not be amiss and should grab the attention of those who know about these things.


    Personally, and since these go over my head, I just leave them at the default and concentrate on bitrate on, in the context of AVC, CRF value which in my own experience should be in the range of 18-20.
    Unfortunately, there is no actual CRF value setting for H.264. Their version is VBR(Constant Quality) with a Quality setting 0-100. According to them if I was to set the Quality to 100 I would then have to set the bitrate to 60Mbps. This is what they told me about CQ and how it relates to CRF.
    Image
    [Attachment 65358 - Click to enlarge]

    How is using a CRF value any better that just using CBR(Constant bitrate)?
    Quote Quote  
  12. Originally Posted by Purple2112 View Post
    Unfortunately, there is no actual CRF value setting for H.264.
    How so? Haven't they given you the formula: CRF = (100 - Q) * 0.5 + 1, so Q = 102 - 2 * CRF

    According to their formula, quality = 100 does not give you lossless encode (CRF==0) as CRF will be 1. I wonder can you enter quality value 102 for lossless encode?

    Originally Posted by Purple2112 View Post
    According to them if I was to set the Quality to 100 I would then have to set the bitrate to 60Mbps.
    This is not what the attached email says.

    Originally Posted by Purple2112 View Post
    How is using a CRF value any better that just using CBR(Constant bitrate)?
    Constant bitrate is the same amount of bytes per second no matter how complex a scene is - useful for linear media like tape. CRF is the same quality per scene, so depending on scene complexity the bitrate will fluctuate. CRF implies VBR.
    Last edited by ConsumerDV; 12th Jun 2022 at 14:05.
    Quote Quote  
  13. Member DB83's Avatar
    Join Date
    Jul 2007
    Location
    United Kingdom
    Search Comp PM
    Well they do not exactly make things easy for you

    CBR allocates precisely that bitrate regardless of whether the actual video requires it.
    CRF only allocates bitrate subject to the complexity of the video.


    So with CBR you will have a firm idea of the final size which could result in a waste of bitrate.
    With CRF you have no way of anticipating final size but should have better quality subject to that weird calculation.


    Since we are typically using a x264, or compatabe, encoder we quote CRF values of between 0 (highest quality) and 51 (lowest) with typical values of between 18 and 23. I guess you can adapt these to the demands of this encoder.
    Quote Quote  
  14. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    I played around with version 5 of this software which uses x264. Doesn't your version use the same?
    You can open the file in mediaindo and can see the CRF value used for the corresponding
    TMPGMW CQ value
    CRF (CQ) allocates bits on demand to match the complexities of the frame/scene
    (Soft/sharp, flat/detail, noise/clean, still/ movement etc, etc).
    Last edited by davexnet; 12th Jun 2022 at 14:25.
    Quote Quote  
  15. Member DB83's Avatar
    Join Date
    Jul 2007
    Location
    United Kingdom
    Search Comp PM
    Well according to the file installation of v7, x264 is still relevant.

    They are just, apparently, clouding the issue with their settings/formulae.
    Quote Quote  
  16. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    Originally Posted by DB83 View Post
    Well according to the file installation of v7, x264 is still relevant.

    They are just, apparently, clouding the issue with their settings/formulae.
    Yes but you can do small test encodes using their CQ settings and see the actual CRF values used.
    Looking at the tests I did, I get this. Whether version 7 is identical can be tested
    CQ 60/CRF 21
    CQ 62/CRF 20
    CQ 70/CRF 16

    Here's how it looks in mediainfo:
    Image Attached Thumbnails Click image for larger version

Name:	rc.png
Views:	6
Size:	41.1 KB
ID:	65361  

    Last edited by davexnet; 12th Jun 2022 at 14:37.
    Quote Quote  
  17. Originally Posted by ConsumerDV View Post
    Originally Posted by Purple2112 View Post
    Unfortunately, there is no actual CRF value setting for H.264.
    How so? Haven't they given you the formula: CRF = (100 - Q) * 0.5 + 1, so Q = 102 - 2 * CRF

    According to their formula, quality = 100 does not give you lossless encode (CRF==0) as CRF will be 1. I wonder can you enter quality value 102 for lossless encode?
    Yes, in a round about way, that's why I used the word (actual). The setting doesn't go to 102. They are saying if I set the Quality to 60 the CRF value would be 21.

    Originally Posted by ConsumerDV View Post
    Originally Posted by Purple2112 View Post
    According to them if I was to set the Quality to 100 I would then have to set the bitrate to 60Mbps.
    This is not what the attached email says.
    It says "e.g. a video scene need 60Mbps for CQ100" Keep in mind that they are Japanese so their English is a little broken.

    Originally Posted by ConsumerDV View Post
    Originally Posted by Purple2112 View Post
    How is using a CRF value any better that just using CBR(Constant bitrate)?
    Constant bitrate is the same amount of bytes per second no matter how complex a scene is - useful for linear media like tape. CRF is the same quality per scene, so depending on scene complexity the bitrate will fluctuate. CRF implies VBR.
    Isn't this only important if I care about the finished file size?
    Quote Quote  
  18. Originally Posted by DB83 View Post
    Well they do not exactly make things easy for you

    CBR allocates precisely that bitrate regardless of whether the actual video requires it.
    CRF only allocates bitrate subject to the complexity of the video.


    So with CBR you will have a firm idea of the final size which could result in a waste of bitrate.
    With CRF you have no way of anticipating final size but should have better quality subject to that weird calculation.


    Since we are typically using a x264, or compatabe, encoder we quote CRF values of between 0 (highest quality) and 51 (lowest) with typical values of between 18 and 23. I guess you can adapt these to the demands of this encoder.
    Yes, I know what CBR and CRF do. I guess I should have asked the last question differently. (Aside from using more bits and having a larger finished file size is there any difference in picture quality when using CBR vs CRF?) Remember, I don't care about how large the final encoded file is, they can stay at the original 20GB DV file size for all I care. Also, because I may use only I frames in the GOP I will need to use a much higher bitrate. I'm not sure how that would work out with the whole CRF calculations.
    Quote Quote  
  19. Originally Posted by davexnet View Post
    Yes but you can do small test encodes using their CQ settings and see the actual CRF values used.
    Looking at the tests I did, I get this. Whether version 7 is identical can be tested
    CQ 60/CRF 21
    CQ 62/CRF 20
    CQ 70/CRF 16
    You did not believe their formula?

    Originally Posted by Purple2112 View Post
    The setting doesn't go to 102.
    Ok, so no uncompressed H.264 for you.

    Originally Posted by Purple2112 View Post
    It says "e.g. a video scene need 60Mbps for CQ100" Keep in mind that they are Japanese so their English is a little broken.
    Nothing is wrong with their English. If your set both quality value and max bitrate, and max bitrate is insufficient for the quality setting you use, the encode will honor the max bitrate value, so quality will suffer. The number they gave is just an example.

    Originally Posted by Purple2112 View Post
    Isn't this only important if I care about the finished file size?
    CBR is important if you want to send out to a channel that has constant rate like tape. You can control file size in VBR mode specifying max and average rates, or using CRF/Quality value. You can google for experimental values or do several encodes yourself and compare file sizes. The page I linked above shows some experimental data:



    Or from here:

    Quote Quote  
  20. Originally Posted by davexnet View Post
    Originally Posted by DB83 View Post
    Well according to the file installation of v7, x264 is still relevant.

    They are just, apparently, clouding the issue with their settings/formulae.
    Yes but you can do small test encodes using their CQ settings and see the actual CRF values used.
    Looking at the tests I did, I get this. Whether version 7 is identical can be tested
    CQ 60/CRF 21
    CQ 62/CRF 20
    CQ 70/CRF 16

    Here's how it looks in mediainfo:
    Okay, I just encoded a video using CQ @ 60 and ended up with / crf=21.0 / in MediaInfo specs as you stated. So at least now I will know what CQ value corresponds to what CRF value.
    Quote Quote  
  21. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    Originally Posted by ConsumerDV View Post
    Originally Posted by davexnet View Post
    Yes but you can do small test encodes using their CQ settings and see the actual CRF values used.
    Looking at the tests I did, I get this. Whether version 7 is identical can be tested
    CQ 60/CRF 21
    CQ 62/CRF 20
    CQ 70/CRF 16
    You did not believe their formula?
    Yes, but that's the first time I saw it. I did those comparisons two weeks ago.

    (I added the parenthesis for easier reading) :
    CRF = (100 - Q) * 0.5 + 1, so Q = 102 - (2 * CRF)
    Quote Quote  
  22. Member DB83's Avatar
    Join Date
    Jul 2007
    Location
    United Kingdom
    Search Comp PM
    Originally Posted by Purple2112 View Post
    Originally Posted by DB83 View Post
    Well they do not exactly make things easy for you

    CBR allocates precisely that bitrate regardless of whether the actual video requires it.
    CRF only allocates bitrate subject to the complexity of the video.


    So with CBR you will have a firm idea of the final size which could result in a waste of bitrate.
    With CRF you have no way of anticipating final size but should have better quality subject to that weird calculation.


    Since we are typically using a x264, or compatabe, encoder we quote CRF values of between 0 (highest quality) and 51 (lowest) with typical values of between 18 and 23. I guess you can adapt these to the demands of this encoder.
    Yes, I know what CBR and CRF do. I guess I should have asked the last question differently. (Aside from using more bits and having a larger finished file size is there any difference in picture quality when using CBR vs CRF?) Remember, I don't care about how large the final encoded file is, they can stay at the original 20GB DV file size for all I care. Also, because I may use only I frames in the GOP I will need to use a much higher bitrate. I'm not sure how that would work out with the whole CRF calculations.
    Since we can not judge the effect of either on your actual video you have to do some experimenting of your own. At the end of the day, only you can judge the visual quality.


    But you can, as far as what has been stated here, judge the DV sample I posted with jagabo's h264 i-frame only conversion which, even without audio was substantially larger. And I also posted an NTSC sample for you to experiment with.


    'Real' quality - not visual - is judged by how much information is lost by the encoding process. DV is still a lossy format so however you encode it you lose information. And just because that h264 was larger can not increase the original quality.


    (If the above has already been explained here than I apologise for the repetition)
    Quote Quote  
  23. Originally Posted by Purple2112 View Post
    Okay, I just encoded a video using CQ @ 60 and ended up with / crf=21.0 / in MediaInfo specs as you stated. So at least now I will know what CQ value corresponds to what CRF value.
    They gave you the formula. Oh, well.

    For selecting quality value you can use data from this article. He uses SSIM for measuring quality. If you want PSNR, you can get this value directly from X.264 log. I suppose, since you are so picky regarding quality, you should be looking at PSNR of 50 dB or more (Most people are very happy with 45 dB). Experiment with CRF/Quality value; after you reach the target SSIM/PSNR, there is no reason to increase quality/bitrate.
    Quote Quote  



Similar Threads