YouTube Stutters

Joined
Nov 27, 2013
Messages
125
Reaction score
0
Can anyone tell me why YouTube doesn't like pan shots and turns a nice smooth movement into a series of stutters?
 
Fair Game said:
Can anyone tell me why YouTube doesn't like pan shots and turns a nice smooth movement into a series of stutters?

Could be a number of things. If it's only happening on Youtube, you should look at the format your uploading. Best to encode everything into a format you know that Youtube won't need to transcode. It will create lower resolution copies no matter what, add more compression and crush your colors but it should leave standard frame rates alone. If you find your pans are stuttering outside of Youtube too, you need to either slow the pans down, switch to a higher frame rate, shoot in better light, or ideally have a subject that you are keeping in frame.
 
ianwood said:
Fair Game said:
Can anyone tell me why YouTube doesn't like pan shots and turns a nice smooth movement into a series of stutters?

Could be a number of things. If it's only happening on Youtube, you should look at the format your uploading. Best to encode everything into a format you know that Youtube won't need to transcode. It will create lower resolution copies no matter what, add more compression and crush your colors but it should leave standard frame rates alone. If you find your pans are stuttering outside of Youtube too, you need to either slow the pans down, switch to a higher frame rate, shoot in better light, or ideally have a subject that you are keeping in frame.
I believe Youtube likes Quicktime, and hates H.264....just my observation.
 
CunningStuntFlyer said:
havasuphoto said:
I believe Youtube likes Quicktime, and hates H.264....just my observation.

1. MOV is just a container and typically the codec inside that wrapper is h.264
2. MP4 is just a container and typically the codec insiude that wrapper is h.264
3. Youtube recommends h.264 video (https://support.google.com/youtube/answ ... ic=2888648)
4. The video I posted above is an h.264 MP4
Thanks...that's the answer I was looking for ;)
Why is it, that youtube always "recommends" quicktime? h.264 is the codec that I think just about everyone uses...just curious.
 
[/quote]
I believe Youtube likes Quicktime, and hates H.264....just my observation.[/quote]

Actually....

According to YouTube’s handbook, YouTube can accept almost any video format for upload, but the following settings give the best results.
* Video Format: H.264, MPEG-2 or MPEG-4 preferred
* Aspect Ratio: Native aspect ratio without letterboxing (examples: 4:3, 16:9)
* Resolution: 640×360 (16:9) or 480×360 (4:3) recommended
* Audio Format: MP3 or AAC preferred
* Frames per second: 30

If your camera is 24 frames and computer monitors are 30 frames that can cause flutter. If your camera is SLR, that can create "shutter flutter". Your editing program might be doing things you are not aware of.... There are lots of factors that can come into play. Solution? Simple trial and error testing until you find your personal formula.
 
Thanks. Been on Youtube for years. But, they're about to wear out my last good nerve!!
The problem is copyright laws. IF, you use a copyrighted song, or even sound-your video will not be available to users of "mobile devices". Meaning, that any smart phone/tablet/TV, will not even show your video-even with a link.

This is new to me. I have a smart TV-and now have to create 2 copies of video's for customers. 1 with copyrighted music, and the other with no sound at all-for mobile devices.
No idea when this went into effect. But, my DP(producer)has an I-phone....and when he can't view my work, it's a waste of my time. So now, I have to do everything without sound-get it approved, then figure out how to "score" it so it can be used on that service.
Vimeo is much better for a lot of reasons. But, I have too many subscribers, etc on the tube....so I'm screwed right now.
 
Timtro said:
If your camera is 24 frames and computer monitors are 30 frames that can cause flutter.

Wuh? Computer monitors are not 30fps. They don't have even have the notion of frames per second.

My point before about submitting in H.264 is to avoid transcoding on Youtube's end. Transcoding when done right shouldn't have much of an impact on quality but Youtube sacrifices quality for efficiency especially during transcoding which is very time consuming and processor intensive so best to submit in a format you know Youtube will take without monkeying with it.

OP, this link may help you:

https://support.google.com/youtube/answer/1722171?hl=en
 
CunningStuntFlyer said:
Timtro said:
There's a point of diminishing return.... If your viewer has a slow connection, your higher bit rate serves no useful purpose. The higher you go the more quickly you lose compatibility with your viewer's display capabilities.

Check this: http://www.reelseo.com/best-bitrate-encode-youtube

I would go with Youtube"s recommendations vs. recommendations from a two year old blog.

https://support.google.com/youtube/answ ... ic=2888648
Your posts were the most useful for me. Like everything-Youtube changes, and I see they've made some changes from the past.

The one that caught my eye, was the; if shot in 60, render to 60fps and upload that way. Also, it seems you can now go to 50mbs. However, even in Protune/RAW on a GP3 Black-the max is 35mb/s.
I've found in my last two private video's that the one I rendered down from 60 to 30fps, had much more "pan stutter", than the one shot/rendered/uploaded at 60fps.

Now that I know I can use the higher bit-rate(30mb/s w/o protune on), I'll try that out.
Thanks for the help.

Their Copyright "laws" are still flawed though. Why is it, I can use virtually any music, and my audience can watch the video on a desktop/laptop-but not on a Table, Smart Phone, or Smart TV?? FYI, I first noticed this in October of last year......and, I can't find any answers on the Youtube's FAQ's. What's different on these devices, that blocks my video's with Copyrighted music?
 
Lots of info here on the stutter which I will need tome to digest.

Regarding copyright. My last video came up with 'not available on iPad or iPhone' but guess what, hit the greyed out image and it still downloads and plays!
 
CunningStuntFlyer said:
havasuphoto said:
Also, it seems you can now go to 50mbs. However, even in Protune/RAW on a GP3 Black-the max is 35mb/s.

GP3B is 45 mbps in 2k/30 or 1080/60.

When converted to an AVI for editing they are ~ 255 mbps leaving you plenty of headroom for 2 pass VBR render with a target of 50mbps.
So, if you upload at 50mb/second-can you see the difference between that, and say 25mb/sec(half?)? Assuming that the person playing the video has dual video cards, and is well capable of viewing the resolution.......

As for the I-phone copyright "laws"...it's total B.S. It didn't use to be that way-then they just changed it, and didn't bother to tell anyone. So now-you have to make 2 video's(if you use copyrighted anything). 1 for I-phones and tablets with no sound, and 1 with your copyrighted music.
I haven't a clue as to why there would be a copyright difference playing the video on a desk/laptop Vs. a Mobile Device.....
 
CunningStuntFlyer said:
havasuphoto said:
So, if you upload at 50mb/second-can you see the difference between that, and say 25mb/sec(half?)? Assuming that the person playing the video has dual video cards, and is well capable of viewing the resolution.......

The uploaded file is still going to be processed by Youtube which results in a file that is much smaller than your original.

The advantage to uploading a larger file is that Youtube has information to work with as they work their encoding "magic."
For example:

The file that I uploaded for the previously linked video is 1080, 25 mbps video and is 93MB.
Youtube's output was a 720, 2.5 mbps 10 MB file
How do you know the output file? I understand you can download youtube video's. But, I'm wondering if they only let you download a 720 version-max??
 

Members online

No members online now.

Forum statistics

Threads
143,092
Messages
1,467,578
Members
104,976
Latest member
cgarner1