Log in

View Full Version : LAV Filters - DirectShow Media Splitter and Decoders


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 [316] 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508

nevcairiel
28th July 2013, 09:57
Well its not like there is a list of all weirdo FourCCs somewhere. :p

Pat357
28th July 2013, 23:42
Well its not like there is a list of all weirdo FourCCs somewhere. :p

It seems that ffmpeg/ffplay can handle this file without problems ; does this mean that the FourCC "Divx" is already known by FFplay ? Or does it use another trick to properly detect the codec ?
Wouldn't it be possible to use the same method in LAV for correct detection ? (ie use the same FourCC list and/or the same probing trick ?)

Output ffplay (verbose) :

[avi @ 044a1260] Format avi probed with size=2048 and score=100
[avi @ 04482fe0] use odml:1
[avi @ 044a1260] File position before avformat_find_stream_info() is 8204
[avi @ 044a1260] All info found
[avi @ 044a1260] File position after avformat_find_stream_info() is 35133
Input #0, avi, from 'K:\downloads\Divx failed.avi':
Metadata:
title : IFDVA_038_title2
encoder : Lavf52.13.0
Duration: 00:00:08.02, start: 0.000000, bitrate: 1997 kb/s
Stream #0:0, 1, 100/2997: Video: mpeg4 (Simple Profile) (Divx / 0x78766944), yuv420p, 720x480 [SAR 1:1 DAR 3:2], 100/2997, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0:1, 21, 3/125: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16p, 160 kb/s
detected 12 logical cores
[AVIOContext @ 0448b680] Statistics: 182332 bytes read, 7 seeks

cyberbeing
29th July 2013, 05:15
It seems that ffmpeg/ffplay can handle this file without problems ; does this mean that the FourCC "Divx" is already known by FFplay ? Or does it use another trick to properly detect the codec?

It looks like ffmpeg mpegvideo.c may convert "Divx" to uppercase:


/* convert fourcc to upper case */
s->codec_tag = avpriv_toupper4(s->avctx->codec_tag);
s->stream_codec_tag = avpriv_toupper4(s->avctx->stream_codec_tag);

sdancer75
29th July 2013, 19:07
Hi,

Trying to complile LAVSplitter I get the following errors....



1>------ Build started: Project: DSUtilLite, Configuration: Debug Win32 ------
1> ByteParser.cpp
1> DSUtilLite.vcxproj -> C:\MyProjects\LAVFilters-master\bin_Win32d\lib\dsutild.lib
2>------ Build started: Project: LAVSplitter, Configuration: Debug Win32 ------
2> LAVSplitter.cpp
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(79): error C2143: syntax error : missing ';' before '*'
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(79): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(85): error C2143: syntax error : missing ';' before '*'
2>c:\myprojects\lavfilters-master\demuxer\demuxers\bddemuxer.h(85): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
2>c:\program files (x86)\microsoft visual studio 11.0\vc\include\regex(1670): fatal error C1903: unable to recover from previous error(s); stopping compilation
2> Generating Code...
2> Compiling...
2> StreamParser.cpp
2> Generating Code...
========== Build: 1 succeeded, 1 failed, 3 up-to-date, 0 skipped ==========

Any help ?

nevcairiel
30th July 2013, 07:08
Works just fine here under both VS2010 and VS2012.
Are you maybe missing the libbluray checkout in the correct position?

Building LAV really isn't all that hard.

1) Checkout LAV Git repository (git clone <url>)
2) Checkout Submodules in the Git Repository (git submodule update --init)
3) Build FFmpeg (included build script, "sh build_ffmpeg.sh")
4) Build LAV itself in VS2010/2012

Or use "build.bat" which combines steps 3 and 4.
Of course this assumes you have VS2010 or VS2012 properly setup and a mingw-w64 GCC properly setup - but i provide the GCC i use for download if required. :)

pOpY
30th July 2013, 09:00
LAV Filters 0.58.2

LAV Splitter
- Fixed demuxing of WavPack from MKV

LAV Video
- Fixed a crash when YADIF was being used on a single- or dual-core CPU

LAV Audio
- Fixed decoding of DTS streams with a frame size change mid-stream


Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.58.2.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.58.2.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.58.2-x64.zip)

Just a bug fix/crash fix release, primarily for the YADIF crash, and i decided to pull in two other safe changes.
This release is not based on todays git master, but a stable branch i specifically created to push these changes (of course master also contains the fixes), just as a FYI for anyone that builds their own or bundles it.

Anyway, not much to say about this one otherwise!

Have fun!

thx for the fix :)
will try this and report back.

cu
pOpY

sdancer75
30th July 2013, 12:04
Works just fine here under both VS2010 and VS2012.
Are you maybe missing the libbluray checkout in the correct position?

Building LAV really isn't all that hard.

1) Checkout LAV Git repository (git clone <url>)
2) Checkout Submodules in the Git Repository (git submodule update --init)
3) Build FFmpeg (included build script, "sh build_ffmpeg.sh")
4) Build LAV itself in VS2010/2012

Or use "build.bat" which combines steps 3 and 4.
Of course this assumes you have VS2010 or VS2012 properly setup and a mingw-w64 GCC properly setup - but i provide the GCC i use for download if required. :)

Hi,

I dont think that I am missing libbluray since the Demuxers that uses libbluray compiles just fine.

Anyway, I solved this situation by adding the

#include "libbluray/bluray.h"

in the stdafx.h of the LAVSplitter project.


Regards,

nevcairiel
30th July 2013, 12:48
Anyway, I solved this situation by adding the

#include "libbluray/bluray.h"


You mean this line, which has been there for ever?
https://github.com/Nevcairiel/LAVFilters/blob/master/demuxer/LAVSplitter/stdafx.h#L42

clsid
30th July 2013, 16:46
MPC-HC randomly crashes when destroying the graph if the tray icon is enabled for the internal LAV Splitter.

nevcairiel
30th July 2013, 16:48
Thats something for them to work out, it works in a standalone config.

ƒreeman
1st August 2013, 14:06
hi.. i'm using MPC-BE with LAVFilters and madVR..
here is my configuration:
Windows 7 Professional x64
Intel Pentium Dual Core CPU 997 @ 1.60GHz 1.6GHz
RAM 4GB DDR3 @ 1333MHz
Intel HD Graphics 128 MB dedicated and 1632MB shared..
http://i40.tinypic.com/23rkcph.png

here is my question:
should I use intel quicksync decoding method or software decoding method in LAV Video Filter..?
i'm using madVR too nothing changed except smooth video on..

thanks..

SamKook
1st August 2013, 14:30
should I use intel quicksync decoding method or software decoding method in LAV Video Filter..?
i'm using madVR too nothing changed except smooth video on..

thanks..

Unless you want to save power or you notice dropped frames(this may or may not happen in your case depending on your madvr settings), always use software decoding.

sneaker_ger
1st August 2013, 14:41
Intel Pentium 997 does not support QuickSync in the first place, so it will fall back to software even if you select it.

nevcairiel
1st August 2013, 14:53
Intel Pentium 997 does not support QuickSync in the first place, so it will fall back to software even if you select it.

Thats not true.
What Intel calls "QuickSync" is the encoder support, however all CPUs of the SNB/IVY/Haswell generation with an iGPU support the decoder.

sneaker_ger
1st August 2013, 15:10
I stand corrected - only looked at the Intel chart where it just says not supported without specifying further.

ƒreeman
1st August 2013, 15:57
I stand corrected - only looked at the Intel chart where it just says not supported without specifying further.

it says available in LAV Video decoder.. what it that mean then..??

http://i43.tinypic.com/2cf8wzo.png

SamKook
1st August 2013, 16:04
it says available in LAV Video decoder.. what it that mean then..??

I suggest you read nevcairiel post again, he already explained why.

ƒreeman
1st August 2013, 16:09
Oh yeah.. I got it.. so, as of now software decoding is best on this cpu..??

Edit: one more thing, can this cpu handle madVR..? shall I use madVR or EVR Custom..??

SamKook
1st August 2013, 16:17
Oh yeah.. I got it.. so, as of now software decoding is best on this cpu..??

Software decoding is best for all CPU since, as far as I know, there's no hardware acceleration which doesn't degrade the picture quality vs software decoding.

The reasons one would use hardware decoding are the two I mentioned earlier.

detmek
1st August 2013, 16:43
Hardware acceleration does not degrade picutre quality.

DragonQ
1st August 2013, 16:47
Yeah, this is demonstrable by comparing frames. He may be referring to all of the "enhancements" sometimes added by the GPU during decoding but these can all be turned off. Same with audio - you need to tick "Disable all enhancements" in your sound card's properties to ensure it isn't doing anything funny (like my laptop which liked to apply DRC for no reason until I ticked this option). :o

SamKook
1st August 2013, 17:11
It might be because of the "enhencements", all I know is that out of all the comparison I've seen, those with hardware decoding always looked worse so I never bothered doing extensive testing with it.

The quicksync encoder(not decoder) produced especially terrible results when I was looking if it was worth getting a MB that supported it a year and a half ago.

sneaker_ger
1st August 2013, 17:22
Yes, the hardware and software decoding of LAV are bit-identical (at least for H.264). You can prove it via AviSynth. Differences can only be from the mentioned "enhancements" or deinterlacing. Any "terrible results" could also simply be driver errors.

it says available in LAV Video decoder.. what it that mean then..??

http://i43.tinypic.com/2cf8wzo.png

"Available" means that your system does indeed offer QuickSync decoding (as nevcairiel pointed out). It will turn to "Active" and appear under "Active Decoder" if it actually used which does not seem to be the case for you currently. This could for example be because the video you are playing is not compatible with the hardware decoder - not all formats are. Successful hardware decoding can depend on several factors including OS, drivers, resolution, level/DPB, format, renderer (only DXVA2 native). That's why software is used by default - it is the least error prone decoding method.

DragonQ
1st August 2013, 19:35
It might be because of the "enhencements", all I know is that out of all the comparison I've seen, those with hardware decoding always looked worse so I never bothered doing extensive testing with it.

The quicksync encoder(not decoder) produced especially terrible results when I was looking if it was worth getting a MB that supported it a year and a half ago.
If you're talking about encoding, you're right, hardware options are usually inferior (but much faster). Decoding is totally different though and can (and should) produce identical output.

detmek
1st August 2013, 23:14
I compared output of CoreAVC, LAV Video decoder and FFDShow last year, hardware and software decoding and all output streams ended up bit-identical. You can see test here (http://translate.google.com/translate?sl=sr&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Falexxandar.wordpress.com%2F2012%2F09%2F08%2Fda-li-h-264-dekoderi-daju-identican-output%2F&act=url) (P.S. Google Translate is not perfect but you can fill some blanks).

jkauff
2nd August 2013, 00:33
Nev said in an earlier post that the main reason software decoding is better is that if you have a fast CPU, it will decode many more frames per second than either CUVID or QuickSync (between the two, though, QuickSync is faster). I only use hw decoding if I'm doing a Handbrake encode that grabs 100% of my CPU most of the time.

mindbomb
2nd August 2013, 00:53
I would use quicksync. His cpu might choke on high bitrate h264.
The driver enhancements happen at the renderer level afaik, so it shouldn't impact whether you use hardware accelerated video decoding or not.

sdancer75
2nd August 2013, 07:45
You mean this line, which has been there for ever?
https://github.com/Nevcairiel/LAVFilters/blob/master/demuxer/LAVSplitter/stdafx.h#L42

Yeap you have right, but for a strange reason that I dont remember, I commented sometime the specific line, and I didn't even see it, when I added my own libbluray include.

Thanks :-)
It seems, I am getting old and I can not see things any more or maybe my laptop's screen its to small for my eyes !

pOpY
2nd August 2013, 16:33
thx for the fix :)
will try this and report back.

cu
pOpY

0.58.2 with yadif on my Core 2 Duo works :):)
thx for the fix!

nevcairiel
2nd August 2013, 16:39
Thanks for confirming!

SeeMoreDigital
2nd August 2013, 16:51
Nev,

Out of interest. When you configure 'LAV Audio' to bit-stream Dolby Digital, Dolby Digital Plus, Dolby TrueHD, DTS and DTS-HD audio via HDMI, does it use 'WASAPI' or 'DirectSound'?


Cheers

nevcairiel
2nd August 2013, 16:52
Thats not up to LAV Audio, your audio renderer decides that. Although for bit-streaming its really not important which you use, its not like the mixer can change the bitstream.

sebas_led
2nd August 2013, 20:17
Hi!

First, thanks for the great job with LAV Filters.
Second, can an application uses two instances of LAV filters? I want to have two (or more) independent graphs with LAV Splitter+audio+video+Windows default render.

Sebas

Reino
2nd August 2013, 21:11
"Available" means that your system does indeed offer QuickSync decoding (as nevcairiel pointed out).

http://www.ld-host.de/uploads/images/3791d627cda93616423962a8a78967d1.png

Oops?

nevcairiel
2nd August 2013, 21:25
I blacklisted that on XP before, but some people said it worked for them under certain circumstances, so i enabled it again. It may work on a limited number of systems and codecs.

nevcairiel
3rd August 2013, 09:38
@ nevcairiel:

Any chance you could add auto-update functionality to LAV Filters?

No. Not going to happen.

wanezhiling
3rd August 2013, 14:20
http://aleksoid.voserver.net/Sample/Subtitle/MKV/dvb-subtitle_heb.mkv
Lav splitter can't handle the dvb sub?

nevcairiel
3rd August 2013, 15:41
http://aleksoid.voserver.net/Sample/Subtitle/MKV/dvb-subtitle_heb.mkv
Lav splitter can't handle the dvb sub?

You could also say that whatever subtitle renderer was used could not handle dvb in mkv, but i fixed it anyway.

Sparktank
4th August 2013, 06:01
nevcairiel, please look at this issue (http://forum.doom9.org/showthread.php?p=1639178#post1639178) when you have time.
(Didn't want to cross-post).

frosh
6th August 2013, 11:21
Lav video decoder 0.58.2 doesn't activate neither copy-back nor native DXVA during playback of mkv with 12 reframes.
Tested with PotPlayer and MPC-BE on ATI HD 3200 videocard and 13.1 Catalyst. 0.57 works fine.

Lav splitter hangs PotPlayer up at start of playing of mkv via http.

wanezhiling
6th August 2013, 11:54
Lav video decoder 0.58.2 doesn't activate neither copy-back nor native DXVA during playback of mkv with 12 reframes.
Tested with PotPlayer and MPC-BE on AMD HD4000 videocard. 0.57 works fine.
ref16: http://i.imgur.com/czpF3e8.png

works fine here: http://i.imgur.com/Wd4hDdv.png

roytam1
8th August 2013, 01:01
@nev: is 1f0.de not available right now?

lavfsplitter$ git pull && git submodule update
fatal: unable to connect to git.1f0.de:
git.1f0.de[0: 144.76.108.235]: errno=No such file or directory

CoKing
8th August 2013, 14:12
Hi nev, some questions, namely about an odd h.264 format that I haven't been able to connect the LAV Video Decoder to.

I've seen it called a couple things, H264_bis and H264_MainConcept, and the GUID is { 0x8D2D71CB, 0x243F, 0x45E3, { 0xB2, 0xD8, 0x5F, 0xD7, 0x96, 0x7E, 0xC0, 0x9B } }

Should this be having a problem? I did some digging and it seems to be supported by ffdshow, but I also see references stating not to use it at all for video streaming. I'm trying to pick up an MPEG2 transport stream over udp (multicast) using a mainconcept demuxer that doesn't want to output one of the more common H264 formats.

I also tried using the LAV Splitter but it doesn't want to connect to the source (elecard nwsource-plus). Sadly the splitter source isn't an option since I need to be able to dump the stream to a file before it is demuxed.

SeeMoreDigital
8th August 2013, 15:08
Hi nev, some questions, namely about an odd h.264 format that I haven't been able to connect the LAV Video Decoder to.

Hi and welcome to the forum,

Please provide detailed information about your 'problem' file by using an application called MediaInfo (http://mediainfo.sourceforge.net/en) (set to text mode). And post what it reports, IN FULL as a text (.txt) file.

CoKing
8th August 2013, 15:47
Hi and welcome to the forum,

Please provide detailed information about your 'problem' file by using an application called MediaInfo (http://mediainfo.sourceforge.net/en) (set to text mode). And post what it reports, IN FULL as a text (.txt) file.

Thanks, it's been an interesting site so far! Also, thanks for pointing me to that application, I expect it will be extremely useful in the future!

I've attached the file generated from one of my sample videos. Ideally I'm dealing with live video from camera streamed by a hardware encoder that I then pick up with a directshow graph. This sample video was recorded from the source prior to demuxing so it should match what I see normally. I restream this video for testing when I am without a live source using VLC and the following script:

cd\
cd C:\Program Files (x86)\VideoLAN\VLC
VLC.exe "C:\Users\Public\Videos\EOW_110140Z_001.ts" :sout="#standard{access=udp,mux=ts,dst=224.168.99.99:1239}" -L

If there is any more information I can provide please ask; any help is very much appreciated!

SeeMoreDigital
8th August 2013, 18:14
Given the size of your .TS contained file is only 111MB, try re-muxing it into the .MKV container using the newest version of MKVmerge GUI (http://forum.doom9.org/showthread.php?p=1634657#post1634657).

If MKVmerge rejects it, there may be a problem with the .TS file...

nevcairiel
8th August 2013, 18:28
I think you didn't read his post thoroughly. :)

@CoKing:
Here is a test build with that mediatype added, let me know if it works:
http://files.1f0.de/lavf/LAVFilters-0.58.2-h264bis.zip

Keep in mind that you need to run the install_video.bat script to make it recognize the new type.

CoKing
8th August 2013, 21:01
@SeeMoreDigital:
The file should be fine; it is small because it's just a sample I use for testing and works with other decoders. I'm investigating decoders to try to find a replacement for the one I've used in the past which while it provided some of the lowest latency, it is quite old and support has been non existent the last year or so.

@nevcairiel:
Thanks for taking the time to help with this, I really appreciate it!

I tried the new build and while it was able to connect through to a renderer, I only see a grey output with very occasional artifacts (same result in either graphstudio and my app).

The output itself seems to be ok as it will render correctly using another decoder. I am able to get LAV to decode the video when using a rather specific version of the elecard mpeg push demuxer that outputs both a standard version of H264 and bis, but I really want to avoid painting myself into a corner with a specific version if possible. I'm investigating demuxers as well, which is why I was curious if you have any idea why the splitter wasn't able to connect to the source stream.


For reference, some pin spec's from graph studio:

Output pin from the Elecard NWSource-Plus:

Allocator Properties:
cBuffers: 5; cbBuffer 204800; cbAlign: 1; cbPrefix: 0;

MediaType:
major type: MEDIATYPE_Stream; subtype: MEDIASUBTYPE_MPEG2_TRANSPORT; format type: GUID_NULL;
bFixedSizeSamples: true; bTemporalCompression: false; lSampleSize: 1; cbFormat: 0;


Output pin from the Elecard MPEG Push Demultiplexer:

Allocator Properties:
cBuffers: 200; cbBuffer 655360; cbAlign: 1; cbPrefix: 0;

MediaType:
major type: MEDIATYPE_Video; subtype: {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}; format type: FORMAT_MPEG2_VIDEO;
bFixedSizeSamples: true; bTemporalCompression: false; lSampleSize: 1; cbFormat: 173;

nevcairiel
8th August 2013, 21:45
LAV doesn't support push sources, only pull sources, which is most likely why it doesn't work.

Anyway, here is another version, i forgot to add the new type in a second place:
http://files.1f0.de/lavf/LAVFilters-0.58.2-h264bis2.zip

A new H264 type doesn't need adding every day, easy to forget places. .)

CoKing
8th August 2013, 22:22
That's got it working, much thanks!

And I imagine they don't come up too often, though there does seem to be far more types than strictly necessary ...

This solves the splitter issue. I do deal occasionally with pull sources and will try LAV there as well.