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

[burek]

[00:01:18 CET] <c_14> That happens after you connect a client?
[00:02:45 CET] <ethe> only ffmpeg it seems, jack_rec works fine (which is also a jack client doing the same thing as what ffmpeg is trying to do)
[00:02:58 CET] <ethe> JACK in itself looks like it is working
[00:03:41 CET] <c_14> I meant, after you used jack_connect to connect a readable client to ffmpeg (if I understand jack correctly)
[00:12:47 CET] <ethe> there's not enough time to start connect the ports after I start ffmpeg
[00:14:25 CET] <ethe> it exits immediately, it should (I think) stay open, regardless if it's connected or not
[00:17:05 CET] <ethe> c_14: also, shouldn't we be discussing this in #ffmpeg-devel?
[00:17:27 CET] <c_14> doesn't really matter
[00:17:33 CET] <c_14> and they're busy talking about vp9
[00:37:20 CET] <c_14> ethe: maybe try this? https://pb.c-14.de/t/kng.Qyb8I1
[00:37:23 CET] <c_14> on top of the current patch
[00:42:50 CET] <ethe> didn't seem to help
[00:43:23 CET] <c_14> Same error, or does it hang?
[00:51:27 CET] <ethe> same error
[00:51:29 CET] <ethe> no hand
[00:51:31 CET] <ethe> hang*
[00:53:20 CET] <c_14> strange
[00:54:40 CET] <c_14> https://pb.c-14.de/t/kng.ukZPD6
[00:54:43 CET] <c_14> how about with that as well?
[00:57:23 CET] <ethe> wont it always throw an erorr?
[00:57:40 CET] <ethe> (because of the else)
[00:58:37 CET] <c_14> Nah, semaphore_wait returns 0 on success and therefore doesn't enter the first if
[01:00:07 CET] <ethe> "Error while waiting for audio packet: Undefined error: 0" both times now, rather than just one
[01:02:07 CET] <c_14> https://pb.c-14.de/t/kng.EsJKa9
[01:02:36 CET] <c_14> It would help if apple actually documented their functions *sigh*
[01:15:26 CET] <ethe> c_14: https://gist.github.com/joshdekock/b6a654ca256f67713e41
[01:16:19 CET] <c_14> Is there data in the output wav?
[01:20:17 CET] <ethe> yeah, but it only looks like there's a header
[01:32:29 CET] <c_14> I'm out of ideas...
[01:35:32 CET] <ethe> :(
[06:53:39 CET] <prelude2004c> hi everyone
[06:53:51 CET] <prelude2004c> using ffmpeg and vdpau . the M4000 does h264 decoding right ? i am using vdpau and i finally got it going but for some reason any source that is mpeg2video decodes fine with GPU but h264 content does not ? Any idea why that would be ?
[07:30:26 CET] <CarlFK> I am running this to create a file: https://github.com/voc/voctomix/blob/master/example-scripts/ffmpeg/record-mixed-ffmpeg-segmented.sh
[07:33:20 CET] <CarlFK> mediainfo doesn't show a start datetime http://paste.ubuntu.com/14113311/
[07:34:01 CET] <CarlFK> the os's time is fine.  or if it should be coming from the source -i tcp://localhost:11000    I can poke the people that do that
[07:37:41 CET] <c_14> Do you mean a metadata creation timestamp?
[07:42:22 CET] <c_14> If yes, I don't think mpegts supports that.
[07:51:31 CET] <CarlFK> c_14: yes
[07:56:34 CET] <CarlFK> is there another container I could use?  (it's the container, right?)
[08:48:58 CET] <CarlFK> https://github.com/voc/voctomix/blob/master/example-scripts/ffmpeg/source-mjpg-framegrabber.sh
[08:49:19 CET] <CarlFK> ffmpeg -y  -i "http://10.73.5.2:1881/stream.mjpg" ...
[08:50:04 CET] <CarlFK> I want to swap the input for /dev/video0
[08:50:32 CET] <CarlFK> it kinda works.. but something not right in the app this feeds
[08:51:07 CET] <CarlFK> which is very new, so hard to know where to look first.
[08:51:28 CET] <CarlFK> how safe is it to assume I can just swap in /dev/video0 ?
[12:28:22 CET] <luc4> Hello! Im debugging a decoder and it seems I found some videos that result wrong. By using ffmpeg I got this: https://paste.kde.org/pjkquwkt2. I notice two things here: the pixel format is yuv420p(tv, bt709) and the SAR is 1:1. Can the SAR be 1:1 when the resolution is 1080x1920? Shouldnt it be 1080/1920? And Im not sure about what that (tv, bt709) means. bt709 seems to specify the representation of pixels, but w
[12:28:22 CET] <luc4> tv? What is the difference between yuv420p and yuv420p(tv, bt709)?
[12:31:21 CET] <JEEB> if the SAR is 1:1 it is 1:1, it just means that the samples' aspect ratio is 1:1. "tv"/"pc" are YCbCr ranges and BT.709 is one of the possible colorimetry values in AVC streams set to a specific value
[12:33:10 CET] <Mavrik> mhm
[12:33:32 CET] <Mavrik> those are standard parameters for 1080p video :)
[12:34:29 CET] <Mavrik> luc4, note that SAR isn't the display aspect ratio (which is 16:9) but the sample (pixel) aspect ratio saying how pixels should be stretched when displayed. Since your video isn't anamorphic, 1:1 is fine.
[12:35:23 CET] <luc4> Mavrik: I read wikipedia, and SAR is reported as Storage Aspect Ration. Is this wrong?
[12:35:37 CET] <JEEB> yes
[12:35:46 CET] <JEEB> only wikipedia uses that definition
[12:35:54 CET] <luc4> Mavrik: ah I see
[12:36:18 CET] <luc4> Mavrik: so SAR is Sample Aspect Ratio, which is what wikipedia names PAR
[12:36:23 CET] <JEEB> it's very unfortunate that they chose to use a three-letter-thing that is actually used in specifications :P
[12:36:57 CET] <luc4> Mavrik: so SAR of 1:1 is perfectly normal
[12:37:00 CET] <JEEB> yes, also PAR is what MPEG-4 called it for a while, until AVC and HEVC which had SAR again
[12:37:00 CET] <Mavrik> Yes.
[12:37:14 CET] <Mavrik> luc4, if SAR isn't 1:1 then video has to be stretched to another resolution when displayed.
[12:37:43 CET] <luc4> I understand now. And DAR 9:16 is a consequence of 1080x1920, so perfectly correct.
[12:37:48 CET] <Mavrik> e.yes.
[12:37:49 CET] <JEEB> yes
[12:38:05 CET] <Mavrik> For example you had 16:9 DVD video, which was encoded as 720x576 (which is 4:3 video)
[12:38:13 CET] <luc4> Which means the only weird thing is yuv420p(tv, bt709)&
[12:38:26 CET] <Mavrik> Then it had a SAR flag of 4:3 which told the video player to stretch the video to 1024x576 (I think) when playing it :)
[12:38:31 CET] <JEEB> it's not really weird, tv is the default range for most if not all YCbCr content
[12:38:44 CET] <JEEB> Mavrik: there's a lot of dark history there, don't touch the dragons
[12:38:47 CET] <Mavrik> luc4, nop, that's not wierd, that's prescribed HD colormetry
[12:38:50 CET] <luc4> JEEB: but I commonly only read yuv420p in ffprobe
[12:39:01 CET] <Mavrik> JEEB, eh, still writing software for DVB/IPTV broadcasts.
[12:39:01 CET] <JEEB> that just means that the stream doesn't contain specific metadata
[12:39:09 CET] <Mavrik> Aspect ratio switching on TV ftw.
[12:39:29 CET] <luc4> By weird I mean, different than many other videos that I have and that seem to work properly with that decoder.
[12:39:32 CET] <JEEB> yeah, that works just fine
[12:39:46 CET] <JEEB> I'm just saying that the DVD/BD aspect ratios for SD can be funky
[12:40:03 CET] <luc4> It is an accelerated decoder, and I use ffmpeg to feed with the samples. I need to play the find the differences game :-)
[12:40:20 CET] <Mavrik> luc4, what you have is as standard as it gets
[12:40:34 CET] <luc4> Mavrik: yes, but still bbb works properly
[12:40:38 CET] <Mavrik> BT.709 is the stadardized colormetricts for pretty much all HD content out there
[12:40:44 CET] <Mavrik> So the issue isn't with what you showed us :)
[12:41:06 CET] <JEEB> my guess would be that the height is the issue :P
[12:41:09 CET] <luc4> You mean that the standard big buck bunny is identical?
[12:41:29 CET] <luc4> JEEB: yes, first thing I tried to rotate the regular bbb video. No problem
[12:41:36 CET] <Mavrik> Big Buck Bunny isn't really encoded to the broadcasting standards.
[12:42:04 CET] <JEEB> luc4: then it's something else :P not the specific points you've been pointing towards (unless the decoder is really broken)
[12:42:10 CET] <luc4> Do you guys notice anything weird in the ffprobe output I pasted?
[12:42:29 CET] <JEEB> no
[12:42:31 CET] <Mavrik> Well, it's baseline, which makes it funny.
[12:42:47 CET] <Mavrik> For 1080p, only mobile cameras do 1080p at baseline.
[12:42:48 CET] <luc4> Ah yes, constrained baseline.
[12:43:03 CET] <Mavrik> but any decoder capable of doing main/high has to do constrained baseline
[12:43:10 CET] <luc4> Ill try to re-encode something that way and see what happens, thanks
[12:43:10 CET] <Mavrik> luc4, is that recorded from mobile phone?
[12:43:24 CET] <luc4> Mavrik: no, I dont think so.
[12:43:28 CET] <JEEB> Mavrik: re aspect ratios, like 576p/i having --sar 16:11 for "16:9" and --sar 12:11 for "4:3"
[12:43:46 CET] <Mavrik> Indeed (was writing out of my head).
[12:43:52 CET] <Mavrik> luc4, if it is, those videos are usually VFR
[12:44:05 CET] <Mavrik> Which wrecks havoc with a lot of hardware decoders.
[12:44:07 CET] <luc4> Mavrik: no no, it seems like an advertisment
[12:44:11 CET] <Mavrik> Set "30fps" when reencoding.
[12:44:14 CET] <Mavrik> And see if that helps.
[12:44:38 CET] <Mavrik> But yeah, do encode 1080p into at least Main to keep some semblance of quality :D
[12:44:49 CET] <luc4> Mavrik: I have to say the result I see seems really something related to pixel format
[12:44:52 CET] <Mavrik> 1200kbit 1080p in baseline must look like garbage :D
[12:44:58 CET] <JEEB> note, anything said based on that pastebin is totally guessing because there is nothing weird :P
[12:45:05 CET] <Mavrik> Yes.
[12:45:10 CET] <Mavrik> It's totally guessing. >D
[12:45:32 CET] <JEEB> there's nothing there that would cause a decoder to break, other than the height. but if you have already tested that exact width+height combo with another thing...
[12:45:36 CET] <Mavrik> Maybe grab a screenshot?
[12:45:40 CET] <luc4> Do you guys have other advises?
[12:45:49 CET] <luc4> ah yes, I can take a photo
[12:45:53 CET] <luc4> just a sec
[12:48:04 CET] <luc4> ah& more than a sec, I need to switch firmware, I noticed older firmwares were working properly
[12:48:16 CET] <luc4> its a regression
[12:54:59 CET] <luc4> yes, the problem seems to be the aspect ration with that h264 profile
[12:55:26 CET] <luc4> great, I can now look into the firmware and see if I can fix this
[12:55:30 CET] <luc4> thanks guys!
[15:29:04 CET] <t4nk751> I am receiving errors similar to the following "concealing 8160 DC, 8160 AC, 8160 MV errors in P frame". Is this a codec context setting issue? Is the decoding taking too long so it is missing frames?
[15:37:45 CET] <prelude2004c> good morning everyone
[15:37:53 CET] <prelude2004c> using ffmpeg and vdpau . the M4000 does h264 decoding right ? i am using vdpau and i finally got it going but for some reason any source that is mpeg2video decodes fine with GPU but h264 content does not ? Any idea why that would be ?
[15:46:27 CET] <DHE> t4nk751: you likely have corrupted data or dropped packets
[15:49:32 CET] <t4nk751> Well I am encoding the screen using x264 and then sending each NAL out individually until I set a flag for frame end. Then I use a client side buffer full of those NALs to decode. Currently, I running the client and server on the same machine. So dropped packets shouldn't be happening too often.
[15:50:23 CET] <t4nk751> Is there any good way to debug corrupted data?
[15:51:41 CET] <DHE> that's beyond my area of expertise...
[15:52:07 CET] <t4nk751> Okay I appreciate your assistance
[16:04:38 CET] <Franciman> hi all
[16:05:24 CET] <Franciman> I want to compile a program that uses ffmpeg's api (libavcodec, libavformat etc..) on windows
[16:05:32 CET] <Franciman> what should i install?
[16:05:46 CET] <fritsch> a C compiler?
[16:05:56 CET] <Franciman> other than that :P
[16:06:14 CET] <fritsch> ffmpeg headers and libs that's it
[16:06:15 CET] <Franciman> i should compile ffmpeg?
[16:06:24 CET] <fritsch> you can do so
[16:06:34 CET] <Franciman> is there a standard way to get them?
[16:06:56 CET] <fritsch> http://ffmpeg.zeranoe.com/builds/
[16:07:24 CET] <fritsch> the dev versions looks like what you need
[16:07:32 CET] <furq> you need dev and shared
[16:07:37 CET] <fritsch> jep
[16:07:42 CET] <Franciman> great thanks
[16:08:23 CET] <furq> and you'll need to distribute the dlls along with your app
[16:08:33 CET] <furq> if you want it all static linked then you need to compile yourself
[16:14:04 CET] <waressearcher2> "compile yourself", das ist sehr heftig
[16:14:35 CET] <fritsch> your "sehr heftig" the next time - if you want to be a developer you need to compile something ...
[16:17:02 CET] <waressearcher2> vielleicht "compile it yourself"
[16:23:16 CET] <fritsch> added to the laugh about it later queue
[16:23:58 CET] <prelude2004c> using ffmpeg and vdpau . the M4000 does h264 decoding right ? i am using vdpau and i finally got it going but for some reason any source that is mpeg2video decodes fine with GPU but h264 content does not ? Any idea why that would be ?
[16:24:47 CET] <fritsch> what does vdpauinfo say?
[16:24:52 CET] <fritsch> is h264 supported?
[00:00:00 CET] --- Mon Dec 21 2015