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

[burek]

[00:49:03 CEST] <ZiNC> Hi.
[00:49:07 CEST] <kepstin> wfbarksd_: note that "seeking to the last packet and checking" doesn't work on some formats, e.g. mpeg-ts, where the timestamps can reset in the middle of the stream.
[00:49:51 CEST] <ZiNC> Is there a way to check what video formats/levels ffmpeg's hardware decoder detects and can use?
[03:00:48 CEST] <debianuser> Hm... Hello. I'm reencoding some mpeg2 videos into h264 and I noticed that, while I haven't set any video filters, ffmpeg automatically deinterlaces the video for me. I don't really mind, but... how can I select which deinterlacer to use for that?
[03:06:05 CEST] <ZiNC> I don't know, but if you want the best quality deinterlacing you may have to use AviSynth scripts and a whole bunch of plugins.
[03:06:18 CEST] <ZiNC> And a whole lot more CPU time.
[03:07:31 CEST] <furq> debianuser: unless something drastically changed then it doesn't deinterlace automatically
[03:07:44 CEST] <furq> but you do have to manually set the interlaced flags on the output if you want to encode interlaced
[03:08:33 CEST] <furq> iirc just `-x264-params tff=1` should work
[03:10:58 CEST] <ZiNC> For high quality deinterlacing search for QTGMC. It's a hassle to collect and get running, and with good performance, unless there are neat packages around that didn't exist when I last used it.
[03:12:06 CEST] <furq> qtgmc does a great job on sd mpeg2
[03:12:11 CEST] <furq> but if you do use it then use it through vapoursynth
[03:12:14 CEST] <debianuser> Well, maybe I misunderstand something... Does the "yuv420p(tv, top first)" mean that the video is interlaced?
[03:12:19 CEST] <debianuser> Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc
[03:12:26 CEST] <furq> debianuser: it means it's signaled as tff
[03:12:41 CEST] <furq> iirc all dvd sources are signaled as tff even if they're progressive
[03:13:04 CEST] <furq> so if the output looks progressive in a player and you definitely don't have deinterlacing enabled then that's probably what's going on
[03:13:30 CEST] <furq> the only way to tell for sure is to check and see if the input looks interlaced
[03:14:00 CEST] <furq> and hope that it doesn't because that makes your life vastly simpler
[03:40:04 CEST] <debianuser> Hm... I can upload a small sample...
[03:52:15 CEST] <debianuser> https://www.sendspace.com/file/5x771b (frags.zip, 3.38MB) - two fragments inside. If you watch first fragment frame by frame in its last frame you may see: https://i.imgur.com/Ws6qArB.jpg which looks very interlaced. But! If you cat those two files together (`cat frag*.ts > both.ts`) and play them frame by frame, you won't see that frame there. How could that be?
[03:57:22 CEST] <furq> doesn't look interlaced to me in mpv
[03:58:12 CEST] <furq> https://0x0.st/s__W.png
[03:58:16 CEST] <furq> that's the last frame i get in frag1.ts
[04:05:45 CEST] <debianuser> I was dumping it with `mplayer -vo png`. So either mpv deinterlaced that last frame for you, or mplayer somehow interlaced only the last frame of the video for me. :)
[04:06:10 CEST] <furq> i would assume mplayer just didn't fully decode the last frame
[04:06:46 CEST] <furq> if it's signaled as tff then it's still technically a field-based input, it's just that both fields are from the same frame
[04:07:41 CEST] <furq> anyway yeah that looks progressive to me but you might want to check a few different spots in the full program
[04:08:07 CEST] <furq> broadcast is more than happy to switch between interlaced and progressive (or between tff and bff if they're feeling particularly evil)
[04:11:30 CEST] <debianuser> "i would assume mplayer just didn't fully decode the last frame" -- good idea, that's possible too, my mplayer is old and probably buggy.
[04:12:36 CEST] <debianuser> "signaled as tff then it's still technically a field-based input, it's just that both fields are from the same frame" - Ah! And those fields are still interlaced? Is there any way to check that, e.g. to dump individual "fields" within frame, or, maybe, see them in ffprobe, for example?
[04:15:16 CEST] <furq> debianuser: -vf separatefields
[04:28:44 CEST] <debianuser> furq: I think I understand everything now. Thanks a lot for your help and explanations!
[06:22:04 CEST] <JC_Yang> questions about avformat_new_stream(fmt_ctx, NonNull_Known_Codec), what else do I need to fill in the AVStream.codecpar? for video, maybe width and height? and how about audio? since the documents in avformat.h suggest prefer manually initialize to avcodec_parameters_copy(), but does not mentioned how to in case when avformat_new_stream is passed with NonNull_Known_codec.
[07:39:34 CEST] <sarab> Hi, can i ask questions related to ffmpeg?
[07:41:39 CEST] <sarab> i want to play and record a device simultaneously. i can do it individually but how to do it simultaneousy as it says device resource busy
[09:37:49 CEST] <MJBauer> Hi. Is it possible to record a rtsp stream in a ring-buffer and save a single image N seconds before an event which is triggerd with a bash SIGNAL?
[09:38:04 CEST] <MJBauer> or any other trigger...
[10:11:58 CEST] <JC_Yang> yes, you can. it's not a complex task, provided that you've got big enough ram, it's an easy task
[10:29:25 CEST] <MJBauer> JC_Yang: RAM should not be the problem. Can you explain roughly how this can be done?
[10:40:04 CEST] <JC_Yang> cache the video frames for a long enough time with keyframe as head of the buffer to ease decoding and when you need to take save the frame, feed a decoder with all the frames in the buffer and simply count which frame you need to capture, then save the decoded pic to file, done. remember frame contain pts, combine with "keyframe as head" as the buffer, it provides good enough guidance for "how to choose what to cached". is this what you asked for?
[10:44:42 CEST] <Mavrik> I did something like that once - I ran a demuxer on RTSP stream and only decoded each keyframe, encoded it into JPEG and stored it into memory.
[10:45:08 CEST] <Mavrik> That JPEG could be retrieved via HTTP at any time so you always got an decently up to date thumbnail of a stream with rather lowish CPU cost.
[10:52:15 CEST] <MJBauer> JC_Yang: yes, this would suite my requirements. However, @Mavrik 's solution looks much easier.
[10:53:23 CEST] <MJBauer> @Mavrik: you solution will need more cpu i guess..
[10:54:16 CEST] <Mavrik> I guess.
[10:54:18 CEST] <MJBauer> Do you think a raspberry pi 3B+ can handle 4 video streams (720p) at once? It is connected with cable ethernet.
[10:54:24 CEST] <Mavrik> You can always just store demuxed frame.
[10:54:31 CEST] <Mavrik> And decode it when you need it.
[10:54:41 CEST] <Mavrik> Which is pretty much what JC_Yang recommended :)
[10:55:03 CEST] <MJBauer> How would i store a demuxed frame and decode it later?
[10:55:08 CEST] <furq> MJBauer: it should be ok if you're only decoding keyframes
[10:57:17 CEST] <MJBauer> furq: how much keyframes are there typically in a rtsp stream? 1 per second?
[10:57:38 CEST] <furq> probably less than that
[10:58:41 CEST] <JEEB> it really depends on the stream
[10:59:34 CEST] <Mavrik> Yeah, it can be anything from "every frame is a keyframe" to "there's one keyframe at the start" :)
[10:59:53 CEST] <MJBauer> how can I determine it? Is there something like a "stat" tool to see the video-stream properties?
[11:00:28 CEST] <JEEB> ffprobe can output information on a running stream
[11:00:54 CEST] <furq> well you'll know if it's every frame because the pi will start choking to death
[11:01:18 CEST] <MJBauer> furq: XD true
[11:01:42 CEST] <furq> for 720p h264 i would expect somewhere between once every 2 and 10 seconds
[11:01:46 CEST] <furq> but yeah, it could be anything
[11:02:46 CEST] <JC_Yang> some streams have pretty long keyframe interval, so "cached then decoded all and get the very frame you want" might be a better approach
[11:03:33 CEST] <MJBauer> every 2 to 10 secs would be not frequent enough :(
[11:04:24 CEST] <furq> if it's always the same rtsp streams then just check and see
[11:04:52 CEST] <MJBauer> JC_Yang: would i use cache:URL (as said in https://ffmpeg.org/ffmpeg-protocols.html#cache )?
[11:06:29 CEST] <JC_Yang> don't have ideas, that's not a part that I'm familiar with
[11:11:44 CEST] <MJBauer> JEEB: ffprobe displays me the following: Stream #0:1: Video: h264 (Constrained Baseline), yuv420p(progressive), 240x160, 24 fps, 24 tbr, 90k tbn, 48 tbc
[11:12:08 CEST] <MJBauer> which one of that is the keyframe-rate?
[11:12:18 CEST] <JEEB> MJBauer: you would have to output packets or frames
[11:12:27 CEST] <JEEB> those then can contain a flag for being a random access point
[11:18:27 CEST] <MJBauer> Wouldn't it be possible to "restream" with a delay of, let's say, 5 seconds and then issue a snapshot with ffmpeg on that delayed-stream?
[11:18:31 CEST] <Mavrik> There's no such thing as keyframe rate.
[11:18:55 CEST] <Mavrik> Any frame can be a keyframe depending on encoder decision :/
[11:19:33 CEST] <MJBauer> so i don't need to worry about if it is a keyframe or not?
[11:19:58 CEST] <MJBauer> Mavrik: thank's for pointing out. I am new to video-processing...
[11:24:15 CEST] <MJBauer> after reading more discussions in the net, i would like to change my original question.
[11:25:06 CEST] <MJBauer> How can i setup a rtsp live stream with a timeshift of 5 Minutes, so i can grap a snapshot at specific time from the timeshift-stream?
[11:25:32 CEST] <JEEB> RTSP sounds like VLC might support serving it better
[11:25:36 CEST] <JEEB> no idea about timeshift
[11:25:42 CEST] <JEEB> usually a feature of the serving side
[11:25:51 CEST] <JEEB> so I recommend #videolan for RTSP serving needs
[11:30:09 CEST] <MJBauer> JEEB: so it qould be videolan doing the timeshift and ffmpeg grabbing a still image of the stream?
[13:13:44 CEST] <kerio> whoever came up with libavformat needs jesus btw
[13:55:42 CEST] <DHE> kerio: how many different file formats you have to deal with? there's a lot each with their own quirks. from files that don't have an actual "fps" value saved anywhere to files that are actually network streams
[13:56:35 CEST] <kerio> i just need a way to store a single ffvhuff or ffv1 stream
[14:02:27 CEST] <kerio> actually i wonder if i can just retrieve the bitstream
[14:05:16 CEST] <kerio> how do i parse a ffvhuff bitstream
[16:10:37 CEST] <kerio> ok i think i understand how to use libavformat
[16:10:52 CEST] <kerio> and whoever wrote it still needs jesus
[16:13:14 CEST] <atomnuker> its simple - create an avf context, create a stream, populate the codecpar context from an avctx (if you've got one, or do it manually), then write a header, write packets in a loop and write a trailer
[16:13:44 CEST] <atomnuker> make sure to mark the stream avpackets belong to if you're writing interleaved audio and video streams
[16:24:32 CEST] <zevarito> hi guys, is anyone familiar with the encoder message input picture width (x) is greater than stride (y) ?
[16:25:25 CEST] <zevarito> I am having troubles encoding hls, look like a strange issue since it only happen when I simultaneously reproduce the stream
[16:31:16 CEST] <DHE> API warning from mpegts muxer: "frame size not set", which seems to be a side-effect of AAC encoding. know how to fix this?
[16:31:55 CEST] <DHE> from my own checking: function get_audio_frame_duration() returns 0 because AAC has no fixed packet/frame duration and at mpegts initialization time it doesn't have anything to use as a guess
[16:37:49 CEST] <DHE> for now I'm just going to ignore it
[16:55:00 CEST] <upgrade> hi all, its possible to capture stream from youtube and restream to another rtmp server?
[16:55:22 CEST] <upgrade> using youtube-dl, for example
[16:55:45 CEST] <DHE> well, yes. ffmpeg should accept the URLs youtube-dl can provide
[16:56:51 CEST] <upgrade> can u tell when i must read about this?
[17:27:04 CEST] <waterworks> I'm trying to build ffmpeg with nvenc support. The configure script says it cannot find ffnvcodec but the headers are installed and is listed in pkg-config --list-all. MSYS64 32 bit VS2017 https://pastebin.com/DezFQtAb
[18:54:41 CEST] <anill> How to make ffmpeg run as daemon on windows.?
[19:15:54 CEST] <anill> DHE: Hi
[19:19:10 CEST] <DHE> sorry bus
[19:19:12 CEST] <DHE> busy
[19:21:12 CEST] <ariyasu> what do you mean a daemon?
[19:21:19 CEST] <ariyasu> so you can call it from anywhere?
[19:21:31 CEST] <ariyasu> you can add it to your path to do tha
[21:57:40 CEST] <migu3x> Hello I'm using ffmpeg to download .ts streams with following command ```ffmpeg.exe -i 'source.m3u8' -c copy out.ts``` but when the video gets to 8 hours I start getting discontinuity errors and it stops capping/downloading
[21:58:01 CEST] <migu3x> Any idea how I can prevent this from happening? Is it a MPEG-TS file issue?
[22:07:00 CEST] <migu3x> I will be sitting here expecting somebody knows the answer
[22:08:38 CEST] <tom13> how large does the file get
[22:09:06 CEST] <JEEB> I think libavformat should handle discontinuities and generally discontinuities happen every... twenty-something hours
[22:09:09 CEST] <migu3x> different sizes
[22:09:19 CEST] <JEEB> of course it depends on how far into the timestamps you are when it starts
[22:09:24 CEST] <JEEB> oh right, HLS
[22:09:37 CEST] <migu3x> What sohuld I do?
[22:09:39 CEST] <JEEB> the HLS demuxer isn't actually noted as "this has discontinuities"
[22:09:47 CEST] <JEEB> even though it uses mpeg-ts underneath
[22:09:49 CEST] <JEEB> which has it
[22:09:49 CEST] <migu3x> I mean the timestamps
[22:10:17 CEST] <JEEB> also, do note that something dumber might be able to just rip it for you
[22:10:20 CEST] <DHE> MPEG-TS internal timestamps overflow/wrap around every 26.5 hours or so. on a live stream you could join it at any point along that timeline.
[22:10:33 CEST] <JEEB> because you literally just need to concatenate the MPEG-TS files
[22:10:51 CEST] <JEEB> so you download the playlist and download segments, rince n' repeat
[22:12:46 CEST] <migu3x> you meean download al .ts files
[22:12:49 CEST] <migu3x> separately and join them?
[22:13:03 CEST] <JEEB> or just have a script that writes their bytes into a single file to begin with?
[22:14:34 CEST] <migu3x> hows that?
[22:14:52 CEST] <migu3x> They have EXT--X-KEY it isn't as simple as just grabbing the .ts urls
[22:15:19 CEST] <migu3x> And I'm not sure but I think the m3u8 gets updated over time and the segments aren't linealy numerated
[22:15:32 CEST] <migu3x> numbered*
[22:32:08 CEST] <migu3x> and when capturing with VLC
[22:32:20 CEST] <migu3x> i get a strange "nothing to play" debug message and doesnt download anything
[22:52:41 CEST] <salviadud> I was here a couple of days ago, when I asked a really good question and my internet lagged me out, so unfortunate, I must ask again.
[22:53:08 CEST] <salviadud> I have a .mkv file with 7.1 atmos audio (truehd)
[22:53:34 CEST] <salviadud> I am converting that audio stream to DTS with dca, but I am not playing with any bitrate options
[22:53:49 CEST] <salviadud> I want to know if there's some equivalent for quality, like -crf
[22:54:03 CEST] <salviadud> Or maybe I should just keep it that way (sounds fine to me)
[22:54:50 CEST] <furq> i'm pretty sure dts core is always cbr
[22:55:04 CEST] <salviadud> constant?
[22:55:38 CEST] <furq> only dtsma is vbr, and i don't think ffmpeg supports encoding that anyway
[22:55:40 CEST] <furq> and yes constant
[22:55:57 CEST] <salviadud> So, if I don't specify a bitrate
[22:56:10 CEST] <salviadud> It will default to whatever the original stream is?
[22:56:19 CEST] <furq> no it'll default to whatever the default for the encoder is
[22:57:07 CEST] <furq> which is apparently 1411kbps
[22:57:15 CEST] <furq> i guess for dts-wav compatibility or something
[22:57:30 CEST] <salviadud> so, on an 8 channel stream
[22:57:35 CEST] <salviadud> 7000 kbps aprox?
[22:57:51 CEST] <salviadud> at least, I mean
[22:57:58 CEST] <furq> dts core maxes out at 1536kbps iirc
[22:58:10 CEST] <salviadud> No matter the number of chans?
[22:58:13 CEST] <furq> right
[22:58:22 CEST] <furq> that should be more than enough for 7.1 though
[22:58:38 CEST] <furq> bearing in mind raw stereo pcm at 48k is 1536kbps
[22:58:51 CEST] <furq> and dts is lossy
[22:59:29 CEST] <salviadud> I get this from the -codecs parameter ---> DEA.LS dts
[22:59:39 CEST] <salviadud> It seems it could be lossless as well
[23:00:39 CEST] <furq> shrug
[23:00:41 CEST] <furq> i've never used it
[23:01:43 CEST] <salviadud> Well, it is experimental
[23:01:53 CEST] <salviadud> I'm going to trust the default values I guess
[23:02:53 CEST] <JEEB> wouldn't that be the decoder that has lossless?
[23:03:27 CEST] <salviadud> JEEB, it would seem that way
[23:03:50 CEST] <furq> oh right yeah
[23:03:51 CEST] <JEEB> yea since caps_internal has just THREADSAFE | INIT_CLEANUP
[23:03:57 CEST] <JEEB> the decoder has XLL support yes
[23:04:04 CEST] <furq> i notice -profile dts_hd_ma is a thing
[23:04:06 CEST] <JEEB> XLL being what the marketing side calls DTS-HD MA
[23:04:10 CEST] <furq> but it doesn't seem to do anything for the encoder
[23:04:12 CEST] <migu3x> Any idea about what I said?
[23:04:27 CEST] <JEEB> XLL being something like eXtension LossLess
[23:04:30 CEST] <furq> at least dts_96_24 is auto-resampling to 48k
[23:04:35 CEST] <furq> so i'm guessing the others don't work either
[23:04:42 CEST] <JEEB> yea, it's basic DTS
[23:04:51 CEST] <JEEB> I don't think anyone /wants/ to code DTS
[23:04:58 CEST] <salviadud> I do
[23:05:03 CEST] <JEEB> my condolences sir
[23:05:09 CEST] <salviadud> My AMP doesn't support atmos
[23:05:15 CEST] <JEEB> if it's a blu-ray just encode PCM
[23:05:22 CEST] <JEEB> well, uh
[23:05:23 CEST] <JEEB> ATMOS
[23:05:32 CEST] <salviadud> truehd codec
[23:05:36 CEST] <JEEB> (do note there's like N different things under the Dolby Atmos name)
[23:05:43 CEST] <furq> pcm is going to get pretty big for 7.1
[23:05:45 CEST] <JEEB> no, Atmos are different extensions
[23:05:54 CEST] <furq> but if it's just going straight to an amp then i guess who cares
[23:05:57 CEST] <JEEB> yea
[23:06:10 CEST] <JEEB> if you're on HDMI or something just rock PCM
[23:06:37 CEST] <JEEB> you're not going to gain anything by first decoding and then encoding into some lossy format (or even lossless to be honest)
[23:06:43 CEST] <salviadud> It's a samsung smart tv that does the initial read, then it passes through optical
[23:06:50 CEST] <JEEB> optical
[23:06:57 CEST] Action: salviadud laughs
[23:06:57 CEST] <JEEB> well that pushed out any lossless tuff
[23:06:59 CEST] <JEEB> *stuff
[23:07:07 CEST] <salviadud> Yeah, it's an old amp
[23:07:10 CEST] <JEEB> then just encode AC3
[23:07:13 CEST] <JEEB> if you need 5.1
[23:07:16 CEST] <salviadud> So, I'm guessing regular DTS is pretty good
[23:07:20 CEST] <JEEB> no it is not
[23:07:23 CEST] <salviadud> It does support 7.1
[23:07:23 CEST] <JEEB> DTS is goddamn awful
[23:07:32 CEST] <JEEB> without extensions no it doesn't
[23:07:52 CEST] <JEEB> and I see mono, stereo, 2.2, 5.0, 5.1 in the list of supported audio layouts
[23:07:53 CEST] <salviadud> What extensions do I need for 7.1?
[23:07:55 CEST] <JEEB> in the dcaenc
[23:08:03 CEST] <JEEB> let me see from the decoder
[23:08:24 CEST] <furq> oh
[23:08:27 CEST] <furq> it's XXCH apparently
[23:08:30 CEST] <JEEB> yes
[23:08:30 CEST] <furq> whatever ffmpeg calls that
[23:08:47 CEST] <furq> dts_es
[23:09:14 CEST] <JEEB> furq: there's plenty of XXCH strings in the code base so that name is utilized
[23:09:18 CEST] <furq> [dca @ 0000000000546be0] Specified channel layout '7.1' is not supported
[23:09:24 CEST] <JEEB> well yes I just noted that
[23:09:26 CEST] <furq> i get that with -profile:a dts_es
[23:09:27 CEST] <furq> so yeah
[23:09:28 CEST] <salviadud> So, if I want to encode as DTS with those extensions, I run -c:a dca with some flag?
[23:09:36 CEST] <JEEB> you cannot, nobody wrote that code
[23:09:42 CEST] <furq> yeah you need to use some other encoder
[23:09:43 CEST] <JEEB> and DTS is a god-awful audio format
[23:09:48 CEST] <furq> i'm not aware of any other free one
[23:10:03 CEST] <JEEB> only the lossless extensions save it for that use case although I'd much rather use PCM or TrueHD for blu-rays
[23:10:09 CEST] <salviadud> I do seem to need to turn up the volume, compared to AC-3
[23:10:45 CEST] <JEEB> anyways, AC3 or AAC is what you probably want to bit stream, but almost nothing but set-top-boxes support the latter
[23:10:53 CEST] <JEEB> if you need 5.1 over SPDIF
[23:11:25 CEST] <JEEB> not lossless of course because you barely have enough bandwidth for raw 2ch 48kHz 24bit audio track on SPDIF
[23:11:58 CEST] <salviadud> I don't get it though, if my DTS audio stream is larger than the equivalent AC-3 stream, why is it worse?
[23:12:08 CEST] <furq> does the eac3 encoder support 7.1
[23:12:21 CEST] <JEEB> oh we have eac3 encoder
[23:12:21 CEST] <JEEB> lol
[23:12:24 CEST] <furq> [eac3 @ 0000000000574bc0] Specified channel layout '7.1' is not supported
[23:12:25 CEST] <furq> nice
[23:12:43 CEST] <JEEB> yea it very much looks like a minor extension to ac3enc
[23:12:45 CEST] <salviadud> So, I'm just getting more audio channels on DTS?
[23:12:51 CEST] <JEEB> no, you're not?
[23:13:04 CEST] <JEEB> I don't know what on earth you're comparing
[23:13:32 CEST] <salviadud> Let me give you an example
[23:13:33 CEST] <furq> dts core only does 5.1
[23:13:50 CEST] <furq> if you're just transcoding with default arguments then i guess it's automatically downmixing
[23:13:59 CEST] <salviadud> Ohhh, I get it
[23:14:15 CEST] <salviadud> My 7.1 truehd gets downmixed to 5.1 with dts_core
[23:14:25 CEST] <furq> right
[23:14:33 CEST] <salviadud> Still, it spits out a higher bitrate than with AC-3
[23:14:46 CEST] <salviadud> So, isn't that better quality?
[23:14:53 CEST] <furq> pcm is higher bitrate than flac
[23:14:53 CEST] <JEEB> no?
[23:15:00 CEST] <JEEB> also you can set the darn bit rate
[23:15:12 CEST] <JEEB> what the default is up to everyone's surprise and amazement
[23:15:15 CEST] <JEEB> welcome to FFmpeg
[23:15:44 CEST] <salviadud> flac uses compression, pcm is raw
[23:16:17 CEST] <salviadud> Well, it sounds just the same, but I have to turn up the volume up a notch+
[23:16:30 CEST] <salviadud> Just saying, from experience.
[23:16:35 CEST] <salviadud> Comparing AC-3 with DTS
[23:16:45 CEST] <JEEB> yes, some of the formats have random normalization in the specification
[23:16:48 CEST] <kepstin> opus at 96kbps will sound better than mp3 at 128kbps, bitrate comparison between codecs doesn't make sense.
[23:16:58 CEST] <JEEB> that is, the proprietary ones
[23:17:00 CEST] <furq> thank you for a better example
[23:17:10 CEST] <JEEB> which would explain random volume differences with Patents Paid decoders
[23:22:12 CEST] <furq> do you think he ever found that hidden porno message
[00:00:00 CEST] --- Fri Jun  8 2018