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

[burek]

[00:17:41 CET] <alexpigment> i can ffmpeg to say q=[int]-[int] by using qmax and qmin, but it seems to have no effect on bitrate
[00:18:01 CET] <alexpigment> and there's a default bitrate of 200kbps, which I can override by setting -b:v 0
[00:18:19 CET] <alexpigment> but basically -b:v 0 is always unlimited regardless of the qmax/qmin
[00:18:36 CET] <alexpigment> in other words, qmax and qmin have no purpose from what I can tell
[00:20:24 CET] <alexpigment> well, I guess I'm done talking to myself for the day :) maybe someone will chime in later who has any experience with the h264_videotoolbox encoder
[00:33:02 CET] <daddesio> Hmm, is there a way to specify the input sample rate for an Xbox 360 XMA .wav file (compression type 0x165)? I don't see anything that looks like a sampling rate (e.g. 0xac44 -> 44100) in the header of my file.
[00:33:30 CET] <JEEB> you'd probably want to check if someone has documented that format
[00:33:34 CET] <daddesio> passing -ar 44100 either before or after the -i input.wav doesn't seem to do anything. I always get: "Invalid sample rate: 0
[00:33:37 CET] <daddesio> "
[00:33:52 CET] <JEEB> yea non-raw demuxers usually try to read stuff themselves
[00:35:00 CET] <JEEB> ok, the first hint is that X360 WAVs seem to use the same code but since it's all big endian I bet all the values have to be read in BE
[00:35:13 CET] <furq> daddesio: https://wiki.multimedia.cx/index.php/XMA
[00:35:25 CET] <furq> looks like you're going to have fun
[00:35:57 CET] <JEEB> hmm, that sounds different
[00:36:20 CET] <JEEB> there seem to be actual WAV files which are in the opposite endian on the X360 as well
[00:37:04 CET] <furq> where are you reading that
[00:37:13 CET] <furq> google isn't being much use here
[00:37:59 CET] <JEEB> xbox 360 wav brought up "WAV endian converter" on some forum
[00:38:14 CET] <JEEB> "Changes endianess for standard WAV files (all floats + ints) found in the game."
[00:38:27 CET] <JEEB> which sounds like MS used common code and just dumped data from memory in it
[00:38:31 CET] <JEEB> which led to endian swaps
[00:42:19 CET] <daddesio> yes, seems I will have to do some investigating/RE :)
[00:42:34 CET] <daddesio> vgmstream also can't decode it
[00:52:18 CET] <furq> http://www.scampers.org/steve/sms/other.htm
[00:52:19 CET] <furq> maybe this?
[00:52:26 CET] <furq> Supports XMA v1 and XMA2 (format tags 0x165 and 0x166).
[01:11:57 CET] <matej_k> when parsing hevc bytestream, the zero byte seems to be last byte of previous frame instead of first byte of next
[01:12:20 CET] <matej_k> so the AU starts with 3 bytes startcode
[01:12:25 CET] <matej_k> is that to be expected?
[01:20:24 CET] <jkqxz> Parsing with what?
[01:20:30 CET] <jkqxz> I don't think anything really cares, though.
[01:21:21 CET] <jkqxz> Though things writing it should do the right thing (zero byte at start of AU and in front of PS NALs).
[01:24:03 CET] <matej_k> jkqxz: thanks. right now it seems to leave zero byte trailing in previous AU, at least for the file im testing this with
[01:24:47 CET] <matej_k> on the other hand annex b says zero byte should be discarded, so it should probably be irrelevant
[01:24:58 CET] <matej_k> but it confuses timestamps in gstreamer HEVC parser
[01:25:28 CET] <matej_k> so now Im trying to figure out if the HEVC parser in ffmpeg is doign something wrong or just gstreamer should handle this better
[01:25:54 CET] <jkqxz> Um, what to timestamps have to do with it?  There are no timestamps in annex B.
[01:26:01 CET] <jkqxz> *what do
[01:26:50 CET] <JEEB> there can be SEI messages but those are unlikely :P
[01:27:08 CET] <JEEB> usually you just get a header that says the time base or so
[01:27:12 CET] <JEEB> if even that
[01:28:24 CET] <matej_k> jkqxz, the timestamps are not in stream of course; the problem happens when gstreamer assign timestamp to AU
[01:28:44 CET] <matej_k> because it looks the bufferr where there zero byte belongs
[01:29:00 CET] <matej_k> and uses that as timestamp for the AU
[01:29:15 CET] <matej_k> except when parsed by ffmepg that the zero byte is traling byte in previous AU
[01:29:28 CET] <matej_k> which is different buffer, with different timestamp
[01:30:13 CET] <matej_k> but specs says that zero byte is to be discarded, so i dont think what gstreamer does is correct
[01:30:37 CET] <jkqxz> How does it distinguish between zero_byte and the other zero bytes ((leading|trailing)_zero_8bits)?
[01:32:04 CET] <matej_k> it just searches for 0x000001, and once it finds, check if there is zero byte before it
[01:32:04 CET] <matej_k> if it is, moves the pointer
[01:32:31 CET] <matej_k> and that pointer position later determines timestamp of AU
[01:32:50 CET] <jkqxz> What if the previous NAL unit is padded with trailing_zero_8bits?
[01:33:52 CET] <jkqxz> You can always put as many zeroes as you like between NAL units.
[01:34:54 CET] <matej_k> yeah, looking at the code traling_zero_8bits would also mess up the timestamp assignment
[01:37:29 CET] <jkqxz> Generating timestamps from raw streams is in general a hard problem (though not quite as bad as H.264).  You need to at least look inside the packets to find the POCs.
[04:51:32 CET] <lpt10> hi
[04:55:41 CET] <lpt10> can you specify the RGB (and white) CIE xy primaries of an input footage to be encoded?
[04:56:01 CET] <lpt10> i.e, i have a sequence of scene-linear EXR files, with ACEScg AP1 RGB primaries, D60 whitepoint
[04:56:35 CET] <lpt10> and want to encode that to a Rec.2020 transfer function encoded sequence, with Rec.2020 RGB primaries, D65 whitepoint, 10 bit full range
[04:57:02 CET] <lpt10> one would expect a chromatic adaptation transform from D60 to D65, and indeed you have Bradford and "fake von Kries" transform to deal with this
[04:57:48 CET] <lpt10> but i cannot seem to find where to specify the RGB(W) xy primaries of the input space. Is it assumed to be always Rec.709/sRGB RGB primaries (and D65 whitepoint) ?
[05:01:36 CET] <lpt10> Or is it the input sequence assumed to be in the same RGB primaries (and whitepoint) of the output space?
[05:02:17 CET] <lpt10> i.e, choosing an for instance, Rec.2020 transfer function encoded sequence, with Rec.2020 RGB primaries, D65 whitepoint, would expect the input footage to be using the same RGB primaries (Rec.2020) and whitepoint (D65)
[07:19:52 CET] <SortaCore> bad JEEB
[07:20:33 CET] <SortaCore> turns out setting the interrupt_cb callback for RTSP gets it silently copied to the underlying TcpContext
[07:20:46 CET] <SortaCore> and you can't access that without more fun address hackery
[07:21:36 CET] <SortaCore> memset((AVIOInterruptCB *)(*(((int ***)rtsp_format_context->priv_data) + 1) + 8), 0, sizeof(AVIOInterruptCB));
[07:23:25 CET] <SortaCore> so my timeout for connecting ended up aborting all the streams
[07:23:30 CET] <SortaCore> el sob
[07:23:42 CET] <furq> what a beautiful line of code
[07:24:50 CET] <SortaCore> I have one that's worse for accessing the socket
[07:25:13 CET] <SortaCore> inside a tcpcontext, inside a urlcontext, inside a rtspstate, inside a formatcontext
[07:28:08 CET] <SortaCore> my motto is "you can use really evil code as long as you fully document it"
[07:28:39 CET] <SortaCore> come to think of it, I can read back the interrupt callback and check it matches my cb's function address
[07:29:02 CET] <SortaCore> ima add an if in thar
[07:32:09 CET] <SortaCore> now it's fully documented and not very likely to break things
[07:32:19 CET] <SortaCore> yay for progress
[07:40:38 CET] <fantesy> would anybody know how to output the average encode speed to a text file
[07:54:13 CET] <SortaCore> fantesy, you probably want the batch > operator
[07:55:22 CET] <JC_Yang> when avformat_find_stream_info failed with get_buffer() failed and thread_get_buffer() failed, what might be the cause? ffmpeg build with "--disable-encoders --disable-decoders --disable-demuxers --disable-muxers --disable-bsfs --disable-protocols --disable-filters --disable-parsers --enable-demuxer=h264,mpegps,hevc,mov,rtp,rtsp --enable-parser=h264,hevc --enable-protocol=file,rtp --enable-bsf=h264_mp4toannexb,hevc_mp4toannexb --disable-avfilter --disable-swres
[07:55:22 CET] <JC_Yang> sable-avdevice --enable-decoder=h264,hevc"
[07:57:00 CET] <fantesy> it only outputs per frame and i am doing a lot of these so i don't want to have to average them myself, does ffmpeg even store that, might i need to do verbose logging
[07:57:27 CET] <SortaCore> you may need sdp demuxer JC_Yang
[07:58:25 CET] <JC_Yang> the output indicate rtp is in action
[07:58:31 CET] <SortaCore> fantesy: afaik it doesn't, but I'm not a pro user
[07:58:41 CET] <SortaCore> JC: rtsp uses sdp in the headers
[07:58:50 CET] <fantesy> ok thanks
[07:59:23 CET] <JC_Yang> okay, will try immediately
[08:11:33 CET] <JC_Yang> does not help much, still "no frame! get_buffer() failed  thread_get_buffer() failed"
[08:17:06 CET] <Fig1024> I'm using C++ SDK for h264 encoder, trying to record 60 fps video, but for some strange reason, media info says file has "variable frame rate." I'm giving it exactly 60, it should say constant frame rate!
[08:18:21 CET] <SortaCore> set r_frame_rate and avg_frame_rate?
[08:18:35 CET] <SortaCore> although, forcing a higher framerate than what you have will just waste space
[08:20:47 CET] <Fig1024> variable frame rate is not good for video editing
[08:24:04 CET] <SortaCore> having wasted space isn't good for video editing
[08:24:29 CET] <Fig1024> also, I couldn't find either r_frame_rate or avg_frame_rate in avcodec.h
[08:25:19 CET] <c3r1c3-Win> When it comes to editing videos, CFR is the way to go, always.
[08:26:44 CET] <Fig1024> also, when I try to open Nvidia h264 encoder, it fails, I suspect it doesn't like variable frame rate. But I can't find how to change it
[08:27:27 CET] <SortaCore> c3r1c3-Win tag you're it
[08:27:55 CET] <c3r1c3-Win> lol
[08:31:02 CET] <MoziM> is writing images to disk slower than writing video?
[08:31:23 CET] <c3r1c3-Win> Depends, but almost 100% yes.
[08:32:04 CET] <c3r1c3-Win> Images = uncompressed video (usually). Also you have to add entries to the file tables (and whatnot) for each image saved.
[08:37:43 CET] <c3r1c3-Win> That said, if you're completely CPU bound (i.e. your drives can keep up and are always waiting on your CPU) then writing video can be slower than images.
[08:45:00 CET] <Fig1024> oops, my NVidia driver was too old to support nvenc
[08:46:29 CET] <MoziM> c3r1c3-Win: hmmm... it was an embedded board and the drive was an sd card. i'm thinking now that writing video may have been a little better, but not a whole lot.
[08:47:04 CET] <c3r1c3-Win> MoziM: Were you writing a compressed video or something uncompressed?
[08:48:07 CET] <MoziM> raw images
[08:49:14 CET] <MoziM> get buffered image from raspberry pi camers -> jetson tk1 -> opencv program -> write image with status overlay to disk
[09:15:05 CET] <astral> Hello, I have a very interesting case that I am unable to crack myself, perhaps anybody can take a look at the video file? context:   Video file comes from Hikvision's NVR (security IP cameras) internal API. You pass start time and end time parameters to this API and it produces a video file in memory available for download,
[09:15:47 CET] <astral> but this video file is flawed in several ways:
[09:16:05 CET] <astral> Duration of the video file is wrong (as seen in Mediainfo or VLC). My guess is this happens due to NVR storing video files in chunks and when attempting to download video by supplying specific start time and end time to NVR's API the software just creates a new video file in memory by extracting the needed parts from stored video and attaching the original video file's duration to the newly created one.
[09:16:35 CET] <astral> and also Audio cannot be played in most media players including VLC.
[09:16:51 CET] <astral> I have tried converting the video file using ffmpeg with different settings to try and fix these issues but the output video still has the same problems. What's interesting is that ffmpeg's ffplay is able to play the video file perfectly with sound and no disruptions. Therefore I figured there must be a way to convert the video file to normalize it for other players as well.
[09:17:08 CET] <astral> Mediainfo output of the video file in question:  https://pastebin.com/zNTpPi79
[09:17:27 CET] <astral> Output of ffmpeg: https://pastebin.com/vAZZV9CT
[09:17:55 CET] <astral> Video file itself:  https://www.dropbox.com/s/9ccptsuiqk2ntsv/1.zip?dl=0
[09:18:04 CET] <astral> Any help is greatly appreciated.
[09:37:32 CET] <JC_Yang> ever tried ffprobe?
[09:48:04 CET] <SortaCore> what is yuv4mpegpipe
[09:52:24 CET] <JC_Yang> astral, you should try ffprobe, it probably can detect the correct info of your file. since ffplay can do it
[09:53:09 CET] <JC_Yang> and then, instruct ffmpeg to use a probe, then you can remux the file correctly
[09:53:15 CET] <astral> Tried it yesterday, but just a second, let me do it again
[09:54:39 CET] <Fig1024> for some reason my h264 video recording always starts with broken keyframe, so first couple seconds show broken stuff
[09:55:49 CET] <astral> Here is the output from ffprobe  https://pastebin.com/wy0QjURM
[10:00:13 CET] <JC_Yang> okay that is a program stream
[10:00:22 CET] <astral> Yep, PS
[10:00:47 CET] <astral> Which is why timestamps are incorrect, because I requested only a small piece of a big video chunk
[10:01:31 CET] <astral> I tried -t parameter in ffmpeg to set the correct duration, but it still does not play audio
[10:36:13 CET] <gmipf> hello
[10:36:54 CET] <gmipf> I would like to report a bug for a wiki page: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos#IfYouNeedHelp
[10:37:22 CET] <durandal_1707> anybody can edit wiki
[10:37:49 CET] <gmipf> https://trac.ffmpeg.org/wiki/CompilationGuide/Centos
[10:38:05 CET] <gmipf> but I have no account
[10:39:06 CET] <JC_Yang> it's not a pure PS stream, contain some proprietary headers and data, so may confuse the codes.  cut 40 bytes from the head, everything works
[10:39:21 CET] <JC_Yang> astral
[10:39:58 CET] <astral> Hm, let me try that
[10:41:22 CET] <JC_Yang> the video is recognized as 2 mins long after I cut the 40 bytes, and play well
[10:41:38 CET] <gmipf> for the last step you need to add the line "--extra-libs=-lm" after \"--extra-libs=-lpthread \". Without lm you get the error message: "ERROR: libmp3lame >= 3.98.3 not found" on the latest snapshot, see: http://ffmpeg.org/pipermail/ffmpeg-user/2017-October/037662.html
[10:43:03 CET] <JC_Yang> just use any hex editor/tool you like
[10:43:13 CET] <astral> already on it, 1 min
[10:45:47 CET] <astral> are you sure it's the first 40 bytes? I did it but i still get incorrect duration and no audio
[10:46:05 CET] <JC_Yang> yes, 40, in decimal
[10:46:35 CET] <astral> it is undoubtedly Hikvision's proprietary codec data
[10:46:37 CET] <astral> Let me try again
[10:47:50 CET] <JC_Yang> the first 4 bytes should be 00 00 01 ba
[10:48:45 CET] <astral> yes, that is what I get as well. But still incorrect duration and no audio
[10:49:11 CET] <astral> What player are you using?
[10:49:19 CET] <JC_Yang> the player still does not play audio, yet. but at least the duration seems correct, 2mins here. mpc-hc
[10:49:53 CET] <Nacht> Removing the first 40 seems to work, nice find JC_Yang
[10:51:39 CET] <astral> Indeed, in works in MPC. VLC shows the wrong duration though
[10:51:54 CET] <JC_Yang> because it's a ps, still we need probe to find the complete(hopefully) media info, in api level, that is avformat_find_stream_info().
[10:52:46 CET] <astral> I was told on mailing list:   to convert you currently have to use an audio-only intermediate file or force audio pts.
[10:53:07 CET] <astral> I however do not have experience with syncing PTS with regards to video streams
[10:53:21 CET] <astral> Any insight on this matter?
[10:55:20 CET] <Nacht> I assume with asetpts
[10:55:36 CET] <Nacht> https://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts
[10:55:59 CET] <astral> ffplay is not unable to play audio as well, with 40 bytes removed
[10:56:06 CET] <astral> ffplay is unable*
[10:57:48 CET] <JC_Yang> maybe the best bet is RE the 40 bytes headers, it may contain some hints for the following streams, including syncing
[10:58:21 CET] <JC_Yang> had you tried their proprietary players?
[10:58:28 CET] <JC_Yang> can it play them well
[10:59:01 CET] <astral> Yes I have and it works there. But my goal is to display this video on a website, therefore I was going for H.264 & AAC
[10:59:16 CET] <astral> How is it possible that ffplay has the means to play this file flawlessly but VLC cannot?
[11:00:13 CET] <JC_Yang> ffplay do so correctly by *guess*, and definitely with the help of avformat_find_stream_info(),
[11:01:32 CET] <astral> I will try to produce the output of avformat_find_stream_info()
[11:02:25 CET] <astral> "to convert you currently have to use an audio-only intermediate file , Use FFmpeg to create the intermediate audio file."  Why would extracting the audio stream and then merging it with original video stream again solve this issue?
[11:07:19 CET] <gmipf> so I have changed the wiki page now.
[11:13:30 CET] <astral> Extracting audio from the video file and playing it separately in VLC/MPC works perfectly
[11:14:00 CET] <astral> I guess I will try extract the video now and merge them and convert simultaneously now
[11:27:46 CET] <gmipf> I have followed the instruction to install ffmpeg: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos
[11:28:30 CET] <gmipf> is ffmpeg-devel included in the installation process with last make install command?
[12:06:50 CET] <throstur> I'm trying to concatenate 4 mp4 files, but keep having problems. I tried with the concat protocol and it produced a broken output file because the files are not concat-able, so then I tried with a video filter but couldn't produce a valid filtergraph descritpion. Could anyone hook me up with "concat video filter" example with 4 input files (1-4.mp4) ?
[12:29:16 CET] <astral> In case anyone ever bumps into the same problem: I was able to solve mine by  first extracting audio from MPEG-PS video file  and encoding it to AAC, then producing video file by removing audio from the original MPEG-PS, and finally merging the two files together
[12:29:58 CET] <astral> I also used the -t parameter to correct the duration of both video and audio files  before merging them
[12:30:50 CET] <astral> Doing this manually is not the best option, sure, but I always have the exact video duration since it is stored in my app, so..
[12:35:57 CET] <throstur> my problem was videos not same size :p snapchat exports some with black bars and some without... heh
[13:31:04 CET] <ayum> Hi, I am current using a linked-list to cache AVFrame in the libavfilter, but I have to return a AVFrame everytime.  anyone knows how to properly cache AVFrame in libavfilter?
[13:32:21 CET] <ayum> If I return a NULL pointer in the filter process function, they I get segment fault. my current idea is to create a dummy AVFrame. and give it a wrong pts, so ffmpeg will ignore it when output
[16:20:05 CET] <neverminder> How to see what's being recorded? Is it possible somehow to use ffplay for that?
[16:21:33 CET] <DHE> depends. some file types will allow viewing the file as it's being written. otherwise you'll need to do a multi-output from ffmpeg to a viewable stream format
[16:24:48 CET] <neverminder> Well I'm doing this: ffmpeg -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -vcodec copy video.mkv
[16:25:00 CET] <neverminder> so the file format is mkv, would that work?
[17:00:52 CET] <alexpigment> hey guys. i'm trying to figure out whether I'm looking at a bug or just a feature limitation with the videotoolbox encoder on macOS
[17:01:38 CET] <alexpigment> in the "Stream #0:0" information, it shows "q=2-31" by default. I can seemingly change these numbers with qmin and qmax, but it has no effect on file size at all
[17:01:51 CET] <alexpigment> even if I set -b:v 0
[17:02:05 CET] <alexpigment> (the default bitrate is 200kbps otherwise)
[17:02:18 CET] <alexpigment> would that qualify as a bug?
[17:20:52 CET] <kepstin> maybe, but it could just be that the videotoolbox interface simply has no way to set min/max qp values - in which case it's unfixable.
[17:21:17 CET] <kepstin> hmm.
[17:21:18 CET] <alexpigment> kepstin: I considered that, but I don't know how to confirm that
[17:21:41 CET] <alexpigment> I'd like to log it up so we can whip this encoder into shape, but I don't understand where the limitations are coming from
[17:22:56 CET] <kepstin> well, here's a list of properties: https://developer.apple.com/documentation/videotoolbox/vtcompressionsession/compression_properties
[17:23:53 CET] <alexpigment> yeah it seems like kVTCompressionPropertyKey_Quality should at least be implemented
[17:24:11 CET] <alexpigment> I don't really care about qmin/qmax; it was just the only way I could seemingly get something related to quality
[17:24:33 CET] <ritsuka> kVTCompressionPropertyKey_Quality is not implemented for h.264 in VideoToolbox
[17:24:37 CET] <ritsuka> I didn't check hevc yet
[17:24:49 CET] <alexpigment> ah
[17:25:13 CET] <alexpigment> how can you tell?
[17:25:41 CET] <alexpigment> this documentation doesn't mention hevc or h.264 specifically
[17:25:46 CET] <ritsuka> there is a function to ask an encoder which properties can be set
[17:26:51 CET] <alexpigment> well, as a more general question, is there a way at all to get a bitrate that is variable based on the complexity of the source?
[17:27:01 CET] <alexpigment> or is it always ABR?
[17:36:10 CET] <alexpigment> kepstin: do you see any reason why kVTCompressionPropertyKey_Quality couldn't be implemented for H.264?
[17:36:20 CET] <alexpigment> i'm not seeing the restriction that ritsuka is talking about
[17:37:57 CET] <ritsuka> well it's easy to check, start and encode, set only the quality and not the bitrate in the videotoolbox session, see what happens
[17:38:23 CET] <alexpigment> ritsuka: are you talking about ffmpeg's implementation or videotoolbox itself?
[17:38:31 CET] <ritsuka> videotoolbox itself
[17:38:53 CET] <alexpigment> is there a reference encoder, or do I have to write an application to test that?
[17:39:05 CET] <alexpigment> (option b is above my skill level)
[17:39:52 CET] <ritsuka> I added support for videotoolbox h.264 encoder in handbrake years ago
[17:40:23 CET] <alexpigment> ritsuka: are you sure it's not a hardware-specific limitation you're running into?
[17:40:28 CET] <alexpigment> what is your CPU/GPU/
[17:40:29 CET] <alexpigment> ?
[17:42:32 CET] <alexpigment> ritsuka: I'm not trying to be incredulous. I just have to make 100% sure of its limitations before I give up on this encoder
[17:44:21 CET] <ritsuka> you can run https://subler.org/downloads/VideoToolboxTest.zip and see the supported keys for each codec
[17:49:31 CET] <alexpigment> ritsuka: thanks. apparently I need to update macOS to test this, so I'll check it out afterward
[17:53:46 CET] <kepstin> alexpigment: there's no reason it couldn't be implemented, but whether it is or not is completely up to apple, not the ffmpeg decs.
[17:54:31 CET] <alexpigment> understandable. I was confused initially if ritsuka was saying it wasn't implemented in ffmpeg or videotoolbox, since I didn't see any documentation saying it wasn't available for h.264
[17:54:58 CET] <alexpigment> it sounds like it isn't though, which I'll confirm once this 6gb download/install for the new macOS finishes
[18:04:19 CET] <redblob> is there an option or audio filter that can be used to emit silence when there is missing time in the input (like errors/breaks in a TS stream) when converting a video+audio file to an audio-only file?
[18:06:12 CET] <redblob> currently if I convert a TS with problems, to an aac output, it will just skip over the bad time and pick up when it can decode again, so a 1hr file with 5 min of issues ends up 55 min long, I want it to be the original hr with silence where the audio isn't there
[18:18:47 CET] <adgtl> ping
[18:35:39 CET] <teratorn> redblob: perhaps if you do an amix filter with a silent source
[18:35:48 CET] <teratorn> redblob: it will automatically "fix" the broken parts
[19:05:21 CET] <redblob> teratorn, interesting - thanks I'll give it a try.
[19:19:40 CET] <alexpigment> is cehoyos on trac just a dick in general?
[19:19:52 CET] <alexpigment> or just mostly a dick?
[19:20:39 CET] <JEEB> he can be rather cold and not understanding
[19:21:00 CET] <JEEB> also one of the few people roaming the tickets. when he understands the issue he will attempt to do something about it, though
[19:21:04 CET] <alexpigment> seems like it
[19:22:19 CET] <Netun0> Is It possible for any reason that x11grab are working just fine to save in file and really doesn't in go with rtmp://? because I can't do it work, already did all kind of combinations in command. lol
[19:22:24 CET] <BtbN> There are a lot of weird and annoying people reporting stuff on track. So I can understand why he behaves like a better bot a lot of the times.
[19:23:46 CET] <JEEB> yes, he will template the first response or responses
[19:23:49 CET] <sfan5> alexpigment: I'd definitely say it is the issue reporters responsibility to verify that the issue is still present on HEAD.
[19:24:31 CET] <alexpigment> sfan5: you'll have to pardon my ignorance on this, but I'm not an ffmpeg developer, and I don't even really know what HEAD means. i did build ffmpeg yesterday though
[19:24:38 CET] <alexpigment> and noted that in the issue
[19:25:56 CET] <JEEB> alexpigment: he just wants "I tested this with the current master" or so
[19:26:03 CET] <JEEB> HEAD means the tip of master usually
[19:26:05 CET] <sfan5> " test current FFmpeg git head" == clone this https://github.com/ffmpeg/ffmpeg, compile it and verify that the same stuff happens
[19:26:18 CET] <JEEB> > linking to the github mirror
[19:26:28 CET] <JEEB> https://git.videolan.org/git/ffmpeg.git , was it?
[19:26:48 CET] <alexpigment> i built with brew install ffmpeg
[19:27:00 CET] <sfan5> i think brew has a --HEAD flag or something similar
[19:27:27 CET] <sfan5> JEEB: it's a lot faster than the ffmpeg.org git
[19:27:44 CET] <alexpigment> sfan5: thanks
[19:28:51 CET] <alexpigment> at any rate, i'm not trying to say there's a reason for checking the newest available code. I just think it's a dumb move to come into an issue, say it's not valid because of some seemingly unwritten rule, and then assign me with more work. like, take less time and just copy and paste the information expressly given in the issue details
[19:29:04 CET] <JEEB> sfan5: ffmpeg.org should anyways be videolan.org
[19:29:20 CET] <JEEB> someone just decided they wanted some redirection
[19:29:22 CET] <alexpigment> er, not trying to say there's *not* a reason
[19:29:49 CET] <JEEB> alexpigment: it's a template response to make sure the thing still happens on the tip
[19:29:50 CET] <sfan5> you know he might not have a mac?
[19:30:03 CET] <alexpigment> sfan5: right, and that's why he shouldn't be commenting on the issue at all
[19:30:13 CET] <alexpigment> that's exactly my point
[19:30:23 CET] <alexpigment> stay out of issues that do not concern you
[19:30:34 CET] <alexpigment> especially when all the relevant information is there
[19:30:51 CET] <alexpigment> and the bug submission template has been followed to a T
[19:31:01 CET] <sfan5> i would agree with you if he was an outsider
[19:31:23 CET] <sfan5> but it's the "job" of project-affiliated devs to categorize issues and ascertain whether it's a "real" issue or not
[19:31:35 CET] <alexpigment> sfan5: I don't give people passes like that. good developers are dicks too. i'm not questioning his developer skills. i'm questioning his people skills
[19:33:28 CET] <sfan5> hmm yea i guess i can agree with that
[19:33:34 CET] <alexpigment> so now I have to spend the next 30 minutes following these unwritten rules and recompiling to verify an issue that is 99.999% certain to still be an issue, just because some person that was never socially adjusted can have some extra details that he still won't do anything with because he probably doesn't have a mac
[19:33:52 CET] <alexpigment> hence my frustration
[19:33:54 CET] <sfan5> but as BtbN has said, it's not surprising considering the shit FOSS developers always have to deal with
[19:33:55 CET] <alexpigment> end of rant :)
[19:45:23 CET] <jkqxz> alexpigment:  You got what you paid for.
[19:45:35 CET] <jkqxz> Also, while you may be 99.999% certain, you are also wrong.
[19:46:53 CET] <alexpigment> jkqxz: thanks
[19:46:59 CET] <jkqxz> Hardware codecs are now annotated with metadata which provides that information to an API user, and the ffmpeg utility uses it to determine whether a device is needed.
[19:47:49 CET] <ritsuka> alexpigment: which version of macOS are you running?
[19:47:49 CET] <jkqxz> (Which was not possible in previous versions, hence the message.)
[19:50:36 CET] <alexpigment> ritsuka: just updated to 10.13.2 a few minutes ago to test the project you linked me to
[19:52:36 CET] <alexpigment> jkqxz: are you implying that there should be a warning?
[19:52:48 CET] <alexpigment> why have a warning if the default case gives you that warning?
[19:53:53 CET] <alexpigment> anyway, still building over here on this Core M...
[19:55:08 CET] <jkqxz> If you have an encoder which requires a device and you don't provide one, yes there should be a warning.
[19:55:34 CET] <alexpigment> jkqxz: x264 requires a device and it doesn't make you list your CPU
[19:55:40 CET] <alexpigment> it assumes you have one
[19:55:49 CET] <alexpigment> nvenc requires a device and it doesn't make you list your gpu
[19:55:54 CET] <alexpigment> it assumes you have one
[19:56:00 CET] <alexpigment> specifically assumes you have exactly one
[19:56:12 CET] <alexpigment> multi-gpu situations are opt-in
[19:56:22 CET] <alexpigment> you don't warn for the common case
[19:56:32 CET] <jkqxz> nvenc inherits the device from its input frames.
[19:56:34 CET] <alexpigment> that's not logically in any field
[19:56:51 CET] <alexpigment> *logical
[19:57:22 CET] <BtbN> nvenc also does not have a software-fallback.
[19:57:25 CET] <alexpigment> jkqxz: hear me out. if you warn in a default case where the vast majority of users will be, and you don't tell the user what to even do to remedy such warnings, that is bad design
[19:57:43 CET] <jkqxz> Anyway, here "device" means "some sort of hardware device exposed by the generic hardware device framework".
[19:57:56 CET] <alexpigment> a) you should not warn in the default case, b) when you do have to warn (in the non-default case) you provide suggestions
[19:58:25 CET] <alexpigment> jkqxz: you're speaking from a developer's point of view, and in this case, the user is who you should be focusing on
[19:58:48 CET] <alexpigment> there is a warning given that does not provide any suggestions
[19:59:11 CET] <alexpigment> and ignoring the warning is somehow the correct solution
[19:59:46 CET] <jkqxz> For the videotoolbox case.
[19:59:51 CET] <alexpigment> there is no logic there, regardless of the technical explanation of why the code does this
[20:00:40 CET] <alexpigment> anyone who's ever written software knows that there's a reason why developers do not run companies. developers are notoriously terrible at making sound end-user decisions
[20:01:02 CET] <alexpigment> and i've met very very few developers who do not make terrible end-user decisions
[20:01:24 CET] <alexpigment> end of second rant (which I didn't start)
[20:06:06 CET] <jkqxz> I guess from my point of view ffmpeg is fundamentally a tool for developers.  Using it without understanding what is going on is bound to lead to confusion and pain.
[20:07:22 CET] <alexpigment> jkqxz: I do get that distinct vibe around here. given that it's a powerful tool and google search often brings up results with explicit instructions on how to solve a specific problem with ffmpeg, I don't really see it that way
[20:07:30 CET] <jkqxz> So making things which are friendly to people who don't understand what is going on is not, from my point of view, a priority.
[20:07:39 CET] <alexpigment> I obviously do not have stats, but I'd say the ratio of non-dev to dev is probably a lot higher than you'd think
[20:08:23 CET] <alexpigment> jkqxz: well, I'm certainly not a dev. perhaps I was personally confused by the message and had no idea what to do about it
[20:09:41 CET] <alexpigment> anyway, I'm not trying to make enemies here. I want to get these hardware encoders from the state they're currently in to something that has a similar place as x264 based on a particular use-case
[20:09:48 CET] <jkqxz> (Hence also trying to make people understand what is going on, rather than just answering questions.)
[20:10:20 CET] <alexpigment> jkqxz: yes, but please understand that a warning that occurs in a default case without any suggestions for remedying it is not acceptable in any scenario
[20:10:38 CET] <alexpigment> I would fire a developer right on the spot if they tried to defend that
[20:10:56 CET] <alexpigment> it's like 10 Commandments level of wrong
[20:20:11 CET] <Netun0> someone available to help me out setup a command line ffmpeg to stream with x11grab from a aws ec2 to periscope and/or youtube?
[21:10:52 CET] <SpeakerToMeat> Hello
[21:11:22 CET] <SpeakerToMeat> Question, is mxf_opatom format OP1a? ANy way to output OP1a compatible MXF from ff?
[21:12:38 CET] <alexpigment> SpeakerToMeat: i was helping someone with this recently. I believe they are the same, based on my interaction with that person
[21:12:56 CET] <alexpigment> the regular mxf muxer will require that you have a video stream, so it won't work for audio streams
[21:13:04 CET] <SpeakerToMeat> ok, thank you alexpigment
[21:13:05 CET] <alexpigment> mxf_opatom will allow you to create those streams
[21:13:35 CET] <SpeakerToMeat> alexpigment: Yes, I'm just doing a test, I have an xdcam sourced mpeg2 inside a mov, and I want to move it to MXF OP1a (the expected for xdcam) without transcoding.
[21:14:01 CET] <SpeakerToMeat> I found something about using ffmbc but I preffer to use ffmpeg whenever possible
[21:29:57 CET] <ArsenArsen> how do I set the avfoundation video frame location?
[21:49:56 CET] <php67> hi, I just tried to convert a bmp to jpg with ffmpeg -i 01.bmp 01.jpg It works but the jpg image is a bit grumsy. Any chance to adjust the quality of the jpg from ffmpeg?
[21:50:24 CET] <durandal_1707> php67: -qscale 0?
[21:50:38 CET] <php67> I'll try brb
[21:53:30 CET] <php67> -qscale 0 didnt work but then I tried -qscale 2 cause I read somewhere it goes from 2-31 or something.. but with 2 is much better thx.
[21:53:49 CET] <durandal_1707> yea
[21:53:59 CET] <kepstin> yeah, the jpeg encoder defaults to -qmin 2, iirc
[21:54:12 CET] <kepstin> you can change that, but 2 should already be pretty decent
[21:54:39 CET] <alexpigment> going down to 0 on a jpeg is getting close to defeating the purpose of jpeg (over PNG, for example) anyway
[21:55:14 CET] <php67> would it be better with png?
[21:55:33 CET] <alexpigment> php67: if there are a lot of solid colors and also text, yes
[21:56:06 CET] <alexpigment> in other words, if it's purely synthetic content, png is usually what you'd use. if it's a photo that was taken, jpeg is usually better
[21:57:51 CET] <php67> wow my bmp is 1.44mb and the png I just generated is 71kb and I cant see any major diff :)
[21:58:04 CET] <alexpigment> you shouldn't be able to see a difference
[21:58:06 CET] <alexpigment> it's a lossless codec
[22:00:35 CET] <php67> thx im amazed. So now if I want to convert a bunch of bmp in same folder into a bunch of png in same folder is this correct then? ffmpeg -i *.bmp -qscale 2 %03d.png
[22:01:45 CET] <kepstin> php67: no, ffmpeg can't do batch conversion like that by itself.
[22:02:06 CET] <kepstin> php67: (you can write a shell or batch script loop that runs ffmpeg a bunch of times, tho)
[22:02:26 CET] <alexpigment> you can also get rid of the qscale 2 by the way
[22:02:39 CET] <alexpigment> png is lossless so I'm guessing it ignores qscale completely
[22:02:58 CET] <php67> I'll try see if there is a diff.
[22:03:42 CET] <php67> no diff.. so -qscale 2 is not nessesary
[22:04:37 CET] <php67> the %03d.png would work I think if instead of bmp it was a movieformat like ex. mpeg or avi etc.
[22:04:42 CET] <ArsenArsen> how do I set the avfoundation video frame location?
[22:06:48 CET] <alexpigment> php67: yes, because that basically is saying create a PNG for every frame in the source video. the input in this case is a single frame as well. as kepstin said, you need a script to actually run ffmpeg multiple times because each one has a new infile and outfile
[22:08:33 CET] <php67> Oki thanks for the help, long live ffmpeg :) ..I'll try make a batch with loop tc&merychristmas :)
[22:28:40 CET] <alexpigment> ok, I've got a weird one that I don't fully understand. I'm testing with the AMF encoder. When I use MP4 as my output container and play in Windows Media Player, high motion scenes will cause all kinds of visual garbage (colors will get weird, heavy macroblocks, etc)
[22:28:54 CET] <alexpigment> playing the same video in VLC doesn't result in the same problem
[22:29:10 CET] <alexpigment> outputting to MKV and playing in Windows Media Player doesn't cause the problem
[22:29:30 CET] <alexpigment> using another hardware codec (e.g. NVENC) with similar settings in mp4 output doesn't cause the same problem
[22:29:40 CET] <alexpigment> any ideas what this would point to?
[22:32:56 CET] <jkqxz> Can you post an example stream?
[22:33:11 CET] <jkqxz> (I didn't see that when testing, but I didn't run it on anything particularly nasty.)
[22:33:13 CET] <teratorn> redblob: did it work?
[22:33:28 CET] <alexpigment> jkqxz: yes, give me 5
[22:33:34 CET] <alexpigment> (minutes)
[22:41:02 CET] <ChocolateArmpits> Has anyone tried to produce an encoding table that would suggest optimal settings for given conditions? For example specifying intended bitrate would give optimal preset and resolution settings, possibly suggesting two pass encoding for added benefit?
[22:41:08 CET] Action: kepstin has no idea what the 'amf' encoder is, there's nothing obvious in ffmpeg by that name?
[22:41:57 CET] <kepstin> ChocolateArmpits: for x264 you don't need a table - it's just "use -crf mode at a quality you like with -preset veryslow, or twopass if you're targetting a specific filesize", done.
[22:43:04 CET] <alexpigment> jkqxz: http://s000.tinyupload.com/index.php?file_id=68868310432733014351
[22:43:29 CET] <ChocolateArmpits> kepstin, well sometimes the only option is to reduce resolution, those options do not help at that by themselves.
[22:44:08 CET] <alexpigment> jkqxz: command was https://pastebin.com/VJb3xYat
[22:44:27 CET] <alexpigment> note: the video linked is the source video, not the resultant "bad" video
[22:45:23 CET] <alexpigment> oddly, the artifacting is different on systems with nvidia and amd graphics, so I suspect this causes hardware decoders or dxva2 to freak out
[22:45:43 CET] <kepstin> ChocolateArmpits: ok, but that depends so much on the video content that you can't really do any useful general recommendations, other than say "if you're using two pass and the video quality is too low, try reducing the resolution" :/
[22:46:24 CET] <furq> kepstin: amf is the amd vce encoder
[22:46:27 CET] <furq> it got added a few days ago
[22:46:54 CET] <kepstin> oh, fun.
[22:47:15 CET] <jkqxz> Right, I was about to say that that was made with x264...
[22:47:18 CET] <alexpigment> kepstin: what's more fun is the sheer lack of b-frames ;)
[22:47:19 CET] <jkqxz> I was meaning the result?
[22:47:28 CET] <jkqxz> Since it will likely be system-dependent.
[22:47:31 CET] <alexpigment> jkqxz: coming up
[22:48:29 CET] <alexpigment> jkqxz: http://s000.tinyupload.com/index.php?file_id=50058129558109292999
[22:48:50 CET] <jkqxz> I suspect those rate options won't do anything when you've specified the QP values, but I don't actually know.
[22:48:52 CET] <alexpigment> i should note that i just added -g 30 to my command line to exacerbate the issue, although it occurs with the standard gop length as well
[22:48:58 CET] <jkqxz> They all get passed to the driver, so maybe.
[22:48:59 CET] <kepstin> the 'amf' name is confusing, because iirc isn't amf the name of the serialization used in flv/rtmp?
[22:49:29 CET] <alexpigment> jkqxz: they're there because I was trying to mimic a virgin test against Staxrip. it occurs with much simpler commands
[22:49:45 CET] <alexpigment> basically i compare against staxrip to determine if it's an ffmpeg-specific thing
[22:50:13 CET] <kepstin> I guess this AMF stuff is specific to windows?
[22:50:37 CET] <kepstin> (I presume this'll be exposed via vaapi or vdpau or something on linux, maybe)
[22:50:39 CET] <alexpigment> kepstin: yeah, I think linux would be through vaapi
[22:50:54 CET] <jkqxz> Currently.  They have said they will do it on Linux, but it will probably be in the crazy proprietary driver and therefore not very useful.
[22:53:16 CET] <alexpigment> jkqxz: let me know if you aren't seeing the issue on your end. I've verified it on two Windows 7 systems, but I haven't looked at Win10
[22:53:43 CET] <ChocolateArmpits> kepstin, well I would surely like it hands free. ffmpeg recently got two vmaf based filters that measure video quality. My idea is to run tests involving different sets of video that have different motion levels, repeat this for different resolutions vs presets vs pass count and receive quality score. Under given bitrate constraints and knowing the amount of motion, the previous data can be used to give settings for optimal quality.
[22:53:52 CET] <jkqxz> Just in that video I already see brokenness at the top of frame 2.
[22:53:52 CET] <miller7> can I use two -c copy outputs with ffmpeg? I'm trying to but only the first one seems to work
[22:54:49 CET] <kepstin> huh, the x.org radeon feature page says vaapi support is "DONE" up to artic islands (amdgpu kernel driver), apparently via some code in mesa.
[22:55:29 CET] <kepstin> who knows if it actually works :/
[22:55:41 CET] <jkqxz> VAAPI on AMD is completely fine for decode.
[22:55:46 CET] <jkqxz> It's not so good for encoding.
[22:56:09 CET] <alexpigment> i'm kinda regretting buying an rx 550 for testing. it sounds like the vega series has b-frame support
[22:56:23 CET] <jkqxz> ?  I get B-frames from a GCN 2.
[22:56:31 CET] <jkqxz> You don't seem to have any here.
[22:56:32 CET] <alexpigment> really?
[22:56:38 CET] <jkqxz> Yes.
[22:56:54 CET] <alexpigment> what card exactly?
[22:57:50 CET] <jkqxz> Bonaire Pro.
[22:58:31 CET] <alexpigment> hmmm
[22:58:49 CET] <alexpigment> i looked this up yesterday and found random forum talk that seemed to indicate polaris chips don't have b-frames
[22:59:32 CET] <alexpigment> https://github.com/Xaymar/obs-studio_amf-encoder-plugin/wiki/Hardware-VCE3.4
[22:59:43 CET] <alexpigment> "Version 3.4 added support for H265/HEVC encoding at the cost of reduced throughput in H264/AVC and H264/SVC encoding and also losing the ability to encode B-Frames."
[23:00:27 CET] <alexpigment> good ol' amd doing what they do best
[23:00:29 CET] <miller7> https://pastebin.com/ugVSkMZu Command works fine (creates mp4 files and publishes stream). It does not create JPG file though. Any pointers?
[23:01:01 CET] <miller7> if I remove the first -c copy, it works as expected
[23:01:52 CET] <kepstin> miller7: what format is your camera actually producing, mjpeg?
[23:02:37 CET] <miller7> kepstin: is there a command to check it? ffmpeg -i <input> ?
[23:03:17 CET] <sfan5> ffprobe /dev/camera should work
[23:03:29 CET] <sfan5> also the second -c copy would need to be just before the jpg filename
[23:03:32 CET] <kepstin> "ffmpeg -list_formats all -i /dev/video0" or so will list everything the camera supports
[23:03:55 CET] <kepstin> nah, the positioning is fine, it just has to be after the first output file and before the second output file
[23:04:18 CET] <miller7> input #0, mpegts
[23:04:43 CET] <jkqxz> alexpigment:  <http://sprunge.us/GiQM>
[23:04:57 CET] <kepstin> miller7: please pastebin the complete output
[23:05:17 CET] <alexpigment> jkqxz: what's the context?
[23:05:48 CET] <alexpigment> are you showing me that yours has b frames?
[23:08:11 CET] <jkqxz> Yes.  I'm just looking at encoding your file now.
[23:09:16 CET] <alexpigment> jkqxz: yeah, I trust that it lets you on your end. I guess I just bought the wrong series of card. was really just looking for a middle-of-the-road chip from a recent gen, and the only option was the 550
[23:09:49 CET] <alexpigment> oh well, it wasn't the most expensive card in the world
[23:10:04 CET] <jkqxz> It gives output which is broken in WMP as well for me.
[23:10:07 CET] <jkqxz> Works in mpv.
[23:10:42 CET] <alexpigment> jkqxz: yeah, I just don't have the knowledge to even know what that would mean. I really do think it's something related to decoding through hardware though
[23:11:12 CET] <alexpigment> as if the MP4 container has info that is incorrect, and the hardware decoders are using the info
[23:11:26 CET] <jkqxz> <http://ixia.jkqxz.net/~mrt/ffmpeg/broken_amf.mp4> is my output.
[23:11:51 CET] <alexpigment> yep
[23:11:58 CET] <miller7> kepstin: You were right. The format of the input has the problem.
[23:12:53 CET] <kepstin> miller7: if your input is not mjpeg, you can't use "-c copy" to save to a jpeg file, you have to transcode it.
[23:13:06 CET] <jkqxz> alexpigment:  Maybe send it to the AMD guy on the ffmpeg ML?
[23:13:27 CET] <alexpigment> jkqxz: mikhail?
[23:13:30 CET] <jkqxz> Yeah.
[23:13:37 CET] <alexpigment> ok, I'll do that
[23:13:46 CET] <jkqxz> Or open a bug on trac and point him at it.
[23:14:00 CET] <alexpigment> still though, what does it mean if it's just MP4 output?
[23:14:13 CET] <alexpigment> i doubt his code has anything to do with the mp4 container
[23:14:28 CET] <alexpigment> although it does seem specific to AMF
[23:14:33 CET] <alexpigment> ok, I just talked myself into a circle
[23:14:38 CET] <alexpigment> I'll email him
[23:14:39 CET] <jkqxz> This is a really trivial stream for the container (I dropped the audio in mine, too).
[23:14:48 CET] <jkqxz> So I think it must be AMD's problem.
[23:14:56 CET] <jkqxz> What else does WMP play?
[23:15:16 CET] <jkqxz> Can I put H.264 in a WMV container?
[23:15:17 CET] <alexpigment> jkqxz: ts, mkv, mov(ish), etc
[23:15:28 CET] <alexpigment> probably not officially, but I'm sure it'll play it
[23:15:29 CET] <jkqxz> (ASF, whatever it is.)
[23:15:34 CET] <alexpigment> I just compared it with MKV
[23:15:42 CET] <alexpigment> but I didn't go further than that
[23:16:14 CET] <jkqxz> Hmm, yeah.  It works in an ASF container.
[23:16:15 CET] <miller7> kepstin: thanks a lot for the assistance
[23:16:17 CET] <jkqxz> That's pretty weird.
[23:17:23 CET] <jkqxz> The timestamps aren't obviously doing anything funny.  I've no idea what else to suggest as a possible container difference.
[23:17:45 CET] <alexpigment> ts is also broken
[23:17:58 CET] <alexpigment> although i feel like ffmpeg's ts implementation is generally broken
[23:18:08 CET] <alexpigment> mov broken
[23:18:39 CET] <alexpigment> hmmmm, avi and wmv are fine
[23:18:48 CET] <alexpigment> i know avi doesn't officially support b-frames
[23:19:20 CET] <alexpigment> is it possible it's related to something about b-frame metadata (even though mine isn't making b-frames)
[23:20:23 CET] <jkqxz> If I enable B-frames it's crazy broken.
[23:20:46 CET] <alexpigment> are b frames bigger than p frames?
[23:21:06 CET] <jkqxz> A lot smaller.
[23:21:17 CET] <alexpigment> ok, well that theory is out
[23:21:54 CET] <jkqxz> <http://ixia.jkqxz.net/~mrt/ffmpeg/broken_amf_bframes.mp4>
[23:22:32 CET] <alexpigment> yeah, that one got nice and choppy at the end for me ;)
[23:22:58 CET] <jkqxz> It's like WMP is just picking totally the wrong reference frame at times.
[23:23:06 CET] <alexpigment> right
[23:24:48 CET] <jkqxz> Can I commend to you the merits of only using ffmpeg-based players which do not do that?  :)
[23:29:06 CET] <jkqxz> ffmpeg output does agree exactly with the reference decoder.  The stream is in some sense "correct".
[23:29:22 CET] <alexpigment> sorry back
[23:30:02 CET] <jkqxz> (All 1866240000 bytes of it.)
[23:30:17 CET] <alexpigment> jkqxz: that's an understandable position. however, if you create something that exposes a bug in the player that 90%+ of people use, it's kinda your bug at that point
[23:30:30 CET] <alexpigment> sadly
[23:31:19 CET] <rmbarbosa> hello good people
[23:31:29 CET] <jkqxz> Doesn't everyone play videos in chrome nowadays?
[23:31:50 CET] <alexpigment> jkqxz: i'll grant you this technicality :)
[23:32:01 CET] <rmbarbosa> i'm having a problem compiling ffmpeg on windows 64 with visual studio 2017 and msys2 64
[23:32:23 CET] <rmbarbosa> everything is smooth running until the ./configure
[23:32:41 CET] <rmbarbosa> ./configure -toolchain=msvc -arch=x86_64 -enable-yasm -enable-asm -enable-static -disable-examples -disable-programs -enable-libx264 -enable-gpl -prefix=./install
[23:32:52 CET] <rmbarbosa> throws:
[23:32:53 CET] <rmbarbosa> Unknown option "-toolchain=msvc".
[23:33:07 CET] <rmbarbosa> has anybody ever had this issue??
[23:33:17 CET] <rmbarbosa> thank you...
[23:34:30 CET] <alexpigment> rmbarbosa: is it possible this is related? https://github.com/telegramdesktop/tdesktop/issues/2646
[23:34:43 CET] <jkqxz> rmbarbosa:  What version?  That really shouldn't be an unknown option.
[23:35:26 CET] <jkqxz> Oh, that might make more sense.
[23:35:29 CET] <SortaCore> I'm using VS 2015, msys2 64, works ok
[23:35:52 CET] <rmbarbosa> this happened to me today in the beginning of the afternoor
[23:36:10 CET] <rmbarbosa> then for some unexplicable reason it worked...
[23:36:17 CET] <rmbarbosa> then i closed the bash
[23:36:36 CET] <rmbarbosa> and when i opened it again is stuck on the same problem
[23:36:40 CET] <SortaCore> you're meant to run the bash from VS 2015 command prompt
[23:36:52 CET] <rmbarbosa> yes... well to be more clear
[23:37:01 CET] <miller7> Any suggestion for hardware to use with my linux box to capture full HD from DVB-T2 free-to-air channel? I want to connect an antenna to my linux so I can capture and save the stream.
[23:37:03 CET] <rmbarbosa> i've opened a terminal cmd
[23:37:25 CET] <rmbarbosa> called vcvars64.bat
[23:37:30 CET] <alexpigment> miller7: does hauppauge make anything linux compatible? I use a lot of their hardware for OTA capture
[23:37:37 CET] <rmbarbosa> then C:\msys64\msys2_shell.cmd -mingw64 -use-full-path
[23:37:59 CET] <rmbarbosa> i've checked the "where link" and "where cl"
[23:38:06 CET] <miller7> alexpigment: I don't know. Never done this before
[23:38:08 CET] <rmbarbosa> all is pointing to the correct locations
[23:38:15 CET] <SortaCore> yea, this looks valid so far
[23:38:20 CET] <SortaCore> did you CD into ffmpeg?
[23:38:27 CET] <rmbarbosa> but the configure just not working
[23:38:29 CET] <SortaCore> from bash
[23:38:41 CET] <alexpigment> miller7: https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-dualHD
[23:38:41 CET] <rmbarbosa> yes i've cd to ffmpeg
[23:38:42 CET] <miller7> alexpigment: http://www.hauppauge.com/site/support/linux.html has many different models. Any particular you suggest?
[23:39:09 CET] <miller7> thanks :)
[23:39:17 CET] <rmbarbosa> 'm using vs2017
[23:39:20 CET] <SortaCore> I can download latest git and try again
[23:39:25 CET] <alexpigment> miller7: i'd recommend dualHD or quadHD. i've used them both. i've also used the 955Q, but it only has one tuner
[23:39:28 CET] <SortaCore> but I'm using vs2015, it may not support 2017
[23:39:37 CET] <rmbarbosa> humm
[23:40:06 CET] <SortaCore> the configure has a log file you can check
[23:40:52 CET] <SortaCore> look for under ffmpeg\ffbuild\config.log
[23:41:17 CET] <rmbarbosa> ok.. i will look at the config.log...
[23:42:50 CET] <miller7> alexpigment: How can I use DVB-C and DVB-T2 at the same time with it? It only has 1 cable antenna connection
[23:43:15 CET] <alexpigment> miller7: the dualhd and quadHD are split internally
[23:43:30 CET] <rmbarbosa> is there a way to clean the configure? and restart from clean?
[23:43:31 CET] <alexpigment> but if you're trying to hardwire one to an antenna and one to cable, you'll need two cards probably
[23:45:04 CET] <Li> I'm wondering if there is anyway to watch video in linux without GUI! and no one seems to have a proper answer in #linux channel. Can anyone help here?
[23:45:47 CET] <jkqxz> You mean at the console, without X or anything like that?
[23:45:50 CET] <alexpigment> Li: https://www.maketecheasier.com/mpv-cli-media-player/
[23:45:59 CET] <jkqxz> DRM output in mpv, yeah.
[23:46:34 CET] <jkqxz> Oh, that's not quite the same thing.
[23:46:52 CET] <Li> jkqxz: this is the second time I read the word "output" in this context without knowing what it means!
[23:46:53 CET] <jkqxz> But mpv is probably the answer, whichever your question was :)
[23:47:52 CET] <miller7> alexpigment: Have you used this box? HD PVR 2
[23:47:53 CET] <jkqxz> "output" meaning the method it is using the display the frames.
[23:47:57 CET] <alexpigment> maybe he wants the video to play in ascii? ;)
[23:48:16 CET] <alexpigment> miller7: yes, almost every single day
[23:48:32 CET] <alexpigment> but it's for capture streams via HDMI, not OTA
[23:48:41 CET] <alexpigment> *capturing
[23:49:08 CET] <miller7> alexpigment: I understand. How can I get the stream from it?
[23:49:11 CET] <alexpigment> it also allows you to capture the original dolby digital 5.1 audio, so it's the only one I know that can do that
[23:49:23 CET] <Li> thanks guys i'll check mpv
[23:49:32 CET] <alexpigment> miller7: I'm not sure really. I just use the Hauppauge Capture app for Windows that it ships with
[23:49:57 CET] <miller7> I would like to stream my laptop screen etc and show it on a webpage. So if it somehow streams to an endpoint, it's nice
[23:50:47 CET] <alexpigment> miller7: i'm sure there's a way to do what you're doing. i'm just not the person to help. I've used the products, but only in the normal context of how to use them
[23:51:00 CET] <miller7> thanks a lot
[23:51:17 CET] <Li> oh Ok, now i recall trying that mpv before but it works only if I'm on full fledged linux desktop system
[23:51:52 CET] <Li> I'm trying to play video from command line terminal distro without launching x windows
[23:52:29 CET] <jkqxz> Li:  mpv --vo=drm
[00:00:00 CET] --- Wed Dec 13 2017