Log in

View Full Version : Alternative Matroska Splitter (Haali)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20

Atak_Snajpera
19th May 2008, 06:57
Yes! I use RGB32 in ffdshow. I need RGB for accurate black and reds under vista.

Liisachan
19th May 2008, 07:02
I can't explain this clearly, but a "normal" (positive-height) Windows Bitmap (DIB) is bottom-up. That is, the first line is the bottom line, the second line is the next (2nd from the bottom) and so on. Whereas in the usual graphic coordinates, things go top down. The first line is the topmost line, the second line is just below that and so on. This could be confusing. To make it even more confusing, some (bad) decoders may decode the image top-down, and still reports a positive height. (OR decoding the image bottom-up and reporting a negative height) Anyway RGB can be both top-down and bottom-up so output image can be upside down if anything is screwed up. That's what I can say from my limited knowledge.

Mercury_22
27th May 2008, 11:19
Any chance for a 64-bit version ?

cm_uk
27th May 2008, 11:22
Im using vista media center and im getting constant crashes when i browse files in my video library after (and only after) ive watched a film, it happens if im using coreavc or ffdshow so im thinking its the mkv splitter or one of its associated programs thats causing the issue. I used to get a data execution error that crashed at the same point (so i turned dep off) but im still getting the crash (just not a dep one). I have generated thumb nails in my video library.

Can anyone tell me what is going on?? Ive installed the latest ccp but it doesnt make any difference.

Apart from this the splitter is awesome, thanks for your hard work.

bmnot
4th August 2008, 05:50
Any updates in the pipeline?

ADude
8th August 2008, 19:04
I've found that the latest version of Haali Media Splitter (29 March 2008) does not work properly with MPEG-1 videos - they stop at the beginning and state that the file is length 0:00.

If I use MPC-HC internal media splitter for MPEG-1, it is fine, but I want to use Haali Media Splitter for MPEG2 TS/PS, so it would be helpful if this were fixed (since MPC-HC requires one splitter to do all MPEG-1 and MPEG-2 video).

sneaker_ger
21st August 2008, 14:56
I have two feature requests:
It would be nice if the automatic subtitle and audio switcher could use the name instead of the language of the tracks, if the language hasn't been set for any of the tracks.
For example with 2 tracks:
S: English [Undetermined]
S: German [Undetermined]
and the option set to "ger,eng" then the second track should be chosen, not the first one.

It would also be nice if the option wasn't case sensitive. In a different thread a user set it to "Dut" and was wondering why it did not work.

TheShadowRunner
21st September 2008, 04:43
And another little request, but for the installer (for next version, if)
please make an option to NOT alter file association, icons and context menu and basically don't do any shell changes.
Last time I updated Haali, i had to clean the mess for at least 20 minutes. I don't need new icons/association with WMP/file types at all. Actually, it would be fantastic if Haali (also) came WITHOUT an installer.
On another note, thanks for the best splitter. ;)
See you,

TSR

clsid
21st September 2008, 13:58
You can extract the files from the installer with 7-zip ;) But don't come asking for help here if things don't work after manual registration of the filters.

ricardo.santos
21st September 2008, 14:51
And another little request, but for the installer (for next version, if)
please make an option to NOT alter file association, icons and context menu and basically don't do any shell changes.

I'll second that request.

Jeff Flowerday
2nd November 2008, 07:38
I'm having problems with LPCM streams in m2ts containers. The channels are getting all sent to my back speakers and eventually just die into white noise when using the Haali splitter. If I switch to the AC3 track all is fine.

Anyone seen this before?

nautilus7
2nd November 2008, 12:26
It's a known bug with haali media splitter and m2ts files. Use mpc-hc and its internal splitter for pcm.

Jeff Flowerday
2nd November 2008, 19:01
It's a known bug with haali media splitter and m2ts files. Use mpc-hc and its internal splitter for pcm.

I need a directshow splitter that will will work in windows media player and then media portal.

nautilus7
2nd November 2008, 20:46
It comes as standalone splitter also. Ask the guys in the mpc-hc thread to compile the latest for you.

Jeff Flowerday
3rd November 2008, 16:57
It comes as standalone splitter also. Ask the guys in the mpc-hc thread to compile the latest for you.

I found the latest builds for the standalone splitter. Unfortunately it doesn't work very well either. I'm not sure if I'm missing something but, I'll try actually playing my files in mpc-hc tonight which should tell me one way or another.

TheShadowRunner
9th November 2008, 03:22
Small bug report on Haali media splitter for .MOV format:
If I use Haali to split this file http://anon.nasa-global.edgesuite.net/qt.nasa-global/ksc/ksc_061108_glast_launch_1080i.mov , I'm getting crazy stuttering/frameskip for some reason.
If I replace Haali with Gabest's MP4Splitter (latest guliverkli2 build), it works just fine.
Everything else in the chain remains unchanged (decoder, renderer, etc..) so it must be an issue with Haali splitter?
See you,

TSR

cc979
9th November 2008, 12:35
Small bug report on Haali media splitter for .MOV format:
If I use Haali to split this file http://anon.nasa-global.edgesuite.net/qt.nasa-global/ksc/ksc_061108_glast_launch_1080i.mov , I'm getting crazy stuttering/frameskip for some reason.
If I replace Haali with Gabest's MP4Splitter (latest guliverkli2 build), it works just fine.
Everything else in the chain remains unchanged (decoder, renderer, etc..) so it must be an issue with Haali splitter?
See you,

TSR

if i remember correctly, there was a timestamp issue before with SVQ3 files and it was a problem with ffdshow-show

TheShadowRunner
9th November 2008, 13:59
if i remember correctly, there was a timestamp issue before with SVQ3 files and it was a problem with ffdshow-show

Hmm possibly but then how come it works fine with Gabest mp4 splitter ? ^^;
See you,

TSR

cc979
9th November 2008, 21:29
I think its something about .mov containers, and timestamps not been passed on

pelle412
15th November 2008, 12:02
There's something about Haali's renderer that's been bugging me for quite a while. If I select it as the directshow video option in MPC, any 1280x720 movie I select always gets displayed at a 640 width. The MPC file properties also say it's only 640 wide. Any attempts at resizing the window doesn't change the size of the video at all. Has anyone experienced this also?

If I use another renderer the video resolution appear correctly.

73ChargerFan
15th November 2008, 19:14
What resolution monitor are you using? If the movie cannot be shown at 100% resolution, then this renderer automatically displays at 50%. By design. I don't like it either.

pelle412
15th November 2008, 21:24
I use 1280x1024, so yes that could be it then. There should be a way to disable that I hope.

haruhiko_yamagata
21st December 2008, 14:23
I found access units are missing after seeking with Haali Media Splitter and H.264 on MPEG2-TS container.
Sample file: premiere-paff.ts (http://x264.nl/h.264.samples/premiere-paff.ts).
When I seek in the file using ffdshow + your splitter, I see garbled images.
Not always, 5% or so.

I dug into this issue and found it. CoreAVC works fine, but I'm not surprised, as workaround is possible.
But the workaround is a bit hard and I don't want to break libavcodec too much.
This issue is not observed using ffdshow+Elacard's splitter.

One access unit is dropped at the later stage of seeking.
After seeking, ffdshow find an entry point and starts decoding.
ffdshow gets a good first image and deliver it to the renderer.
Then the filter graph change to 'Run' state.
It seems one field of a frame is dropped before 'Run' and the complementary field pair is delivered after 'Run'.

Because the dropped unit is a (top or bottom) field of a frame, libavcodec lose coupling of complementary field pair, thus goes into garbled image. In this regard, it's a bug of libavcodec, lack of error recognition. For current libavcodec to work, if one field picture is dropped, a complementary field pair has to be dropped either.

Below is debug output of ffdshow (with custom logging code).
dropable means it's a non-ref (usually B-) frame (s->dropable= h->nal_ref_idc == 0;).
frame_num is the H.264's official frame_num.
DPRINTF(_l("TffdshowVideoInputPin::Receive %d"),pSample->GetActualDataLength());
ffdshow prints the size of received date at the first line of its input pin.


Normal (taken while playing normally)

TffdshowVideoInputPin::Receive 74963
s->dropable 0 h->frame_num 32
TffdshowVideoInputPin::Receive 48328
s->dropable 0 h->frame_num 32
TffdshowVideoInputPin::Receive 26167
s->dropable 1 h->frame_num 33
TffdshowVideoInputPin::Receive 27071
s->dropable 1 h->frame_num 33
TffdshowVideoInputPin::Receive 70714
s->dropable 0 h->frame_num 33
TffdshowVideoInputPin::Receive 47448
s->dropable 0 h->frame_num 33
TffdshowVideoInputPin::Receive 24878
s->dropable 1 h->frame_num 34
TffdshowVideoInputPin::Receive 26201
s->dropable 1 h->frame_num 34
TffdshowVideoInputPin::Receive 74064
s->dropable 0 h->frame_num 34
TffdshowVideoInputPin::Receive 49634
s->dropable 0 h->frame_num 34
TffdshowVideoInputPin::Receive 26102
s->dropable 1 h->frame_num 35
TffdshowVideoInputPin::Receive 27799
s->dropable 1 h->frame_num 35
TffdshowVideoInputPin::Receive 75079
s->dropable 0 h->frame_num 35
TffdshowVideoInputPin::Receive 50142
s->dropable 0 h->frame_num 35

TffdshowVideoInputPin::Receive 27348
s->dropable 1 h->frame_num 36
TffdshowVideoInputPin::Receive 28822
s->dropable 1 h->frame_num 36

TffdshowVideoInputPin::Receive 75615
s->dropable 0 h->frame_num 36
TffdshowVideoInputPin::Receive 51965
s->dropable 0 h->frame_num 36
TffdshowVideoInputPin::Receive 27979
s->dropable 1 h->frame_num 37


Abnormal (taken after seeking)TffdshowDecVideo::NewSegment thread=2512
TffdshowDecVideoOutputPin::DeliverNewSegment tStart 15543, tStop 33800
queue->NewSegment
TffdshowVideoInputPin::Receive 33344
TffdshowVideoInputPin::Receive 69828
TffdshowVideoInputPin::Receive 34534
TffdshowVideoInputPin::Receive 73223
TffdshowVideoInputPin::Receive 39126
TffdshowVideoInputPin::Receive 67003
TffdshowVideoInputPin::Receive 37677
TffdshowVideoInputPin::Receive 66365
TffdshowVideoInputPin::Receive 40264
TffdshowVideoInputPin::Receive 68995
TffdshowVideoInputPin::Receive 42618
TffdshowVideoInputPin::Receive 65953
TffdshowVideoInputPin::Receive 40927
TffdshowVideoInputPin::Receive 65343
TffdshowVideoInputPin::Receive 40573
TffdshowVideoInputPin::Receive 64881
TffdshowVideoInputPin::Receive 38674
TffdshowVideoInputPin::Receive 66951
TffdshowVideoInputPin::Receive 38127
TffdshowVideoInputPin::Receive 68041
TffdshowVideoInputPin::Receive 39774
TffdshowVideoInputPin::Receive 71970
TffdshowVideoInputPin::Receive 40717
TffdshowVideoInputPin::Receive 77345
TffdshowVideoInputPin::Receive 43849
TffdshowVideoInputPin::Receive 82649
TffdshowVideoInputPin::Receive 44373
TffdshowVideoInputPin::Receive 121746
s->dropable 0 h->frame_num 24
TffdshowVideoInputPin::Receive 57105
s->dropable 0 h->frame_num 24
no picture
TffdshowVideoInputPin::Receive 69378
s->dropable 0 h->frame_num 25
TffdshowVideoInputPin::Receive 45105
s->dropable 0 h->frame_num 25
TffdshowVideoInputPin::Receive 73096
s->dropable 0 h->frame_num 26
TffdshowVideoInputPin::Receive 52738
s->dropable 0 h->frame_num 26
TffdshowVideoInputPin::Receive 71124
s->dropable 0 h->frame_num 27
TffdshowVideoInputPin::Receive 54217
s->dropable 0 h->frame_num 27
TffdshowVideoInputPin::Receive 83618
s->dropable 0 h->frame_num 28
TffdshowVideoInputPin::Receive 59106
s->dropable 0 h->frame_num 28
TffdshowVideoInputPin::Receive 87677
s->dropable 0 h->frame_num 29
TffdshowVideoInputPin::Receive 55979
s->dropable 0 h->frame_num 29
TffdshowVideoInputPin::Receive 83603
s->dropable 0 h->frame_num 30
TffdshowVideoInputPin::Receive 55119
s->dropable 0 h->frame_num 30
TffdshowVideoInputPin::Receive 83157
s->dropable 0 h->frame_num 31
TffdshowVideoInputPin::Receive 55313
s->dropable 0 h->frame_num 31
TffdshowVideoInputPin::Receive 74963
s->dropable 0 h->frame_num 32
TffdshowVideoInputPin::Receive 48328
s->dropable 0 h->frame_num 32
TffdshowVideoInputPin::Receive 70714
s->dropable 0 h->frame_num 33
TffdshowVideoInputPin::Receive 47448
s->dropable 0 h->frame_num 33
TffdshowVideoInputPin::Receive 74064
s->dropable 0 h->frame_num 34
TffdshowVideoInputPin::Receive 49634
s->dropable 0 h->frame_num 34
TffdshowVideoInputPin::Receive 75079
s->dropable 0 h->frame_num 35
TffdshowVideoInputPin::Receive 50142
s->dropable 0 h->frame_num 35

TffdshowVideoInputPin::Receive 28822
TffdshowDecVideo::Run
s->dropable 1 h->frame_num 36

TffdshowVideoInputPin::Receive 75615
s->dropable 0 h->frame_num 36
TffdshowVideoInputPin::Receive 51965
s->dropable 0 h->frame_num 36


As you can see, "s->dropable 1 h->frame_num 36" is printed only once (should be twice), because one access unit is missing.
Also many other 'dropable' frames are dropped. I think these frames should be delivered, because there is a delay before the first usable frame is delivered to the renderer. The delay is worse if ffmpeg-mt is used. ffdshow can drop frames if the delivered frames are not necessary.
Could you take a look?

// EDIT: It seems B-frames are dropped until the graph begin running. This isn't a good idea for H.264.
Maybe you had to do so for older ffdshow. Current ffdshow needs those B-frames.

bmnot
11th January 2009, 01:04
11/01/2009
* New Features:
o The shortcut for gdsmux is created in the start menu
* Fixed items:
o Broken Matroska files with looped SeekHeads could cause a hang in Matroska Parser, the number of SeekHeads is now limited to 10
o Removed the workaround to find tags written by Matroska Shell Extension, this caused excessive file scanning when opening files created by recent MKVToolnix
o File linking is now enabled by default
http://haali.cs.msu.ru/mkv/

wiak
11th January 2009, 07:22
haali you around? please for the love of someone
add flac support to muxer and gdsmux :D
so we can encode music video dvds with LPCM 2ch to x264+flac 2ch in mkv

a flac is only 24MB for 3min :thanks:

Rectal Prolapse
11th January 2009, 09:23
It doesn't look like LPCM playback was fixed - at least, it is not mentioned in the changelog. :(

Kurtnoise
11th January 2009, 10:16
add flac support to muxer and gdsmux :D

FLAC support is there since the previous release...

Haali
11th January 2009, 10:40
I found access units are missing after seeking with Haali Media Splitter and H.264 on MPEG2-TS container.
Sample file: premiere-paff.ts (http://x264.nl/h.264.samples/premiere-paff.ts).
When I seek in the file using ffdshow + your splitter, I see garbled images.
Not always, 5% or so.

// EDIT: It seems B-frames are dropped until the graph begin running. This isn't a good idea for H.264.
Maybe you had to do so for older ffdshow. Current ffdshow needs those B-frames.
The splitter starts with a preceding sync point when requested to seek to a certain point in time. To speedup the seek AUs that are not referenced are dropped when processing preroll data up to the requested time.
I thought it was ok to drop nonref H.264 AUs, and it provides a noticeable speedup when seeking.

haruhiko_yamagata
11th January 2009, 13:08
The splitter starts with a preceding sync point when requested to seek to a certain point in time. To speedup the seek AUs that are not referenced are dropped when processing preroll data up to the requested time.
I thought it was ok to drop nonref H.264 AUs, and it provides a noticeable speedup when seeking.
Yes, I can understand that you have done so for speed. However, a few non ref frames that should be displayed are dropped.
As I wrote above, complementary field pair should not be divided. If they are divided, it is irreversible and perfect workaround is theoretically impossible, as far as I can imagine.
I have added workaround at rev 2533 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2533). But this is not correct, because an unpaired field can be a reference field.
As for speed, it is possible to skip decoding non ref frames before the first usable picture in ffdshow. I think I can code it.

Haali
11th January 2009, 13:31
Yes, I can understand that you have done so for speed. However, a few non ref frames that should be displayed are dropped.
As I wrote above, complementary field pair should not be divided. If they are divided, it is irreversible and perfect workaround is theoretically impossible, as far as I can imagine.
I have added workaround at rev 2533 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2533). But this is not correct, because an unpaired field can be a reference field.
As for speed, it is possible to skip decoding non ref frames before the first usable picture in ffdshow. I think I can code it.
But they shouldn't be displayed! If the player requests a seek to time X, usually we can't start decoding right there, and have to start earlier. Of these preroll frames, nothing should be displayed, and they are only needed to update the decoder.

So the question is if it's ok to discard non-reference preroll AUs, that aren't going to be displayed anyway?

My initial thought was it's fine, but now I'm not sure.

leeperry
11th January 2009, 14:35
hi Haali, nice to see you around.....most ppl thought you went AWOL :D

anyway, sorry to nag you with that...but do you have any idea why 25 & 29.97 fps MKV have very stable jitter with Reclock & HR, but not 23.976 ?

it would appear that for 23.976 MKV's, there's too much jitter when the data gets streamed off HMS.

it jitters quite a lot with AC3 in 23.976 MKV, but with DTS in 23.976 MKV it's completely nuts....the Reclock community wishes so much that everything would be as tight as 25 fps MKV.

also if you could force triple buffering, HR would never miss the VSYNC flip...as explained here :
http://software.intel.com/en-us/articles/video-frame-display-synchronization

thanks for reading, and I'll be glad to try any beta version you might be kind enough to build to fix these 2 problems :o

:thanks:

haruhiko_yamagata
11th January 2009, 14:46
So the question is if it's ok to discard non-reference preroll AUs, that aren't going to be displayed anyway?

My initial thought was it's fine, but now I'm not sure.
If the first field of complementary field pair has negative timestamp (preroll), and second field of the pair has positive timestamp (non preroll), the first field should be delivered even if it is not a reference field. (It is possible that two fields have different timestamps.)
Or second field should be dropped.

73ChargerFan
11th January 2009, 17:04
I use your splitter with anydvd-hd to watch blu-ray .m2ts files directly from the bd-disk. TrueHD with embedded AC3 audio streams aren't recognized yet. These work with the MPC-HC built-in .ts splitter, but your splitter is superior for video. DTS-MA streams okay, and my receiver sees the dts core.

Thanks for the new version! Happy New Year!

Thunderbolt8
11th January 2009, 23:55
haali, I recently got to know that the haali renderer has a little too much red colour in the picture, at least for HD content (saw it in screen comparisons, pictures taken with powerdvd and VRM9 look the same, while the picture taken with the haali renderer was a little more reddish). would it be possible for you to fix that as well? I dont want to switch renderer because of that :/
thanks!! :)

haali BT.709 (left) vs avsp with converttorgb24(matrix="rec709") (right)

http://thumbnails6.imagebam.com/2339/496c2523381920.gif (http://www.imagebam.com/image/496c2523381920) http://thumbnails6.imagebam.com/2339/25a49f23381921.gif (http://www.imagebam.com/image/25a49f23381921)

bmnot
12th January 2009, 01:01
haali, I recently got to know that the haali renderer has a little too much red colour in the picture, at least for HD content (saw it in screen comparisons, pictures taken with powerdvd and VRM9 look the same, while the picture taken with the haali renderer was a little more reddish). would it be possible for you to fix that as well? I dont want to switch renderer because of that :/
thanks!! :)

haali BT.709 (left) vs avsp with converttorgb24(matrix="rec709") (right)

http://thumbnails6.imagebam.com/2339/496c2523381920.gif (http://www.imagebam.com/image/496c2523381920) http://thumbnails6.imagebam.com/2339/25a49f23381921.gif (http://www.imagebam.com/image/25a49f23381921)

Yes, I would love that fixed too as your renderer is my favorite one to use :)

Snowknight26
13th January 2009, 00:24
Can't say about older versions, but this new version doesn't seem to detect 2.0 or 1.0 channel PCM tracks in .m2ts files, such as those found on The Third Man Blu-ray or Cassandra's Dream Blu-ray.

Haali
19th January 2009, 09:06
I've made an experimental x64 build of the splitter, it's available at http://haali.net/mkv/mkx.y.7.exe

The installer has both 32 and 64 bit versions, and will install a 64 bit version in addition to 32 bit when run under 64 bit windows.

The release is experimental, and while it works on my test install of Windows 7 Beta, I suspect some rough edges are still there.

Mark_A_W
20th January 2009, 06:02
Thank you for the update Haali.

I have some requests (sorry..).

- Ability to see TrueHd in a m2ts file or straight off a BD (sorry if you already added it, the older version wouldn't do it)

- Ability to describe the streams by type (TrueHD/DTS-MA/AC3/etc.). With generic names it takes trial and error to find the best audio track on a BD.

- Reclock jitter/smoothness tweaks - although I think you may have done some work in this area - my jitter in the Haali Renderer doesn't wander anymore, cheers.

haruhiko_yamagata
20th January 2009, 10:38
I've made an experimental x64 build of the splitter, it's available at http://haali.net/mkv/mkx.y.7.exe

The installer has both 32 and 64 bit versions, and will install a 64 bit version in addition to 32 bit when run under 64 bit windows.

The release is experimental, and while it works on my test install of Windows 7 Beta, I suspect some rough edges are still there.Great news!
I installed on Xp64, but it installs 32 bit version only. Please support Xp64 if it is not too hard.

hubblec4
20th January 2009, 14:54
hallo Haali

i found a small bug. when i mux more than 32 streams (e.g. 1 video, + 5 audio, + 32 subs) only the first 32streams were shown.

hubble

Rectal Prolapse
20th January 2009, 16:59
haali, any chance you can look at the LPCM output corruption issues? The corruption is so bad that it could blow up speakers! :O

Haali
21st January 2009, 10:38
hallo Haali

i found a small bug. when i mux more than 32 streams (e.g. 1 video, + 5 audio, + 32 subs) only the first 32streams were shown.

hubble
This is a limitation of the parser, it supports up to 32 streams in matroska files.

Haali
21st January 2009, 10:39
The updated installer with x64 support is at http://haali.net/mkv/mkx.y.8.exe

leeperry
21st January 2009, 11:54
@Haali : do you think you could try to make the 23.976 MKV jitter as smooth as 25/29.97 in Reclock, or is it a lost cause ?
and would adding triple buffering in HR help to never miss the VSYNC flip time ?

:thanks:

hubblec4
21st January 2009, 13:31
This is a limitation of the parser, it supports up to 32 streams in matroska files.

is it possible to increase that up to 64streams? because when i played the same file in VLC it shows me all streams!
the file was muxed with mkvmergre.

but i use MPC only.


hubble

SBeaver
23rd January 2009, 01:31
I still get ghost lines with my ATI card, guess I'm gonna have to live with using ffdshows' resizer

Mixer73
25th January 2009, 07:43
Hey all,

I am using Haali Media Splitter to enabled playback of mp4 files in Vista MCE, it works great but after I have played the file VMC won't let me delete it. The Haali Splitter tray icon is still there and it seems the Haali Splitter still has the file open.

Anybody else seen this and is there a way to fix it?

leeperry
25th January 2009, 11:23
is there a way to fix it?
yes, don't install the Haali shell extensions...I had the same problem.

Mixer73
26th January 2009, 01:25
yes, don't install the Haali shell extensions...I had the same problem.

I had the shell extension disabled, but maybe I need to try this also.

Currently I only have MP4Splitter in the system and it works well, but only for mp4 and not MKV, but I don't have all that many MKV files.

Thanks for the tip.

slaman
4th February 2009, 06:26
Was the judder issue for properly playing back 23.976FPS ever fixed? Is it in the works? Can anyone shine more light on the issue?

All I know is that my 23.976FPS source MKV has significant judder when I set output frequency to 24Hz on my Toshiba LCD, which accepts 24p... I expect SUPER smooth playback and simply cannot get it.