View Profile
View Forum Posts
Private Message
I have several problems, SAR and DAR are weird, I saw some people using wide-480p and had their sar 1:1 and DAR as 427:240 ...
Took 1:30 to 2 hours to start processing, that's way too long. First test came out was 860 MB (902.062.080 bytes) with the source file at 1,07 GB (1.156.739.072 bytes) - sizes on disk.
Unfortunately the CMD window for the first recode log would not copy and i accidentially closed it, recode takes like 30 mins so I can't just redo it on fly, gonna go for another different test.
I'm making this for another person, and he says that he can't upload 1.1GB source because it's taking so long and his channel is dependant on speed as these videos rool almost every day, most of them are 3 hours, sometimes 20 minutes more, many times just 5 mins more. I'm not the one that's going to use this, but I create short video clips with Sony Vegas and just haven't went that deep into it all, I kept using WMV since for me it's never been a problem with such small filesizes usually not over 150MB or even 100MB.
Maybe the treshold is not based on just size, but the encoding/container structure. But what is known is that 1.1GB gets into the queue, but about 800 MB doesn't, I don't really know even if that's the case since the person I barely know and doesn't appear to be a PC geek so I have to pull stuff out from him and he told me he has a 5 core CPU which I hope he's correct (i just set that to 4 threads no idea what threads really matter since sometimes i see them set specifically to zero) (but he's not stupid don't get me wrong, it's important stuff)
Im not sure if those YT uploads that get to 700MB (which means his source file for that is above 700MB ) even are fast-non-queue ones, as he didn't told me a lot about the situation.
Current config:
Code:ffmpeg -loglevel verbose -i %input%.mp4 -vcodec libx264 -profile:v "high" -preset slow -level:v 3.0 -pix_fmt yuv420p -s 854x480 -aspect 854:480 -r 29.97 -g 29.97 -keyint_min 59.94 -b:v 512k -minrate 512k -maxrate 512k -bufsize 1024k -acodec copy -threads 4 %input%_Recoded.mp4
Now after I researched a bit more I found out about the MOOV ATOM (fast start) which lead me to fragmentation having to do something with "decoding without having the whole file"
Then I saw the Closed GOP thingy, and read about something "decoding one gop without the need of another"
All these things ring a bell, it would appear this would be how youtube can process the video while it's uploading ... but in past it always happened randomly for me, I didn't upload a whole lot anyways.
https://support.google.com/youtube/answer/1722171?hl=en
(some stuff may ofcourse not be correct as this is mediainfo - 0.7.71)
THE FIRST TEST RECODE:
Code:Complete name : D:\VEGAS_PROJECT_SOURCE\TOOLS\ffmpeg\latest\bin\aj1_Recoded.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom File size : 860 MiB Duration : 3h 5mn Overall bit rate mode : Variable Overall bit rate : 649 Kbps Writing application : Lavf56.16.102 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L3.0 Format settings, CABAC : Yes Format settings, ReFrames : 5 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 3h 5mn Bit rate : 512 Kbps Width : 854 pixels Height : 480 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 29.970 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.042 Stream size : 679 MiB (79%) Writing library : x264 core 144 r2525 40bb568 Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=30 / keyint_min=16 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=cbr / mbtree=1 / bitrate=512 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=512 / vbv_bufsize=1024 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : 40 Duration : 3h 5mn Bit rate mode : Variable Bit rate : 128 Kbps Maximum bit rate : 512 Kbps Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 KHz Compression mode : Lossy Stream size : 170 MiB (20%)
THE SOURCE FILE:
Mediainfo added GOP status to MPEG but it doesn't seem like it show for MP4, maybe it's not for x264 and they meant plain MPEG.Code:Complete name : D:\VEGAS_PROJECT_SOURCE\TOOLS\ffmpeg\latest\bin\aj1.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom File size : 1.08 GiB Duration : 3h 5mn Overall bit rate mode : Variable Overall bit rate : 832 Kbps Encoded date : UTC 1970-01-01 00:00:00 Tagged date : UTC 1970-01-01 00:00:00 Writing application : Lavf52.64.2 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L3.0 Format settings, CABAC : Yes Format settings, ReFrames : 3 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 3h 5mn Bit rate : 699 Kbps Width : 700 pixels Height : 394 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 29.970 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.085 Stream size : 927 MiB (84%) Encoded date : UTC 1970-01-01 00:00:00 Tagged date : UTC 1970-01-01 00:00:00 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : 40 Duration : 3h 5mn Bit rate mode : Variable Bit rate : 128 Kbps Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 KHz Compression mode : Lossy Stream size : 170 MiB (15%) Encoded date : UTC 1970-01-01 00:00:00 Tagged date : UTC 1970-01-01 00:00:00
YT also says it likes GOP half the framerate, but the source video probably doesn't have that and I don't see the reason for this as it would just increase filesize unnecessairly.
I don't think we can hang on all of those recommendations since some of them are kind of shaky, they still recode all audio to 44.1 Khz for some stupid shit reason.
Anyways I would like to try all of the above mentioned stuff, and I'll then pull out one by one, until I only have faststart left, and then with all these combinations, I have to make various sizes, so it's going to take a lot of testing unless somebody knows this whole thing already.
The treshold might be just at 900 K bytes so ... but I do surely want to try those options out, one other thing is that I heard somewhere if fragmentation is used then faststart can't be used, https://www.ffmpeg.org/ffmpeg-formats.html
Support our site by donate $5 directly to us Thanks!!!
Try StreamFab Downloader and download streaming video from Netflix, Amazon!
Try StreamFab Downloader and download streaming video from Netflix, Amazon!
+ Reply to Thread
Results 1 to 30 of 37
-
Last edited by Wader8; 4th Jan 2015 at 08:27.
-
Ok, I made another small testfile to get the log
Code:///////////////////////////////////////////////////////////////////// --------------- Preparing to start recoding process ---------------- ///////////////////////////////////////////////////////////////////// ---- Copy/Cut the required file into this folder, ------------------- ----- or place ffmpeg folder closer to where you put downloaded files ------ Now type it's filename exactly and hit enter ----------------- Filename without extension: aj1 ffmpeg version N-68826-g504267f Copyright (c) 2000-2014 the FFmpeg developers built on Jan 2 2015 22:12:34 with gcc 4.9.2 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable -frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib libavutil 54. 16.100 / 54. 16.100 libavcodec 56. 19.100 / 56. 19.100 libavformat 56. 16.102 / 56. 16.102 libavdevice 56. 3.100 / 56. 3.100 libavfilter 5. 6.100 / 5. 6.100 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 3.100 / 53. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'aj1.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 creation_time : 1970-01-01 00:00:00 encoder : Lavf52.64.2 Duration: 03:05:23.86, start: 0.000000, bitrate: 831 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 700x394 (704x400), 699 kb/s, 29.97 fps, 29.97 tbr, 29970 tbn, 59.94 tbc (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : VideoHandler Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : SoundHandler [graph 0 input from stream 0:0 @ 0000000000333680] w:700 h:394 pixfmt:yuv420p tb:1/29970 fr:2997/100 sar:0/1 sws_param:flags=2 [scaler for output stream 0:0 @ 0000000000333800] w:854 h:480 flags:'0x4' interl:0 [scaler for output stream 0:0 @ 0000000000333800] w:700 h:394 fmt:yuv420p sar:0/1 -> w:854 h:480 fmt:yuv420p sar:0/1 flags:0x4 [libx264 @ 00000000003a8960] using SAR=1/1 [libx264 @ 00000000003a8960] MB rate (48551) > level limit (40500) [libx264 @ 00000000003a8960] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [libx264 @ 00000000003a8960] profile High, level 3.0 [libx264 @ 00000000003a8960] 264 - core 144 r2525 40bb568 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/ x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=4 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=30 keyint_min=16 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=cbr mbtree=1 bitrate=512 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=512 vbv_bufsize=1024 nal_hrd=none filler=0 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to 'aj1_Recoded1.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf56.16.102 Stream #0:0(und): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 854x480 [SAR 32880:32879 DAR 137:77], q=-1--1, 512 kb/s, 29.97 fps, 11988 tbn, 29.97 tbc (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : VideoHandler encoder : Lavc56.19.100 libx264 Stream #0:1(und): Audio: aac ([64][0][0][0] / 0x0040), 48000 Hz, stereo, 127 kb/s (default) Metadata: creation_time : 1970-01-01 00:00:00 handler_name : SoundHandler Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Stream #0:1 -> #0:1 (copy) Press [q] to stop, [?] for help No more output streams to write to, finishing.e=00:01:58.37 bitrate= 630.5kbits/s frame= 3597 fps=135 q=-1.0 Lsize= 9539kB time=00:02:00.00 bitrate= 651.2kbits/s video:7534kB audio:1875kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.381339% Input file #0 (aj1.mp4): Input stream #0:0 (video): 3606 packets read (11598105 bytes); 3599 frames decoded; Input stream #0:1 (audio): 5636 packets read (1924590 bytes); Total: 9242 packets (13522695 bytes) demuxed Output file #0 (aj1_Recoded1.mp4): Output stream #0:0 (video): 3597 frames encoded; 3597 packets muxed (7714803 bytes); Output stream #0:1 (audio): 5625 packets muxed (1919835 bytes); Total: 9222 packets (9634638 bytes) muxed [libx264 @ 00000000003a8960] frame I:121 Avg QP:24.60 size: 37149 [libx264 @ 00000000003a8960] frame P:1077 Avg QP:26.32 size: 2298 [libx264 @ 00000000003a8960] frame B:2399 Avg QP:26.58 size: 310 [libx264 @ 00000000003a8960] consecutive B-frames: 7.5% 5.0% 17.3% 70.2% [libx264 @ 00000000003a8960] mb I I16..4: 26.5% 40.7% 32.8% [libx264 @ 00000000003a8960] mb P I16..4: 2.2% 2.5% 0.4% P16..4: 15.2% 3.9% 2.4% 0.0% 0.0% skip:73.4% [libx264 @ 00000000003a8960] mb B I16..4: 0.1% 0.1% 0.0% B16..8: 10.5% 0.5% 0.1% direct: 0.1% skip:88.7% L0:33.9% L1:63. 4% BI: 2.7% [libx264 @ 00000000003a8960] 8x8 transform intra:43.6% inter:71.7% [libx264 @ 00000000003a8960] direct mvs spatial:99.9% temporal:0.1% [libx264 @ 00000000003a8960] coded y,uvDC,uvAC intra: 44.7% 43.8% 22.2% inter: 2.4% 2.2% 0.1% [libx264 @ 00000000003a8960] i16 v,h,dc,p: 41% 36% 8% 14% [libx264 @ 00000000003a8960] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 13% 20% 6% 9% 9% 9% 7% 12% [libx264 @ 00000000003a8960] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 21% 7% 6% 9% 9% 9% 8% 13% [libx264 @ 00000000003a8960] i8c dc,h,v,p: 55% 25% 12% 7% [libx264 @ 00000000003a8960] Weighted P-Frames: Y:6.4% UV:5.8% [libx264 @ 00000000003a8960] ref P L0: 65.6% 14.5% 13.0% 3.4% 2.8% 0.7% 0.0% [libx264 @ 00000000003a8960] ref B L0: 87.9% 9.2% 2.3% 0.7% [libx264 @ 00000000003a8960] ref B L1: 96.1% 3.9% [libx264 @ 00000000003a8960] kb/s:514.18 Press any key to continue . . .
EDIT: Seems like gop_open = 0 as default already, but with the manual -g and keyframe setting maybe it would break that or not?
And I don't have any clue what the whole second pass about faststart means ?Last edited by Wader8; 4th Jan 2015 at 08:28.
-
for ffmpeg to move the moov atom to the beginning:
Code:-movflags faststart
It allows you to view and access videos before they are completely uploaded (or downloaded depending which end you are on) -
Simple solution, get a faster internet connection.Originally Posted by Wader8
-
No no no, I think I didn't explain that properly.Originally Posted by newpball
Simple solution, get a faster internet connection.Originally Posted by Wader8
The video is already uploaded, and it waits in queue for 2 hours, then it starts processing.
My test was somewhere around 1.5 to 2 hours in queue. He says he usually would have to wait 2.5 hours. -
So unless you have a connection at Google, how do you expect to be able to change your queue waiting times? Wouldn't that be dependent on working buffer at Google?
Got my retirement plans all set. Looks like I only have to work another 5 years after I die........ -
Supposedly , the rumor is if you upload video with moov atom at the beginning, it starts processing right away, before upload is complete. So that would be substantially faster before it's "up" for longer videos. I don't know if this is true or any conclusive proof (sometimes their servers are loaded regardless)
-
I see now. I would test it out, but I haven't uploaded to youtube in a long time and don't feel like it any time soon.
Got my retirement plans all set. Looks like I only have to work another 5 years after I die........ -
Never encountered that problem, usually my H.264 uploads start processing right away, occasionally there may be a few minutes delay when times are very busy.
What codec and resolution do you typically use for those videos?Last edited by newpball; 4th Jan 2015 at 14:35.
-
It's problematic to "proove" conclusively, because you don't know what the current queue time would have been, or which node or server group gets the job, or exactly what type of "processing" is being done (is it just dividing up the video, or currently encoding) ?Originally Posted by racer-x
But you should move the moov atom to the beginning anyways for streaming or general use (not just youtube). Programs like newer mp4box binaries, ffmbc, yamb etc.. automatically do this anyways . ffmpeg doesn't -
Maybe yours have the moov atom at the beginning already , and those delays were actual sever processing delays from overload?Originally Posted by newpball
You can check with mp4box
Specifically "moov" has to be before "mdat"Code:MP4Box -info -v input.mp4
-
The source is from an internet video service, the file is the middle option of 3 available, so this is a VOD file that is downloaded directly, the source is not a screen capture or a stream dump. (lowest quality is in very weird resolution and quality as wmv so much of the text is unreadable inside, highest is also MP4 but it's 4 GB HD)
Why I went looking for extra config is that I wasn't sure if it's only the size triggering the extra wait queue, there is no queue for any videos below ~150MB even if they don't start processing right away (don't know exactly the treshold around that)
As I said, I knew about this feature as I witnessed it, those were some videos I uploaded many years ago when I didn't had any of the experience with video codecs / editing like I have today.
I will check with mp4box more detailed info about the source, right now. The sources may vary, I have only one example, out of thousands.Last edited by Wader8; 4th Jan 2015 at 14:41.
-
@Wader8
I just noticed in one of your info reports "D:\VEGAS_PROJECT_SOURCE\TOOLS\ffmpeg\latest\bin\aj1.mp4" blah blah...
Both vegas and ffmpeg are commonly used programs that produce MP4's without the moov atom at the beginning (with ffmpeg you can use the switch mentioned in the earlier post; but for vegas, you have to re-wrap it I don't think it can be done internally). You don't have to re-encode to move the moov atom -
UPDATE:
Source File:
Code:[iso file] Current top box start before parsing 0 [iso file] Read Box type ftyp size 32 start 0 [iso file] Current top box start before parsing 32 [iso file] Read Box type moov size 6847360 start 32 [iso file] Read Box type mvhd size 108 start 40 [iso file] Read Box type trak size 2675292 start 148 [iso file] Read Box type tkhd size 92 start 156 [iso file] Read Box type mdia size 2675192 start 248 [iso file] Read Box type mdhd size 32 start 256 [iso file] Read Box type hdlr size 45 start 288 [iso file] Read Box type minf size 2675107 start 333 [iso file] Read Box type vmhd size 20 start 341 [iso file] Read Box type dinf size 36 start 361 [iso file] Read Box type dref size 28 start 369 [iso file] Read Box type url size 12 start 385 [iso file] Read Box type stbl size 2675043 start 397 [iso file] Read Box type stsd size 151 start 405 [iso file] Read Box type avc1 size 135 start 421 [iso file] Read Box type avcC size 49 start 507 [iso file] Read Box type stts size 24 start 556 [iso file] Read Box type stss size 7740 start 580 [iso file] Read Box type stsc size 28 start 8320 [iso file] Read Box type stsz size 1333548 start 8348 [iso file] Read Box type stco size 1333544 start 1341896 [iso file] Read Box type trak size 4171856 start 2675440 [iso file] Read Box type tkhd size 92 start 2675448 [iso file] Read Box type mdia size 4171756 start 2675540 [iso file] Read Box type mdhd size 32 start 2675548 [iso file] Read Box type hdlr size 45 start 2675580 [iso file] Read Box type minf size 4171671 start 2675625 [iso file] Read Box type smhd size 16 start 2675633 [iso file] Read Box type dinf size 36 start 2675649 [iso file] Read Box type dref size 28 start 2675657 [iso file] Read Box type url size 12 start 2675673 [iso file] Read Box type stbl size 4171611 start 2675685 [iso file] Read Box type stsd size 91 start 2675693 [iso file] Read Box type mp4a size 75 start 2675709 [iso file] Read Box type esds size 39 start 2675745 [iso file] Read Box type stts size 24 start 2675784 [iso file] Read Box type stsc size 28 start 2675808 [iso file] Read Box type stsz size 2085732 start 2675836 [iso file] Read Box type stco size 2085728 start 4761568 [iso file] Read Box type udta size 96 start 6847296 [iso file] Read Box type meta size 88 start 6847304 [iso file] Read Box type hdlr size 33 start 6847316 [iso file] Read Box type ilst size 43 start 6847349 [iso file] Read Box type .too size 35 start 6847357 [iso file] Read Box type data size 27 start 6847365 [iso file] Current top box start before parsing 6847392 [iso file] Read Box type free size 8 start 6847392 [iso file] Current top box start before parsing 6847400 [iso file] Read Box type mdat size 1149891311 start 6847400 * Movie Info * Timescale 1000 - Duration 03:05:23.858 2 track(s) Fragmented File: no File suitable for progressive download (moov before mdat) File Brand isom - version 512 Created: GMT Thu Jan 01 00:00:00 1970 Modified: GMT Thu Jan 01 00:00:00 1970 File has no MPEG4 IOD/OD iTunes Info: Encoder Software: Lavf52.64.2 Track # 1 Info - TrackID 1 - TimeScale 29970 - Media Duration 03:05:23.857 Media Info: Language "und (und)" - Type "vide:avc1" - 333382 samples Visual Track layout: x=0 y=0 width=700 height=394 MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21 AVC/H264 Video - Visual Size 700 x 394 AVC Info: 1 SPS - 1 PPS - Profile High @ Level 3 NAL Unit length bits: 32 Self-synchronized Track # 2 Info - TrackID 2 - TimeScale 48000 - Media Duration 03:05:23.797 Media Info: Language "und (und)" - Type "soun:mp4a" - 521428 samples MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40 MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000 Synchronized on stream 1
Originally Posted by poisondeathray
Nah that's just my materials folder I happen to have ffmpeg in. I don't produce these files with Vegas, that was some separate stuff I mentioned, and I was doing all in WMV, every code-quote was for the stuff I'm helping another guy out, i just mentioned what my experiences were, my uploading is not time sensetive, but I may implement the things in my operations once I figure them out with this, don't worry about that.
He takes the VOD from the video service and uploads to youtube, he doesn't do anything to it. He is forced to use low quality format (300 MB WMV) because the 1.1 GB MP4 takes too long for his audience's standards.
So this thread should shift from just finding out the queue size treshold, but also how to force youtube to start processing while it's uploading.Last edited by Wader8; 4th Jan 2015 at 14:54.
-
Originally Posted by Wader8
As you can see, "moov" is already before "mdat" in that example. So if this one doesn't process immediately, "quickstart" is not the reason why for your observations
I don't think you can "force" youtube to do anything
-
Misc: Not sure if this is the same problem https://www.youtube.com/watch?v=qzgyBCqkQEM
I didn't mean the word force, just figuring it out, whatever, seems like a stupid amount of time wasted because it doesn't want to process while upload and this should be figured out and many people may come across this thread, so please hang around guys.
My test upload yesterday got stuck at 95%, but, that's because I can't upload more than 15 minutes and it was removed before it finished processing.
EDIT:
I just tried uploading the source MP4 for a few seconds, i immediately go this TIP message "Your videos will process faster if you encode into a streamable file format. For more information, visit our Help Center."
Usually, I normally get the TIP message saying "you are uploading video in 16:9, bla bla bla" when I do my stuff, even then it's not processsing while uploading. -
So newpball has the solution to that other problem - get a faster connection or a better one that allows you to upload more than 15 minutes (why can you only upload for 15 minutes ?)
-
You need to register with a real identity (takes 1 minute) and your account must be in good standing.Originally Posted by poisondeathray
-
Oh, does he mean 15 minute duration videos, not 15 minutes of uploading time ? I didn't click the linkOriginally Posted by newpball
You need to register with a real identity (takes 1 minute) and your account must be in good standing.Originally Posted by poisondeathray
Do they limit you if you've been "bad" or something ?
-
Originally Posted by newpball
You need to register with a real identity (takes 1 minute) and your account must be in good standing.Originally Posted by poisondeathray
Yeah but I'm just testing, the guy that needs this has this sorted out.
Continuing, I get the hunch that it's not just moov atom but also all the other pesky things, maybe the video really has to have GOP size half the framerate and all of those settings just exactly as in the https://support.google.com/youtube/answer/1722171?hl=en
So my next thing it will be to recreate what the YT help page says. And actually encode with variable bitrate, the first test was CBR.
I don't even know what bitrate mode the source uses ... let me check if it even says anything. -
-
Yes, I said that the main stuff is still the stuff from the OP, I don't know why I even mentioned that I have my own YT channel doing something completely different and it has zero connection to all of this, ... i don't have a ton of experiences so it's kind of worthless for me to say I uploaded some WMV clips that I made with Vegas.Originally Posted by poisondeathray
That "Source" is the same "Source" i already posted mediainfo in the OP.
These are the direct links available from the VODs on the internet TV website:
Actual Quote:
I don't do any reconversion/rendering before upload. I just download the .wmv file from PPTV and then upload to You Tube.
I use the .wmv file which renders in 240p because it is a smaller file and processes faster...much faster.
Another thing I noticed is if you upload a file larger than 1 GB You Tube REALLY takes a long time to process the video.Sometimes they even put you in a waiting line
So my goal is to get the full show up as quickly as possible
For this video,12-26, PPTV offers 3 formats:
.wmv 848mb
.mp4 1.1gb
.mp4HD 4.1gb
The WMV I was talking about has nothing to do with the "low quality 300 meg WMV" .. just prioritize on latter, and skip those things when I was mentioning my own stuff, I don't have access to the internet TV website because it required paid subscription, he sent me a sample because I requested it so I can figure out a way to modify it so it loses some quality but it would upload on youtube much faster, the result would be much better than using the "low quality 300 meg WMV" from the internet TV website. .. should have explained more clearly earlier.
As I said, most of the stuff I have to figure out the hard way, I had to ask him for bits of techincal details or else I would just be guessing stuff.
CORRECTION: "low quality 300 MEG WMV" comes from the fact that once it's on youtube it's fairly low, lower than the usual 700 MB for a 360p download when he uses the slow method or what, im not really sure myself if the sources are consistent as he didn't look like to know all that detailed info. Let's just assume the sources are consistent, I've got enough on my head.
That's just because the source resolution is a wonky one and youtube just doesn't make the upscales to use the extra bitrate and cuts down to 240p only, I'm not sure exactly what resolution the 848 WMVs are but when they are on youtube they appear as 480x270.
That's why im using ffmpeg to also upscale the 700x394 1.1GB MP4 source to 854x480 so the 480p links are unloked on youtube, which enable video and audio to have higher bitrates, probably not that much but all the quality we can get
So ... a difference of just 300 MB and he has to wait 2 hours MORE to get his video on, ofcourse I was up in arms about it and wanted to help, and I will get to the bottom of this madness. it's also the TV service that uses some absolutely weird non-standard resolutions. When that 848 WMV gets converted to 240p on YT, it looks horrible, text is all garbled which is the main problem.
UPD: I only have 1.1 GB MP4 Source on my PC right here (aj1.mp4), that's the SOURCE i was always talking about earlier, I don't have WMV nor HD ones, I can ask him to send me if I would need them.
UPD2: That said ... now I get another hunch, what if this queue only triggers with MP4's and WMVs are the ones that work, so it may not be the size nor the encoding config behind the +2 hour queue ... what a great start for 2015
Last edited by Wader8; 4th Jan 2015 at 15:47.
-
TEST 2:
WMV2 + COPY AUD + AVI + FULL UPLOAD AND WAIT
CODE:UL-FILESIZE: 1,18 GB (1.272.016.896 bytes)Code:ffmpeg -loglevel verbose -i %input%.mp4 -vcodec wmv2 -pix_fmt yuv420p -s 854x480 -aspect 854:480 -r 29.97 -b:v 768k -acodec copy -threads 4 %input%_Recoded1.avi
TIPS: #1""You uploaded a wide-screen (16:9) video. If your original was 720p or greater (i.e. 1280x720 or greater) we encourage you to submit your video at original resolution to enable better quality playback.""
--------------------------------------------------
No concurrent processing.
Processing started immediately after full upload.Last edited by Wader8; 4th Jan 2015 at 19:04.
-
The whole thing sounds incredibly messy.Originally Posted by Wader8
Yes, I said that the main stuff is still the stuff from the OP, I don't know why I even mentioned that I have my own YT channel doing something completely different and it has zero connection to all of this, ... i don't have a ton of experiences so it's kind of worthless for me to say I uploaded some WMV clips that I made with Vegas.Originally Posted by poisondeathray
That "Source" is the same "Source" i already posted mediainfo in the OP.
These are the direct links available from the VODs on the internet TV website:
Actual Quote:
I don't do any reconversion/rendering before upload. I just download the .wmv file from PPTV and then upload to You Tube.
I use the .wmv file which renders in 240p because it is a smaller file and processes faster...much faster.
Another thing I noticed is if you upload a file larger than 1 GB You Tube REALLY takes a long time to process the video.Sometimes they even put you in a waiting line
So my goal is to get the full show up as quickly as possible
For this video,12-26, PPTV offers 3 formats:
.wmv 848mb
.mp4 1.1gb
.mp4HD 4.1gb
The WMV I was talking about has nothing to do with the "low quality 300 meg WMV" .. just prioritize on latter, and skip those things when I was mentioning my own stuff, I don't have access to the internet TV website because it required paid subscription, he sent me a sample because I requested it so I can figure out a way to modify it so it loses some quality but it would upload on youtube much faster, the result would be much better than using the "low quality 300 meg WMV" from the internet TV website. .. should have explained more clearly earlier.
As I said, most of the stuff I have to figure out the hard way, I had to ask him for bits of techincal details or else I would just be guessing stuff.
CORRECTION: "low quality 300 MEG WMV" comes from the fact that once it's on youtube it's fairly low, lower than the usual 700 MB for a 360p download when he uses the slow method or what, im not really sure myself if the sources are consistent as he didn't look like to know all that detailed info. Let's just assume the sources are consistent, I've got enough on my head.
That's just because the source resolution is a wonky one and youtube just doesn't make the upscales to use the extra bitrate and cuts down to 240p only, I'm not sure exactly what resolution the 848 WMVs are but when they are on youtube they appear as 480x270.
That's why im using ffmpeg to also upscale the 700x394 1.1GB MP4 source to 854x480 so the 480p links are unloked on youtube, which enable video and audio to have higher bitrates, probably not that much but all the quality we can get
So ... a difference of just 300 MB and he has to wait 2 hours MORE to get his video on, ofcourse I was up in arms about it and wanted to help, and I will get to the bottom of this madness. it's also the TV service that uses some absolutely weird non-standard resolutions. When that 848 WMV gets converted to 240p on YT, it looks horrible, text is all garbled which is the main problem.
UPD: I only have 1.1 GB MP4 Source on my PC right here (aj1.mp4), that's the SOURCE i was always talking about earlier, I don't have WMV nor HD ones, I can ask him to send me if I would need them.
UPD2: That said ... now I get another hunch, what if this queue only triggers with MP4's and WMVs are the ones that work, so it may not be the size nor the encoding config behind the +2 hour queue ... what a great start for 2015
I would suggest thinking things through with quality and efficiency in mind and creating a workflow and sticking to it. -
Originally Posted by Wader8
The size of the upload has nothing to do with it. I often upload files to YouTube well over 2GB and the processing begins immediately after the upload is completed. I create MP4s through RipBot.So ... a difference of just 300 MB and he has to wait 2 hours MORE to get his video on
I agree. It sounds to me like a case of the blind leading the blind.Originally Posted by newpball
-
TEST 3: YT-HELP-PAGE-"COMPLIANCE"-TEST https://support.google.com/youtube/answer/1722171?hl=en
x264 + COPY AUD + MP4 + FULL UPLOAD AND WAIT
CODE:UL-FILESIZE: 677 MB (710.123.520 bytes) ... came out a bit too small, maxrate minrate includes audio for some stupid reason.Code:ffmpeg -loglevel verbose -i %input%.mp4 -vcodec libx264 -profile:v "high" -level:v 3.1 -pix_fmt yuv420p -s 854x480 -aspect 16:9 -movflags faststart -r 29.97 -g 14.985 -keyint_min 59.94 -bf 2 -b:v 496k -minrate 432k -maxrate 528k -bufsize 96k -acodec copy -threads 4 %input%_Recoded-YTHELP2.mp4
TIPS: "" Your videos will process faster if you encode into a streamable file format. For more information, visit our Help Center. ""
-------------------------------------
No concurrent processing.
Processing started immediately, reached 99% then fell back to 0% and TIP2 about queue appeared (maybe a file length thingy with my channel, cancelled)
The other one above got stuck at 95% which is the real processing, that's how the first file got stuck at 95% after 2 hrs because of video length, the stuck was because it got cancelled by youtube automatically, so it would have finished if I had verified channel, which I'm not going to do until I find a spare phone that's not my own or my close ones.Last edited by Wader8; 4th Jan 2015 at 21:26.
-
Omg ... I may have found the bugger!
Found something that recalled me to a unrelated file that I happened to test for youtube for an unrelated reason, but was never intended for upload on it's own, just a few months ago, and because it was unusual I remember that processing was happening concurrently, but this is not 100% confirmed, the TEST 3 is finishing and I am skipping another test I was planning and preparing a for this one instead.
STAY TUNED -
TEST 4:
x264 + AUD COPY + MPEGTS + FULL UPLOAD AND WAIT
CODE:UL-FILESIZE: 1,13 GB (1.214.992.384 bytes)Code:ffmpeg -loglevel verbose -i %input%.mp4 -vcodec libx264 -preset medium -profile:v "high" -level:v 3.1 -pix_fmt yuv420p -s 854x480 -aspect 16:9 -movflags faststart -r 29.97 -g 14.985 -keyint_min 59.94 -bf 2 -b:v 832k -minrate 736k -maxrate 992k -bufsize 168k -acodec copy -f mpegts -threads 8 %input%_Recoded-MPEGTS1.mpg
TIPS: ??
-------------------------------------------------
No concurrent processing.
Fell asleep shortly after -
Load of bull pretty much, youtube is such POS.
The processing info doesn't alternate-overlap the upload completion bar as it used to (i use opera without flash player for this, tried in firefox too)
VIDEO MANAGER: Once you start uploading you need to have this open on another tab and refresh it.
Video Draft:
Processing has started. == Not processing. Was it stuck at this for x264 the whole time while uploading, no idea.
Processing 0% ... 20% .. 33% == Actual processing while uploading. and the percentage show is the percent from currently uploaded, so in bigger files it starts and goes way ahead of the upload percentage but then it super slows down as video gets uploaded.
Now I had no idea about this before so whatever the 2 hours of wait was for I don't know, could have probably processed that x264 but would stuck for 2 hours for some BS reason, to the point I don't even know what the hell is their problem, I just know it's a pile of shit.
So.. I would have to repeat all the tests just to keep checking that.
VP8 and WEBM are taking too long for ffmpeg, very slow, so that's out.
Going back to MPEG2 ...Last edited by Wader8; 5th Jan 2015 at 05:58.
-
TEST 5:
HEVC + AUD COPY + MKV + 50 MB Clip
CODE:UL-FILESIZE: 43,3 MB (45.498.368 bytes)Code:ffmpeg -loglevel verbose -i %input%.mp4 -vcodec libx265 -preset faster -level:v 3.1 -pix_fmt yuv420p -s 854x480 -aspect 16:9 -movflags faststart -ss 00:00:00 -to 00:10:00 -r 29.97 -g 14.985 -b:v 608k -acodec copy -f matroska -threads 8 %input%_Recoded-MKV1.mkv
TIPS: Wide + Queue
--------------------------------
Processing never started.
Waiting in Queue ... 30 minutes and counting .. oops MKV is not supported :/
EDIT: For some reason a big dejavu hit my head that I was already once trying to figure this out and thinking about the file that I uploaded many many months ago that did have processing being indicated on the main uploading page, i remember it clearly the text was alternating between upload progress and processing progress, basically 2 progress bars in one, i've never since spotted that.
It's really a pity, HEVC produces a great looking video, MPEG2 is horrible, maybe I really need to use CRF lossless or SAMEQ ... but that would be some huge filesize imo.
Maybe I didn't use proper options for VP8 and VP9 because they looked good and I think it worked, but, ffmpeg was going like 15 fps speed that's too slow, at least 150fps is necessary and that should take 15-20 minutes for a 3 hour file.Last edited by Wader8; 5th Jan 2015 at 09:23.
Quote