Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 3rd June 2018, 23:53   #761  |  Link
Richard1485
Registered User
 
Join Date: Feb 2010
Posts: 233
Oh, I see. I'm not one for writing procedures/functions, but that looks pretty simple. And if that's how they would be implemented internally, then I don't mind doing it the long way. Thanks!
Richard1485 is offline   Reply With Quote
Old 3rd June 2018, 23:57   #762  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,081
Obviously, the optimal solution would be for a generic master ConvertToPixelFormat() (or just plain old ConvertTo(), but I figured the main one I suggest should be more explicit about what it does) function that can convert between YUV(A), Y, Planar/Packed RGB(A) and change bitdepth at the same time, either by the user selecting the bitdepth separately or by taking it from the dest format name. A master function like that wouldn't massively reduplicate code and, IMO, would be fine to include in the core*. For instance:
Code:
input()
ConvertToPixelFormat("YUV420P16", extra_opts)
or
Code:
input()
ConvertToPixelFormat("YUV420", bit_depth=16, extra_opts)
Or you know, the same function as-written could do either of those, since 'YUV420P16' and 'YUV420' are both valid format names; the difference is just whether you'd have to declare any of the extra_opts explicitly because there's also a dedicated bit_depth= parameter.

*and before anyone hits me with the 'AviSynth+ doesn't do implicit conversions' thing, filters shouldn't silently change the input format to do the processing. A master ConvertTo function is always an explicit conversion, so that criticism doesn't apply.
qyot27 is offline   Reply With Quote
Old 4th June 2018, 09:49   #763  |  Link
Richard1485
Registered User
 
Join Date: Feb 2010
Posts: 233
That solution does sound feasible. Even if it's never included in the core, perhaps someone will write an .avsi for it all at some point.
Richard1485 is offline   Reply With Quote
Old 4th June 2018, 11:35   #764  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,245
Then there is the z.lib resizer plugin, see z_ConvertFormat as a swiss-army knife.
Color-space, primaries, bit-depth, size conversion - all-in-one.
https://forum.doom9.org/showthread.php?p=1784316
pinterf is offline   Reply With Quote
Old 17th June 2018, 20:15   #765  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 413
Yeah the newest L-smash does not work for VC-1 at all,at least not in avs+. Getting super corrupt frames with grey bits everywhere.
Gser is offline   Reply With Quote
Old 17th June 2018, 23:01   #766  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,942
Decoding interlaced VC-1 was always a problem, not sure if it was ever completely fixed... can you provide samples? If it fails for "usual" progressive VC-1 as well, which worked with earlier versions, then there may be a regression in libavcodec?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 17th June 2018, 23:15   #767  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,495
Two samples:
https://drive.google.com/file/d/0Bwx...pHeW5wbjQ/view (interlaced)
https://drive.google.com/file/d/0Bwx...RVVGNfeEU/view (progressive)
(via https://kodi.wiki/view/Samples )

No problem with ffmpeg git.
sneaker_ger is offline   Reply With Quote
Old 17th June 2018, 23:24   #768  |  Link
videoh
Registered User
 
Join Date: Jul 2014
Posts: 893
The files look fine as both decode without problems with DGDecNV and Avisynth+.

I don't understand the big problem with interlaced VC-1. There's nothing special about it.
videoh is offline   Reply With Quote
Old 18th June 2018, 09:16   #769  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,942
May be in combination with the container, correct demultiplexing and joining the contained video streams from interleaving segments. FFMS2 used to have issues with interlaced AVC in TS (may have been due to its early dependency on Haali). "Nobody is perfect"... and I know nothing about the details, there are only vague memories.

Quick test: Both L-SMASH Works r929 (20170224) Static in MeGUI and r941 (20180530) Shared fail the same way, already with the progressive source (VC-1_23.976_sample.mkv). FFMS 2.23-1 Static in MeGUI and FFMS2 (bonus) Shared decode it correctly. — Known as L-SMASH-Works issue #58.

At least I hope that they got correctly assigned...

Code:
ClearAutoloadDirs()
LoadPlugin("E:\Programme\MeGUI\tools\lsmash\LSMASHSource.dll")
LwLibavVideoSource("VC-1_23.976_sample.mkv")
vs.
Code:
ClearAutoloadDirs()
LoadPlugin("E:\Programme\AviSynth+\plugins\LSMASHSource.dll")
LwLibavVideoSource("VC-1_23.976_sample.mkv")
Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 18th June 2018 at 09:34.
LigH is offline   Reply With Quote
Old 18th June 2018, 14:18   #770  |  Link
Gser
Registered User
 
Join Date: Apr 2008
Posts: 413
Quote:
Originally Posted by LigH View Post
May be in combination with the container, correct demultiplexing and joining the contained video streams from interleaving segments. FFMS2 used to have issues with interlaced AVC in TS (may have been due to its early dependency on Haali). "Nobody is perfect"... and I know nothing about the details, there are only vague memories.

Quick test: Both L-SMASH Works r929 (20170224) Static in MeGUI and r941 (20180530) Shared fail the same way, already with the progressive source (VC-1_23.976_sample.mkv). FFMS 2.23-1 Static in MeGUI and FFMS2 (bonus) Shared decode it correctly. — Known as L-SMASH-Works issue #58.
Just plain progressive. I remuxed it to m2ts and it played properly, then I reremuxed it to mkv and got the same problems again. So yeah their seems to be a problem with decoding MKV. If I remember correctly this happened even before the update to the new ffmpeg.

PS. Don't make the same mistake I did with updating FFMS, the package only includes the 32-bit version of ffmsindex

Last edited by Gser; 18th June 2018 at 14:39.
Gser is offline   Reply With Quote
Old 18th June 2018, 15:11   #771  |  Link
l33tmeatwad
Registered User
 
l33tmeatwad's Avatar
 
Join Date: Jun 2007
Posts: 157
Quote:
Originally Posted by sl1pkn07 View Post
this is a avs 2.5 API. can you update this to avs 2.6? greetings
Low priority on my todo list, but I'll try to get around to it.
l33tmeatwad is offline   Reply With Quote
Old 20th June 2018, 18:13   #772  |  Link
l33tmeatwad
Registered User
 
l33tmeatwad's Avatar
 
Join Date: Jun 2007
Posts: 157
Patched LSMASHSource to use swresample instead of avresample since ffms2 now requires that and I like the ability to have these share the same libs without excess bloat. Needs to be tested, it can be found on GitHub. Would appreciate it if someone with more experience working with the FFmpeg libs would look over it...

Last edited by l33tmeatwad; 20th June 2018 at 19:29.
l33tmeatwad is offline   Reply With Quote
Old 20th July 2018, 01:37   #773  |  Link
magiblot
Eurobeat Fan
 
Join Date: Sep 2014
Posts: 97
As the wiki suggests, I tried to set decoder="h264_qsv,mpeg2_qsv" hoping that I would experience a speed boost or a reduction in CPU usage (assuming 'qsv' stands for 'Intel QuickSync Video'), but I saw none.

In fact, it doesn't matter what I put into the decoder parameter, LWLibavVideoSource won't complain at all.

Am I not using this feature properly or is it not implemented yet?

Thanks.
magiblot is offline   Reply With Quote
Old 20th July 2018, 02:02   #774  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 187
It need to be compiled with mfx_dispatcher in order to make qsv decoding works. Also It's not frame accurate, or more precise notice "it might return green frames on seeking". But I still got ~400 fps with 4670k, so I'm using qsv for fast source preview.
I also managed to make cuvid decoder works, but it has issues with seeking as well.
__________________
Me on GitHub | My Telegram
PC Specs: Ryzen 3900X (no OC with 250W Air cooling), Asus ROG Crosshair Hero VII (WiFi) @ chipset x470, 32 GB RAM @ 3333MHz OC, Gigabyte RTX 2070, Kingston A1000 @ 240 GB

Last edited by DJATOM; 20th July 2018 at 02:05.
DJATOM is offline   Reply With Quote
Old 20th July 2018, 15:14   #775  |  Link
magiblot
Eurobeat Fan
 
Join Date: Sep 2014
Posts: 97
Oh. Since a index file is created, I was hoping accurate seeking would be possible. Is it still any better than DirectShowSource?

How do I compile the plugin with mfx_dispatcher?

Thanks.
magiblot is offline   Reply With Quote
Old 20th July 2018, 15:41   #776  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,942
I would assume that the index file is used for all frames only when L-SMASH Source decodes using the software decoder in libavcodec. But if you use a hardware decoder provided by your GPU (if that is implemented at all), then it will need to upload the video stream to be decoded into the decoder chip at least GOP-wise, and lose frame-accurate control partially.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 21st July 2018, 00:55   #777  |  Link
magiblot
Eurobeat Fan
 
Join Date: Sep 2014
Posts: 97
I have never written or even looked into a video decoder.

However, if I understand right the idea of GOP, and asuming that you seek to a frame in the middle of a GOP, couldn't the source plugin get the decoded GOP from the decoder and then discard frames until it gets to the sought frame?

Since the source video was indexed previously, I guess the source plugin knows where each GOP starts and in what position inside the GOP the requested frame is.

However, I also guess that if it was that simple it would have already been done.
magiblot is offline   Reply With Quote
Old 21st July 2018, 06:39   #778  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 187
Smart decoder might not discard frames behind decoded one in the GOP, as it might be requested upon further seeking. But issue with qsv is by Intel, as they broke something (Donald described this issue on his forum). Probably the only workaround is to check for decoded frame and request new on error.
__________________
Me on GitHub | My Telegram
PC Specs: Ryzen 3900X (no OC with 250W Air cooling), Asus ROG Crosshair Hero VII (WiFi) @ chipset x470, 32 GB RAM @ 3333MHz OC, Gigabyte RTX 2070, Kingston A1000 @ 240 GB
DJATOM is offline   Reply With Quote
Old 15th September 2018, 19:13   #779  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,881
A fresh build to support av1 would be great.
Thanks!
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 17th September 2018, 19:19   #780  |  Link
Monamona
Registered User
 
Join Date: Aug 2002
Posts: 34
VFR maniac,

Thank you for providing useful filters.

In the future, is there any chance to have an option to create and read the index file (.lwi) in any directory other than at the source file?

I want to read a file located in DVD or BD by LWLibavVideo(Audio)Source, without copying the file to HDD.

Thank you in advance.
Monamona is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.