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

[burek]

[00:43:36 CET] <greentea> JEEB:  I see.  How about Libmp3lame for x64 msvc windows?
[00:44:28 CET] <JEEB> no idea
[00:44:56 CET] <JEEB> basically depends on how easily you can get a pkg-config pc file from all those things
[00:46:41 CET] <BtbN> pkg-config on msvc is problematic though
[00:46:52 CET] <JEEB> yes and no, it seems to work with libx264?
[00:47:09 CET] <JEEB> also pkg-config has that option for MSVC style parameters
[00:47:18 CET] <BtbN> when I tried it, it tried to mix in "system" libs, and msvc barfed on them
[00:47:18 CET] <JEEB> which may or may not work
[00:47:24 CET] <JEEB> right
[00:47:39 CET] <JEEB> yea, it can be """fun""", that I'm not going to say isn't true
[00:47:56 CET] <JEEB> but at least I've seen someone succeed with libx264, and I think I did at one point too
[00:48:57 CET] <greentea> I have done it with libx264 no problem.
[00:49:21 CET] <BtbN> Generally, I'd say avoid building with msvc if you at all can
[00:49:35 CET] <BtbN> gcc is better at optimising anyway
[00:50:12 CET] <greentea> i would use gcc with visual studio, i guess.....might lose debugging
[00:50:35 CET] <BtbN> Or just don't use Visual Studio. There are other IDEs
[00:50:52 CET] <JEEB> yea if you want to specifically use MSVC's debugger (which is actually surprisingly decent) you need MSVC
[00:51:01 CET] <JEEB> for mingw-w64 you just have gdb
[00:51:05 CET] <JEEB> which can be good enough
[00:51:21 CET] <JEEB> but it sure as hell is less welcoming than MSVS :)
[00:51:28 CET] <BtbN> I guess profiling code on Windows is also pretty much msvc-only
[01:02:51 CET] <greentea> https://pastebin.com/NML50sSX
[01:03:40 CET] <greentea> Getting fatal error LNK1181 : cannot open input file 'm.lib', when using --enable-libvorbis,  having libvorbis.lib and libogg.lib in the libdirs
[01:04:59 CET] <hypothete> Hi all, I'm hoping you can clear up some confusion I'm experiencing. Can FFmpeg export transparent GIFs? I'm producing animated GIFs successfully from transparent PNGs, but the background is always black.
[01:05:16 CET] <BtbN> yeah, that's it picking up a "system"-lib, which msvc simply does not have
[01:30:40 CET] <greentea> is it possible to build m.lib or is it a msvcr thing?
[01:30:52 CET] <greentea> JEEB or anyone :)
[01:48:01 CET] <CowboyPride> Evening all, I'm attempting to compile ffmpeg but keep getting an errror. I've done much searching on google, verfiying by dependcies are building correctly and even attempted many of the fixes found but to no success.
[01:49:17 CET] <CowboyPride> The gist of the error is `ERROR: x265 not found using pkg-config` but x265 is indeed being built and is showing in the bindir where it should be.
[01:50:10 CET] <marcurling> Hello, which option should I set to encode an interlaced source interlaced (and will the field order will be the same by default)?
[01:50:29 CET] <CowboyPride> I first was trying to use a script to automate it based upon instructions I've found, but then afterwards went through manual process of compling each compent and still arrive at the same result.
[01:50:56 CET] <CowboyPride> My install script is here, https://pastebin.com/raw/CQdXgRTV
[01:51:53 CET] <CowboyPride> My build result for x265 and the end result for ffmpeg along with ffbuild/console.log can be found here, https://pastebin.com/raw/5PkzMEHY
[01:53:30 CET] <CowboyPride> I've also been searching items showin in console.log have yet to get a successful build.
[01:53:49 CET] <CowboyPride> Any assistance would be appreciated.
[01:56:06 CET] <CowboyPride> I'm trying to this to build successfully so that I can include this in a docker build.
[01:56:38 CET] <furq> CowboyPride: --extra-libs=lpthread
[01:57:16 CET] <CowboyPride> Thanks, let me try that.
[01:59:35 CET] <CowboyPride> Cool, that solves the x265 error, now I can move on the next error I just got.. C compiler test failed, hopefully shouldn't have much more problems.
[02:01:50 CET] <CowboyPride>  "gcc: error: lpthread: No such file or directory", at least I'm getting somewhere now.
[02:09:39 CET] <Laurenceb_> hi
[02:09:52 CET] <Laurenceb_> has anyone ever looked at dashcam metadata encoding?
[02:10:30 CET] <Laurenceb_> I've got a cobra dashcam and wanted an automated way to extract gps data from files loaded onto a server
[02:22:58 CET] <marcurling> Hello, does ffmpeg has something like a -quiet option for he doesn't spend time in verbosing all errors?
[02:23:33 CET] <furq> -v error
[02:23:49 CET] <furq> you probably also want -stats or else it'll hide the stats bar
[02:23:51 CET] <marcurling> :me thanks furq
[04:22:16 CET] <CowboyPride> I finally have a working build, it's compiling now... Been a very long day. Much thanks furq
[05:48:05 CET] <kota1> I'm using ffmpeg to do a stream, and I"m running into inconvenient behavior
[05:48:21 CET] <kota1> I'm using the realtime filter to output the stream in, well, realtime
[05:48:30 CET] <kota1> My files have subtitles that I'm burning into the stream
[05:49:37 CET] <kota1> If I try to seek the file using output seeking, the subtitles appear at the proper time (a line spoken at 00:30 is seen/heard at the same time subtitles appear for 00:30), but it doesn't jump to that location of the file
[05:49:56 CET] <kota1> because of the realtime filter, I have to sit and wait for the seek to get there in real time, which doesn't do me any good.
[05:50:48 CET] <kota1> If I try to seek the file using input seeking, it seeks immediately, but the subtitles do not appear at the proper time (a line spoken at 00:30 in the new timecode does not have its appropriate subtitle, the subtitles start appearing as though the file hadn't been seeked at all)
[05:51:14 CET] <kota1> Is there a way to reconcile this behavior so that I can seek a file, output it in real time for the stream, and have the subtitles timed properly?
[05:52:53 CET] <kota1> ffmpeg -ss 00:30:00 -i file.mkv -vf subtitles=file.mkv,realtime gives me mistimed subtitles
[05:53:26 CET] <kota1> ffmpeg -i file.mkv -ss 00:30:00 -vf subtitles=file.mkv,realtime gives me aligned subs, but takes 00:30:00 to start streaming
[12:45:20 CET] <kms_> how to trim audio to video stream length?
[12:55:01 CET] <Nacht> Anyone know what this means? : "Application provided invalid, non monotonically increasing dts to muxer"
[12:56:10 CET] <Nacht> I got this bunch of files made by Rotter in both OGG and AAC. Yet when I want to convert them to MPEGTS, I get gaps with AAC between concatted files, and with OGG I suddenly get 24 hours and 50 mins out of 24 hours of data.
[12:56:23 CET] <Nacht> Now I recon the extra 50 mins comes from the correction made to the PTS/DTS
[13:23:26 CET] <JEEB> Nacht: DTS did not increase between packets
[13:28:38 CET] <Nacht> Hmmm. If I use the AAC, I get 24 hours, but gaps between the TS files, yet when I use the OGG I get an extra 50 mins. Is there a way to tell ffmpeg to skip the invalid DTS packages ?
[13:32:38 CET] <terminalator> Which options would you recommend when using ffmpeg for making gifs?
[19:54:27 CET] <hojuruku> If you google: qtdemux qtdemux_parse_trak:<qtdemux0> Track shorter than 20% (gstreamer trying to read what ffmpeg vaapi creates with a rx560 mesa-git vaapi) you'll only come up with me talking about it :( That's the error that gstreamer gives. vlc is suggesting the first two frames are no good. How do you analyse a mp4 file for iso standards compliancy?
[19:54:58 CET] <JEEB> the container or the content?
[19:55:16 CET] <JEEB> because mp4 is one thing, and then the contained H.264 or H.265 or whatever track is separate
[20:10:55 CET] <hojuruku> i'm looking at it in full TRACE level debugging in gstreamer, it's got different time scale:    1/1000 sec/   duration:      5834998 for the audio and the video
[20:16:20 CET] <JEEB> time scale being different between tracks is completely normal
[20:19:17 CET] <hojuruku> JEEB: here's some useful information. What do you think of this ffprobe on the stream? https://pastebin.com/TRVM9XiH
[20:57:56 CET] <alexpigment> i'm making some audio files for testing, and i just ran across something kinda odd
[20:58:23 CET] <alexpigment> if i encode this 96/24 flac file without specifying anything, it preserves the 24-bit aspect
[20:58:32 CET] <alexpigment> but i can't specify 24 explicitly it seems
[20:58:39 CET] <alexpigment> -sample_fmt s24 doesn't work
[20:59:03 CET] <alexpigment> and ffmpeg -sample_fmts only has 8, 16, 32, and 64bit depths
[21:00:28 CET] <alexpigment> oh, i guess i just specify s32...
[21:00:30 CET] <alexpigment> weird
[21:01:56 CET] <durandal_1707> flac accepts only 16 or 32 bit pcm bit depth
[21:02:12 CET] <alexpigment> so what is a 24-bit flac then?
[21:02:14 CET] <durandal_1707> and encodes 24bit for 33 case
[21:02:26 CET] <alexpigment> so is there a way to make a 32-bit flac?
[21:02:35 CET] <alexpigment> not that i care to make that; i'm just making a test bank
[21:03:14 CET] <durandal_1707> 32 bit flac is not posssible practically
[21:03:19 CET] <alexpigment> k
[21:07:54 CET] <furq> there are other lossless formats that support 32-bit if that's of any interest to you
[21:09:24 CET] <alexpigment> well i know PCM does it
[21:09:28 CET] <alexpigment> i'm sure there are others
[21:09:38 CET] <alexpigment> i'm really just trying to create every permutation of flac at the moment
[21:09:48 CET] <furq> well i have some annoying news for you
[21:09:56 CET] <furq> apparently there is a flac encoder that does 32-bit int
[21:10:02 CET] <alexpigment> great ;)
[21:10:04 CET] <furq> i have no idea if libflac will decode it though
[21:10:21 CET] <furq> http://flake-enc.sourceforge.net/
[21:11:10 CET] <alexpigment> well, if the vast majority are 16 and 24-bit, i'm fine with this test bank
[21:11:16 CET] <alexpigment> does 8-bit flac exist?
[21:12:14 CET] <furq> [flac @ 0x80d4bba00] Specified sample format u8 is invalid or not supported
[21:12:16 CET] <furq> apparently not
[21:12:30 CET] <alexpigment> oh yeah, i guess it says s16 and s32 right here during encode
[21:12:40 CET] <alexpigment> sorry, i read that and didn't fully process it
[21:13:02 CET] <alexpigment> i'm also listening to an 8khz flac file right now :)
[21:13:08 CET] <furq> yeah i was about to say
[21:13:11 CET] <furq> apparently libflac does it
[21:13:25 CET] <alexpigment> k, i may look into that next
[21:13:26 CET] <durandal_1707> use float and wavpack
[21:14:15 CET] <alexpigment> wavpack is on my list but it's down the chain a little bit
[21:14:20 CET] <alexpigment> i want to hit the common formats first
[21:14:34 CET] <alexpigment> (mp3, pcm, aac, ogg, flac, etc)
[21:14:34 CET] <furq> Stream #0:0: Audio: flac, 44100 Hz, mono, s16 (8 bit)
[21:14:35 CET] <furq> fun
[21:15:05 CET] <alexpigment> so how do you get an 8-bit file?
[21:15:14 CET] <alexpigment> do you have to feed it an 8bit source and then use s16?
[21:15:15 CET] <furq> i encoded an 8-bit wav and then used the flac cli
[21:15:19 CET] <alexpigment> gotcha
[21:15:21 CET] <furq> i assume there's some way to do it with ffmpeg but idk how
[21:15:31 CET] <alexpigment> yeah, i only know about sample fmt
[21:15:32 CET] <furq> the only way i know to set the bit depth with flac is -sample_fmt and that doesn't work
[21:15:42 CET] <durandal_1707> 8bit needs heavy dither
[21:15:44 CET] <alexpigment> i bet there's a filter to convert to 8bit
[21:15:57 CET] <furq> durandal_1707: i don't think he's that bothered about sound quality
[21:16:00 CET] <durandal_1707> and it sounds bad
[21:16:00 CET] <alexpigment> well fortunately, i'm not too concerned about the quality
[21:16:01 CET] <alexpigment> yeah
[21:16:02 CET] <alexpigment> :0
[21:16:13 CET] <alexpigment> i'm not really trying to squeeze out all the quality i can for 8bit ;)
[21:16:37 CET] <alexpigment> this is more about "oh, does something fail when i throw a file at it"
[21:16:58 CET] <furq> it is probably worth testing other flac encoders
[21:17:12 CET] <furq> i know some of them use features that libflac doesn't that are part of the spec and some that aren't part of the spec
[21:17:12 CET] <alexpigment> yeah, you're probably right
[21:17:15 CET] <alexpigment> i'll put that on my list
[21:17:18 CET] <furq> flaccl will definitely encode stuff outside of spec
[21:17:32 CET] <furq> i'd put that down the list though because pretty much everyone uses libflac or ffmpeg afaik
[21:18:13 CET] <alexpigment> yeah, probably a good point
[21:18:55 CET] <furq> ape, wv, shn, tta and tak are the only other lossless formats i've ever seen in the wild
[21:19:00 CET] <furq> in order of how often i've seen them
[21:19:12 CET] <alexpigment> i don't even know what tta or tak are
[21:19:19 CET] <furq> stuff like optimfrog and LA aren't even worth testing really
[21:19:26 CET] <alexpigment> and ape and shn i haven't seen since flac really took off
[21:19:28 CET] <furq> hardly anything even decodes them
[21:19:35 CET] <furq> there's still a lot of shn on archive.orgf
[21:19:36 CET] <furq> -f
[21:19:44 CET] <alexpigment> yeah, i'll definitely test it
[21:19:49 CET] <furq> and ape is popular on non-western p2p
[21:19:57 CET] <alexpigment> ape is popular in 2001
[21:19:58 CET] <alexpigment> ;)
[21:19:58 CET] <furq> got to get that extra 1% compression
[21:20:01 CET] <furq> yeah pretty much
[21:20:08 CET] <furq> it's popular in countries where they haven't upgraded anything since 2001
[21:20:11 CET] <alexpigment> haha
[21:20:30 CET] <alexpigment> if you find a house with a VCD player, you might find an APE file or two
[21:21:22 CET] <furq> i've seen plenty of ape in the last few years
[21:21:29 CET] <furq> any reasonable person just converts it to flac though
[21:22:12 CET] <furq> decoding ape ultra quality is actually slower than encoding flac -8 here
[21:22:31 CET] <furq> when i've encoded it it's slowed the conversion down by more than 50%
[21:22:56 CET] <hojuruku> https://bugs.freedesktop.org/show_bug.cgi?id=105277 i've taken the time to write up the bug for ffmpeg's vaaapi with mesa git's radeonsi driver on polaris hardware creating corrupt streams. What is the avc flag in mp4 video stream do.. see the ticket
[21:23:18 CET] <hojuruku> < is_avc=true
[21:23:18 CET] <hojuruku> < nal_length_size=4
[21:23:18 CET] <hojuruku> ---
[21:23:18 CET] <hojuruku> > is_avc=false
[21:23:18 CET] <hojuruku> > nal_length_size=0 - will that cause problems is_avc=false?
[21:23:24 CET] <alexpigment> fortunately, audio encoding these days really is trivial for most formats. if one codec is slower but much more compatible, i'll take the slower option every time
[21:23:39 CET] <furq> i meant ape decoding
[21:23:50 CET] <alexpigment> oh i read that wrong
[21:23:54 CET] <alexpigment> decoding is slower than encoding flac
[21:23:55 CET] <alexpigment> gotcha
[21:23:57 CET] <furq> yeah
[21:25:31 CET] <hojuruku> JEEB: does that bug report make the issue clearer. I really appreciate the help you've given me with this on and off over the last month.
[21:28:29 CET] <jkqxz> hojuruku:  Does it work if you make a raw file and then remux it afterwards?
[21:29:20 CET] <jkqxz> That is, don't make the mp4 file in one step.
[21:30:16 CET] <jkqxz> The Mesa VAAPI implementation doesn't support packed headers, so you end up with no extradata in the file if you mux directly to mp4 or other format with global headers.
[21:33:55 CET] <chance83> is there a way to stop ffprobe decode errors by having it wait to decode until it gets sps/pps?
[21:34:04 CET] <alexpigment> furq: are you aware of any optimizations flac makes for 22khz? this should sound way worse than it does
[21:34:36 CET] <furq> not really but i've never encoded anything other than 16/44 or 16/48
[21:34:45 CET] <alexpigment> it's really weird
[21:34:49 CET] <hojuruku> jkqxz: can you give an exmaple of how to try this. the corrupted file of sorts is on the freedesktop ticket (8mb)
[21:34:57 CET] <alexpigment> i would have no idea it wasn't 44 or higher
[21:35:04 CET] <hojuruku> jkqxz: you can only see it's corrupt if you try and play with totem / gstreamer or one of many hardware players.
[21:35:08 CET] <alexpigment> without a side by side. and even then, i'm having a hard time hearing the difference
[21:35:59 CET] <hojuruku> jkqxz: with avc off and a different nal_length_size=0 is that a problem?
[21:37:01 CET] <jkqxz> Yeah, your file there works fine in an ffmpeg-based player (e.g. mpv).  So use one of those or remux it afterwards.
[21:42:32 CET] <philipp64> hi. got a newbie developer question... I want to be able to test network performance on video streaming on a headless device. I'm thinking I could write a null rendering output device.
[21:43:09 CET] <philipp64> I want it to render in realize, so it would "pace" itself to the frame rate, and then allow me to measure jitter, loss, etc. any pointers on adding such an output driver?
[21:56:59 CET] <hojuruku> GST_DEBUG=3 totem https://bugs.freedesktop.org/attachment.cgi?id=137664 , see if it works.
[21:57:00 CET] <hojuruku> https://bugs.freedesktop.org/show_bug.cgi?id=105277#c2
[21:57:38 CET] <hojuruku> The source file is throwing ffmpeg off, vaapi encoding works perfectly with other source files such as big buck bunny the plot thickens jkqxz  JEEB
[22:00:36 CET] <jkqxz> And does this new file work if you remux it after the encode?
[22:03:15 CET] <jkqxz> Like "ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.file -vf scale_vaapi=w=1366:h=768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -profile:v constrained_baseline -quality:v 0 -level:v 3.1 -coder:v cavlc intermediate.h264 ; ffmpeg -i intermediate.h264 -c:v copy output.mp4" or something.
[22:07:34 CET] <hojuruku> jkqxz:  i'll give that a test, but i just found out gstreamer has got the same bug, see the ticket new comments. gstreamer is also failing with mesa vaapi on polaris too the same way when it does the encoding.
[22:43:11 CET] <hojuruku> jkqxz: i'm testing it now mate sorry for the delay, someone asked me to check something on the ticket too: https://bugs.freedesktop.org/show_bug.cgi?id=105277#c4 it doesn't relate to that gstreamer bug at all, this is something new.
[22:56:19 CET] <alexpigment> are there lossy formats that support 24-bit audio?
[22:56:54 CET] <alexpigment> i'm not seeing any indication of bit depth in the resultant files (aac, ac3, ogg, mp3, etc)
[22:58:34 CET] <JEEB> lossy formats generally don't have a "bit depth"
[22:58:41 CET] <alexpigment> i was starting to get that vibe
[22:58:46 CET] <JEEB> which is why most lossy decoders output float
[22:58:50 CET] <alexpigment> yeah
[22:58:56 CET] <alexpigment> ftlp (24-bit) is what they all show
[22:59:02 CET] <alexpigment> er
[22:59:03 CET] <alexpigment> fltp
[22:59:21 CET] <alexpigment> that's in the encoding info that ffmpeg spits out
[22:59:23 CET] <JEEB> then you get to dither that to whatever value space you need at the end
[22:59:48 CET] <alexpigment> well, i guess that saves me some trouble on these batch file encodes, at least
[22:59:50 CET] <JEEB> that said I think the DTS spec requires specific decoding so that the attachment extensions can be added to it
[23:00:17 CET] <JEEB> so it in theory has a bit depth in output, and then on that decoded output you get a crankload of extensions like the XLL one
[23:00:28 CET] <JEEB> which people call DTS-HD MA (aka "the lossless thing")
[23:00:48 CET] <JEEB> well, not in theory but basically DTS decided that shit gets decoded to this precision in this way
[23:00:55 CET] <JEEB> and then you can hoop things on top of that :P
[23:01:24 CET] <JEEB> but that's kind of the outlier
[23:01:43 CET] <JEEB> and you would in theory get better lossy output by having a full floaty decoding flow
[23:01:50 CET] <alexpigment> well, would dolby's equivalent not be the same?
[23:01:53 CET] <JEEB> no
[23:02:00 CET] <JEEB> truehd is MLP
[23:02:03 CET] <JEEB> which is a separate format
[23:02:15 CET] <alexpigment> ah
[23:02:30 CET] <hojuruku> jkqxz: fmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -t 60 -i pony.mkv -map 0:0 -vf scale_vaapi=w=1366:h=768 -c:v h264_vaapi -b:v 2000k -qp 20 -bf 0 -profile:v constrained_baseline -sn -quality:v 0 -level:v 3.1 -coder:v cavlc -c:a aac -ab 128k -ar 48000 -ac 2 -sn vaapitest3-intermediate.h264; ffmpeg-git -i vaapitest3-intermediate.h264 -t 60 -i pony.mkv -map 0:0 -map 1:1 -movflags +faststart -c:a aac
[23:02:30 CET] <hojuruku> -ab 128k -ar 48000 -ac 2 -sn vaapitest3.mp4 DID NOT WORK :(
[23:03:12 CET] <jkqxz> Um, what even happens if you mux aac into a raw H.264 file?
[23:03:31 CET] <hojuruku> i didn't do that i used map to only take the video stream
[23:04:14 CET] <jkqxz> Why didn't you do it without the audio?  That makes it much more confusing.
[23:04:21 CET] <alexpigment> jkqxz: i think we all know the answer to this. the world ends
[23:07:29 CET] <hojuruku> jkqxz: [mp4 @ 0x55a35c67acc0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[23:07:32 CET] <jkqxz> There is also no copy in the send command, which I think means it would be reencoding (presumably with x264).
[23:07:48 CET] <hojuruku> jkqxz: doing it that way may have given me a new error explaining the problem.
[23:08:28 CET] <classsict> hi, someody can explainme or pointme where find what mean this "Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'"
[23:08:47 CET] <classsict> I'm use vaapi
[23:12:14 CET] <jkqxz> classsict:  <https://trac.ffmpeg.org/wiki/Hardware/VAAPI#SurfaceFormats>
[23:14:52 CET] <classsict> yes, I read, but really I'm a little lost here
[23:15:31 CET] <classsict>  ffmpeg  -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi  -ar 48000 -ac 2 -f s16le -i /dev/zero  -i input.mp4   -c:v h264_vaapi -b:v 1M -maxrate 1M  -bufsize 2M  -acodec libopus -ar 48000 -f flv output.flv
[23:15:52 CET] <classsict> I'm create a silence audio stream.
[23:16:28 CET] <classsict> and the input is h264, i'm not sure if hw decoder can decode this, or not
[23:20:44 CET] <atomnuker> you're trying to hardware decode from /dev/null
[23:21:21 CET] <hojuruku> jkqxz: you can't put audio in a .h264 file. btw when it's video only in the mp4 it works in totem. I will go test it in the hardware player now too.
[23:21:24 CET] <hojuruku> [h264 @ 0x556e70a00800] h264 files have exactly one stream
[23:21:25 CET] <hojuruku> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
[23:21:25 CET] <hojuruku> Error initializing output stream 0:0 --
[23:24:45 CET] <hojuruku> classsict: no audio stream is silence. you want to encode a silent audio stream?... why?
[23:25:12 CET] <classsict> because I have to convert in hls
[23:25:24 CET] <alexpigment> hojuruku: i haven't been following above, but if the problem is that you're trying to make an h.264 elementary stream, and you need to disable the audio, just use -an
[23:25:37 CET] <classsict> and some player expect audio, if not, doesn't work
[23:26:25 CET] <hojuruku> alexpigment: jkqxz told me to put the audio in an elementary stream, that's impossible so i gave my example to combine the video / audio. in doing that got a hint from ffmpeg what is wrong with the mesa encoded h264 stream - TIMESTAMPS in the stream.
[23:26:55 CET] <alexpigment> gotcha
[23:27:17 CET] <alexpigment> sorry, it just seemed like if you were getting the "exactly one stream" error, you needed to explicitly -an the audio
[23:27:28 CET] <alexpigment> anyway, i'll leave it to you and jkqxz to figure it out
[23:30:32 CET] <jkqxz> No, I was trying to suggest leaving the audio out completely because it confuses everything.  You definitely don't want to encode audio on the first step because H.264 annex B stream contain only H.264, not anything else.
[23:31:55 CET] <jkqxz> In any case, if all of your stuff can play the video-only file then that indicates the audio is the problem and all of this mucking around with video is a red herring.
[23:33:43 CET] <jkqxz> Or the muxing somehow.
[23:35:25 CET] <hojuruku> jkqxz: or broken timestamps in a video stream confusing some players trying to mux it all together?
[23:35:50 CET] <hojuruku> jkqxz: remember the same command line options are used to encode the audio when i'm using libx264
[23:41:55 CET] <alexpigment> weird. does opus only support 48khz??
[23:44:55 CET] <kerio> yep
[23:45:06 CET] <alexpigment> hmmm
[23:45:11 CET] <alexpigment> seems kinda limiting, but ok ;)
[23:45:19 CET] <kerio> it's a lossy codec
[23:45:54 CET] <kerio> any artifacts caused by the resampling are shadowed by the loss in compression
[23:45:58 CET] <alexpigment> yeah, but if the most common input sample rate is 44100, it seems weird to not accept it
[23:47:30 CET] <kerio> the most common output sample rate is 48000 tho
[23:48:42 CET] <alexpigment> kerio?
[23:48:49 CET] <alexpigment> 1983
[23:48:51 CET] <alexpigment> CD
[23:48:53 CET] <alexpigment> 44.1
[23:49:06 CET] <kerio> k
[23:49:16 CET] <JEEB> broadcast is pretty much all 48kHz
[23:49:21 CET] <alexpigment> there is 35 years of 44.1k audio out there
[23:49:24 CET] <JEEB> while CD and related things are 44.1kHz
[23:49:39 CET] <alexpigment> right
[23:49:41 CET] <furq> the most common output rate is 48khz though
[23:50:15 CET] <alexpigment> if the assumption that opus is only going to be used for audio from video files, then maybe there's a point to be made there
[23:50:29 CET] <furq> most playback paths will resample 44.1 to 48
[23:51:10 CET] <furq> idk about specialist audio equipment but that's a huge minority these days
[23:51:21 CET] <alexpigment> anyway, i realized that the failure was because i was explicitly setting -ar
[23:51:31 CET] <kerio> the assumption is that having one model is simpler than having two
[23:51:31 CET] <alexpigment> honestly, i'm fine with the assumption
[23:51:51 CET] <alexpigment> i just think it's weird that it fails when you specify a non-48000 -ar value
[23:52:10 CET] <furq> that's an ffmpeg/libopus interop failing really
[23:52:17 CET] <furq> the actual opus cli doesn't do that
[23:52:34 CET] <kerio> isn't there some "opus custom" thing that does actually let you pick a sample rate
[23:52:48 CET] <furq> yeah but it's recommended not to use it
[23:52:53 CET] <furq> it's not guaranteed to be decodable
[23:53:09 CET] <JEEB> https://wiki.xiph.org/OpusFAQ#How_do_I_use_44.1_kHz_or_some_other_sampling_rate_not_directly_supported_by_Opus.3F
[23:53:20 CET] <JEEB> the xiph.org FAQ has a thing about non-48kHz rates
[23:53:50 CET] <hojuruku> https://bugs.freedesktop.org/show_bug.cgi?id=105277#c6 JEEB  jkqxz holy crap guys you did it - you found a workaround to get my hardware player happy, even though totem isn't appeased. :) :) :)
[23:54:11 CET] <furq> i like how the answer to the question is "how do i use 44.1khz?" is "don't use 44.1khz"
[23:54:14 CET] <furq> -is
[23:54:24 CET] <JEEB> yup, "just resample it around it"
[23:55:05 CET] <alexpigment> k, well it's probably ideal to warn rather than error at -ar 44100
[23:55:17 CET] <alexpigment> that's my 2 cents on it; you may all disagree
[23:55:31 CET] <JEEB> if you didn't specify the rate it wouldn't error out
[23:55:32 CET] <furq> you're probably right but there's probably Reasons that doesn't happen
[23:55:50 CET] <jkqxz> hojuruku:  Right, so it probably is the headers.  The Intel implementation does have correct headers so I would expect it not to be affected by the same problem, then.  (But very interesting if it is!)
[23:55:50 CET] <alexpigment> i'm creating this audio test bank with batch commands, and all of the sudden my script fails massively on opus except for 4 files
[23:55:50 CET] <JEEB> it's just that ffmpeg.c doesn't do resampling in an encoder unless it's part of the encoder in the spec
[23:56:03 CET] <JEEB> or well, FFmpeg doesn't do it :P
[23:56:36 CET] <JEEB> ffmpeg.c would insert the resampler for you if you hadn't told it to keep the input at 44.1kHz
[23:56:43 CET] <alexpigment> right
[23:56:46 CET] <alexpigment> it does
[23:56:50 CET] <hojuruku> jkqxz: i wont copy paste you again - you can add that to freedesktop bugzilla yourself  - get some cred for helping fix this issue.
[23:57:17 CET] <alexpigment> i'm just thinking there's no reason to fail. just say "unsupported sample rate, resampling to 48000"
[23:57:29 CET] <JEEB> but the encoder doesn't resample?
[23:57:47 CET] <JEEB> and there must be a reason to require 44100
[23:57:57 CET] <alexpigment> i'm confused
[23:57:59 CET] <JEEB> thus since you have specifically said you want 44100 if 44100 is not good it will error
[23:58:14 CET] <JEEB> read the FAQ I linked :P
[23:58:26 CET] <alexpigment> i did
[23:58:46 CET] <alexpigment> i'm saying that if you don't specify -ar 44100, it resamples for you
[23:58:49 CET] <alexpigment> ffmpeg, that is
[23:58:58 CET] <alexpigment> if you specify -ar 44100, it fails
[23:59:04 CET] <JEEB> yes, since you didn't tell it I WANT 44100
[23:59:09 CET] <alexpigment> do we really need a failure case, since there is no other option?
[23:59:23 CET] <JEEB> well there's plenty of other things that you specify because you want EXACTLY THAT
[23:59:28 CET] <JEEB> this is just one of them
[23:59:47 CET] <alexpigment> on the other hand, you can specify yuv420p for hardware encoders and it uses nv12
[23:59:57 CET] <alexpigment> it's not a consistent standpoint across the board
[23:59:59 CET] <JEEB> I have no idea about that bullshit
[00:00:00 CET] --- Wed Feb 28 2018