View Profile
View Forum Posts
Private Message
I have noticed recently, that my videos that I converted with x264.exe tends to lag when played back on Youtube. The lagging happens when you move the mouse on the screen. It can be just a momentary move or continuous. The lagging is mostly in the video, but sometimes the sound stops for a moment as well. This is what I captured on the attachment titled: Lagging.mp4.
The videos in question are 1080 50p, this option is selected in Youtube as well. When I select 360p on Youtube, the video is not lagging any more.
You could conclude: Okay this is a laptop performance error, but I checked 1080 50p videos uploaded by others, and in those cases I did not experience this lagging. I captured it in the attachment: Not lagging.mp4
So the error has to be in my conversion process. I wonder what do I do wrong that it happens? I wonder if it is caused by the fact that the profile of my videos are: High L4.2 and not Main or Baseline?
Here is the full video that you can see in the attachments:
https://drive.google.com/file/d/1go7PI1uMLWToNOGbET89C0ZP3jWGr4p1/view?usp=sharing
I have used this mod to convert recently:
https://github.com/jpsdr/x264/releases
However I checked my older videos as well, and this lagging happens in case of those, too. I created those with the x264.exe versions available on the VLC Player website. Those are mkv files of course. In their case the lagging is not that heavy though. Occurs here and there, but less noticeable.
By the way, I noticed certain errors while playing back these videos on my laptop as well. With the mkv's there is no problem. But the mp4's that I converted with the mod, behave strangely when played back on the laptop, too. Depening on what software you use to mux them, they may lag or not lag. For example if you mux with Yamb, they lag heavily when you click to various positions on the timeline during playback, but even when you mux with MeGui. The videos seems to have no lagging or just minimal when using this software to mux:
https://www.videohelp.com/software/MP4-tool
So based on this I am not sure whether the error comes from x264.exe or the muxing process. The outcome is, however, that no matter what software I use to mux, the lagging is there in every case when I watch these videos on Youtube.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays!
Try StreamFab Downloader and download streaming video from Youtube, Netflix, Amazon! Download free trial.
+ Reply to Thread
Results 1 to 30 of 34
Thread
-
-
this is not a youtube issue, they reencode everything you upload into a web friendly format, i.e. number of b frames, number of reference frames and so on.
the fact that this is also happening with certain locally stored files just cements this.
my guess is a video card problem. -
But as I said, when I checked other 50p videos on Youtube, it did not do that. Other times I mostly uploaded stuff imported by Vegas in the past. I never had this problem.Originally Posted by frank_footer
This also makes it questionable whether Youtube treats all videos the same. From this case it seems not. I also read about how Youtube converts, but from this recent issue it seems to me how people imagine Youtube converts stuff is partly misunderstanding. Since I am uploading stuff converted by x264.exe, I notice such lagging issues time by time.
How can you download Youtube videos without conversion, to have it in the exact state as Youtube is streaming it? Maybe if I could check it's properties and would copy them when converting, I could stop this lagging.Last edited by Bencuri; 12th Jul 2024 at 17:53.
-
yt-dlpOriginally Posted by Bencuri
-
When I ask a list of formats of the video that is not lagging, I get this list:Originally Posted by jagabo
yt-dlpOriginally Posted by Bencuri
[Attachment 80669 - Click to enlarge]
But how can I investigate which is the one that I can see when I am watching that video in Youtube in my Chrome browser? It is showing a bunch of different versions. -
I'd try encoding your video into another format, say MPEG 2, and see if YT still lags. If it doesn't, then you have isolated your H264 encoding process as the problem. If YT still lags, then it would seem it is the source videos you are using and not your H264 encoding.
-
In the the Youtube window when the video is playing, right click the video and select "Stats for nerds"
The streams are identified there -
This is the mediainfo of the video not lagging:
In this one there is no more info, but in other versions of this video there is:Code:General Complete name : C:\YT\Panasonic Lumix GH5 4K 50P Footage Video Sample [O0xgzn7JO_k].webm Format : WebM Format version : Version 4 File size : 265 MiB Duration : 8 min 32 s Overall bit rate : 4 329 kb/s Frame rate : 50.000 FPS Writing application : google Writing library : google Video ID : 1 Format : VP9 Format profile : 0 Codec ID : V_VP9 Duration : 8 min 32 s Bit rate : 4 151 kb/s Width : 1 920 pixels Height : 1 080 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 Bits/(Pixel*Frame) : 0.040 Stream size : 254 MiB (96%) Language : English Default : Yes Forced : No Color range : Limited Matrix coefficients : BT.709
For reference frames it writes 3. My video has 4. I don't know if it matters?Code:General Complete name : C:\YT\2.mp4 Format : dash Codec ID : dash (iso6/avc1/mp41) File size : 335 MiB Duration : 8 min 32 s Overall bit rate : 5 476 kb/s Frame rate : 50.000 FPS Encoded date : 2017-03-26 07:10:10 UTC Tagged date : 2017-03-26 07:10:10 UTC Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.2 Format settings : CABAC / 3 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 3 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 8 min 32 s Bit rate : 5 471 kb/s Width : 1 920 pixels Height : 1 080 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.053 Stream size : 334 MiB (100%) Encoded date : 2017-03-26 07:10:10 UTC Tagged date : 2017-03-26 07:10:10 UTC Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 Codec configuration box : avcC
I will try the Mpeg version, whether that lags or not.Code:General Complete name : C:\Users\bencuri\Videos\Obligatoire\Obligatoire_Low.mp4 Format : MPEG-4 Format profile : Base Media / Version 2 Codec ID : mp42 (mp42/mp41/isom) File size : 362 MiB Duration : 8 min 24 s Overall bit rate mode : Variable Overall bit rate : 6 013 kb/s Frame rate : 50.000 FPS Encoded date : 2024-07-10 00:06:10 UTC Tagged date : 2024-07-10 00:06:10 UTC Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.2 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 8 min 24 s Bit rate : 5 623 kb/s Maximum bit rate : 12.8 Mb/s Width : 1 920 pixels Height : 1 080 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.054 Stream size : 338 MiB (94%) Writing library : x264 core 164 r3186+62M 5e8a29f t_mod_New [(8 & 10)-bit@all X86] Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=4 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=20 / rc=crf / mbtree=1 / crf=20.0000 / qcomp=0.60 / qpmin=0:0:0 / qpmax=69:69:69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 / aq-sensitivity=10.00 / aq-factor=1.00:1.00:1.00 / aq2=0 / aq3=0 Encoded date : 2024-07-10 00:06:10 UTC Tagged date : 2024-07-10 00:06:10 UTC Color range : Limited Codec configuration box : avcC
Anyway I remember that I had a lot of problem with lagging on my previous laptop that had a Dual-Core T4500 CPU. Even with SD videos, that should have been handled by that CPU I guess. I noticed after a while, that in case I use the default settings in HCEnc and use that to create videos, they are not lagging playing back on the laptop, even if the bitrate was 9200. But interestingly, when I read an article for recommended DVD settings, and I chose those in HCEnc, the videos started lagging again playing back on the laptop as well. Those changes included settings of GOP and something else that I don't remember. But basically with those recommended settings I got the problems back. I wanted to ask here back then how the change might result in lagging, I had better having done so. Maybe it would help now. -
What's your computer build?
I think,therefore i am a hamster. -
Intel i5-3210M 8GBOriginally Posted by johns0
-
Isn't the problem here, though, that during conversion I did not set the CRF to be capped? These are the parameters that I used:
x264.exe --preset faster --crf 20
But as I read online the guide says CRF is not for streaming. If I want it for streaming I should use 2 pass or capped CRF. You could expect however that Youtube adresses the problem, however considering my case it seems not, or not to the extent expected. -
Post the link to this Guide that you're referring to.
In general it doesn't matter that much, since Yotube re-encodes everything it receives anyway.
If you look here, it's pretty much wide open
https://support.google.com/youtube/answer/1722171?hl=en#zippy=%2Cvideo-codec-h -
I would say your systems aren't up to date and can't handle video's that are encoded wrong.
I think,therefore i am a hamster. -
That is the correct conclusion: encoded wrong. So the question is, how to encode it well so that my machine can handle it? Because as it seems from Youtube it is possible.Originally Posted by johns0
-
This is where the author mentions capping:Originally Posted by davexnet
https://slhck.info/video/2017/02/24/crf-guide.html
As I see my video pretty much meets the Youtube recommendation. Except for GOP maybe, but that one I don't see mentioned anywhere in Mediainfo, and bframes, that is 3 instead of 2. How can you control GOP in x264? I don't see such an option.
What if I would try some Scene Rules recommendation anyway? Even when I had my Dual Core laptop that was much slower, I had almost no problems playing back Torrent videos that were HD yet extra small in size. Maybe those methods would help when uploading to Youtube as well. -
That's in incorrect conclusion. There's nothing "wrong" with any of the encodings.Originally Posted by Bencuri
That is the correct conclusion: encoded wrong.Originally Posted by johns0
Capping the bitrate of videos you upload to youtube won't help. Youtube reencodes everything you upload and will cap the bitrate for those encodings before playing them.
In your first post the "not lagging" video is 30p youtube video captured at 30p. The "lagging" video is a 50p or 60p video captured at 30p. It looks to me like your computers simply can't play 1080p50 or 1080p60 smoothly. -
Excuse me, but I have to correct this.Originally Posted by jagabo
That's in incorrect conclusion. There's nothing "wrong" with any of the encodings.Originally Posted by Bencuri
That is the correct conclusion: encoded wrong.Originally Posted by johns0
Capping the bitrate of videos you upload to youtube won't help. Youtube reencodes everything you upload and will cap the bitrate for those encodings before playing them.
In your first post the "not lagging" video is 30p youtube video captured at 30p. The "lagging" video is a 50p or 60p video captured at 30p. It looks to me like your computers simply can't play 1080p50 or 1080p60 smoothly.
The lagging video was 50i deinterlaced to 50p, uploaded to Youtube, played back on 60Hz screen and recorded with 25p. The not lagging video was I don't know what format originally, but Youtube plays it back at 1080 50p, I watched that on the same screen, and recorded the same way. This is that video:
https://www.youtube.com/watch?v=O0xgzn7JO_k
But it is only interesting until the playback on Youtube. With my recording process I couldn't show every lagging properly, when the playback of the video slows down momentarity when you move the mouse, but you can hear when the music is skipping as well in my video, that is another symptom. So you can notice the essence, the rest: how it is displayed and recorded is not interesting.
It makes no sense debating on whether the conversion was done correctly or not, or whether my laptop is capable of playing back 50p videos correctly. The essence is that it can play them back correctly, as it can be seen from certain Youtube videos, but not the ones that I create. So the question is, how to create ones that can play them back.
It is the same problem like in case of my old computer. Most videos were lagging, but when I noticed videos created with HcEnc on default settings are not lagging, I had no problem any more on my old computer either. Or my TV was the same: 1080 50i capable TV, released in 2011: 50i videos rendered in Vegas with the Main Concept AVC option were lagging and skipping, videos rendered with the Sony AVC option were not lagging. No matter the TV supported 50i and the same bitrate was used. So as examples show, it can be done, the question: how? -
Also provide the youtube link to a video that is lagging on your laptop
-
If you think the problem is bitrate peaks you can use x264's vbv settings to limit bitrate peaks -- with either crf or bitrate based encoding.Originally Posted by Bencuri
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#vbv-maxrate
GOP size is probably not an issue. But streaming usually uses about 1 second GOPs, ie 50 frames for 50 fps video. Youtube appears to use about 250 frame GOPs.
Decreasing ref from 5 to 4 may help.
Here's a list of all the versions available at youtube obtained with "yt-dlp -F https://www.youtube.com/watch?v=O0xgzn7JO_k"
You can download one of the the 1920x1080 avc videos, plus m4a audio with:Code:ID EXT RESOLUTION FPS CH │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── sb2 mhtml 48x27 0 │ mhtml │ images storyboard sb1 mhtml 80x45 0 │ mhtml │ images storyboard sb0 mhtml 160x90 0 │ mhtml │ images storyboard 233 mp4 audio only │ m3u8 │ audio only unknown Default 234 mp4 audio only │ m3u8 │ audio only unknown Default 249-drc webm audio only 2 │ 3.35MiB 55k https │ audio only opus 55k 48k low, DRC, THROTTLED, webm_dash 250-drc webm audio only 2 │ 4.44MiB 73k https │ audio only opus 73k 48k low, DRC, THROTTLED, webm_dash 139-drc m4a audio only 2 │ 2.98MiB 49k https │ audio only mp4a.40.5 49k 22k low, DRC, m4a_dash 249 webm audio only 2 │ 3.43MiB 56k https │ audio only opus 56k 48k low, THROTTLED, webm_dash 250 webm audio only 2 │ 4.56MiB 75k https │ audio only opus 75k 48k low, THROTTLED, webm_dash 139 m4a audio only 2 │ 2.91MiB 48k https │ audio only mp4a.40.5 48k 22k low, m4a_dash 251-drc webm audio only 2 │ 8.67MiB 142k https │ audio only opus 142k 48k medium, DRC, THROTTLED, webm_dash 140-drc m4a audio only 2 │ 7.91MiB 129k https │ audio only mp4a.40.2 129k 44k medium, DRC, m4a_dash 251 webm audio only 2 │ 8.91MiB 146k https │ audio only opus 146k 48k medium, THROTTLED, webm_dash 140 m4a audio only 2 │ 7.77MiB 127k https │ audio only mp4a.40.2 127k 44k medium, m4a_dash 278 webm 256x144 25 │ 5.86MiB 96k https │ vp9 96k video only 144p, THROTTLED, webm_dash 269 mp4 256x144 25 │ ~ 10.36MiB 169k m3u8 │ avc1.4D400C 169k video only 160 mp4 256x144 25 │ 3.98MiB 65k https │ avc1.4D400C 65k video only 144p, mp4_dash 603 mp4 256x144 25 │ ~ 10.33MiB 169k m3u8 │ vp09.00.11.08 169k video only 242 webm 426x240 25 │ 12.08MiB 198k https │ vp9 198k video only 240p, THROTTLED, webm_dash 229 mp4 426x240 25 │ ~ 20.21MiB 330k m3u8 │ avc1.4D4015 330k video only 133 mp4 426x240 25 │ 15.01MiB 246k https │ avc1.4D4015 246k video only 240p, mp4_dash 604 mp4 426x240 25 │ ~ 19.81MiB 324k m3u8 │ vp09.00.20.08 324k video only 18 mp4 640x360 25 2 │ ≈ 34.11MiB 558k https │ avc1.42001E mp4a.40.2 44k 360p, THROTTLED 243 webm 640x360 25 │ 23.23MiB 380k https │ vp9 380k video only 360p, THROTTLED, webm_dash 230 mp4 640x360 25 │ ~ 49.65MiB 812k m3u8 │ avc1.4D401E 812k video only 134 mp4 640x360 25 │ 26.37MiB 432k https │ avc1.4D401E 432k video only 360p, mp4_dash 605 mp4 640x360 25 │ ~ 39.12MiB 640k m3u8 │ vp09.00.21.08 640k video only 244 webm 854x480 25 │ 42.99MiB 703k https │ vp9 703k video only 480p, THROTTLED, webm_dash 231 mp4 854x480 25 │ ~ 87.32MiB 1428k m3u8 │ avc1.4D401E 1428k video only 135 mp4 854x480 25 │ 57.58MiB 942k https │ avc1.4D401E 942k video only 480p, mp4_dash 606 mp4 854x480 25 │ ~ 66.84MiB 1093k m3u8 │ vp09.00.30.08 1093k video only 136 mp4 1280x720 25 │ 116.61MiB 1908k https │ avc1.4d401f 1908k video only 720p, THROTTLED, mp4_dash 247 webm 1280x720 25 │ 89.38MiB 1463k https │ vp9 1463k video only 720p, THROTTLED, webm_dash 302 webm 1280x720 50 │ 151.89MiB 2485k https │ vp9 2485k video only 720p50, THROTTLED, webm_dash 311 mp4 1280x720 50 │ ~231.73MiB 3789k m3u8 │ avc1.4D4020 3789k video only 298 mp4 1280x720 50 │ 190.85MiB 3123k https │ avc1.4D4020 3123k video only 720p50, mp4_dash 612 mp4 1280x720 50 │ ~215.71MiB 3527k m3u8 │ vp09.00.40.08 3527k video only 303 webm 1920x1080 50 │ 264.57MiB 4329k https │ vp9 4329k video only 1080p50, THROTTLED, webm_dash 312 mp4 1920x1080 50 │ ~387.00MiB 6328k m3u8 │ avc1.64002A 6328k video only 299 mp4 1920x1080 50 │ 334.68MiB 5476k https │ avc1.64002A 5476k video only 1080p50, mp4_dash 617 mp4 1920x1080 50 │ ~353.95MiB 5788k m3u8 │ vp09.00.41.08 5788k video only 308 webm 2560x1440 50 │ 779.77MiB 12759k https │ vp9 12759k video only 1440p50, THROTTLED, webm_dash 623 mp4 2560x1440 50 │ ~ 1.02GiB 17012k m3u8 │ vp09.00.50.08 17012k video only 315 webm 3840x2160 50 │ 1.57GiB 26286k https │ vp9 26286k video only 2160p50, THROTTLED, webm_dash 628 mp4 3840x2160 50 │ ~ 1.94GiB 32427k m3u8 │ vp09.00.51.08 32427k video only
Code:yt-dlp -f 299+139 https://www.youtube.com/watch?v=O0xgzn7JO_k
Last edited by jagabo; 13th Jul 2024 at 11:53.
-
For me Youtube is showing it is streaming the VP9 webm version of the video. What if I would reconvert to that format. I downloaded qencoder, it tried it, it seems to do nothing, or something is taking very long, the fan is speeding up but the meter is always at 0%. I tried the ffmpeg.exe in its library though, and that seems to start and work. What would be the optimal script for my video? I have no clue which CRF setting would fit Youtube, and whether to leave audio or not. I have found this command line, but my machine has only 4 threads and I have no clue what the title column and g parameters are for:Originally Posted by jagabo
If you think the problem is bitrate peaks you can use x264's vbv settings to limit bitrate peaks -- with either crf or bitrate based encoding.Originally Posted by Bencuri
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#vbv-maxrate
GOP size is probably not an issue. But streaming usually uses about 1 second GOPs, ie 50 frames for 50 fps video. Youtube appears to use about 250 frame GOPs.
Decreasing ref from 5 to 4 may help.
Here's a list of all the versions available at youtube obtained with "yt-dlp -F https://www.youtube.com/watch?v=O0xgzn7JO_k"
You can download one of the the 1920x1080 avc videos, plus m4a audio with:Code:ID EXT RESOLUTION FPS CH │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── sb2 mhtml 48x27 0 │ mhtml │ images storyboard sb1 mhtml 80x45 0 │ mhtml │ images storyboard sb0 mhtml 160x90 0 │ mhtml │ images storyboard 233 mp4 audio only │ m3u8 │ audio only unknown Default 234 mp4 audio only │ m3u8 │ audio only unknown Default 249-drc webm audio only 2 │ 3.35MiB 55k https │ audio only opus 55k 48k low, DRC, THROTTLED, webm_dash 250-drc webm audio only 2 │ 4.44MiB 73k https │ audio only opus 73k 48k low, DRC, THROTTLED, webm_dash 139-drc m4a audio only 2 │ 2.98MiB 49k https │ audio only mp4a.40.5 49k 22k low, DRC, m4a_dash 249 webm audio only 2 │ 3.43MiB 56k https │ audio only opus 56k 48k low, THROTTLED, webm_dash 250 webm audio only 2 │ 4.56MiB 75k https │ audio only opus 75k 48k low, THROTTLED, webm_dash 139 m4a audio only 2 │ 2.91MiB 48k https │ audio only mp4a.40.5 48k 22k low, m4a_dash 251-drc webm audio only 2 │ 8.67MiB 142k https │ audio only opus 142k 48k medium, DRC, THROTTLED, webm_dash 140-drc m4a audio only 2 │ 7.91MiB 129k https │ audio only mp4a.40.2 129k 44k medium, DRC, m4a_dash 251 webm audio only 2 │ 8.91MiB 146k https │ audio only opus 146k 48k medium, THROTTLED, webm_dash 140 m4a audio only 2 │ 7.77MiB 127k https │ audio only mp4a.40.2 127k 44k medium, m4a_dash 278 webm 256x144 25 │ 5.86MiB 96k https │ vp9 96k video only 144p, THROTTLED, webm_dash 269 mp4 256x144 25 │ ~ 10.36MiB 169k m3u8 │ avc1.4D400C 169k video only 160 mp4 256x144 25 │ 3.98MiB 65k https │ avc1.4D400C 65k video only 144p, mp4_dash 603 mp4 256x144 25 │ ~ 10.33MiB 169k m3u8 │ vp09.00.11.08 169k video only 242 webm 426x240 25 │ 12.08MiB 198k https │ vp9 198k video only 240p, THROTTLED, webm_dash 229 mp4 426x240 25 │ ~ 20.21MiB 330k m3u8 │ avc1.4D4015 330k video only 133 mp4 426x240 25 │ 15.01MiB 246k https │ avc1.4D4015 246k video only 240p, mp4_dash 604 mp4 426x240 25 │ ~ 19.81MiB 324k m3u8 │ vp09.00.20.08 324k video only 18 mp4 640x360 25 2 │ ≈ 34.11MiB 558k https │ avc1.42001E mp4a.40.2 44k 360p, THROTTLED 243 webm 640x360 25 │ 23.23MiB 380k https │ vp9 380k video only 360p, THROTTLED, webm_dash 230 mp4 640x360 25 │ ~ 49.65MiB 812k m3u8 │ avc1.4D401E 812k video only 134 mp4 640x360 25 │ 26.37MiB 432k https │ avc1.4D401E 432k video only 360p, mp4_dash 605 mp4 640x360 25 │ ~ 39.12MiB 640k m3u8 │ vp09.00.21.08 640k video only 244 webm 854x480 25 │ 42.99MiB 703k https │ vp9 703k video only 480p, THROTTLED, webm_dash 231 mp4 854x480 25 │ ~ 87.32MiB 1428k m3u8 │ avc1.4D401E 1428k video only 135 mp4 854x480 25 │ 57.58MiB 942k https │ avc1.4D401E 942k video only 480p, mp4_dash 606 mp4 854x480 25 │ ~ 66.84MiB 1093k m3u8 │ vp09.00.30.08 1093k video only 136 mp4 1280x720 25 │ 116.61MiB 1908k https │ avc1.4d401f 1908k video only 720p, THROTTLED, mp4_dash 247 webm 1280x720 25 │ 89.38MiB 1463k https │ vp9 1463k video only 720p, THROTTLED, webm_dash 302 webm 1280x720 50 │ 151.89MiB 2485k https │ vp9 2485k video only 720p50, THROTTLED, webm_dash 311 mp4 1280x720 50 │ ~231.73MiB 3789k m3u8 │ avc1.4D4020 3789k video only 298 mp4 1280x720 50 │ 190.85MiB 3123k https │ avc1.4D4020 3123k video only 720p50, mp4_dash 612 mp4 1280x720 50 │ ~215.71MiB 3527k m3u8 │ vp09.00.40.08 3527k video only 303 webm 1920x1080 50 │ 264.57MiB 4329k https │ vp9 4329k video only 1080p50, THROTTLED, webm_dash 312 mp4 1920x1080 50 │ ~387.00MiB 6328k m3u8 │ avc1.64002A 6328k video only 299 mp4 1920x1080 50 │ 334.68MiB 5476k https │ avc1.64002A 5476k video only 1080p50, mp4_dash 617 mp4 1920x1080 50 │ ~353.95MiB 5788k m3u8 │ vp09.00.41.08 5788k video only 308 webm 2560x1440 50 │ 779.77MiB 12759k https │ vp9 12759k video only 1440p50, THROTTLED, webm_dash 623 mp4 2560x1440 50 │ ~ 1.02GiB 17012k m3u8 │ vp09.00.50.08 17012k video only 315 webm 3840x2160 50 │ 1.57GiB 26286k https │ vp9 26286k video only 2160p50, THROTTLED, webm_dash 628 mp4 3840x2160 50 │ ~ 1.94GiB 32427k m3u8 │ vp09.00.51.08 32427k video only
Code:yt-dlp -f 299+139 https://www.youtube.com/watch?v=O0xgzn7JO_k
ffmpeg -i input.mp4 -b:v 0 -tile-columns 2 -g 240 -threads 8 -quality good -crf 31 -c:v libvpx-vp9 -pass 1 -an -f null
ffmpeg -i input.mp4 -b:v 0 -tile-columns 3 -g 240 -threads 8 -quality good -crf 31 -c:v libvpx-vp9 -c:a libopus -pass 2 -speed 4 -y output.webm -
I'm not real familiar with VP9 but from what I just read:
-g is the GOP size. This is standard for the ffmpeg command line.
VP9 multithreads by splitting the frame into tiles, ie strips. Each strip is encoded by a thread; the tiles are reassembled upon decompression. The number of columns is 2^N where N is the -tile-columns value you specify. So 2 means 2^2 or 4 tiles across the width of the frame. 3 means 2^3 or 8 tiles. There's also a tile-rows value for splitting the height too. With your 2 core 4 thread CPU you'll probably get the fastest encoding with -tile-columns 1 and -tile-rows 1 and -threads 4. ffmpeg is usually pretty good about picking optimal values for things like this so you may not need to specify any of that. It's easy enough to test.
you can get a list of vp9 settings with:
or with output re-directed to a file:Code:ffmpeg -? encoder=libvpx-vp9
Code:ffmpeg -? encoder=libvpx-vp9 >help_libvpx-vp9.txt
Try encoding with something like:Code:Encoder libvpx-vp9 [libvpx VP9]: General capabilities: dr1 delay threads Threading capabilities: other Supported pixel formats: yuv420p yuva420p yuv422p yuv440p yuv444p yuv420p10le yuv422p10le yuv440p10le yuv444p10le yuv420p12le yuv422p12le yuv440p12le yuv444p12le gbrp gbrp10le gbrp12le libvpx-vp9 encoder AVOptions: -lag-in-frames <int> E..V....... Number of frames to look ahead for alternate reference frame selection (from -1 to INT_MAX) (default -1) -arnr-maxframes <int> E..V....... altref noise reduction max frame count (from -1 to INT_MAX) (default -1) -arnr-strength <int> E..V....... altref noise reduction filter strength (from -1 to INT_MAX) (default -1) -arnr-type <int> E..V....... altref noise reduction filter type (from -1 to INT_MAX) (default -1) backward 1 E..V....... forward 2 E..V....... centered 3 E..V....... -tune <int> E..V....... Tune the encoding to a specific scenario (from -1 to INT_MAX) (default -1) psnr 0 E..V....... ssim 1 E..V....... -deadline <int> E..V....... Time to spend encoding, in microseconds. (from INT_MIN to INT_MAX) (default good) best 0 E..V....... good 1000000 E..V....... realtime 1 E..V....... -error-resilient <flags> E..V....... Error resilience configuration (default 0) default E..V....... Improve resiliency against losses of whole frames partitions E..V....... The frame partitions are independently decodable by the bool decoder, meaning that partitions can be decoded even though earlier partitions have been lost. Note that intra prediction is still done over the partition boundary. -max-intra-rate <int> E..V....... Maximum I-frame bitrate (pct) 0=unlimited (from -1 to INT_MAX) (default -1) -crf <int> E..V....... Select the quality for constant quality mode (from -1 to 63) (default -1) -static-thresh <int> E..V....... A change threshold on blocks below which they will be skipped by the encoder (from 0 to INT_MAX) (default 0) -drop-threshold <int> E..V....... Frame drop threshold (from INT_MIN to INT_MAX) (default 0) -noise-sensitivity <int> E..V....... Noise sensitivity (from 0 to 4) (default 0) -undershoot-pct <int> E..V....... Datarate undershoot (min) target (%) (from -1 to 100) (default -1) -overshoot-pct <int> E..V....... Datarate overshoot (max) target (%) (from -1 to 1000) (default -1) -ts-parameters <dictionary> E..V....... Temporal scaling configuration using a :-separated list of key=value parameters -auto-alt-ref <int> E..V....... Enable use of alternate reference frames (2-pass only) (from -1 to 6) (default -1) -cpu-used <int> E..V....... Quality/Speed ratio modifier (from -8 to 8) (default 1) -lossless <int> E..V....... Lossless mode (from -1 to 1) (default -1) -tile-columns <int> E..V....... Number of tile columns to use, log2 (from -1 to 6) (default -1) -tile-rows <int> E..V....... Number of tile rows to use, log2 (from -1 to 2) (default -1) -frame-parallel <boolean> E..V....... Enable frame parallel decodability features (default auto) -aq-mode <int> E..V....... adaptive quantization mode (from -1 to 4) (default -1) none 0 E..V....... Aq not used variance 1 E..V....... Variance based Aq complexity 2 E..V....... Complexity based Aq cyclic 3 E..V....... Cyclic Refresh Aq equator360 4 E..V....... 360 video Aq -level <float> E..V....... Specify level (from -1 to 6.2) (default -1) -row-mt <boolean> E..V....... Row based multi-threading (default auto) -tune-content <int> E..V....... Tune content type (from -1 to 2) (default -1) default 0 E..V....... Regular video content screen 1 E..V....... Screen capture content film 2 E..V....... Film content; improves grain retention -corpus-complexity <int> E..V....... corpus vbr complexity midpoint (from -1 to 10000) (default -1) -enable-tpl <boolean> E..V....... Enable temporal dependency model (default auto) -min-gf-interval <int> E..V....... Minimum golden/alternate reference frame interval (from -1 to INT_MAX) (default -1) -speed <int> E..V....... (from -16 to 16) (default 1) -quality <int> E..V....... (from INT_MIN to INT_MAX) (default good) best 0 E..V....... good 1000000 E..V....... realtime 1 E..V....... -vp8flags <flags> E..V....... (default 0) error_resilient E..V....... enable error resilience altref E..V....... enable use of alternate reference frames (VP8/2-pass only) -arnr_max_frames <int> E..V....... altref noise reduction max frame count (from 0 to 15) (default 0) -arnr_strength <int> E..V....... altref noise reduction filter strength (from 0 to 6) (default 3) -arnr_type <int> E..V....... altref noise reduction filter type (from 1 to 3) (default 3) -rc_lookahead <int> E..V....... Number of frames to look ahead for alternate reference frame selection (from 0 to 25) (default 25) -sharpness <int> E..V....... Increase sharpness at the expense of lower PSNR (from -1 to 7) (default -1)
Once again, beyond frame size and frame rate, it shouldn't matter what you upload. Youtube will reencode with the settings it wants. It's generally recommended you upload with the highest bitrate you can tolerate -- so youtube at least starts with a high quality video.Code:ffmpeg -i source.mp4 -g 240 -quality good -crf 18 -c:v libvpx-vp9 -c:a libopus -speed 4 -y output.webm
Last edited by jagabo; 13th Jul 2024 at 17:11.
-
Well, the only difference left to consider in that case is the video format. The video that is not lagging for me on Youtube is streamed in VP9, the lagging video is AVC. The only problem is if I upload the 1080 50p VP9 video, Youtube still streams that as AVC. Have no clue how the other uploader could force VP9.
-
The requirement used to be in order to get VP9 treatment on YT (ie. to make VP9 versions available for viewers), either you have to be a "VIP" with many viewers , or upload something 2560x1440 or greater (upscale if you have to) . It does not matter what you do for the upload in terms of the compression type or settings, that does not affect what YT uses for re-encoding choices
-
By uploading a 3840x2160 video.Originally Posted by Bencuri
-
This is still the case. 1440 vertical size is the trigger; for example, 1920x1440 will trigger VP9 encoding by YT.Originally Posted by PDR
Last edited by Alwyn; 13th Jul 2024 at 22:51. Reason: Example note added.
-
Another thing to keep in mind: playing the video on youtube means your browser is doing the work, not VLC. One may be using hardware encoding the other not. If both are using software decoding, they are using different software. So you don't necessarily expect the same result from both.
Your best solution is to stop buying 10 year old laptops. Get something more modern. -
You may be right particularly about that playback thing, but it is useless to debate about accelerations when the situation is that seemingly there are scenarios when there is no lagging, so it would be more useful to investigate how that is possible than debating about what causes the lagging in the other video on the hardware side.
What to buy is an oversimplification of the problem in my philosophy. Millions is the world have worse device than mine, if they have any, and when my target audience is among them, it would be unwary to just let their playback problems be overlooked when actually there seem to be solutions. But it is just one part of the story, because personally I noticed there are instances when a modern device does not necessarily perform better, and annoying situations can occur. A good example is our new LG Smart TV that was quite expensive, but handles simple mpeg2 videos with such a struggle sometimes that our 12 year old Philips TV expells it in most situations. But I could also mention that case again with the MainConcept AVC rendering option in Vegas: the 1080 50i videos it created was lagging sometimes on that 2012 manufactured Philips, when that 1080 50i technology was 4-5 years old at least by then, moreover the TV supported that format anyway. And as soon as you switched to other mp4 rendering methods, that problem was gone. Or the classic example from that era: anything I recorded with my Canon camcorders were big, so much that my laptop back then was unable to handle it, the source and rendered files were lagging, renders were big, while HD videos downloaded from Torrent were ridiculously small, sharp, and were never lagging. You could obviously see back then that my laptop was not suitable handling the HD videos, yet you were confused about how they could render videos for torrents so effectively that they played fine even on my laptop. So all in all, what I learnt during the years about video technology is that many times you don't get what you expect for your money and playability of even outdated technologies are often a problem on most of the devices owned by users.
In this particular case I know: if I purchased the new flagship Asus Rog, verly likely I would have no such problems. But would that help on the multitude of viewers who would be still annoyed, especially when it seems there would be solution for them, too? And I use the word: very likely, because personally I experienced it very rarely that the expensive devices I purchased performed 100% as you expected. There were cases like that: in the 80's when we used turntables, and you purchased a good Thorens turntable, it was worth the money. But I could buy the expensive Sony SA CD player in the 2000's, it could not play CDs any more when they had some small scratches, ones that basic quality players could easily handle, and failed to play the newly purchased Sony release Shakira CD, because their own copy protection technology confused their own player. So yes, very likely a better machine would do better job, but until I can solve things other way I don't want the new disappointments. Better stick to what works anyway. -
it seems it's a decoding issue, the video that is not lagging is vp9 and the one that is lagging is avc.
my guess is that the vp9 video is always being decoded by the gpu and the avc video is sometimes being decoded by the cpu because the video may not conform to an avc profile that is supported for hardware acceleration by your video card.
i have stopped using avc and hevc, i only use mpeg-2, vp9 or av1, -
ffmpeg has a -threads parameter, but I am reading at certain places that it tends to work oddly. For this CPU, what would be the optimal threads value for ffmpeg?Originally Posted by jagabo
Amd Ryzen 5 3600xt
6 cores 12 threads
I see you included -speed in the command what is that for? -
we'll see I do a test soon and then it will turn outOriginally Posted by frank_footer
what do you use to render into vp9?
Quote
Similar Threads
-
Any version of x264.exe with mp4 output?
By Bencuri in forum Video ConversionReplies: 3Last Post: 31st May 2024, 08:47 -
No longer able to download videos with youtube-dl.exe
By BRH in forum Newbie / General discussionsReplies: 25Last Post: 3rd Mar 2023, 20:22 -
How to get rid of blocks when encoding with x264.exe
By arthurm in forum Video ConversionReplies: 5Last Post: 9th Aug 2021, 18:56 -
Please help with x264.exe command line for Full HD video
By Bencuri in forum Video ConversionReplies: 1Last Post: 24th Nov 2020, 18:52 -
youtube-dl.exe and Final Video Downloader problems that i have
By sommers in forum Newbie / General discussionsReplies: 2Last Post: 14th May 2020, 09:52