[Ffmpeg-devel-irc] ffmpeg.log.20151112

[burek]

[00:01:29 CET] <disturbed1> hello  all
[00:03:42 CET] <ChocolateArmpits> hey
[00:03:49 CET] <disturbed1> any recommendations, need to transcode ac3 to aac before i push stream to wowza to transcode mpeg_ts to h264... anyone now the commandline to use ffmpeg for this process?
[00:04:02 CET] <JEEB> mpeg-ts is a container
[00:04:06 CET] <JEEB> H.264 is a video format
[00:04:31 CET] <disturbed1> sorry for wording but you get my point
[00:04:54 CET] <disturbed1> wowza don't support of ac3...
[00:05:17 CET] <disturbed1> so i need to transcode audio side of stream to aac
[00:05:28 CET] <disturbed1> before i push it to wowza
[00:05:31 CET] <JEEB> well -c:a aac -strict experimental -b:a 128k
[00:05:36 CET] <JEEB> will encode audio to aac
[00:06:01 CET] <JEEB> I recommend grabbing the latest FFmpeg for that, since the internal aac encoder has been vastly improved lately
[00:06:06 CET] <disturbed1> okay, thx, been awhile since i've played in this field
[00:06:14 CET] <JEEB> as in, a version from master within a few weeks
[00:06:36 CET] <disturbed1> ka, thx for heads up, last time i downloaded was last spring
[00:06:46 CET] <JEEB> yeah, definitely update then
[00:07:00 CET] <JEEB> atomnuker's updates to the AAC encoder are <3
[00:09:56 CET] <SpeakerToMeat> Is there a way to list profiles for a codec?
[00:10:01 CET] <disturbed1> git-480bad7 (2015-11-09)..... got it....
[00:14:37 CET] <ChocolateArmpits> why is the "aac" encoder still considered experimental ? stability issues or something ?
[00:17:46 CET] <jasom> ChocolateArmpits: If it's based off of faacm then it generates very poor quality output
[00:18:21 CET] <SpeakerToMeat> JEEB: I guess this new one didn't make it into 2.8.1, right?
[00:18:28 CET] <ChocolateArmpits> jasom: well JEEB's saying it was drastically improved, so it begs the question when is it good enough to not be considered experimental
[00:18:56 CET] <jasom> JEEB: oh, aac encoder improvements?  Where can I read more?
[00:19:00 CET] <c_14> ChocolateArmpits: iirc there's one little thing he still wants to fix
[00:20:59 CET] <JEEB> SpeakerToMeat: no
[00:21:04 CET] <JEEB> 2.8 was cut before that from master
[00:21:25 CET] <JEEB> jasom: see the related video from https://www.youtube.com/playlist?list=PLQLpBN3oI7E44HIdTOovThc1MNHLchgHE
[00:21:32 CET] <JEEB> (and the longest thread on the trac)
[00:22:23 CET] <SpeakerToMeat> JEEB: Sigh, I didn't want to move from the packaged version of ffmpeg on my distro. :D
[00:22:30 CET] <jasom> JEEB: thanks!
[00:22:41 CET] <SpeakerToMeat> JEEB: To avoid making a load of placeholders. But, It seems I'll have to.
[00:23:01 CET] <jasom> SpeakerToMeat: what distro?  There may be a package in an alternate repository that follows ffmpeg master
[00:23:49 CET] <SpeakerToMeat> jasom: Debian Jeese
[00:24:18 CET] <SpeakerToMeat> jasom: With 2.8.1 from backports
[00:26:18 CET] <jasom> SpeakerToMeat: I'm not super familiar with deb, but you may have to wait until a newer ffmpeg hits backports
[00:26:19 CET] <SpeakerToMeat> I could get the packaging data from the backport, see if the patches are needed/broken against HEAD, and use it to build new packages for myself every while...
[00:26:28 CET] <jasom> SpeakerToMeat: yeah
[00:26:31 CET] <SpeakerToMeat> jasom: It wont.
[00:27:14 CET] <SpeakerToMeat> jasom: Not if some of these stuff wont make it into 2.8. Once they've set on the version for the next release, after a certain date they'll stop moving majors forward.
[00:27:20 CET] <jasom> ah
[00:27:39 CET] <jasom> I haven't used a linux distro with releases in a long time
[00:27:58 CET] <SpeakerToMeat> jasom: Backports come from the next release. Basically. In this case jessie being stable, receives from testing which will be the next stable, right now that's stretch.
[00:28:05 CET] <jasom> you could always do something crazy like https://wiki.debian.org/CreatePackageFromPPA
[00:28:41 CET] <SpeakerToMeat> when stretch avances in the process of going thowards stable, majors, and then minors will be frozen, and maintainers will work only on eliminating bugs from the frozen version
[00:28:59 CET] <SpeakerToMeat> jasom: I think I'll rather try my idea.
[00:30:26 CET] <SpeakerToMeat> disturbed1: what's v210?
[00:41:48 CET] <JEEB> SpeakerToMeat: you can quite easily build FFmpeg from source and put the static binary somewhere in your PATH
[00:42:07 CET] <JEEB> that way it won't do harm to your packaged stuff
[02:31:10 CET] <disturbed1> got it
[02:31:12 CET] <disturbed1> ffmpeg -i 'udp://localhost:5000?fifo_size=1000000&overrun_nonfatal=1' -crf 30 -preset ultrafast -acodec aac -strict experimental -ar 44100 -ac 2 -b:a 96k -vcodec libx264 -r 25 -b:v 500k -f flv 'rtmp://<wowza server IP>/live/cam0'
[03:36:35 CET] <test123456> hey everyone
[03:36:46 CET] <test123456> been playing around with NVENC for h264
[03:36:58 CET] <test123456> it looks like the "-crf" option isn't really being followed
[03:37:03 CET] <test123456> any thoughts?
[06:28:36 CET] <SianaGearz> hi there guys. i'm trying to encode a ROQ (quake VQ format) video as an experiment, and it appears ffmpeg binary (version N-76539-g480bad7) does not appear to obey video bitrate control.
[06:30:01 CET] <SianaGearz> it prints the requested bitrate in the Stream #0:0 line but the video invariably comes out at unrelated bitrate which is much much higher.
[06:31:14 CET] <SianaGearz> is there a good reason for that though?
[07:19:03 CET] <JamJams> Does anybody know what the buffer size is for the default avio in libavcodec?
[07:23:04 CET] <Primer> Pardon my ignorance, but can ffmpeg be used to simply display an input (file, stream, whatever) to the display?
[07:29:33 CET] <JamJams> No you're thinking of ffplay
[07:39:10 CET] <flux> it seems to be so, but I think it wouldn't be too far-fetched given it also has X11 capture :)
[08:19:30 CET] <Primer> JamJams: ahhh thanks
[08:19:40 CET] <Primer> I presume that supports all the features ffmpeg does?
[08:19:40 CET] <JamJams> :)
[08:19:45 CET] <JamJams> Should do
[08:19:52 CET] <Primer> excellent
[09:05:01 CET] <Primer> Seems it does not
[09:05:54 CET] <Primer> Trying to do -filter_complex and it complains that it's already got a -i
[09:10:05 CET] <Primer> Argument 'rtsp://theurl' provided as input filename, but 'rtsp://theurl' was already specified.
[11:34:18 CET] <Lobs> I have an odd thing happening with using ffmpeg to live stream to youtube with rtmp, it seems to for some reason not matter what bitrate is set only stream at around 512kbit, if i change the bitrate the encoding fps changes to reflect the change, i know i am not maxing out the cpu as i can encode to a file faster than real time. Anyone have any remote idea as to what could cause this?
[11:34:50 CET] <Lobs> (it was working properly about 2 weeks ago and just started doing this)
[11:36:23 CET] <Lobs> i know the bandwidth from the encoding machine to the internet is fine, have tested that.
[11:38:33 CET] <Lobs> `ffmpeg -y -i "$1" -vf yadif,scale=640:36
[11:38:34 CET] <Lobs>  aac -ac 1 -ar 48k -ab 64k -c:v libx264 -g 12 -b:v 2m -profile:v baseline -prese
[11:38:37 CET] <Lobs> aspect 16/9 -strict -2 -threads 0 "rtmp://a.rtmp.youtube.com/live2/$2"`
[11:38:55 CET] <Lobs> gah, sorry forgot about right click in this terminal
[11:41:13 CET] <Lobs> fflogger: http://pastebin.com/UhwDEupy
[11:42:21 CET] <Lobs> i added -report to try to debug,
[11:42:50 CET] <c_14> Try removing yadif and/or scale. I'm pretty sure scale at least doesn't thread particularly well.
[11:43:11 CET] <Lobs> i can encode to a file at faster than real time though,
[11:43:17 CET] <c_14> With the exact same command?
[11:43:23 CET] <c_14> (just replacing the rtmp:// output)
[11:43:33 CET] <Lobs> yes except change the rtmp to `file.flv`
[11:43:52 CET] <c_14> hmm
[11:43:57 CET] <Lobs> as that command is it encodes at 5-6fps, to a file it encodes at over 56fps
[11:44:09 CET] <Lobs> so i know there is cpu to do it,
[11:44:17 CET] <c_14> How did you test the internet bandwidth?
[11:44:41 CET] <Lobs> yes, plenty of bandwidth on a 100mbit fiber connection.
[11:45:06 CET] <Lobs> tested it with sending files to my own server and using speedtest.net
[11:45:22 CET] <c_14> Yes, but maybe your connection to a.rtmp.youtube.com is slower than connections to other places (due to bad peering or whatever)
[11:45:26 CET] <Lobs> downloading from youtube is very fast,
[11:45:57 CET] <Lobs> i cant test a.rtmp.youtube.com for bandwidth directly, but on a second machine on the same network the command to stream works fine.
[11:46:09 CET] <c_14> Can you encode ~15 or so min of video to out.flv, and then use that file as input with -c copy ?
[11:46:18 CET] <c_14> (as input to send to rtmp)
[11:46:32 CET] <c_14> If that works that would rule out network bandwidth issues.
[11:46:37 CET] <Lobs> i can also use the backup youtube servers (b.rtmp.youtube.com c.rtmp.youtube.com etc and same result)
[11:47:05 CET] <Lobs> will try the sending pre encoded file with -c now.
[11:50:45 CET] <Lobs> wont go over 8fps
[11:51:51 CET] <Lobs> i re compiled ffmpeg earlier today to lates git, that didnt change anything, so i am not 100% sure it is ffmpegs fault,
[11:52:08 CET] <Lobs> i have used a diferent network and network interface, i have rebooted the machine,
[11:52:14 CET] <Lobs> i cant think of anything else.
[11:55:08 CET] <c_14> Can you try testing against an rtmp server that isn't youtube? (maybe setting up something like nginx-rtmp somewhere)
[11:55:17 CET] <c_14> Also, you said it worked fine on another computer
[11:55:23 CET] <c_14> Any differences between the two?
[11:55:47 CET] <Lobs> i could, i did use netcat on the rtmp ports to dump a file across to one of my own international servers and that sent at over 7mbit.
[11:56:32 CET] <c_14> So the problem only occurs with the youtube servers?
[11:56:50 CET] <Lobs> the working machine is 32bit, the non working is 64bit, but the non working one worked about 2 weeks ago and nothing was upgraded or installed since it last worked (apart from earlier today when i recompiled ffmpeg to see if that would fix it)
[11:58:00 CET] <c_14> And the last time you tested on the 32bit machine was recent (today or so)?
[11:58:06 CET] <c_14> Any different compilation flags between the two?
[11:59:06 CET] <Lobs> i tested on the 32bit machine today,
[11:59:44 CET] <Lobs> no different configure flags set between the two,
[12:00:00 CET] <Lobs> just likely installed libs and whatever differneces between 32bit and 64bit.
[12:00:24 CET] <Lobs> but like i said the 64bit one did work previously and just out of the blue started being "limited"
[12:00:37 CET] <c_14> Can you pastebin the command output of the slow rtmp command? Maybe there's a message somewhere you missed.
[12:01:04 CET] <Lobs> i am fairly sure i have not missed any messages,
[12:01:35 CET] <Lobs> i can do the output but will need to edit out the rtmp address as that can be missused if someone gets the "key" from it.
[12:01:42 CET] <c_14> sure
[12:03:46 CET] <c_14> But it doesn't really sound like a problem with ffmpeg, considering that it used to work and it now doesn't work even though nothing changed. Maybe try with another 64bit computer on the same network? (live-cd or something maybe)
[12:07:31 CET] <Lobs> i figure this should be enough,  http://pastebin.com/aEFm1p6v
[12:08:03 CET] <Lobs> the actual encode does not change the further it goes
[12:10:40 CET] <c_14> Hmm, yeah. looks fine
[12:11:03 CET] <Lobs> it really has me stumped....
[12:24:39 CET] <Lobs> c_14: just to add, just made my own rtmp server on my international host and it has similar to youtubes rtmp server happening, when ffmepg is streamig it isnt using full bandwidth, (tho is slightly faster than the youtube one)
[12:36:47 CET] <c_14> Lobs: But it works with the 32bit host?
[12:42:14 CET] <Lobs> c_14: yes.
[12:42:33 CET] <Lobs> c_14: overe 50fps on that one.
[12:42:52 CET] <c_14> Do you have another 64bit host that you can test with?
[12:43:39 CET] <c_14> If you can somehow make the problem reproducible, then you could open a ticket to see if the bug maybe is in ffmpeg somewhere.
[12:45:05 CET] <Lobs> c_14: works find on a second 64bit machine on the same network as the others
[12:45:32 CET] <Lobs> c_14: so it seems to onnly be with this single machine, but it is weird only ffmpeg sending rtmp has issues.
[12:45:55 CET] <furq> do you have an rtmp server on the lan you can try streaming to
[12:46:11 CET] <furq> all i can think of is some kind of firewall/router misconfiguration
[12:46:21 CET] <Lobs> furq: i have set one up on a international server i have which is what i have just best testing it with,
[12:47:01 CET] <Lobs> furq: no, i have used a different network interface to send through a different network bypassing the usual router etc and still the same issue.
[12:47:29 CET] <furq> weird
[12:48:02 CET] <Lobs> my first thought with it was there was some qos or traffic shaping rule at play, but have proven that not to be the case.
[12:49:09 CET] <Lobs> i can use netcat and send out on the rtmp port quite fine, but with ffmpeg it seems limited.
[12:55:50 CET] <c_14> Lobs: what if you were to stream with plain tcp on the same port using ffmpeg? tcp://address:1935
[12:56:44 CET] <c_14> Using otherwise the same options (-f flv etc)
[12:59:43 CET] <Lobs> c_14: that works fine, getting over 30fps on the same file that only got 8fps with rtmp
[13:00:15 CET] <c_14> So it's either something in the rtmp protocol, or deep packet inspection
[13:00:43 CET] <c_14> Can you try setting up rtmps? (not entirely sure what this involves doing with ffmpeg)
[13:00:46 CET] <furq> dpi wouldn't explain it working from another machine on the same network
[13:00:58 CET] <c_14> Unless it's actually the system itself doing the inspection.
[13:01:15 CET] <furq> is that even a thing
[13:01:17 CET] <c_14> Though I don't know what/why it would do that...
[13:01:20 CET] <Lobs> as far as i am aware there is nothing installed on the machine with issues that should do any dpi
[13:01:41 CET] <Lobs> as i say it used to work on this machine
[13:02:12 CET] <c_14> The machine acquired a sudden intense dislike of rtmp?
[13:02:19 CET] <Lobs> it seems so...
[13:02:22 CET] <c_14> Maybe it's haunted? :P
[13:02:33 CET] <Lobs> wouldnt surprise me to be honest.
[13:02:34 CET] <furq> that's better than anything i can think of
[13:02:54 CET] <Lobs> but normally a reboot kicks out the ghosts (at least for a short time)
[13:04:19 CET] <Lobs> guess i will have to encode to a file on this machine for now and use another machine to actually stream it.
[13:04:35 CET] <Lobs> i'd just love to know what has happend to cause what is going on.
[13:06:17 CET] <furq> you could set up a local rtmp server and use it as a relay
[13:06:33 CET] <furq> obviously it's not ideal but it's less hassle than encoding and streaming separately
[13:07:16 CET] <Lobs> i suspect from the tests i have done that even a local rtmp server on the same network will have the same issue.
[13:07:50 CET] <Lobs> the stream i send has to be delayed by 30 mins anyway (due to broadcasting rights issues) so streaming from a file isnt the end of the world.
[14:47:07 CET] <AndrewMock> What library is used to decode TrueHD?
[15:08:42 CET] <JEEB> libavcodec
[16:00:22 CET] <AndrewMock> thx JEEB
[16:07:21 CET] <AndrewMock> Are there concerns over copyright + patent infringement?
[16:07:38 CET] <AndrewMock> Surely Dolby and DTS would not approve lol
[16:09:29 CET] <AndrewMock> I assume that a clean-lab reverse engineering is in play?
[16:10:29 CET] <durandal_1707> Patents have nothing to do with that
[16:10:45 CET] <AndrewMock> what do you mean?
[16:11:31 CET] <DHE> if it's a patented thing, a patent is a public record. anybody can look them up. so the development is fairly straight-forward
[16:11:58 CET] <DHE> patents affect what you can do with it afterwards
[16:12:12 CET] <AndrewMock> exactly i.e. publish it on git
[16:16:05 CET] <AndrewMock> In other words, what's to prevent DTS/Dolby from sending a DMCA takedown notice for using their copyrighted technology in FFmpeg?
[16:18:00 CET] <AndrewMock> The only defense is called clean-room reverse engineering. https://en.wikipedia.org/wiki/Chinese_wall#Reverse_engineering
[16:20:05 CET] <AndrewMock> sounds like ffmpeg could have legal problems
[16:20:37 CET] <Venti> technology can't be copyrighted, for one
[16:21:09 CET] <AndrewMock> copyrighted codec*
[16:26:33 CET] <furq> if you don't plan on embedding libavcodec into a commercial product then i wouldn't worry
[16:28:16 CET] <AndrewMock> lol
[16:34:07 CET] <disturbed1_awy> question, going to build a dell t7500 with 2x nvidia S870's and if room allows, 1-2 nvidia quadros 5000... once built how would i tell ffmpeg which gpu to use?
[16:35:47 CET] <DHE> with nvenc? -gpu 0 or -gpu 1
[16:35:55 CET] <DHE> and so on
[16:36:51 CET] <AndrewMock> Does libavcodec read TrueHD embedded downmix coefficients?
[16:49:54 CET] <disturbed1_awy> thx
[17:59:23 CET] <RobertNagy> so I'm having a bit of an issue with growing memory usage in ffmpeg with the following command:
[17:59:49 CET] <RobertNagy> cat raw_mpeg2 | ffmpeg -f mpegvideo -threads 1 -i - -f mpeg1video -an -threads 1 - > /dev/null
[18:00:23 CET] <RobertNagy> anyone got any ideas as to how to get around the memory leak?
[18:00:32 CET] <RobertNagy> or what might be causing it?
[18:00:46 CET] <c_14> Can you try running under valgrind?
[18:00:52 CET] <c_14> And are you using a recent version of ffmpeg?
[18:00:53 CET] <RobertNagy> how do I do that?
[18:00:54 CET] <RobertNagy> yes
[18:01:01 CET] <RobertNagy> 2.8.1
[18:01:09 CET] <RobertNagy> valgrind memcheck something
[18:02:10 CET] <c_14> just `cat raw_mpeg2 | valgrind ffmpeg -f mpegvideo -threads 1 -i - -f mpeg1video -an -threads 1 - > /dev/null' should work
[18:02:27 CET] <c_14> Also, does this issue occur with all rawa mpeg2 or only with a specific source?
[18:02:35 CET] <RobertNagy> haven't tried with another source
[18:02:52 CET] <RobertNagy> running with "valgrind --leak-check=yes"
[18:03:32 CET] <RobertNagy> https://gist.github.com/ronag/7585db89fbf2b79809fd
[18:04:06 CET] <c_14> How long does it take for the memleak to occur/become noticeable?
[18:04:15 CET] <RobertNagy> it steadily increases
[18:04:21 CET] <RobertNagy> as soon as I start it
[18:04:29 CET] <RobertNagy> 1 MB every 5 min or so
[18:04:57 CET] <c_14> But that's a definitely lost. So definitely a bug. Can you retry with a git build? static build or something
[18:05:09 CET] <RobertNagy> hm
[18:05:14 CET] <RobertNagy> I'll try
[18:06:05 CET] <RobertNagy> if I replace
[18:06:07 CET] <RobertNagy> -f mpeg1video
[18:06:15 CET] <RobertNagy> with -f nut -vcodec libx264 -preset ultrafast
[18:06:20 CET] <RobertNagy> the memory usage is steady
[18:07:33 CET] <c_14> I can reproduce with a git build
[18:07:51 CET] <RobertNagy> oh, good, then it's not just me
[18:08:12 CET] <RobertNagy> should we try with older versions
[18:08:16 CET] <RobertNagy> to see where it regressed?
[18:09:33 CET] <c_14> If you can, that would be great. It would make it easier to find the leak. But the valgrind information is usually enough so you don't have to. (especially if it can be easily reproduced)
[18:09:38 CET] <c_14> It will make it easier for the developer to fix.
[18:09:52 CET] <RobertNagy> alright, should I create a ticket or can you do it?
[18:10:43 CET] <c_14> I can do it. (They'll want the output from the debug git build anyway)
[18:10:52 CET] <c_14> I'll also see if I can simplify the test-case
[18:11:01 CET] <RobertNagy> yea, I suspected something like that
[18:11:10 CET] <RobertNagy> please provide the link so I can follow it
[18:11:14 CET] <c_14> I will
[18:33:05 CET] <c_14> RobertNagy: https://trac.ffmpeg.org/ticket/5004
[18:33:18 CET] <RobertNagy> thanks!
[19:43:28 CET] <Zeranoe> So 'Stream #0:0(und): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p(bt709), 640x368 [SAR 1:1 DAR 40:23], 2392 kb/s, 25 fps, 25 tbr, 90k tbn, 25 tbc (default)' is H.264 or MPEG-4 Part 2?
[19:44:25 CET] <furq> that's part 2
[19:44:52 CET] <DHE> sometimes known as XviD or DivX
[19:44:57 CET] <furq> https://en.wikipedia.org/wiki/MPEG-4_Part_2#Simple_Profile_.28SP.29
[19:45:22 CET] <klaxa> i thought xvid was just a compliant implementation?
[19:45:30 CET] <furq> aren't xvid and divx ASP
[19:45:45 CET] <furq> it's been too long since i messed with that stuff
[22:07:10 CET] <Lobs> 10
[23:03:44 CET] <inlinevoid> Could someone help me out? I'm trying to reduce artifacts I'm getting in my videos: https://www.youtube.com/watch?v=Hb-n6QtlQvU
[23:04:02 CET] <inlinevoid> I used these commands for that video: ffmpeg -start_number 1 -framerate 120 -i frame_%d.tga -framerate 60 -bf 2 -b_strategy 2 -c:v libx264 -preset veryslow -crf 12 -pix_fmt yuv420p -movflags +faststart output.mp4
[23:04:23 CET] <inlinevoid> The source images are 1920x1080 .tga files recorded at 120fps
[23:05:35 CET] <inlinevoid> The video looks good but theres noticable artifacts around the ui when the camera moves
[23:06:01 CET] <inlinevoid> -crf 0 doesn seem to make a difference
[23:06:25 CET] <intracube> inlinevoid: that looks fairly typical for YouTube re-compressed stuff
[23:06:49 CET] <inlinevoid> any way to minimize it or is that as good as it gets?
[23:07:36 CET] <intracube> I doubt you'll get much better
[23:07:41 CET] <intracube> as long as the video you upload is artefact-free
[23:07:54 CET] <intracube> since youtube compress it right down to less than 10mbps
[23:08:06 CET] <intracube> *Mbps
[23:08:40 CET] <inlinevoid> I see.  Also another question, am I wasting my time recording at 120fps and encoding to 60fps?
[23:09:15 CET] <intracube> definitely a benefit in encoding to 60fps since youtube now support that
[23:09:17 CET] <inlinevoid> Or is it worthwhile if quality matters
[23:09:25 CET] <intracube> I don't know if there's any benefit recording @ 120
[23:10:01 CET] <intracube> ffmpeg will ditch every other frame by default
[23:10:42 CET] <inlinevoid> It'll just drop it?  I thought it might use the extra frames in some useful way
[23:11:08 CET] <intracube> inlinevoid: I don't think so
[23:11:27 CET] <intracube> there might be a filter to merge pairs of frames, but that will give a slight ghosting effect
[23:11:33 CET] <intracube> (poor motion blur effect)
[23:11:47 CET] <meekohi> Hey I have a weird situation creating webm files from a stack of jpegs where *rarely* the resulting video will have "Metadata: alpha_mode:1" set.
[23:11:59 CET] <meekohi> And this seems to cause a bug in Chrome: https://code.google.com/p/chromium/issues/detail?id=555086
[23:12:12 CET] <intracube> inlinevoid: does your recording have any glitches when the camera moves or only after uploading to YT?
[23:12:14 CET] <meekohi> Is there anyway to prevent that from happening?
[23:12:47 CET] <inlinevoid> intracube: I'm not sure, vlc cant play the video on my pc haha
[23:13:45 CET] <intracube> inlinevoid: strange. vlc can play most stuff. but that would be the first thing to check
[23:13:55 CET] <intracube> if you still see the blockies, then you need to increase capture quality
[23:14:37 CET] <inlinevoid> The source quality is 1:1 quality with the game
[23:15:17 CET] <inlinevoid> Since the game has a feature to output the frames as is...
[23:15:21 CET] <intracube> then it's YT messing up the quality
[23:15:28 CET] <intracube> nothing you can do about that
[23:15:39 CET] <inlinevoid> Let me try a higher crf so I can actually view the video on my pc
[23:16:05 CET] <intracube> meekohi: can you post the first bit of the encoding output from ffmpeg somewhere?
[23:17:50 CET] <meekohi> intracube: https://gist.github.com/Meekohi/15e344d85d5fc4592a9e
[23:18:46 CET] <meekohi> (just updated with output from ffmpeg -i also)
[23:20:59 CET] <intracube> meekohi: try adding -pix_fmt yuv420p
[23:21:23 CET] <meekohi> Ah yup that seems to fix it.
[23:21:25 CET] <intracube> this might be enough to strip the alpha information from the video
[23:21:40 CET] <meekohi> I'll see if it fixes the issue from Chrome too
[23:21:46 CET] <intracube> ok :)
[23:22:27 CET] <meekohi> geez I even have that argument for the same code that makes mp4s... :P
[23:22:35 CET] <meekohi> Must have decided I needed it at some point...
[23:24:11 CET] <intracube> iirc in the last few years x264 gained the option of encoding to RGB rather than the usual YUV/YCbCr
[23:24:25 CET] <intracube> and ffmpeg would detect which to use from the source
[23:24:43 CET] <intracube> so image sequences would end up as RGB h264 video
[23:25:04 CET] <intracube> but transcoding a video that is already YUV will stay as YUV
[23:25:20 CET] <intracube> and RGB for video isn't well supported in a lot of players
[23:25:50 CET] <meekohi> Is this a bug possibly? Seems strange that JPEGS (which don't have transparency) would result in a video that has alpha_mode:1. It's especially weird because this only happens in certain situations, in most examples it doesn't.
[23:25:53 CET] <intracube> maybe things have changed again, but that was a problem a while back
[23:26:07 CET] <intracube> meekohi: I'm not sure
[23:51:28 CET] <Unknownly> Hello how can i merge 2 .mp4 video files with ffmpeg into one output.mp4 file
[23:53:53 CET] <waressearcher2> Unknownly: hallo
[00:00:00 CET] --- Fri Nov 13 2015