|
|
| -vdub- |
| Posted: May 15 2012, 11:12 PM |
 |
|
Advanced Member
Group: Members
Posts: 613
Member No.: 27087
Joined: 24-February 10
|
If refer to my posts. I am looking into using those new optical writers and players to do this. Which will enable the original data to remain (as is) unmodified. Using Newer Blu-ray writers and players when have one I then can see about up-scaling on the fly for viewing. Maybe able to watch at 1024x576 without black bars padding present at the top and bottom of the video.
For this I'm looking at the new optical blue-ray extra layer (xl) drives, that can store 128gb to each blu-ray disc. |
|
| mpegclient |
| Posted: Jun 3 2012, 05:52 PM |
|
|
Newbie
Group: Members
Posts: 1
Member No.: 34970
Joined: 2-June 12
|
Hello,
My computer OS windows 7, 64-bit.
I extracted 32-bit static build (the latest version) into vd program directory. Then I extracted the x86 v0.7 (32-bit) binary plugin into the vd dierctory. Then I moved the ffinputdriver.vdplugin to the plugins folder. When I open the virtual dub and try to open wmv file the pogram crashes with kernelbase error. Any idea wht is happening? |
|
| Abrazo |
| Posted: Jun 3 2012, 07:40 PM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
Together with the "ffinputdriver.vdplugin"-file there is also a subfolder (ffdlls) with four files in it that you have to copy to the plugins32 folder of VirtualDub. Did you do that ?
C:\Program Files\VirtualDub\plugins32\FFInputDriver.vdplugin
C:\Program Files\VirtualDub\plugins32\ffdlls\*.* |
|
| Abrazo |
| Posted: Jun 4 2012, 07:22 PM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
@mpegclient
I received your reply by e-mail and succeeded to reproduce your problem: An exception occurred in module 'KERNELBASE'
It is simply the fact that you do not have that "ffdlls-folder" (with the four dll-files in it) as a subfolder of the "plugins32"-folder in VirtualDub.
Another attempt to make that clear:
C:\Program Files\VirtualDub\VirtualDub.exe (+ the other VirtualDub-files in that same folder)
C:\Program Files\VirtualDub\plugins32\FFInputDriver.vdplugin
C:\Program Files\VirtualDub\plugins32\ffdlls\avcodec-53.dll
C:\Program Files\VirtualDub\plugins32\ffdlls\avformat-53.dll
C:\Program Files\VirtualDub\plugins32\ffdlls\avutil-51.dll
C:\Program Files\VirtualDub\plugins32\ffdlls\swscale-2.dll
And forget about that files in "ffmpeg-latest-win32-static.7z", you don't need them.
Still to be as clear as possible: when you want to open a *.WMV with the FFMpeg inputdriver:
- click File > Open video file...
- select the wmv-file that you want to open (one single click on the filename)
- than at "Files of type:" select "FFMpeg Supported files" out of the choicelist
- only on that moment, click on "Open"
|
|
| AEN007 |
| Posted: Jun 11 2012, 03:23 PM |
|
|
Advanced Member
Group: Members
Posts: 90
Member No.: 24508
Joined: 10-November 08
|
11June2012
... Seems like this might be the/a proper place to post a request
for some way to use FFmpeg for ViDub playback...FFmpegPlayback?
AvantGUI, which uses FFmpeg for playback, will play
video files with "outrageous dimensions" on my PIV/XP laptops.
Neither ViDub (not even with this FFmpegID)
nor other (freeware) MultiMedia apps will playback those files.
AvantGUI will play these files whether opened directly or via aviSynth.
ViDub will not.
It seems that avs files are not an FFmpegID supported file type ...
... maybe avs files could/should be an FFmpegID supported file type?
... if the actual source file is an FFmpegID supported file type ... |
|
| L.H.V.F. |
| Posted: Oct 15 2012, 12:59 AM |
|
|
Advanced Member
Group: Members
Posts: 49
Member No.: 28822
Joined: 19-October 10
|
| QUOTE | Hi, raythe0n
[...]
Note: Other people are facing similar problems with some damaged videos or problematic medias, as I have saw and had notified, with principally .flvs with unexpected situations. If the direction of the development be dedicated for some damaged stream media or problematic media and fix unexpected situations, the users will not go back for other alternatives, and the video editing will be very usable and efficient (mainly for file extensions with difficult support, and recognition, that are already supported by the FFmpeg library). I am reporting, and trying to convincing that developers of FFmpeg Project to correct the bugs, principally in .ts file extension (Transport Stream) with wrong framerate recognition (because of the instability in VirtualDub), and one day, maybe, this will be fixed as are done with the FFDShow, for windows operating systems. There are, as I can enumerate, players that support these damaged medias (reconstructing the basic structure or recovering the keyframe map and tables), as the MPlayer or VLC, and other players, as recently now the Media Player Classic - Home Cinema, supporting some damaged videos, by deactivating some filter or internal configuration, or creating a workaround for can play these damaged media, and more videos in general, as I have noticed.
I recommend that with FFmpeg Input Driver, in terms of usability, all problems be submitted for analysis in FFmpeg Bug Tracker, because there, is where the developers of the Official FFmpeg builds could correct all errors or problems with all based libraries, since that many programs uses that library, and programs uses it, to have a free library, as a base, and are affected for some error existent, using it for have this free support in their Projects for video and audio or stream media. Even if that the error be minimum, I believe that with various patches received to mantainers, is possible that in a nearly future all video, that in the moment have a problems, these will working better consequently, since that the FFmpeg Bug Tracker has many developers working for improvements in all libraries related of FFmpeg Project. I'm in the Bug Tracker, and in any notice of Bug correction of .ts, and h264 libraries, I will notify raythe0n developer for update your builds, even as other fixes that will go together all development of FFmpeg Project. I need also, some people that be understood in the subject, for notify a possible noticed Bug error (for FFmpeg Input Driver), and write a correct description, of what goes wrong, and technical explanation for convincing the developers of FFmpeg Project, after the reproduction of a possible problem, for the developers make a correction in the bug mentioned. Seems that are happening some progress for H.264/AVC .ts streams (incorrect framerate recognition, with double of 29.970 fps as 59.940 fps).
I thank reply,
L.H.V.F. .
|
Hi to Everyone
Good news. Since now, 14, October, 2012, the bug related with H.264/AVC .ts streams has been fixed, and I have opened that bug ticket and responsible for notice of this bug ticket (now closed and fixed), since that the VirtualDub has crashed with a sample .ts that previously, I wanted to convert, with the best quality of VirtualDub, and it stability, but testing without DirectShow Input Driver, that would be envolved various configurations with x264vfw, and I have not did that yet, and I have used the VirtualDub only with K-Lite Mega Codec, and LAV codecs and for while, not with the bridges x264vfw, Haali Splitter, and maybe with FFDShow-tryouts. Have passed 7 months since I open the ticket with the bug with a sample .ts, with a sample smaller that I had, and I had to convincing the developers for focusing this problem and analyse the problem. Several programs, even at Doom9.org Forum have to be corrected and updated, even the TsRemux, with ability for the reconstruction of the tables of broken .ts streams, and I will notify this for the developer, in the Doom9.org Forum. Now even in Linux or Mac, will more easy to play video streams with in this H.264 format, including VLC (played experimentally with ffh264 decoder in other players, and with an incredible stability viewed by me, only in actual Debian stable in VLC media player, same for HD videos with a stuttering video reproduction, and in big dimensions), MPlayer, SMPlayer, or any other player based in FFmpeg, now with better quality in CLI conversions/ video handlings in the FFmpeg, now with the correct handling of the framerate (has detected at 59.940 fps, and now correct and exact "29.970" fps for correct default of the h264 libraries). MPlayer stable Linux release (1.1 - not the SVN), by use the FFmpeg 0.11 as release compatibility, suffers with dropped frames.
Note: Who have a sample with problems, in .ts or any other H.264, please give me a smaller sample that have for sent and specify technically the problem for FFmpeg Project in the Bug Tracker. Please, raythe0n, update your plugin for next builds of the latest Zeranoe FFmpeg windows Official builds.
Edit: Now, 20 October, 2012, Zeranoe FFmpeg windows Official Builds, have released the update, with the fix of my opened bug ticket and referred by me. I will notify raythe0n forum member developer, for update your plugin.
Snapshot of FFmpeg CLI (ffplay.exe) playing the video, with corrected framerate recognition:
http://s18.postimage.org/w2zjhelbt/Transport_Stream_h264_avc_bug_fixed.png
Edit (2): Coming soon, probably, in the next year, the VLC media player could be included with a new version of FFmpeg, updated with the Bug Correction from my ticket in FFmpeg Bug Tracker, whose has fixes for H.264/AVC streams, since now (2.0.5) the base used of the FFmpeg is still developed with the previous versions of FFmpeg, meaning that the next version could be with the next FFmpeg news release stable:
http://git.videolan.org/?p=ffmpeg.git;a=log;h=refs/tags/n1.0.1
Edit: (3) Today, 11th April, 2013, the 2.0.6 VLC have not included the mentioned FFmpeg fix in your base used. However, in Linux, you can compile VLC with the latest FFmpeg GIT, in the Official repository. Maybe in the next versions, will come carried with the fixes from the Official FFmpeg Project.
Update: Now in 05-05-2013, the MPlayer Community have released a new version update (1.1.1), and as well the VLC in June, 13th, 2013, have released a new version, the "2.0.7", but these two Projects are still developed with previous versions of FFmpeg and ships with the FFmpeg 0.11, much probably looking for a stability with exaustive tests of previous releases below the 1.0 version.
|
|
| -vdub- |
| Posted: Dec 22 2012, 06:08 AM |
|
|
Advanced Member
Group: Members
Posts: 613
Member No.: 27087
Joined: 24-February 10
|
RaytheOn Belated post for FFmpeg Input Driver x32 v0.7.32 which has left over remnant .svn folders and contents in the download zip archive > Plugins32 folder and also in the ffdlls folder. Replacement archives would be useful for when helping people install your plugin, not to have those .svn folders in their Plugins32 folder.
Maybe you do quick update to a new version also for new ffmpeg changes would be most welcome  |
|
| -vdub- |
| Posted: Jan 15 2013, 03:18 PM |
|
|
Advanced Member
Group: Members
Posts: 613
Member No.: 27087
Joined: 24-February 10
|
Audio aac with direct audio copy will output the audio as wav pcm format only. This is noted with avc/aac in mp4 and flv containers and maybe the same for other containers.
Needing a fix to retain the aac audio with direct copy |
|
| tateu |
| Posted: Mar 15 2013, 07:43 PM |
|
|
Member
Group: Members
Posts: 17
Member No.: 22214
Joined: 7-October 07
|
Anyone else notice that it doesn't decode the last frame of some files such as mjpeg or uncompressed AVI, and that it doesn't decode the last several frames of some files such as IBP h264 MP4 and also I-Frame only h264 MP4?
If my uncompressed or mjpeg AVI file is 48 frames long, all frames will decode correctly as I step through them until I get to frame 47. At frame 47, the status bar in the lower left of the VirtualDub window will say "decoding frame 47 ..." and VirtualDub's CPU usage will stay pegged at 100% of 1 CPU core. If I stay on frame 47, it will continue to max out 1 CPU core and will never decode the frame. If I step back to frame 46, it will correctly decode frame 46 and CPU usage will drop to 0.
With IBP h264 MP4 files I've seen it not be able to decode the last 16 frames.
I've stepped through the code and it seems to come from "bool VDFFInputFile::readFrame( IFFStream* pStream )." When it reaches the last frame(s) it can't decode, av_read_frame(m_pFormatCtx, pPacket) returns AVERROR_EOF and it goes into an endless loop, trying and failing "bool VDFFVideoSource::Read([...])" over and over again.
But I can't figure out anything more than that. |
|
| -vdub- |
| Posted: Mar 15 2013, 08:28 PM |
|
|
Advanced Member
Group: Members
Posts: 613
Member No.: 27087
Joined: 24-February 10
|
Are you using latest version http://code.google.com/p/ffinputdriver/downloads/list
If problem still persists after update to latest version. You could also post your post here to Issues there, maybe a new version will come from it ! |
|
| tateu |
| Posted: Mar 15 2013, 08:47 PM |
|
|
Member
Group: Members
Posts: 17
Member No.: 22214
Joined: 7-October 07
|
Yes, I've tried v0.2, v0.4, v0.5, v0.6 and v0.7-32. I've even modified and recompiled v0.7-32 to work with a brand new set of FFMpeg dlls that I built from a git clone done two days ago. The problem happens with all versions, on every file I have tried. I can't believe that no one else has this problem or has never noticed it.
I'll post it as an issue at the google code page. |
|
| -vdub- |
| Posted: Mar 15 2013, 10:26 PM |
|
|
Advanced Member
Group: Members
Posts: 613
Member No.: 27087
Joined: 24-February 10
|
Will check that soon since I use FFinputdriver often daily with virtualdub for various type compressed video files.
maybe you could share a link with us all your recompiled ffmpeg updated dlls so we all can have some type of update.
A fork branch of FFinputdriver from the original source code would be welcome if come across one, better if updated often. |
|
| tateu |
| Posted: Mar 16 2013, 06:55 AM |
|
|
Member
Group: Members
Posts: 17
Member No.: 22214
Joined: 7-October 07
|
The FFMpeg dlls that I compiled are built with enable-nonfree so I can't redistribute them. I'm out of town this weekend but I can recompile FFInputDriver using the latest FFMpeg dlls from http://ffmpeg.zeranoe.com/builds/ early next week.
I also fixed issue #10, https://code.google.com/p/ffinputdriver/iss...es/detail?id=10 (it was a 64 bit int truncation error) and could easily fix issue #9, https://code.google.com/p/ffinputdriver/iss...ues/detail?id=9.
Edit: Nevermind, I can't post a build with updated FFMpeg dlls, audio doesn't work because they changed the audio decoding API. |
|
| -vdub- |
| Posted: Mar 17 2013, 03:14 AM |
|
|
Advanced Member
Group: Members
Posts: 613
Member No.: 27087
Joined: 24-February 10
|
That's a shame as wait for RaytheOn could take forever been over a year so far since last release. Maybe you make a fork version with newer audio API if possible ?
If do make a fork branch of this and make #9 above default as long as included for those that need it ability to make default either way. I prefer as is now then can see actually what the aspect really is when loading a video instead of having to check. Also work with correct AR when applying filters (when apply filters). Maybe you fix other bugs also and keep us updated more often that RaytheOn does.
I would be interested if you could fix audio - direct copy that it does direct copy aac audio not convert to pcm audio |
|
| lwc |
| Posted: May 31 2013, 06:39 PM |
|
|
Advanced Member
Group: Members
Posts: 34
Member No.: 20748
Joined: 26-January 07
|
Wow, what a plugin.
Please add "webm" to the OP because this container/format is supported too!
Anyway, should I use this plugin even for files which are supported by fcchandler's plugins? What do you think? |
|
|
