LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

but just wanted to do it for all subtypes, not wait for the next problematic one.

There is no comprehensive list of all types.
Alot of types are simple types based on the FourCC (not even listed anywhere), the others can only be seen in the source, sometimes scattered a bit.

First function in this file, for example, for audio
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=demuxer/Demuxers/LAVFAudioHelper.cpp;h=23a2083009dee434f2539e8b997092edb4d3129f;hb=HEAD

Or here for video:
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=demuxer/Demuxers/LAVFVideoHelper.cpp;h=d38e747a5305ea0bd2a8f5ef5cf5be49f522cb71;hb=HEAD

But thats not all (and of course the symbolic names). :P

[Kaotech]

No it's a 5.1 track, i remember when i register LAVAudio.ax with 0.19, I could change audio Track, I don't know why it no longer works.

I found the problem, it's when I connect ffdshow audio processor.

I Disabled "Enable jitter correction", and now it's working.

[SamuriHL]

Nev, my file does break with LAV Splitter, but, I'm not terribly concerned. I tried to trim the first 100 megs from it and that works fine. (I use the Video ReDo file trim function which doesn't modify anything). So I can easily fix it. But it is the splitter as when I use the MPC-HC internal MPEG-TS splitter I can seek fine. Odd. If you want the file to play around with let me know. It's 5 gigs, though. :) Otherwise I'll fix it when I cut the commercials anyway.

[nevcairiel]

Nev, my file does break with LAV Splitter, but, I'm not terribly concerned. I tried to trim the first 100 megs from it and that works fine. (I use the Video ReDo file trim function which doesn't modify anything). So I can easily fix it. But it is the splitter as when I use the MPC-HC internal MPEG-TS splitter I can seek fine. Odd. If you want the file to play around with let me know. It's 5 gigs, though. :) Otherwise I'll fix it when I cut the commercials anyway.

You could run a debug build and see what the log in DebugView says.

[SamuriHL]

You could run a debug build and see what the log in DebugView says.

Yup I can do that. As soon as I'm done with work I'll give that a try.

[madshi]

For the record, all these issues never affected madVR once, always played just fine with it.
Some months ago I added code to madVR to correct swapped timestamps, because that was the only way to make VC-1 Blu-Rays play correctly with the MPC-HC internal TS splitter. That's probably why you don't see a problem with madVR. It's not really ideal if madVR has to do that, though. If timestamps are swapped madVR does not really know for 100% sure which timestamp originally belonged to which frame. So there's a small danger of audio/video sync being imperfect.

The option was added years back to fix VC-1 in MPEG-TS decoding, because for some reason the timestamp reordering for VC-1 B-Frames creates broken timestamps - at least in the internal VC-1 decoder (and the MS WMVideo Decoder).
What exactly causes the broken timestamps on those codecs, i cannot say.
What I can say is that eac3to has always muxed VC-1 frames with simply increasing timestamps. Meaning, the first VC-1 frame in the video bitstream in an eac3to muxed MKV file has timestamp 0. The second VC-1 frame has timestamp 41708. Etc. This worked just fine with Haali MKV Splitter -> MS VC-1 decoder -> any renderer. So it seems to me that the MS VC-1 decoder expects to simply get increasing timestamps for every VC-1 frame in the bitstream. That's probably similar to DTS, I guess?

Now, what i did to fix this was ask ffmpeg to give me Decoding Time Stamps (DTS) instead of Presentation Time Stamps (PTS). The DTS timestamps are already reordered, and playback was fine again.
Ok, makes sense.

The second part was to write a new parser for VC-1, for those codecs that do not need/want the timestamp correction.
Sadly i cannot use the ffmpeg parsers without them also correcting timestamps - so i wrote my own (based on the MPC-HC VC-1 parser), which looks for the VC-1 sync bytes and reassembles the MPEG-TS stream into full VC-1 frames, and sends those off to the decoder.
Hmmmm... So there are 3 variations? I can understand the difference between PTS and DTS. But what is the 3rd variation? I understand ffmpeg can output either PTS or DTS. That makes sense. But some of the commercial decoders expect neither PTS nor DTS but something else??

The puzziling part of the story is VC-1 in MKV. For some reason, its backwards. The container timestamps are just fine for MPC-HC and the WMVideo Decoder, but for the commercial decoders i have to activate ffmpegs parsing.
That might partially be my fault because eac3to was the first application to properly mux VC-1 Blu-Ray movies to MKV, so I might have defined the timestamp logic for VC-1 MKV muxing... :p And as I said, eac3to simply muxes frames with simple increasing timestamps.

To be honest, I wouldn't know how to produce any other timestamps than those. I mean MPEG2 has a bitsteam field "temporal_reference" which tells us the relation between DTS <-> PTS. h264 has a similar bitstream field, too. But VC-1 has not.

[nevcairiel]

Some months ago I added code to madVR to correct swapped timestamps, because that was the only way to make VC-1 Blu-Rays play correctly with the MPC-HC internal TS splitter. That's probably why you don't see a problem with madVR. It's not really ideal if madVR has to do that, though. If timestamps are swapped madVR does not really know for 100% sure which timestamp originally belonged to which frame. So there's a small danger of audio/video sync being imperfect.

So thats why, neato :p
With latest LAV Splitter, i could not get it to break again with any of the decoders i tried on EVR, so it might be all better now. :)


Hmmmm... So there are 3 variations? I can understand the difference between PTS and DTS. But what is the 3rd variation? I understand ffmpeg can output either PTS or DTS. That makes sense. But some of the commercial decoders expect neither PTS nor DTS but something else??
No, its just PTS, the only change is that i had to create a parser so i can send exactly one complete frame per media sample. Some of the decoders did not like getting partial frames and re-assembling them themself - this caused them to go weird with the timestamps again. But this is just decoders being buggy, i figure.

ffmpeg has a parser to do this, but it changes the timestamps while doing so. I mostly copied the concept of this from MPC-HC, as it seemed to work there just fine.

[madshi]

No, its just PTS, the only change is that i had to create a parser so i can send exactly one complete frame per media sample. Some of the decoders did not like getting partial frames and re-assembling them themself - this caused them to go weird with the timestamps again. But this is just decoders being buggy, i figure.

ffmpeg has a parser to do this, but it changes the timestamps while doing so. I mostly copied the concept of this from MPC-HC, as it seemed to work there just fine.
Got it, makes sense. Yeah, I remember some decoders breaking when eac3to muxed partial video frames in some early version. Had to make sure that video frames are completely muxed, otherwise some decoders would show artifacts. So yes, it's definitely a good idea to send whole frames to decoders, not partial frames.

[Midzuki]

Thanks for these very-informative posts. :) :) :)

Now I am sure, VC-1 is a b0rked format, and it is best-stored in b0rked containers like ASF :devil: and AVI :D

[SamuriHL]

Nev or anyone else. I don't have MSVC installed on my HTPC for many reasons. When I try to register the debug LAV Splitter it complains that there's missing dll's. I'm quite sure this is because it doesn't have the debug version of the VC++ 2010 runtime. Where can I get that?

[pankov]

There is no comprehensive list of all types.
Alot of types are simple types based on the FourCC (not even listed anywhere), the others can only be seen in the source, sometimes scattered a bit.

First function in this file, for example, for audio
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=demuxer/Demuxers/LAVFAudioHelper.cpp;h=23a2083009dee434f2539e8b997092edb4d3129f;hb=HEAD

Or here for video:
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=demuxer/Demuxers/LAVFVideoHelper.cpp;h=d38e747a5305ea0bd2a8f5ef5cf5be49f522cb71;hb=HEAD

But thats not all (and of course the symbolic names). :P
Thanks, Nev.
I've found those two links in the MSDN
http://msdn.microsoft.com/en-us/library/dd317599%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/dd407353%28v=vs.85%29.aspx
but sadly they too use the symbolic names. Any idea where I can find the actual values of these constants in format like this {AFBC2343-3DCB-4047-9655-E1E62A61B1C5}? Sadly I don't have Visual Studio. Is there any chance I can get these .h files (mentioned in the articles) separately?

[SamuriHL]

Alright, fine, I just simply set up my laptop so I can use the debug version on here and ran it that way. Hope this helps, Nev, cause it was a major pain in the....yea, anyway. :D



00000000 0.00000000 [6748] Loading modified build of detours library designed for MPC-HC player (http://sourceforge.net/projects/mpc-hc/)
00000001 5.75534630 [6748] LAVSplitter.ax(tid 6c8) 2 : Probed with size=2048 and score=100
00000002 5.75601625 [6748] LAVSplitter.ax(tid 6c8) 3 : [mpegts @ 0044B9A0] stream=0 stream_type=1b pid=1011 prog_reg_desc=HDMV
00000003 5.75655222 [6748] LAVSplitter.ax(tid 6c8) 3 : [mpegts @ 0044B9A0] stream=1 stream_type=81 pid=1100 prog_reg_desc=HDMV
00000004 5.75660229 [6748] LAVSplitter.ax(tid 6c8) 3 : ::Open(): av_open_input_file opened file of type 'mpegts'
00000005 5.79587269 [6748] LAVSplitter.ax(tid 6c8) 43 : [h264 @ 00443250] no picture
00000006 5.91842413 [6748] LAVSplitter.ax(tid 6c8) 165 : [mpegts @ 0044B9A0] Probe buffer size limit 5000000 reached
00000007 5.92643833 [6748] LAVSplitter.ax(tid 6c8) 173 : Stream 0 (pid 4113) - codec: 28; parsing: AVSTREAM_PARSE_FULL;
00000008 5.92648220 [6748] LAVSplitter.ax(tid 6c8) 173 : Stream 1 (pid 4352) - codec: 86019; parsing: AVSTREAM_PARSE_FULL;
00000009 5.94545364 [6748] LAVSplitter.ax(tid 6c8) 192 : Trying to connect Pins :
00000010 5.94551945 [6748] LAVSplitter.ax(tid 6c8) 192 : <Video>
00000011 5.94559050 [6748] LAVSplitter.ax(tid 6c8) 192 : <Video In>
00000012 5.94565296 [6748] LAVSplitter.ax(tid 6c8) 192 : Trying media type:
00000013 5.94575262 [6748] LAVSplitter.ax(tid 6c8) 193 : major type: MEDIATYPE_Video
00000014 5.94665670 [6748] LAVSplitter.ax(tid 6c8) 193 : sub type : Unknown GUID Name
00000015 5.94920778 [6748] LAVSplitter.ax(tid 6c8) 196 : Connection succeeded
00000016 6.19655609 [6748] LAVSplitter.ax(tid 6c8) 443 : Trying to connect Pins :
00000017 6.19659424 [6748] LAVSplitter.ax(tid 6c8) 443 : <Audio>
00000018 6.19667673 [6748] LAVSplitter.ax(tid 6c8) 443 : <SP In>
00000019 6.19674826 [6748] LAVSplitter.ax(tid 6c8) 444 : Trying media type:
00000020 6.19679356 [6748] LAVSplitter.ax(tid 6c8) 444 : major type: MEDIATYPE_Audio
00000021 6.19686174 [6748] LAVSplitter.ax(tid 6c8) 444 : sub type : MEDIASUBTYPE_DOLBY_AC3
00000022 6.19692373 [6748] LAVSplitter.ax(tid 6c8) 444 : Trying media type:
00000023 6.19696760 [6748] LAVSplitter.ax(tid 6c8) 444 : major type: MEDIATYPE_Audio
00000024 6.19705057 [6748] LAVSplitter.ax(tid 6c8) 444 : sub type : Unknown GUID Name
00000025 6.19710350 [6748] LAVSplitter.ax(tid 6c8) 444 : Failed to agree type
00000026 6.21313906 [6748] LAVSplitter.ax(tid 6c8) 460 : Trying to connect Pins :
00000027 6.21317482 [6748] LAVSplitter.ax(tid 6c8) 460 : <Audio>
00000028 6.21321726 [6748] LAVSplitter.ax(tid 6c8) 460 : <In>
00000029 6.21328068 [6748] LAVSplitter.ax(tid 6c8) 460 : Trying media type:
00000030 6.21332550 [6748] LAVSplitter.ax(tid 6c8) 460 : major type: MEDIATYPE_Audio
00000031 6.21340132 [6748] LAVSplitter.ax(tid 6c8) 460 : sub type : MEDIASUBTYPE_DOLBY_AC3
00000032 6.21867990 [6748] LAVSplitter.ax(tid 6c8) 465 : Connection succeeded
00000033 6.41199017 [6748] AMD VLD 32
00000034 6.41624594 [6748] LAVSplitter.ax(tid 1a54) 663 : ::DeliverNewSegment on Video Pin (rtStart: 0; rtStop: 39476169780)
00000035 6.41652870 [6748] LAVSplitter.ax(tid 1a54) 663 : ::DeliverNewSegment on Audio Pin (rtStart: 0; rtStop: 39476169780)
00000036 6.78060675 [6748] LAVSplitter.ax(tid 1a54) 1027 : TIMING: av_read_frame took 38 ms
00000037 11.77170467 [6748] LAVSplitter.ax(tid 1d3c) 6018 : ::DeliverBeginFlush on Video Pin
00000038 11.79533577 [6748] LAVSplitter.ax(tid 1d3c) 6028 : ::DeliverBeginFlush on Audio Pin
00000039 11.79545593 [6748] LAVSplitter.ax(tid 1a54) 6030 : [mpegts @ 0044B9A0] read_seek: 0 16867692
00000040 11.79574776 [6748] LAVSplitter.ax(tid 1a54) 6042 : [mpegts @ 0044B9A0] gen_seek: 0 16867692
00000041 11.79584980 [6748] LAVSplitter.ax(tid 1a54) 6042 : [mpegts @ 0044B9A0] pos_min=0x234 pos_max=0x13a391e54 dts_min=1499 dts_max=983782
00000042 11.79591370 [6748] LAVSplitter.ax(tid 1a54) 6042 : [mpegts @ 0044B9A0] 564 5271789140 5271789140 / 1499 -9223372036854775808 983782 target:16867692 limit:5271789140 start:5271789140 noc:1
00000043 11.79599571 [6748] LAVSplitter.ax(tid 1a54) 6042 : [mpegts @ 0044B9A0] read_timestamp() failed in the middle
00000044 11.79605770 [6748] LAVSplitter.ax(tid 1a54) 6042 : ::Seek() -- Key-Frame Seek failed
00000045 11.79611778 [6748] LAVSplitter.ax(tid 1a54) 6043 : [mpegts @ 0044B9A0] read_seek: 0 16867692
00000046 11.79631805 [6748] LAVSplitter.ax(tid 1a54) 6043 : [mpegts @ 0044B9A0] gen_seek: 0 16867692
00000047 11.79641914 [6748] LAVSplitter.ax(tid 1a54) 6043 : [mpegts @ 0044B9A0] pos_min=0x234 pos_max=0x13a391e54 dts_min=1499 dts_max=983782
00000048 11.79648399 [6748] LAVSplitter.ax(tid 1a54) 6043 : [mpegts @ 0044B9A0] 564 5271789140 5271789140 / 1499 -9223372036854775808 983782 target:16867692 limit:5271789140 start:5271789140 noc:1
00000049 11.79653931 [6748] LAVSplitter.ax(tid 1a54) 6043 : [mpegts @ 0044B9A0] read_timestamp() failed in the middle
00000050 11.79661179 [6748] LAVSplitter.ax(tid 1a54) 6043 : ::Seek() -- Inaccurate Seek failed as well
00000051 11.79688263 [6748] LAVSplitter.ax(tid 1d3c) 6043 : ::DeliverEndFlush on Video Pin
00000052 11.83045864 [6748] LAVSplitter.ax(tid 1d3c) 6077 : ::DeliverEndFlush on Audio Pin
00000053 11.83066273 [6748] LAVSplitter.ax(tid 1a54) 6077 : ::DeliverNewSegment on Video Pin (rtStart: 1870317583; rtStop: 39476169780)
00000054 11.83109570 [6748] LAVSplitter.ax(tid 1a54) 6078 : ::DeliverNewSegment on Audio Pin (rtStart: 1870317583; rtStop: 39476169780)
00000055 11.83964157 [6748] LAVSplitter.ax(tid 1d3c) 6086 : ::DeliverBeginFlush on Video Pin
00000056 11.84001732 [6748] LAVSplitter.ax(tid 1d3c) 6087 : ::DeliverBeginFlush on Audio Pin
00000057 11.84013462 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] read_seek: 0 31680608
00000058 11.84018707 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] gen_seek: 0 31680608
00000059 11.84049511 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] pos_min=0x234 pos_max=0x13a391e54 dts_min=1499 dts_max=983782
00000060 11.84058571 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] 564 5271789140 5271789140 / 1499 -9223372036854775808 983782 target:31680608 limit:5271789140 start:5271789140 noc:1
00000061 11.84064102 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] read_timestamp() failed in the middle
00000062 11.84068584 [6748] LAVSplitter.ax(tid 1a54) 6087 : ::Seek() -- Key-Frame Seek failed
00000063 11.84073544 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] read_seek: 0 31680608
00000064 11.84078503 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] gen_seek: 0 31680608
00000065 11.84102249 [6748] LAVSplitter.ax(tid 1a54) 6087 : [mpegts @ 0044B9A0] pos_min=0x234 pos_max=0x13a391e54 dts_min=1499 dts_max=983782
00000066 11.84111309 [6748] LAVSplitter.ax(tid 1a54) 6088 : [mpegts @ 0044B9A0] 564 5271789140 5271789140 / 1499 -9223372036854775808 983782 target:31680608 limit:5271789140 start:5271789140 noc:1
00000067 11.84116268 [6748] LAVSplitter.ax(tid 1a54) 6088 : [mpegts @ 0044B9A0] read_timestamp() failed in the middle
00000068 11.84120560 [6748] LAVSplitter.ax(tid 1a54) 6088 : ::Seek() -- Inaccurate Seek failed as well
00000069 11.84125423 [6748] LAVSplitter.ax(tid 1d3c) 6088 : ::DeliverEndFlush on Video Pin
00000070 11.84368038 [6748] LAVSplitter.ax(tid 1d3c) 6090 : ::DeliverEndFlush on Audio Pin
00000071 11.84382725 [6748] LAVSplitter.ax(tid 1a54) 6090 : ::DeliverNewSegment on Video Pin (rtStart: 3516197056; rtStop: 39476169780)
00000072 11.84428787 [6748] LAVSplitter.ax(tid 1a54) 6091 : ::DeliverNewSegment on Audio Pin (rtStart: 3516197056; rtStop: 39476169780)

[robpdotcom]

I was trying out 0.22 today and noticed something I hadn't noticed before - TrueHD would not get bitstreamed by ffdshow when using LAVSplitter for mkv. For some reason, even though it is set to bitstream, ffdshow insists on decoding it. I also checked with version 0.19, and it did the same thing.

ts and m2ts give no problems, and I have no problem with mkv when using Haali or Gabest. I tried with several versions of ffdshow, and even with a TrueHD+AC3 stream muxed to mkv via SMM muxer.

[mindbomb]

possible lav splitter bug- dtshd tracks muxed with a delay with mkvmerge aren't recognized

http://www.mediafire.com/?avtg2vztfhp8467

~35 MB sample, ignore the fact the video doesnt match the audio, that part was intentional.

[nevcairiel]

Alright, fine, I just simply set up my laptop so I can use the debug version on here and ran it that way. Hope this helps, Nev, cause it was a major pain in the....yea, anyway. :D



If by helping you mean telling me that ffmpeg simply doesn't like the file, well, then yes!

[f@chance]

I have tried for the first time these splitter and audio filters and like them very much. Just a quick question though when using the LAV splitter and audio decoder I no longer get AC3 passthrough on just plain vanilla hdtv capped transport streams, is that by design or is there a setting that will enable bit streaming?

When I use the FFDshow audio decoder and the LAV splitter passthrough and bitstreaming works.

[nevcairiel]

My filters do not yet support bitstreaming. You'll have to use ffdshow if you want that.

[f@chance]

Thanks, I'll look forward to the time when you can implement this.

[Dogway]

No problem here using Nevcairiel-LAVFSplitter-0.21-26-gd96cd94 (http://www.multiupload.com/3SL36ZVRNI)

I see Graphstudio has no problems so guilty must be MPC, what version are you using? I even started from scratch again installing nVidia drivers,MPC-HC, LAVSplitter,LAVCUVID,madVR,ffdshow.
ffdshow defaults higher merit than LAVCUVID so I have to prefer it in MPC...

[CruNcher]

Nev did you take a look @ the sample_hd.ts stream (Hauppauge HDPVR record) and the wrong starttime (unsync issue) correction if Video Parsing is Enabled (when Video Parsing is disabled it's ok but that brakes 2 other samples 1 which goes unsync and another which stays entirely black (video)) i will try not to mention that another specific Splitter works with this as it seems you start to react allergic on that ;)
Though that specific filter also has years of development behind it so i guess it would take some time bringing your splitter to that stability (as their support already munched a lot of samples in those years in a dshow enviroment)

[Mercury_22]

I see Graphstudio has no problems so guilty must be MPC, what version are you using? I even started from scratch again installing nVidia drivers,MPC-HC, LAVSplitter,LAVCUVID,madVR,ffdshow.
ffdshow defaults higher merit than LAVCUVID so I have to prefer it in MPC...

See my Signature:)

[SamuriHL]

If by helping you mean telling me that ffmpeg simply doesn't like the file, well, then yes!

Hey I told you it was likely the file that was bad! :) However, just so you fully understand and are prepared for the future, that file was recorded on an HD PVR connected to a very finicky cable box. (It was a recording of the last episode of The Walking Dead which I still haven't actually had time to watch.) I'm telling you this for one reason only....because that thing creates REALLY messed up streams and you're likely to get a bunch of "broken" files posted from those devices. I spent months working with the Video ReDo guys providing them samples so that they could make Video ReDo very robust. That's why I wasn't worried. I know VRD handles them and I can run it through that and output perfectly fine files. It's just that you're going to see the inevitable "well, the internal splitter is fine with it" types of posts. I personally don't care and if you're not worried about it then we're all good.

[SamuriHL]

Nev did you take a look @ the sample_hd.ts stream (Hauppauge HDPVR record) and the wrong starttime (unsync issue) correction if Video Parsing is Enabled (when Video Parsing is disabled it's ok but that brakes 2 other samples 1 which goes unsync and another which stays entirely black (video)) i will try not to mention that another specific Splitter works with this as it seems you start to react allergic on that ;)
Though that specific filter also has years of development behind it so i guess it would take some time bringing your splitter to that stability (as their support already munched a lot of samples in those years in a dshow enviroment)

Oh look, Nev.....I think my point is proven. :D ROFLMAO! :p

[CruNcher]

My solution would be try to detect something specific about the HDPVR recordings and then turn of Video Parsing only for them as this fixes all samples i have here, it would be also the least invasive in terms of code changes that could brake other things ;)

@SamuriHL
do you have only sync issues or are their other problems as well with your recordings and LAV Splitter ?
could you provide a sample that shows other issues (no unsync ones) ?

I guess a big part here plays the ADTS muxing of the AAC streams, so detecting ADTS and then turning of Video Parsing could be a fix already, though a naughty one ;)

[Mark_A_W]

nevcairiel

I'm just now giving your splitter a go. I've searched through the thread and have found some discussions about timestamps.

I'm having slightly incorrect/strange behaviour for HD-DVD sourced VC-1 23.976fps mkv files (well, they were kinda 60i on the disc...HD-DVD was messy in this regard).

The results for the VC-1 Timestamp correction:

- Enabled: Reclock and madVR report 29.970 fps, video plays FAST, audio at normal rate, lipsync is immediately lost.

- Auto: Same as above.

- Disabled (checkbox cleared): Reclock reports 23.976 (correctly), madVR reports (29.970), playback is at correct speed.
From memory madVR just reports what the splitter tells it, so I think the splitter Timestamp Correction (or at least reporting) is probably doing the technically correct thing, it's just that it's wrong for these HD-DVD VC-1 streams. It's cosmetic only I think, but it's annoying/confusing.

Sorry if this has been mentioned before, I couldn't find it with a search (and there are 79 pages...).

Mark

[SamuriHL]

My solution would be try to detect something specific about the HDPVR recordings and then turn of Video Parsing only for them as this fixes all samples i have here, it would be also the least invasive in terms of code changes that could brake other things ;)

Good luck with that. There's nothing that I've seen that signify that it's an HD PVR recording. My advice to you is simple. Buy yourself a copy of VRD and run them through the stream fixer. :) You'll be doing yourself a huge favor.

[CruNcher]

Im not sure what to think about a Product where its developers give up on their own code and seek for help @ a 3rd party (though in investment time and providing fast fixes nothing wrong with that, if you stuck and need to stay competitive on time) ;)

[SamuriHL]

Fwiw I'm not a developer. I'm a user that's telling you a potential solution. What Nev does is up to him.

[CruNcher]

Good luck with that. There's nothing that I've seen that signify that it's an HD PVR recording. My advice to you is simple. Buy yourself a copy of VRD and run them through the stream fixer. You'll be doing yourself a huge favor.

sorry it was meant to be an answer for that part forget to quote and Bold
If i understand it right from everything i read Nevs Personal main goal is Blu-Ray .m2ts
though doesn't mean that others can't contribute with other preferences therefore it's open source :)
Though for other Devs to go in i guess it would be a good thing to post up in the Main thread which posted files are still problematic in some way to get some overview also based on the different container :)

[SamuriHL]

Like I said, I'm merely giving you an opinion based on my several year's experience as an HD pvr owner. In fact I have 2 of them. The streams they produce are flawed. Vrd fixes them. You can attempt to harass Nev further to deal with these files but I'm guessing that won't get very far.

[CruNcher]

As i said it would be helpfull if you could provide samples that show other problems then the unsync issue (as this is half fixed ;) )

[nevcairiel]

I'm having slightly incorrect/strange behaviour for HD-DVD sourced VC-1 23.976fps mkv files (well, they were kinda 60i on the disc...HD-DVD was messy in this regard)


Which decoder did you use?
ffdshow/MPC-HC internal fail on those files because they don't understand the pulldown flags in the files, so it plays them as 29.97 (also happens with the original HD-DVD content), but decoders like Cyberlink, ArcSoft or my own LAV CUVID play them just fine. (at least did the original EVO files, didn't have a MKV)

I do not have direct influence on what the FPS value is, i just report what ffmpeg detected, and yes, it mis-detects those files as well. For the same reason, i cannot detect if a file is really 29.97 or just wrongly detected 23.976, so i cannot dynamically turn the option on/off for these files.

Sadly, you'll have to live with it, but at least knowing that HD-DVD is a dead format and there won't be any new releases for it. :)

PS:
This is only happening because ffmpeg does not trust the values stored in the container, it has to go probe the stream and figure out whats in it. On really broken files this just has advantages, i guess, however on sanely muxed files, stuff like this happens - oh well, can't have it all.

[nevcairiel]

Re: File Source (Async) support

I talked about this before, but i would like to explain in detail what this means for the next LAV Splitter version.

I added support to LAV Splitter today for using a IAsyncReader to supply data to the demuxers. This means it can now connect to the "File Source (async)" filter, it does not have to open the file itself anymore.
This was added for multiple reasons, for one its much easier to work together with other splitters this way, especially the MS splitters, or the stand-alone MPC-HC splitters, and secondly, it also allows other streaming filters to supply data to LAV Splitter.

In the list of registered filters, you will now see two LAV Splitter instances, one "LAV Splitter Source", which is the "old" version of the filter, which acts like a Source filter, and a second, just plain "LAV Splitter", which is the filter that connects to the File Source (Async).

Now, why would you care, you ask?
The default mode changed. I changed the filter registration, so that by default, it always tries to go through the "File Source (Async)", except for BluRays.
To adjust to this change, you have quite some options.

- Adjust your external filter configs so that it prefers the "File Source (Async)" as a source filter, and add the "new" "LAV Splitter" filter to the preferred list as well (you can do this by just disabling all other source filters, of course)
- If you can control source filters by file extension (some players do that, not MPC-HC though), you can just keep using "LAV Splitter Source", it still works as before.
- You can use the installer (i got clsid's script, going to toy with it a bit and provide an installer for 0.23), which can manually assign "LAV Splitter Source" to be used for the selected extensions.

Another bonus side effect of this change is that LAV Splitter can now demux a whole lot of other formats without registry hacking. MPC-HC, for example, always trys to load the File Source (Async), for any file, and will always try to connect it to LAV Splitter - that means i can ask ffmpeg to probe and try to demux the file, and if its supported, it'll just start playing. Formats do not need to be registered manually anymore. I don't know which other players always insert the File Source as a backup filter, but heck, its a useful feature in MPC-HC. :)

Oh, another bonus feature, you should now be able to use it without registering it first in MPC-HC through the external filter list (again, except for BluRays)

In addition to these changes, i'll be implementing a new interface soon which will let you select which file formats it should be active for, so you have a fine-grained control over this from within the filter.

If you have any questions concerning this change, please just ask.

@Blight: This also fixes the MPEG-PS media type issue.

[Mercury_22]

LAVSplitter.ax x64 version Nevcairiel-LAVFSplitter-0.22-7-g011e934 won't register !!!

[nevcairiel]

LAVSplitter.ax x64 version Nevcairiel-LAVFSplitter-0.22-7-g011e934 won't register !!!

Fixed.

[CruNcher]

Re: File Source (Async) support

I talked about this before, but i would like to explain in detail what this means for the next LAV Splitter version.

I added support to LAV Splitter today for using a IAsyncReader to supply data to the demuxers. This means it can now connect to the "File Source (async)" filter, it does not have to open the file itself anymore.
This was added for multiple reasons, for one its much easier to work together with other splitters this way, especially the MS splitters, or the stand-alone MPC-HC splitters, and secondly, it also allows other streaming filters to supply data to LAV Splitter.

In the list of registered filters, you will now see two LAV Splitter instances, one "LAV Splitter Source", which is the "old" version of the filter, which acts like a Source filter, and a second, just plain "LAV Splitter", which is the filter that connects to the File Source (Async).

Now, why would you care, you ask?
The default mode changed. I changed the filter registration, so that by default, it always tries to go through the "File Source (Async)", except for BluRays.
To adjust to this change, you have quite some options.

- Adjust your external filter configs so that it prefers the "File Source (Async)" as a source filter, and add the "new" "LAV Splitter" filter to the preferred list as well (you can do this by just disabling all other source filters, of course)
- If you can control source filters by file extension (some players do that, not MPC-HC though), you can just keep using "LAV Splitter Source", it still works as before.
- You can use the installer (i got clsid's script, going to toy with it a bit and provide an installer for 0.23), which can manually assign "LAV Splitter Source" to be used for the selected extensions.

Another bonus side effect of this change is that LAV Splitter can now demux a whole lot of other formats without registry hacking. MPC-HC, for example, always trys to load the File Source (Async), for any file, and will always try to connect it to LAV Splitter - that means i can ask ffmpeg to probe and try to demux the file, and if its supported, it'll just start playing. Formats do not need to be registered manually anymore. I don't know which other players always insert the File Source as a backup filter, but heck, its a useful feature in MPC-HC. :)

Oh, another bonus feature, you should now be able to use it without registering it first in MPC-HC through the external filter list (again, except for BluRays)

In addition to these changes, i'll be implementing a new interface soon which will let you select which file formats it should be active for, so you have a fine-grained control over this from within the filter.

If you have any questions concerning this change, please just ask.

@Blight: This also fixes the MPEG-PS media type issue.

a dream in customizeability as used from MPC-HC main source selection and makes debugging also a hell lot more efficient as testing is already consuming time enough,really great work Nev if progress stays stable and more come over also from the MPC-HC splitter devs it would be awesome and hopefully in no time we would have a stable ffmpeg input for dshow where we can even exchange with them and improve :)
I hope it will work efficient in load/unload so that you wont need to close MPC-HC for the changes to become effective ?
Though this here is a good question http://forum.doom9.org/showthread.php?t=160560 and on which side is lav splitter going to sync with (non dshow specific improvements) ?
http://www.golem.de/1104/82702.html

[Mark_A_W]

Which decoder did you use?
ffdshow/MPC-HC internal fail on those files because they don't understand the pulldown flags in the files, so it plays them as 29.97 (also happens with the original HD-DVD content), but decoders like Cyberlink, ArcSoft or my own LAV CUVID play them just fine. (at least did the original EVO files, didn't have a MKV)

I do not have direct influence on what the FPS value is, i just report what ffmpeg detected, and yes, it mis-detects those files as well. For the same reason, i cannot detect if a file is really 29.97 or just wrongly detected 23.976, so i cannot dynamically turn the option on/off for these files.

Sadly, you'll have to live with it, but at least knowing that HD-DVD is a dead format and there won't be any new releases for it. :)

PS:
This is only happening because ffmpeg does not trust the values stored in the container, it has to go probe the stream and figure out whats in it. On really broken files this just has advantages, i guess, however on sanely muxed files, stuff like this happens - oh well, can't have it all.

I'm using ffdshow, but internally it is using wmv9.

Arcsoft gives me the 29/29 reporting, but plays at the correct speed - reclock yellow.

CUVID is for nvidia only isn't it?


Thanks.

Mark

[SamuriHL]

Nev, what happened to git?


git.exe submodule update --init

Submodule 'ffmpeg' (git://git.1f0.de/ffmpeg.git) registered for path 'ffmpeg'
Submodule 'libbluray' (git://git.1f0.de/libbluray.git) registered for path 'libbluray'
Cloning into ffmpeg...
fatal: reference is not a tree: fb7a95d7b12e965b14acbdb01c06261d91cb7a54
Unable to checkout 'fb7a95d7b12e965b14acbdb01c06261d91cb7a54' in submodule path 'ffmpeg'


I thought I broke something local and have pulled a clean branch but um, yea.

[nevcairiel]

I havent touched the ffmpeg thingys for a while, dunno why its acting up - will check later what happend.

Btw, you only need to do --init once after initial checkout, pure update should be good otherwise.


I'm using ffdshow, but internally it is using wmv9.

Arcsoft gives me the 29/29 reporting, but plays at the correct speed - reclock yellow.

The reporting is unimportant, its just hints for the initial connection, whats important is the actual frame rate of the movie going out after decoding, which ArcSoft seems to do fine.

[Kurtnoise]

Another bonus side effect of this change is that LAV Splitter can now demux a whole lot of other formats without registry hacking. MPC-HC, for example, always trys to load the File Source (Async), for any file, and will always try to connect it to LAV Splitter - that means i can ask ffmpeg to probe and try to demux the file, and if its supported, it'll just start playing. Formats do not need to be registered manually anymore. I don't know which other players always insert the File Source as a backup filter, but heck, its a useful feature in MPC-HC. :)

I tried to load several wtv files using your last commits but MPC-HC uses MS filters to split them. Is it because wtv files extension registers his own filters ?

Anyway, thanks for your work.

[nevcairiel]

.wtv has probably a special filter by MS. You'll need to change the extension configuration in the registry - the installer will be able to do this.

Note that i have not tested a single wtv with the splitter. hey, i haven't even seen such a file yet. :)

[thuan]

Might I ask do you intend to implement linked MKV file support. If so how urgent is it on your priority list?

[nevcairiel]

Might I ask do you intend to implement linked MKV file support. If so how urgent is it on your priority list?

Very low priority.

[SamuriHL]

I havent touched the ffmpeg thingys for a while, dunno why its acting up - will check later what happend.

Btw, you only need to do --init once after initial checkout, pure update should be good otherwise.


I don't know what's going on but I can't pull the ffmpeg code at ALL now. I keep getting the same error over and over again. I've completely wiped out my local dir and started over and get the same error. This sucks as I've been happily building for days now. Anyone have any ideas? Whenever I try to pull ffpmpeg, it just errors out completely.

[nevcairiel]

I'm going home in an hour, going to check it then.

[SamuriHL]

Thanks, Nev. Definitely appreciate it.

[SamuriHL]

Ok, I got it working again. I have NO IDEA HOW OR WHY, though. After all those stupid windows updates yesterday my machine's been very tempermental. Anyway, it seems all is well and I'm building again. Now to figure out my ffdshow problem. Stupid thing is prompting me for user creds when it gets to the boost part of the update. I can't win.

[nevcairiel]

It was actually my fault, my local ffmpeg didn't seem to match the one in the repository, fixed now.

[Kurtnoise]

@Nevcairiel : i'll give you some files asap if you want...

[SamuriHL]

It was actually my fault, my local ffmpeg didn't seem to match the one in the repository, fixed now.

Ah, ok. Thank you for fixing it. I was going nuts.