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

[burek]

[00:57:33 CEST] <A124> Heya, looking for lossless pixel perfect commpact video fromat with RGB. qtrle in mov works, little smaller then list of png files, but still huge. Any recommendations or pointers really welcome.
[00:58:13 CEST] <furq> A124: x264 does rgb
[00:58:23 CEST] <furq> -c:v libx264rgb
[00:59:30 CEST] <DHE> and if you set "-qp 0" then x264 will produce lossless output
[00:59:56 CEST] <DHE> there's no colourspace loss in rgb mode, is there?
[01:05:06 CEST] <A124> I did try that but the result was not pixel perfect, using checksum, will try again then.
[01:12:39 CEST] <A124> furq, DHE: https://paste.fedoraproject.org/371306/30435014/
[01:14:45 CEST] <A124> The crcs mismatch 0xa90b4adb 0x162c4adb
[01:16:46 CEST] <drv> you could use ffv1
[01:26:02 CEST] <furq> i get the same thing with ffv1
[01:26:13 CEST] <furq> i guess it's because they're using different pixel formats
[01:26:50 CEST] <furq> yeah it is
[01:27:17 CEST] <furq> A124: http://vpaste.net/1F1jW
[01:28:30 CEST] <furq> i didn't know ffv1 supported rgb, though, so that might be a better choice
[01:30:04 CEST] <klaxa> how does ffv1 compare to x264rgb compression wise?
[01:30:25 CEST] <furq> no idea, but i'd expect ffv1 to be faster to encode and decode
[01:30:42 CEST] <klaxa> that's true
[01:30:52 CEST] <A124> furq yes, you are right, -pix_fmt rgb24 did solve that.
[01:31:01 CEST] <furq> yeah x264rgb uses gbrp
[01:31:19 CEST] <furq> i guess x264gbrp would be a dumb name though
[01:31:20 CEST] <klaxa> gree, blue, red, ????
[01:31:35 CEST] <klaxa> *green even
[01:31:39 CEST] <furq> planar
[01:31:54 CEST] <klaxa> what does that encode?
[01:32:39 CEST] <furq> planar encodes all red pixels, then all green pixels, then all blue pixels (or whatever order they're in)
[01:32:50 CEST] <A124> furq Thank you very much. Gotta try ff1 compression ratios.
[01:32:52 CEST] <furq> as opposed to packed which groups each channel together by pixel
[01:33:12 CEST] <furq> any pix_fmt in ffmpeg which ends in p is planar
[01:33:34 CEST] <klaxa> ooh, i see, thanks for the explanation
[02:08:13 CEST] <Admin__> hey guys.. question -method PUT -multiple_requests 1 http://.. webdav
[02:08:38 CEST] <Admin__> i am sending thing to webdav and yes PUT works.. the files show up.. for some reason the DELETE is not working and i don't see the request on the opposite end.
[02:08:44 CEST] <Admin__> does the delete request exist ?
[02:18:05 CEST] <A124> png 1.5G; x264 ultrafast 2.5G; ffv1.3 1.2G ... speed same ... with superfast it gets down to 2.4, but processing doubles, ffv1.3 with -coder 1 -context 1 does produce even smaller output. Thanks everyone, got a some rgb space saving, while having playable file in container
[02:18:11 CEST] <WereCatf> What has changed as of late? Nvenc-support seems to have broken in ffmpeg. It used to work, but now I can't get it working no matter what I do.
[02:18:46 CEST] <A124> klaxa that ^
[02:19:32 CEST] <furq> that's surprisingly rubbish for x264
[02:19:39 CEST] <furq> i guess it's more of a yuv codec though
[02:19:42 CEST] <klaxa> wow, is ffv1 also faster than x264?
[02:20:02 CEST] <furq> looks like it
[02:20:04 CEST] <A124> Yeah, it is noisy lossy source converted to lossless.
[02:20:08 CEST] <WereCatf> Does anyone else even use nvenc aside from me?
[02:20:22 CEST] <furq> i'm sure some people do
[02:20:36 CEST] <A124> klaxa at ultrafast, they are on par. When I add stuff for more compression ffv gets slower. But faster then superfast on 264
[02:20:52 CEST] <A124> 4 core, real time.
[02:21:22 CEST] <furq> it's been a while since i did any lossless encoding but x264 lossless always seemed a bit poor
[02:21:29 CEST] <furq> mostly because of the terrible decoding speed
[02:21:50 CEST] <A124> I did like nvenc, cause speed, but software gives better qualits, WereCatf, unless you need your stuff fast or you are live streaming.
[02:22:07 CEST] <furq> i assume he is streaming
[02:22:28 CEST] <A124> Yeah, it was meant just as a note.
[02:22:49 CEST] <A124> How does x265 lossless perform?
[02:22:55 CEST] <furq> never tried it
[02:23:06 CEST] <furq> it's almost certainly much slower than x264
[02:23:08 CEST] <A124> Does the default do rgb?
[02:23:15 CEST] <furq> no idea
[02:23:22 CEST] <WereCatf> A124: Of course I know using software would give better quality. I could just plop the placebo-preset if I wanted really good quality, but nvenc isn't *that* terrible and it's tens of times faster
[02:23:25 CEST] <A124> I did use x265 lossy, very good when you know.
[02:23:38 CEST] <furq> i'd stick with ffv1 for lossless stuff in general
[02:23:43 CEST] <furq> it seems to be becoming a standard for archival
[02:25:24 CEST] <A124> It is personal, so I do not care at some stuff, and at some I do. So sometimes want less space taken.
[02:25:24 CEST] <WereCatf> Alas, neither nvenc_h264 or nvenc_hevc works anymore and I was hoping to find someone who knew something about the why, or maybe someone who could test it so I'd know if it was just me or if it's something in general
[02:25:44 CEST] <furq> what error do you get
[02:26:01 CEST] <WereCatf> "EncodePicture failed!: generic error (20)"
[02:34:15 CEST] <klaxa> wow that sure is a helpful error message
[02:34:31 CEST] <A124> furq, klaxa x265 lossless in bgrp/rgb24 is on par with default ffv1 but slow.
[02:34:53 CEST] <klaxa> so ffv1 beats everyone else in everything?
[02:37:44 CEST] <A124> Well, there are other things, but either lack ffmpeg support, paid, or whatever. There is also utvideo I can try, and so on. But definitely not a bad choice for lossless today.
[02:38:25 CEST] <A124> I mean lossless rgb... 264/265 might do well on yuv, which it is designed in mind, did not test.
[02:51:30 CEST] <A124> klaxa utvideo is faster then huffyuv and does great on yuv (nearing 2x speed), better then huffyuv. ffv (fps 0.7x) 326M, utvideo (fps 2.1x) 464M
[02:51:43 CEST] <A124> Hope this helps you and / or someone else.
[02:52:06 CEST] <klaxa> oh nice
[02:52:57 CEST] <A124> Archival -> ffv, realtime -> utvideo, distribution -> x265, Done.
[02:53:28 CEST] <A124> Oh and OPUS. I meet weekly a lot of people that dwell on mp3.
[02:53:50 CEST] Action: A124 thanks everyone and goes around.
[02:54:11 CEST] <klaxa> i use opus a lot
[02:55:30 CEST] <AndrewMock> Are there plans to support DTS' embedded downmix coefficients?
[02:56:15 CEST] <furq> mp3 isn't that bad
[02:56:34 CEST] <A124> False. AAC isn't.
[02:56:40 CEST] <furq> v2 lame is pretty much fine, even if it is a bit of a waste of bits
[02:56:57 CEST] <AndrewMock> mp3 and aac can be used to get good quality
[02:57:07 CEST] <AndrewMock> but aac can do the same with less bitrate
[02:57:18 CEST] <A124> Well, idk, but my ears can hear. 256k OPUS over 320k mp3 any day.
[02:57:24 CEST] <furq> the nice thing about lame is that it writes the xing header so you know which encoder was used
[02:57:35 CEST] <furq> whereas you never know whether your m4a was encoded with faac or some other garbage
[02:57:58 CEST] <AndrewMock> a124, exactly--per bit, the aac coded is best
[02:58:00 CEST] <AndrewMock> qaac ftw
[02:58:07 CEST] <furq> opus beats qaac at the same bitrate
[02:58:21 CEST] <AndrewMock> no way looking up
[02:58:35 CEST] <A124> AndrewMock Yeah, that one is excellent, OPUS is there too though.
[02:58:46 CEST] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png
[02:59:08 CEST] <furq> and yeah, lame is only 30kbps away from being on par
[03:00:03 CEST] <AndrewMock> haha cvbr what the heck
[03:00:10 CEST] <AndrewMock> versus cbr
[03:00:14 CEST] <AndrewMock> unfair test
[03:00:51 CEST] <AndrewMock> cbr 107 kbps would likely crush the opus results
[03:01:11 CEST] <furq> --bitrate is vbr
[03:01:21 CEST] <AndrewMock> still
[03:01:22 CEST] <furq> or rather --vbr is the default
[03:01:46 CEST] <AndrewMock> i think 128k cbr for both will show a diff result set
[03:01:46 CEST] <furq> i don't see how that's unfair unless aac's vbr inherently sucks
[03:01:56 CEST] <furq> 128k cbr for both would be all 5s
[03:02:01 CEST] <furq> that's the only reason they use 96k
[03:02:06 CEST] <AndrewMock> but yeah i am surprised, i guess opus is best at vbr
[03:02:24 CEST] <AndrewMock> most encoders for audio and video are best with cbr
[03:02:27 CEST] <A124> Then people are deaf to my standard.
[03:02:31 CEST] <furq> ?
[03:03:09 CEST] <furq> i thought cbr was pretty much always worse
[03:03:09 CEST] <AndrewMock> ok then, 96kbps stereo cbr would not be all fives still qaac on top
[03:03:53 CEST] <AndrewMock> maybe i am crazy
[03:05:21 CEST] <furq> remember that opus is a much newer codec as well
[03:05:27 CEST] <furq> aac is getting on for 20 years old now
[03:05:51 CEST] <AndrewMock> man codecs are fun
[03:05:55 CEST] <AndrewMock> vp10 boiiiii
[03:06:47 CEST] <furq> tbh i'm mostly just pleased to see that lame acquits itself fairly well
[03:07:53 CEST] <furq> not that i plan on encoding anything new with it, but i still have plenty
[03:11:03 CEST] <alfonsodev> Hi, I''m compiling ffmpeg 3.0 on aws instance for using it a lambda function,
[03:11:29 CEST] <alfonsodev> so far I can compile it successfully with this script http://pastebin.com/k83qKDKH
[03:11:55 CEST] <alfonsodev> The question is how can I compile as a static binary
[03:12:00 CEST] <alfonsodev> The question is how can I compile as a static binary?
[03:12:02 CEST] <AndrewMock> why compile?
[03:12:15 CEST] <alfonsodev> because fdk_aac can't be distributed
[03:12:25 CEST] <AndrewMock> why fdk_aac?
[03:12:38 CEST] <furq> alfonsodev: --disable-shared --enable-static
[03:12:53 CEST] <AndrewMock> fdk_aac is not the "thing" anymore
[03:12:58 CEST] <furq> it is the thing in ffmpeg
[03:13:10 CEST] <AndrewMock> also do you lambda is good for that? thinking aobut it myself
[03:13:19 CEST] <furq> the builtin encoder is good enough but fdk is still better in some regards
[03:13:19 CEST] <AndrewMock> really?
[03:13:21 CEST] <furq> if not all regards
[03:13:37 CEST] <AndrewMock> even with new aac-native improvements?
[03:13:40 CEST] <furq> yeah
[03:13:47 CEST] <AndrewMock> dang good to know
[03:13:49 CEST] <furq> fdk is definitely better at he-aac and vbr
[03:13:54 CEST] <alfonsodev> I read is more efficient in the wiki, I'm using it for faststart and moveflags params
[03:14:01 CEST] <alfonsodev> so I can do progresive download
[03:14:05 CEST] <AndrewMock> nice
[03:14:06 CEST] <furq> and it's probably still a bit better at cbr, but that depends who you ask
[03:14:18 CEST] <furq> the native encoder is just better than faac and vo-aacenc which are garbage
[03:14:28 CEST] <AndrewMock> yeah i am trying to perfect my 128k aac cbr
[03:14:37 CEST] <AndrewMock> so i will return to fdk_aac
[03:15:01 CEST] <alfonsodev> my usage is
[03:15:01 CEST] <alfonsodev> ffmpeg -i input.wav -c:a libfdk_aac -movflags +faststart output.m4a
[03:15:08 CEST] <furq> it's nice that the native encoder is being worked on but i still trust fdk more
[03:15:19 CEST] <alfonsodev> I took it from the wiki https://trac.ffmpeg.org/wiki/Encode/AAC
[03:15:20 CEST] <furq> until i see a decent listening test, anyway
[03:16:17 CEST] <AndrewMock> -movflags and +faststart are the containter's features i think, let me double check
[03:16:27 CEST] <furq> yeah that has nothing to do with fdk
[03:16:57 CEST] <furq> -movflags +faststart is an mp4 muxer option
[03:17:15 CEST] <AndrewMock> alfons, is this for a WWW context?
[03:17:27 CEST] <alfonsodev> mobile app
[03:17:35 CEST] <AndrewMock> make sure to put video with something like 5sec const keyframe intervals
[03:17:41 CEST] <AndrewMock> any video?
[03:17:43 CEST] <alfonsodev> it's Objective c , playing a file from S3 bucket
[03:17:48 CEST] <alfonsodev> mp3
[03:18:05 CEST] <AndrewMock> nice
[03:24:56 CEST] <AndrewMock> do you guys think that qaac or fdk_aac would have a better SNR for 128k cbr fullband stereo music?
[03:25:12 CEST] <furq> qaac was the best aac encoder last time HA tested them all
[03:25:28 CEST] <AndrewMock> sweet thx
[03:25:29 CEST] <furq> they didn't test fdk but they did test fhg, which is fraunhofer's proprietary encoder
[03:25:36 CEST] <furq> so you'd expect fdk to be the same or worse
[03:58:26 CEST] <bumblehead> is it possible to use ffmpeg to combine audio files so that they appear on separated channels within a single audio output file?
[03:59:59 CEST] <bumblehead> I'm using this argument to merge 4 wav files I downloaded from the internet
[04:00:04 CEST] <bumblehead> -filter_complex amix=inputs=4:duration=first:dropout_transition=3
[04:00:26 CEST] <bumblehead> it does produce an output file with the joined result
[04:00:51 CEST] <bumblehead> but they don't appear to be channel separated
[04:00:57 CEST] <furq> you want amerge, not amix
[04:01:01 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#amerge
[04:03:14 CEST] <bumblehead> furq: thanks I will try that
[04:03:23 CEST] <furq> https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[04:03:29 CEST] <furq> that should be useful as well
[05:57:26 CEST] <bumblehead> furq: thank you
[05:57:35 CEST] <bumblehead> I was able to get the result I needed
[05:57:46 CEST] <bumblehead> those links were a terrific help
[09:35:44 CEST] <bumblehead> J„YjUD
[10:36:39 CEST] <yagiza> Hello!
[10:59:16 CEST] <yagiza> Keep fightin' with RTP...
[11:01:30 CEST] <yagiza> Do any1 understand how RTP demuxing should work? What needs to be on specified host:port? What means connect() to UDP socket?
[11:22:16 CEST] <DHE> a connect() locks the remote end of a UDP socket. you don't need to sendto(), you can simply send() and return packets will be filtered to block out other endpoints
[11:26:52 CEST] <yagiza> DHE, ok, thanx
[11:27:03 CEST] <yagiza> DHE, another question is...
[11:28:44 CEST] <yagiza> DHE, when I try to play RTP stream, I specify just destination host and port.
[11:32:00 CEST] <yagiza> DHE, how destination host should know, where to send UDP datagrams?
[12:39:57 CEST] <m1dnight_> Guys, Im trying to stream my webcam from osx to youtube. I have a command that seems to work, but nothing is arriving at youtube's end..
[12:48:57 CEST] <m1dnight_> Hrm, even with VLC it dies in the end.
[14:38:22 CEST] <alfonsodev> Hi, perhaps anyone here can help with this question http://serverfault.com/questions/779407/gcc-is-unable-to-create-an-executable-file-compiling-ffmpeg-as-static-binary
[14:38:59 CEST] <furq> alfonsodev: tail config.log
[14:39:46 CEST] <DeHackEd> without the log, I would assume you're missing some host static libraries, like zlib or openssl or something like that
[14:40:28 CEST] <alfonsodev> thanks, I'll fire up a instance now to try again and read the log
[14:40:54 CEST] <furq> the configure output errors generally aren't much use without the log
[14:41:10 CEST] <furq> that one in particular
[14:42:23 CEST] <furq> why do you want a static binary anyway
[14:43:59 CEST] <alfonsodev> Yeah, actually after last night conversation I don't need it anymore, by not using fdk_aac I can use one of the static binaries out there
[14:44:26 CEST] <alfonsodev> But I'm curious about the problem I still want to be able to compile it myself :)
[14:44:33 CEST] <furq> i meant instead of a shared binary
[14:45:13 CEST] <furq> that command will still dynamically link against glibc, so you can't reliably move the binary between boxes unless they have the same glibc and kernel version
[14:45:42 CEST] <DeHackEd> I prefer a shared binary but with a static link of libav*, libx264, etc. get the host's libraries but be able to copy ffmpeg to another system and get all the codecs go with it
[14:46:41 CEST] <furq> it's less hassle to just build a shared library unless you have a lot of boxes with the exact same distro version
[14:46:54 CEST] <furq> s/library/binary/
[14:47:43 CEST] <DeHackEd> true, but I think it's best to keep the number of shared libraries to a core minimum. glibc, zlib, openssl, things like that
[14:48:03 CEST] <alfonsodev> In my use case is for a specific kernel that amazon uses in lambda functions , so I need to upload the binary to that environment every time I deploy a change to the function
[14:48:36 CEST] <furq> that sounds fun
[14:49:20 CEST] <furq> well in that case you probably want to add --static to --extra-ldflags
[14:51:59 CEST] <DeHackEd> he did
[14:52:02 CEST] <DeHackEd> also single dash for gcc
[14:52:50 CEST] <furq> oh right it's there in the stackoverflow question
[15:17:33 CEST] <alfonsodev> here is my config.log http://pastebin.com/vQ5g2MDU
[15:17:59 CEST] <alfonsodev> aparently is an error at the end "cannot find -ldl"
[15:18:06 CEST] <furq> yeah that's a worry
[15:18:10 CEST] <alfonsodev> apparently is an error at the end "cannot find -ldl"
[15:18:23 CEST] <RalphORama> Hello everyone! I'm looking for some help with using ffmpeg to capture a fullscreen application
[15:18:51 CEST] <RalphORama> I've followed the guide for streaming one's desktop, but it doesn't work with the program I'm using (snes9x)
[15:18:52 CEST] <furq> alfonsodev: i guess you don't have libdl.a
[15:19:11 CEST] <RalphORama> Here's the script that I've written for attempting to stream the video: https://glot.io/snippets/ef2jfdazps
[15:19:32 CEST] <Amitari> Does anyone know how to use ANIM-to-GIF conversion? When I type "ffmpeg -i anim.anim5 gif.gif" I only get the first frame of the animation.
[15:20:38 CEST] <RalphORama> Actually, sorry. Didn't see the note about pastebin. Here's my config: http://pastebin.com/DsAkL9sD
[15:21:01 CEST] <furq> RalphORama: it probably doesn't work because snes9x is using opengl
[15:21:33 CEST] <furq> https://github.com/lano1106/glcs
[15:21:37 CEST] <furq> google suggests that, i can't say i've ever used it
[15:22:02 CEST] <RalphORama> furq: I don't know if that's the case - I'm using a Raspberry Pi model 2b running Raspbian
[15:22:09 CEST] <RalphORama> I'll double check
[15:22:16 CEST] <furq> you might be able to disable opengl in snes9x
[15:23:40 CEST] <RalphORama> I'll give it a shot, thank you!
[15:38:53 CEST] <alfonsodev> @furq I've installed libdl , now I get this http://pastebin.com/k4PPq593
[15:40:43 CEST] <alfonsodev> I think it's too much for me, I'm about to give up,  unless anybody here could give a hint,  thanks anyway :)
[15:41:00 CEST] <DeHackEd> I can't help but feel it got cut off...
[15:41:26 CEST] <DeHackEd> hmm maybe not.
[15:41:33 CEST] <iive> dl stands for dynamic loader
[15:42:03 CEST] <iive> so... it's the library that is used for loading other libraries. if you do static build...
[15:42:45 CEST] <DeHackEd> what are you doing that needs libdl? the only thing I know is libx264's opencl support
[15:42:50 CEST] <furq> oh yeah that's a good point
[15:43:03 CEST] <furq> i figured ffmpeg was adding that automatically but you're supplying it to --extra-libs
[15:43:34 CEST] <furq> also yeah if you're going to paste config.log just paste the last 100 lines or so
[15:44:00 CEST] <alfonsodev> hehe, yeah 8K lines it's crazy
[15:44:09 CEST] <furq> firefox doesn't seem to care for 13,000 line pastes on pastebin
[15:44:19 CEST] <DeHackEd> leaves chrome lukewarm as well
[15:56:03 CEST] <alfonsodev> I removed --extra-libs=-ldl , and I get this http://pastebin.com/9QYvfEGg
[15:56:39 CEST] <alfonsodev> The command ends with "config.asm is unchanged    libavutil/avconfig.h is unchanged"
[16:00:58 CEST] <DeHackEd> but configure appeared to work?
[16:04:46 CEST] <furq> yeah that looks fine
[16:05:16 CEST] <furq> you might need to run make distclean before rerunning configure
[16:06:03 CEST] <emitchell> sup
[16:22:49 CEST] <flux> I'm converting a video.mp4 to video-low-quality.mp4 with ffmpeg -i video.mp4 -vcodec libx264 -crf 30 video-low-quality.mp4, but I would like the time stamps to stay exactly the same
[16:23:08 CEST] <flux> however, MP4Box says the first video stars at composition time 512, whereas the resulting video starts at 1024
[16:23:19 CEST] <flux> is there some trick to this?-o
[16:24:02 CEST] <DeHackEd> there's a few options that affect timestamping. You might need to experiment, but there's -copyts, -copytb and -vsync sometimes helps with mucking with timestamps (see the manuals for all options, their parameters vary)
[16:24:15 CEST] <JEEB> flux: I recommend taking a look at the timestamps with L-SMASH's boxdumper
[16:24:21 CEST] <JEEB> the value changes might not mean what you think they do
[16:24:37 CEST] <flux> that's a good point, I should also look at composition offset
[16:25:20 CEST] <JEEB> basically L-SMASH's can either dump a text representation of all (most of) the container values, or just CTS/DTS values calculated from those
[16:25:24 CEST] <JEEB> depending on the mode
[16:28:32 CEST] <flux> EditListBox/../@MediaTime apparently ends up different in the converted video. I think however they should be the same? I'll try the -copyts switch first, I can't believeI missed it :-o.
[16:29:34 CEST] <JEEB> uhh
[16:30:04 CEST] <JEEB> you're most probably not going to get the same as the copyts switch only sets API level timestamps
[16:30:11 CEST] <JEEB> the timestamps then travel from the API to the muxer
[16:30:30 CEST] <JEEB> you shouldn't expect bitexact remuxes in that sense. The results should be correct, of course
[16:30:31 CEST] <flux> I recall it assigns the headers by the perceived first frame time stamp, no?
[16:31:06 CEST] <flux> the documentation on -copyts suggests the conversion by default ignores the composition timestamp of the first frame
[16:31:41 CEST] <JEEB> no
[16:32:01 CEST] <JEEB> copyts is a generic option and has nothing to do with movenc specifically
[16:32:10 CEST] <flux> "In particular, do not remove the initial start time offset value." ?-o
[16:32:18 CEST] <JEEB> that's not specific to mov
[16:32:28 CEST] <flux> does it really need to be specific to mov..
[16:32:42 CEST] <JEEB> what you're referring to is in the mov/ISOBMFF context
[16:32:55 CEST] <JEEB> which this stuff doesn't speak about, rather it speaks about the API value
[16:33:06 CEST] <JEEB> which comes from the demuxer
[16:33:09 CEST] <vade> ive ported my decoding and encoding code to use send / recieve packet/ frame API alongside codecpar via the latest public GIT - my decode works fine - however, encode gets silence and black frames. Im creating my own CodecContext for audio and video as per the new codecpar spec - do I need to do  anything to my destination Streams CodecContext? Why might I be getting black frames when my old path via encode calls worked?
[16:34:42 CEST] <vade> previously Id use my avstreams -> codec to do encoding with
[16:41:03 CEST] <vade> (ie open it, etc, pass it to encode) - however since I cant access it, I create a context from my streams set up codecparameters as suggested. I appear to be encoding packets correctly from what I can tell. My source frames data[] is populated, has the correct dims, and my packets also appear to have encoded data as well
[16:41:29 CEST] <vade> I dont have errors on muxing either, but, I get nada on output :X
[16:41:45 CEST] <vade> and OS Xs AVFoundation based player spews TONS of video decode errors ive not seen either
[16:42:17 CEST] <vade> (decode errors trying to play my resulting file) - im curious if anyone is using codecpar path successfully
[17:06:38 CEST] <drazin> Hi everyone, i've been using a script to auto convert some multi audio track mkv files to mp4 which is adding a new aac 2.0 track and the issue i'm getting is that apple tv and ios devices are saying they are hearing both the aac 2.0 and the original ac3 5.1 track being played at the same time.  i did some digging and the script creator is saying "This is an
[17:06:38 CEST] <drazin> unfortunate limitation of FFMPEG. There's no way to set a track as enabled and others as disabled. Its annoying and the only way around it at this time is to patch FFMPEG. The issue with the script is documented here: https://github.com/mdhiggins/sickbeard_mp4_automator/issues/360 has this been fixed or is there some way to fix this issue?
[17:12:06 CEST] <DeHackEd> you can select which tracks to import. Use ffprobe or the output of ffmpeg to read which tracks are available, then select what you want with "-map 0:0 -map 0:2"
[17:12:43 CEST] <drazin> i want all the tracks and the newly created 2.0 mixdown
[17:14:35 CEST] <drazin> ive sent a note to the dev about adding that -map to the script but i havent heard back
[17:14:40 CEST] <drazin> wanted to make sure thats a solution
[17:15:13 CEST] <DeHackEd> it means that one of the audio tracks will be dropped during processing
[17:19:13 CEST] <drazin> so i cant keep them all and select the new 2.0 as the default?
[17:19:17 CEST] <drazin> and the other to off?
[17:19:42 CEST] <furq> doesn't the aac track need to be first on iOS
[17:20:01 CEST] <drazin> it is being added as first
[17:20:06 CEST] <furq> nvm then
[17:20:28 CEST] <drazin> but apparently they are all on by default which is why i'm hearing them all at once
[17:20:43 CEST] <drazin> if i manually select the ac3 5.1 the echoing stops
[17:39:59 CEST] <Threads> is -re recursive because i cant find much on it in the wiki
[17:40:35 CEST] <c_14> https://ffmpeg.org/ffmpeg.html#Advanced-options
[17:42:21 CEST] <Threads> c_14 thanks for that link bookmarked it
[17:56:33 CEST] <drazin> aahh https://trac.ffmpeg.org/ticket/3622#comment:19
[17:56:39 CEST] <drazin> looks like it wont be fixed
[17:57:44 CEST] <ritsuka> drazin: if you want only a track playing you need to set an alternate group, and enable one of the two tracks. iOS will select the one it prefers based on your current locale/accessibility settings.
[17:58:05 CEST] <ritsuka> Obviously I have no idea how to set the alternate group with ffmpeg ;)
[17:58:09 CEST] <drazin> how do i go about that
[18:00:34 CEST] <drazin> who discussion about this here: https://forums.plex.tv/discussion/comment/1103854#Comment_1103854
[18:30:52 CEST] <vade> hi rkern - thanks for joining here. Anything I can look at specifically in my app to debug h264_videotoolbox vs lib x264 and why it might not be working?
[18:33:06 CEST] <rkern> Is avcodec_receive_packet() returning an error?
[18:34:38 CEST] <vade> I get Resource temporarily unavailable which as I understand it is the encoder warming up. I get that for a few input frames and then it goes away
[18:34:50 CEST] <vade> ie, the encoder delayed frames accruing
[18:36:20 CEST] <rkern> That's normal. Do you get frames after that?
[18:36:30 CEST] <rkern> sorry - packets?
[18:36:52 CEST] <vade> yup, I do
[18:38:08 CEST] <vade> my frames are 1920x1080, and I get resulting packets size 3754, no side data, but the pts and dts is marked, and buf appears filled
[18:38:27 CEST] <vade> interestingly buff size is larger, at 3786
[18:38:48 CEST] <vade> unsure why there is a size delta, or if thats expected
[18:39:05 CEST] <rkern> Yeah, there's extra padding. It's ok.
[18:39:27 CEST] <rkern> Maybe I don't understand the issue then. What's going wrong?
[18:40:07 CEST] <vade> well, I get only black frames on output when my file is finished / muxed and I complete writing when I playback.
[18:40:29 CEST] <vade> when I playback, I throw errors in console from QUicktime Player
[18:41:06 CEST] <vade> H264VideoDecoder_DecodeFrame signalled err=-12910 (err) (createJVTLibInstance failed) at /Library/Caches/com.apple.xbs/Sources/CoreMedia_frameworks/CoreMedia-1731.15.202/Sources/VideoCodecs/H264/H264VideoDecoder.c line 2477
[18:41:19 CEST] <vade> however the muxed files audio plays back fine
[18:41:29 CEST] <vade> so something is up with the samples being written
[18:43:12 CEST] <vade> interestingly, thats a video toolbox error - kVTVideoDecoderUnsupportedDataFormatErr
[18:43:32 CEST] <vade> so the encoded samples / packets I write to the muxer, from VIdeoToolbox, itself wont play
[18:43:47 CEST] <rkern> Ah, I think I see the issue. AVCodecContext.extradata isn't set until the first frame is received. This is ok for some muxers, but since AVCodecParameters is copied before this, the muxer never gets this info.
[18:44:27 CEST] <rkern> I assume you're muxing to mp4 or mov?
[18:44:31 CEST] <vade> yup :)
[18:44:34 CEST] <vade> mp4
[18:47:16 CEST] <vade> rkern: is that something I should mark as a bug ?
[18:47:25 CEST] <rkern> yes
[18:48:19 CEST] <rkern> I'll see if the extradata can be set when the codec is opened. As a temp work-around, you could try manually setting extradata and extradata_size in codecpar when you receive the first packet.
[18:49:14 CEST] <vade> ah ok. so when I get the first packet encoded, check if codecpar on my video output stream has extra data / size set, if not, set it to the packets info?
[18:50:23 CEST] <vade> oh. not the packets info, my codec context. my bad
[18:50:43 CEST] <rkern> right - copy over extradata and extradata_size
[18:50:53 CEST] <vade> trying now. Thank you so much for the info
[18:51:21 CEST] <vade> works
[18:51:28 CEST] <vade> ^^^^^^ youre awesome rkern
[18:51:32 CEST] <vade> I really appreciate your help
[18:52:08 CEST] <rkern> haha nice - please submit a bug anyway and I'll work on the underlying issue.
[18:52:19 CEST] <vade> will do. thanks again x 1000
[19:47:55 CEST] <somebody_useless> Has anyone successfully been able to record an input stream that would satisfy the developers for troubleshooting? If so, how?
[19:50:15 CEST] <DeHackEd> depends on the media. what's the source?
[19:53:10 CEST] <somebody_useless> DeHackEd, MPTS
[19:53:23 CEST] <DeHackEd> like, on an OTA receiver?
[19:53:38 CEST] <somebody_useless> MPTS stream coming in from a satellite receiver, which is being transcoded from mpeg2ts to mpeg4ts
[19:54:03 CEST] <DeHackEd> so, multicast ethernet?
[19:54:08 CEST] <somebody_useless> yessir
[19:54:09 CEST] <DeHackEd> ASI?
[19:54:13 CEST] <somebody_useless> ethernet
[19:54:17 CEST] <somebody_useless> via multicast
[19:55:36 CEST] <vade> hi rkern - ive made a trac ticket for the issue you helped debug - as requested : https://trac.ffmpeg.org/ticket/5593
[19:55:43 CEST] <vade> thanks again! :)
[19:56:24 CEST] <somebody_useless> I work for a small ISP and we are trying to deliver IPTV and the hurdle we've come across is with ffmpeg bugging out due to either audio codec problems (likely a compilation issue) but more specifically due to "Lost audio" on the channels; ffprobe says audio is being interlaced with the output stream, however ffmpeg complains about the audio offset being incorrect.
[19:56:25 CEST] <somebody_useless> I'm trying to supply a source stream because the program output doesn't suffice (completely understandable)
[19:57:01 CEST] <josh98> what is the most secure source of ffmpeg other than linux repo?
[19:57:14 CEST] <somebody_useless> It's weird because sometimes ffmpeg is able to correct it, other times it just hops around for hours on end trying fix the problem
[19:57:35 CEST] <somebody_useless> josh98, git assuming your ssl cert store hasn't been compromised?
[19:57:46 CEST] <somebody_useless> josh98, sneakernet ftw
[19:58:02 CEST] <somebody_useless> You only have to have utmost trust in one person ;)
[19:58:53 CEST] <josh98> well i did ask
[19:59:46 CEST] <somebody_useless> josh98, if you live in a region covered by area code 204, I might be able to help you out :)
[19:59:56 CEST] <josh98> aside from sneakernet
[20:00:06 CEST] <josh98> and assuming my ssl cert store hasn't been compromised
[20:00:32 CEST] <somebody_useless> josh98, third part repos aren't the best, use GIT (as ffmpeg suggests), run bleeding edge
[20:01:08 CEST] <somebody_useless> ffmpeg also provides prebuilt packages if you're interested in getting them that way
[20:01:17 CEST] <josh98> are you recommending that i pull it from hit.ffmpeg.org?
[20:01:20 CEST] <josh98> git
[20:01:28 CEST] <somebody_useless> yes, that's what ffmpeg recommends
[20:01:56 CEST] <josh98> as for the ssl cert store, pffft
[20:02:15 CEST] <somebody_useless> not necessarily the most secure (I don't think git uses ssl), but it does guarantee a level of security via diffs
[20:02:18 CEST] <somebody_useless> (hashlog, etc)
[20:03:32 CEST] <josh98> https://ffmpeg.org/download/html#get-sources
[20:04:06 CEST] <josh98> says source can be retrieved through git using https
[20:06:16 CEST] <josh98> ssl cert courtesy of CNIC
[20:08:53 CEST] <somebody_useless> perfect
[20:08:58 CEST] <somebody_useless> good thing it's not CNIB
[20:10:23 CEST] <josh98> sourceforge recommends using CPWN
[20:14:30 CEST] <Admin__> hey guys... loooking for some help... so my source is an mpetgs stream and it has closed captions in the video PID ... i pipe it to a hardware transcoder and then back out to ffmpeg to segment. It seems that my closed caption data is missing :( .. when i look at the source direct its there.. anyone know some way to pull out the closed caption before pipping it to hardware encoder ( nvidia ) , and then it is kept and sent to the final stage for
[20:14:30 CEST] <Admin__> segmenting and readding ?
[20:50:47 CEST] <DeHackEd> somebody_useless: I'm trying something similar, but with an ATSC to ethernet converter
[20:53:03 CEST] <somebody_useless> DeHackEd, we have a few OTA systems, but we're moving away from it because it's super old and unreliable tech.
[20:53:35 CEST] <somebody_useless> ATSC via OTA
[21:12:16 CEST] <Admin__> hey guys... loooking for some help... so my source is an mpetgs stream and it has closed captions in the video PID ... i pipe it to a hardware transcoder and then back out to ffmpeg to segment. It seems that my closed caption data is missing :( .. when i look at the source direct its there.. anyone know some way to pull out the closed caption before pipping it to hardware encoder ( nvidia ) , and then it is kept and sent to the final stage for
[21:12:29 CEST] <Admin__> anyone know how i can extract the closed caption from the video ?
[21:19:24 CEST] <DeHackEd> but it copies properly? (-c:v copy)
[22:34:06 CEST] <antgeth>  i have some raw aac audio that i'd like to wrap up as m4a, but the internet is not being terribly clear on how to do it
[22:34:13 CEST] <antgeth> getting some conflicting advice
[22:34:23 CEST] <c_14> ffmpeg -i aac -c copy out.m4a
[22:35:48 CEST] <antgeth> ohhhhhhhh, i think it was the -c switch that i hadn't seen in any of the suggestions
[22:35:53 CEST] <antgeth> danke!
[22:38:10 CEST] <antgeth> hmm
[22:38:18 CEST] <antgeth> itunes is refusing to deal with it
[22:38:37 CEST] <c_14> does it give an error?
[22:38:50 CEST] <JEEB> while recording? yes because unless you're using movie fragments there's no index
[22:39:10 CEST] <JEEB> and not sure if QT/iTunes supports fragmented ISOBMFF
[22:39:45 CEST] <antgeth> no error, i add it to the library and it just doesn't appear
[22:40:13 CEST] <allquixotic_> Hi, does anyone know if ffmpeg has support for H264 encoding using Intel QSV (I guess through VideoToolbox?) on Mac OS X?
[22:40:26 CEST] <antgeth> also quicktime reports the bitrate as 0
[22:40:41 CEST] <antgeth> (it does give the correct length, at least)
[22:42:05 CEST] <rkern> allquixotic_: there's a videotoolbox encoder wrapper in master - not in a release yet.
[22:50:12 CEST] <allquixotic_> rkern: Thanks!
[22:50:22 CEST] <wallbroken> hi
[22:50:27 CEST] <wallbroken>  -vf "transpose=1,scale=576:-2" -metadata:s:v rotate="" -c:a copy output.mov
[22:50:48 CEST] <wallbroken> ops
[22:51:18 CEST] <wallbroken> ffmpeg.exe -i "Video.mov"  -vf "transpose=1" -metadata:s:v rotate="" -c:a copy output.mov
[22:51:27 CEST] <wallbroken> the original video is 400 kb
[22:51:34 CEST] <wallbroken> the output video is 130 kb
[22:51:41 CEST] <wallbroken> i think something is unclear
[22:51:44 CEST] <c_14> you're reencoding it
[22:51:50 CEST] <c_14> that happens
[22:51:55 CEST] <wallbroken> yes i know
[22:51:58 CEST] <c_14> adjust the encoder settings to your liking
[22:52:20 CEST] <wallbroken> but i have an app on my iphone that rotates, and the output is 350 kb
[22:52:22 CEST] <wallbroken> not 150
[22:52:39 CEST] <c_14> maybe it uses different settings
[22:52:53 CEST] <wallbroken> it keeps more quality?
[22:53:14 CEST] <c_14> maybe
[22:53:27 CEST] <c_14> it has more bits, that's about all bitrate really tells you
[22:53:47 CEST] <c_14> assuming it uses the same codec/encoder then it's probably better quality
[22:53:53 CEST] <c_14> assuming they don't fuck things up
[22:54:03 CEST] <wallbroken> it could be that an iOS app uses ffmpeg?
[22:54:18 CEST] <c_14> it's possible
[22:54:27 CEST] <wallbroken> due to licence agreement?
[22:54:38 CEST] <wallbroken> nothing wrong with it?
[22:54:55 CEST] <c_14> as long as they adhere to the (L)GPL there's nothing wrong with it
[22:58:23 CEST] <wallbroken> that app has an option called "optimize for network use" it will start playing after only a small portion of the filehas been downloaded from the network
[22:58:35 CEST] <wallbroken> is something belonging to ffmpeg?
[22:58:54 CEST] <c_14> If it's an mp4, that's just moving the MOOV atom to the front
[22:59:34 CEST] <wallbroken> it lets me choose the container, this function only work with mp4 ?
[22:59:42 CEST] <wallbroken> i can also choose ".mov"
[23:00:00 CEST] <c_14> afaik no other container needs it
[23:00:03 CEST] <c_14> mov is basically mp4
[23:00:28 CEST] <wallbroken> ok and ffmpeg supports that thing?
[23:00:31 CEST] <furq> wallbroken: -movflags +faststart
[23:00:46 CEST] <wallbroken> by default is not enabled?
[23:00:49 CEST] <furq> no
[23:01:19 CEST] <wallbroken> ok
[23:01:38 CEST] <furq> if you want the output video to be higher quality then set -crf to a value below 23
[23:02:52 CEST] <wallbroken> yes i've used it with h264
[23:02:54 CEST] <wallbroken> do you know?
[23:03:30 CEST] <wallbroken> there was also a flag which set the encoding method. from -fast , to -placebo
[23:03:39 CEST] <wallbroken> -placebo was the slowest
[23:03:46 CEST] <furq> -preset
[23:03:49 CEST] <wallbroken> yes
[23:04:03 CEST] <furq> the default is -preset medium which is probably fine
[23:04:31 CEST] <wallbroken> placebo in my case was 3 days long
[23:04:39 CEST] <wallbroken> on 2 hours video
[23:04:40 CEST] <furq> it's called placebo for a reason
[23:04:43 CEST] <c_14> don't use placebo
[23:04:51 CEST] <c_14> It's *shock* a placebo
[23:05:16 CEST] <furq> don't use anything slower than slow unless you know your source will benefit from it
[23:05:32 CEST] <wallbroken> i was using x264vfw, a codec for windows that it's not very good
[23:05:45 CEST] <furq> you could have stopped writing that sentence after "windows"
[23:06:21 CEST] <furq> although i don't remember x264vfw being any slower than ffmpeg
[23:06:25 CEST] <furq> it's been ages though
[23:07:08 CEST] <wallbroken> now x265 soppressed x264 ?
[23:07:16 CEST] <furq> not really
[23:07:37 CEST] <furq> hevc isn't very widely-supported yet and also x265 is still incredibly slow if you want it to be noticeably better than x264
[23:08:22 CEST] <wallbroken> the problem is that i got a video, and i need to get the best possible quality i can
[23:08:39 CEST] <furq> use x264 with a low crf value
[23:09:12 CEST] <c_14> -qp 0 (with libx264)
[23:09:14 CEST] <furq> i very much doubt anyone can see any quality improvements below -crf 16
[23:09:16 CEST] <c_14> that's as good as it'll get
[23:09:27 CEST] <furq> if you want "the best possible quality" then yeah use -qp 0 but the video will be enormous
[23:09:39 CEST] <furq> that's only really of use if you want to process the video further
[23:11:17 CEST] <wallbroken> between setting rotation tag and reencoding, which one will you suggest?
[23:11:38 CEST] <furq> set the rotation tag if your player supports it
[23:12:13 CEST] <wallbroken> those who supports it are too much?
[23:12:32 CEST] <wallbroken> i use vlc and does it
[23:12:44 CEST] <wallbroken> but i need to give the video to some people
[23:12:54 CEST] <wallbroken> and i don't know which player are using
[23:17:03 CEST] <llogan> then you'll have to rotate and re-encode
[23:17:28 CEST] <llogan> ffmpeg will automatically rotate based on rotate metadata/sidedata
[23:17:44 CEST] <llogan> se -noautorotate option
[23:17:58 CEST] <llogan> *see
[23:18:17 CEST] <llogan> ...for more info
[23:57:32 CEST] <wallbroken> if i only want to change rotation tag keeping all the same?
[00:00:00 CEST] --- Sat May 28 2016