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

[burek]

[00:22:28 CEST] <stigma> hey furq, hand pm
[04:10:20 CEST] <Kris_> Hello everybody. It's my first time here... After several days of intense googling, I can't find a solution for my problem: I cant get ffplay to play files using a full 0-255 dynamic range. The black levels seem off and washed-out with every single video file and format that I've tried. What can I do?
[04:16:33 CEST] <kepstin> Kris_: ffplay's video renderer is... iffy. Use a real video player? mpv's opengl output is known to be quite good.
[04:20:41 CEST] <Kris_> I'm using ffplay to play a local rtmp stream, it's by far the best option for low latency. But alas, I have this problem.
[04:31:44 CEST] <kevr> Hello.
[04:33:01 CEST] <kevr> I'm trying to convert a frame n to it's timestamp in a video stream, how should i go about doing this? at the moment, i get unreliable results [i'm just doing stream->duration / (stream->r_avg_frame_rate.num / stream->r_avg_frame_rate.den)]
[04:33:15 CEST] <kevr> I'm doing this in C, by the way, so AV_TIME_BASE is available and whatnot
[04:46:36 CEST] <kepstin> kevr: there's no way to do that in general for all file formats, since there might be variable frame rate
[04:46:43 CEST] <kepstin> and files are indexed by time, not frame count
[04:47:15 CEST] <kepstin> so the only reliable way to get a timestamp for a particular frame no. is demux the video, counting frames, and then get the pts value :/
[04:53:24 CEST] <kepstin> if and only if the stream timebase is 1 over framerate, and each frame has a pts monotonically incrementing by 1, then the frame timestamp is (frameno * timebase).
[04:54:17 CEST] <kepstin> but that's a pretty big iff, and it'll never be true for e.g. mkv
[05:00:07 CEST] <kepstin> if this is something you're doing a lot of (why?) you'd want to just go through the file once and build a mapping table of frameno’pts and save it somewhere :/
[06:09:12 CEST] <kynlem> hey
[06:10:57 CEST] <kynlem>  ffmpeg -i source.mp4 -acodec copy -vcodec copy -map 0 output.mp4 &>/dev/null
[06:11:57 CEST] <kynlem> why am i getting an output.mp4 file that is smaller than the source?
[06:12:13 CEST] <kynlem> (56mb vs 62mb)
[06:14:59 CEST] <kynlem> and i if i do it on a bigger file, the difference increases proportionally
[08:14:59 CEST] <jswagner> hi, trying to merge three mpeg files into a single file.  'ffmpeg -f concat -i input.txt -c copy output.mp4' produces almost exactly what i want
[08:15:51 CEST] <jswagner> ffmpeg seems begin reading file2 at the timestamp where file1 ends
[08:16:04 CEST] <jswagner> but doesn't do this for file 3
[08:16:06 CEST] <jswagner> so for example
[08:16:28 CEST] <jswagner> file1 = 50 seconds, file2 = 45min, file3 = 45min
[08:16:59 CEST] <jswagner> ffmpeg includes file1 from 00:00 to 00:50, file2 from 00:50 to 45:00 and file3 from 00:00 to 45:00
[08:17:20 CEST] <jswagner> expected result: ffmpeg includes file1 from 00:00 to 00:50, file2 from 00:00 to 45:00 and file3 from 00:00 to 45:00
[08:17:53 CEST] <jswagner> this is with ffmpeg version N-81664-g6f062eb (Windows build)
[08:23:13 CEST] <jswagner> i get a slightly different result on each attempt
[08:23:25 CEST] <jswagner> but ultimately same behavior on ffmpeg version 3.1.3 on arch linux
[10:40:51 CEST] <aiju> how do you set the format for image2?
[10:40:53 CEST] <aiju> i want to output to a pipe
[10:40:59 CEST] <aiju> it seems to default to jpg, but i want png instead.
[10:48:55 CEST] <relaxed> aiju: ffmpeg -i input -c:v png -f image2pipe -
[10:50:00 CEST] <aiju> thanks
[14:40:11 CEST] <soulshock1> anyone successfully used BlackMagic DeckLink cards in Linux with ffmpeg?
[14:40:38 CEST] <soulshock1> ffmpeg doesn't detect my UltraStudio SDI card
[14:41:03 CEST] <soulshock1> to be fair neither does the BlackMagic software
[14:41:55 CEST] <BtbN> have you tried running ffmpeg as root?
[14:42:14 CEST] <BtbN> if that works, fix your device permissions
[14:42:21 CEST] <soulshock1> interesting idea
[14:42:40 CEST] <soulshock1> unfortunately no dice
[14:43:06 CEST] <BtbN> you are on the latest drivers/SDK?
[14:44:14 CEST] <strixUK> hi; i want to dynamically add text to h.264 video in a semi-realtime way (i'm assuming that this is impossible within the timeframe of an HTTP request, but processing time in the order of 5 minutes would be okay).  how should i go about doing this?
[14:44:33 CEST] <strixUK> a subtitle overlay (which i assume is a separately muxed stream) or is there some way i can add the text to the video stream itself without transcoding it (for different quality)?
[14:45:51 CEST] <soulshock1> I'm unsure how to actually load the drivers. do I need to use modprobe or will it load them automatically once installed
[14:46:06 CEST] <strixUK> (technically, modifying the video in any way is probably transcoding, but hopefully there's a way of statically changing pixels, presumably on every I frame, without messing with the unaffected pixels)
[14:54:31 CEST] <strixUK> perhaps a better way to phrase my question: what is the least computationally expensive way to add a watermark to a video?  don't need to transcode for quality, just add a static watermark.
[14:57:19 CEST] <DHE> strixUK: not really. the only low-CPU way is to add a subtitle stream but there's no guarantee of them being rendered
[14:57:35 CEST] <strixUK> that's what i thought
[14:57:45 CEST] <strixUK> or rather, feared
[14:57:47 CEST] <strixUK> dhe- thanks for confirming
[14:57:57 CEST] <DHE> and if you modify only the I-frames, all that will happen is they'll be promptly smudged and skewed as the next frames apply motion compensation
[14:58:10 CEST] <strixUK> oh, that makes sense
[14:58:28 CEST] <strixUK> i've seen similar effects on DVB when an I frame is dropped
[14:59:34 CEST] <strixUK> do subtitles support alpha blending?  i assume not, so the only way to do a true watermark is to rerender the video stream, is that right?
[15:00:20 CEST] <strixUK> in which case, how do i tell ffmpeg to maintain the same quality settings as the input, or will it do that automatically if the input and output codecs are the same?
[15:41:42 CEST] <qxt> I used an old firewire 1394 card to pull in some Video8 files. ffprobe gives me an aspect of Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3]. Thing is when I use ffmped to compress them I get an aspect of 4:5. What am I missing?
[15:46:22 CEST] <qxt> I am piping the output of a VapourSynth script into ffmpeg then mapping the audio 1:1 to mux in sound.
[15:46:33 CEST] <qxt> C:\VideoStuff\VS\VSPipe.exe -y C:\VideoStuff\VS\Project.vpy - | C:\VideoStuff\ffmpeg.exe -i - -i C:\VideoStuff\clip.avi -c:v utvideo -c:a copy -map 0:0 -map 1:1 PLEASE.mkv -y
[15:47:26 CEST] <qxt> utvideo should not be doing anything to the aspect I would think.
[15:48:24 CEST] <JEEB> check the ffprobe output of the output file
[15:52:14 CEST] <qxt> Hi JEEB (same jeeb from years ago? Finland/Japan guy?) This is the output  Video: utvideo (ULY0 / 0x30594C55), yuv420p(bt470bg/unknown/unknown), 720x576, 100116 kb/s, 50 fps, 50 tbr, 50 tbn
[15:52:29 CEST] <JEEB> yes, same guy
[15:52:50 CEST] <JEEB> right
[15:52:50 CEST] <qxt> hi Dang you been at this for a while =)
[15:53:07 CEST] <JEEB> basically I guess y4m doesn't have aspect ratio headers
[15:53:09 CEST] <qxt> mediainfo says 4:5
[15:53:10 CEST] <JEEB> or they weren't exported
[15:53:46 CEST] <qxt> So just att a --y4m then?
[15:53:56 CEST] <qxt> blah add a --y4m then?
[15:54:13 CEST] <JEEB> also the 5:4 comes from the video resolution
[15:54:13 CEST] <JEEB> >>> Fraction(720/576)
[15:54:13 CEST] <JEEB> Fraction(5, 4)
[15:54:45 CEST] <JEEB> check the ffmpeg log
[15:54:52 CEST] <JEEB> it should tell you if it is getting in aspect ratio flags or not
[15:54:52 CEST] <kdehl> Greetings, friends.
[15:55:10 CEST] <qxt> yeah not seeing a flag in there...
[15:55:16 CEST] <JEEB> the "Input #0" part basically
[15:55:27 CEST] <JEEB> ok, if it doesn't have aspect ratio there then it isn't passed from vspipe forwards
[15:55:49 CEST] <qxt> yep that seems to be the issue looking at it now
[15:56:23 CEST] <qxt> thx JEEB for the tip.
[15:56:27 CEST] <JEEB> I don't remember if there was another way of doing setsar/setdar that's not the video filter
[15:56:49 CEST] <JEEB> you're encoding so -vf setsar or -vf setdar with the correct params should work
[15:57:15 CEST] <JEEB> oh, y4m can have aspect ratio
[15:57:27 CEST] <JEEB> you can dump some of it and see if it is there https://wiki.multimedia.cx/index.php?title=YUV4MPEG2
[15:58:10 CEST] <kdehl> I have a question about H.264, and maybe specifically OpenH264. When I encode a test video, it gets displaced diagonally once every few (depends on the bitrate setting, I believe, 4 in this case) frames.
[15:58:11 CEST] <ehsan> Hi I'm trying to run ffmpeg on AWS Lambda but it seems that it crashes in the middle of the process. can anyone help me with it?
[15:58:19 CEST] <kdehl> http://dose.se/~madman/openh264/stefan004.png
[15:58:25 CEST] <kdehl> That's my fourth frame.
[15:58:39 CEST] <kdehl> All the others can be found here: http://dose.se/~madman/openh264/
[16:01:03 CEST] <kdehl>  nonex86: You here? :)
[16:01:38 CEST] <kdehl> Weird, it looks as if the colors are out of sync.
[16:03:26 CEST] <ozette> any idea why a client media player in chrome, may request the same byte range over and over again when trying to skip through the video during playback?
[16:04:22 CEST] <ozette> the media player breaks with the message a network error caused the media download to fail part-way"
[16:04:33 CEST] <jkqxz> kdehl:  What is the input for that?  Does it happen if you encode the input directly to something else?  (To png images, for example.)
[16:06:42 CEST] <kdehl> jkqxz: To be honest, I have written a program that uses a codec (OpenH264), and it encodes it just fine, but when I go through my company's crap code (based on Java's Media Framework!), it gets messed up for some input files.
[16:07:11 CEST] <kdehl> jkqxz: I just wondered if you could see directly on that frame what it is that gets messed up, the color format, or the resolution or something.
[16:07:27 CEST] <kdehl> I just don't know where to begin.
[16:09:14 CEST] <jkqxz> The data is just offset somehow, and the residual part of the luma plane has been encoded as a chroma plane.  It looks like the top of the luma plane might be a chroma plane, though possibly of a different frame.
[16:09:44 CEST] <kdehl> Wow that is weird.
[16:09:48 CEST] <jkqxz> It seems more likely to be a decoder problem, which was why I was asking what the source is and whether it happens with other outputs.
[16:11:04 CEST] <kdehl> It does not happen with all input files. I use a short 10-frame static YUV file as input, and it works just fine, but if I use a larger input file, like that Stefan Edberg clip, I get this problem.
[16:12:57 CEST] <nonex86> kdehl: now i am :)
[16:13:03 CEST] <nonex86> kdehl: hey
[16:14:17 CEST] <kdehl> nonex86: Hey. :)
[16:14:28 CEST] <kdehl> nonex86: Everything's good in Moscow?
[16:14:40 CEST] <nonex86> kdehl: stable and rainy :)
[16:15:05 CEST] <kdehl> nonex86: Ah the stereotype!
[16:15:06 CEST] <kdehl> :)
[16:15:29 CEST] <nonex86> kdehl: but no drunk bears on streets :( :)
[16:16:04 CEST] <nonex86> kdehl: that screenshot - stefan004.png, how did you get it?
[16:16:25 CEST] <nonex86> kdehl: i mean - full cycle - encode with openh264 than decode with openh264?
[16:18:31 CEST] <qxt> JEEB, So something like -vf setdar=5:4 should be what I am looking for? Weird that vspipe did not pass the headers. The "-y" is the same as --y4m. Well that is not a ffmpeg issue. It is vspipe.
[17:26:08 CEST] <meego> kepstin: lifting the TP ceiling from -3 to -1.5 helped quite a bit, as did lowering IL target. Thanks for the tips
[17:28:48 CEST] <vans163> is .mkv equal to a h264 stream? https://github.com/Akagi201/h264-parser/blob/master/src/h264-stream.c
[17:29:08 CEST] <vans163> or is there a way to just output raw h264 without anything wrapping it like mp4 or mkv?
[17:29:22 CEST] <c_14> -f h264
[17:29:57 CEST] <vans163> c_14: let me try
[17:30:06 CEST] <kepstin> note that if you do that, you lose all the framerate information from the container.
[17:30:23 CEST] <vans163> yea i dont need it, im doing realtime streaming / lowest latency possible
[17:30:31 CEST] <kepstin> meego: glad that helped.
[17:47:54 CEST] <vans163> c_14: some custom header is being inserted into the stream
[17:48:17 CEST] <vans163> with the parameters used and about vlc copyleft license
[17:48:30 CEST] <vans163> let me try -v quiet to see if it removes it
[17:49:29 CEST] <vans163> nope still there
[17:49:45 CEST] <c_14> It's probably already part of the bitstream then
[17:50:57 CEST] <vans163> https://gist.github.com/anonymous/cbc1e98253cdc1e023c88407b585c81f
[17:51:02 CEST] <vans163> c_14: hum..
[17:51:13 CEST] <c_14> Yup
[17:51:19 CEST] <furq> there's no way to remove that without editing the x264 source iirc
[17:51:21 CEST] <c_14> The x264 encoder writes that into the bitstream
[17:51:32 CEST] <furq> although i don't see why you'd want to
[17:51:35 CEST] <vans163> the first 4 bytes.  00 00 00 1 afaik thats a valid NAL frame header?
[17:51:54 CEST] <vans163> I dont mind it, im trying to figure out where the first NAL frame starts
[17:52:55 CEST] <vans163> disabling it, il know for sure the first 4 bytes are the first NAL frame header
[17:55:33 CEST] <vans163> let me see if I can find a frame analyzer
[17:55:40 CEST] <vans163> that will break down the binary into what it means
[17:55:47 CEST] <furq> just scan for the next 0x00000001
[17:56:06 CEST] <vans163> some source says the NAL header is 00 00 01  another says its 00 00 00 01
[17:56:08 CEST] <vans163> o.o
[17:56:11 CEST] <furq> that sequence is illegal within a NALU
[17:56:29 CEST] <vans163> 00 00 01?
[17:56:34 CEST] <furq> it can be 000001 or 00000001
[17:57:27 CEST] <vans163> https://github.com/shi-yan/H264Naked this looks good let me try it
[18:00:15 CEST] <jkqxz> SPS and PPS are required to have the extra zero (three zeroes before the one), in other cases you only need two.  You can insert as many extra zeroes as you like anyway, though.
[18:18:14 CEST] <vans163> furq: Yup its called a DISPOS with a SEI frametype, so completely valid
[18:18:32 CEST] <vans163> the nalframe start header is 00 00 01 OR 00 00 00 01
[18:18:36 CEST] <vans163> there is no length it seems?
[18:18:46 CEST] <vans163> (nothing in the header to indicaton the length of the frame?)
[18:25:05 CEST] <vans163> so it seems pretty straightforward
[18:25:16 CEST] <vans163> keep reading until 00 00 01 or 00 00 00 01
[18:25:21 CEST] <vans163> and thats your frame
[18:25:41 CEST] <vans163> having a length would make things so much easier though.. because a question
[18:25:53 CEST] <vans163> to get the next frames header, you need to generate the next frame right?
[18:25:58 CEST] <vans163> so youl always be 1 frame behind parsing
[18:26:16 CEST] <vans163> (since you cannot know when the current frame ends until you can read the next frames header?)
[18:27:00 CEST] <jkqxz> In a raw stream, yes.  Note also that a frame can be made of of multiple NAL units.
[18:27:22 CEST] <vans163> jkqxz: that compensates it a little i guess, not sure
[18:28:15 CEST] <vans163> guessing you just pipe in these NAL units to the decoder and eventually itl spit you out a frame?
[18:29:22 CEST] <vans163> this example im looking at, has a fixed size for NAL frames
[18:29:27 CEST] <vans163> not sure if FFMpeg can set that
[18:29:34 CEST] <vans163> that way youl always know how long a frame would be
[18:29:50 CEST] <vans163> (no need to get a future frame to know when the current ended)
[18:29:52 CEST] <jkqxz> Also there can be more NAL units in the middle of the stream - SPS and PPS can occur at any time, as can SEI.  AUD and filler appear in some streams.
[18:30:26 CEST] <vans163> the size is quite big though
[18:30:34 CEST] <vans163> 151kb for a 480x320 video at 25fps
[18:33:35 CEST] <vans163> is there a way to know if your using Baseline.  https://developer.chrome.com/native-client/pepper_dev/c/group___enums#gga4d50d27186f68b2de578e82162206feaa65c543f4e17057ba76e3e2828fb4a5ae
[18:34:00 CEST] <vans163> That enum PP_VideoProfile  has so many values
[18:34:10 CEST] <vans163> how would you know which one to use for your stream? Other then trial and error?
[18:35:45 CEST] <jkqxz> The profile is in the first byte of the SPS.  If that's 66, it's baseline profile (or constrained baseline, which is a subset of baseline).
[18:37:06 CEST] <jkqxz> You choose the profile based on the features you want to use and the capabilities of the devices which you want to be able to decode it.
[18:44:13 CEST] <vans163> jkqxz: so why doesnt the decoder automatically determine this then
[18:44:43 CEST] <vans163> 67 is first
[18:47:00 CEST] <jkqxz> It does?  (The 0x67 will be the NAL unit header - the next byte after that is first byte of the SPS.)
[18:53:05 CEST] <GyrosGeier> hm
[18:53:30 CEST] <GyrosGeier> I have a 3GP video from a Nokia 6230i and would like to reencode it as something modern
[18:53:45 CEST] <GyrosGeier> I get "Multiple frames in a packet from stream 1"
[18:54:10 CEST] <vans163> jkqxz: The frame analyzer says the first frame is SPS which is 23 bytes in size, and has a 4 byte header. (so 27 total bytes)
[18:54:12 CEST] <vans163> 00 00 00 01 67 F4 00 1F AE B4 02 00 30 D0 80 00 00 03 00 80 00 00 1E 47 8C 19 50
[18:54:37 CEST] <vans163> also would there be a way to not have IDR_SLICE frames?
[18:55:43 CEST] <vans163> the stream goes like SPS, PPS, IDR_SLICE, IDR_SLICE, IDR_SLICE, SLICE x 1000.  Then again and again this sequence.
[18:59:32 CEST] <vans163> nevermind that is rediculous
[19:03:58 CEST] <vans163> okay the decoder in the NaCl examples just reading until the next 00 00 00 01 header
[19:04:05 CEST] <vans163> then it has a NAL frame that it pipes
[19:04:07 CEST] <vans163> pretty simple?
[19:04:10 CEST] <vans163> let me try
[19:04:18 CEST] <vans163> (i thought it was grabbing in chunks of 151kb
[20:03:56 CEST] <qxt> Anybody know what this weird artifact is on the bottom left of this video. It is messing up the aspect ratio of my video. http://imgur.com/u6sUcuj
[20:04:13 CEST] <qxt> The video is a capture from a firewire 1394 card. The video is a 20 year old Video8 tape.
[20:04:57 CEST] <qxt> lol'd a little...that sounded robotic
[20:06:49 CEST] <qxt> nej, nej och nej! Det ska jag inte göra. Det är din skit code =P
[20:06:54 CEST] <qxt> sry wrong term
[20:07:37 CEST] <durandal_170> qxt: how that could mess aspect ratio
[20:08:58 CEST] <qxt> I am piping this into ffmpeg from VapourSynth. Headers are there but the aspect ratio is wrong. This video should be 4:3 PAL. ffmpeg thinks it is 5:4
[20:09:40 CEST] <durandal_170> vspipe kills pixel aspect ratio
[20:09:46 CEST] <qxt> that little thinky on the bottom left is poking out so the video size is all wrong
[20:10:24 CEST] <durandal_170> its y4m doesn't export aspect ratio
[20:10:43 CEST] <qxt> but I am using the --y4m flag to force it
[20:11:35 CEST] <durandal_170> as I said vspipe set aspect to 0/0
[20:11:51 CEST] <qxt> hmm could it be that. All the analogue stuff is not my thing. So what do I need to do?
[20:12:29 CEST] <qxt> -vf setdar=4:3 in the ffmpeg cmd?
[20:12:36 CEST] <durandal_170> setsar ffmpeg filter
[20:13:06 CEST] <qxt> sar or dar? Get them mixed up all the time
[20:13:12 CEST] <durandal_170> if you known correct pixel aspect ratio
[20:14:05 CEST] <qxt> oh why could they not be "normal" 30 years ago...like gosh =P
[20:14:43 CEST] <qxt> the video is 720x576 PAL not sure what to punch in
[20:15:59 CEST] <furq> probably 12:11
[20:16:22 CEST] <furq> (width / height) * (12/11) is the output dar
[20:16:58 CEST] <qxt> Where does the 12:11 come from furq?
[20:17:13 CEST] <qxt> Just a standard?
[20:17:29 CEST] <furq> https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_common_video_formats
[20:17:37 CEST] <qxt> thank you thank....
[20:18:40 CEST] <JEEB> basically we're hoping that the capture ended up with enterprise standard "4:3" aspect ratio (except it's not exactly 4:3 if you take the whole picture in)
[20:19:05 CEST] <furq> (704/576) * (12/11) is roughly 4/3
[20:19:13 CEST] <JEEB> yes
[20:19:15 CEST] <furq> so put in the values after cropping and you should get the correct dar
[20:19:41 CEST] <durandal_170> or 16/15?
[20:20:59 CEST] <JEEB> also if you're interested in the maths behind it, there's plenty of articles on the subject. some touch the theoretical values and then there's the "simplified" values that are used in the corporate stuff (IIRC someone noted that non-full lines in analog signals lead to the "simplified" ones actually being the exact ones)
[20:22:28 CEST] <qxt> ah got it. Seems a bit convoluted but I guess they had no choice back then.
[20:22:39 CEST] <qxt> ffprobe is giving this Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3],
[20:22:52 CEST] <qxt> looks like it a SAR 16:15
[20:23:09 CEST] <JEEB> if it's signaled "4:3", that is what it will be noted as
[20:23:19 CEST] <JEEB> ffmpeg as such doesn't try to guess which sort of "4:3" it is
[20:23:36 CEST] <JEEB> blame old formats, basically
[20:23:54 CEST] <JEEB> MPEG-2 Video in DVDs have the same issue
[20:24:42 CEST] <qxt> So how would I pass on the correct "kind of 4:3" I am using?
[20:24:56 CEST] <qxt> SAR 16:15 that is
[20:24:58 CEST] <JEEB> thankfully the fact that blu-ray specs actually contained the "simplified" analog aspect ratios for SD pretty much proved that those should be defaulted to with such content (SD, based on analog=
[20:25:18 CEST] <JEEB> qxt: -vf setsar=12:11 I think_
[20:25:39 CEST] <qxt> Not 16:15 ?
[20:25:47 CEST] <JEEB> 16:15 is exact 4:3
[20:26:01 CEST] <JEEB> ffmpeg treats a "4:3" flag as exact 4:3
[20:26:19 CEST] <JEEB> since it can't possibly know the context (well, in some cases it could but it doesn't)
[20:26:42 CEST] <durandal_170> 16:15 same as input passed to vs
[20:28:17 CEST] <durandal_170> unless your vs changes that, which I don't think it happens
[20:28:47 CEST] <qxt> how quaint =)
[20:29:04 CEST] <JEEB> I will guess L-SMASH Works or something was used to decode the dv
[20:29:13 CEST] <JEEB> and I will take a wild guess that the dv has a flag for "4:3"
[20:29:39 CEST] <JEEB> and basically you know your capture device and you know your content - you should be the one to know if that captured content is actually 4:3 or analog-in-digital 4:3
[20:30:44 CEST] <JEEB> (LWLibavVideoSource uses libavformat/-codec behind the scenes)
[20:31:02 CEST] <JEEB> which takes the field at face value without context
[20:31:07 CEST] <qxt> Gonna plug in the video camera and just ffprobe the /dev/video0 or what ever it was. Maybe Ill get some info
[20:31:21 CEST] <JEEB> ffprobe is gonna just show you the flag at face value
[20:31:31 CEST] <JEEB> it's the same thing as with DVDs :P
[20:31:36 CEST] <qxt> lol
[20:32:06 CEST] <qxt> ok imma, imma... well have a beer and just be happy with it then =P
[20:32:15 CEST] <kepstin> blu-ray with 576line stuff uses 504 as the active video width, right, to get the simplified sar? (rather than 502ish)
[20:32:26 CEST] <spaam> someone know something about dash? how come that this http://8f8438fe5bac6c05.paste.se/ download 13 files + init file? :)
[20:32:41 CEST] <spaam> SegmentTimeline thing say 10..
[20:32:51 CEST] <JEEB> kepstin: no idea but I do know that the values @ http://www.x264bluray.com/home/576p-pal are according to spec
[20:33:17 CEST] <JEEB> which IMHO verifies the SAR for DVDs (of course if you know better you should use the SAR that you know the content should be)
[20:34:39 CEST] <JEEB> qxt: welcome to formats that didn't specify exact aspect ratios and left room for interpretation :) (thankfully that got kind of fixed with later things)
[20:35:53 CEST] <kepstin> JEEB: hmm. that page appears to be giving the widescreen sar?
[20:35:56 CEST] <qxt> wow I am so happy those days are behind us. Thing is I kinda need to know for a rewrite of Deshaker I am working on. Rotation info gets really messed up if I don't plug aspect in right.
[20:35:56 CEST] <kepstin> not the 4:3 one
[20:36:19 CEST] <kepstin> oh, I just didn't read the first paragraph :)
[20:36:49 CEST] <JEEB> yeah, it has both there and I've checked them against "the PDF" at one point
[20:37:56 CEST] <kepstin> yeah, imo those values make sense, and are a lot nicer to use than values other people have come up with based on the old "squarish pixel" analog sampling
[20:38:09 CEST] <kepstin> easier to convert between pal and ntsc frame sizes too, if needed.
[20:40:45 CEST] <kepstin> at worst the error would be in the range of 0.2%, which is rather smaller than the error due to slightly misaligned or out of tune CRT tubes :/
[20:41:11 CEST] <JEEB> yeah
[20:41:37 CEST] <JEEB> basically the spec just gives me a thing to expect from a lot of SD analog->digital media
[20:41:38 CEST] <teo_> Hi everyone, is it possible to feed in realtime with webp+duration and multiple audio source (buffers to be merged) ?
[20:48:42 CEST] <vans163> Damn so using h264 raw encoding, there is no way to know how long a NAL frame is? mp4 carries frame size, but mp4 cant be piped
[20:49:04 CEST] <vans163> meaning.. decoding a 30 fps stream, you will always be 33ms behind?
[20:49:13 CEST] <vans163> (1 frame)
[20:50:08 CEST] <vans163> or no nevermind.. a NAL unit is not a full frame so
[20:50:15 CEST] <vans163> the decoder will probably reconstruct fast enough
[20:50:40 CEST] <vans163> so being 1 NAL unit behind always != 1 full frame behind
[20:51:24 CEST] <vans163> the only problematic case is when the encoder stops producing output on a frame boundary.
[20:51:46 CEST] <vans163> so a frame comes in, it encodes. then the last NAL unit cannot be processes as we dont know the full length until the next frame is encoded?
[20:52:01 CEST] <vans163> and that next frame at 30 fps will be encoded in 33ms
[20:52:24 CEST] <vans163> so if the decoder cannot decode the next full frame without the last NAL unit, it will indeed be 33ms behind (1 frame)
[20:52:52 CEST] <vans163> anyone know if it works like that?
[20:53:08 CEST] <vans163> Nvidia claiming they do sub 15ms decode makes me think its not the case
[20:54:19 CEST] <kepstin> well, nvidia's claims are probably assuming a packetized format where all the lengths are known
[20:57:16 CEST] <vans163> kepstin: im not sure.. il have to put the nvidia encoded .h264 until an analyzer
[20:57:28 CEST] <s0126h> what is best lossy audio codec to use these days
[20:57:34 CEST] <vans163> but the file extension being .h264 leads me to believe its the same as ffmepgs -f h264?
[20:57:50 CEST] <kepstin> s0126h: depends what players you need to support
[20:58:03 CEST] <jkqxz> The stream is complete internally.  You can feed the stream into a decoder byte by byte and it can tell you are exactly at the moment the frame is complete.
[20:58:04 CEST] <kepstin> s0126h: in general, probably opus, but if you need wide player support then aac.
[20:59:26 CEST] <jkqxz> Few (no?) decoders actually support that mode of operation, though.  And making a stream parser to compute that is basically an exercise in writing a large proportion of a decoder.
[20:59:56 CEST] <s0126h> kepstin i don't need wide support,  but why opus?  is it better than aac
[21:00:37 CEST] <kepstin> s0126h: according to some comparisons, marginally better - and it has a good open-source encoder, unlike aac, and no patent worries if you care about that sort of thing.
[21:01:05 CEST] <kepstin> (well, I guess libfdk_aac is open-source, but license incompatible with ffmpeg for distribution? dunno how that works)
[21:01:05 CEST] <s0126h> i don't like the fact that aac  has like 10 different encoders
[21:01:18 CEST] <s0126h> and some are good and some are bad
[21:01:22 CEST] <furq> aren't you the guy who loves mp3
[21:01:34 CEST] <DHE> kepstin: basically you can compile your own binary and keep it to yourself. you can't share the binary with anyone
[21:01:40 CEST] <s0126h> furq  no, but i like that mp3 is always .mp3
[21:01:42 CEST] <furq> there are plenty of shitty mp3 encoders out there
[21:01:59 CEST] <kepstin> DHE: it's just that i've never actually read the libfdk_aac license, so i dunno /why/ it's incompatible :)
[21:02:10 CEST] <s0126h> how many opus encoders are there?  i am guessing only one
[21:02:19 CEST] <s0126h> furq which ones are shitty?
[21:02:44 CEST] <kepstin> s0126h: only one opus encoder (for now), but multiple versions hang around and the old ones aren't as good
[21:02:54 CEST] <vans163> jkqxz: good to know, thanks. I will play with it then. The example shows only feeding full name frames to the Chrome Pepper decoder
[21:03:06 CEST] <vans163> name/nal
[21:03:21 CEST] <furq> kepstin: https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE#L51-L58
[21:03:24 CEST] <furq> that's GPL incompatible
[21:03:55 CEST] <s0126h> Stable release 	
[21:03:55 CEST] <s0126h> 1.1.3 / July 15, 2016; 2 months ago
[21:03:59 CEST] <kepstin> s0126h: almost everyone uses lame for mp3 encoding nowadays, it's basically the 'x264' of mp3 encoding ;)
[21:04:18 CEST] <s0126h> kepstin what about the one itunes use
[21:04:30 CEST] <furq> itunes is garbage
[21:04:37 CEST] <kepstin> s0126h: most itunes stuff i've seen is AAC, and apple has one of the best aac encoders around.
[21:04:40 CEST] <s0126h> i don't think that one is is lame and  al ot of people use itunes
[21:04:40 CEST] <furq> by which i mean itunes' mp3 encoder
[21:04:44 CEST] <furq> it isn't lame
[21:04:53 CEST] <s0126h> furq  agreed but a lot of people use itunes
[21:05:03 CEST] <furq> yes?
[21:05:38 CEST] <furq> pretty much anything but lame and helix suck
[21:05:54 CEST] <furq> and nobody really uses helix
[21:05:59 CEST] <s0126h> kepstin  so are you claiming   opus  1.0.x  are crappy
[21:06:17 CEST] <s0126h> isn't helix  .rm
[21:06:44 CEST] <kepstin> s0126h: newer opus have significant improvements over the 1.0
[21:06:50 CEST] <s0126h> kepstin i see
[21:06:56 CEST] <kepstin> it's not that the 1.0 are really bad, it's just that the newer ones are better.
[21:06:56 CEST] <furq> helix was realnetworks' mp3 encoder but it got open sourced years ago
[21:07:02 CEST] <furq> it does surprisingly well in listening tests
[21:07:13 CEST] <furq> there's no reason to use it over lame though
[21:07:23 CEST] <s0126h> furq i see, i wonder which mp3 encoder itunes use then
[21:07:32 CEST] <furq> probably a proprietary one
[21:07:38 CEST] <furq> same as their aac encoder
[21:07:48 CEST] <furq> i think they use a proprietary h.264 encoder as well
[21:08:04 CEST] <kepstin> their aac one is unique to them, I wonder if their mp3 encoder is also in-house or licensed from someone else.
[21:08:22 CEST] <s0126h> do you think we will see more than one opus encoder?
[21:08:30 CEST] <furq> well it sucks so it's not really worth speculating about
[21:08:45 CEST] <furq> opus is MIT licensed isn't it
[21:08:52 CEST] <furq> so there's not really any reason for anyone to make another one
[21:08:54 CEST] <kepstin> s0126h: maybe? It's possible, but IMO rather unlikely since the license is so liberal.
[21:08:57 CEST] <furq> maybe a fixed-point one
[21:09:09 CEST] <kepstin> they have fixed-point in the main library already
[21:09:13 CEST] <furq> oh really
[21:09:20 CEST] <kepstin> compile time option, been there from the start iirc
[21:09:40 CEST] <s0126h> flac is also only one encoder.. right?
[21:09:43 CEST] <furq> i guess some people will release custom tunings like they did with libvorbis
[21:09:55 CEST] <kepstin> s0126h: no, e.g. ffmpeg contains an independent flac encoder.
[21:09:59 CEST] <furq> there's more than one flac encoder but it doesn't really matter
[21:10:12 CEST] <s0126h> furq  true it doesn't matter since it's lossless
[21:10:29 CEST] <kepstin> only difference would be "this encoder makes marginally smaller files than that one" or whatever :/
[21:10:38 CEST] <s0126h> i do remember seeing  2 different libvorbis
[21:10:51 CEST] <furq> they were both based on the same encoder though
[21:11:01 CEST] <furq> s/both/all because there were more than two variants
[21:11:18 CEST] <kepstin> iirc, a lot of the improvements from the aotuv libvorbis have been merged into the the main one over time.
[21:11:33 CEST] <furq> yeah
[21:11:35 CEST] <s0126h> is it pointless to use libvorbis now since there is opus?
[21:11:46 CEST] <furq> some devices will support vorbis but not opus
[21:11:48 CEST] <furq> not many though
[21:12:18 CEST] <furq> also there are at least five flac encoders fwiw
[21:12:29 CEST] <s0126h> wow 5
[21:12:41 CEST] <s0126h> why even bother
[21:12:51 CEST] <furq> libflac, libflake, flacuda/flaccl, lavc and cuetools
[21:13:15 CEST] <s0126h> libflac = official one by main author?
[21:13:20 CEST] <furq> yes
[21:13:49 CEST] <s0126h> i really feel there is no point of keep creating other flac encoders since it's lossless
[21:14:06 CEST] <furq> flake and flaccl support nonstandard compression levels
[21:14:18 CEST] <furq> which is nice in theory but it's not guaranteed to be decodable
[21:14:38 CEST] <furq> flaccl is also really fast if you have a decent gpu
[21:14:54 CEST] <s0126h> oh it uses GPU instead of CPU?
[21:14:58 CEST] <furq> yeah
[21:15:18 CEST] <s0126h> oh, then maybe there is a point
[21:16:29 CEST] <furq> i've not used it in years but it was much faster than libflac on my old gtx 260
[21:16:36 CEST] <furq> so it's probably incredibly fast on modern gpus
[21:16:38 CEST] <kepstin> well, if you just want a fast flac encoder, I could write one up quick that just uses the 'verbatim' encoding (no compression) to repack pcm in a flac bitstream ;)
[21:16:57 CEST] <furq> it compresses roughly as well as flac -8 as well
[21:17:14 CEST] <furq> or at least it did a few years ago
[21:17:25 CEST] <durandal_170> kepstin: no!
[21:17:56 CEST] <s0126h> .ape does better compression than .flac  but  playback support is not as good (even on desktop computer)
[21:18:13 CEST] <furq> there are lots of lossless codecs which compress better than flac
[21:18:30 CEST] <s0126h> then flac should be doing better
[21:18:35 CEST] <kepstin> most of them do it by not being seekable (or being slower to seek, with larger blocks)
[21:18:40 CEST] <furq> but you're looking at maybe 3-4% savings at the cost of terrible support and much slower decoding
[21:18:43 CEST] <kepstin> not always tho
[21:18:43 CEST] <furq> and yeah that
[21:19:05 CEST] <kepstin> flac was designed with efficient *playback* being a major goal.
[21:19:24 CEST] <s0126h> i dont' care about encoding speed  but i care if  decoding is slow
[21:19:32 CEST] <furq> the slowest ape preset is something like 30x slower to decode than flac -8
[21:19:50 CEST] <furq> for ~2% less space used
[21:20:54 CEST] <furq> https://xiph.org/flac/comparison.html
[21:20:57 CEST] <furq> there's a nice graph there
[21:21:05 CEST] <furq> it's actually much worse than 30x
[21:21:35 CEST] <furq> tak looks really good there but it's not opensource iirc so nobody cares about it
[21:22:57 CEST] <durandal_170> tak is open source
[21:23:17 CEST] <furq> since when
[21:24:18 CEST] <kepstin> there's an open-source tak *decoder* in lavc.
[21:24:19 CEST] <durandal_170> since 2013
[21:24:30 CEST] <furq> i don't see any source code on its site
[21:24:40 CEST] <furq> i know lavc has a decoder but there's no open-source encoder
[21:25:17 CEST] <durandal_170> write one, there is decoder
[21:25:43 CEST] <kepstin> tbh, I was kinda surprised someone wrote an alac encoder for ffmpeg.
[21:27:00 CEST] <furq> this doesn't really refute my point that nobody cares about tak
[21:27:03 CEST] <furq> except for some japanese weirdos
[21:27:20 CEST] <furq> the ones who decided they were too cool for ape
[21:27:42 CEST] <durandal_170> there is tta, wavpack and optimfrog
[21:27:43 CEST] <s0126h> lol
[21:28:09 CEST] <s0126h> http://www.lossless-audio.com/comparison.htm
[21:28:36 CEST] <s0126h> big difference in size
[21:29:41 CEST] <kepstin> bigger difference in decoding speed :)
[21:29:51 CEST] <kepstin> (and they don't say what settings they're using with flac, either)
[21:30:29 CEST] <kepstin> 'la' looks like one of those 'symmetric' encoders where slower compression means slower decompression too.
[21:32:36 CEST] <furq> yeah LA is pretty much realtime decompression iirc
[21:32:49 CEST] <furq> that and optimfrog are pretty much the only lossless formats i've never seen in the wild
[21:32:56 CEST] <furq> other than the weird mpeg-4 extensions
[21:50:27 CEST] <ianbytchek> greetings all. i'm getting a massive mem. leak while encoding with libraries. started after i introduced filter graph and buffer filters. is there anything obvious to do / free / cleanup after each iteration? can buffersrc be accumulating / not releasing un-needed data?
[21:57:18 CEST] <durandal_1707> ianbytchek: free frame after you no longer need it
[22:00:49 CEST] <Chloe__> furq: I've seem optimfrog in the wild, depressingly enough
[22:03:39 CEST] <ianbytchek> durandal_1707: yep. this is also in examples, missed it somehow. thanks! though, still seeing 10+ mb leak. anything else that might causing it? also calling av_packet_unref.
[22:05:04 CEST] <ianbytchek> durandal_1707: can this be related to input frame? av_frame_unref(input_frame) causes troubles.
[22:08:41 CEST] <durandal_1707> ianbytchek: what you added? and by how much memory decreased?
[22:09:47 CEST] <DelphiWorld> hi people
[22:09:50 CEST] <DelphiWorld> [h264 @ 0x4a39fc0] no frame!
[22:10:04 CEST] <DelphiWorld> what could  i do to avoid that crap that making my playback so long to start?
[22:20:43 CEST] <vans163> Hey is there anyway to get this kind of output for h264?  https://groups.google.com/forum/#!topic/native-client-discuss/d1DnxbbIj88
[22:20:56 CEST] <vans163> Basically the NAL frames have a 4bytes header that states the length of the frame
[22:21:05 CEST] <vans163> instead of 0 0 0 1 or 0 0 1
[22:21:51 CEST] <vans163> if you open good.h264 in hex editor youl see   00 00 00 27 67 64 00 20 AC 2B 40 28 02 DD 80 B5 01 0D 01 40 00 00 FA 00 00 75 30 18 00 00 09 89 60 00 05 26 5D BB CB 83 E3 86 54 00 00 00 04 68 EE 3C B0
[22:22:07 CEST] <vans163> which is 2 NAL frames, first being 0x27 in size and second 0x04
[22:22:48 CEST] <vans163> it can be played back in ffmpeg by using  CODEC_FLAG2_CHUNKS
[22:23:16 CEST] <furq> you want avcc instead of annex b
[22:23:28 CEST] <furq> i don't know if there's any way to get ffmpeg to produce that unless you're muxing into mov/mp4
[22:24:10 CEST] <vans163> furq: hum.. mp4 is no go, because it needs to seek backwards I believe (you cant pipe output)
[22:25:58 CEST] <furq> when i say "you want" i mean that's the thing you're asking for, not that it would be better
[22:26:32 CEST] <vans163> furq: yea ty il test that
[22:26:41 CEST] <vans163> any idea how to set that flag for ffmpeg?
[22:26:47 CEST] <vans163> to use avcc
[22:27:22 CEST] <furq> no idea
[22:42:05 CEST] <ianbytchek> durandal_1707: i think there are two issues. actual memory leak report and actual memory usage. before migrating to filtergraph the memory would stay within 30 mb range  i cleared it on every iteration.
[22:43:15 CEST] <ianbytchek> durandal_1707: after freeing output frame the major mem leak did go away. but memory is still slowly rising. for 50 frames for 1080 video it goes up to 100+ mb.
[22:44:05 CEST] <ianbytchek> durandal_1707: before  is when i used swscale to simply make format conversion. without filters.
[22:46:26 CEST] <ianbytchek> durandal_1707: 100 mb is a little underestimate. it goes just over 200. but when i close all outputs and clear things out it drops back to 30.
[22:47:10 CEST] <ianbytchek> durandal_1707: so, it works. but something within ffmpeg is holding it back.
[22:48:04 CEST] <durandal_1707> ianbytchek: can you use valgrind?
[22:51:20 CEST] <ianbytchek> durandal_1707: i have a craziest setup. using ffmpeg from within swift. in xcode on osx. i never used it, since xcode comes with own profiler and debugger. from a brief look it might be possible to use them together. anything in particular you want to know?
[22:54:35 CEST] <ianbytchek> durandal_1707: sounds like even if valgrind and swift are possible it would be a huge pain.
[23:19:57 CEST] <durandal_1707> ianbytchek: doesn't look like leak if everything goes to normal after freeing graph
[23:23:32 CEST] <ianbytchek> durandal_1707: no, it's not. the major lead was fixed. there are minor ones, hoping to track them down myself. right now mostly wondering, if there is anything filter-related (using simple scale filter for this test) which may cause frame data to be held back in memory up until closing the encoder?
[23:24:07 CEST] <ianbytchek> durandal_1707: like you say, it's acting fine, but before frames were freed instantaneously. now  only after closing the encoder.
[23:24:24 CEST] <ianbytchek> durandal_1707: do i make any sense?
[23:29:10 CEST] <durandal_1707> you need to av_free_frame after giving it to encoder
[23:32:36 CEST] <ianbytchek> durandal_1707: i do. right after `avcodec_send_frame`.
[23:33:41 CEST] <ianbytchek> durandal_1707: must i use the same input frame for the entire encoding duration? if i try creating / freeing it inside every iteration the memory starts leaking through the roof.
[23:33:59 CEST] <ianbytchek> durandal_1707: i somehow feel the issue might be with that&
[23:37:40 CEST] <durandal_1707> ianbytchek: I don't get it, could you pastebin relevant code?
[23:38:03 CEST] <Z0ltans> Hi im trying to do ffmpeg nnvec using a 970 gtx streaming but i run into a roadblock when streaming to my server im only getting audio video is black what could be the issue?
[23:41:33 CEST] <Z0ltans> thanks
[23:42:41 CEST] <Z0ltans> http://pastebin.com/K7bRn1xN
[23:43:29 CEST] <BtbN> I'm more interested in the output, and that's not the full commandline.
[23:43:48 CEST] <BtbN> you also seem to specify the codec twice?
[23:44:02 CEST] <Z0ltans> ohh
[23:44:02 CEST] <BtbN> nvenc_h264 is also a deprecated name
[23:44:33 CEST] <Z0ltans> so that could be my issue then?
[23:44:48 CEST] <BtbN> no
[23:56:30 CEST] <Z0ltans> BtbN this? http://pastebin.com/DFeHqCwY
[23:58:45 CEST] <BtbN> No, the exact ffmpeg command you invoke, and the complete console output it produces.
[23:58:57 CEST] <Z0ltans> oh that one 1 sec
[23:59:34 CEST] <Z0ltans> http://pastebin.com/1R4h5wcR
[23:59:36 CEST] <Z0ltans> there u go
[00:00:00 CEST] --- Sat Sep 17 2016