|
|
| Loadus |
| Posted: Sep 8 2011, 09:44 PM |
 |
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
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.
--------------------
deviantART behance |
|
| dann23 |
| Posted: Sep 24 2011, 06:52 AM |
|
|
Newbie
Group: Members
Posts: 3
Member No.: 33151
Joined: 24-September 11
|
hello, there is no x64 build. do you plan to release one? thank you. |
|
| L.H.V.F. |
| Posted: Sep 27 2011, 01:26 AM |
|
|
Advanced Member
Group: Members
Posts: 49
Member No.: 28822
Joined: 19-October 10
|
| QUOTE (raythe0n @ Aug 6 2011, 10:28 AM) | | QUOTE (L.H.V.F. @ Aug 4 2011, 08: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 an intermediate file address for plugin detection?
I thank reply. |
Whether have you the same problems with other input plugins? |
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. . |
|
| Jim_pansen |
| Posted: Dec 4 2011, 10:14 PM |
|
|
Advanced Member
Group: Members
Posts: 30
Member No.: 25998
Joined: 12-August 09
|
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 |
|
| Barnister |
| Posted: Dec 12 2011, 08:45 PM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 27261
Joined: 22-March 10
|
No more development? It's an awesome plugin! |
|
| L.H.V.F. |
| Posted: Dec 28 2011, 02:22 AM |
|
|
Advanced Member
Group: Members
Posts: 49
Member No.: 28822
Joined: 19-October 10
|
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 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 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 Firefox add-on, 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:
ffmpeg-git-f514695-win32-static
I have catch the link of the second video in embedded player (source code of the page), and I have downloaded with IcyVideo, 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 VirtualDub 1.10.1 Test Thread, 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 Freemake Video Converter and Free Studio by DVDVideoSoft), having the same problem of the Ffmpeg Input Driver (recognizes 12,000 fps in a .rmvb video). I had used SUPER, 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 ffmpeg-git-7f83db3-win32-static (2012-01-05), I have tested the .ts mentioned video, and the problems persists.
Edit2: I have tested also with FFmpeg git-ceb0dd9 32-bit Static (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 FFmpeg Project.
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 (Zeranoe 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. . |
|
| v0lt |
| Posted: Jan 4 2012, 09:14 AM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 26125
Joined: 5-September 09
|
@raythe0n
"Adjust Pixel Aspect Ratio" option is not saved. It is always enabled.  |
|
| raythe0n |
| Posted: Jan 12 2012, 11:41 AM |
|
|
Member
Group: Members
Posts: 19
Member No.: 31262
Joined: 10-May 11
|
| QUOTE (Barnister @ Dec 12 2011, 11:45 PM) | | No more development? It's an awesome plugin! |
Hi Barnister,
In the near future I will update the driver for the new ffmpeg and make x64 version.
thank you
|
|
| L.H.V.F. |
| Posted: Jan 27 2012, 10:57 PM |
|
|
Advanced Member
Group: Members
Posts: 49
Member No.: 28822
Joined: 19-October 10
|
| QUOTE (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
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 Firefox add-on, 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:
ffmpeg-git-f514695-win32-static
I have catch the link of the second video in embedded player (source code of the page), and I have downloaded with IcyVideo, and the problem persists.
|
Hi, raythe0n
I have tested the problem in VirtualDub, with the latest version of VirtualDub (VirtualDub-1.10.2-test2), 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 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 VirtualDub Test Thread, phaeron have said that the problem possibly is coming of your plugin. I think, that if the given problem be corrected, in the 20101214bl3_1292371138.flv, 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 (test-3).
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 (20101214bl3_1292371138.flv), testing with the last test-release (VirtualDub-1.10.2-test9). 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 .flvs with unexpected situations. If the direction of the development be dedicated for some damaged stream media or problematic media and fix unexpected situations, the users will not go back for other alternatives, and the video editing will be very usable and efficient (mainly for file extensions with difficult support, and recognition, that are already supported by the FFmpeg library). I am reporting, and trying to convincing that developers of FFmpeg Project to correct the bugs, principally in .ts file extension (Transport Stream) with wrong framerate recognition (because of the instability in VirtualDub), and one day, maybe, this will be fixed as are done with the FFDShow, for windows operating systems. There are, as I can enumerate, players that support these damaged medias (reconstructing the basic structure or recovering the keyframe map and tables), as the MPlayer or VLC, and other players, as recently now the Media Player Classic - Home Cinema, supporting some damaged videos, by deactivating some filter or internal configuration, or creating a workaround for can play these damaged media, and more videos in general, as I have noticed.
I recommend that with FFmpeg Input Driver, in terms of usability, all problems be submitted for analysis in FFmpeg Bug Tracker, because there, is where the developers of the Official FFmpeg builds could correct all errors or problems with all based libraries, since that many programs uses that library, and programs uses it, to have a free library, as a base, and are affected for some error existent, using it for have this free support in their Projects for video and audio or stream media. Even if that the error be minimum, I believe that with various patches received to mantainers, is possible that in a nearly future all video, that in the moment have a problems, these will working better consequently, since that the FFmpeg Bug Tracker has many developers working for improvements in all libraries related of FFmpeg Project. I'm in the Bug Tracker, and in any notice of Bug correction of .ts, and h264 libraries, I will notify raythe0n developer for update your builds, even as other fixes that will go together all development of FFmpeg Project. I need also, some people that be understood in the subject, for notify a possible noticed Bug error (for FFmpeg Input Driver), and write a correct description, of what goes wrong, and technical explanation for convincing the developers of FFmpeg Project, after the 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 FFmpeg Project.
Link: http://www.ffmpeg.org/trac/ffmpeg/ticket/1065
I thank reply,
L.H.V.F. . |
|
| Jim_pansen |
| Posted: Feb 21 2012, 05:05 PM |
|
|
Advanced Member
Group: Members
Posts: 30
Member No.: 25998
Joined: 12-August 09
|
| QUOTE (v0lt @ Jan 4 2012, 10:14 AM) | @raythe0n
"Adjust Pixel Aspect Ratio" option is not saved. It is always enabled. |
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 |
|
| v0lt |
| Posted: Feb 28 2012, 05:54 AM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 26125
Joined: 5-September 09
|
ffinputdriver-0.7_nodefaultresize.zip |
|
| Jim_pansen |
| Posted: Feb 28 2012, 09:51 AM |
|
|
Advanced Member
Group: Members
Posts: 30
Member No.: 25998
Joined: 12-August 09
|
Works fine!
Thank you! |
|
| Dstruct |
| Posted: Mar 2 2012, 04:11 PM |
|
|
Advanced Member
Group: Members
Posts: 257
Member No.: 24005
Joined: 8-August 08
|
What about making it working with Libav too?
http://www.libav.org |
|
| CommonTater |
| Posted: May 14 2012, 03:24 AM |
|
|
Newbie
Group: Members
Posts: 1
Member No.: 34860
Joined: 14-May 12
|
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? |
|
| levicki |
| Posted: May 15 2012, 01:54 PM |
|
|
Advanced Member
Group: Members
Posts: 167
Member No.: 22605
Joined: 13-December 07
|
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.
|
|
|
