Yes I saw it before and the resolution was crisp I uploaded in 1920 x 1080 which is also what I recorded in

If you previewed your finished exported video on your computer full screen, and uploaded to youtube and waited for youtube to finish processing your 1080HD video (which can take some time), then it's youtube where the problem is.

@Hamid-Bilverdy

Which program and version are you using?

John CB

I am using VPX 12… I just got it in a humble bundle on sale..

@Hamid-Bilverdy

Hi and welcome to the forum

I would agree with @Reyfox comment - the issue is down to Youtube, however more information may indicate a way to 'persuade' YT to improve your uploads.

Download and install MediaInfo and analyse one of the clips and post the results, see this tutorial on how to setup MediaInfo and analyse a video clip for all the data required.

Which export setting did you use and did you change any of the parameters of the preset? A screenshot of the export dialog would help and also a MediaInfo analysis of the file you exported.

I would also suggest you put your computer specification and program version into your profile, Signature, see this topic for what is required and please quote processor and graphics card make/model in full. Then we will not have to ask for it in future posts you may make.

Thanks

John EB
Forum Moderator.

Will do indeed.
Thank you.
 

@Hamid-Bilverdy

Hi and welcome to the user to user site.

YouTube. Will re-encode all uploaded files again and often using the lower quality codec for HD content. It will cause some degradation from your original finished render. That is very difficult to avoid from happening.

Ray

Ok. What is the preferred way to export to YouTube to to get best quality

@johnebaker gave you several suggestions that will help you get suggestions/answers. If you want answers, you will have to provide the necessary information in that post.

@Hamid-Bilverdy

What is the preferred way to export to YouTube to to get best quality

Export out of VPX at at least 2560x1440, 25 frames a second and at as high a bitrate as you can stand for upload. Higher bitrates improve the quality and should fix your noise/grain. Set the "coding quality" to Best; you can leave all the rest of the video export settings as-is. Any lower eg 1920x1080 (1080P) will result in Youtube encoding in AVC.

Youtube will encode your video with the VP9 codec, better than AVC. All your resolutions for that video (eg 360P) will be in VP9.

@AAProds @Hamid-Bilverdy

Hi Al.

It is my recent experience that only the 4K viewed version gets the VP9 codec and lower resolutions are still shown using avc for at least a week before they finally get encoded to VP9. To keep the average bit rate high you can opt for using all I frames during encoding. Even then you have to understand that dependent on the lighting conditions there can still be variations in the quality of what you see on YouTube and your original footage.

The darker the shooting conditions, the worse this problem becomes but with properly exposed footage at good lighting levels hardly any differences will be seen.

Top line of images from YouTube and beneath from the original export.

Sorry. Up load didn't go as planned first 3 images vs last 3 images.

Ray.

@CubeAce

Ray, I was merely providing practical numbers for @Hamid-Bilverdy to use to get better quality on YT by invoking VP9.

Re the iframes, I'm not noticing any significant difference in file size. If I export at 6,000kbps, that's what VPX gives me, regardless of all-iframes or not, which makes sense to me.

@AAProds

Hi Al.

I was intending to add additional information as to why sometimes even trying to enforce a VP9 encoding sometimes still does not give desired results and possible solutions as to the next steps that can be taken to reduce possible re-encoding errors at the YouTube end. The idea of solely using I frames is not to reduce file size but just to ensure that existing B and P frames are exact copies of the original footage and not re-encoded that could produce alterations in the macro blocks that make up the image. Where there is less detail in areas that have very close luma and chroma similarities in adjacent macro blocks they can get combined into large blocks that may still not be that visible in the export form an editor to the PC screen but may get exacerbated in another re-encoding at the YouTube end. VP9 is not lossless and will compress less defined areas.

I did stress this can happen in video shot in difficult lighting conditions. As such I don't see it as contradicting your advice.

One thing you said I did find interesting is that you see little difference in file size by using all I frames. On 30 minute export of a project running at 25 fps up-scaled to 4K from 1080p I see a increase difference of approximately 6GB but I am not using a Magix preset.

Ray.

@CubeAce

One thing you said I did find interesting is that you see little difference in file size by using all I frames. On 30 minute export of a project running at 25 fps up-scaled to 4K from 1080p I see a increase difference of approximately 6GB but I am not using a Magix preset.

Ray, I'm really struggling with this. As far as I can see, we have no control over the "quality" of an export, only the average (and max) bitrates. You are saying that there are significant file size differences ie larger files if you choose all-iframes. That means, obviously, that the bitrate is also significantly higher. How can that be if we set the export bitrate?

Could you post the mediainfo reports from the two files (all-iframe and auto) so we can see the final bitrates.

@AAProds

Hi Al.

I have deleted that unused export file from my system as I deleted it from YouTube when the other file encoded with less differences. I can and will if you wish re-render the file tomorrow and give you the two sets of MediaInfo data. As far as I'm aware the lower the initial bit rate is set for the export the less difference you will see between using an IBBP GOP structure to an all I frame GOP structure.

At present I'm still not happy with the encoded VP9 uploaded version to YouTube and I'm still tinkering with the project in general. For that reason I haven't released it for public viewing yet and I still also want to tweak the audio as it was blowing a gale the night I recorded it.

If you are interested though here is what is probably not the finished version yet.

It took twenty three hours for the first 640 x 360 render to appear. Almost a week for the 4K version.

Ray.

@CubeAce

Ray, don't go to any special effort. I note that the file export size shown in the Format Description box is exactly the same for an IBBP export verses an all iframe export. That was for a movie of 2 hours to be exported at 20,000kbps.

The question is, why would there be a size difference? We don't have a "quality" control in MEP/VPX. If we did, I could understand an increase in size with all iframes. But we only have the bitrate control.

In any case, I suspect that @Hamid-Bilverdy will have no problem with noise if he exported at your bitrates. 6gb difference over 30 minutes? Wow!

@AAProds

Hi Al.

I only know what I see. I don't pretend to be an expert, I only look at and compare the results I get.

From what I understand of the differences between I and B and P frames is that both B and P frames look at other frames, don't compress where there are pixel changes within the frames but recalculate those that don't change and express them mathematically different to the original frames, saving encoding bits. An I frame can do some of that (Not look ahead but still look for blocks of similar adjacent colour contrast matches) and it would be possible that some macro blocks of similar / close / colour / contrast be grouped together, but less of that occurs. The less bits you allow the file to record,the more likely this is to happen, the less difference between the sizes between I B and P frames. If I recall correctly on what I read in the past that made me think this might be a good idea to pursue was the original H264 development group had a heavy discussion at the time as to whether it was a good idea to include P and B frames at all.

I still experiment all the time looking for a foolproof way to upload to YouTube but now and then they change the game plan. That file size per minute is the largest I've had to try to date. For good daylight I get away with lower settings although I always do my best to try to keep the bit rate of the files higher than the original files which tend to be up to 100.0 Mb/s.

General
Complete name                            : I:\2020\Legoland 2020\100MEDIA\DJI_0324.MP4
Format                                   : MPEG-4
Format profile                           : JVT
Codec ID                                 : avc1 (avc1/isom)
File size                                : 967 MiB
Duration                                 : 1 min 20 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 100 Mb/s
Encoded date                             : UTC 2020-09-26 10:47:48
Tagged date                              : UTC 2020-09-26 10:47:48
Comment                                  : DE=None, Type=Normal, HQ=Normal, Mode=P
gpt                                      : +3.50
gyw                                      : +2.60
grl                                      : +0.00

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L5.2
Format settings                          : CABAC / 1 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 1 frame
Format settings, GOP                     : M=1, N=30
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 1 min 20 s
Bit rate mode                            : Variable
Bit rate                                 : 100.0 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 50.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.241
Stream size                              : 965 MiB (100%)
Title                                    : DJI.AVC
Language                                 : English
Encoded date                             : UTC 2020-09-26 10:47:48
Tagged date                              : UTC 2020-09-26 10:47:48
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : avcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 1 min 20 s
Bit rate mode                            : Constant
Bit rate                                 : 192 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 1.83 MiB (0%)
Title                                    : DJI.AAC
Language                                 : English
Encoded date                             : UTC 2020-09-26 10:47:48
Tagged date                              : UTC 2020-09-26 10:47:48

Other
Type                                     : meta
Duration                                 : 1 s 0 ms
Bit rate mode                            : Constant
Default                                  : No

Ray.

@CubeAce, @AAProds

Hi

. . . . the differences between I and B and P frames is that both B and P frames look at other frames, don't compress where there are pixel changes within the frames but recalculate those that don't change and express them mathematically different to the original frames, saving encoding bits. . . .

This sounds the wrong way round . . . .

I frame - (Intra) is a complete image frame.

P (Predictive) frames store only the differences from the previous I or P frame,

B (Bidirectional) frames store only the differences between the current frame and both the preceding and following frames. How many frames are looked at depends on other settings which the user cannot normally change.

The encoding (compression) parameters are independent of the frame type, are influenced the bitrate settings.

The macro blocks sizes are basically controlled over a limited range by the Quality slider.

When encoding an IPB video to All Intra the encoder is using the I, B and P frames to reconstruct a complete I frame where there was originally a P or B frame. and can increase the file size significantly.

John EB

@johnebaker

Hi John.

I thought that was what I was saying apart from saying which frames specifically were being looked at. 😂

Thank you for explaining it more clearly.

Ray.

and can increase the file size significantly.

My point is that when one sets the bitrate, that is what one gets, regardless of the type of frames encoded. The limited exports I've done using all-iframes and certainly the MEP encoder size prediction indicate that the file size will be exactly the same for the same bitrate setting. We don't have a quality slider/RF setting so any discussion about increased file sizes with all-iframes is IMO irrelevant.

Unless I'm missing something! 😂

@AAProds

Hi Alwyn

. . . . My point is that when one sets the bitrate, that is what one gets, regardless of the type of frames encoded . . . .

You are correct, however, IMHO, it needs qualifying which bitrate setting you are referring to - Average or Maximum.

The average bitrate may end up lower than the targeted average bitrate eg the export settings for the original video clip analysed below were: Ave: 22000 kbs and Max: 28000 kbs.

Setting the Ave and Max bitrates too low for All-Intra the encoder 'runs out of bits' to encode frames to the quality set resulting in increased blockiness and banding - see image comparison below - left is the original video clip, right an All-Intra version same Average and Bitrate settings for both - the All-Intra is not comfortable to view as it has a lot of 'frazzling'.

MediaInfo data

The file size has increased by ~ 53%.

John EB

@johnebaker @CubeAce

Thinking more about this, that second video is appalling quality. 1.5gb for 9 minutes should be great video; surely that isn't what all-intra (is that the all-iframe term?) is about. It looks to me as you'd have to triple the bitrate to go close to getting rid of those blocks. That'd be an insane 60,000kbps. Why would anybody bother? Is the improvement in quality worth all that extra data if uploading to YT regularly?