Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg) (Read 15390 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

First, i would like to thank Peter for such great component!
Although there are some problems with it.
1) Some long files aren't decoded at full duration even if duration is reported correctly in playlist.
I had the same problem when decoding with foo_input_exe+ffmpeg if output format set to wav (option -f wav in ffmpeg), but if output format is changed to w64 (option -f w64 in ffmpeg) then such files are decoded at full duration.
2) This is not real problem, just request/wish. ffmpeg has audio compression for ac3 decoding enabled by default. Can we have it disabled by foo_input_ffmpeg? In command-line this can be done by specifying option -drc_scale 0 before -i and it not affects decoding of other formats except ac3 and eac3. Of course i can use foo_ac3 for ac3 decoding, but also e-ac3 exists and ac3 audio can be in some container not supported by foobar2000 natively.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #1
foo_ac3 doesn't support e-ac3 anyway.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #2
Thanks for your feedback.

I'm switching foo_input_ffmpeg to use -f w64 for the next update as well as enabling the ability to supply custom commandline arguments.

Edit: New version posted, enjoy
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #3
as well as enabling the ability to supply custom commandline arguments.
If i understanf correctly, additional arguments from component settings can only be inserted to command line after input file name. Unfortunately -drc_scale 0 should be specified before input file to work.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #4
Version 0.3.1 up.

The extra arguments are now injected before -i %s.
If you require otherwise, include -i %s in your arguments, -i %s will not be inserted again.
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #5
One more question.
I opened foo_input_ffmpeg.dll in HEX editor and found that seeking position with option -ss in inserted after -i %s.
But seeking on long files could be mush faster if -ss was inserted before -i %s (probably, also -copyts after -i % is needed in this case) - https://trac.ffmpeg.org/wiki/Seeking. Or is using of -ss before -i %s just incompatible with component for technical reasons?

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #6
Seeking before input is not sample accurate. It's usually only frame accurate.


Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #8
Alright I'll change argument order to include -ss before -i, thanks for pointing out. And also print FFmpeg commandlines being fired to console so you don't have to use a hex editor to find out what it's doing, perhaps you'll find more potential improvements/tweaks that way.
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #9
The new one does not seem to release the file: ffmpeg keeps the music file locked for editing/deletion even after foobar2000 has closed.
I must admit I have not tried this out on a previous version, so the problem need not be new.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #10
Can't reproduce the issue. Tried some random files with my own ffmpeg compile and the latest 64-bit Zeranoe build.

Does it only happen with certain format and are some custom command line parameters required to trigger it?

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #11
FFmpeg Decoder Wrapper says ffmpeg.exe and ffprobe.exe found in %PATH%. (I run FFmpeg 3.3.3.)

What I did:
In Preferences -> Playback -> Input -> FFmpeg Decoder Wrapper, I added a new entry "m4a as mmm" with mask "*.mmm4a" and no parameters.
I copied an .m4a, renamed the copy to .mmm4a, and dragged it from Windows Explorer into fb2k and played.
Closed fb2k.  Tried to delete. "The action cannot be completed because the file is open in ffmpeg.exe".

Task Manager reports that there are two ffmpeg.exe processes.

Tried with .mp3 too.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #12
You're sure there is no foobar2000.exe process still running? When the player process ends all of its subprocesses will also be terminated by the OS.

I for one still can't replicate your issue. I tried both 32-bit and 64-bit ffmpeg 3.3.3, but as soon as I hit Stop, close the player or kill it with Task Manager, I can remove the just played .mmm4a file.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #13
Argh, sorry for wasting your time.  There is a folder with shims in my %PATH%, something I forgot to even check when I found the actual applications from Task Manager.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #14
Version 0.4 out - much improved FFprobe interop, added conditional inaccurate/accurate seeking.
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #15
conditional inaccurate/accurate seeking.
It seems i can't find condition when inaccurate/fast seeking is used  ;D 
Maybe it is possible to add option in component preferences to force inaccurate seeking?

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #16
It seems format name field cannot be empty. In wiki says -> Leave this field empty to show FFmpeg-reported codec name as "codec" info.
Do I get it wrong? Sorry, I'm bad in English :)

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #17
conditional inaccurate/accurate seeking.
It seems i can't find condition when inaccurate/fast seeking is used  ;D 
Maybe it is possible to add option in component preferences to force inaccurate seeking?
If you just play a standalone file and use the seekbar, fast seeking is what you get - which you can verify with the console, -ss goes before -i.
If the decoder is invoked in any other context (conversion, file referenced by cuesheet, etc), slow seeking will be used instead.
It seems format name field cannot be empty. In wiki says -> Leave this field empty to show FFmpeg-reported codec name as "codec" info.
Do I get it wrong? Sorry, I'm bad in English :)
Ooops, forgot to allow empty value there. Fixing soon.

Edit: 0.4.1 posted, blank format name now works.
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #18
If you just play a standalone file and use the seekbar, fast seeking is what you get - which you can verify with the console, -ss goes before -i
This is exactly what i'm trying to do. But seeking is slow with version 0.4 and 0.4.1 (like it was before version 0.3.2) and in console i see that -ss is used after -i. https://youtu.be/YQQ6Q3T-jFs

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #19
Uncheck:
Preferences / Advanced / Playback / Slow but accurate seeking (affects some music formats only)
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #20
Uncheck:
Preferences / Advanced / Playback / Slow but accurate seeking (affects some music formats only)
foobar2000 1.3.17 beta 3, foo_input_ffmpeg 0.4.1. Can't find such option

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #21
That's true - I also can't find that option.

Bonus question - does this plugin affect foo_input_exe already configured with ffmpeg? I mean - can I expect randomized output of files configured to be played through foo_input_ffmpeg if they were also configured to be played through foo_input_exe (sometimes through foo_input_exe, sometimes through foo_input_ffmpeg) ?

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #22
Two more things:
1st: as I don't see any dedicated general topic for foo_input_ffmpeg I will put that here - can we have here option similar to foo_input_exe - to import/export settings to an .xml format? It would be great to be able to import settings from foo_input_exe to foo_input_ffmpeg - in my case all foo_input_exe entries are using ffmpeg.exe...
EDIT:
2nd: The way that format name is handled now is not nice. To be able to see how ffmpeg detects all formats, I must keep a long column of "unnamed" formats - not convenient when I need to edit something - which "unnamed" chould I doubleclick? It should work like this: Format name is just user description and should be MANDATORY. Then, there should be checkbox named "report formats as detected by ffmpeg instead by Format Name field". And checking this will cause that despite I named my format "MPEG-2 Video Containers" I will see "MP2" in my status bar or related column in playlist.
By the way - I am used to see formats in foobar in upper case, but now "MP2" is reported as "mp2" and "MS ADPCM" is reported as "adpcm_ms". It would opt for having formats reported as "all uppercase" .

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #23
Well, this is embarassing, indeed the fast/slow seeking toggle is a fb2k 1.4 feature and you guys don't have it yet. I'll provide a workaround shortly.

Re: foo_input_exe vs foo_input_ffmpeg
This is how fb2k has been doing things since sometime 2003, on each startup the order of services is randomized, to prevent things that rely on service order from working reliably. If you have more than one decoder supporting a specific file format, which one will get it is undefined - or rather, intentionally random. The alternative is that you'd have a seemingly working config that suddenly breaks with some change that causes DLLs to load in a different order, then blame the breakage on whatever harmless thing you just did.
I approached the idea of decoder merit management configuration a few times in the past, most notably in 0.9 alpha days (it was actually implemented but got dropped before a public beta), I think it's time to implement it and make decoder priority fully deterministic.

As for codec names, feedback noted, another new update soon.
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #24
The way that format name is handled now is not nice. To be able to see how ffmpeg detects all formats, I must keep a long column of "unnamed" formats - not convenient when I need to edit something - which "unnamed" chould I doubleclick? It should work like this: Format name is just user description and should be MANDATORY. Then, there should be checkbox named "report formats as detected by ffmpeg instead by Format Name field". And checking this will cause that despite I named my format "MPEG-2 Video Containers" I will see "MP2" in my status bar or related column in playlist.
You can keep your custom format name and use $if($info(codec_long_name),$info(codec_long_name),%codec%) instead of %codec% to display real codec info for files decoded by foo_input_ffmpeg.