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

[burek]

[00:04:40 CEST] <dreamp> Hi there?! how are you?
[00:05:49 CEST] <dreamp> When I run the command `ffprobe -show_streams -i "file.mp4"` it outputs the bitrate info... I'd like to know where the libav gets this information about the bitrate. Supposing it's an h264 coded video in a fmp4 container.. is this information on the container or the codec? or is it calculated?
[00:09:57 CEST] <JEEB> it depends. in some cases lavf decides to read it from the container (which can't always be trusted), then in other cases it loads up the amount of data it uses for probing and averages over that, and then you have stuff like calculating the sizes of all samples over the duration of the clip
[00:10:18 CEST] <JEEB> and sometimes there's just a single value over the whole file if the duration and file size are available
[00:10:27 CEST] <JEEB> I think that might be in -show_format though :P
[00:14:55 CEST] <blap> DID YOU JUST ASSUME MY BACTERIAL INFECTION?
[00:17:03 CEST] <jarainf> blap, please provide the full output of your command
[00:17:14 CEST] <blap> ;)
[00:17:54 CEST] <blap> jarainf: join #blap, i'll share some good stuff
[00:18:03 CEST] <dreamp> Thanks JEEB I think you just described my situation =/ I'm reading and cating and init.mp4 + segment1.mp4 (from one Delta packager) and when I run ffmpeg and ffprobe and mediainfo they give me different info, mediainfo gets right I guess by looking at the numbers.
[00:18:22 CEST] <jarainf> blap, okay, whatever, I'm in.
[00:18:51 CEST] <JEEB> dreamp: bit rate is really easy though
[00:19:23 CEST] <JEEB> amount of bits / seconds => bits per second, and if you divide that by 1000 it'll be kilobits per second
[00:19:50 CEST] <dreamp> JEEB: how can I force my AVFormatContex to give me the right number
[00:19:55 CEST] <dreamp> owww you're right :D
[00:20:18 CEST] <dreamp> do I have the total amount of bits from AVFormatContext or should I go further into the Stream?
[00:21:31 CEST] <JEEB> dunno, it's not a field you can expect to have anyways and well -- stat'ing is easy :P
[00:21:41 CEST] <JEEB> ftell I guess?
[00:21:49 CEST] <JEEB> not sure what the way of getting a file's size was again :P
[00:22:18 CEST] <JEEB> dreamp: another way is to with ffprobe -show_streams -show_packets and then use the packets' sizes and the overall duration
[00:22:20 CEST] <dreamp> I was afraid to use the total file size
[00:22:34 CEST] <dreamp> because it includes the container  + streams
[00:22:35 CEST] <JEEB> that way you can get the overall size of the stream in bytes :P
[00:22:36 CEST] <dreamp> but in reality
[00:22:41 CEST] <dreamp> it is the whole fieeeeD
[00:22:46 CEST] <dreamp> *file
[00:22:51 CEST] <JEEB> well container overhead is minimal generally
[00:23:00 CEST] <dreamp> JEEB: You've opened my opens =D thanks
[00:23:02 CEST] <JEEB> except with MPEG-TS I guess, where it can be 15%
[00:23:15 CEST] <JEEB> or well, depends on muxer
[00:23:35 CEST] <dreamp> anyway the bitrate should account these bits too!
[00:24:00 CEST] <JEEB> but yea, -show_packets should get you the packet data
[00:24:05 CEST] <JEEB> for each stream
[00:24:13 CEST] <JEEB> and to match things you also want -show_streams
[00:24:47 CEST] <dreamp> I'm using ffprobe just to know if I'm using the ffmpeg libav correctly!
[00:24:51 CEST] <JEEB> ok
[00:25:14 CEST] <dreamp> Thanks JEEB I wish every community had someone so helpful as you! :D
[00:25:23 CEST] <JEEB> also I wonder if edit lists can fuck you up nicely
[00:25:39 CEST] <JEEB> because google implemented them on the demuxer level
[00:25:44 CEST] <JEEB> so it might try to feed you previous data again
[00:26:57 CEST] <dreamp> I dunno what is "edit lists"
[00:27:01 CEST] <JEEB> virtual timelines
[00:27:07 CEST] <JEEB> a thing from the MOV roots of MP4
[00:27:08 CEST] <dreamp> PTS
[00:27:17 CEST] <dreamp> ?
[00:27:27 CEST] <dreamp> ohhh I see timeline
[00:27:39 CEST] <JEEB> basically MOV used to be used as a "project file" format as well
[00:27:40 CEST] <dreamp> (like the thing we use to know the real time )
[00:27:41 CEST] <JEEB> for editors
[00:28:21 CEST] <JEEB> virtual time line like: "play 00:00-00:15" "play 00:30-00:45 at speed 2x" "play 00:15-00:30"
[00:28:26 CEST] <JEEB> those are edit lists
[00:29:10 CEST] <JEEB> and now you might understand why implementing them on the demuxer level is probably not the best idea (exporting them IMHO is a good idea)
[00:29:38 CEST] <dreamp> yep
[00:29:55 CEST] <JEEB> of course, you can disable edit list stuff in the demuxer I think
[00:30:07 CEST] <JEEB> which should give you the packets A->B
[00:30:19 CEST] <dreamp> this part of how audio and video are sync (the PTS and DTS) I'm still learning =/ do you have any material to point me?
[00:31:13 CEST] <dreamp> (are sync in a player by using the info from the container + codecs (streams))
[00:31:31 CEST] <JEEB> PTS are just something to synchronize multiple tracks against each other. in MP4 DTS are used as the base, and then you have offsets for each sample to get the PTS for it.
[00:31:52 CEST] <JEEB> some containers only contain fields for DTS, others only have PTS
[00:32:12 CEST] <JEEB> DTS in some containers is used for broadcast timing
[00:32:39 CEST] <JEEB> it's the time when the packet is supposed to hit the "decoder"
[00:32:55 CEST] <dreamp> there must be a sync conversion between Frequency (audio) and FPS (video) to make them orderly timmed
[00:33:04 CEST] <JEEB> yes, all streams have their own time base
[00:33:51 CEST] <JEEB> with audio that tends to be the sample rate, with video it is anything that matches :P
[00:34:06 CEST] <dreamp> I really need to use it to learn it =[ like programing it in C using libav
[00:35:09 CEST] <dreamp> feel free to drop me any post/thing to read about it :D
[00:35:13 CEST] <dreamp> Thanks a lot JEEB
[00:35:56 CEST] <JEEB> I really don't think there's much special about it, PTS is what you generally care about in most cases, and you use it to synchronize multiple things together when utilizing whatever you're decoding
[00:37:04 CEST] <JEEB> when you demux your AVPackets will have stuff in the container's stream time base, then when you decode the decoder can have its own time base so the AVFrames you get from the decoder are in that, and then if you do filtering that has its own time base as well
[00:37:53 CEST] <JEEB> generally when you are doing transcoding you care about passing those numbers through correctly - that should be enough
[00:38:29 CEST] <JEEB> *cough* MPEG-TS can GTFO with its random "I'm going to go back in time even if I didn't have an overflow btw!" *cough*
[00:38:49 CEST] <JEEB> anyways, sleep for me :P
[00:47:11 CEST] <dreamp> thanks JEEB I'll be experiencing it and if I have some doubts I'll be here! I'll sleep too!
[00:57:09 CEST] <suNooBku> 420 users online
[00:57:11 CEST] <suNooBku> legit
[00:57:57 CEST] <suNooBku> guys, after installing last ffmpeg, i have problem with recording desktop via nvidia_hevc
[00:58:07 CEST] <suNooBku> using simplescreenrecorder
[00:58:28 CEST] <suNooBku> 90% of screen is black, i only see cursor and small blurry area around it
[00:59:00 CEST] <suNooBku> using nvidia drivers
[01:41:06 CEST] <jiffe> so reading https://medium.com/netflix-techblog/extracting-contextual-information-from-video-assets-ee9da25b6008 it sounds like netflix does use some sort of fingerprinting to identify title/credit sequences
[01:59:58 CEST] <thebombzen> I'm having trouble encoding two different libopus streams with ffmpeg.c at the same time
[02:00:20 CEST] <thebombzen> if I try to do: ffmpeg -i temp.mkv -map 0 -c:a libopus -b:a 128k temp2.mkv, it produces an error
[02:00:55 CEST] <thebombzen> https://0x0.st/srhP.log
[02:08:09 CEST] <arog> Anyone here familiar with fdk aac
[02:08:46 CEST] <arog> We are seeing issues where our data has weird glitches. When we put a sine wave through we see little portions where the amplitude increases then goes back to normal
[02:08:59 CEST] <arog> Or the opposite, the amplitude decreases then goes back to normal.
[02:09:39 CEST] <arog> Anyone know if this means if our input aac data is missing data and the decoder just guessed or is it another issue
[02:13:45 CEST] <redrabbit> thebombzen: your site has an ipv6 adress however it doesnt seem to serve web on the ipv6
[02:14:05 CEST] <thebombzen> my website?
[02:14:10 CEST] <thebombzen> 0x0.st is not mine
[02:14:16 CEST] <redrabbit> ok ok
[02:16:43 CEST] <redrabbit> curl -4 0x0.st > works
[02:16:52 CEST] <redrabbit> curl -6 0x0.st > hangs
[02:18:07 CEST] <thebombzen> don't bug me about that :P
[03:12:28 CEST] <AndrewMock> Does the smptehdbars test filter not generate in 4:4:4? It default to yuv420p. I feel like that is not correct?
[03:13:49 CEST] <AndrewMock> Can't seem to force it to 444
[03:14:08 CEST] <AndrewMock> i mean, i can convert after the fact but it is too late
[03:22:44 CEST] <AndrewMock> just don't want chroma subsampling distorting my bars
[06:05:42 CEST] <Shred00> when i try to map such as:
[06:05:42 CEST] <Shred00> $ ffmpeg -y -i INPUT -map 0:0 -map 0:1 -map 0:1 -c:v copy -c:a:0 aac -ac:a:0 2 -af:a:0 "pan=stereo|FL=FC+0.30*FL+0.30*BL|FR=FC+0.30*FR+0.30*BR" -c:a:1 copy OUTPUT
[06:05:42 CEST] <Shred00> i get an error:
[06:05:42 CEST] <Shred00> Filtergraph 'pan=stereo|FL=FC+0.30*FL+0.30*BL|FR=FC+0.30*FR+0.30*BR' was defined for audio output stream 0:2 but codec copy was selected.
[06:05:42 CEST] <Shred00> Filtering and streamcopy cannot be used together.
[06:05:42 CEST] <Shred00> but i cannot see how what i am doing is any different than https://trac.ffmpeg.org/wiki/Map Example 1.
[06:30:34 CEST] <thebombzen> Shred00: -af is an alias for -filter:a
[06:30:42 CEST] <thebombzen> it will apply to all audio streams. you want -filter:a:0
[06:31:16 CEST] <thebombzen> the stream specifier on -af is ignored and it will be treated as -filter:a, even if you have -af:a:0
[06:31:36 CEST] <thebombzen> so it's applying to output a:1, the one you wanted to copy.
[06:46:26 CEST] <Shred00> thebombzen: ahhh.  thanks for the explanation.
[06:52:09 CEST] <thebombzen> you're welcome :)
[09:26:28 CEST] <Jutoms> Hi guys, can we use ffmpeg to convert 1 to multiple profiles ?
[09:27:43 CEST] <Jutoms> or we have to run X time for X profiles ?
[10:02:46 CEST] <inter123> Hello there. I need some help with ffmpeg on my linux vps, is there someone here to help me out?
[11:00:00 CEST] <akkad> ok
[11:35:59 CEST] <chriss4349347293>  Hello all. I'm trying to capture from a pulseaudio device (actually a monitor of my main output) that has 8 channels. the (what I think is, please ask if you need more) important stuff from pactl list:
[11:35:59 CEST] <chriss4349347293> Source #0
[11:35:59 CEST] <chriss4349347293>         State: IDLE
[11:35:59 CEST] <chriss4349347293>         Name: alsa_output.pci-0000_00_1b.0.analog-surround-71.monitor
[11:35:59 CEST] <chriss4349347293>         Description: Monitor of Built-in Audio Analog Surround 7.1
[11:35:59 CEST] <chriss4349347293>         Driver: module-alsa-card.c
[11:35:59 CEST] <chriss4349347293>         Sample Specification: s16le 8ch 44100Hz
[11:36:00 CEST] <chriss4349347293>         Channel Map: front-left,front-right,rear-left,rear-right,front-center,lfe,side-left,side-right
[11:36:00 CEST] <chriss4349347293>         Owner Module: 6
[11:36:01 CEST] <chriss4349347293>         Mute: no
[11:36:01 CEST] <chriss4349347293> when capturing, ffmpeg guesses Stereo layout, which is expected as far as I understood, because it's a raw stream, so I need to specify -ac 8 for ffmpeg
[11:36:02 CEST] <chriss4349347293> but this gives error:
[11:38:49 CEST] <durandal_1707> use pastebin
[12:13:06 CEST] <_julian> do I need any modules except for rtp,mpegts and rtp_mpegts mux and rtp protocol to generate a mpegts in rtp stream for a h264+aac stream? I can't seem to get it working...
[12:15:22 CEST] <DHE> trying to build a super-minimal version of ffmpeg?
[12:15:28 CEST] <_julian> yes
[12:15:42 CEST] <_julian> works fine for mpegts->udp, but can't get rtp_mpegts->rtp to work
[12:16:09 CEST] <JEEB> make sure you have it working with normal configuration first
[12:16:20 CEST] <JEEB> after verifying that you can start looking into which protocols etc you require
[12:20:35 CEST] <_julian> hm, strange, I can get it to work with lavfi/testsrc input, but not with decklink input
[12:20:55 CEST] <_julian> with decklink input it seems the pipeline is just stalled, and the decklink input fifo is constantly overflowing
[12:28:01 CEST] <memeka> hi; how are decoded frames sent to the video drivers? profiling gstreamer and mpv+ffmpeg, I get very different results: on my arm board with no dmabuf-import gpu support, gstreamer spends most of the time doing memcpy, and less in the gpu driver, but mpv+ffmpeg spends most of its time in the driver: 72% libmali.so cobjp_neon_linear_to_block_8b_8x8, 16% libmali.so               cobjp_neon_linear_to_block_16b_8x8, 7%
[12:28:01 CEST] <memeka> memcpy
[12:28:20 CEST] <memeka> JEEB, durandal_1707 ^^^ any idea?
[12:29:23 CEST] <_julian> Any thoughs why decklink input could behave differently compared to lavfi? And why rtp_mpegts makes a difference to mpegts when connected to decklink input?
[12:32:43 CEST] <durandal_1707> memeka: what are you actually doing?
[12:33:53 CEST] <durandal_1707> comparing gs and mpv have little sense
[12:35:18 CEST] <memeka> durandal_1707: decoding on my board is fast (ffmpeg -f null shows 120fps on 1080p video) but display is slow (no dmabuf-import)
[12:35:29 CEST] <memeka> i was trying to see how i can speed things up
[12:36:40 CEST] <memeka> for example, in gst, memcpy was taking a lot of time => by using the arm-mem library, memcpy is now faster and i can reach 45fps with gst on 1080p video (instead of 20fps)
[12:37:19 CEST] <memeka> with ffmpeg, i am still at 20fps, and apparently libmali is taking a lot of time => you're copying buffers in a different way?
[12:38:51 CEST] <Mavrik> Usually those devices have a way to bypass copying video surface to the main memory
[12:38:57 CEST] <Mavrik> E.g. display it directly
[12:38:57 CEST] <durandal_1707> for mpv you need to ask on mpv channel,  i dunno about arm support
[12:39:21 CEST] <memeka> durandal_1707: so it's not ffmpeg doing the copy?
[12:39:25 CEST] <durandal_1707> mpv have dr option for some vo
[12:39:40 CEST] <memeka> what's "dr" ?
[12:39:59 CEST] <durandal_1707> memeka: ffmpeg is only doing decoding in hw or sw
[12:40:11 CEST] <durandal_1707> memeka: direct rendering
[12:41:19 CEST] <memeka> durandal_1707: mpv --list-options | grep dr shows no such option
[12:42:37 CEST] <durandal_1707> too old version?
[12:45:33 CEST] <memeka> durandal_1707: it's 0.26 (i think 0.27 it's the latest) ....
[12:54:40 CEST] <chriss4349347293> ok, https://pastebin.com/ZNGy7Uzf
[12:54:57 CEST] <chriss4349347293> want to record from pulseaudio device with 8 channels
[12:55:08 CEST] <chriss4349347293> specifying -ac 8 gives error
[12:55:23 CEST] <chriss4349347293> specifying -ac 6 works
[12:55:32 CEST] <chriss4349347293> am I doing something wrong?
[12:56:00 CEST] <chriss4349347293> the only change between the two ffmpeg commands is number of channels (see pastebin link)
[12:56:44 CEST] <chriss4349347293> ffmpeg is v 3.3.4
[13:10:13 CEST] <ToffeeYogurtPots> Hey, I'm having some trouble with encoding using libvpx (both VP8 and VP9). The output appears noticeably blocky and the only way to eliminate it I've found is to lower the CRF value to the point where the output has a larger file size than the input. I have made a question on video.stackexchange.com ( https://video.stackexchange.com/q/22615 ) but I thought it's probably a good idea to check here too for suggestions.
[13:15:40 CEST] <JEEB> ToffeeYogurtPots: you never compare to the input if it's already compressed
[13:16:03 CEST] <JEEB> and second of all, there are some parameters in the webm wiki on VP9 encoding in FFmpeg, see that
[13:16:09 CEST] <JEEB> for some parameters to tweak
[13:16:21 CEST] <JEEB> libvpx has some "speed" parameter that can improve compression
[13:16:39 CEST] <JEEB> but generally if you're compressing something already compressed you will end up with a larger file if you're trying to re-compress it
[13:16:51 CEST] <JEEB> because you're not only compressing the original input, but also the artifacts etc
[13:18:34 CEST] <Mavrik> Even though, usually that's not that noticable
[13:19:06 CEST] <JEEB> well if he's got a heavily compressed file and then you re-compress it with random parameters in libvpx then I don't really know what you're expecting
[13:19:27 CEST] <JEEB> you just can't expect "I recompress this piece of REDACTED and I will get a smaller file always for the same quality"
[13:19:42 CEST] <JEEB> which is why I often do not re-compress old MPEG-1 encodes for which I don't have masters
[13:19:53 CEST] <Mavrik> Yeah true
[13:20:19 CEST] <Mavrik> But still, recompressing something to about the same filesize in most cases won't introduce noticable artifacts (for a decent SD input)
[13:21:05 CEST] <JEEB> I try to drag people away from looking at the source bit rate altogether because it doesn't make any sense
[13:21:27 CEST] <JEEB> because some people specifically set the bit rate to the same thing
[13:21:31 CEST] <JEEB> it's just *dumb*
[13:22:09 CEST] <ToffeeYogurtPots> JEEB: Yeah, I'm not hoping for a perfect output they are DVD's after all. Just wanting to minimise quality loss  where possible, if it is possible. Thanks for the suggestions.
[13:22:41 CEST] <Mavrik> JEEB: yeah, that's obvious I think :)
[16:23:21 CEST] <zerodefect> I'm using an AVFilterGraph and programmatically setting it up using the C-API to insert/output video frames.  I'm noticing what I think is the graph buffering a frame internally. I think this should probably be expected when using multithreading, right?
[16:23:39 CEST] <zerodefect> I couldn't find too much in the docs about this behaviour
[17:07:56 CEST] <Mavrik> zerodefect: yeah, it might buffer a frame. Also depends on filters
[17:08:03 CEST] <Mavrik> E.g. I think fps filter does keep one frame around
[17:08:12 CEST] <Mavrik> You also might get several or no frames out :)
[17:08:33 CEST] <zerodefect> Yeah, using 'Yadif' filter...it probably does some interpolation.
[17:08:41 CEST] <JEEB> yes
[17:08:45 CEST] <JEEB> it also has required buffering
[17:09:32 CEST] <zerodefect> Is there a way to hook into a func callback to receive a notification when a frame is available in the buffersink filter?
[17:09:55 CEST] <JEEB> not yet, feel free to propose such
[17:10:09 CEST] <JEEB> you basically have one function to push things in, another to try and fetch
[17:10:39 CEST] <zerodefect> Yeah, I'm pushing a frame in and then immediately checking if a frame is available :)
[17:11:54 CEST] <JEEB> the thing is kind of similar but not exactly compared to the feed/fetch API for decoding and encoding
[17:12:00 CEST] <zerodefect> If I received a callback, I could make my code async.
[17:12:02 CEST] <zerodefect> Yeah
[17:12:53 CEST] <zerodefect> I'm guessing in a hardware de-interlacer, you would have the same sort of buffering too?
[17:13:14 CEST] <JEEB> if the filter requires more than one picture of input then yes
[17:13:27 CEST] <JEEB> I mean, it depends on what sort of filter you're making and what are the requirements
[17:14:44 CEST] <zerodefect> Ok. The buffering is not a problem, so this is more for interest. Do you know if the bwdif and/or w3fdif have the same sort of buffering?
[17:15:14 CEST] <Mavrik> Isn't there a PUSH flag that immediately forces processing through the whole chain?
[17:16:29 CEST] <zerodefect> AV_BUFFERSRC_FLAG_PUSH, yes. Already set tht
[17:16:32 CEST] <zerodefect> *that
[17:25:26 CEST] <Johnjay> damn
[17:25:43 CEST] <Johnjay> if I do ffmpeg -y -i file.mp3 -af aresample=48000 file.mp3
[17:25:48 CEST] <Johnjay> does that overwrite file.mp3 with 0 bytes?
[17:26:10 CEST] <c_14> it will most probably trash your input, yes
[17:27:00 CEST] <Johnjay> alright well i will reencode this entire directory then
[17:28:18 CEST] <c_14> Maybe I should write something for ffmpeg.c that checks if the input and output files are the same...
[17:30:50 CEST] <Johnjay> c_14: I think I had this problem before
[17:31:04 CEST] <Johnjay> I downloaded a youtube playlist but the file formats were different. So i batch converted to mp3 with ffmpeg
[17:31:15 CEST] <Johnjay> but concat didn't work properly because the samples rates were different
[17:31:22 CEST] <Johnjay> so I had to make sure everything was 44.1khz I think
[17:31:42 CEST] <Johnjay> I thought I could maybe fix it by transcoding the entire directory with aresample
[17:32:24 CEST] <Johnjay> maybe a flag that specifically says you want to copy it in place? -noclobber or something lol
[17:33:43 CEST] <c_14> Detecting the problem and aborting would be easier and should probably be enough
[17:33:57 CEST] <c_14> Since you can handle the output to temporary file and then rename better in a surrounding shell script
[17:34:21 CEST] <Mavrik> Note that you pass -y parameter, where you force the files to be overwritten without question :)
[17:34:27 CEST] <Johnjay> it would at least not make all my files 0 bytes. lol
[17:34:42 CEST] <Johnjay> i am getting errors when I try to concat the mp3 files together
[17:34:44 CEST] <Mavrik> It wouldn't if you wouldn't tell it to with a switch :P
[17:34:50 CEST] <Johnjay> i just don't understand what it means
[17:35:16 CEST] <Johnjay> Mavrik: That's like saying I signed on the dotted line at the dentists, so i consented to having my teeth ripped out without question. lol
[17:36:42 CEST] <Mavrik> Hrmf, not really.
[17:36:48 CEST] <Mavrik> You explicitly pass a flag to clobber files :P
[17:37:29 CEST] <c_14> Yeah, but most people will assume that it overwrites the file with the output of the encoding, not that it clobbers it's input and then soft-fails
[17:37:44 CEST] <Johnjay> idk what it is about mp3 that concatenation fails utterly and produces a corrupt file when sample rates differ
[17:38:00 CEST] <c_14> Johnjay: try the concat demuxer?
[17:38:10 CEST] <c_14> though
[17:38:13 CEST] <Johnjay> c_14: yes
[17:38:19 CEST] <c_14> if the samplerate differs that won't help
[17:38:40 CEST] <Johnjay> ffmpeg -f concat -i mylist.txt -c copy output.mp3
[17:38:48 CEST] <Johnjay> i think i had to pass -safe 0 too
[17:38:59 CEST] <Johnjay> it also failed with -c mp3
[17:39:47 CEST] <Mavrik> c_14: yeah true, ffmpeg should probably fail fast on those "reading file while trying to write to it" condition
[17:40:03 CEST] <Johnjay> c_14: you're right i guess, it still fails with error [mp3 @ 00000000004749a0] Application provided invalid, non monotonically increas ing dts to muxer in stream 0: 26337024 >= 12304071
[17:40:47 CEST] <zerodefect> Question about some of the private/internal opts on the encoders.  Taking an example with the x264 encoder, does it matter if I set 'tune=zerolatency' before setting the values in the AVCodecContext? Is the order important?
[17:40:49 CEST] <Johnjay> dammit, what did I do last time that fixed this
[17:41:38 CEST] <zerodefect> My question is related to C-API now cmd line.
[17:41:44 CEST] <zerodefect> *not
[17:44:21 CEST] <Mavrik> zerodefect: check libx264.c for the order
[17:44:39 CEST] <Mavrik> But probably text opts are set after the avcodeccontext params
[17:44:45 CEST] <doublya> Is ffmpeg using ncurses or something for CLI output?  Is there a switch to turn that off so it just writes new  fps= speed= lines?
[17:45:20 CEST] <c_14> doublya: try -v quiet -stats
[17:45:31 CEST] <c_14> and it's not ncurses
[17:45:41 CEST] <zerodefect> Mavrik: Thanks. I'll take a look at x264, but I was wondering if there was a sort of 'best practice'.
[17:45:49 CEST] <zerodefect> I'll see what I can find
[17:46:12 CEST] <Johnjay> c_14: ok i'm trying ffmpeg -f concat -i mylist.txt -c mp3 output.mp3 this time
[17:46:22 CEST] <c_14> doublya: or do you mean the fact that it redraws the line instead of printing new lines?
[17:46:57 CEST] <doublya> c_14: thanks. i'll try that. Yes exactly. I'd like to always print a new line instead of redrawing.
[17:50:29 CEST] <Johnjay> c_14: ok i give up. i checked output.mp3 and it says it is about an hour long
[17:50:37 CEST] <Johnjay> but input files total to about 2 hours of audio.
[17:50:45 CEST] <Johnjay> and the output file doesn't sound corrupted, so not sure what's happening
[17:52:10 CEST] <c_14> Johnjay: are some of the songs faster than they should be?
[17:52:20 CEST] <c_14> Also, is it just the duration that's wrong maybe?
[17:53:06 CEST] <Johnjay> c_14: not as far as i can tell. unless windows is lying about this directory of files being total 2 hours long
[17:53:15 CEST] <Johnjay> listening to the first 5 minutes so far
[17:53:32 CEST] <c_14> fast forward to close to the hour mark and see if it continues
[17:53:59 CEST] <doublya> c_14: ffmpeg.c is_last_report ? '\n' : '\r';
[17:55:13 CEST] <Johnjay> c_14: total of directory is about 120MB, but file is only ~50MB
[17:55:17 CEST] <Johnjay> so i don't think it's that
[17:55:31 CEST] <Johnjay> nope it restarted
[17:55:44 CEST] <c_14> doublya: yeah, if you get rid of the terminal and always use \n it'll use new lines
[17:56:01 CEST] <c_14> I was trying to see if you could convince a terminal to treat CR as LF so you wouldn't have to recompile
[17:56:03 CEST] <Johnjay> c_14: what does the non-monotonically dts to muxer mean in this context? it repeated that error a lot
[17:56:30 CEST] <Johnjay> how do i capture the full debug output of ffmpeg, it took up my whole console with the dts-to-muxer messages
[17:58:51 CEST] <c_14> I think regular file redirection works on windows, so &> file.txt
[17:59:23 CEST] <c_14> at very least 2> should work
[17:59:40 CEST] <Johnjay> that seems to be working
[17:59:47 CEST] <Johnjay> it's not vomitting into the console now
[18:05:38 CEST] <Johnjay> i wish they made these mp3 players as something other than mp3
[18:05:45 CEST] <Johnjay> i.e. ability to play ogg or webm or something
[18:05:57 CEST] <Johnjay> i guess those formats are more modern and less prone to weirdness like this
[18:09:46 CEST] <Johnjay> hrm
[18:09:51 CEST] <Johnjay> it seems like it's working c_14 but very slowly
[18:09:57 CEST] <Johnjay> the output file is 11MB after this time
[18:14:38 CEST] <c_14> doublya: *ternary
[18:19:43 CEST] <Johnjay> c_14: idk ffmpeg appears to be frozen
[18:19:55 CEST] <Johnjay> and i can't access file.txt because it's in use by another process
[18:20:15 CEST] <Johnjay> CPU activity is zero
[18:20:48 CEST] <c_14> kill it with task manager and then check the file?
[18:25:45 CEST] <Johnjay> oops I al ready deleted it
[18:25:52 CEST] <Johnjay> you know some of these file names have ' in them that I somehow missed
[18:25:57 CEST] <Johnjay> that might be the issue
[18:30:16 CEST] <Johnjay> reencoding with libmp3lame
[18:35:12 CEST] <Johnjay> hmm some of this is opus lol
[18:36:59 CEST] <Johnjay> still getting that message
[18:37:04 CEST] <Johnjay> idk what i'm doing wrong here
[18:37:26 CEST] <Johnjay> output file this time around is 80MB though
[18:40:04 CEST] <Johnjay> ok looks good.
[18:40:11 CEST] <Johnjay> total input size 80.2 MB, output.mp3 is 80.3 MB
[18:43:58 CEST] <Johnjay> oh crap. i might have left half the input files out
[18:51:53 CEST] <Johnjay> hmm. ok i guess that whole problem was caused by ' in file names
[19:00:18 CEST] <Johnjay> i'm confused now
[19:00:37 CEST] <Johnjay> WMP plays the final file back fine, but VLC does not. it seems to chop off the last 10 second of sound
[19:00:46 CEST] <Johnjay> and in VLC the playback time flashes up and down. wtf
[22:56:27 CEST] <fella> hi there, my mplayer seems to be unable to play https streams, so i do 'mplayer ffmpeg://"STREAM-URL"' - is there a way to put this ffmpeg option to my ~/.mplayer/config ?
[22:56:46 CEST] <durandal_1707> no
[22:57:17 CEST] <fella> so? any other way to make mplayer play https?
[22:57:30 CEST] <BtbN> you could just not use mplayer
[22:58:32 CEST] <fella> lol - wrong channel :)
[22:58:58 CEST] <fella> BtbN: ok, but ffplay is no alternative, is it?
[22:59:08 CEST] <BtbN> but mpv and vlc are.
[22:59:15 CEST] <fella> what would you suggest?
[22:59:23 CEST] <BtbN> Generally, everything but mplayer.
[22:59:30 CEST] <kepstin> if you like mplayer, then mpv is fairly similar.
[22:59:36 CEST] <fella> i don't like vlc to much but i'ld have to try mpv
[22:59:39 CEST] <durandal_1707> install windows media player
[22:59:49 CEST] <fella> with wine?
[23:00:18 CEST] <__jack__> mpv is awesome
[23:00:32 CEST] <fella> installing it this very moment
[23:01:11 CEST] <durandal_1707> fella: no.., in win 2k
[23:04:42 CEST] <fella> __jack__: mpv vs mplayer make no difference when it comes to cpu usage, *but* - pulseaudio needs more than twice as much ressources with mpv compared to mplayer!?
[23:07:50 CEST] <__jack__> dunno, I flushed pulseaudio away, as it sucks
[23:10:54 CEST] <fella> so i've tested mpv, mplayer, vlc and ffplay now and it seems like, mplayer has the smallest footprint
[23:11:31 CEST] <durandal_1707> mpv may use cache
[23:12:03 CEST] <durandal_1707> so "footprint" is meaningless
[23:16:47 CEST] <fella> i didn't mean memory footprint but cpu usage - it seems to be higher with mpv compared to mplayer
[23:17:11 CEST] <durandal_1707> fella: how much?
[23:18:17 CEST] <fella> about 10%+ with mpv
[23:19:27 CEST] <durandal_1707> fella: what vo you use?
[23:22:14 CEST] <fella> what do you mean?
[23:23:51 CEST] <durandal_1707> fella: video output
[23:25:41 CEST] <fella> some internal gpu chip
[23:26:17 CEST] <durandal_1707> but vo as used by mpv and mplayer
[23:26:47 CEST] <fella> default i guess - haven't changed that in config
[23:28:11 CEST] <fella> vdpau is the first listed wiht mplayer -vo help - but i'm not sure if thats the one that gets used?
[23:28:13 CEST] <durandal_1707> mae sure you are not comparing apples and oranges
[23:28:32 CEST] <fella> so what would you suggest as vo?
[23:31:34 CEST] <kepstin> mpv probably defaults to gl, which is recommended for best quality
[23:31:43 CEST] <kepstin> mplayer usually uses xv by default on linux
[23:32:02 CEST] <kepstin> the gl output has a bit more overhead, yeah
[23:32:04 CEST] <durandal_1707> fella: same as mplayer for fair comparison
[23:33:30 CEST] <fella> ok, good to know - thx :)
[23:54:58 CEST] <Johnjay> isn't mpv just the continuation of mplayer?
[23:55:20 CEST] <durandal_1707> its fork
[23:57:28 CEST] <Johnjay> is it still considered a fork if the original project just stalls or stops updating?
[00:00:00 CEST] --- Fri Oct 27 2017