Suchiman has quit [Quit: Connection closed for inactivity]
<le_patenteux>
Now... I know that for the alpha channel to be included, my best bet is VP9, but I have no idea what is the right commands to make the background transparent
<le_patenteux>
I googled this for several hours before someone points it out
<dv_>
so, in h.264, on-the-fly manual CBR bitrate changes may not work, because a change in bitrate may cause the current h.264 level to no longer apply?
<dv_>
do I see that correctly?
<dv_>
same with on-the-fly framerate changes
iive has quit [Quit: They came for me...]
<furq>
le_patenteux: if you want to replace the background with transparency then chromakey=0x00000000
<furq>
dv_: framerate has nothing to do with the level
<furq>
bitrate changes might screw up the decoder
five618480 has quit [Remote host closed the connection]
five618480 has joined #ffmpeg
<le_patenteux>
furq : thank you... DO I need to specify a color space?
<furq>
chromakey will do that for you
<furq>
but if you want the background to be transparent then color=0x00000000,format=yuva420p
<le_patenteux>
Not sure where the 0x00000000 value goes though? Your explanation puts it after chromakey= , but that is the color of my green screen
<furq>
or rgba if you want rgb
<furq>
yeah i meant color= not chromakey=
<le_patenteux>
My source is HEVC, can you correct my command to make the background transparent instead of the pre-defined color I chose?
<le_patenteux>
I think my source is 422 though, does it make it more computationnaly intensive if I go down to 420 or makes no difference?
<furq>
you can use yuva422p if you want
<le_patenteux>
i makes it harder down the line form me to keep it 422... but I was wondering, given that I will process the chroma, does pulling it down to 420 make a huge difference on processing?
<le_patenteux>
aka: does reducing the chroma subsampling take a lot of processing?
<le_patenteux>
Oh... nevermind, I made a mistake... it is 420, it is the 10 bits that causes me some issues...
<le_patenteux>
I will try your suggestion and report in a bit... I need to put the kids to bed!
<furq>
there's yuva420p10le as well
<furq>
and converting it takes vastly less time than encoding video
<furq>
but if you want to keep it 10-bit you probably want -c:v libx265
<furq>
it'll default to x264 otherwise and 10-bit h264 decoder support sucks
<le_patenteux>
where does the -c:v libx265 go in the line?
<le_patenteux>
just before the output?
<furq>
syre
<furq>
sure
<le_patenteux>
alright... I am running it at the moment...
<le_patenteux>
wow it is slow! I will need hardware encoding to make that useable after this first try! :D
lexano has quit [Ping timeout: 252 seconds]
<le_patenteux>
ok, here is what I tried, but it made the background black, not transparent
<FlorianBad>
What would be the highest quality sharpening filter if I want to apply some subtle sharpening after resizing to let's say 25% resolution? (just enough to compensate for having lost a bit a detail due to the downscaling)
hussein1 has quit [Remote host closed the connection]
hussein1 has joined #ffmpeg
georgereynolds8 has quit [Ping timeout: 260 seconds]
<aaabbb>
FlorianBad: if you want to compensate from loss of detail from downscaling, you'll want to use a downscaling algorithm that naturally has sharpening properties
<aaabbb>
you don't want to use a downscaler that makes things smooth and then sharpen
<FlorianBad>
aaabbb, well, I found spline wonderful, I just want to keep that and add a little 10% of something
<FlorianBad>
(for low res versions only)
<FlorianBad>
Also, I need that configurable because my program will make these decisions based on the type of content
<aaabbb>
i think you can use different version of spline with zscale, some have more sharpening
navi has quit [Quit: WeeChat 4.1.2]
fossdd has quit [Ping timeout: 260 seconds]
irrgit has quit [Read error: Connection reset by peer]
le_patenteux has quit [Quit: Konversation terminated!]
fossdd has joined #ffmpeg
troyt has quit [Quit: AAAGH! IT BURNS!]
MrZeus has quit [Ping timeout: 252 seconds]
<FlorianBad>
aaabbb, I don't see any equivalent of accurate_rnd+full_chroma_int+full_chroma_inp for zscale
<aaabbb>
FlorianBad: i believe zscale already does accurate rounding and the computations use the full chroma
<FlorianBad>
ah, ok thanks
<aaabbb>
out of curiosity what ipratio did you end up using
<aaabbb>
i'm curious to know if calculating the ssim of every frame and then adjusting ipratio until the i frames are similar to non i frames has any downsides
fossdd has quit [Ping timeout: 256 seconds]
fossdd has joined #ffmpeg
minimal has quit [Quit: Leaving]
<FlorianBad>
aaabbb, I ended up making it depend on a "detail" parameter that I will provide to my program (which defaults to 5). And the detail is converted to ipratio using this: https://www.desmos.com/calculator/peeoc8nqro
<FlorianBad>
so 5 (default) becomes 1.3
<FlorianBad>
That way when I encode videos I'll just provide 2 parameters that describe what I'm encoding action, and detail
<aaabbb>
you seem to be doing a lot of micro optimizations
<FlorianBad>
action will influence keyint and a few other things, and detail will influence ipratio and sharpness at low resolution, and maybe a few other things
<aaabbb>
in that case it would be better to spend time perfecting the aq-mode and aq-strength and psy
<FlorianBad>
took me 10 minutes lol, I'm use to doing that all the time with all my programs, building math functions that do things like that
lucasta has quit [Quit: Leaving]
<aaabbb>
you'll get better returns by tuning aq, aq-mode, and psy-rd
<aaabbb>
eg aq-mode=3 is a good default for high bitrate 8bit or low bitrate 10bit, especially if there are lots of dark gradients
<aaabbb>
it helps reduce banding by lowering the qp on dark macroblocks
lemourin has quit [Read error: Connection reset by peer]
waleee has quit [Ping timeout: 259 seconds]
<FlorianBad>
hmm, looking into this
fossdd has quit [Ping timeout: 256 seconds]
<aaabbb>
it's one of the most important things to tweak if you'll be tweaking things in general
lemourin3 has joined #ffmpeg
lemourin3 is now known as lemourin
<FlorianBad>
by "aq" you mean "aq-strength" ?
<aaabbb>
right
<FlorianBad>
ok
<aaabbb>
and aq-mode describes the aq technique, aq-strength describes how aggressive it will be
<aaabbb>
FlorianBad: if you don't know what those do, aq is adaptive quantization and changes the qp of macroblocks based on factors, such as amount of motion (high motion scenes can use higher qp because humans are not good at noticing bad quality when it's fast moving, so it saves bits for stationary high detail macroblocks that a human will notice)
fossdd has joined #ffmpeg
<FlorianBad>
so these are not in -x264-params but as single options (-aq-mode -aq-strength -psy-rd) ?
<aaabbb>
and psy-rd is a psychovisual optimization because humans subjectively prefer incorrect motion rather than blurring so it takes bits from accurate motion vectors and moves those bits to improve spatial quality
<aaabbb>
they are also in -x264-params
<FlorianBad>
ok so "scenecut=0:keyint=123:ipratio=1.4;aq-mode=1:aq-strength=123:psy-rd=123" ?
<aaabbb>
yeah that would be the equivalent of "-x264-params scenecut=0:ipratio=1.4 -aq-mode 1 -aq-strength 123 -psy-rd 123 -g 123"
<aaabbb>
you generally don't want aq-mode=1, usually you want default (2) or with bias to dark areas (3)
<FlorianBad>
ok I see, will just put them in the params
<FlorianBad>
yeah I haven't looked into it yet, it was just for hte format
<aaabbb>
when you tune it, the higher the aq-strength the more aggressive the aq will be. the higher the psy-rd, the more the encoder will prefer accurate shape over accurate motion (too little and you aren't fully exploiting the human visual system's quirks, too much and you start to get artifacts caused by wildly inaccurate motion estimation)
<aaabbb>
btw because psy is less "technically accurate" to the source, you should turn it off when doing ssim or psnr calculations (use -tune ssim or -tune psnr to do that), but even tho it's less technically accurate to the source, it's better for human vision which is why psy is on by default
<FlorianBad>
ok, these will go very well with my {action} and {detail} options!
fossdd has quit [Ping timeout: 255 seconds]
<aaabbb>
FlorianBad: possibly but you'll need to do lots of testing. if it was as simple as an action and detail variable, then it would have been built into x264 already
<aaabbb>
and what counts as action or detail to a human brain might not be what counts as action or detail to x264
<aaabbb>
such as gentle slowfall is low action to us, but ultra high action for x264, and tom cruise in a car chase is high action to us, but very low action to x264
fossdd has joined #ffmpeg
<aaabbb>
a beautiful backdrop is high detail to us, but medium detail to x264. gentle rain is low detail to us, but ultra high detail to x264
<FlorianBad>
aaabbb, that's exactly why I have 2 different settings, action and detail, snow/confetti are what I call detail, and action is the big movements
<FlorianBad>
(I originally called the "detail" option "confetti" but I realized I'm going to misspell it often :) )
<aaabbb>
big movements of the whole camera or of portions?
<aaabbb>
oh so detail and action are both about motion for you, you don't mean detail for still
<aaabbb>
maybe better terms would be something where action = all macroblocks with similar motion vectors, detail = each macroblock will have lots of random motion vectors
<aaabbb>
x265 has a feature that automatically adjusts for that called aq-motion, x264 has no equivalent
<FlorianBad>
well, yes and no because I do consider the woman's hair from that ARRI footage to be a little higher than normal detail, simply because they move a bit, so it's like 10% on its way to a full confetti scenario :)
<aaabbb>
but it's all moving in mostly the same direction so that's pretty low detail
<FlorianBad>
so if there's woman hair ion close up like that I'll put detail=6 instead 5 default
<aaabbb>
i just don't think those variables are useful models of what matters to x264
<FlorianBad>
well, I tried various ipratio and that kind of area of fine hair definitely needs a below 1.4 ratio
<aaabbb>
you might be able to do a script that automatically adjusts ipratio based on ssim of each frame
<aaabbb>
idk if that would have any real downsides
<FlorianBad>
it brings it down to 1 in this case I think, which is subtle but noticeable
<FlorianBad>
well... I also have to know when to stop and move on to the next thing ;) So I think I will stop just after these aq and psy things you mentioned, and that will be good enough. That with all the rest I'm going to do with the custom server/client will already make the quality of my videos 3x better than most platforms
<aaabbb>
it's not great for compatibility, but if you do yuv420p10le encodes, you massively reduce banding even without aq-mode=3
<aaabbb>
especially when downscaling
<FlorianBad>
aaabbb, I just tested spline vs spline16 vs spline36 and cannot see the slighest difference. My bet is that it only makes a difference when UPscaling. So I'm going to need to sharpness parameters
<aaabbb>
i believe lanczos has sharpness parameters in swscale
<FlorianBad>
Is unsharp the true/best way to sharpen? Just the name sounds like it's a blur that was adapted to also sharpen as a side-effect...
<FlorianBad>
ah, yes, plus I noticed that lanczos was already sharpen in general
<aaabbb>
FlorianBad: i wouldn't sharpen after downscaling, just play with other scaling algorithms and their parameters until you get something that works well for you
<FlorianBad>
ok, and since spline has no parameters (apparently) then lanczos?
<aaabbb>
no parameters in swscale at least, and sure
<aaabbb>
lanczos is usually the gold standard downscaler if you want it to be sharp instead of smooth
fossdd has quit [Ping timeout: 256 seconds]
<FlorianBad>
ok, I found spline beautiful, but yeah, at low resolutions it lacks a bit of sharpness
fossdd has joined #ffmpeg
<FlorianBad>
ok so after testing some downscaling of the woman footage (3840x2160 to 768x432) in all 3 spline and lanczos from scale and zscale I cannot see any difference at all. So I'm definitely going to need some sharpening options
<FlorianBad>
when downscaling a lot the difference between algorithms probably too subtle to notice
Vonter has quit [Ping timeout: 264 seconds]
Vonter has joined #ffmpeg
<FlorianBad>
aaabbb, something like this seems to be just as subtle as I need for downscaling to very small res: -vf "scale=768:432:flags=lanczos,unsharp=9:9:0.2:9:9:0.2"
<FlorianBad>
Then I can just adjust the 0.2 based on my {detail} variable and the resolution. The higher the {detail} and the lower the resolution, the higher that 0.2
emmanuelux has quit [Read error: Connection reset by peer]
emmanuelux_ has joined #ffmpeg
fling has quit [Ping timeout: 255 seconds]
YuGiOhJCJ has joined #ffmpeg
fling has joined #ffmpeg
Tano has joined #ffmpeg
foul_owl has quit [Ping timeout: 276 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
HarshK23 has joined #ffmpeg
foul_owl has joined #ffmpeg
FH_thecat has quit [Quit: Leaving]
rpthms has quit [Remote host closed the connection]
rpthms has joined #ffmpeg
YuGiOhJCJ has quit [Ping timeout: 255 seconds]
YuGiOhJCJ has joined #ffmpeg
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #ffmpeg
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #ffmpeg
AntimaD has joined #ffmpeg
AntimaD has quit [Quit: Client closed]
FH_thecat has joined #ffmpeg
AntimaD has joined #ffmpeg
mrelcee has quit [Quit: I want Waffles!]
mrelcee has joined #ffmpeg
Hackerpcs has quit [Quit: Hackerpcs]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
Hackerpcs has joined #ffmpeg
cosimone has joined #ffmpeg
rv1sr has joined #ffmpeg
rv1sr has quit [Client Quit]
rv1sr has joined #ffmpeg
jarthur has quit [Quit: jarthur]
intrac has quit [Ping timeout: 264 seconds]
AntimaD has quit [Quit: Client closed]
Suchiman has joined #ffmpeg
<dv_>
<furq> dv_: framerate has nothing to do with the level
<dv_>
but, it influences how the max possible leve is estimated
<dv_>
because the max possible h264 level depends on the bitrate, the profile, and the number of macroblocks per second
<dv_>
and the number of macroblocks per second depends on the framerate
<dv_>
so if during the encoding, I suddenly increase the framerate, I might end up having more macroblocks per second than the level allows for
cosimone has quit [Remote host closed the connection]
cosimone has joined #ffmpeg
foul_owl has quit [Ping timeout: 256 seconds]
Some_Person has quit [Ping timeout: 268 seconds]
cosimone has quit [Remote host closed the connection]
zsoltiv_ has quit [Ping timeout: 246 seconds]
foul_owl has joined #ffmpeg
cosimone has joined #ffmpeg
ivanich has joined #ffmpeg
<aaabbb>
how do i prepend a single i frame to a video, and change the pts of the next frame (which ofc will also be an iframe) so that it is 5 seconds later?
<aaabbb>
i want to be able to prepend one frame that lasts 5 seconds without reencoding (i am the one encoding the video so i have full control over the encoder parameters)
Some_Person has joined #ffmpeg
<aaabbb>
i'm wondering if there's a way to do it in one command instead of having to create two ts files and then use the concat muxer
ivanich has quit [Remote host closed the connection]
lusciouslover has quit [Read error: Connection reset by peer]
lusciouslover has joined #ffmpeg
s55 has quit [Ping timeout: 255 seconds]
<aaabbb>
right now what i'm doing is encoding the first ts and using muxdelay, then generating a ts with a single frame, then concatenating them, but i'd like to do that at once if possible
intrac has joined #ffmpeg
ivanich has joined #ffmpeg
lavaball has joined #ffmpeg
cosimone has quit [Remote host closed the connection]
<alydev>
hi o/ i was looking for possible ways to record EGLFS video from my pi 4's video driver, a search turned up this log from last month https://libera.irclog.whitequark.org/ffmpeg/2024-01-03, i don't want to start pinging names after having just joined but i wanted to see if the people involved were still here and if there was perhaps a working script they figured out
<alydev>
i've got the same Invalid output format bgr0 for hwframe download. and i'm trying to grok the conversation but i'm not pulling anything meaningful from it
<alydev>
it seems Bombo isn't here at least, last they spoke was the 6th, they got something captured but it's just vertical lines, which is what i was afraid of
<alydev>
decoding the output is a sticking point even if you can get something captured from the broadcom chip
navi has joined #ffmpeg
waleee has joined #ffmpeg
Exa has quit [Quit: see ya!]
Exa has joined #ffmpeg
<alydev>
alrighty so i ran the script Bombo came up with for testing each pixfmt in turn, the only one that produced output was nv12, https://cdn.aly.pet/nv12.mp4 not super helpful but maybe it's something
<alydev>
i wanted to share the log, i forgot to pipe output to tee, running it again
<alydev>
it's different to what they got with their pi 3, for them bgr0 was the one that returned the garbled result, for me it's nv12
<CounterPillow>
that looks like some tiled format that is incorrectly interpreted
<CounterPillow>
which makes me think either kmsgrab has no concept of DRM modifiers or Berrycum's shit downstream vendor kernel doesn't set them or specifies vendor specific ones that they never upstreamed to anything
<alydev>
https://sprunge.us/UL8Xfb that log for reference, third time's the charm, forgot tee and then didn't redirect stderr
<alydev>
i found it interesting that it alternated between a couple different error messages, idk if it's meaningful at all in figuring this out
<alydev>
for getting it to work i'm inclined to run moonlight through X11, at least i know i can capture frames from that, but def would be helpful for the next person to find this log on google in a month trying to solve the same problem again. tl;dr no clue how to parse the data, nv12 seems to at least produce *something* on the pi 4, good luck
<alydev>
pi 400* afaik it's a minor revision in the chipset, hopefully it doesn't affect it
emmanuelux_ has quit [Read error: Connection reset by peer]
waleee has quit [Ping timeout: 256 seconds]
emmanuelux_ has joined #ffmpeg
<CounterPillow>
My guess is that you'll need to teach FFmpeg about broadcom pixel formats
<alydev>
joy
<alydev>
i definitely don't have the requisite knowledge to accomplish this
<CounterPillow>
Looks like the only reason why they even need this modifier in the first place is to hack around their memory controller's poor performance, which makes this a certified Broadcom moment
lavaball has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
epony has quit [Remote host closed the connection]
junaid_ has joined #ffmpeg
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #ffmpeg
<CounterPillow>
Comparing this to a different vendor, the other embedded vendor's solution to efficient data transfer from decoder to whatever else was apparently to 1. allow untiled formats to be output and just eat the memory bandwidth, 2. allow a tiled semi-planar format which is simple 16x16 row-major or 8x8 row-major, 3. also allow for AFBC
lemourin has quit [Read error: Connection reset by peer]
lemourin4 has joined #ffmpeg
lemourin4 is now known as lemourin
lemourin has quit [Ping timeout: 255 seconds]
junaid_ has quit [Quit: Lost terminal]
Scorpi has left #ffmpeg [#ffmpeg]
Scorpi has joined #ffmpeg
Scorpi has left #ffmpeg [#ffmpeg]
lexano has joined #ffmpeg
hussein1_ has joined #ffmpeg
hussein1 has quit [Ping timeout: 255 seconds]
LuKaRo has quit [Ping timeout: 260 seconds]
beastd has joined #ffmpeg
lavaball has joined #ffmpeg
lemourin has joined #ffmpeg
LuKaRo has joined #ffmpeg
epony has joined #ffmpeg
alydev has quit [Ping timeout: 260 seconds]
alydev has joined #ffmpeg
epony has quit [Remote host closed the connection]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg
holgersson has quit [Quit: “Format C:........[Done]“]
holgersson has joined #ffmpeg
alydev has quit [Quit: WeeChat 4.2.1]
lemourin6 has joined #ffmpeg
lemourin has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
lemourin6 is now known as lemourin
minimal has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
lemourin8 has joined #ffmpeg
lemourin8 is now known as lemourin
lemourin has quit [Killed (mercury.libera.chat (Nickname regained by services))]
cosimone has joined #ffmpeg
JanC_ has joined #ffmpeg
epony has joined #ffmpeg
JanC has quit [Killed (zinc.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
FlorianBad has joined #ffmpeg
<FlorianBad>
Any reason why ffmpeg would stop encoding after 28 bytes of output in each file and an exit code of 9, but no warning and no error?
<FlorianBad>
Ah... oom killed
<FlorianBad>
probably due to -thread_queue_size 8192 being too high? (for 64GB of ram)
AntimaD has joined #ffmpeg
cosimone has quit [Remote host closed the connection]
<FlorianBad>
Can I count on it to be 9 every time so my script can retry with lower thread_queue_size values?
<BtbN>
the amount of threads used will depend on your CPU and system config
<BtbN>
if you don't specify it manually
hightower2 has quit [Ping timeout: 276 seconds]
hussein1_ has quit [Remote host closed the connection]
lusciouslover has quit [Read error: Connection reset by peer]
hussein1_ has joined #ffmpeg
AntimaD has quit [Ping timeout: 250 seconds]
lusciouslover has joined #ffmpeg
<FlorianBad>
BtbN, yeah but I often had warnings when I didn't put that option
<FlorianBad>
because it was too low
<BtbN>
given it's in packets, and not bytes, 8192 seems insanely excessive
AntimaD has joined #ffmpeg
<BtbN>
But I'm still confused what you're actually asking.
<FlorianBad>
I'm asking if I can count on the exit code of 9 when this happens, so my script can lower that queue_size and try again
<BtbN>
Isn't 9 just SIGKILL?
<BtbN>
i.e. the kernel is just telling you the process got killed, somehow.
<BtbN>
Incorporating reliance on the OOM killer into your workflow sounds absolutely ridiculous to me
<FlorianBad>
ok, then how would you make the difference between an error from ffmpeg and an OOM ?
<FlorianBad>
(in a script)
<BtbN>
I have serious trouble believing you run out of RAM from that on a system with 64G, unless it's already under memory pressure
<FlorianBad>
Well I always use around 20GB so it might have only had 48 or something, and the videos are 4K in amazing quality from PNG sources
<FlorianBad>
and I encode into MANY outputs at once (like 6 ofo them)
<BtbN>
yeah, queueing 8000+ frames in 4K, even compressed... probably too much
LionEagle has quit [Ping timeout: 256 seconds]
<BtbN>
Just don't specify such a huge queue for your video?
<FlorianBad>
ok, what happens exactly when I get that warning because it's too low? (forgot the exact warning but you know what I'm refering to?)
LionEagle has joined #ffmpeg
lemourin3 has joined #ffmpeg
lemourin3 is now known as lemourin
Muimi has joined #ffmpeg
hightower2 has joined #ffmpeg
vincejv has quit [Quit: Bye bye! Leaving for now...]
AntimaD has quit [Quit: Client closed]
AntimaD has joined #ffmpeg
ivanich has quit [Ping timeout: 255 seconds]
rvalue has quit [Ping timeout: 264 seconds]
holgersson has quit [Quit: “Format C:........[Done]“]
<furq>
usually the thread message queue blocking warning means nothing at all
<furq>
but when it does mean something it just means things will run slower
<FlorianBad>
furq, ok so it's not going to produce any difference in output? (at least when not streaming live)
<furq>
right
<furq>
with live inputs it means input packets might be dropped
<furq>
but you don't have live inputs
<FlorianBad>
So if that buffer is too low it might just be sub-optimized then, that's it?
<furq>
something like that
<FlorianBad>
ok thanks
rvalue has joined #ffmpeg
LionEagle has quit [Ping timeout: 264 seconds]
holgersson has joined #ffmpeg
<FlorianBad>
ok so now I'm going to get into aq-mode, aq-strength, and psy-rd that aaabbb mentioned yesterday, and then I'll stop with the micro-optimizations ;) and move on to the next step, which will be to turn all that into dash
LionEagle has joined #ffmpeg
lemourin has quit [Ping timeout: 260 seconds]
tomaw has quit [Remote host closed the connection]
tomaw- has joined #ffmpeg
<FlorianBad>
BTW if anyone is interested in that beautiful (but quite still) test footage of the woman's hair I just put it here: https://florian.club/pub/video-test-footage/ I found it excellent for testing sharpness and rescale, and also ipratio where the hair is dark and moves just slightly
Vonter has quit [Ping timeout: 264 seconds]
tomaw- is now known as tomaw
Vonter has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
<FlorianBad>
When I use -f adts output.aac to encode the audio separately, and then use that back as input -i file.aac with -c copy I get this error: Malformed AAC bitstream detected: use the audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg)
<FlorianBad>
so of course I could use that option suggested, but then, could I just use another container than adts in the first place?
<FlorianBad>
(actually I wasn't using -c copy but -c:a copy of course since there's video with it, and -f mp4)
lemourin has joined #ffmpeg
<FlorianBad>
I was trying -f m4a but it seems it's not a container
<FlorianBad>
Is an .m4a file just some AAC in -f mp4 ?
<FlorianBad>
Also, another question ;) Is there a way to limit duration to that of a specific input without having to analyze it and then call -t ? So if I have 2 inputs of 10s and 15s respectively, I can output only the first 10s by indicating that I want the duration from input 0
hussein1_ has quit [Remote host closed the connection]
hussein1_ has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
hussein1_ has quit [Ping timeout: 255 seconds]
<furq>
-shortest
<furq>
and the m4a muxer is -f ipod
<furq>
but m4a, m4v, mp4 etc are all the same thing
hussein1_ has joined #ffmpeg
<FlorianBad>
Oh! -shortest, wonderful! :)
<FlorianBad>
hmm "ipod" does not sound good lol
<FlorianBad>
so basically -c:a libfdk_aac -f mp4 output.m4a is fine too?
<FlorianBad>
furq, actually -shortest is not what I'm looking for, because the reason I need something like that is to prevent the audio from extending the video, but with -shortest it would shorten the video to the audio if it ends a bit before
<FlorianBad>
I guess what I'm looking for is just a way for video to determine duration regardless of audio, which is why I wanted to refer to an input number (0 in my case, since audio is input 1)
<furq>
you could append silence to the audio and then use -shortest
<FlorianBad>
Well, I do know the number of frames though, so can -t be a number of frames instead of time? (or equivalent option)
<FlorianBad>
hmm
AntimaD has quit [Ping timeout: 250 seconds]
rsx has joined #ffmpeg
<FlorianBad>
Can't append silent with -c:a copy though
<furq>
you can but not all in one command
<FlorianBad>
And there's no equivalent of -f that would be in frames instead of time?
<FlorianBad>
sorry, -t
<furq>
no but you can calculate the time from the frame count and rate
<FlorianBad>
So I have a suggestion then: a -shortest-video option which acts just like -shortest but only considers the video inputs, that would be VERY useful
<FlorianBad>
yeah but I'm a bit worried about rounding things differently from what ffmpeg will do
<FlorianBad>
it's doable but just not the cleanest approach
<FlorianBad>
where do I submit that kind of suggestion? :)
rsx has quit [Quit: rsx]
<FlorianBad>
oh that would be an "enhancement" ticket?