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 17042 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #25 –
Thanks Rollin, looks like it works as intended. However - I would still welcome to also have the option that I described above.

Regarding "foo_input_exe vs foo_input_ffmpeg" and randomized decoders order - honestly Peter I don't want you to change anything in the foobar's core - it may be randomized as it is now - that's is no problem. I only wanted to be sure, if I get correctly, that with these 2 very similar decoders I can expect, that when both are loaded and both have been configured in similar way / to support same formats (input_exe due to legacy reasons, input_ffmpeg just as I wanted to test it and compare to input_exe behaviors) I may notice that something changes between foobar's runs. For a short time when both were loaded I think always input_ffmpeg was loading first. I guess it by the fact that input_exe and input_ffmpeg act differently when reading audio from my music videos. And for sure input_ffmpeg works much closer to my expectations. Plugin foo_input_exe is rather "last resort" solution for me, for some very strange formats. Don't get me wrong and don't read my words as criticism - its presence is a great option, however its nature doesn't allow me to work with certain files exactly as I need, but I accept it. But it is even greater thing that foo_input_ffmpeg came as a companion to foo_input_exe.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #26 –
Version 0.4.2 posted, seeking is now working as intended.

A new toggle has been added for codec name handling.

Some way to import/export format list is coming for 0.5.
Microsoft Windows: We can't script here, this is bat country.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #28 –
Don't ask.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #29 –
May as well not ask, since there's no definite answer.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #31 –
I have specific problem with my foobar. I don't know how to determine which component - foo_input_ffmpeg or foo_waveform_seekbar fails. The problem is that several files played back through foo_input_ffmpeg (video files in various containers) don't display waveform seekbar in my DUI. Or to be exact - I see progress in producing the waveform, but after reaching certain point it disappears. Those files definitely report some errors at the very end of the files. So - this may be some slight problem with error handling in any of these 2 components.

Here:
https://1drv.ms/u/s!AizQnez18-j2dShrVxmuiytDduo
I gathered together all these problem causing files, together with list of errors that they produce and configuration files for both components. Additionally there are 2 files that do not brake waveform generation, despite there are also errors produced while files are played back.
My foobar is v 1.3.17 b3. My OS is Win7 PL x64 SP1 MSDNAA sourced, with all security updates installed. Graphic card is nVidia GTX 1050Ti with drivers version 382.05. Problem is first observed in this config (foo_input_ffmpeg as component that supports these video files). In the past I didn't had this kind of issues (when foo_input_ds was used for the same purpose and I didn't have problems with DirectShow and files were played back smoothly). If any more details are needed - please let me know.
I am asking both Peter (here) and Zao (in his plugin thread) to take a look at this situation.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #32 –
@EpicForever The archive seems to be broken in both 7zip and WinRAR:
!   F:\Downloads\seekbar_disappears.7z: CRC failed in seekbar_disappears\Dieselboy & Technical Itch – Atlantic Connection  SEEKBAR DISAPPEARS.VOB. The file is corrupt
!   F:\Downloads\seekbar_disappears.7z: Error - operation failed
Stay sane, exile.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #33 –
I have 2 entries I added and enabled from the list.
Adaptive Multi-Rate for *.AMR and WebM Audio for *.WEBA, both with Show codec names from FFmpeg unchecked.
When playing *.AMR, it display AMR_NB but when playing *.WEBA, it display WebM Audio. So it seems to me that foobar2000 doesn't display codec name correctly. With Show codec names from FFmpeg checked, no changes.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #34 –
@Zao: OK, I see the problem also in file on my HDD. Probably, because .cfg files were added to ready archive with Mvids - repack was unsuccessful.
I took down previous file and added new one, tested, with .md5 inside (for unpacked files) and .md5 outside (for the download).
7ZIP: https://1drv.ms/u/s!AizQnez18-j2dxtQR5Ds5OoxoPo
MD5: https://1drv.ms/u/s!AizQnez18-j2dtTfo9jSFLyAmMM

By the way when I am in this topic - there is a side effect of using foo_input_ffmpeg. If I play any file through FFMPEG I can't delete it while playing, despite my settings for full file buffering (250MB). For all files natively supported by foobar I can delete the song from HDD while it is played from the buffer / memory. It includes files supported through dedicated plugins - like I recently encountered with Adaptive Multi Rate files, which I switched to be supported through FFMPEG to limit number of dlls in fobar. For files that go through FFMPEG I always get message that file is locked :) . But that's just a note here - I don't expect it to be changed / "fixed" as I know that this technically can not be "fixed".
Other note - I am surprised that despite I configured foo_input_ffmpeg to play .flv files, I always get "Unable to open item for playback (Unsupported file format)". Is it really not playable through FFMPEG? Accordingly to this source: https://trac.ffmpeg.org/wiki/SupportedMediaTypesInFormats they should be supported. Most of these files have audio in MP3 format, some in AAC format. None are playable... I use 64bit Zeranoe build of FFMPEG, dated 11 November. Does this change anything in formats recognition? When I run command "ffmpeg -formats" FLV was shown to be supported (muxing and demuxing) in the build that I use...

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #35 –
@EpicForever I just tried playing FLV files and it works. Maybe there's conflict with other components.

Anyway I just found how to produce my issue above. If I check " Show codec names from FFmpeg unchecked" play certain file, it shows correctly. If I uncheck it, it keep show previous codec name. But if I play new file, it shows as format name entry. So, seems to me there's history saved for codec name for each files.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #36 –
@EpicForever
The files you have problems with have decoding errors.
If you check them with http://www.foobar2000.org/components/view/foo_verifier you will see it.
You could also check running in a cmd line
Code: [Select]
ffmpeg -v error -i filename.ext -map 0:1 -f null - 2>error.log
You will need to fix the files for them to work.
For MPEG2, TS you could use https://www.videohelp.com/software/ProjectX to repair.

Alternative is to demux the files, fix them and remux to a new container.
If possible/supported remux to mp4,
https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
as mkv with foobar2000 native decoder has slow seeking.

p.s. Some of the files you uploaded have two audio streams , foobar2000 will only play the first audio stream it finds.


Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #37 –
@arch21: I found the reason for problems with FLV. Declaration was wrong:
*.flv, *.fla   (note the coma)
while it should be:
*.flv; *.fla  (note the semicolon) - now it works as it should.

Regarding your problem with codec name representation - you need to use function "Tagging / Reload info from file(s)" in context menu for affected files.

@zermy: sure, files seem to have errors and are remuxed already, however if they can be played back as they are - then it would be nice if error handling in any component that is used to process them could still allow to build waveforms for them - but it seems it is up to foo_waveform_seekbar to make it happen.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #38 –
@EpicForever Thank you so much, it works. :)

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #39 –
Concerning Flash Video, is there any reason not to remux them?

Edit: oh, should have read the rest of zeremy's post.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #40 –
Some additional / more general note:
I went to Windows 10 installation, because of Forza Horizon. Additionally I dug through foobar installation on that OS. I cleaned up components in similar manner as under Windows 7, with one exception  - I left there unconfigured foo_input_ffmpeg and I left there working foo_input_ds. I tested it with bunch of old Mvids, awaiting to be finally deleted after remuxing them to .mkv

Observations:
First of all - waveform seekbar works there very well on all tested video files (as it was usually, before I overloaded foobar with DLLs). All waveforms, for all supported video files are displayed and they don't disappear at any circumstances.
Then:
There are some files which are barely seekable (audio is reset to beginning upon any seek operation). But that changes when LAV Filters are re-installed from their separate installer (see below). This doesn't occur under Windows 7, where I use foo_input_ffmpeg - so here we have big advantage of this method of playing back audio from video files.
There are some files which incorrectly report their length, even after LAV reinstallation - they are cut by 20, 30, 45 seconds. What is specific: when all video files are played in foobar, in notification area I have just LAV Splitter and LAV Audio Decoder icons. But when some of these "broken" files come to its premature end - these icons start quickly appearing and disappearing with LAV Video Decoder showing up 2-3 times for an eye-blink. Waveform seekbar shows their waveform cut, accordingly to length reported on playlist, which is rather proper behavior. Such situations doesn't occur with foo_input_ffmpeg, with exception of Westbam - Hard Times.mpg mvid. Still an advantage of foo_input_ffmpeg method, which fails only with one file.
That Westbam - Hard Times mvid reports proper length when played through foo_input_ds and is properly seekable, with proper waveform in seekbar displayed... So it is totally different to what is achieved through foo_input_ffmpeg as a data feed for foo_waveform_seekbar, where file reports just 2-3 seconds of length. Together with files, which play and seek properly, but throw playback errors at their ends (which causes foo_waveform_seekbar to discard whole waveform data) we can see also some limitations in either ffmpeg.exe/fprobe.exe combination or foo_input_ffmpeg itself.

Now something closer to the topic:
Of course as a non developer, and as somebody who don't know exact pipelines in foobar / certain components I don't want to blame Peter for above mentioned problems which occurred when I was using his component and issues that occur in foo_waveform_seekbar. Having my above observations in mind I would like to simply ask for an expertise, if this is due to foo_input_ffmpeg's very rough handling of errors coming from ffmpeg.exe (present in decoded data stream as well as in form of any kind of control/debug messages - if they exist) OR if this is only due to ffmpeg.exe internal behavior (how it treats internally situation when source file is broken - how decoded stream is prepared in such situation and if ffmpeg cares in such cases how receiving party will read it). This will simply allow me to know overall limitations of the setup that I have and properly react to any errors in "through-ffmpeg-playback" that may occur in future.

Side note:
What I can say regarding the pain that was induced by foo_input_ds (which caused me to exchange it to foo_input_ffmpeg) - both Win 7 and Win 10 were installed at the same time, so I used the same KLCP installer on both, and used the same settings for installation. So I suppose this is KLCP installer that messes something in system (not the first one, but not all of them are such buggy). It may be also something with recent version of LAV filters, as in both cases (Win 7 & Win 10) installing just LAV Filters taken directly from their source doesn't change situation that much. I suspect it because afaik both KLCP installer and direct LAV installer install LAV in the same version, so that may suggest that it is this exact version of LAV to be blamed for problems when foo_input_ds was used.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #41 –
@EpicForever you can add -loglevel 0 to Additional arguments. This should fix disappearing of waveform for files from your archive when decoding with foo_input_ffmpeg.
Westbam... is really broken/malformed. ffmpeg, mpc-hc/be+LAV, VLC, mediainfo - all report wrong length.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #42 –
Rollin - it is not the first time you helped me :) . That switch works great with all the files that I had problems with. And you know what? After adding that switch even Westbam shows its length as 3:17. Still there is something wrong - file is 3:47 long, anyway that is some progress ;)
 -loglevel 0 is now a must in my foo_input_ffmpeg config :)

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #43 –
There is still some slight problem, despite all switches, etc. Some of these problematic files are 5.1 DVD-Video files (.vob with 5.1 AC-3 sound). When I play these files remuxed to .mkv OR when I play them through foo_input_ds Zao's waveform seekbar shows 6 channels - exactly as it should. But when I play them through foo_input_ffmpeg waveform seekbar shows only 4 channels - Rear left and Rear right are missing. They reappear after ticking Side left and Side right. Accordingly to all findings it seems it is problem in stream from foo_input_ffmpeg - foo_waveform_ seekbar gets incorrect channel flags... can it be somehow cured?

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #44 –
@EpicForever, standard channels layout for Dolby 5.1 is front left, front right, center, lfe, SIDE left, SIDE right - https://en.wikipedia.org/wiki/Surround_sound#Standard_speaker_channels (see "Note" 3 in header of column "5.0 side"). So, probably ffmpeg is right here and foo_input_ds is wrong.

Quote from: EpicForever on
When I play these files remuxed to .mkv <...> Zao's waveform seekbar shows 6 channels
I take "Dieselboy & Technical Itch – Atlantic Connection" from your archive, remuxed its video and ac3 audio (and drop PCM audio) into mkv with mkvtoolnix and when playing with foo_input_ffmpeg it still reports fl, fr, c, lfe, Sl, Sr (not Rl, Rr). So it seems that remuxing doesn't changes channels layout reported by ffmpeg.
 

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #45 –
One note - I missed it - all .mkv files are supported here natively - not foo_input_ffmpeg nor foo_input_ds were allowed to process these files in their config, so playback is based on foobar's built in capabilities of Matroska containers. In such case I don't have to add Side channels to foo_waveform_seekbar configuration, but Rear channels instead - and it was working like that for years. So - from my perspective this is something completely new and unexpected... I remember that one time due to similar complaint built in "downmix channels to stereo" DSP was updated to support some other channel configs, as without it sound was wrong and/or waveform_seekbar display was also wrong...
You know - I am not an expert - I just reported something that is unexpected from the perspective of usage of core components for few years. If we need to dig deeper / search for the problem elsewhere - no problem, I am open for some tests, etc.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #46 –
Quote from: EpicForever on
One note - I missed it - all .mkv files are supported here natively - not foo_input_ffmpeg nor foo_input_ds were allowed to process these files in their config, so playback is based on foobar's built in capabilities of Matroska containers. In such case I don't have to add Side channels to foo_waveform_seekbar configuration, but Rear channels instead - and it was working like that for years. So - from my perspective this is something completely new and unexpected...
So "playback based on foobar's built in capabilities of Matroska containers" is reporting wrong channels layout. Or more likely not reporting it at all. If channels layout is not reported, by default fb2k "thinks" that 6 channel audio is FL-FR-C-LFE-RL-RR

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #47 –
Does this wrapper work with radio streams, or files only?  I have made and selected an entry in it like this:

Format name: OPUS 1.2.1
File type mask: OPUS;http://*.opus

Regular Opus files play fine and show the codec type in the Status bar as "OPUS 1.2.1", reflecting the given format name in the wrapper plugin.  When playing an opus radio stream, the status bar codec type displays just as "Opus", the same as when not using the ffmpeg wrapper.

No big deal, and I know Foobar supports Opus natively, but just was curious to know if the new wrapper is actually in use for radio streams or not for a format if Foobar already natively supports it (or did I specify the http file type mask wrong??).

Thanks for any input!

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #48 –
The wrapper can both work with streams that ffmpeg.exe supports (like HLS and RTMP) and plain files.

I thought FB2K had native Shoutcast/Icecast support for Opus out of the box.

Re: Problems with component FFmpeg Decoder Wrapper (foo_input_ffmpeg)

Reply #49 –
Thanks mudlord for the reply!  Yes I know fb2k already supports Opus streams, was just using this entry as a test case to see if the wrapper was being used or not on streams at all by seeing if the format name I gave one was reflected by the status bar info.  As the latter was indeed the case when playing a file, I was wondering why it did not show the user-given format name when playing a stream.  If the nomenclature I used in the file type mask, http://*.opus, looks correct to you then I guess the status bar name difference is in the "not to be concerned about" category.  Probably too many of my concerns fit that one anyway, haha..