LAV Filters - DirectShow Media Splitter and Decoders [Archive] - Page 291

roytam1

22nd March 2013, 07:34

http://roy.orz.hm/lavf-w32-nightlies/lavf-my130228-045c141.7z
Cant register .ax:)

Same problem in lavf-my130301-ad71550.7z :scared: :mad:

does it happen in latest nightly?
I changed gcc compiler to 4.8.0 which links to libgcc dll by default, and some builds later I discover the issue and changed linker switch to link it statically. So latest build should work for you.

itsonlyjustincase

22nd March 2013, 09:57

Hi guys,

I have worked a lot and understood a lot. But that i don't manage to get it :http://www.imagup.com/npic/1178472500.html

Left part of the screen is the 2 videos playing at the sametime and being mixed (that is why there is only 1 output windows)

I had enabled the lav tray icon. As you can see the DXVA2 native is choosen. You can see that it is not in use. It is written "avcodec".

But on the right part is the same video launched with MPC-HC forced with lav (same configuration with DXVA2 native). And that time it's being used well and i can confirm it with GPU-Z graph which shows that the video engine load increases only when i start the video with MPC-HC

My goal would be to ensure my application is using DXVA2

File used is 720p H264 AAC (taken from youtube)

http://npic.imagup.com/1/1178472500.png (http://www.imagup.com/npic/1178472500.html)

Hi nevcairiel,

Any thoughts about my problem ?

nevcairiel

22nd March 2013, 10:01

itsonlyjustincase

22nd March 2013, 10:31

Please do not post screenshots that fill a whole screen, and do not re-post your questions every other day. We can read, re-posting them is just spam.
Also, people already answered your problem. DXVA2 Native needs a compatible video renderer, and a direct connection between decoder and renderer, which you apparently just don't have (either no such renderer, or a post-processing filter in between that does your mixing)

I knew you had read it but i just wanted to have your thoughts as you're the one that knows LAV filters and how it works the most. I really didnt' want to bother any of you. I wish i could have avoid to need your help.

When you say "which you apparently just don't have (either no such renderer, or a post-processing filter in between that does your mixing)" what would i need to solve my problem ?

nevcairiel

22nd March 2013, 10:34

DXVA Native is designed for playback and for playback only, for everything else use Copy-Back. To use Native, you need a player which supports DXVA, that is all.

itsonlyjustincase

22nd March 2013, 14:08

DXVA Native is designed for playback and for playback only, for everything else use Copy-Back. To use Native, you need a player which supports DXVA, that is all.

Thanks for you answer. So yes the major problem is my soft.

nevcairiel

22nd March 2013, 15:36

Latest versions of LAV DXVA2 (native) are crashing when trying to play Blu-ray menus with MediaPortal and DSLibBluray (http://dslibbluray.svn.sourceforge.net/viewvc/dslibbluray/) there are also black screens instead of video for some menu videos too (this one tested only in DSLibBluray)

Everything it's playing fine with LAV DXVA2 (native) "official" version (from the first page)

P.S. With CB the only problem in all version are the black screens in the menu

I tried with DSLibbluray and no crashes.
I did find one case of black screen though, but that probably would've happened with the release too.

Edit:
May have found something now.

Mercury_22

22nd March 2013, 16:06

I tried with DSLibbluray and no crashes.
I did find one case of black screen though, but that probably would've happened with the release too.

Edit:
May have found something now.
Looks like it's (more of) an ATI issue then

Don't know if you have it so here is (http://www.multiupload.nl/E97DAD02NI) an update version of DSLibBluray with latest (AFAIK) libbluray.jar since dukey hasn't update the test files (yet :))

EDIT As for the black screen I've just retested with the release version one BD which I'm sure it had black screens with latest git and NO black screen so...:confused:

nevcairiel

22nd March 2013, 16:25

Mercury_22

22nd March 2013, 16:48

Try with the latest Git, or here:

32-bit: http://files.1f0.de/lavf/LAVFilters-0.55.3-43-gbddb80c.zip
64-bit: http://files.1f0.de/lavf/LAVFilters-0.55.3-43-gbddb80c-x64.zip

It should fix another bunch of issues related to ffmpeg changes.
Crash it's fixed :thanks:
Black screens still present but I'm starting to think it's an DSLibBluray problem though e.g. for the same BD with CB i have 2 black screens and with native just 1 but this might be because there are all the 3 types of file mpeg2 vc1 and h264 in the menu

Also you're right (my bad) the 1 black screen with native for that BD it's there with the release version too ( was at the end and I have missed it ):o

Edit Do you want a sample from this BD (BBC Africa) ?

itsonlyjustincase

22nd March 2013, 17:08

Shouldn't IntelQuick sync supposed to be better than CUVID ? My stress test shows that because of the high CPU utilization i couldn't do anything on the computer wiith quicksync so cuvid was giving better performance

aufkrawall

22nd March 2013, 17:31

QS is faster but this doesn't mean CPU utilization would be lower.

nevcairiel

22nd March 2013, 18:02

itsonlyjustincase

22nd March 2013, 18:25

In fact it usually means the CPU util is higher because more frames need to be processed.
Anyhow i can only repeat myself, DXVA and any other kind of hardware decoding is primarily aimed at playback, any other uses-cases will have drawbacks.

Yes i understood but the soft mixes the video but the base is just a playback. You just play to videos at the same time and fade them how you want.....it is based on a MAC application developped in OPENGL. On win they didn't developped it well and with gpu hardware support :s

filler56789

23rd March 2013, 22:22

I changed gcc compiler to 4.8.0 which links to libgcc dll by default, and some builds later I discover the issue and changed linker switch to link it statically. So latest build should work for you.

Just confirming, the problem has been fixed. :goodpost: :thanks:

lboregard

24th March 2013, 17:10

nevcairel, any change of heart with regards to reading iso file format natively within .. i assume .. lav splitter ?

nevcairiel

24th March 2013, 17:11

nevcairel, any change of heart with regards to reading iso file format natively within .. i assume .. lav splitter ?

No. Its not in the scope of LAV Splitter.

paradoxical

24th March 2013, 19:14

nevcairel, any change of heart with regards to reading iso file format natively within .. i assume .. lav splitter ?

Why would it need to? Are you unable to use Daemon Tools or something similar? Or just use a media player than can read an ISO directly like MPC-HC, etc. It seems silly to ask Nev to implement this when there are already existing and mature tools you can use.

dukey

25th March 2013, 14:43

Hi nevcairiel,
I got an issue with dslibbluray with playlists with basically 1 video frame (+long audio). Mpeg2 seems fine, but h264 streams appear to get, stuck in the decoder until I send a bunch more frames. Then they appear at the video renderer. The single video frames have an end of sequence code at the end. If i call DeliverEndOfStream() after the single video frames they appear, but this seems to cause other issues. What should I be doing to handle this case? Mark the frame a a discontinuity or something ?

nevcairiel

25th March 2013, 14:46

Send me a m2ts file like that, and i'll see if it can detect the end of sequence in h264 somehow, like it can for mpeg2 (which is used on DVD menus like this, too)

dukey

25th March 2013, 14:53

I'm not sure what exact m2ts file its in as it doesn't play in MPC. (The .mpls file plays). I'll upload a sample of the bluray.

dukey

25th March 2013, 17:11

http://www.mediafire.com/download.php?lk9t9tai41bxr6v

dukey

26th March 2013, 00:57

Well, I tested out

if(m_VideoDecoderInfo.CodecType == cudaVideoCodec_H264 || m_VideoDecoderInfo.CodecType == cudaVideoCodec_VC1) {

if ((buflen > 3 && !memcmp(&buffer[buflen-4], "\x00\x00\x01\x0a", 4)) ||
(buflen > 4 && !memcmp(&buffer[buflen-5], "\x00\x00\x01\x0a", 4)))
{
m_bEndOfSequence = TRUE;
}
}

on cuvid.cpp, and it fixes all my playback issues. For bluray, at least there is no need to exhaustively search all bytes in in the data for the end sequence code. It'll always be at the end of the data. If you could add this code, and for the other playback types software etc, that would be great :)

nevcairiel

26th March 2013, 09:32

I opened a ticket about this, because i'm busy with other topics right now:
http://code.google.com/p/lavfilters/issues/detail?id=338

I'll look into it when time permits.

filler56789

27th March 2013, 00:02

Anybody already tested the "MKV edition switching" thing? :)

http://roy.orz.hm/lavf-w32-nightlies/lavf-my130326-mkveditions-6859278.7z

JEEB

27th March 2013, 00:15

Not the same branch, but it worked for me with the editions samples I had. Also virtual timelines in general are created and work as they're supposed as far as I can see.

That specific branch seems to now also have segment linking support, but since nev poked me to only test stuff merged into master for now, I haven't tried it yet :)

edit: Someone kick me when writing stuff tired. This commit (http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=b8abbd667066bf16d3ca92d87c41d9a48ad6cc18;js=1) is also in master.

wanezhiling

27th March 2013, 06:16

http://www.newlaunches.com/archives/japan-has-come-up-with-worlds-first-8k-shv-filmed-short-drama.php
:)

CiNcH

27th March 2013, 12:06

@ nev,

we are again discussing A/V async problems with LAV Video together with the DVBSource, see here (http://www.dvbviewer.tv/forum/topic/52149-asynchrone-wiedergabe/). Maybe you got some ideas or comments?

nevcairiel

27th March 2013, 12:14

LAV uses the frame timestamps from the source to time video and audio. In Audio its important that "Auto A/V Sync" is turned on (default is on), or the audio decoder can run out of sync.

When testing, please use software or DXVA, not QuickSync or CUVID. The last two are more or less blackboxes that may or may not internally behave properly when dropping corrupted frames (especially QS is a bit unreliable there)

Dodgexander

27th March 2013, 12:58

On dvb-t2 broadcasts (1080i 25) lav seems to cope badly with corruption/signal drops. Sometimes the picture catches up, but sometimes the corruption gets worse and worse until I have to restart my player.

Also once when this happened, audio got completely out of sync, but after a while caught up again.

The other thing I can mention is switching between dvb-t mpeg2 channels always produces corruption for the first couple of seconds. Even when the filter graph is rebuilt on every switch!

This all has been witnessed using software mode.

Sent from my Blade S using Tapatalk 2

CiNcH

27th March 2013, 13:06

We now have a plugin internally for the DVBViewer which can drop a specified number of TS packets (either whole TS / audio / video) via a button-press. In case nev is interested...

dandirk

27th March 2013, 17:37

Question: about the non-installers downloads (zip versions)...

There are 3 install bat files (audio, video, splitter). Is running all 3 bat files the same as running the installer?

nevcairiel

27th March 2013, 17:57

There are 3 install bat files (audio, video, splitter). Is running all 3 bat files the same as running the installer?

For audio and video yes, but for the splitter, no.
The installer sets the splitter as the actual source filter for the enabled formats, while the bat file only registers it in the system.

nevcairiel

27th March 2013, 18:11

We now have a plugin internally for the DVBViewer which can drop a specified number of TS packets (either whole TS / audio / video) via a button-press. In case nev is interested...

Where would i find this?

CiNcH

27th March 2013, 19:19

Where would i find this?
Got PM. It is not yet public.

nevcairiel

27th March 2013, 20:23

I did some tests, and with the DVB Clock option turned on, i can reproduce a small async after dropping 5% of data for a while, with the option turned off, it seems perfectly fine.
Considering this option does all the difference, i'm inclined to think its not LAV. I confirmed that audio and video timestamps match the input timestamps, and are just passed through the decoder.

And for the record, LAV does pay attention to the discontinuity flags, and does take it into account for timestamps (at least for audio, for video there is no need, because timestamps are passed through 1:1)

PS:
What good is this option supposed to do? Its not on by default, so it must have some known drawbacks. All i hear is that it causes async issues, instead of fixing them :)

mzso

27th March 2013, 23:39

Anybody already tested the "MKV edition switching" thing? :)

http://roy.orz.hm/lavf-w32-nightlies/lavf-my130326-mkveditions-6859278.7z

Any way to get the info about what/where is it different? I have some movies with editions. But watching them fully again right after I finished is not that attractive.

dansrfe

28th March 2013, 02:37

There's a problem with playlist files. The next file in the playlist gives no sound unless I manually go to the next song in the playlist and back again. Also, m4a file duration is inaccurate as the file finishes earlier and the mpc's timeslider keeps going for another min sometimes.

CiNcH

28th March 2013, 08:06

What good is this option supposed to do? Its not on by default, so it must have some known drawbacks. All i hear is that it causes async issues, instead of fixing them
The purpose of the DVB Clock is to synchronize producer and consumer since it is not possible to vary stream (e.g. DVB) speed which will result in a buffer overflow/underrun sooner or later. So the playback clock is synchronized to the producer's clock which is represented via the PCR. This of course means that the graph clock is neither synchronized to the video nor to the audio output. So the video renderer has to drop/repeat a frame every now and then and the audio renderer has to apply rate-matching (frequency/pitch adjustments).
The DVBSource uses the system clock (Multimedia timer based) for generating the PCR compensated graph clock which may not be as accurate as desired in some cases. The audio clock is typically the better clock to use. Also the deviation between producer and consumer is mostly not that high when using the pretty accurate audio clock, so a buffer overflow/underrun won't happen that soon...

starla

28th March 2013, 09:52

The purpose of the DVB Clock is to synchronize producer and consumer since it is not possible to vary stream (e.g. DVB) speed which will result in a buffer overflow/underrun sooner or later. So the playback clock is synchronized to the producer's clock which is represented via the PCR. This of course means that the graph clock is neither synchronized to the video nor to the audio output. So the video renderer has to drop/repeat a frame every now and then and the audio renderer has to apply rate-matching (frequency/pitch adjustments).
The DVBSource uses the system clock (Multimedia timer based) for generating the PCR compensated graph clock which may not be as accurate as desired in some cases. The audio clock is typically the better clock to use. Also the deviation between producer and consumer is mostly not that high when using the pretty accurate audio clock, so a buffer overflow/underrun won't happen that soon...

Based on that description it sounds the issue is not in LAV side. Audio and video decoders wont care about the reference clock at all, so altering that or using some other time source than audio HW wont make any difference how the audio and/or video decoders work.

zerowalker

30th March 2013, 00:20

There seem to be a problem decoding fade outs with Lagarith.
It always freeze the frame before it´s totally black, and then starts the next frame after the fade out.

It´s always the same not matter what the content it, as long as it´s a fade out. It doesn´t happen when decoding with the original Lagarith decoder.

nevcairiel

30th March 2013, 09:50

As some people figured out already, i've added support for Matroska Ordered Chapters and Segment/File Linking to LAV over the last week.

Here is finally an official test build:

32-bit: http://files.1f0.de/lavf/LAVFilters-0.55.3-56-g3524495.zip
64-bit: http://files.1f0.de/lavf/LAVFilters-0.55.3-56-g3524495-x64.zip

What is supported?
- Ordered Chapters within one segment/file (as created by xin1generator (https://code.google.com/p/xin1generator/) for example)
- Ordered Chapters with linked segments (both in separate files, and multiple segments in the same file)
- File Linking (Prev/NextUID in the MKV headers, as created by mkvmerge's "split" feature)

Known issues:
- MPC-HCs Keyframe Seek does not work with Ordered Chapter files yet, its on my TODO

The usual limitations apply for ordered chapters to work properly. There should be a Cue/Seek point on the ordered chapter boundary, and the tracks in the different files should match.
At this time, there is no code at all that tries to match different stream configurations, its just assumed that stream #1 in file #1 is also stream #1 in file #2. If its common for this to not be the case, i can look into it, but i need sample files to work against.

Please test and report problems!
Note that in this case especially, i will need the files that cause problems, so it is important that you tell me how to generate or obtain the problematic files!

Edit:
New Build (0.55.3-56) because of a crash-on-close issue.

wanezhiling

30th March 2013, 10:17

Wow! :thanks:

Sebastiii

30th March 2013, 11:10

Thanks Nev, first test on the files i have works good :)

wanezhiling

30th March 2013, 11:25

http://forum.doom9.org/showpost.php?p=1608859&postcount=13681

lav s + lav v: op (http://i.imgur.com/IHEpwP8.png) ed (http://i.imgur.com/bQVFrQv.png)

haali: op (http://i.imgur.com/ulNgrKP.png) ed (http://i.imgur.com/8JDfiyl.jpg)

cyberbeing

30th March 2013, 11:32

I just ran into a problem with Ordered Chapter + Segment Linking which causes broken playback and corruption when one segment has header removal compression on the video track and the other doesn't. At least that appears to be the issue at first glance. [Edit: Confirmed]

LAV Splitter + LAV Video = Broken (http://imageshack.us/a/img195/9454/ordchapseghcompresslav.png). If you try to seek within this segment showing corrupted output, the screen turns pure gray and usually will hang or crash MPC-HC.

Haali Splitter + LAV Video = Working

MPlayer2 = Working

For reference, the first main segment got re-muxed with MKVToolNix 4.9.1 (enabled header removal compression), and the second second segment which was inserted into the middle of the first got muxed with MKVToolNix 4.4.0 (disabled header removal compression). If you are unable to reproduce, I'll provide you with a sample.

nevcairiel

30th March 2013, 12:30