For an initial release it's remarkably good
| Printable Version of Topic
Click here to view this topic in its original format |
| Unofficial VirtualDub Support Forums > VirtualDub Filters and Filter Development > Ffmpeg Input Driver |
| Posted by: raythe0n May 10 2011, 10:20 AM |
| REQUIRES VIRTUALDUB V1.10.xx+ for v0.8.0.5 or later Installation: Place unarchived package under VirtualDub program directory. NOTES: -Supported YUV420P, Y8, UYVY, YUYV, RGB555, RGB565, RGB888 color spaces; -Simple downmix of multichannel audio stream alg implemented; -Both video and audio are always decompressed; - Implemented Media File Information dialog (File->File Information) for the first video / audio stream in the container file; -Source solution for vs2010 included (but earlier versions of the VS can be used); -Opening file formats: anm; asf; avi; bik; dts; dxa; flv; fli; flc; flx; h261; h263; h264; m4v; mkv; mjp; mlp; mov; mp4; 3gp; 3g2; mj2; mvi; pmp; rm; rmvb; rpl; smk; swf; vc1; wmv; ts; vob; mts; m2ts; m2t;*.mxf;*.ogm;*.qt;*.tp;*.dvr-ms;*.amv To build the driver you will need the assembly of ffmpeg libraries for win32. (recommended assembly by http://ffmpeg.zeranoe.com/builds ) v0.7 [mod edit] newer version lower down the page [01/22/2012] Changelog: -ffmpeg v0.9.1 with significant speed improvements; -added x64 version; x64 Plugin Binary: http://code.google.com/p/ffinputdriver/downloads/detail?name=ffinputdriver-bin-0.7-64.zip x86 Plugin Binary: http://code.google.com/p/ffinputdriver/downloads/detail?name=ffinputdriver-bin-0.7-32.zip ------------ [mod edit] Latest version V1.8.2.5 https://sourceforge.net/projects/virtualdubffmpeginputplugin/ V1.8.2.5 [8 March 2015] Update ffdlls to 2.6.0 Add checkbox to enable/disable priority - with it enabled, virtualdub is giving us .avs files even though we don't want them Change version number so it's higher than a very old version that was released V0.8.2.4 [25 February 2015] Added set plugin priority in the extended options dialog and file information dialog Added plugin is selectable from audio menu 'from another file' Fix better handling of truncated audio stream Fix seek recursion endless loop Modify fallback of reading options from HKLM registry in case an installer wants to set any options on install Fix bug in seeking loop (accidental = instead of ==) V0.8.2.3 [14 February 2015] Update ffdlls to 2.5.4 Fix small bug in offset audio when dropped frames are at the beginning Modify ensure width/height are mod2 when aspect scaling is enabled Modify use lanczos scaling when aspect ratio is enabled V0.8.2.2 [31 January 2015] Modified use longest duration of audio when stream and format lengths are different Modify pad end of audio packet when at the end of an audio stream Fix reading very first audio packet when seeking Fix honouring the sync video/audio option when turned off Modify try reducing some seeks in the audio Modify add extra codec info to file information dialog Fix video stream may change height/width during decoding, caused green bars at bottom or right Fix decode error in sws_scale that could crash on certain height/widths when playing in virtualdub Modify file information dialog to add some more info Modify audio delay when first frames are dropped V0.8.2.1 [24 January 2015] Workaround seeking in wmv files could be way off - ask ffdlls for frame 2000 and actually get 2500..sigh... Fix setting the first audio stream to the best choice relating to the video when there are multiple audio streams Modify don't autosync audio that's more than 15 minutes out of sync > fix for some .ts files where audio streams are marked as starting a log way off from the video V0.8.2.0 [20 January 2015] Update ffdlls to 2.5.3 Fix bug where seeking would get stuck in a loop > silly mistake, a - should have been a + so instead of moving back trying to find the frame it moved forwards > couldn't find the frame and would try again, still moving forwards..... oops Fix once the above bug was fixed, retrying could be improved to it quits faster on undecodable video frames > with the bug above, the code for undecodable frames was called for valid frames Fix with both of those fixed, some nasty peekmessage code could be stripped out > it was only there to keep the buttons working in virtualdub when the plugin was stuck in a loop > so you could move to a different frame and get it out of the loop > it was a very nasty hack!! >and all because of a minus sign..... Fix files with extra video streams of 1 frame thumbnail images could confuse the plugin Change files with no keyframe index information are scanned when opened to let the ffmpeg dlls build one >this is an option in the plugins preferences (on by default) >may cause a delay on opening a file, but quicker seeking when open Fix trying to cut down on possibly unneeded seeks to try and make playing a video in virtualdub smoother (less stuttering on audio) Fix sometimes a missing frame in the video would manage to skip the code that reports an error to virtualdub >then virtualdub would try again, looping until it was killed Fix bug not clearing buffers after a seek sometimes V0.8.1.9 [29 December 2014] Update ffdlls to 2.5.2 Fix very old audio positioning bug Fix filling mono empty data with correct value Fix try to correct sync of audio at the start when it's been offset Fix crash at end of video Fix repeat last frame at end of video where b-frames cause a shift at the start Fix strange error where you'd get 90000fps for the source file (thanks shek for finding it) Fix error that would slow decoding if frame rates were being altered eg by IVTC Fix seek error in some formats where seeking on the audio failed Fix seek to first frame for some formats Remove .avs from default file extensions, avisynth already needs to be installed and virtualdub already handles .avs better Fix setting first starting frame to only skip leading undecodable b-frames as there are vids with no I-frames (just P&B) Improve seeking in audio with some formats v0.8.1.8 [16 December 2014] Update ffdlls to 2.5.1 Fix first starting frame where there are leading b-frames v0.8.1.7 [30 August 2014] Update ffdlls to 2.3.2 - delete the old ones, these have new numbering Added option(on by default) to sync the audio timestamp start to the video one - fixes some out of sync problems where the audio is off by the same amount all the way through the video v0.8.1.6 [17 July 2014] Update ffdlls to 2.3.0 FFDlls now need swresample-0.dll also swresample-0.dll added v0.8.1.5 [26 May 2014] Update ffdlls to 2.2.2 v0.8.1.4 [20 Apr 2014] Added error checking for missing ffmpeg dlls Larger maximum index size for seeking Timeout for decoding video/audio frames of 2 minutes so job's don't get stuck on queue (->not perfect, virtualdub can still get in a seemingly endless loop on some errors) Reporting decoding errors back to virtualdub on discontinuity Error handling option for allowing an occasional missing frame(s) More accurate discontinuity handling, will backtrack further through the file before giving up on a missing frame Better fps detection Some better handling of decoding errors v0.8.1.3 [29 Mar 2014] Fix another edge case with seeking getting stuck on a frame The day after 0.8.1.2 was released, a failing file was sent to me Sample .mts file had packets needed for a pts time scattered throughout the file It's fixed now, but a file like that can be slow to decode as it was made so you have to read almost the entire file to get 1 frame of video Fix doesn't affect speed of decoding files that aren't like that (I think it's a test sample made to try and break decoders) On the other hand FFMpeg plugin is more robust at decoding bizarre .mts files v0.8.1.2 [28 Mar 2014] Fixed some formats with large keyframe intervals or weird pts/dts had trouble seeking and would only show keyframes after the first seek Extra seeking further back to find a valid keyframe is done now if an initial seek fails Some seeking optimizations Updated FFMpeg dlls to 27/03/2014 - v2.2.0 isn't on zeranoes site, so these are the first dlls after v2.2.0 v0.8.1.1 [20 Mar 2014] After a night sleep, thought of a better way to get the very end frames of the source file Sorry about the quick release but it's better now and didn't want to hold it just because it was so soon v0.8.1.0 [19 Mar 2014] Problem that caused incomplete video frames to be returned to virtualdub (garbled moving blocks) especially after seeking Problem with some formats (eg mkv) when seeking back to the start of the file Problem with the wrong video frame being shown (repeatedly) after turning audio display off and back on Better handling of video/audio at the end frames of the file Added installer c/o raffriff42 v0.8.0.9 [3 Mar 2014] Bugfix for audio downsampling mistake I introduced in 0.8.0.7 Replaced download with one that doesn't require AVX cpu - sorry about that v0.8.0.8 [27 Feb 2014] Updated ffdlls to 2.1.4 v0.8.0.7 [23 Jan 2014] Added option, default video decoding format for unusual formats (There are many formats that virtualdub doesn't handle, now you can choose how they are decoded) Updated ffdlls to 2.1.3 0.8.0.6 Fixed crash from FFDshow dlls logging Added more native virtualdub video formats, so less are converted to rgb -> yuv 410p, 422p, 444p, nv12, nv21 Changed default format to rgb32 from rgb24 0.8.0.5 Added option for FFMPeg autodetecting 709 colorspace - if that info is in the source file Added option for setting 709 colorspace for source file height>=720 Use the ask for extended options checkbox on opening a video to set them Disabled by default 0.8.0.4 Fixed so registry works on XP Includes required ffmpeg dlls 0.8.0.3 Settings saved in registry 0.8.0.2 (a) The "Adjust Pixel Aspect Ratio" option is disabled by default 0.8.0.2a plugin 0.8.0.2 - Implemented full support for multichannel. - Fixed a memory leak. - When opening a file with the plugin, if you select "Ask for extened options after this dialog", you get the following options for audio -- Downmix Audio - if selected, downmixes multichannel to stereo (off by default). -- Limit Audio To 16-bit - converts 32-bit audio source to 16-bit samples (off by default). Note that virtualdub has some limitations when dealing with multichannel or 32-bit source audio: - Some audio compression codecs do not accept multichannel or 32-bit samples as input. - Virtualdub menu Audio->Conversion does not know how to mix multichannel down to stereo, or convert 32-bit audio to 16-bit. - Therefore, above options in "Open video file" were implemented to convert to stereo or 16-bit if necessary. 0.8.0.2 plugin 0.8.0.2 source 0.8.0.0 - Upgraded to current versions of ffmpeg - avcodec-55, avformat-55, avutils-52, swscale-2. - Minimized usage of deprecated features in ffmpeg. - Added support for planar audio formats. - Added support for 32-bit audio samples. - There's tentative support for multichannel, but Virtualdub hangs when fed multichannel audio by an input plugin. So for now, multichannel is down-mixed to stereo as before. See Below. - Fixed a bug that caused garbled audio and occasional crashes near the end of playback. - Split the sources to make them more manageable. - VS2012 project files. |
| Posted by: dloneranger May 10 2011, 11:17 AM |
| Very interesting For an initial release it's remarkably good |
| Posted by: v0lt May 13 2011, 04:02 PM |
| Good alternative for "Directshow Input Driver". You can do a simple "File Information..." window? |
| Posted by: raythe0n May 16 2011, 09:12 AM |
| Thx. ) I'm planning the next release with bug fixes. And then I'll add file information and some options for management. Knowing issues: - Crash when opening an uncompressed avi; - Delay in audio playback when you cut fragments of video (about 2 seconds, depending on the number of frames between I-frames); The Ffmpeg project is developing rapidly so we would expect the addition of new formats and improving the work already supported formats. |
| Posted by: -vdub- May 18 2011, 08:01 AM |
This does sound good will have to try  ! In the past ffmpeg has suffered from major bugs that foxed the developers for a long while. How about also allowing the user able to load any other version of ffmpeg executable they like to work with. For any bugs or to use an older ffmpeg version for a dropped format that is no longer included, so on. ::Note:: Have found taht either dropping doesn't load mpeg2 and .ts files. Using open file with 'FFMpeg Supported Files' doesn't show mpeg2 or .ts files. While FFPlay.exe (cli) or wmp will see and play both mpeg2 and .ts files. |
| Posted by: L.H.V.F. May 21 2011, 01:21 AM |
| Hi, raythe0n One question: With your FFMPEG Input Driver , would be possible to make of someway, create a capacity open videos of the type ".rmvb" (Real Media in general), using, for example, FFDShow or the FFMPEG lib, correctly configurated, or make it possible one day ? I know that Real Media became based in MPEG-4 there is some time. I thank reply, L.H.V.F. |
| Posted by: raythe0n May 23 2011, 12:42 PM | ||
Hi L.H.V.F. I will add the template to open rmvb files as well as the .ts (transport stream) and .vob files . Unfortunately Real Media format is not fully supported by ffmpeg. Some frames appear in the wrong time. Thanks. |
| Posted by: -vdub- May 23 2011, 02:28 PM |
| Thanks Ray for your reply. Looking forward to your next release with mpeg-2 and ts support btw Ray just an after thought the videos i have to process all are mainly mpeg-2 SD with mpa or mp2 audio not often with ac3. Though ac3 would be need for HD .ts streams. Had a quick look at your source and see very few formats of what ffmpeg does support. Can it be made to have all those formats supported in your ffmpeg input driver ? Ask since other virtualdub users will need support for all if possible. Actualy it could easily replace ffdshow_tryouts and would be a clear winner over ffdshow. For those like me who need a simple alternative and those who need minimal install or small portable virtualdub with plugin filters. |
| Posted by: L.H.V.F. May 24 2011, 03:17 AM |
| Hi, raythe0n Now I have saw that your plugin in the documentation supports Real Media (encode/decode). I have a file for sample, for test the FFMPEG Input Driver: http://www.4shared.com/audio/fBBwTusc/videotest.html The error of the video, in my tests (runs the time line, but not play the video correctly): http://s18.postimage.org/bycqft2c9/problem_FFmpeg_ID.png This video up is included in old versions of Real Player. I notice that the video stay freezed, but the time line runs. I guess that the part of audio, needs a codec of the type "ACM" separated, or is not native from FFMPEG lib. Could you see what the file information of MediaInfo says?: Video ID : 2 Format : RealVideo 1 Codec ID : RV10 Codec ID/Info : Based on H.263, Real Player 5 Duration : 5s 0ms Bit rate : 8 979 bps Width : 176 pixels Height : 144 pixels Display aspect ratio : 1.222 Frame rate : 2.000 fps Bits/(Pixel*Frame) : 0.177 Stream size : 5.48 KiB (32%) Audio ID : 1 Format : ACELP Codec ID : sipr Codec ID/Info : Real Player 4 Duration : 4s 482ms Bit rate: 4 616 bps Channel(s) : 1 channel Sampling rate : 8 000 Hz Bit depth : 16 bits Stream size : 2.53 KiB (15%) I had other files for tests, but these are ancient Real Media codecs in geral, and the same in the Real Player new versions, for can play, decode by converting the file for MPEG-4 codec based. You can arrange this problem using schemas utilized for the fccHandler developer, 'Audio from other file' like, for more gama support, in case of the conversion for unknown audio. Thanks for reply, L.H.V.F. |
| Posted by: raythe0n May 25 2011, 03:48 PM | ||
Hi vdub, L.H.V.F. Unfortunately SDK available for input plugin does not allow to use probing file formats functions. So while the file extension is compared with the pattern to open it. One way to open an unknown file just rename its extension. ) HD ts file that I use for the test contains an AC3 audio strem. ffmpeg is experiencing some problems with playback and seeking it. I hope they fix the problem in future. L.H.V.F. i check your rm file and ffmpeg says that sizes of audio packets are corrupted and ffplay playing video with same freezes. File specification are identical. thanks |
| Posted by: -vdub- May 26 2011, 12:19 AM |
| TS + AC3 problems with ffmpeg, try the hd video with this filter installed http://fcchandler.home.comcast.net/~fcchandler/AC3ACM/index.html If ffmpeg also has any problems with aac audio, Fcchandler installable aac filter for use with virtualdub http://fcchandler.home.comcast.net/~fcchandler/AACACM/ |
| Posted by: L.H.V.F. May 27 2011, 01:38 AM |
| Hi, raythe0n I have tested the new format support to open ".rmvb", and I can play the video normally, but apparently the video stays overloaded. The video that I have tested is of the site Bleach PROJECT, that makes subtitle for anime videos in portuguese, and this site have used .avi (DivX), .rmvb, and now produces videos for Bleach anime episodes with Matroska (.mkv using mkvmerge for encode). One thing that I have noticed is that does not exist "File Information" functioning, as you have notificate, it's will be added. I thank reply, L.H.V.F. |
| Posted by: vibe May 27 2011, 12:22 PM |
| Wow this is impressive, many thanks for your efforts. Is there any chance DIRECT STREAM COPY could be supported under video so I could finally fix my old videos with vorbis audio 0x566f which still has no ACM available (for nearly a decade now  )Your driver definitely can read the audio, just no way to preserve original video quality. Just let me know if it's on the "to do" list because I've waited this many years for a solution, I can wait longer, lol. |
| Posted by: -vdub- May 27 2011, 04:57 PM |
| Hi vibe until raythe0n replies for your request for (direct copying a vorbis audio track). I have written a couple of suggestions you could try while waiting Try with virtualdub compressing the audio track to another format such as ac3 or similar instead. Or if need vorbis audio compress to wav with video edits and filters work. Later remux wav back to vorbis changing only the audio track, leaving the video as is. I don't know if virtualdub has good vorbis support or not. You say this ffmpeg input driver does decode and play the audio. Will be easier now to compress the vorbis audio track to another format instead such as ac3 or other. |
| Posted by: raythe0n May 27 2011, 06:18 PM | ||
Hi vibe, Due to different schemes of video processing direct copying couldn't be supported as adopted in VirtualDub. Thanks -vdub- for suggestions. Or there is a way to transcode audio and copy video using ffmpeg utility directly. |
| Posted by: -vdub- May 27 2011, 11:38 PM |
| http://ffmpeg.org/ffmpeg-doc.html -vcodec copy (force video stream copy) -acodec copy (force audio stream copy) -scodec copy (force subtitle stream copy) FFMpeg remux example using stream direct copy ffmpeg -i Source.mpg -vcodec copy -acodec copy -scodec copy Output.mpg Transcode audio and copy video using ffmpeg utility directly. Example transcodes input audio (any format) to (any format) ac3 with bitrate 384k. Video is direct copy. ffmpeg -i Source.mpg -vcodec copy -acodec ac3 -ab 384k Output.mpg |
| Posted by: Dstruct Jun 12 2011, 09:15 AM | ||||
Crash on opening this file:
VirtualDub 1.10.1-test7 + FFInputDriver 0.2 + FFmpeg git-39dbe9b + Windows XP SP3 |
| Posted by: dloneranger Jun 12 2011, 10:57 AM |
| Is that the same file that you reported the directshow plugin wouldn't open either? Possibly a bad (damaged) file???? |
| Posted by: Dstruct Jun 12 2011, 11:16 AM | ||
It is. Windows Media Player 11.0.5721.5280 (Haali splitter + ffdshow tryouts decoder) and Media Player Classic Homecinema 1.5.2.3196 (internal splitter and filters) both can play it back fine! |
| Posted by: dloneranger Jun 12 2011, 12:22 PM |
| MPC, as you say, uses it's own playback mechanism (although you can disable the internal ones if you wish) On win7, so does windows media player Also, they're designed to ignore as many errors as possible - a glitch on screen, or garbled audio etc As long as they can keep playing, they're happy Video editors are usually less tolerant of errors though Does Graphedit or Graphstudio load and play the video correctly? |
| Posted by: -vdub- Jun 12 2011, 02:38 PM |
| Incase you have have email notifications raythe0n. Let us know how it's going, and any new updates for us. Is raythe0n still developing this FFInputDriver be nice to hear if he is |
| Posted by: raythe0n Jun 14 2011, 07:21 PM | ||||||
Hi Dstruct, Can you send me a sample of crashing file? Seems it is a bug in ffmpeg init funcs. Thanks. |
| Posted by: raythe0n Jun 14 2011, 07:40 PM | ||
Hi -vdub- Sorry for delay, I have a little vacation now. The work on next update is still in progress where some new features will be available. ) Thanks. |
| Posted by: -vdub- Jun 14 2011, 09:02 PM |
| Good to hear your back rested and ready for next phase of FFMpeg Input Driver development. Been reading the plugin is been mentioned in various places, on the net. Am waiting for the next release to test the new changes |
| Posted by: Dstruct Jun 15 2011, 10:14 AM | ||
Already deleted. Maybe I can find another one ... |
| Posted by: ale5000 Jun 20 2011, 02:44 PM |
| @raythe0n: Is it possible to load .dll files from a subdirectory (maybe named FFmpeg)? It is more clean like this. Can you please also include version information in the resources of "FFInputDriver.vdplugin"? |
| Posted by: ale5000 Jun 20 2011, 05:32 PM |
| @raythe0n: There is a report of a conflict between FFinputDriver and AVS scripts here => http://forums.virtualdub.org/index.php?act=ST&f=5&t=20155 (third post) |
| Posted by: raythe0n Jun 27 2011, 10:24 AM | ||
Hi ale5000, No problem, I think it really will be cleaner. I've marked it in the todo for the next version. Thanks. |
| Posted by: raythe0n Jun 27 2011, 11:01 AM | ||
FFmpeg by itself is able to open files avs. Directly FFInputDriver does not support this feature while this format is present in the template extension. Please, try to open the script file specialized avisynth plugin. Thanks |
| Posted by: Placio74 Jun 27 2011, 12:04 PM |
| Yes, but also FFInputDriver should not open .avs instead of default AVIFile input driver. .avs files should be opened by default through 'internal' AVIFile input driver - not FFInputDriver. |
| Posted by: Barnister Jul 3 2011, 01:50 PM |
| AWWWWWW YYYEAAAAHHH! I've been waiting a long, long time for VDub to be able to load any other format than avi! Much obliged! |
| Posted by: ale5000 Jul 5 2011, 03:10 AM | ||
It is nice that you added "File Information dialog" but what I was referring was this:
|
| Posted by: raythe0n Jul 7 2011, 02:57 PM | ||||
This refers to information about a media file which opens the plugin. I changed only the VirtualDub structure of the plugin description. Dll file information resource will change later. Thanks for the reminder. ) |
| Posted by: ale5000 Jul 7 2011, 03:55 PM |
| Don't worry, I just wanted to be sure that you didn't misunderstand me. |
| Posted by: Jim_pansen Jul 8 2011, 11:31 AM |
| Hi raythe0n, great plugin, it works fine here! Thank you very very much! Could you add some more supported file format filters in opening window to be able to select files such as *.MTS, *.M2TS, *.TS & *.M2T? I know, it works if I put in *.* & hit ENTER! But it would be fine if these fromats will be present. THX a lot Jim |
| Posted by: Barough Jul 10 2011, 09:40 AM |
| Hi raythe0n Can't understand how i could have missed this plugin earlier. Works really nice on the few files i've tested so far. Keep up to good work. |
| Posted by: raythe0n Jul 11 2011, 03:18 PM |
| Hi Jim_pansen, Hi Barough, Nice to hear! Work in progress ) |
| Posted by: L.H.V.F. Jul 13 2011, 04:52 AM |
| Hi, raythe0n I have tested your latest version Ffmpeg Input Driver, 0.5, and for an video, that I was planing convert for make an DVD, with possible synchrony in audio, that I still have not tested definitively, and your latest version not working as before: Video mentioned: http://www.4shared.com/video/OE0y3D4v/Projeto_de_Apoio_a_Continuidad.html In your earlier version (0.4), the video have run normally in Input Side (had not stayed freezed). Earlier version: http://www.4shared.com/file/fYNgmo6y/FFInputDriver-v04.html Edit: Since the link at http://http:/minus.com is no longer available, the new link that not expires are now at Google Drive: https://docs.google.com/file/d/0B2P9tmmpSwF-WXA3QjdwMXFjcDg/edit Or backup in Google Code, if preferred: http://code.google.com/p/ffinputdriver/downloads/list 4Shared has blocked for only registered users do download of the shared files. Note: I use windows xp SP3, and in "limited user account". This last problem mentioned, have occured also for the fccHandler developer for some time. I suggest that you keep all versions of your plugin stored, for these possible problems. I will test in Administrator account, for check if the problem repeats. I thank your reply. |
| Posted by: raythe0n Jul 14 2011, 11:36 AM | ||
HI L.H.V.F., Unfortunately I was unable to reproduce the problem in terms of video playback on XP SP3. Very slow seek apparently related to not fully support in the used FFMpeg an ASF format (in part of keyframe index table). So here are sought a frame by frame. You can replace the ffmpeg libs in plugins32/ffdlls to the last assembly http://ffmpeg.zeranoe.com/builds/ or from 0.4 release. thx. |
| Posted by: -vdub- Jul 14 2011, 01:13 PM |
| Ray feedback for loading .ts file containing mpeg-2 transport stream and mpeg audio. None seem to load with correct AR into virtualdub. Maybe a little tweak to loads with DAR instaead of PAR could correct this. Maybe then two extended load selections available for PAR and DAR, with DAR default on load ? FFPlay and FFProbe in console show PAR 16:11 DAR 16:9 GSpot SAR 1.222 (11:9) PAR 1.455 (16:11) DAR 1.778 (16:9) Players vlc and mpc both show the above as 16:9 using the DAR for AR Verson this applies to ffinputdriver-v0.5-bin.zip atm |
| Posted by: Barnister Jul 15 2011, 05:24 PM | ||
| What about support for the dreadful .bik format? http://en.wikipedia.org/wiki/Bink_Video , according to wiki
|
| Posted by: Placio74 Jul 16 2011, 05:23 AM |
| Bink Video (.bik) is opened and decoded. http://imageshack.us/photo/my-images/827/ffinputdrivbik.png/ |
| Posted by: Barnister Jul 17 2011, 07:04 AM |
| Awesome! Thanks! I must've been blind. Anyway, can you help me out. Nothing to do with this plugin per se though. I've got ffdshow installed. And I'm trying to open a .bik file with my Media Player Classic. But MPC can't render said file. However opening the file with VDub, with your plugin installed, works just fine. Hasn't your plugin libraries which are also in ffdshow? If not, how do I get it running short of installing codecs from http://www.radgametools.com/ . |
| Posted by: Placio74 Jul 17 2011, 10:38 AM | ||||||
ffdshow is primarily DirectShow decoder (and Bink support is not set in ffdshow). Also decoders isn't enough. Other filter is needed - splitter (simplifying... to handle 'file formats'/containers). You can find RAD Game Tools Splitter (was removed from Media Player Classic due to problems of legality). It's not standalone - binkw32.dll and smackw32.dll are used for decoding.
Not mine, but... (simplifying) yes, however ffdshow uses only some FFmpeg libraries.
Can't. |
| Posted by: raythe0n Jul 17 2011, 05:05 PM | ||
Hi -vdub- Have you tried to set the Aspect Ratio (right click on INPUT view) to the Source from the popup list? It is calculated by PAR and SAR from ffmpeg. Aspect Ratio is often found in the Free Adjust state by default. thx |
| Posted by: Barnister Jul 17 2011, 06:12 PM |
| Thanks, Placio74. |
| Posted by: -vdub- Jul 17 2011, 08:12 PM |
| re-posted below |
| Posted by: Placio74 Jul 17 2011, 11:55 PM |
| I do not think so... DAR is for display; VirtualDub isn't player; are working on 'real' frame size. For what you want, resizing frame size is required (not just change AR). Of course when you change view AR, this has no effect on the processed image. Also can't preserve DAR in AVI (not supported in this container), however can set DAR in some video codecs. |
| Posted by: -vdub- Jul 18 2011, 04:28 AM | ||
| If can be done with ffmpeg then should easily be able to do so with this plugin. FFMpeg Input Driver is built from FFMpeg source codes. As quoted atm
|
| Posted by: -vdub- Aug 1 2011, 08:04 AM | ||
| Ray that is what i tried first. Problem is when need to adjust the resolution the video resize filter then again is PAR. So it is of no use since the actual video is 16:9 DAR. Any possibility for tweak to add this into load extension for PAR and DAR selectable and have default DAR at load. Since incorrect shown in virtualdub means also resize cannot correct AR with to the same resolution of source file 720x576 (full dvd resolution D1). Instead resize tried to give resolution as 720x405 with 16:9. When make load correct using DAR would be able to work with video at source 720x576 16:9 Two clips for download below to show this problem. Load mpg into g-spot also will show PAR and DAR difference, where DAR is correct AR and PAR is incorrect. When video loaded in virtualdub also see your filter uses PAR not DAR. Both the video clips load using DAR 16:9 when viewed with vlc, wmp and mpc video players.
|
| Posted by: Jim_pansen Aug 1 2011, 08:55 AM |
| Hi raythe0n, ffmpeg input driver version 0.5 works really fine, except the following issue: sometimes the first frame appears with the last seen screen or just green. Will test this later more to give you a reproducable scenario! I also have one request more! Can you add the *.mxf file format in format list? As far as I know ffmpeg supports *.mxf containing MPEG, AVCHD & JPEG2000 (not shure)! I really have to say, for me the ffmpeg driver is the most used input filter now! Great work & thank you very much! Cheers Jim |
| Posted by: raythe0n Aug 1 2011, 04:15 PM | ||||
Hi -vdub- I have looked at your files. FFMpeg gives right DAR of video 16:9 (64:45 in variables). I have tried to apply filter Resize with parameters Aspect Ratio 16:9 and "New size" Relative (%) of 142.22 % x 100 % - in this case avi file remains truly PAR 1024x576. Unfortunately VD realization of AVI isnt provide Aspect Ratio storage. Therefore such situations are processed incorrectly. Scaling to DAR using FFMpeg can become other decision. But it would be incorrect approach as VirtualDub allows to reach the same result by means of more advanced tools such as Resize. Thanks for the found lacks! |
| Posted by: raythe0n Aug 1 2011, 04:19 PM | ||
Hello Jim_pansen Please specify in what cases there is a green screen or the previous frame. I will add MXF format in next update. Thanks Jim! |
| Posted by: -vdub- Aug 2 2011, 06:25 AM | ||||||||||
| G-spot actually reports this for these videos i have which are many hundreds or thousands. But do see near same for dvd video i have looked at to see differences. Since bbc captures and broadcasts using dvd D1 sd resolution and AR. DVD and captured vidoes are the same. Also note that other channels i captured from also have the same problem AR for DAR is correct SAR and PAR are not. G-Spot as maybe you have also looked at (mpg as g-spot doesn't show details for .ts yet). Storage Aspect Ratio - SAR 1.250 (5:4) Pixel Aspect Ratio - PAR 1.422 (~10:7) Display Aspect Ratio - DAR 1.778 (16:9) From used ffmpeg tools ouput below i have stripped the ffmpeg internal infos. These FFmpeg tools don't seem to upscale any process to 1024x576 seems only to be using the DAR information.
Resize cannot make the source video AR as loaded by ffmpeg input driver correct to how it should be same as DAR. best it can do is 1024 as you have seen. But that would be upscaling interlaced which is not recommended. Would prefer to load using DAR information so can process the video without up or down scaling, leaving interlace as is. Also the same is happening with retail pal dvd here are deatils that g-spot shows. All play using correct DAR and can be loaded with correct AR with home or pc video players.
Dvd AR info posted to show the video clips i posted are of same dvd D1 specification. So would expect virtualdub or filter to be able to load them correctly. Without up or down scaling the resolution. Also have many other video 720x576 is not the only resolution, but they all are the same the DAR is the correct AR of the video. I don't know if this a decoder filter or virtualdub problem. Only guess decoder filter where virtualdub only shows what the decoder gives it to show ? @ Phaeron ... Maybe Phaeron knows better as to why this happens. Or can say whether fault with virtualdub or is down to the decoder filter itself to load correct AR |
| Posted by: raythe0n Aug 3 2011, 12:58 PM | ||
As the experimental decision I have made ffinputdriver-0.6 which adjusts the frame according to PAR. You can find it in options of opening file. |
| Posted by: L.H.V.F. Aug 4 2011, 05:35 AM |
| Hi, raythe0n Again I am noticing a problem that I have had with your plugin, that have appeared since the version 0.5. The problem, as I have saw, after test with your latest version 0.6 is that the Input Side stayed freezed also for .ogm video files, in limited user account in windows xp SP3. Another thing that I have discovered is that VirtualDub 1.10.1 (pre-release) the problem doesn't occur. But the VirtualDub 1.9.11 is stable version, and also maybe is relationed to file way for plugin, that was rechanged for plugins32, instead of only plugins, this default in latest instable versions. Is not possible to rename for "plugins32" in limited user account. I will test that with the Administrator user account. Is possible create a intermediate file address for plugin detection? I thank reply. |
| Posted by: -vdub- Aug 4 2011, 09:29 AM |
| Hi ray have evaluted the ffmpeg input driver v0.6 filter. These below are needing further work Filters = 1024x576 which is incorrect. Should be showing as video source 720x576 File Information - AR is showing 64:45 it should be 16:9 Video output = 1024x576 (saved without adjustment using source copy should be same as video source 720x576) Checked with filters VDMod_Resize, null transform, resize (the po mans VDMod_Resize) and others Clips used PAR-DAR.mpg and .ts Also have tested with other files to verify the same. Ray i also noticed on File Information the video showing as yuv420p. Should this be instead yuv420i for interlace. The filters don't show video as interlaced, maybe they also use value yuv420p also! The PAR-DAR.mpg plays in virtualdub as interlaced. The source file PAR-DAR.mpg and .ts are interlaced video clips |
| Posted by: raythe0n Aug 6 2011, 10:28 AM | ||
Whether have you the same problems with other input plugins? |
| Posted by: raythe0n Aug 6 2011, 10:43 AM | ||
-vdub- driver v0.6 is rescaling Storage AR to Display AR. Virtual Dub work only with Display AR so you see rescaled frame size in filters. (File Information display original Storage AR). In AVI header the AR field isnt provided therefore processing of images with not square pixel is incorrect. The algorithm without converting frame size is accessible in options of opening of a file. thx. |
| Posted by: -vdub- Aug 6 2011, 03:40 PM |
| Problem i have is with any resize filter how to make it 720x576 [1.778 (16:9)] again for dvd ? 1024x576 or 720x405 is not real dvd spec. Since input is 720x576 [1.778 (16:9)] that is what i really need. Ray maybe this is a virtualdub problem after all and the reason it cannot be done. SAR or PAR values are not correct ones to use. Which of these below has dvd D1 resolution and 16:9 AR par-dar.mpg clip SAR 1.250 (5:4) PAR 1.422 (~10:7) DAR 1.778 (16:9) (sar-par-dar information copied from G-Spot) note also post further up showing dvd titles also are the same. DAR holds the correct resolution and AR values of the video. Ray i am posting here some info and questions for Phaeron when he reads this @ Phaeron maybe can you make virtualdub work using Rays FFmpeg input driver v0.6 filter. Using the clips i have posted links for above. Also any dvd with DAR values of 720x576 [1.778 (16:9)] is exactly the same (any retail dvd will be like this). Use mpeg-2 stream with padding stripped from a dvd video vob. When loading with FFmpeg Input Driver using (FFmpeg Supported Files load option). Then selecting load with extended options. If pixel Aspect Ratio is unselected will load using PAR values and use the same for all in virtualdub (filters, output everything). If keep Pixel Aspect Ratio selected will change to how Ray has described in his last few posts. As you can see from test clip or dvd D1 spec test clip that has DAR values 720x576 [1.778 (16:9)]. There is a problem using either extended options load method with many aspects with virtual dub. Main one been nothing is showing the video values as loaded. Try resize and will see it as either 1024x576 or 720x576 depending on extended option load mode used. Try adjusting resize to be 720x576 [1.778 (16:9)] it cannot be done. Is this a problem with virtualdub that can be fixed or is it the filter at fault and needs fixed ? |
| Posted by: Loadus Sep 8 2011, 09:44 PM |
| Great job on this. I've tested on all the files that I have on my computer atm and they all open (mkv, mov, ts). Very very nice work. |
| Posted by: dann23 Sep 24 2011, 06:52 AM |
| hello, there is no x64 build. do you plan to release one? thank you. |
| Posted by: L.H.V.F. Sep 27 2011, 01:26 AM | ||||
Hi, raythe0n I have now a new computer, and for while, no problem with default folder ("plugins") in the VirtualDub 1.9.11. No problem, yet, for fccHandler plugins. But, in any signal of non-correct functionality, I will rename to "plugins32". Works correctly for a sample that I have ".ogm". Thanks, L.H.V.F. . |
| Posted by: Jim_pansen Dec 4 2011, 10:14 PM |
| Hi raythe0n! Since the actual FFMPEG version includes support for some new codec formats, such as Apple ProRes, could you update the build to be in sync to FFMPEG release? Thanks a lot for your great work! Jim |
| Posted by: Barnister Dec 12 2011, 08:45 PM |
| No more development? It's an awesome plugin! |
| Posted by: L.H.V.F. Dec 28 2011, 02:22 AM |
| Hi, raythe0n I have tested your plugin, and I encounter a problem with 2 samples: http://www.4shared.com/video/M8MP39gx/20101214bl3_1292371138.html http://www.4shared.com/video/MwSlwqZ1/The_Code_Watch_Free_Documentar.html Edit: 4Shared has blocked for only registered users do download of the shared files. Minus.com: The http://minus.com has changed the site policy, and ended leaving unavailable for download all the files that are not images. Edit: Since the link at http://http:/minus.com is no longer available, the new link that not expires are now at Google Drive: 20101214bl3_1292371138.flv : https://docs.google.com/file/d/0B2P9tmmpSwF-Mml3SFY2bHg1dUk/edit?usp=sharing The_Code_Watch_Free_Documentary_Online.flv : https://docs.google.com/file/d/0B2P9tmmpSwF-bjdmY09Wdk5FcDA/edit?usp=sharing The first video, I know that the problem is the video not begin with a keyframe, already corrected in the fccHandler FLV Input plugin. The second in the link list, could be the same problem, but should be more easy to correct. I have tested both with the ffplay, and these can play, first with some difficult in begin, and the second pratically normal. Other thing, is that, in the case of the second video, the error is showed in the first time, and depending of the velocity of command, repeats for both Input and Output panels in the first time. Image of the error exhibited: http://img252.imageshack.us/img252/2514/73errorvdffmpeginputdri.png I have downloaded both videos with Video DownloadHelper http://www.downloadhelper.net/, and both video plays normally with Media Player Classic - Home Cinema (now the first video I can play with Media Player Classic - Home Cinema, but, previously, I only could play with VLC). Version win32 build of the FFmpeg for ffplay utilized for test: http://ffmpeg.zeranoe.com/builds/ I have catch the link of the second video in embedded player (source code of the page), and I have downloaded with http://icyvideo.com/, and the problem persists. I have, also, a sample of a .ts (Transport Stream), of the family codec of Blu-Ray (BDAV, according of MediaInfo), captured in my set-top-box, digital tv signal converter, that I have mentioned in http://forums.virtualdub.org/index.php?act=ST&f=15&t=19755&hl=test%20thread&st=135, and it is recognized as the double of the real framerate (29,970 fps - 54,940 fps) in File Information dialog. I will post also, a sample of another video (.rmvb), that have a frame rate problem (recognizes 12,000 fps, but the video have really 25,000 fps, also according with the MediaInfo), that last version of Ffmpeg CLI recognizes correctly as 25,000 fps. The last mentioned, have a problem with common Video Converters program in my tests (like http://www.freemake.com/free_video_converter/ and Free Studio by http://www.dvdvideosoft.com/free-dvd-video-software.htm), having the same problem of the Ffmpeg Input Driver (recognizes 12,000 fps in a .rmvb video). I had used http://www.erightsoft.com/SUPER.html, for can convert the same for DVD, because DVD have a minimum of 25,000 fps in the structure, using Ffmpeg. Link of the video with framerate Information dialog problem: .rmvb video: http://www.4shared.com/file/VSjA5nJo/Ponto_De_Mutao.html Image of ffplay playing the .rmvb video as "25,000 fps", as the MediaInfo says that the video have: http://s17.postimage.org/c7o1nkbyn/problem_FFmpeg_rmvb.png Obs.: In the case of the .ts video mentioned, I think that the problem need to be corrected in official FFmpeg builds, for the ffplay had indicated wrong framerate, differently than the MediaInfo had indicated. For this, the .ts video I will not still upload, for while a sample, until the problem be corrected in the official builds. One day, I will post a sample for correct both problems (framerate, and instability in VirtualDub). Edit: Now, with the http://ffmpeg.zeranoe.com/builds/ (2012-01-05), I have tested the .ts mentioned video, and the problems persists. Edit2: I have tested also with http://ffmpeg.zeranoe.com/builds/ (2012-01-09), and the problem with .ts mentioned video persists. Edit: The bug related with incorrect framerate recogntion in H.264/AVC streams, was correct and fixed in the http://www.ffmpeg.org/. Link: http://www.ffmpeg.org/trac/ffmpeg/ticket/1065 Note: To Everyone: Since that FFmpeg Input Driver uses FFmpeg libraries for assembly the plugin, for test the updates, of the official builds, of the same, is necessary to test with FFmpeg CLI (http://ffmpeg.zeranoe.com/builds/), for check if some update have corrected a bug or problem related with most recent build, of the FFmpeg Project, comparing it with the Plugin, the FFmpeg Input Driver, since this is assembled with Zeranoe windows Official FFmpeg builds. I thank reply, L.H.V.F. . |
| Posted by: v0lt Jan 4 2012, 09:14 AM |
| @raythe0n "Adjust Pixel Aspect Ratio" option is not saved. It is always enabled. |
| Posted by: raythe0n Jan 12 2012, 11:41 AM | ||
Hi Barnister, In the near future I will update the driver for the new ffmpeg and make x64 version. thank you |
| Posted by: L.H.V.F. Jan 27 2012, 10:57 PM | ||
Hi, raythe0n I have tested the problem in VirtualDub, with the latest version of VirtualDub (http://www.virtualdub.org/beta/VirtualDub-1.10.2-test2.zip), however in the computer mentioned, the problem persists. In another mine computer, I have not the error, under a limited user account, with two videos below: http://img268.imageshack.us/img268/3408/20errorvirtualdubtest2.png http://www.4shared.com/video/M8MP39gx/20101214bl3_1292371138.html http://www.4shared.com/video/MwSlwqZ1/The_Code_Watch_Free_Documentar.html Edit: 4Shared has blocked for only registered users do download of the shared files. The correspondent links are below: Edit: Since the link at http://http:/minus.com is no longer available, the new link that not expires are now at Google Drive: 20101214bl3_1292371138.flv : https://docs.google.com/file/d/0B2P9tmmpSwF-Mml3SFY2bHg1dUk/edit?usp=sharing The_Code_Watch_Free_Documentary_Online.flv : https://docs.google.com/file/d/0B2P9tmmpSwF-bjdmY09Wdk5FcDA/edit?usp=sharing Now, with the latest version of the FFmpeg Input Driver 0.7, the problem in first computer, persists. I have liberated recourses in my xp, for example, burn CDs, and the problem mentioned, continued. The fccHandler FLV Input plugin had the same problem there is some time, and now works until in an computer with had been blocked permissions. In General Administrator, the problem noticed with these videos, doesn't occurs. Could you indicate a solution, or correct this to the program? I will report this for Test Thread, but I believe that the problem should come of the your plugin, because others do not have the same problem. About the .rmvb video the last update already corrected the framerate problem. Edit: About the report in the http://forums.virtualdub.org/index.php?act=ST&f=15&t=20772, phaeron have said that the problem possibly is coming of your plugin. I think, that if the given problem be corrected, in the https://docs.google.com/file/d/0B2P9tmmpSwF-Mml3SFY2bHg1dUk/edit?usp=sharing, other videos with this error, them would be also corrected about the problem with playback. Only the General Administrator can use the plugin without any problem in this mentioned computer. Secondary Administrator also have the problem in this mentioned computer. I have tested also under a limited user account, in the same mentioned computer. Could you analyse this problem? At the moment, I'm not with the computer where the problem no occurs under a limited user account, (this had some updates, as .NET Framework and Visual C++) because of an computer virus problem, for can test with last build of the VirtualDub 1.10.2 (http://www.virtualdub.org/beta/VirtualDub-1.10.2-test3.zip). Edit 2: Now, I have again the computer after an formatation, and with all the test-releases (1.10.2), I have problem only with for the manipulation of the timeline (I can't back for the begin of the timeline, after the video already play), I'm getting these same errors for this video : https://docs.google.com/file/d/0B2P9tmmpSwF-Mml3SFY2bHg1dUk/edit?usp=sharing (20101214bl3_1292371138.flv): Edit 3: Now, I have tested with General Administrator account (in the mentioned computer), and, in this computer more updated, with xp SP3, the problem mentioned repeats in all users with this mentioned video (https://docs.google.com/file/d/0B2P9tmmpSwF-Mml3SFY2bHg1dUk/edit?usp=sharing), testing with the last test-release (http://www.virtualdub.org/beta/VirtualDub-1.10.2-test9.zip). Maybe, a more tolerance will be very usable for video editing, the plugins of the fccHandler accepts without any problem damaged videos in the workaround. http://s10.postimg.org/7ybdn2e15/problem_FLV.png Note: Other people are facing similar problems with some damaged videos or problematic medias, as I have saw and had notified, with principally http://forums.virtualdub.org/index.php?act=ST&f=2&t=21124&hl=flv. 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 http://code.google.com/p/ffinputdriver/downloads/list, in terms of usability, all problems be submitted for analysis in http://www.ffmpeg.org/trac/ffmpeg/timeline, 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 http://www.ffmpeg.org/trac/ffmpeg/timeline 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 reprodution 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). Edit: The bug related with incorrect framerate recogntion in H.264/AVC streams, was correct and fixed in the http://www.ffmpeg.org/. Link: http://www.ffmpeg.org/trac/ffmpeg/ticket/1065 I thank reply, L.H.V.F. . |
| Posted by: Jim_pansen Feb 21 2012, 05:05 PM | ||
I agree, this is a little bit annoying because most footage should be processed as it is! "Adjust pixel aspect ratio" is more a resizing process which results in terrible issues with interlaced footage! It should be disabled by default! Greetz Jim |
| Posted by: v0lt Feb 28 2012, 05:54 AM |
| http://www.mediafire.com/?ecydw4tccxkzlng |
| Posted by: Jim_pansen Feb 28 2012, 09:51 AM | ||
Works fine! Thank you! |
| Posted by: Dstruct Mar 2 2012, 04:11 PM |
| What about making it working with Libav too? http://www.libav.org |
| Posted by: CommonTater May 14 2012, 03:24 AM |
| I've just discovered the ffmpeg input driver and it's great! There is however; one problem I keep running into... IF I open AVI files with AC3 sound with the plugin active... It starts up and appears to load, then soon as I press enter (to preview) it crashes VDub and I have to exit and restart. If I disable the plugin I can load the file and reprocess the sound to stereo as usual. Has anyone devised a workaround for this or am I the only one with the problem? |
| Posted by: levicki May 15 2012, 01:54 PM |
| I just want to chime in on this SAR/PAR/DAR discussion. - Input driver of any kind should hand off the frame to VirtualDub as it is with no rescaling - Regarding what is correct for 720x576 16:9 video: 720 / 576 = 1.25. To arrive at 1.778 (i.e. 16:9) you have to rescale the image on playback by 1.25 / (16 / 9) = 0.703125. Now, you can either divide 720 with 0.703125 and get to 1024 x 576 frame size or multiply 576 with 0.703125 and get 405 which you have to round to be divisible by 2 and get 720 x 404 frame size. The best way to deal with this is to not resize at all, do your video processing, then set adequate bitrate for the resolution, and signal the proper aspect ratio on encoding and in the output container. This way, you allow video player to scale the image on playback and you keep the highest possible vertical resolution. Next option, if you are space/bandwidth limited, is to resize to 720 x 404 frame size (remember that deinterlacing must be done before resizing), do your video processing, then set adequate bitrate for the resolution, and signal the aspect ratio of 1:1 so that video does not get scaled on playback. This allows you to save some bandwidth because you have 172 lines (~362.8KB) per frame less to encode vertically but such video will look worse on high-resolution display than the first one. Obviously, the worst option is to scale up to 1024x576 -- not only this doesn't improve picture quality, but as a matter of fact it increases the file size and decreases quality if you do not allocate considerably more bitrate for encoding. Conclusion: scaling is best left to video player, processing is best done in original resolution. |
| Posted by: -vdub- May 15 2012, 11:12 PM |
| 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. |
| Posted by: mpegclient Jun 3 2012, 05:52 PM |
| 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? |
| Posted by: Abrazo Jun 3 2012, 07:40 PM |
| 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\*.* |
| Posted by: Abrazo Jun 4 2012, 07:22 PM |
| @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" |
| Posted by: AEN007 Jun 11 2012, 03:23 PM |
| 11June2012 ... Seems like this might be the/a proper place to post a request for some way to use FFmpeg for ViDub playback...http://forums.virtualdub.org/index.php?act=ST&f=11&t=20865 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 ... |
| Posted by: L.H.V.F. Oct 15 2012, 12:59 AM | ||
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 http://www.ffmpeg.org/trac/ffmpeg/ticket/1065 (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 http://forums.virtualdub.org/index.php?act=ST&f=7&t=15093, that would be envolved various configurations with x264vfw, and I have not did that yet, and I have used the VirtualDub only with http://codecguide.com/, and LAV codecs and for while, not with the bridges x264vfw, Haali Splitter, and maybe with http://ffdshow-tryout.sourceforge.net/. 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 http://forum.doom9.org/ have to be corrected and updated, even the http://forum.doom9.org/showthread.php?t=125447, with ability for the reconstruction of the tables of broken .ts streams, and I will notify this for the developer, in the http://forum.doom9.org/. Now even in Linux or Mac, will more easy to play video streams with in this H.264 format, including http://www.videolan.org/ (played experimentally with ffh264 decoder in other players, and with an incredible stability viewed by me, only in actual Debian stable in http://www.videolan.org/ media player, same for HD videos with a stuttering video reproduction, and in http://s12.postimage.org/gbo022sod/marilynmonroe.png), http://www.mplayerhq.hu/, http://smplayer.sourceforge.net/, or any other player based in http://ffmpeg.org/, now with better quality in CLI conversions/ video handlings in the http://ffmpeg.org/, 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). http://www.mplayerhq.hu stable Linux release (1.1 - not the http://www.webopedia.com/TERM/S/Subversion.html), 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 http://ffmpeg.org/ in the Bug Tracker. Please, raythe0n, update your plugin for next builds of the latest http://ffmpeg.zeranoe.com/builds/ http://ffmpeg.org/ windows Official builds. Edit: Now, 20 October, 2012, http://ffmpeg.zeranoe.com/builds/ http://ffmpeg.org/ 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 http://ffmpeg.org/ CLI (http://ffmpeg.org/ffplay.html) 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 http://www.videolan.org/ media player could be included with a new version of http://ffmpeg.org/, updated with the Bug Correction from my http://www.ffmpeg.org/trac/ffmpeg/ticket/1065 in http://www.ffmpeg.org/trac/ffmpeg/timeline, whose has fixes for H.264/AVC streams, since now (2.0.5) the base used of the http://ffmpeg.org/ is still developed with the previous versions of http://ffmpeg.org/, meaning that the next version could be with the next FFmpeg http://ffmpeg.org/ 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 http://www.videolan.org/ have not included the mentioned http://www.ffmpeg.org/ http://www.ffmpeg.org/trac/ffmpeg/ticket/1065 in your base used. However, in Linux, you can compile http://www.videolan.org/ with the latest FFmpeg GIT, in the Official http://git.videolan.org. Maybe in the next versions, will come carried with the fixes from the Official http://ffmpeg.org/ Project. Update: Now in 05-05-2013, the http://www.mplayerhq.hu/design7/news.html Community have released a new version update (1.1.1), and as well the http://www.videolan.org/ in June, 13th, 2013, have released a new version, the "2.0.7", but these two Projects are still developed with previous versions of http://www.ffmpeg.org/ and ships with the FFmpeg 0.11, much probably looking for a stability with exaustive tests of previous releases below the 1.0 version. |
| Posted by: -vdub- Dec 22 2012, 06:08 AM |
| 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 |
| Posted by: -vdub- Jan 15 2013, 03:18 PM |
| 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 |
| Posted by: tateu Mar 15 2013, 07:43 PM |
| 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. |
| Posted by: -vdub- Mar 15 2013, 08:28 PM |
| 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 ! |
| Posted by: tateu Mar 15 2013, 08:47 PM |
| 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. |
| Posted by: -vdub- Mar 15 2013, 10:26 PM |
| 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. |
| Posted by: tateu Mar 16 2013, 06:55 AM |
| 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/issues/detail?id=10 (it was a 64 bit int truncation error) and could easily fix issue #9, https://code.google.com/p/ffinputdriver/issues/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. |
| Posted by: -vdub- Mar 17 2013, 03:14 AM |
| 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 |
| Posted by: lwc May 31 2013, 06:39 PM |
| 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? |
| Posted by: travisk Aug 29 2013, 10:08 AM |
| I've continued development of the FFmpeg Input Driver and made a new version 0.8. ChangeLog ======== - Upgraded to current versions of ffmpeg - avcodec-55, avformat-55, avutils-52, swscale-2. - Minimized usage of deprecated features in ffmpeg. - Added support for planar audio formats. - Added support for 32-bit audio samples. - - Fixed a bug that caused garbled audio and occasional crashes near the end of playback. - Split the sources to make them more manageable. - VS2012 project files. Edit [Sep 1 2013] ============ I've uploaded release 0.8.0.2 with following changes - Implemented full support for multichannel. - Fixed a memory leak. - When opening a file with the plugin, if you select "Ask for extened options after this dialog", you get the following options for audio -- Downmix Audio - if selected, downmixes multichannel to stereo (off by default). -- Limit Audio To 16-bit - converts 32-bit audio source to 16-bit samples (off by default). Note that virtualdub has some limitations when dealing with multichannel or 32-bit source audio: - Some audio compression codecs do not accept multichannel or 32-bit samples as input. - Virtualdub menu Audio->Conversion does not know how to mix multichannel down to stereo, or convert 32-bit audio to 16-bit. - Therefore, above options in "Open video file" were implemented to convert to stereo or 16-bit if necessary. Binaries: http://www.mediafire.com/?taotoadatohjx7j Sources: http://www.mediafire.com/?y2lc88b9dtjtv91 Regards. |
| Posted by: Abrazo Aug 29 2013, 07:10 PM |
| Thank you very much for creating an update of this inputdriver. Little correction please : The subfolder "fldlls" needs rename to "ffdlls", if not we get "An exception occurred in module 'KERNELBASE'." |
| Posted by: Abrazo Aug 29 2013, 08:30 PM |
| In the meanwhile I received a private mail that the correction has been made. Tested via new download. Rename to "ffdlls" confirmed by this post. Thanks again. |
| Posted by: travisk Sep 1 2013, 06:15 PM |
| I've uploaded version 0.8.0.2 with some improvements. See my previous post for details. |
| Posted by: raffriff42 Sep 2 2013, 01:08 AM |
| Nice! This has been my favored input method for some time, and now suddenly (AFAIK) there's support for UT Video 4:2:0 codecs! |
| Posted by: travisk Sep 2 2013, 11:55 AM | ||
UT Video is supported by current avcodec. To get a full list of decoders, get the command-line version of ffmpeg from http://ffmpeg.zeranoe.com/builds and run 'ffmpeg -decoders'. Also, when opening a file with the plugin from Virtualdub, going to File->File Information shows you the codec details. |
| Posted by: L.H.V.F. Sep 3 2013, 09:23 PM | ||||||||
Private Messages copies:
Hi to Everyone What you of the Unofficial VirtiualDub Forum thinks about the decision of "@travisk" of not want to go publicly also for development your plugin updates, and not continue the Google Code hosting, or a similar dedicated server as "http://sourceforge.net/", because this last is shared for a Community of developers? The "http://sourceforge.net/projects/fcchandler/" surged because a necessity of storage and keep the latest developments of him unlimitedly, but the FFmpeg Input Driver could use http://sourceforge.net/ for only host the Project, in an organized form, and as was being done by "@raythe0n" developer forum member at the "http://code.google.com/p/ffinputdriver/downloads/list" in keep all the sources and versions stored in the same. In Doom9.org Forum, for example, is recommended in the case of submit a sample, to use http://www.mediafire.com/, but for Project hosting there is some other factors that may interfere in that decision, as the time limit, that one day can expire some source code or version of the plugin. The fccHandler's site also had the lucky of be copied in snapshots of the "http://archive.org/web/web.php", not the same with sharing sites. Reference: http://forum.doom9.org/showthread.php?t=96362 Edit:
In the case of occur a possible regression, or if some sample media not work as before, or for the user be able to download a version of the plugin that works better, would be very usefull if it was mantained all the versions developed including the source codes and these files being thus stored unlimitedly, to one day, if some user need a previous version of the plugin, can download without any limitation in life time of the uploaded files, as dedicated servers for development. Thank reply. Best regards, L.H.V.F. . |
| Posted by: -vdub- Sep 4 2013, 04:40 AM |
| A bit crazy to place the files on any file-server such as Mediafire. When it is not know how many people can download or access Mediafire. For last six or seven years I could not access Mediafire at all, only this summer has it started to work again. Who knows for how long or how many other people were also affected the same over the years. This itself tells you how bad such file-servers can be. All old links I wanted to download years ago none of them work all links are dead Doom9 makes sure members use file-servers in case the file are not GPL or illegal to save their asses. If as Travisk says There is no licensing issue because the dlls I uploaded are from Zeranoe. Then there is no reason not to use Sourceforge.net or similar as a permanent place for the files and source code released. Just as RaytheOn has done when the FFMpeg Input Driver project started using http://code.google.com/p/ffinputdriver/downloads/list as a repository and permanent location for all files |
| Posted by: play32 Sep 24 2013, 09:21 AM |
| travisk, thank you so much for taking over the development of Ffmpeg Input Driver. Since Virtualdub doesn't currently support multichannel or 32-bit audio, I was wondering if you could set the "Downmix Audio" and "Limit Audio To 16-bit" options on by default, or perhaps add a "Save options as default" button in the extended open options dialog (similar to what fcchandler did in revision 4.1 of his http://sourceforge.net/projects/fcchandler/files/Virtualdub%20Mpeg2%20plugin/ -- the plugin reads the settings from the registry), in a future version? It'd greatly help when you use full processing audio mode and you have to process many files with multichannel or 32-bit audio. |
| Posted by: Michaelusa Sep 27 2013, 04:32 AM |
| I'm using the latest versions of both VirtualDub and the ffmpeg input driver plugin and Vdub is crashing at a certain point. Is this the proper sub forum to report the issue or is the Testing / Bug Reports sub forum a more appropriate choice? Regards, Gideon. |
| Posted by: play32 Sep 27 2013, 10:17 AM |
| With 0.8.0.2 on Vdub 1.9.11 (and unlike the WMV plugin by fcchandler that overrides VirtualDub's restriction -- added in v1.3d -- concerning ASF files), we get the "ASF files are not supported" error message when trying to add a ASF/WMV/etc. file IF we use drag/drop OR the regular "open all types" (though *.asf, *.wmv and the likes are on the list). Switching from "open all types" to "FFMpeg supported files" and selecting the file does work, though. |
| Posted by: trodas Oct 9 2013, 11:51 PM |
| Using Windows 2000 SP4 and VirtualDub 1.10.4 I wanted to try out this plugin, because fccHandler MKV plugin fail to detect audio in MKV AC3 file, so the result had no audio data at all... At as soon, as I copy the FFInputDriver.vdplugin into plugins32 directory, with the subdir ffdlls of course, then VirtualDub on start come with this message:  ...and there is no way to choose any FFmpeg plugin from the open box dialoque. Obviously the function is missing on W2k and all I can do is to ask, if that could be added, so the plugin will work on Windows 2000 too. Thanks! (ended up using DirectShow input driver, but it give only half second or so of the audio in the end... ) |
| Posted by: play32 Oct 16 2013, 02:09 AM |
| With 0.8.0.2 on Vdub 1.9.11, we get a "The source video stream uses a compression algorithm which is not compatible with AVI files. Direct stream copy cannot be used with this video stream." error message when trying to use direct stream copy with a file handled by Ffmpeg Input Driver. This isn't the case with fcchandler's plugins, where a direct stream copy is achieved successfully (with FLV, MKV, MOV, WMV, etc.). |
| Posted by: dloneranger Oct 16 2013, 05:07 AM |
| That's correct, it doesn't Fcc handlers plugins decode the container and pass the video/audio streams to virtualdub for decompression, which is why they need vfw codecs to decode as well This and the directshow plugin decode the video/audio by themselves and pass uncompressed video/audio to virtualdub There is no 'video/audio stream' for virtualdub to copy, and if it let you it's just be a huge uncompressed file anyway It's not a bug/problem, it's just how these two plugins work |
| Posted by: play32 Oct 16 2013, 10:29 AM |
| Thanks for the explanation, dloneranger. However, I made a few tests and it is possible, using fcchandler's plugins, and with no VFW codec installed (Virtualdub says "MISSING CODEC"), to use direct stream copy and save a compressed AVI (I tried with a wmv -- which uses a VC-1 codec) and fcchandler's WMV plugin: the resulting file is a perfectly fine AVI, still compressed with the VC-1 and thus with a file size equivalent to the original WMV (in fact, usually Virtualdub shaves off a few bytes: my 216 MiB WMV file resulted in a 207 MiB AVI file). I also tried to save only part of the file (of course, without seeing anything since I had uninstalled the VFW codecs I use), with success. This must be why fcchandler's plugins all have to parse the whole file before loading it into Virtualdub, while the Ffmpeg Input Driver opens it directly. |
| Posted by: dloneranger Oct 16 2013, 01:24 PM |
| Yes, you don't need a codec to just copy the video stream direct - virtualdub just copies it, not caring 'what' is actually in the stream The plugin that does the opening has to be one that returns the video/audio stream back to virtualdub though FccHandlers parse the files mainly for indexing keyframes etc Those plugins parse the file itself and pass the video stream and audio stream onto virtualdub, that then decodes it This plugin and the DirectShow one don't 'have' a video or audio stream to pass to virtualdub All the parsing and decoding is done inside the plugin itself and only an image and a section of sound to go along with it are given to virtualdub It's how these two are designed to work And these two plugins only return uncompressed video to virtualdub, so even if you could copy direct it wouldn't be what you wanted anyway Hope that makes sense to you |
| Posted by: play32 Oct 16 2013, 08:35 PM |
| Yes, it now perfectly makes sense (my bad for not understanding at first the "VFW" Vs. "directshow" plugin difference). Thanks for the thorough explanation. |
| Posted by: Jim_pansen Oct 18 2013, 10:00 PM |
| Great to see the plugin development has been continued. Thank you very much for that. I just have one urgent request: please let the 'Adjust Pixel Aspect Ratio' box unticked by default! Users can run easily into serious issues & may will get distorted or degraded image quality! It is not common to apply resizings without respecting field order. Thanks Jim |
| Posted by: v0lt Nov 2 2013, 06:55 AM |
| http://www.mediafire.com/download/ev5u4d0tom9smel/FFInputDriver_0.8.0.2_nodefaultresize.zip The "Adjust Pixel Aspect Ratio" option is disabled by default. |
| Posted by: Elektrospeedy Nov 2 2013, 08:53 AM |
| Hi, I'm new in this forum, but I use VD since many years to capture and cut my camcorder movies from Hi8 to AVI/Huffyuv. Since five years I've AVCHD-Camcorder. The first time I use a Avisynth-script, AC3-filter and extern DirectShow inputdriver to load my AVCHD video in VD. Then came VD1.9.11 (64) and I found the ffinputdriver-0.7-64 to load AVCHD directly in VD and it works perfectly. In VD 1.10.0 to 1.10.4 (final) crash the program with ffinputdriver-0.7-64 and ffinputdriver-0.8.0.2-64 and I'm back to 1.9.11. Camcorder is Panasonic HDC-SD300, files are *.mts 1920x1080 50i Pal. thank you for answer. p.s. the problem ist the file avcodec-53.dll or avcodec-55.dll |
| Posted by: Abrazo Nov 3 2013, 08:23 PM |
| Your last sentence is probably crucial for the right understanding of your problem. Do you mean that the dll's 'are' or 'are not' the problem. Do you get an error message ? You probably know that the FFInputdriver.vdplugin does use a subfolder called "ffdlls" with four dll-files in it ? |
| Posted by: Elektrospeedy Nov 4 2013, 05:11 PM |
| I got an error message, that means, the problem is avcodec-53.dll, if ffinputdriver-0.7-64, or avcodec-55.dll if ffinputdriver-0.8.0.2-64 is installed in VD 1.10.**. Not so in VD 1.9.11 with ffinputdriver-0.7-64, but I would like to use the new version (1.10.4) of VD. Thanks for the feedback. |
| Posted by: Abrazo Nov 4 2013, 07:27 PM |
| Maybe it would be interesting for the actual developer of the FFMpeg inputdriver plugin that you should publish the exact error message that you receive. Let us hope that Travisk is still following this thread. In the meantime, did you already try the DirectShow inputdriver plugin with VirtualDub 1.10.4 ? With this one, in combination with Haali splitter and FFDShow, I have no trouble with opening Panasonic *.MTS files (1280x720p) in VirtualDub 1.10.4 (Windows 7 Home Edition - 32bit.) Video-codec = H264 Audio-codec = AC3 |
| Posted by: Elektrospeedy Nov 5 2013, 05:55 PM | ||
| Thank you for answer. Before the ffmpeg-input-driver appeared, I've a batch used, this created avs scripts, what you can test it. This used the DirectShow input driver. Drag the directory with the mts-files on this batch and open the created avs.files in this directory with VD. videoread.bat :
Now you can use all avs-files in this directory for VD in batch mode. |
| Posted by: Jim_pansen Nov 5 2013, 09:53 PM | ||
Great, thanks a lot! I will have less mouse clicks now! Jim |
| Posted by: play32 Dec 4 2013, 10:44 AM | ||
Thank you so much for this. If I may ask, could you please also release a 64-bit version of this mod ? I was also wondering if you could release a version with the "Downmix Audio" and "Limit Audio To 16-bit" options set on by default... |
| Posted by: dloneranger Dec 4 2013, 04:49 PM |
| How about 32 and 64 bit versions that store the settings in the registry ? Binary files 32/64 https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/VirtualdubFFMpegPlugin.zip Source https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/VirtualdubFFMpegPluginSource.zip I just whipped those up for you, so they're not from a 3rd party |
| Posted by: play32 Dec 4 2013, 09:38 PM |
| dloneranger, you're simply awesome. Thanks a million. |
| Posted by: v0lt Dec 9 2013, 05:13 PM | ||
This is v0.8.0.2? |
| Posted by: dloneranger Dec 9 2013, 08:26 PM |
| @v0lt I guess if we're going with the naming routines it should be bumped to 0.8.0.3 I'll recompile with the new number [edit] Incremented version number done And I've edited the first page to show all the changelogs v0.8.0.3 Binaries, 32 and 64 bit https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/VirtualdubFFMpegPlugin.zip Source https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/VirtualdubFFMpegPluginSource.zip |
| Posted by: j85 Dec 11 2013, 11:10 AM |
| Thanks for writing this; it's working pretty great! Some issues/feature requests, though... From most to least important: 1. The latest binary distribution (0.8.0.3) is missing the directory containing the ffmpeg libraries! It works (in Windows 7) if I copy them from the FFInputDriver_0.8.0.2_nodefaultresize.zip version. People who don't realize these libraries should be there will not be able to install it. 2. The latest version fails to load in Windows XP (32-bit) with the following error message: VirtualDub.exe - Entry Point Not Found The procedure entry point RegGetValueW could not be located in the dynamic link library ADVAPI32.dll. The previous FFInputDriver_0.8.0.2_nodefaultresize.zip version does work in 32-bit XP. 3. Can you expand the list of supported extensions to better reflect ffmpeg's container support? For example, currently the plugin refuses to open .webm and .ogv files, but it is capable of doing so if you merely change the extension to something on the supported list (such as .mp4 or .mkv). 4. When I open a BT.709 video, the input driver appears to be feeding it to VirtualDub as if it were BT.601. This includes both H.264 content with the color matrix flag set, and H.264 content with the color matrix flag set to unknown but where BT.709 would be the most reasonable guess based on the video resolution. The error in the colors is pretty small, and easily corrected with the "alias format" filter, but it would be more convenient if it got it right automatically. FFprobe reports the color matrix flag when it is set, which makes me think it could be possible for this input driver to get it right, too. |
| Posted by: dloneranger Dec 11 2013, 02:45 PM |
| Try this one https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/VirtualdubFFMpegPlugin.zip Fixed registry reads in XP dlls included .ogm and .webm added 4) could well be possible, but it's not my code, so I haven't even looked at how it works |
| Posted by: raffriff42 Dec 11 2013, 07:46 PM | ||
| > 4. When I open a BT.709 video, the input driver appears to be feeding it to VirtualDub as if it were BT.601. Actually the driver is probably (it varies depending on source format) giving you YV12; Virtualdub http://forums.virtualdub.org/index.php?act=ST&f=15&t=21459&hl=709,or,rec709&st=15#entry93237, including conversion to RGB for display. EDIT sorry to say, the Win XP problem remains.
|
| Posted by: dloneranger Dec 11 2013, 08:25 PM |
| Re xp problem ? I changed to using api calls that should work on Win2000 and newer |
| Posted by: dloneranger Dec 11 2013, 09:15 PM |
| Ok, so tried on a brand new xp VM It hung Replaced the ffdlls with older ones It worked Could you try again, and see if its ok on yours now please ? |
| Posted by: raffriff42 Dec 11 2013, 09:15 PM |
| re-unzipped it and it works fine... sorry, must've had a mix of old and new DLL's? EDIT went back and forth between 0802 and 0803 several times... no problems. Re-downloading now. I had started DebugView before 0803 fixed itself, hoping to catch an error message - just so you know. EDIT still working after more back and forth with new download. Tried in a VM (w/ ver 1.10.2) and it's all good. |
| Posted by: dloneranger Dec 11 2013, 09:30 PM |
| :-) It's those darned nightly ffmpeg builds, they change faster than traffic lights The ones I included at first just didn't like xp at all, so I went back a few versions to find one that did The changelog is just insane over there |
| Posted by: raffriff42 Dec 11 2013, 09:33 PM |
| Thanks for your hard work. I totally love this plugin. |
| Posted by: dloneranger Dec 11 2013, 09:40 PM |
| Yup it's a nice one I had a quick look at the 709 stuff, and this code's using an oldish version of the virtualdub sdk that doesn't have a concept of 709 at all I'd like to update it a bit but I only get to play at being a programmer some evenings and until the end of Jan I'm pretty busy :-( |
| Posted by: -vdub- Dec 11 2013, 09:47 PM |
| Congratulations on becoming the new maintainer for this much used plugin. You couldn't of picked a better plugin to maintain that has many users Is the new version posted above is (v0.8.0.5) ? A few suggestions 1. A good place for your release versions for this plugin is on your sourceforge pages 2. Release notes appended to a release log for each new version released, that is included with each release 3. FFMpeg Input Driver added to your signature that links to your sourceforge pages for them 4. Speed optimizations for encoding for internal filters such as resize if possible |
| Posted by: dloneranger Dec 11 2013, 09:57 PM | ||
What??...????? NNOOOOOOOOOOOOOOOOOOO  Omg, I'm busy that day !!! Yeah,that's it, busy, I'm umm... polishing my bald spot that day |
| Posted by: dloneranger Dec 12 2013, 02:54 PM | ||||
OK, I'll have to take that back It's using the current version of the sdk that doesn't support 709 or many formats at all, just the basics So atm the plugin would have to do it's own bit twiddling to convert 709 to 601... and you'd still have to do some conversion in virtualdub anyway... so I can't really see the point of even reading through the code
Sometimes I'd like to track down the people responsible for the HD specs and beat them around the head with a wet fish |
| Posted by: -vdub- Dec 12 2013, 10:09 PM | ||||
Women say they prefer a bald man, something to sit on ! Understand then you are a busy person. Maybe then bug fixing between other maintainer releases when they are mia. Maybe do the same for fcchandler filters until fcchandler returns (if is able to return) The latest version you posted I have named v0.8.0.5 two version released since v0.8.0.3. FFInputDriver.vdplugin properties states both v0.8.0.2 and v0.8.0.3 confusing). Reason I mention need for a change log that could be maintained here on first thread. That also is added to and included in each release who ever makes a new release. That each release is made with a new url so able to download older releases if needed to. Version numbering and change log so we can keep up with development and able to check it is the latest release that we are using with virtualdub |
| Posted by: dloneranger Dec 13 2013, 06:18 AM |
| Version numbers being mixed was vs2013 doing weird things to me if you change the numbers in a certain sequence... fixed (hopefully) Front page updated with changelog and versions Putting things on sourceforge will have to take a back seat until the weekend - omg two days off work... I can barely remember what that feels like |
| Posted by: dloneranger Dec 13 2013, 02:28 PM |
| OK, looking at the '709 problem' there's a few hiccups 1) virtualdub plugin sdk doesn't have anything but 601 for the yuv formats in it 2) the ffmpeg dlls aren't giving information on the video being anything but 'unspecified' on any I've tested So, the only other thing to do is cheat and lie - not my favourite choice We could just measure the height and if >=720 then return a 709 format to virtualdub That'd mean using an out of spec value for the format and could be unpredictable on earlier versions that don't support those formats It seems to work ok but I wouldn't want to distribute/support such a hacky plugin The other way would be to return a standard yuv format, but internally to ffmpeg plugin do some 709->601 conversion Downside for that is you'd always be using 601 when thats not what you want and you wouldn't know if any conversions had taken place or not Thoughts ? Anyhow, here's a purely test version that will return yuv420 or yuv420-709 if the heights>=720 if you'd like to test it and give feedback https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FFInputDriverTest709.zip |
| Posted by: raffriff42 Dec 13 2013, 06:22 PM | ||
Phaeron, Oct 14, 2009: http://www.virtualdub.org/blog/pivot/entry.php?id=280 |
| Posted by: dloneranger Dec 13 2013, 06:43 PM |
| Until the sdk's sorted out, there's currently no way to officially say 'this video is 709' just one of the formats on the list a few posts back So we can only bodge it one of two ways Return the 709 version that's used in virtualdub itself even though it's breaking the sdk contract Pro the filters etc can see the format as 709 or 601 and do their appropriate thing with it Con unsupported, old versions of virtualdub may barf Do a 709-601 conversion in the plugin itself and return the standard format Pro doesn't break any rules Con you're going to get a 601 version and won't know if it's been converted etc Can't say I'm happy with either choice tbh Pragmatically though, you may just go 'I don't care, as long as I get the right colours - gimme!' Heck, if you wanted to fill up the options dialog, you could make it the users choice for all of that It's still horrible though Trouble with the fourcc system is that you them for all the variants eg yuv420 with full range and 709 |
| Posted by: jpsdr Dec 14 2013, 09:49 AM | ||||
Euh... Sorry, SDK v1.2, in vdplugin.h :
I'm using it for more than a year... 2 years at least i think. |
| Posted by: dloneranger Dec 14 2013, 11:08 AM |
| There's only 1.1 on the sdk page http://www.virtualdub.org/filtersdk.html |
| Posted by: jpsdr Dec 14 2013, 01:30 PM |
| A long time ago, phareon put in a post a link to SDK v1.2, probably around the time he introduced a lot of new features. Don't remember in what part of the forum it was, but most likey in a post in "Fiters Developpement" or "New VirtualDub version". Or... if you want, get it here : http://jpsdr.free.fr/XBMC/VDPluginSDK-1.2.rar |
| Posted by: dloneranger Dec 14 2013, 01:43 PM |
| I thought there was a newer one, and mentioned it in a few posts above where I thought it was using an old one But then when I went to look 1.2 was not listed so I thought I was just crazy/tired and imagined it  Wonder why it's not on the main page? Hope it's a 'forgot' not because of problems Thanks for the link |
| Posted by: jpsdr Dec 14 2013, 02:17 PM |
| I've update all my filters and using it since a long time. But, you may still encounter some of the new formats not totaly correctly handled. The last two issues i've encounter "recently", but solved since, was crash when cropping YV12-BT709, and extended format not handle properly by resize filter. But, if no one begin to use these new formats, they'll somehow never be tested. So, it's probably not because a forget, more likely he wants to put it only when 100% sure that every new things is handle properly, and not issue left. |
| Posted by: dloneranger Dec 14 2013, 02:56 PM |
| Ok, here's a test version if anyone wants to play with it It tries to detect 601/709 and limited/fullrange but not many videos I have actually have them marked at all So, there's also an extra tick box in the options to assume a height>=720 means 709 colourspace See what you think https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FFInputDriverTest709.zip |
| Posted by: j85 Dec 15 2013, 10:01 AM | ||
Thanks for getting the more important stuff fixed! As for
I did some testing of this. When the input is 8-bit 4:2:0 YCbCr and I have the decompression format in the color depth dialog set to "autoselect," it seems to work as advertised for the most part. But if the decompression format is set to RGB24, there is an conversion to RGB using the BT.601 matrix regardless of whether the source is BT.601, BT.709, or unspecified. This is clearly not the right behavior, although of course I don't know if it can be fixed on the plugin end. If it's set to one of the 4:2:0 YCbCr options, it is imported without any conversion. For 10-bit 4:2:0 YCbCr (common in anime fansubs), with the decompression format set to "autoselect," the autoselected format is 24-bit RGB, and it converts using the BT.601 matrix. If the decompression format is set manually to one of the 4:2:0 YCbCr options, there is no conversion other than truncation (or perhaps dithering) to 8 bits. The height>=720 rule behaves similarly when enabled. But there are definitely some situations where this rule shouldn't be applied. For example, if I understand correctly, Theora and VP8 always use the BT.601 matrix, but ffmpeg doesn't report them as being BT.601. So this version of the plugin treats them as BT.709 if they have height>=720. This might be something that would be better fixed in ffmpeg, though, by having it report the matrix when it's knowable based on the codec used. It's also possible to explicitly flag an H.264 video as using the BT.601 color matrix. FFmpeg identifies these as "bt470bg" or "smpte170m" (as color matrix flags, these are equivalent). I haven't seen these in the wild, but you can set the flag with x264's --colormatrix option (-x264opts colormatrix=bt470bg from ffmpeg). This should override the height>=720 rule, but didn't. Another issue separate from the color matrix stuff: Selecting the NV12 decompression format and then opening a video provokes a crash. For example, when I do it with this video: http://upload.wikimedia.org/wikipedia/commons/0/0b/Hargeisa.ogv I get this crash report: http://pastebin.com/YxS6rwyt I don't know if this is a bug in the plugin or in VirtualDub itself. I was able to open one AVI file after selecting NV12 without provoking a crash, but that's hardly conclusive. |
| Posted by: dloneranger Dec 15 2013, 12:55 PM | ||||
| Interesting What I've actually done is modify the detection rules like this
So the only place it actually does any tests or modifications is on the yuv formats Virtualdub doesn't even have a concept of rgb 601 or 709 I'd imagine most of rgb stuff is something the ffmpeg's doing itself as there's nothing else in the plugin that deals with 601/709 By default all yuv is reported to virtualdub as 601 unless ffmpeg say's it's yuv-709 or (yuv and option >=720 ticked) I'll change that to only check the height when the colorspace is unknown Can't do anything about 10bit, as virtualdub doesn't have a 10bit format to use The crash is inside of virtualdub where it's copying a frame There was an nv12 bug reported a while ago and fixed
If you're using a previous version try upgrading, if you're using that or newer could you post a bug report for Phaeron to fix? [edit] Only check the height option if the colorspace is unknown https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FFInputDriverTest709.zip |
| Posted by: dloneranger Dec 17 2013, 06:33 PM |
| 0.8.0.5 on first post Options for 709 colorspace detection by ffmpeg or by height (use extended options on opening to set them, disabled by default) Detection by FFMpeg only works if that information is actually in the video |
| Posted by: raffriff42 Jan 20 2014, 10:38 PM |
| Finally got around to testing version 0.8.0.5 - Checked two videos, identical (720p, x264vfw) except for "--colormatrix" option: - advanced options: autodetect 601/709 on, auto >=720 off - Vdub File Information / Pixel Format always shows "yuv420p (?)" however... - Null Filter (or any YUV filter) shows format as "YUV420" or "YUV420-709" as appropriate. Both preview correctly without AliasFormat filter. Success! - checked again with StaxRip-generated 720p, x264 videos - still OK. - correctly detected UTVideo YUV420 BT.601 (UTY0) vs. YUV420 BT.709 (UTH0) - opens x264vfw & x264 (external) 4:4:4 video correctly as BT.709 (but converts to RGB) - opens ffmpeg-generated x264 & MPEG-4 appropriately (MPEG-4 is always 601 AFAIK) Thank you! One problem came up: crashed on attempting to open Bandicam-generated MJPEG AVI: https://dl.dropboxusercontent.com/u/108089426/Screenshots/crashinfo-raffriff42-bandicam-MJPEG.txt (also crashes on 0.8.0.3) ...also crashed on Virtualdub-generated MJPEG AVI: https://dl.dropboxusercontent.com/u/108089426/Screenshots/crashinfo-raffriff42-vdub-MJPEG.txt Currently uploading sample files... EDIT here's a sample, thanks again EDIT ...removed video |
| Posted by: dloneranger Jan 20 2014, 10:55 PM | ||
| Hopefully I'll have some time to look at it at the weekend a quick browse through shows yuv444 decoding isn't in it's source, should be able to add that easily enough
That'll be me not filling in the right data at a guess If the crashes track back to the ffdshow dlls's were stuffed with fixing that at the moment The latest ffdshow dlls are pretty unstable - there are so many commit/reverts going on that I'm going to wait until a stable one comes out.... |
| Posted by: dloneranger Jan 21 2014, 03:29 AM |
| Quick fix for some crashes https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/ffdshowtest.zip FFMPeg returns some logging information, like you see in the commandline version Turns out that sometimes it gives invalid information that breaks c++ print function in a bad way So the quick fix just ignores all logging info I'll get to the rest when possible Quickfix for testing https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/ffdshowtest.zip |
| Posted by: dloneranger Jan 21 2014, 03:50 AM | ||
This is from two things 1) The file information dialog shows the format of the file as reported by ffdshow 2) Not all formats are allowed by virtualdub, so there's a negotiation between the two to get something allowable Eg, for your sample, the format is AV_PIX_FMT_YUVJ420P and it gets negotiated down to rgb24 for virtualdub There's a section of code that has a lot of if ffmpeg format= x then virtualdub format=y (+some data twiddling) The main obstacle here is pretty simple, lots and lots of typing in as many extra formats as possible Well, that and figuring out if/what the equivalent format is in virtualdub Easy to make mistakes on this.... I 'think' YUVJ420 is 601 full range Y and limited range YV https://wiki.videolan.org/YUV/#I420 (wtf???) |
| Posted by: raffriff42 Jan 21 2014, 10:03 AM | ||||||
Don't recall hearing that before ... no citations on that page ... Take a look at http://www.fourcc.org/fccyvrgb.php; scroll down to "Avery Lee's JFIF Clarification"
And here's the Avisynth wiki: http://avisynth.nl/index.php/Color_conversions#Converting_to_programming_values
|
| Posted by: dloneranger Jan 21 2014, 05:56 PM |
| On that link it says it's that same as i420 (limited y,u,v) but with full range y (sounds weird, and possibly erroneous - full range for all sounds more likely) Try this, added yuv444, yuvj420,yuvj444 F:\SyncServices\Dropbox\Public\MyUploadedStuff\ffdshowtest.zip |
| Posted by: raffriff42 Jan 21 2014, 08:01 PM |
| Tested with color bars (which I had prepared earlier) in a bunch of formats: H.264, MPEG4, VC1, MJPEG, Lagarith*, Huffyyuv*, UTVideo*, Fraps* - MJPEG opens w/o crashing! - 444 source remains 444 - 420 remains 420 (*default decoders convert to RGB) - 709 flag detected correctly, AFAICT - no luma range problems seen, except as noted below I saw a weird low-contrast issue with one MJPEG source, but I would not worry about it because (a) MJPEG has many encoder implementations & they are wildly inconsistent; and (b) with another MJPEG source the situation was reversed - FFinput appeared to be correct and the default appeared low-contrast. (anybody wanting correct color from MJPEG has to experiment, to find the correct decoder for that source) |
| Posted by: dloneranger Jan 21 2014, 08:26 PM |
| Fine, I'll put this up at the weekend as a new version There's a bit of fiddling to do with it first though |
| Posted by: dloneranger Jan 22 2014, 06:25 PM |
| Managed to find some time to finish it off V0.8.0.6 is on first post And now also at https://sourceforge.net/projects/virtualdubffmpeginputplugin/ |
| Posted by: dloneranger Jan 23 2014, 05:25 PM |
| 0.8.0.7 Added option, default video decoding format for unusual formats (There are many formats that virtualdub doesn't handle, now you can choose how they are decoded) Updated ffdlls to 2.1.3 |
| Posted by: raffriff42 Jan 23 2014, 06:56 PM |
| Thanks a lot dloneranger, I gave it a 5 star review on the https://sourceforge.net/projects/virtualdubffmpeginputplugin/. I'm curious - can you give an example of a codec that needs/uses the default format setting? |
| Posted by: dloneranger Jan 23 2014, 07:07 PM |
| Not so much the codec as the format of the data, there's an enormous list of formats it supports (they're in ffmpeg's pixfmt.h scource code) Some include things like AV_PIX_FMT_RGB565BE, ///< packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb), big-endian AV_PIX_FMT_RGB565LE, ///< packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb), little-endian AV_PIX_FMT_RGB555BE, ///< packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), big-endian, most significant bit to 0 AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G 4B(lsb), little-endian, most significant bits to 0 AV_PIX_FMT_YUV420P9BE, ///< planar YUV 4:2:0, 13.5bpp, (1 Cr & Cb sample per 2x2 Y samples), big-endian AV_PIX_FMT_YUV420P10LE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), little-endian AV_PIX_FMT_YUV444P9BE, ///< planar YUV 4:4:4, 27bpp, (1 Cr & Cb sample per 1x1 Y samples), big-endian AV_PIX_FMT_YUV444P9LE, ///< planar YUV 4:4:4, 27bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian AV_PIX_FMT_YUV444P10LE,///< planar YUV 4:4:4, 30bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian AV_PIX_FMT_YUV422P9BE, ///< planar YUV 4:2:2, 18bpp, (1 Cr & Cb sample per 2x1 Y samples), big-endian AV_PIX_FMT_YUVA420P9BE, ///< planar YUV 4:2:0 22.5bpp, (1 Cr & Cb sample per 2x2 Y & A samples), big-endian Basically the plugin asks ffmpeg what the format is, and uses virtualdub's nearest equivalent (assuming I've typed the code in) If it doesn't match anything on my list, it'll use the default format instead and let ffmpeg do the conversion to that format |
| Posted by: raffriff42 Jan 23 2014, 08:06 PM |
| I see - there is no effect on codecs with common 8-bit, 420/422/444/RGB formats. So for example: opening a sample video encoded with pic_fmt=yuv444p10le, File/Info shows "yuv444p10le(?)" but when viewed in the Filter chain, the default format is used (whichever default I have selected), as 10-bit processing is not supported. Right? |
| Posted by: dloneranger Jan 23 2014, 08:15 PM |
| Exactly right The directly supported formats are rgb15/24/32, y8, yuv420/422/410/444/uyuv/yuyv, nv12/21 With the rest using the default |
| Posted by: dloneranger Feb 27 2014, 10:18 PM |
| V0.8.0.8 Updated to use ffdlls 2.1.4 Sorry about the delay on that, didn't notice ffmpeg had a new stable release out - feel free to pm me if I'm late on the next stable release |
| Posted by: travisk Feb 28 2014, 03:18 PM |
| Any changes in the source code? I updated the ffmpeg include and lib files for build. The stuff in audioconvert.h is deprecated. I was planning to look into eliminating it and send it to you, but haven't gotten around to it |
| Posted by: dloneranger Feb 28 2014, 03:20 PM |
| From 807 to 808 not much, just some test code (explaining variables so I could see what was happening while debugging) Most of the stuff that changed up to 807 is just improved interfacing with virtualdub, a bit of zeroing out some buffers and the testing code Most of the ffmpeg stuff is left alone as I haven't had time to see how it all fits together or read much of ffmpegs docs I had a play with getting it seek better, and it'd seek to a frame like a demon but then wouldn't advance frame at a time (garbled display) so I'll leave that alone I think...... If you want to play with it - here's a problem scenario Create a file with pcm audio (I used h264 for the video), turn audio display on in virtualdub, load the video Now, there can be huge pauses when seeking - not often, but they're about 4 seconds long when they happen And moving back/forward frame by frame at the end of the video can cause problems (I'm a spare time hobbyist with little c++ skill, so that's a project for whenever I can find a lot of spare time or anyone else gets to look at it) |
| Posted by: dloneranger Feb 28 2014, 03:36 PM | ||||
A quick note from a PM
(I'll assume that decodes was meant instead of encodes) Reply
If anyone else sees FFMpeg plugin being slow, I'd be interested in any data you have |
| Posted by: dloneranger Mar 1 2014, 08:17 PM |
| Looks like comparing ffmpeg plugin and quicktime plugin gives a slight encoding performance penalty when using the ffmpeg plugin Possibly something to do with the much higher IO % in virtualdub when using ffmpeg plugin, but not sure about that |
| Posted by: dloneranger Mar 2 2014, 05:26 PM |
| V0809 Fixes a silly bug I made in 0807 when downsampling audio |
| Posted by: Abrazo Mar 2 2014, 09:02 PM |
| @dloneranger Thanks a lot for all your effort to make this inputdriver better with every next release. This time, I can not get to download your newest version 0.8.0.9 ... Can you please verify the hyperlinks ? http://sourceforge.net/projects/virtualdubffmpeginputplugin/files/V0809/ |
| Posted by: dloneranger Mar 2 2014, 09:48 PM |
| sourceforge takes a while for it to populate to all mirrors you might see a little clock icon on the far right of the filename, that means it hasn't reached the mirror site you're on (does seem to be a bit slow today though) |
| Posted by: dloneranger Mar 3 2014, 12:12 AM |
| Sourceforge is full of 'why are my downloads not showing up?' on the support pages So, just for now https://dl.dropboxusercontent.com/u/17024916/FFMpegPlugin_0809.zip |
| Posted by: Abrazo Mar 3 2014, 05:47 PM |
| Thanks for the additional information. This monday-evening - 18:30 - the files were available via Sourceforge. - - - - Unfortunately with this version, when opening whatever MP4 or FLV (not yet tried with other video container formats), VirtualDub 1.10.5 (build 35512) crashes with following crashinfo (extract): Crash reason: Illegal instruction Crash context: An instruction not supported by the CPU was executed in module 'FFInputDriver'. Version 0808 does not have this problem. For me it seems to be the FFInputDriver.vdplugin file that causes the problem (not the dll's). (I have a Windows 7 - 32-bit Home Edition) |
| Posted by: dloneranger Mar 3 2014, 06:15 PM |
| I'll put fixed ones up (I used the AVX build by mistake) |
| Posted by: Gral Mar 3 2014, 07:23 PM |
| I had the same problem. It's OK now, with new build. Thank you. |
| Posted by: Abrazo Mar 3 2014, 07:42 PM |
| I can also confirm that the problem has been resolved now - no more crash on opening MP4 or FLV files with the 32-bit version of the 0809 release. (I see that the 64-bit version has not been recompiled... maybe that AVX problem was not in there ?) Also confusing behaviour on those Sourceforge servers... Via the Summary-tab and the darkgreen Download-button I got the most recent and correct(ed) version (3 March 2014). Via the Files-tab and subfolder V0809, I still get the older version (2 March 2014). Thanks and kind regards. |
| Posted by: Gral Mar 3 2014, 07:50 PM |
| I never use http for download, only for browse and locate. When i know or expect new version of any software on sourceforge just go directly to ftp mirror (Heanet in Ireland is one of the best) - ftp://ftp.heanet.ie/mirrors/download.sourceforge.net/pub/sourceforge/v/vi/virtualdubffmpeginputplugin/ in this case. |
| Posted by: dloneranger Mar 3 2014, 08:02 PM | ||
Yeah - I put the wrong 32bit version in and the 64bit one was fine Sourceforge is just weird at times What I'll do from now on is put the version number as part of the zip file name so it's obvious what your getting You know what? I'm going to blame Twin Peaks Amazon's prime has just added video in the UK and I was having a Twin Peaks weekend at the same time as doing this |
| Posted by: Abrazo Mar 3 2014, 08:09 PM |
| Thanks for your information Gral. Myself, I would never had gone that way to look for a copy ... I just guess, next time I am going to wait a bit longer before downloading... Also thanks to dloneranger... Good idea to put the version number into the ZIP's filename. |
| Posted by: DarrellS Mar 7 2014, 06:13 PM |
| 32bit still broken. Crashes Virtualdub. Trying to open HEVC in Virtualdub. Was sure that I used to be able to open HEVC months ago without using any plugins. Not sure why I'm having problems now. |
| Posted by: dloneranger Mar 7 2014, 07:38 PM |
| A lot depends on the ffdlls and the file itself - all the actual decoding etc is done by that (in a crash I'll usually see avutil-52 as the cause) If I run that crashing file through ffmpeg's standalone .exe I'll normally see a lot of errors thrown up FFMpeg itself is still very much a work in progress and improving as time goes by - two steps forwards (and one back sometimes) I'll keep it updated, and you can always download the latest dlls from their site H265 is one area that's still very new I don't get any problem with a sample at http://labs.divx.com/node/127909 though |
| Posted by: raffriff42 Mar 7 2014, 07:42 PM |
| Hi DarrellS, did you delete the old plugins32\ffdlls folder before unzipping? |
| Posted by: dloneranger Mar 15 2014, 05:55 PM |
| Upgraded next version to https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/V0810%20beta/ and moved to sourceforge page It's not quite 810 yet as there are a few other little things I want to do to it first Changes Problem that caused incomplete video frames to be returned to virtualdub (garbled moving blocks) especially after seeking Problem with some formats (eg mkv) when seeking back to the start of the file Problem with the wrong video frame being shown (repeatedly) after turning audio display off and back on (Some of these problems only happen with virtualdub's audio display turned on) |
| Posted by: dloneranger Mar 17 2014, 04:53 PM |
| My sucky script created the wrong folder names in the .zip files Instead of ffdlls, the folders were called dlls32 or dlls64 They can be renamed back to ffdlls (delete any old ffdlls folder) So beta2 is just a name change in the .zip files and you don't need to download it again |
| Posted by: dloneranger Mar 17 2014, 10:42 PM |
| https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/V0810%20beta/ Better handling of audio/video just before the end of the file |
| Posted by: dloneranger Mar 19 2014, 04:37 PM |
| V0810 added |
| Posted by: dloneranger Mar 20 2014, 08:17 PM |
| v0.8.1.1 [20 Mar 2014] After a night sleep, thought of a better way to get the very end frames of the source file |
| Posted by: -vdub- Mar 21 2014, 06:18 PM |
| As many people need guidance to unpack this to the correct PluginsXX directory. Using a 7z archive that has a script to copy only the files and folders. This would not be an installer only a copy script that 7z executes so nothing is added to the registry install/uninstall locations etc. I have seen this type of 7z install script with other softwares that works as needed Anyone needing to still unpack as normally should be able to do so if correct 7z archive type is used (unknown which supports script and normal unpack). Although I have seen this type of 7z archive done with a few other softwares previously. 7z could also be used to compress the FFMpeg archive further using settings such as 7z | Ultra | LZMA (or better) As long as script can detect what version Virtualdub is been unpacked to. maybe it checks for PluginsXX folder name to do so. Better if is done automatically after Virtualdub folder destination is chosen for when many Virtualdub are at the same location, example SameDrive:\ABC\Virtualdub1\ SameDrive:\ABC\Virtualdub2\ SameDrive:\ABC\Virtualdub3\ note: Unknown if 7zip still has this type of archive PluginsXX - Plugins, Plugins32 or Plugins64 |
| Posted by: dloneranger Mar 21 2014, 06:48 PM |
| There's a setup installer on the sourceforge page now that lets you pick a folder with virtualdub in (32 or 64 bit) and puts the right files in the right place |
| Posted by: dloneranger Mar 21 2014, 11:56 PM |
| 0812 beta Fixes frame stepping backward Better seeking https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/V0812%20beta1/ I'd appreciate any comments better/worse thanks - pm's best, to avoid clogging the thread (there are so many formats etc out there I can't check if making one thing better has broken a different thing) Confirmed problems H265 - trouble with seeking AVCHD - trouble with seeking I can't see anything obvious the plugins doing wrong - possibly it's ffmpeg's dlls, as ffmpeg.exe also has trouble with the samples I've tested |
| Posted by: moody2014 Mar 25 2014, 10:54 PM | ||
Crash opening any video file with latest 64 bit Zeranoe FFmpeg dll's Build (avcodec-55 version 55.54.100.0, avformat-55 v.55.35.100.0, avutil-52 v.52.69.100.0 and swscale-2 v.2.5.102.0) |
| Posted by: dloneranger Mar 25 2014, 11:20 PM |
| You can't just swap dll's If the dll's conventions have changes at all (between the ones it comes with and the ones your trying) the plugin has to be recompiled with the new sdk files that match the new dlls |
| Posted by: moody2014 Mar 25 2014, 11:28 PM | ||
Ok, it means I can not update only the dll without recompile the all plugin, it's a pity. I have updated until git-63dbba6 (23-Mar-2014) and work great only not work with new git-c25d2cd thanks |
| Posted by: dloneranger Mar 25 2014, 11:41 PM |
| ffmpeg 2.2.0 should be on Zeranoes' site soon I'll recompile with that when it's out, as I'd prefer to include a stable build that a dev one |
| Posted by: dloneranger Mar 26 2014, 05:07 PM |
| 0812 test version https://dl.dropboxusercontent.com/u/17024916/ffmpeg_test_razon.zip razon sent me some test files that didn't seek properly (AVCHD) once you had seeked, you couldn't step forwards/backwards properly and all you got were keyframes every so often hopefully this fixes it, but it's a bit slower at seeking if this problem happens the decodable keyframes are so far apart you have to keep seeking further and further back until you get something you can work with and then scoot forwards to the right place should solve other problems where the pts's and dts's are really out of whack if this doesn't break anything for anyone the new version will be out when zeranoe updates the ffdlls to v2.2.0 |
| Posted by: moody2014 Mar 27 2014, 03:57 PM |
| Thanks, now work with lastest git |
| Posted by: dloneranger Mar 27 2014, 04:10 PM |
| It's using ffmpeg-20140326-git-c05065a so it should be ok to swap them around for a while |
| Posted by: dloneranger Mar 28 2014, 03:10 PM |
| v0.8.1.2 [28 Mar 2014] Fixed some formats with large keyframe intervals or weird pts/dts had trouble seeking and would only show keyframes after the first seek Extra seeking further back to find a valid keyframe is done now if an initial seek fails Some seeking optimizations Updated FFMpeg dlls to 27/03/2014 - v2.2.0 isn't on zeranoes site, so these are the first dlls after v2.2.0 |
| Posted by: dloneranger Mar 29 2014, 11:49 AM |
| v0.8.1.3 [29 Mar 2014] Fix another edge case with seeking getting stuck on a frame The day after 0.8.1.2 was released, a failing file was sent to me Sample .mts file had packets needed for a pts time scattered throughout the file It's fixed now, but a file like that can be slow to decode as it was made so you have to read almost the entire file to get 1 frame of video Fix doesn't affect speed of decoding files that aren't like that (I think it's a test sample made to try and break decoders) On the other hand FFMpeg plugin is more robust at decoding bizarre .mts files |
| Posted by: jpsdr Mar 30 2014, 10:48 AM | ||
| I am, and have since a long time been able to directly open mkv in VDub. I don't realy remember when it begun to be possible. I think it's probably the DShowInputDriver.vdplugin, but i'm not sure. When i open an mkv, i can see the icons of ffdshow and haali's spliter. I've tried, out of curiosity, your pluggin. So, i copied the files in pluggin directory of VDub, open an mkv file i've just opened before to check it worked fine, and when trying to open the file, VDub (version 1.10.5-test1) crashed :
It's not a big deal for me. I notify you of this in case it's a pluggin bug, and not an incompatibility setup from my configuration. ------------------------ mod note - snipped out long crash report and filenames |
| Posted by: dloneranger Mar 30 2014, 01:20 PM |
| Could be an FFMpeg bug Virtualdub's calling VDGetPluginInfo, then a dll is being loaded (or attempted) and it goes boom I'll pm you about additional information Quick check though When moving the plugin into virtualdubs plugins folder The .vdplugin file goes there, and then the ffdlls folder is also copied there, overwriting any old ones eg virtualdub\virtualdub.exe virtualdub\plugins32\ffinputdriver.vdplugin virtualdub\plugins32\ffdlls\avcodec-55.dll virtualdub\plugins32\ffdlls\avformat-55.dll virtualdub\plugins32\ffdlls\avutil-52.dll virtualdub\plugins32\ffdlls\swscale-2.dll With mkv's there are three ways to open them fcchandlers mkv plugin ->requires vfw and acm codecs directshow plugin-> requires directshow codecs and a splitter (haali or lav) ffmpegplugin->requires nothing I use all three (daily, if just for testing) and they have their pros/cons So far they've all been fairly crash proof But they can fail in their own special way if fed damaged files (general error types) fcchandlers->virtualdub crashes directshow->audio suddenly stops before end of file ffmpeg->stops in infinite loop or avutil-52.dll crashes Out of those three the one that's most common is directshow suddenly losing the audio On the whole though it's pretty rare to see an actual crash |
| Posted by: dloneranger Mar 30 2014, 04:14 PM |
| @jpsdr I've found something that may be the same file you have - does it start with people on a train? File size 779 MB (817,459,917 bytes), MD5hash 3D9A65F8D957192D9E07B16E4A1732BB If so, it loads fine It did prompt me to add an test/messagebox for missing dll's in the next version though |
| Posted by: jpsdr Mar 31 2014, 08:08 AM |
| When there is several pluggins which can handle mkv, when i open the mkv only with File->Open Video File, and selection file is on "all" (and "ask for extended options" not checked), which one wins ? |
| Posted by: dloneranger Mar 31 2014, 10:30 AM |
| Normally the most format specific one Each plug in has a chance to check the filename and examine the start/end of the the file It reports back a value to virtualdub about how well the file matches what it can decode for both of those (the filename match being less important) Specific plugins usually report a higher score than general purpose ones eg the mkv plugin scores itself highly for mkv's and zero for everything else It's a score that could be included in the options though |
| Posted by: dloneranger Mar 31 2014, 09:37 PM |
| For anyone with Xp, it looks like the ffdlls are a bit broken at the moment (requiring vista+) http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1889 "the procedure entry point InitializeConditionVariable could not be located in the dynamic link library KERNEL32.dll" These ones work on xp http://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-20140330-git-c01ddf8-win32-shared.7z |
| Posted by: jpsdr Mar 31 2014, 10:25 PM |
| Tested beta 3, worked fine. Thanks. |
| Posted by: dloneranger Apr 1 2014, 02:07 PM |
| https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/V0814%20beta4/ beta 1 Error dialog box if dll's are missing Timeout for decoding video/audio frames of 2 minutes so job's don't get stuck on queue Reporting decoding errors back to virtualdub Report error on discontinuity Larger maximum index size for seeking beta 2 Fixed bug in beta 1 that totally broke seeking with some formats - my bad Better seeking to first frame, fixed bug that was only obvious because of previous problem - serendipity! beta 3 Replaced dll's with ones that work on windows xp beta 4 More accurate discontinuity handling, will backtrack further through the file before giving up on a missing frame Remembers how far it's previously had to backtrack when seeking and uses that (up to a max of 256 frames, then starts dynamically seeking backwards) These two reduce discontinuity errors while improving seek times, betas 1,2 and 3 were a bit too eager to report problems |
| Posted by: Abrazo Apr 1 2014, 07:40 PM |
| Thanks for all your hard work dloneranger ! Just a little remark : please take care for the file-"Path" into your ZIP files ... It has become ffmpegplugin\win32\ffdlls instead of plugins32\ffdlls (similar note for 64-bit) this can mislead the newbies ... |
| Posted by: dloneranger Apr 1 2014, 07:42 PM | ||
Doh, glad someone's keeping me on my toes I'm so used to working with the compilers paths, I didn't notice |
| Posted by: dloneranger Apr 5 2014, 08:38 PM |
| https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/V0814%20beta6/ beta 1 Error dialog box if dll's are missing Timeout for decoding video/audio frames of 2 minutes so job's don't get stuck on queue Reporting decoding errors back to virtualdub Report error on discontinuity Larger maximum index size for seeking beta 2 Fixed bug in beta 1 that totally broke seeking with some formats - my bad Better seeking to first frame, fixed bug that was only obvious because of previous problem - serendipity! beta 3 Replaced dll's with ones that work on windows xp beta 4 More accurate discontinuity handling, will backtrack further through the file before giving up on a missing frame Remembers how far it's previously had to backtrack when seeking and uses that (up to a max of 256 frames, then starts dynamically seeking backwards) These two reduce discontinuity errors while improving seek times, betas 1,2 and 3 were a bit too eager to report problems beta 5 Better use of keyframes when seeking Avoid some seeking when the frame you're seeking to is so close we may as well just wind forwards Fixed an edge case seeking problem when moving to a keyframe and then going back 1 frame Error handling option for allowing an occasional missing frame - replaced by the last good frame eg this will allow frames 1,2,3,4,5,bad,7,8,9,10 -> 1,2,3,4,5,5,7,8,9,10 without stopping an encode beta 6 Better fps detection Some better handling of decoding errors Modified missing frame detection a bit to reduce false error detection |
| Posted by: -vdub- Apr 11 2014, 01:21 AM |
| Is there any code change that can be made so it works like FFmpeg binaries. So it doesn't decode everything but looks at Virtualdub more when user need Direct Audio or Video copy it does just that I noticed but unable to find comment you made about having a user selectable setting so each video loaded can be loaded always using FFmpeg Driver. This is good and would help to make Virtualdub vastly improved. But still the need for Direct Copy is needed as FFmpeg binaries can do and like other Virtualdub Plugins able to do That said if able to make adjustments so Direct Copy is able to be done and Able to set FFmpeg Driver to load all Videos. The other problem disappear such as we can again use Batch Wizard to multi load videos that are not avi. More process more use for Virtualdub more users for Virtualdub If not could you or someone have a look at fcchandlers Qucktime code. To see if is possible to add code so it has option load all videos as default. Since fcchandlers Quicktime already has the ability to Direct Copy Video and Audio |
| Posted by: dloneranger Apr 11 2014, 05:12 AM |
| Direct stream copy mode -> I have no idea how you would get that to work with the way this plugin works, directshow plugin also doesn't do direct stream copy mode I was going to see if I could make the priority of this plugin user selectable, but the sdk doesn't let you It's a hard-coded number that virtualdub reads from the plugin, so you can't change it as you like There's another priority system, but that's a no go as well, as first you have to supply a byte sequence that virtualdub matches in the source file (also hard coded into the plugin file) (virtualdub does those checks without loading the plugin, so you don't even get a chance to be involved) |
| Posted by: -vdub- Apr 11 2014, 07:58 PM |
| Direct Copy I guess those that can do so outweighs the very few those that can't. What I meant was as other plugins are able to and that FFmpeg binaries are able to then would follow that FFmpeg Input Driver should also able to do Direct Copy video and audio. It what will make this plugin as good as those that can Direct Copy so then we will be looking to Phaeron to add this below As many plugins will never be updated but still can be used. If Phaeron were to add a user selectable setting to always load files with a plugin the user need always to load files with |
| Posted by: dloneranger Apr 11 2014, 08:12 PM |
| Probably, but I have no idea how you would get that to work Your quite welcome to find programmers to make this plugin work better :-) |
| Posted by: jpsdr Apr 12 2014, 12:28 PM |
| Noticed a little annoying issue on x64 version (not checked on x86). When pluggin is installed, .avs file are not listed anymore in the first "all" provided by VDub... |
| Posted by: dloneranger Apr 12 2014, 12:54 PM |
| I can add .avs to ffmpeg's list for the next version - it's not specifically in there Avs should be in virtualdub's list already though... What can happen is that the open dialog just takes ages to show everything, I tested a folder with 2000+ files in, and .avs appeared, but it did require a wait as the list was populated |
| Posted by: -vdub- Apr 12 2014, 11:07 PM |
| What If Phaeron changed Virtualdub code to allow selecting Driver plugins to load with. Then selecting for example FFmpeg Input Driver from then always has priority over decoders, that is until set to default again or another decoder I think that would be the only way to make Virtualdub easier for more people to look at using it. Though FFmpeg would still have no Direct Copy and maybe in time if possible it would also change so it has the ability. Easy then to set and forget load everything using FFmpeg Input Driver to do what you need to do with Virtualdub |
| Posted by: jpsdr Apr 13 2014, 09:22 AM |
| There was only 10 files in the directory. Seems to be specific with XP64... occurs with both 32bits and 64bits version of VDub. But it's not occuring apparently with XP32. So, don't bother, if everything is working fine on your side with most recent OS in both 32&64. |
| Posted by: dloneranger Apr 20 2014, 04:54 PM |
| v0814 released |
| Posted by: dloneranger May 26 2014, 03:53 PM |
| v0815 released updated to use ffmpeg 2.2.2 |
| Posted by: moody2014 May 26 2014, 10:19 PM | ||
with v0815 I can not open some mkv files using last git of ffmpeg. but with version 0814 and last ffmeg git i can open files that do not open with version 0815. When try open with version 0815 shows no error message, just loading for long time. |
| Posted by: dloneranger May 26 2014, 10:32 PM |
| Haven't had a problem myself Could be a problem with 2.2.2 dlls from http://ffmpeg.zeranoe.com/builds/, but that's down to ffmpeg's site and would have to wait for a new release to see if it's fixed Previous versions are kept available because ffmpeg is so flaky - they fix 2 things and break 1 ;-) (the changelog on their site is scary.....) |
| Posted by: moody2014 May 26 2014, 11:34 PM | ||
use 0814 with last git had to add the swresample-0.dll to ffdlls folder for open any file. but even if they do this in 0815 not work |
| Posted by: dloneranger May 27 2014, 04:42 AM |
| You can't just mix and match the dlls like that Only from the same version branch, and not even that's guaranteed without a recompile of the plugin The releases newer than the one supplied with the plugin may work, until any calling conventions or types change Just plonking different dlls in is more a case of luck, and your own support problem |
| Posted by: moody2014 May 27 2014, 04:58 PM | ||
I know that but in this case work |
| Posted by: dloneranger Jul 17 2014, 03:54 PM |
| V0816 released Update ffdlls to 2.3.0 FFDlls now need swresample-0.dll also swresample-0.dll added |
| Posted by: moody2014 Aug 10 2014, 03:09 PM | ||
@dloneranger Can you update to the new avcodec-56.dll, avformat-56.dll, avutil-54.dll, and swscale-3.dll? thanks |
| Posted by: dloneranger Aug 10 2014, 03:47 PM |
| Updating to 2.3.1's on my list of possible things to do, but there's nothing in the 2.3.0 -> 2.3.1 changes should make any difference for users (doesn't improve/change decoding in any way) I don't update to the daily releases, only the stable releases So those dlls may appear in the 2.3.2 release |
| Posted by: moody2014 Aug 10 2014, 03:52 PM | ||
Ok, thank you  |
| Posted by: Malaksbane Aug 20 2014, 07:31 PM |
| Audio is out of sync with HDV video. I don't remember this being the case with earlier versions, but I did use another workflow back when. Footage is recorded with Sony Z5 with MRC1K Compact Flash recorder, PAL HDV 25p (MPEG-2 TS) in M2T container. I don't have a short sample video handy, it mostly is (painfully) obvious with interviews and those typically aren't short. |
| Posted by: dloneranger Aug 20 2014, 07:43 PM |
| Try comparing with an older version using the same file to compare, as the timestamps of audio/video are inside the file itself |
| Posted by: dloneranger Aug 20 2014, 07:59 PM |
| Also, if the audio is out by a fixed amount you can just move it around to sync it up I like to use the audio display (on the view menu) With that shown you can hold shift or ctrl (can;t remember which) and drag the audio left/right with the mouse This works best on things like doors slamming etc where you can match the audio spike to the video |
| Posted by: Malaksbane Aug 20 2014, 08:13 PM |
| 8.02 and 7.32 are also both off. FFplay (august 2013) seems to play in-sync ok, as is Sony Vegas Also, with the latest FFInput driver often place the displayed video is shifted down, though processing seems ok, at least processing MXF files, which show the same vertical offset, seemed ok (result is not shifted) I can not just move and shift it audio around, first off all, you will never get it right trying to sync audio on talking heads and secondly, every shoot has dozens of files and I just don't want to sync them all manually, or at least the ones with audio. I've used Avisynth with ffms2 some years ago but couldn't find a binary on their site and the ones I (should) have are quite dated. |
| Posted by: dloneranger Aug 20 2014, 08:30 PM |
| I don't have (or have heard of) any of those problems, you're the first to mention them so I don't have anything else to suggest offhand (virtualdub asks for the audio and video separately so the plugin can't do any sync management either) Try converting to vid+pcm audio using ffmpeg? |
| Posted by: raffriff42 Aug 20 2014, 08:37 PM | ||
Dunno why you are mentioning FFMS2, but the latest downloads are at https://github.com/FFMS/ffms2/releases |
| Posted by: Malaksbane Aug 20 2014, 08:41 PM |
| Same result ... audio is lagging just a bit. I think it's lagging, while it's immediately clear it is out of sync it's always hard to say if audio is ahead or behind video Some files have it really bad, I have found one with audio obviously out-of-sync, but it is 235 Mb. Another one is 45 Mb. It's dutch, btw. |
| Posted by: Malaksbane Aug 20 2014, 08:53 PM | ||||
Yeah, found them from Avisynth. I mention them because using avisynth would be ( a ) another input option and ( b ) it is another ffmpeg input driver and this could be a problem with more recent ffmpeg builds. |
| Posted by: dloneranger Aug 20 2014, 09:06 PM |
| You might want to test if it's just virtualdub lagging on playback It's not optimized as a player and the plugin does a LOT of seeking around the file Is a recompressed file out of sync in a normal player? |
| Posted by: Malaksbane Aug 20 2014, 09:22 PM |
| Good suggestion. I re-saved as avi in virtualdub and overlayed the result with the original in Vegas. Doing so the transcoded AVI is frame exact in video, but the audio is lagging when compared to the original. When I delay the M2T by 8 frames (25p) they match, so it would appear that the ffmpeg/virtualdub route delays the audio by 8 frames. PS. I am going to bed so I can't follow up suggestions until tomorrow. |
| Posted by: dloneranger Aug 20 2014, 09:32 PM |
| Quick fix is to move the audio by -320ms (if I worked that out right 1000/25*8 ??? ) on the audio menu->interleaving I've pm'd you as well |
| Posted by: dloneranger Aug 21 2014, 07:00 PM |
| OK, a test version for you to play with https://dl.dropboxusercontent.com/u/17024916/FFMPegTest_Malaksbane.zip I think I fixed a stepping forward and then rewind error + an error a few frames after doing that The test vid Malaksbane provided has timestamps earlier than the declared start timestamp in the video stream In effect the video goes something like frame 0,-2,-1,1,2 and then when seeking back to the start we count back like 2,1,-1 and stop there as -1 < the time we wanted, then it winds forward until a complete frame is assembled and goes "oops you wanted frame 0 and this is frame 11" Hopefully this is fixed and hasn't broken any other formats The sync problem looks awkward - it's basically due to preroll The start time of the video and the start time of the audio are different So I'll need to work out a way of offsetting the audio and video times This is a pain, as in the code the audio and video doesn't actually have anything to do with each other atm I'll have to check that it won't break other formats that don't have 'connected' timestamps as well (Basically a bigger job and much testing needed) |
| Posted by: dloneranger Aug 30 2014, 12:05 PM |
| v0.8.1.7 released, see first post for details |
| Posted by: moody2014 Aug 30 2014, 02:03 PM | ||
thanks for new version |
| Posted by: Abrazo Aug 30 2014, 06:07 PM |
| @dloneranger many thanks from me too! Small remark: Would it be usefull to update the version history on the Wiki-tab (make it the same content as the readme.txt in the package) ? http://sourceforge.net/p/virtualdubffmpeginputplugin/wiki/Home/ (it stopped at version 0.8.1.3) Regards. |
| Posted by: dloneranger Aug 30 2014, 06:29 PM |
| Done - there are so many places that need updating each time, I forgot about that one -> getting old and senile |
| Posted by: Abrazo Aug 30 2014, 07:25 PM |
| Thanks again man... and thinking that you are getting old and senile... please forget that ! |
| Posted by: sumdumguy Sep 8 2014, 03:49 AM |
| I am trying to read some mj2 files created in Matlab but VDub gives me the "unknown or unsupported file type" error. I thought ffmpeg was cool with motion jpeg 2000? |
| Posted by: sumdumguy Sep 8 2014, 04:11 AM |
| Never mind. PEBCAK. (Old VDub version). |
| Posted by: ekt Nov 3 2014, 02:45 PM |
| @dloneranger i've just added a ticket on sourceforge, with a problematic .mp4 attached on that file virtualdub keeps complaining about 'discontinuity reading frame' (i saw that message as a fixed issue on the previous version) the file has been generated by a nexus4 (android google phone) I hope is the correct way to interact with you cheers |
| Posted by: dloneranger Nov 3 2014, 11:48 PM |
| Answered on sourceforge as well It gives a 90000 fps rate which is weird The discontinuity problem is something that happens when virtualdub asks for a frame The plugin has to work out what the timestamp for that frame is and then search the file for a frame that contains that timestamp (ie the requested timestamp >= the frames tiemstamp and < frames timestamp+length) When a frame can't be found for that then there's a discontinuity error This could be a problem with the plugin or the file (it may even be related to the incorrect fps that's reported) I can't just use 'the next frame' in the file as virtualdub requests frames out of order I'll have to work out a better way to use the nearest frame if possible as long as it doesn't break anything else - it may let damaged files with formats that don't record a timestamp in each frame get through without reporting errors and silently destroying file sync in the process Try using fccHandlers Quicktime plugin instead, that may be your best bet for now (links in my sig) At the moment I don't think I'll have time to look at the problem for ages - works insane atm, 7am start and 11pm finish is going carry on for the rest of the month |
| Posted by: VDMuser Nov 16 2014, 04:07 PM |
| Hello, I initially found this very helpful plugin when I had problems with an mkv file. The audio track was "wanering off" during playback of the resulting avi file. When opened using ffmpeg the video was a few frames longer and finally the audio track matched the video track. Well now I have again a problem with another mkv file. But this time it's the ffmpeg plugin that causes this problem. During at least the second pass (I didn't notice that behaviour during the first one) the cpu load was 100% from time to time for a while with some intermitting spikes down to maybe 20% - and that was no matter where I put the slide control in the status window. That was the first clue. The second clue was that the audio track had some serious dull clicks from time to time. Those were gone when I transcoded the audio track seperately (but also using vd and ffmpeg filter). But the third and final "clue", the actual problem, was/is that at several positions during the video (track) the video juddered. First I thought it might be a problem with the player. But examined the avi file using vd I realised that the file itself was "juddery", i.e. some frames were doubled but at the same time the respective following frame was missing. Is there anything I can do (or check) to avoid this odd behaviour? I have never seen this before but I can't say with absolute certainty that it hasn't happened before - maybe I just missed it up until now. Unfortunately, open the file without ffmpeg results in a video that's a few frames shorter. Otherwise it would be great, because transcoding without having opened the file using ffmpeg filter the frame doubling and dropping does not occur. But then I can't transcode the audio... So, right now I'm in a vicious circle... Thank you very much for any helpful hint. Mike. |
| Posted by: dloneranger Nov 16 2014, 06:26 PM |
| The ffmpeg plugin relies on timecodes in the video/audio stream to decide which frame to return If they're a bit weird you could get this effect I guess Sometimes the ffmpeg dll's are themselves fixed in a later release, but I've no time to look/update it at all Not sure how long this will be for, but it's been double shifts at work for months now |
| Posted by: VDMuser Nov 16 2014, 06:55 PM |
| Thanks for the reply. No worries about a quick fix. For now I'm ok knowing that my problem at least can be something other than my fault and might be fixed someday. :-) |
| Posted by: shekh Nov 18 2014, 11:08 AM |
| Hello, I think I may eventually attempt to debug this specific problem: When I move frame slider too fast and the codec does not catch up, it will take unreasonable amount of time before the last frame is presented. Something like 20 sec while decoding single arbitrary frame is about 0.5 sec. Also it may end up in not complete frame (broken some blocks). If this was investigated before I`d like to hear what to look at. |
| Posted by: dloneranger Nov 18 2014, 01:42 PM |
| You're waiting for the disk activity probably, if you move the slider about, a lot of positions have to be decoded even if you don't see them because you've already moved the slider further by then (most newer codecs encode in a manner that's extremely hostile to seeking) To decode 1 specific frame, you have to backtrack to the nearest previous keyframe (time+disk consuming) and then construct the frames along the way until you get to the one you want (time+disk consuming) This keeps repeating until you finish moving the slider (tip - if you hold down the shift key while moving the slider virtualdub will only go to the keyframes which is usually faster) Decoding/seeking can be slower now than it used to be as I had to add extra 'hunt around to find all the bits you need' code in for problem files that scatter parts of their video a long way apart from each other Re 'broken' frames appearing, yeah that can happen The ffmpeg dlls only say if the decode worked or failed If there's a fail, you'll get a discontinuity message in virtualdubs status bar If the dlls say the decode was ok but it looks corrupted then it's probably a bug in ffmpeg dlls, that may be fixed in a future update of them - normally it's just a transient problem and shouldn't appear when just moving +1 frame all the time ie encoding or playing |
| Posted by: shekh Nov 18 2014, 04:00 PM | ||
| Looks like the problem is here: VDFFVideoSource.cpp
This results in reentry to VDFFVideoSource::Read with all disasters. I simply commented these lines and plugin became completely workable. |
| Posted by: dloneranger Nov 18 2014, 07:27 PM |
| thanks I'll take a look and add to next version (as you may have noticed from the source code it's fairly horrible) [edit] Ah, so that's supposed to stop virtualdub hanging with a ghosted window Deleting it returns the nasty side effect of the app appearing to have hung/crashed if decoding is taking a long time Just changing it to this keeps the message pump active, so no ghosting of the window MSG stMsg; ::PeekMessage(&stMsg, NULL, WM_NULL, WM_NULL, PM_REMOVE); (long wmv files with the audio window showing can take forever to seek towards the end of the file) |
| Posted by: shekh Nov 21 2014, 10:53 AM |
| Found another problem involving B-frames: When a movie begins with B-frames they are thrown away until first I-frame and there is same amount of duplicate frames at the end. For example B0 B0 I2 B3 B4 becomes I2 B3 B4 B4 B4 Hope this helps. |
| Posted by: Testerhood Dec 11 2014, 12:34 AM |
| I have just registered to say a HUGE THANKS! I had a nasty problem where I wanted to reedit a video in another program without losing quality which just supports avi files, and my video was a mp4 file with H.264 codec. Converting into an avi file with Avidemux without recoding hasn't helped, the application crashed (BB Flashback, with K-Lite codec pack installed). And Virtualdub was no option for me, because it doesn't support mp4 files... I thought that, until now! This plugin package is just awesome. I was able to convert the mp4 video absolutely fine with the Lagarith Lossless Codec into an avi video, and this had fixed my issue. I had found the plugin package with Google by coincidence by typing "Virtualdub ffmpeg". Please take this a note that there are quite some people out there and (hopefully) very thankful for this! Thank you again! |
| Posted by: -vdub- Dec 11 2014, 11:25 PM |
| The Google site is ancient it is no longer maintained there Virtualdub FFMpeg Input Plugin https://sourceforge.net/projects/virtualdubffmpeginputplugin/ is where you will find the latest build versions |
| Posted by: dloneranger Dec 16 2014, 07:43 PM |
| 0.8.1.8 Update ffdlls to 2.5.1 Fix leading b-frame problem (there are some other minor changes, but nothing interesting) |
| Posted by: dloneranger Dec 17 2014, 05:58 PM |
| Test version of 0819 g This one attempts to fix some audio problems+other minor stuff Fix error where a frame might be dropped and not returned to virtualdub after decoding Fix correct value of 8bit blank audio Fix correct sync of audio at the start when it's been offset eg If the source videos audio has previously been delayed to sync with the vid then the previous version incorrectly ignored that delay (e) fix really small offsets as well Fix possible crash at end of video Fix repeat last frame at end of video where b-frames cause a shift at the start Fix strange error where you'd get 90000fps for the source file (thanks shek for finding it) Fix error that would slow decoding enormously if frame rates were being altered eg by IVTC Fix seek error in some formats where seeking on the audio failed Fix seek to first frame for some formats https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20819.zip See how it goes Here's a test clip of something with delayed audio for comparison https://dl.dropboxusercontent.com/u/17024916/Bad%20test%20videos/Sync%20Test%201.mkv The audio should start about 22 seconds in [edit] beta version g 20/12/2014 |
| Posted by: Abrazo Dec 20 2014, 11:12 AM |
| A quick test shows (mostly ?) a difference of one frame when opening an flv with the flv plugin towards opening it with the ffmpeg plugin. Opening a webm file is possible, but from the moment that the play button is clicked, there is a message "error while seeking file". > example: http://video.webmfiles.org/elephants-dream.webm (when i compare with version 08.1.8, i see that these two things were already there...) |
| Posted by: dloneranger Dec 20 2014, 01:34 PM |
| Do you have a link for .flv that shows an issue ATM the versions from 818 are trying to show what should really be at a specific frame (like a player) than 'just the frame for that number' eg the plugins that just show a green frame at the start (or show 2+ of the same frame because it's repeating the first real one) To do that you have to find the first actually decodable frame, and then shift everything left/right by by that many frames Plus, now the audio is trying to be decoded at the correct time for the video as well There's a sequence of numbers that starts with 2 b-frames that should show the problem that this should solve https://dl.dropboxusercontent.com/u/17024916/Bad%20test%20videos/TestSequenceOfNumbers%20B8.avi Correctly decoded the frames should read 0,1,2,3 etc Incorrectly they can be garbage,garbage,0,1,2,3 ATM the flv may have 1 b-frame at the start (and it's being shifted 1 frame to correct for that), or my maths is wrong somewhere and I'm shifting it by mistake ------------- the .webm sample won't seek for the audio ffdlls av_seek_frame returns -1 (error) when seeking in it Shek's plugin seems to cope properly though I'll have to see what the two are doing differently |
| Posted by: dloneranger Dec 20 2014, 03:52 PM |
| beta 0819 f available above for testing Fix audio seek in the sample webm file provided by Abrazo |
| Posted by: Abrazo Dec 20 2014, 09:32 PM |
| Thanks @dloneranger. 1) The issue with playing *.webm files has been fixed (FFInputDriver.vdplugin - 20/12/2014 - 15:48). sample > http://video.webmfiles.org/elephants-dream.webm 2) Concerning opening *.flv files, it seems that FFMpeg (dloneranger), FFMpeg2 (shekh) and DirectShow (phaeron) inputdriver plugins are all giving an equal number of frames in the first sample file below (= 423). Only FLV inputdriver plugin (fcchandler) shows one frame more (= 424). (Tested with the most recent version of each plugin, that is available today.) So, I suppose the first three must be right... sample > http://www.mediacollege.com/video-gallery/testclips/20051210-w50s.flv Eventhough, in the next sample file, the numbers are different: - FFMpeg = 7995 - FFMpeg2 = 7994 - DirectShow = 8009 (ffdshow video decoder) / 8011 (Microsoft DTV-DVD video decoder) - FLV = 7994 (x264vfw) > http://www.fullimpactwebdesign.com/solutions/websiteDevelopment/videoGalleryWebsites/files/bobDylanTangledUpInBlue.flv NOTES: Please do not consider the sample webm and flv as "my" files. I only post hyperlinks to files that I find on the internet, and that can serve for testing. Neither consider my testing for personal interests, I only try to contribute for testing and so supporting the development of the plugins. So, it is in favor for everyone who will use them. In either case, many thanks to dloneranger and shekh, who are investing their time and knowledge into this !! |
| Posted by: dloneranger Dec 20 2014, 10:51 PM |
| I have many sample files from all sorts of places - they're just example files that show problems, content is fairly unimportant Out of all of them I'd say the FLV plugin probably gets the closest in terms of frame count etc, but also counts undecodable frames (the ones that can just show as green or black at the beginning of the video) Anyhow..... Looks like some file formats don't like being seeked to before the first frame's timecode, and fail instead of just going to the first frame This made the first frame of the vid be something like frame 42 819 g is up for testing Fix seek to first frame for some formats ps the bob dylan vid made me think I'd really screwed up somewhere and was repeating the last frame too long very sneaky having a totally still part at the end - it was only the fade out that stopped me looking for an error in the code ;-) |
| Posted by: shekh Dec 21 2014, 12:54 PM | ||||
This is rounding vs truncation. The problem is neither is correct. We calculate number given the frame rate but the only real way is to read the stream begin to end and count them. For some reason ffmpeg library here gives frame rate of 29.97 but observing time stamps I see it is more like exactly 30. Given 30 fps we would calculate 8002 / 8003 Again, with that wrong fps we cannot determine frame numbers so the timeline is full of errors. Tried this:
ffmpeg asked me to use that bsf switch because "h264 stream is malformed" Now it has valid index of 7994 frames, fps 29.97 The index really helps in frame accurate seeking etc. The big problem is: For use in VD reliably the source MUST have full index. Otherwise there is no control what can happen. If there was an option for ffmpeg "give me index or die" I would set it. Unfortunately the index is not even public feature so we use it at our risk. I think there is the only possible way to fix it: build index ourself when opening the file. |
| Posted by: ALbino Dec 21 2014, 06:49 PM |
| FWIW, I'm pretty sure fccHandler's MPEG-2 plugin builds it's own index to achieve frame accuracy. |
| Posted by: Abrazo Dec 21 2014, 09:04 PM |
| Thanks @shekh for the explanation. So, if the number of frames is being "estimated" at the time of opening the file, then what happens when we navigate through the file ? With other words: if there are less or more frames then estimated, then accordingly: are there duplicates being made or frames being dropped ? Finally, the best solution would be to parse the whole file (like it is done by the MPEG-2 plugin ?), but the disavantage of that is that it will take more time to open a file (especially "long" files). So, the question to make an index, would be rather an option to put in the "Ask for extended options ..." after the "Open video file"-dialogbox, like it has been done in the MPEG-2 plugin. @ALbino The "Create an index file" is not ON by default in the MPEG-2 plugin, but you can activate it when checking "Ask for extended options". Regards. |
| Posted by: shekh Dec 21 2014, 10:48 PM |
| Yes VD does not allow to change timeline on the go. Last frames are dropped if estimate is low and duplicated if high (in my implementation). For indexing there is implementation challenge as well. fccHandlers plugins have full format reading (at least what I saw in quicktime plugin). This isnt easy coding but then it allows to build index etc. With ffmpeg there is a challenge: will it really work. |
| Posted by: ALbino Dec 21 2014, 11:50 PM | ||
Interesting, I've never done that before until now. That is a different behavior than I normally do, but I don't see a difference in the actual results themselves other than it creates an .midx file. It still says "Parsing interleaved MPEG-2" file, still scrolls the same, and still reports the same frames. What's the benefit of creating the index then? |
| Posted by: dloneranger Dec 22 2014, 12:17 AM |
| Second time you load it, the scanned index is just read from disk - faster -------- We're way off topic now though, so can you take anything else to a different thread, thanks |
| Posted by: jpsdr Dec 25 2014, 02:02 PM |
| Merry Christmas, and thanks for your work. Just to notify of one thing : If i install this pluggin, avs scripts become horribly slow. Is there some kind of configuration to do to solve this ? |
| Posted by: dloneranger Dec 25 2014, 02:27 PM |
| You can select "AVIFile input driver (compat.) (*.avs, *.vdr, *.vpy)" from the files of type dropdown on the open video dialog Then it should use virtualdub's own .avs handler -- This plugin's already at the lowest priority to try avoiding being the default for anything, but looks like virtualdub's own .avs handler is lowest as well |
| Posted by: shekh Dec 25 2014, 02:32 PM |
| If you set it to -4 it will be lower than avs |
| Posted by: dloneranger Dec 25 2014, 09:26 PM |
| Might be better idea to just remove .avs from the list of files handled by the plugin, as it needs avisynth installed and vdub handles that extension anyway |
| Posted by: shekh Dec 25 2014, 09:53 PM |
| I think it does not work Extensions are ignored All you have is 64 bytes to decide |
| Posted by: dloneranger Dec 25 2014, 10:22 PM |
| Works fine here This plugin doesn't use byte sequence signatures, but does use filename pattern signatures Remove the |*.avs| from the extension list and .avs files are ignored as an autodetection match |
| Posted by: dloneranger Dec 26 2014, 03:23 PM |
| The previous info about the test version of the next release is so far above, here's a recap of the latest Test version 0819 (beta h) https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20819.zip Fix very old audio positioning bug Fix filling mono empty data with correct value Fix try to correct sync of audio at the start when it's been offset Fix crash at end of video Fix repeat last frame at end of video where b-frames cause a shift at the start Fix strange error where you'd get 90000fps for the source file (thanks shek for finding it) Fix error that would slow decoding if frame rates were being altered eg by IVTC Fix seek error in some formats where seeking on the audio failed Fix seek to first frame for some formats added in beta g Remove .avs from default file extensions, avisynth already needs to be installed and virtualdub already handles .avs better Fix setting first starting frame to only skip leading undecodable b-frames as there are vids with no I-frames (just P&B) added in beta h Improve audio seeking in some formats |
| Posted by: dloneranger Dec 29 2014, 07:41 PM |
| Version 0819 released on SourceForge https://sourceforge.net/projects/virtualdubffmpeginputplugin/files/ |
| Posted by: moody2014 Dec 31 2014, 12:09 AM | ||
Thank you, happy new year |
| Posted by: dloneranger Jan 1 2015, 08:55 PM |
| V0.8.2.0 beta a https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20820.zip Finally found a tiny little bug that was causing huge problems in all sorts of places Fix bug where seeking would get stuck in a loop silly mistake, a - should have been a + so instead of moving back trying to find the frame it moved forwards couldn't find the frame and would try again, still moving forwards..... oops Fix once the above bug was fixed, retrying could be imbroved so it quits faster on undecodable video frames with the bug above, the code for undecodable frames was called for valid frames Fix with both of those fixed, some nasty peekmessage code could be stripped out it was only there to keep the buttons working in virtualdub when the plugin was stuck in a loop so you could move to a different frame and get it out of the loop it was a very nasty hack!! ...especially if you had the audio display on and all because of a minus sign..... sigh..... So, see how this one does - seems a lot snappier on scrubbing Any feedback appreciated |
| Posted by: ALbino Jan 2 2015, 01:15 AM |
| Scrubs much better for me, thanks! |
| Posted by: dloneranger Jan 15 2015, 02:19 PM |
| V0.8.2.0 beta b https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20820.zip Fixed bug where a video with a thumbnail image in it would give bad fps and the same frame all the way through I've reworked some of the video code to make it understandable and try to improve seeking But as always, this may have accidentally created problems somewhere else It seems fairly solid with everything I have to thrown at it so far though You will notice a longer delay on opening some videos That's because some videos don't have any information in them to seek to a frame I've put some code in to pre-scan any videos like that so the ffmpeg dll's can build up an index of keyframes In the final version I'll put a tick box in the options so you can turn it on/off Con: may make some files take a little while to load Pro: once loaded they should seek faster |
| Posted by: -vdub- Jan 16 2015, 11:32 AM |
| Suggest an option for full scan which may help processing those videos that are bad etc for example when Virtualdub users write... When encoding a video why does Virtualdub keep stopping or crashing Which can be many replies but eventually we consider it bad. So also suggest an option to output a list in window or log file (window and log better) as each bad error is found in the video. So they can then stop it scan to end of the video. An option to be selectable in the options (No Full Scan Video For Errors) as default. Maybe reports the same for audio, does audio stop or crash video encoding often ! |
| Posted by: Abrazo Jan 16 2015, 01:22 PM |
| @dloneranger I did a test with the latest version, by opening multiple kinds of containerformats and playing them, and I see no immediate (new) problem. Concerning the TestStuttering.avi video in thread http://forums.virtualdub.org/index.php?act=ST&f=4&t=23160 , I see a difference in behaviour from the FFInputdriver.vdplugin (dd. 01/01/2015) towards the last one (dd. 15/01/2015). When lowering the "Video buffering" towards "4" (= lowest possible) and then playing that file with 01/01/2015-plugin it plays quasi fluently. When playing it with 15/01/2015-plugin it keeps stuttering. Two questions: 1) in this newest version, do I understand it correct, that the option to build an index is actually ON by design ? If so, I would expect that it should rather avoid stuttering. 2) would it be possible to indicate the (test-)version number of the FFMpeg-plugin via the File Information dialogbox ? Actually I know which version I am working with, thanks to the "modification date" of the *.vdplugin, but clear indications always help (not only for me). Many thanks, as always. |
| Posted by: dloneranger Jan 16 2015, 02:35 PM |
| Thanks for the feedback The trouble with playback is down to seeking in the file, virtualdub reads some audio and goes past the video frame you need Then the video has to reseek back a bit to get the right frame to continue from It's worse with the audio display on as virtualdub gets audio from a while before to after the frame you're on I'm looking at this atm, but that file plays perfectly here no matter what buffering I set so it's difficult to see when changes affect playback Here's how I prioritize what the plugin does gets the correct frame even with vfr files make sure the audio is in sync with the video handles errors as well as possible decode speed seek speed playback 1) the index building is on by default atm, but the index is only used for seeking though a video eg dragging the slider about FFMpeg dll's kind of work like this... some formats like wmv may only have an index of 2 places throughout the video, but as you move through the video more index points are added as you get to them this can give long delays when you move about the video, so the pre-scan quickly seeks through the file allowing the FFMpeg dll's to build their index after that, seeking will be quicker, but the trade off is that you have to scan through first 2) these are just work in progress tests so I haven't added any indication of their status at all - if I have time I'll look at it, but tbh it'll probably be after the next release is done |
| Posted by: shekh Jan 16 2015, 03:08 PM |
| Btw I have example with AVC audio where some packets are decoded with silence *if* this is the first packet after seeking. This may add up to audio stuttering problem if there is unwanted seeking during playback. Found no explanation for this (maybe its good idea to post a bug to ffmpeg?). I sort of fixed it in my plugin by seeking 1000 samples before required position, hoping 1000 is big enough. |
| Posted by: dloneranger Jan 16 2015, 03:54 PM |
| V0.8.2.0 beta c https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20820.zip Trying to cut down on possibly unneeded seeks to try and make playing a video in virtualdub smoother (less stuttering on audio) |
| Posted by: dloneranger Jan 17 2015, 12:40 PM |
| V0.8.2.0 beta d https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20820.zip Added beta numbers to dialogs Update ffdlls to 2.5.3 Fix sometimes a missing frame in the video would manage to skip the code that reports an error to virtualdub then virtualdub would try again, looping until it was killed Fix bug not clearing buffers after a seek sometimes, could get a nasty loop towards the end of the file where the EOF packet was kept after a seek. Every frame after that would be seen as the EOF |
| Posted by: Abrazo Jan 17 2015, 09:31 PM |
| In this version (V0.8.2.0 beta d) the audio stuttering has indeed been resolved (when video buffering is set to the minimum). Not to disappoint you, but I do not (yet) see an indication of the betaversion (not in the extended options, nor in the File information panel). If this is too difficult to realise, then please don't, because you will have to remove it once the version is final. The modification date (and hour) of the *.vdplugin should be sufficient to verify the exact version. Regards and thanks. |
| Posted by: dloneranger Jan 17 2015, 11:03 PM |
| No, that's just me being a moron I did all the code and then forgot to set the letter ;-) I've updated the file |
| Posted by: dloneranger Jan 19 2015, 02:09 PM |
| V0.8.2.0 beta e https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20820.zip Modify try to sync video/audio better when first frames are unshown BFrames |
| Posted by: dloneranger Jan 20 2015, 08:27 PM |
| V0820 released, see first post or in my sig |
| Posted by: v0lt Jan 23 2015, 07:20 AM |
| I see high CPU load in v0.8.2.0 compared to v0.8.0.7 and v0.8.1.9 when playing in the VD. The first playback is going well. But after repeated and rewind so slow. |
| Posted by: dloneranger Jan 23 2015, 12:46 PM |
| Not sure what you're on about? Playing a 1080p file in virtualdub I see the same cpu% with 820 and 819 I see no different in anything when playing, rewinding and repeating Running a video analysis pass on a 1080P file 820 takes 4:57 819 takes 5:05 Practically the same Cpu was also roughly the same There is a cpu spike when first loading a file in 820 is you have 'prescan unindexed files' ticked in the options With that ticked - if the video doesn't have a useful index of seekable points in it, the plugin will scan through to build one It only does it when loading a file though (it's an option to try and make seeking faster when you're editing the file) |
| Posted by: dloneranger Jan 23 2015, 07:20 PM |
| V0.8.2.1 beta a https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20821.zip Workaround seeking in wmv files could be way off - ask ffdlls for frame 2000 and actually get 2500..sigh... So, doing a quicker backtrack to somewhere valid (wmv and ffdlls just don't mix well) |
| Posted by: v0lt Jan 24 2015, 06:28 AM |
| http://www.mediafire.com/view/3b3dziqob3x56rc/Hilary.0000.ts Try playback whith seeking in v0.8.2.0. Also in this file, the sound disappeared. On the other files, playback may be normal, until to search on the timeline. |
| Posted by: dloneranger Jan 24 2015, 09:48 AM | ||
| @v0lt Looked at that file The difference is because it has multiple streams in it (4) With the changes I made to fix files with thumbnail streams in them you also get all audio streams returned to virtualdub now Change the audio stream to stream 2 and you'll get your audio Here's the problem with the audio According to the timestamps... The two audio streams start at different times one has the same start time as the video and the other starts 10 hours before So, what happens is the the sync video/audio sees the difference and corrects the times internally This shifts the audio of the one that has timestamps starting ten hours earlier way off to the left and leaves the rest blank The other is ok and plays fine You could turn this off by disabling sync video/audio - but then any video with an actual delayed audio track would be out of sync with the video I'll have a better look and see if there's anything about the first audio stream that I can use to discard it if it's invalid Maybe, I'll skip correcting the time if it's an insane value like here (10 hours) You may have noticed that you now get the HD video in this file though and not the 704x480 one you got before This may be why you have trouble playing it, it plays fine here but I have a lot of cpu to throw at it? Here's its MediaInfo report of video/audio streams
|
| Posted by: jpsdr Jan 24 2015, 10:45 AM |
| I don't know where it came from, it's from very long TV broadcast history, but there is several time start standard. The most often used are 1h or 10h. Meaning, the timestart of the video can be 1h or 10h. For exemple, Cinemacraft encoder, when you specificaly target DVD compliancy, create MPEG2 stream with a video starting at 1h (and so if you want to add subtitles, you have to add 1h to all your timings). So, 10h is not something insane, broken, it's a standard value you may find. It may be considered unusual, but it's not abnormal. Same thing for 1h. Maybe this information can help you. |
| Posted by: dloneranger Jan 24 2015, 12:27 PM |
| I meant insane from a not even close to the other start times, lets pick one at random so you can't just do simple maths on it Why the heck would you pick different standards for one stream out of four............??????? were they just bored or something??? Seriously, I do not understand who picks these values - lets not even talk about 709 colourspace or 1080 as a height My list of hate is growing this plugin ffmpeg wmv standards committees super duper fabby video cutters that completely mangle the output whoever it is that's changing fps by repeating every 5th or 6th frame sigh Anyhow... shek's pointed out a way of trying to get the right audio for the related video stream V0.8.2.1 beta b https://dl.dropboxusercontent.com/u/17024916/MyUploadedStuff/FF%20test%20821.zip Fix setting the first audio stream to the best choice relating to the video when there are multiple audio streams ***still unhandled, not sync correcting audio that's wildly different to the video*** |
| Posted by: shekh Jan 24 2015, 01:12 PM |
| The related streams there have equal start times, so they should be perfectly aligned |