Keshl has quit [Read error: Connection reset by peer]
Keshl has joined #ffmpeg
pah has quit [Ping timeout: 260 seconds]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
pah has joined #ffmpeg
fling has quit [Remote host closed the connection]
thilo has quit [Ping timeout: 276 seconds]
pulec is now known as purple
purple is now known as choked
choked is now known as boaconstractor
thilo has joined #ffmpeg
boaconstractor is now known as pulec
fling has joined #ffmpeg
Ogobaga has quit [Read error: Connection reset by peer]
Ogobaga has joined #ffmpeg
qaph has joined #ffmpeg
fling has quit [Ping timeout: 240 seconds]
kron has quit [Ping timeout: 252 seconds]
Jhonny2x4 has quit [Read error: Connection reset by peer]
fling has joined #ffmpeg
qaph is now known as kron
user23 has quit [Remote host closed the connection]
minimal has quit [Quit: Leaving]
vincent has quit [Quit: cappuccigo]
vincent has joined #ffmpeg
fling has quit [Remote host closed the connection]
hussein1 has quit [Remote host closed the connection]
fling has joined #ffmpeg
hussein1 has joined #ffmpeg
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
emmanuelux has quit [Quit: au revoir]
lemourin has quit [Read error: Connection reset by peer]
fling has joined #ffmpeg
lemourin8 has joined #ffmpeg
lemourin8 is now known as lemourin
hightower3 has joined #ffmpeg
hightower2 has quit [Ping timeout: 240 seconds]
gvg has quit [Ping timeout: 256 seconds]
gvg_ has quit [Ping timeout: 260 seconds]
navi has quit [Quit: WeeChat 4.0.4]
lullerhaus has quit []
lullerhaus has joined #ffmpeg
Kei_N_ has quit [Ping timeout: 240 seconds]
\\Mr_C\\ has quit [Remote host closed the connection]
antto has quit [Remote host closed the connection]
antto has joined #ffmpeg
Keshl has quit [Ping timeout: 252 seconds]
Kei_N has joined #ffmpeg
gvg has joined #ffmpeg
gvg_ has joined #ffmpeg
vincejv has quit [Ping timeout: 245 seconds]
vincejv has joined #ffmpeg
fling has quit [Ping timeout: 240 seconds]
segfaultfizzbuzz has joined #ffmpeg
<segfaultfizzbuzz>
anyone familiar with ffmpeg, multichannel audio, and youtube?
<aaabbb>
somewhat, but it depends on your question
<segfaultfizzbuzz>
i have multichannel audio recordings (quad channel) from a significant musician who wants to upload their content to youtube
<segfaultfizzbuzz>
i am not finding great documentation unfortunately,... i think most of these files are some kind of four-channel wav file,...
<segfaultfizzbuzz>
what's the "right way" to do this? can i make spatial audio work with this as well so VR headsets/airpods pro/etc get a nice panning effect when the head rotates?
<aaabbb>
i don't know anything about vr on youtube, sorry. just stick around and someone else who knows will eventually be available
<segfaultfizzbuzz>
well can you lend some more general expertise? is there a good guide to ffmpeg + multichannelsomethingorother?
<Marth64>
there is a ton of info here, maybe worth it
<aaabbb>
if you have a 4 channel audio source, you can mux that into a video with 4 channels and upload that to youtube. i know what youtube's recommended setting are, at the very least
fling has joined #ffmpeg
FH_thecat has quit [Quit: Leaving]
Keshl has joined #ffmpeg
<segfaultfizzbuzz>
can you say what youtube's recommended settings are then for four channel?
<segfaultfizzbuzz>
what will happen with folks with spatial audio headsets/vr headsets?
ZedHedTed has quit [Remote host closed the connection]
<segfaultfizzbuzz>
what is a "good preferred" output format which supports 4-channel audio? (or should i find a way to convert to 5.1...?)
Marth64 has quit [Read error: Connection reset by peer]
lavaball has joined #ffmpeg
nigetilly has quit [Remote host closed the connection]
hjckr has quit [Ping timeout: 240 seconds]
030AABDL8 is now known as cc0
Jhonny2x4 has joined #ffmpeg
noonien85 has joined #ffmpeg
hjckr has joined #ffmpeg
vincejv_ has joined #ffmpeg
vincejv has quit [Ping timeout: 276 seconds]
ZedHedTed has joined #ffmpeg
jlc has joined #ffmpeg
Tinos has joined #ffmpeg
navi has joined #ffmpeg
vincejv_ has quit [Quit: Bye bye! Leaving for now...]
BetweenUs has quit [Quit: Leaving]
user23 has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
bitbinge has joined #ffmpeg
LionEagle_ has joined #ffmpeg
LionEagle has quit [Ping timeout: 256 seconds]
LionEagle_ has quit [Quit: Leaving]
Jhonny2x4 has quit [Read error: Connection reset by peer]
Tinos has quit [Quit: Client closed]
LionEagle has joined #ffmpeg
Dotz0cat has quit [Ping timeout: 276 seconds]
Dotz0cat has joined #ffmpeg
LionEagle has quit [Ping timeout: 256 seconds]
LionEagle has joined #ffmpeg
sixecho has joined #ffmpeg
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg
Hikaru has joined #ffmpeg
<Hikaru>
i am trying to do a lossless capture from a directshow device
lucasta has joined #ffmpeg
<Hikaru>
does -profile speed matter if -crf is 0?
<CounterPillow>
-crf 0 is not guaranteed lossless with all pixel formats iirc, you want -qp 0
<Hikaru>
thank you :)
<CounterPillow>
And the speed matters insofar as it determines the filesize
<CounterPillow>
slower speed -> smaller file
<CounterPillow>
Since you can freely reencode after the capture without generational loss in this case it's fine to use a fast encoding speed for lossless capture, the only limit is the space you have
<Hikaru>
thanks again, will do some testing
<CounterPillow>
Also if you're a numerics nerd you might find that there's technically still some loss recording an RGB framebuffer or whatever with libx264, as it'll convert it to YCbCr 4:4:4. There's libx264rgb which keeps it RGB but it's less efficient compression and speed wise afaiu
bitbinge has quit [Ping timeout: 240 seconds]
<Hikaru>
im just trying to get some before an after capture of a sega saturn before i recap it
<Hikaru>
to see if there is any picture improvment after the fact
navi has quit [Ping timeout: 256 seconds]
navi has joined #ffmpeg
Jhonny2x4 has joined #ffmpeg
minimal has joined #ffmpeg
bitbinge has joined #ffmpeg
lucasta has quit [Read error: Connection reset by peer]
stolen has joined #ffmpeg
<kepstin>
technically the speed preset does not _directly_ affect filesize; in some cases the same crf with a slower preset might give a larger file. What the slower presets do is improve the visual quality per bit, which allows you to make a smaller video that looks the same or a better quality video that's the same size.
Ogobaga has quit [Ping timeout: 245 seconds]
<CounterPillow>
kepstin: we're talking about lossless here, quality is a fixed variable.
<kepstin>
ah, yeah, that would be true for lossless :)
<kepstin>
note that "-crf 0" is only lossless in 8-bit mode, the recommended way to enable lossless in libx264 is to use "-qp 0"
<CounterPillow>
I've already said this
segfaultfizzbuzz has joined #ffmpeg
segfaultfizzbuzz has quit [Ping timeout: 240 seconds]
Hikaru has quit [Remote host closed the connection]
waleee has joined #ffmpeg
Kruppt has joined #ffmpeg
Marth64 has joined #ffmpeg
sixecho has quit []
Jhonny2x4 has quit [Read error: Connection reset by peer]
Jhonny2x4 has joined #ffmpeg
Ogobaga has joined #ffmpeg
<apteryx>
can I open /dev/vdeo0 with ffmpeg command line directly?
<apteryx>
/dev/video0
<Marth64>
Did you try v4l input format?
<CounterPillow>
ffmpeg's command line tool hardcodes trying v4l format on /dev/video paths, so yes you can open it directly.
<apteryx>
I'll compare my fresh 6.1.1 with an old 5.1.4 to see
<CounterPillow>
If it's not working for you then you should tell us what problem you're experiencing
<CounterPillow>
V4L devices are stateful, so unless you specify input format, framerate and video size, it will likely pick whatever it was set to last and may fail.
<apteryx>
seems mpv default to use the libaom decoder instead of dav1d, which is slower, according to this Guix ticket: https://issues.guix.gnu.org/39703
<CounterPillow>
Not relevant here, and not true
jagannatharjun has quit [Quit: Connection closed for inactivity]
billchenchina has joined #ffmpeg
LionEagle has quit [Read error: Connection reset by peer]
segfaultfizzbuzz has joined #ffmpeg
<apteryx>
even with --profile=fast, it's still much slower than ffplay
ivanich has joined #ffmpeg
<CounterPillow>
ffplay probably renders in software. mpv uses the GPU's full shading pipeline to render, which for very old/low-end hardware may be a problem. It also necessitates converting pixel formats to something the GPU rendering implementation supports, hence the yuyv422->yuv422p conversion inserted, which will again be slower.
<BtbN>
At least the pixel format conversion I'd expect ffplay to do as well
<BtbN>
And I think ffplay is also hardware accelerated these days?
bitbinge has quit [Remote host closed the connection]
<cristian_c>
the frame is shifted horizontally and vertically (it means it's not centered)
<cristian_c>
Marth64, CounterPillow, I don't know which option is needed to center the frame
<cristian_c>
I've tried to change all the parameter but result is even worse
<CounterPillow>
that sounds like a problem with your capture device/application
ZedHedTed has quit [Quit: leaving]
<cristian_c>
CounterPillow, i mean, when I caputre the stream without ffmpeg (not recording, and just only video) picture is centered
<cristian_c>
if I record video and audio through ffmpeg (getting avi as result), video is misaligned
<cristian_c>
*when I capture
<cristian_c>
only video caapture (not recording) uses mplayer in place of ffmpeg
bitbinge has joined #ffmpeg
<bitbinge>
I created a 10s video and want to compress it to 5MB. I do ffmpeg -y -i test.mkv -c:v libx264 -b:v 3992.812936714k -pass 1 -an -f mp4 /dev/null && \
<cristian_c>
Marth64, when i capture video (not audio and not recording), i use: sudo somagic-capture | mplayer -vf yadif,screenshot -demuxer rawvideo -rawvideo "pal:format=uyvy:fps=25" -aspect 4:3 -
<cristian_c>
I use uyvy in both cases but it doesn't affect alignment based on my experience with other pixel formats
jokoon has joined #ffmpeg
<Marth64>
Thanks cristian_c. Do you have like screenshot of (A) what you expect (B) what you are seeing
<cristian_c>
if I use a different (or no qscale) it seems just affecting pixel compression, not alignment
<jokoon>
does ffmpeg allows to make some frequency/FFT stuff/spectrogram things natively?
<bitbinge>
BtbN, I got muxing overhead: 0.085380%, I guess it's the codec then since the file is larger by a lot more than 1%.
<cristian_c>
maybe, more than that
<apteryx>
is there a point to pass build flags such as: --arch=x86_64, or would that be correctly inferred anyway?
<jokoon>
I want to generate the frequency distribution to research some visualisation project
<cristian_c>
Ive made screenshot badly, but at least it shows misalignment clearly
rvalue has quit [Ping timeout: 245 seconds]
<cristian_c>
every time I record, horizontal and vertical shifts seem rather random
<Marth64>
cristian_c: I wonder if this is is a issue or bug having to do with capturing raw realtime and also doing filtering, compression, etc. I highly doubt it but I have experience this before, where trying to all of this during capture at same time, weird random issues happen
<Marth64>
It's possible this is just strange behaviour since you are doing both raw capture and at same time filter/compress
<cristian_c>
it's something which has to do with frame position
<Marth64>
What happpen if you remove yadif
<bitbinge>
Yes, it's 0.08%. once the job finishes I get frame= 301 fps= 14 q=-1.0 Lsize= 5211kB time=00:00:09.91 bitrate=4305.7kbits/s dup=3 drop=0 speed=0.476x
<bitbinge>
video:5206kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.085380%
kus has quit [Read error: Connection reset by peer]
<Marth64>
U can ignore the "/usr/bin". I have a few different ffmpegs on my machine
ZedHedTed has joined #ffmpeg
waleee has quit [Ping timeout: 245 seconds]
<Marth64>
my point in suggesting it is, it might be easier on your old analog material to do the capture only one time and then convert/process from there, if you have enough disk space
<Marth64>
and store in lossless format like ffv1/flac for the intermediate
SakuraChan has joined #ffmpeg
<furq>
probably better to use x264 lossless there
Sakura`Kinomoto has quit [Ping timeout: 245 seconds]
<Marth64>
furq: just curious why. closed captions?
<Marth64>
ffv1 level 3 supports interlaced ok
<furq>
much lower bitrate
<Marth64>
ah. inter frame coding
<Marth64>
nice
<furq>
ffv1 has poor nle support anyway which is the only reason to use an inter-only codec
<furq>
other than archival which it doesn't sound like you're doing
<furq>
intra-only i mean
<cristian_c>
Marth64, I removed yadif completely and nothing changes about misalignment
<Marth64>
i am doing archival (personally) so ok with the wasted space. but yes for general workflow where it's just a intermediate, thats a better plan
<Marth64>
cristian_c: Okay. Can you study your command closely and try to isolate exactly what causes the issue and what doesn't?
<cristian_c>
furq, I hope that if I change just one of the two buffer commands, at the end video and audio still remain synchronize
ajshell1 has joined #ffmpeg
<cristian_c>
*synced
<cristian_c>
furq, if default is 1 it just means size unit is MB
<Marth64>
cristian_c: This is probably not an option for you but just suggesting it. There's a lot of capture cards, that only work good in Windows. Do you have the easy opportunity to try your workflow in Windows, then you do not have to do the buffer/pipe hacks? ffmpeg support DirectShow device on Windows which is why I'm asking
<Marth64>
Then your whole command is straight shot capture with ffmpeg (if your card has Windows dshow drivers)
waleee has quit [Ping timeout: 260 seconds]
<Marth64>
I completely understand if the answer is no :D
<cristian_c>
Marth64, ok, I get your point. In this case, I know windows doesn't work (or it's broken) about this device
<Marth64>
Ahhhh. Sorry to hear, haha
<Marth64>
your stuck with this then
<cristian_c>
furq, Marth64, the hack i'm using with this script to get a avi video is running cat .video_buffer in another terminal tab after running the script
<cristian_c>
the script is stuck until I run cat .video_buffer in another tab. Then, I get this request by ffmpeg: File 'video.avi' already exists. Overwrite? [y/N] y
<cristian_c>
at that point, i can press ctrl+c in the tab where cat is running and press in the primary tab (where ffmpeg runs) and ffmpeg starts to record
<cristian_c>
if I don't use cat hack, ffmpeg is stuck and doesn't ask for request File 'video.avi' already exists. Overwrite? [y/N] y
<cristian_c>
Marth64, furq , if I try to change buffer size with -m 20, I get immediately File 'video.avi' already exists. Overwrite? [y/N] y
<cristian_c>
and cat doesn't print anything, if I press y, ffmpeg returns errors
<cristian_c>
so I think bash doesn't detect -m properly
<cristian_c>
(maybe there is a bash syntax issue, I've to figure out bash syntax to fix that)
segfaultfizzbuzz has quit [Ping timeout: 240 seconds]
segfaultfizzbuzz has joined #ffmpeg
waleee has joined #ffmpeg
jokoon has quit [Quit: Leaving]
eldowan has joined #ffmpeg
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg
LionEagle has quit [Quit: Leaving]
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg
LionEagle has joined #ffmpeg
<tm512>
dunno if this is the best place to ask but I'm kinda curious if it's possible to transcode something like MP3 to MP3 without generation loss, like take a 320kbit file and transcode it to 192kbit file, having the latter be essentially the same as if you went directly from lossless to 192kbit
<kepstin>
not possible in general. a codec needs to be designed specifically to support that sort of thing.
<kepstin>
(and it usually comes at the expense of compression efficiency)
<tm512>
I understand that it couldn't be generic (where the original lossy gets decoded and then reencoded), and that the transcoder would have to have specific knowledge of the codec
<tm512>
I was thinking it'd be in the realm of possibility that a program could like, further quantize the frequency coefficients of a lossy file and get better results than a naive transcode
<kepstin>
well, it's all dependent on the decisions made in the original encode; it's possible that you'd get better quality at a lower bitrate if different decisions had been made and different data thrown out.
<kepstin>
ogg vorbis actually did support this theoretically - https://en.wikipedia.org/wiki/Bitrate_peeling - but nobody ever actually developed an encoder that could make appropriate files.
<kepstin>
and there's a few "lossy core" lossless codecs where they do a lossy encode and then save the differences between the lossy encode and the original audio alongside; wavpack can do that and i think DTS-HD master audio works similarly?
<Marth64>
DTS-HD MA does
<Marth64>
I don't know the science behind it but they do
ivanich has quit [Remote host closed the connection]
<tm512>
I also know MPEG-4 SLS does this with an AAC lossy core and a correction file
sm1999 has quit [Quit: WeeChat 4.2.0-dev]
<tm512>
kinda unfortunate that MP3 doesn't seem to have any kind of "bitrate peeling" capabilities (or nobody has tried to build a transcoder that brute-forces it). I've got quite a few 320kbit MP3s in my collection, would be nice to be able to get those to a lower bitrate for portable use without incurring generation loss
<tm512>
though maybe it's not worth fretting over
<kepstin>
but yeah, i'm pretty sure that there haven't ever been any actual implementations for doing bitrate peeling on a lossy audio file - and even if you do it, it's very difficult (possibly impossible) to achieve the same quality as encoding directly from the source would have managed
<kepstin>
because you can only throw out more data, you can't throw out different data
<tm512>
I need to get something to ABX set up, see if I can even hear the difference between a lossless original and a lossy copy that's been through 320kbit MP3 and then to, say, ~192kbit AAC
<tm512>
or if opus is on the table, maybe like 160kbit opus
<kepstin>
i solve this issue by having a nas with big hard drives and keeping a flac copy of all my music handy ;)
<tm512>
wouldn't be able to get the bitrate as low as if I were making the final lossy encode directly from lossless
HarshK23 has quit [Quit: Connection closed for inactivity]
<tm512>
kepstin: yeah, that's ideal, though a lot of my music collection is from before I could just collect flac without thinking about how much space it's "wasting"
<kepstin>
heh. yeah, fortunately that part of my music collection is small enough that I just leave it in whatever format it's in, and don't care.
lavaball has quit [Remote host closed the connection]
ivanich has joined #ffmpeg
<kepstin>
(quite handy how microsd cards have gotten very high capacity, no issue keeping all my music on my phone even with some files using wastefully high bitrate on old lossy codecs)
bitbinge has quit [Read error: Connection reset by peer]
bitbinge has joined #ffmpeg
segfaultfizzbuzz has quit [Ping timeout: 260 seconds]
<tm512>
my current porable listening setup is a 4GB iPod mini where 320kbit is arguable too wasteful, though I've got a 64GB CF card here that I'm going to install. still would rather encode albums at a much lower bitrate than 320kbit
user23 has quit [Remote host closed the connection]
sm1999 has joined #ffmpeg
Jhonny2x4 has joined #ffmpeg
<tm512>
320kbit is like this awkward middle-ground that fails to be a perfect copy of the original and also fails to save as much space as possible while maintaining transparency. for MP3, LAME V0 or V1 seems to be way better at the latter
AbleBacon has quit [Ping timeout: 264 seconds]
RetroPunk has quit [Remote host closed the connection]
MootPoot has quit [Quit: Connection closed for inactivity]
RetroPunk has joined #ffmpeg
emmanuelux has joined #ffmpeg
Traneptora has quit [Quit: Quit]
segfaultfizzbuzz has joined #ffmpeg
segfaultfizzbuzz has quit [Ping timeout: 260 seconds]
LionEagle has quit [Read error: Connection reset by peer]
ivanich has quit [Remote host closed the connection]