get fps, dimensions etc. for vidfile from ffprobe

[mdedwards]

No description provided.

[mdedwards]

I'm happy to leave these for now as we don't need them but if you feel like doing your ffprobe magic @Leon-Focker then go ahead.

[Leon-Focker]

Sure, but in what way? We would probably want to avoid a second ffprobe call after get-sound-info... Should get-sound-info also spit out video info (i.e. make it all one function) or should we do a get-video-info function? In case of the latter we might want another update-:around method, right?

[Leon-Focker]

PS: before I get to the ffprobe scripts... what else do you want to know, except fps and dimensions?

[mdedwards]

PS: before I get to the ffprobe scripts... what else do you want to know, except fps and dimensions?

See the vidfile slots + anything else you can extract that's relevant

[mdedwards]

Sure, but in what way? We would probably want to avoid a second ffprobe call after get-sound-info...

Definitely. Can you get it all in one call? I did a lot of work to avoid unnecessary calls to get-sound-info over the weekend and saw a massive increase in computation speed---don't want to ruin that.

BTW are you happy with the in that fun with referring to fixed positions? What if the output changes? Wouldn't assoc be better, if you're going to avoid reg-exps (which will probably be robuster and enable fault detection)

Should get-sound-info also spit out video info (i.e. make it all one function)

That would be the best approach I think. If it's not a vid file then fps etc. will simply be missing from the ffprobe results

In case of the latter we might want another update-:around method, right?

Not sure that's necessary yet

[Leon-Focker]

Can you get it all in one call?

Should be possible, I will try.

I agree, that fixed positions aren't the best option. But I don't know how else to do it, since at the moment the returned string is just the relevant numbers without the information of what they are. Maybe that can be changed...

[Leon-Focker]

I think the only alternative would be to use regex - since I'm not sure how else we would discern between entries in a string.

[mdedwards]

Whatever you think is best. I was just thinking that the order in which things are returned might change at some point but that may simply not be the case or it might be easy to react to it if that does occur. SPEED is of the essence.

[Leon-Focker]

Okay, so changing "default=noprint_wrappers=1:nokey=1" to "default=noprint_wrappers=1:nokey=0" returns all entries with their name like this:

(shell-to-string "/usr/bin/ffprobe" "-v" "quiet"
		 "-show_entries" "format=duration"
		 "-show_entries" "format=size"
		 "-show_entries" "stream=sample_rate,channels,r_frame_rate,width,height,bits_per_sample"
		 "-of" "default=noprint_wrappers=1:nokey=0" "/E/SWELST/video/C0002.MP4")
"width=3840
height=2160
r_frame_rate=25/1
sample_rate=48000
channels=2
bits_per_sample=16
r_frame_rate=0/0
r_frame_rate=0/0
r_frame_rate=0/0
duration=9687.840000
size=114935107344
"

As you can see, we get multiple r_frame_rate entries because when we want audio and video stream data, we have to read ALL streams. You can only choose to read from one stream or all... So packing audio and video in one function means we can already no longer go by order...

Since I wouldn't know how else to parse a list like that, I went with the regex route again. I see no change in speed!

I modified get-sound-info (see ebbd7d0) and added the parse-ffprobe-string function. However I haven't updated any other methods yet.

NB: You can get all entries with this command:

(shell-to-string "/usr/bin/ffprobe" "-v" "quiet" "-show_streams" "-of" "default=noprint_wrappers=1:nokey=0" "/E/SWELST/video/C0002.MP4")

That way you can also determine their names...

[mdedwards]

Thanks Leon. Would you feel in a position to pack those into the vid file slots?

[Leon-Focker]

Thanks Leon. Would you feel in a position to pack those into the vid file slots?

Sure. My approach would be to check if (equal (type-of sf) 'vidfile) in sndfile/update. Or is there a more elegant way?

[mdedwards]

take a look at vidfile.lsp

[Leon-Focker]

Ah, vidfile-p of course :P
But checking that in sndfile/update is the way to go?

[mdedwards]

Maybe I should just take over.

[Leon-Focker]

Sure, obviously I'm missing something...

[mdedwards]

OK. It might take me some time as I really have to do other things now. But it's not at all urgent anyway.