View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
jmone
21st July 2011, 09:37
I like the new tracker as you can see where stuff is at! ...though when I read the ticket on Blu-ray Navigation / Title Switching I was kinda surprised to read it was such a challenge and has no priority at this stage :(
nevcairiel
21st July 2011, 10:02
Its too complicated to pull off for only a little gain.
Writing a playlist parser is easy, so if any player would want to offer the ability to choose playlists, they could easily do that themself, actually. They would only have to read the playlists, extract the duration, possibly some other factors like number of streams and number of chapters, and then offer a list to the user. When the user chooses, they can just tell LAV Splitter to play that specific playlist.
TBH, this is a far easier solution then trying to do it through LAV Splitter.
There are however some other plans in motion for BD navigation and possibly even menu support, unrelated to LAV Splitter itself. We'll see what the future brings, but don't hold your breath yet.
jmone
21st July 2011, 11:43
Thanks - started a thread on MC16's beta board to see what interest JR have....Please feel free to expand on the idea!
Sven75
21st July 2011, 12:43
@nev: May I pm you with login information for my company's download website? I am currently uploading test clips which are not yet working with your splitter and/or decoder.
I assume that some of the clips just need a proprietary codec which is not available in ffmpeg (like e. g. Lead Video MCMP), but maybe you want to have a look at those files and maybe there is something that can be done. There is also files in there which are working fine in ffdShow - so it's probably just missing media types.
What I noticed when I went through my test files with GraphStudio is that on using the standard video renderer {6BC1CFFA-8FC1-4261-AC22-CFB4CC38DB50} the LAVVideoDecoder does not automatically connect to the renderer and sometimes even refuses to connect to it at all - requiring e. g. ffdShow to go in between and to make it work.
I then changed the renderer to the current MadVR and the problems disappeared which makes me believe that the standard video renderer does not support the colorspaces provided. Could this be the reason for it? I would love to change the default renderer to MadVR on our systems, but I am afraid I cannot (at least yet), because so far this has always led to crashes in PowerPoint 2003/2007.
On top of that, I think PowerPoint 2010 uses a fixed rendering chain (to some degree) and will not rely on the merit system to determine its renderer - which is probably responsible for the other incompatibilites I am experiencing.
Thunderbolt8
21st July 2011, 12:43
One issue that I didn't see but didn't want to spoil your list with my not so good English was about the ordered chapters and "editions" in MKV.!support, then we can finally ditch haali for good ;D
nevcairiel
21st July 2011, 12:45
@nev: May I pm you with login information for my company's download website? I am currently uploading test clips which are not yet working with your splitter and/or decoder.
Sure. All samples are appreciated to make it the all powerful decoder. ;)
What I noticed when I went through my test files with GraphStudio is that on using the standard video renderer {6BC1CFFA-8FC1-4261-AC22-CFB4CC38DB50} the LAVVideoDecoder does not automatically connect to the renderer and sometimes even refuses to connect to it at all - requiring e. g. ffdShow to go in between and to make it work.
I require all renderers to at least accept YV12 or NV12.
Can you check which media type ffdshow connects with when it does? I could add RGB32 as a fallback, i suppose.
The problem with the default renderes is that their format support is usually dependent on what your hardware supports. Its a bit annoying to debug.
clsid
21st July 2011, 14:52
Could you also add support for YUY2 and RGB24?
Haali renderer does not support YV12 and prefers YUY2.
Some basic DirectShow apps/filters require RGB24.
cyberbeing
21st July 2011, 14:58
LAV Video crashes when attempting to output 10bit h264 as P010 to madVR. That XForm-out states it is connecting to madVR with 1024x720 for 1280x720 and 1536x1080 for 1920x1080 while madVR thinks it is connecting with 1280x720 & 1920x1080 may be part of the problem.
Usually madVR will request the decoder output 2048x720 for 1280x720 and 2048x1080 for 1920x1080.
Filter : LAV Video Decoder - CLSID : {EE30215D-164F-4A92-A4EB-9D4C13390F9F}
- Connected to:
CLSID: {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
Filter: madVR Renderer
Pin: Input
- Connection media type:
Video: P010 1536x1080 (16:9) 23.98fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_P010 {30313050-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3888000
cbFormat: 112
VIDEOINFOHEADER:
rcSource: (0,0)-(1920,1080)
rcTarget: (0,0)-(1920,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 1536
biHeight: 1080
biPlanes: 2
biBitCount: 15
biCompression: P010
biSizeImage: 3888000
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0010: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 81 00 00 00 00 00 00 00 10 00 00 00 09 00 00 00 ...............
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 06 00 00 ........(.......
0050: 38 04 00 00 02 00 0f 00 50 30 31 30 80 53 3b 00 8.......P010€S;.
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- Enumerated media type 0:
Video: P010 1920x1080 23.98fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_P010 {30313050-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3888000
cbFormat: 112
VIDEOINFOHEADER:
rcSource: (0,0)-(1920,1080)
rcTarget: (0,0)-(1920,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 1920
dwPictAspectRatioY: 1080
dwControlFlags: 0x00000000
dwReserved2: 0x00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
biPlanes: 2
biBitCount: 15
biCompression: P010
biSizeImage: 3888000
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0010: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 81 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 .......€...8...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 07 00 00 ........(...€...
0050: 38 04 00 00 02 00 0f 00 50 30 31 30 80 53 3b 00 8.......P010€S;.
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
- Connected to:
CLSID: {EE30215D-164F-4A92-A4EB-9D4C13390F9F}
Filter: LAV Video Decoder
Pin: XForm Out
- Connection media type:
Video: P010 1920x1080 23.98fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_P010 {30313050-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 3888000
cbFormat: 112
VIDEOINFOHEADER:
rcSource: (0,0)-(1920,1080)
rcTarget: (0,0)-(1920,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
biPlanes: 2
biBitCount: 15
biCompression: P010
biSizeImage: 3888000
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0010: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 81 00 00 00 00 00 00 00 10 00 00 00 09 00 00 00 ...............
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 07 00 00 ........(...€...
0050: 38 04 00 00 02 00 0f 00 50 30 31 30 80 53 3b 00 8.......P010€S;.
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
nevcairiel
21st July 2011, 14:59
Thats a bug in madVR 0.67, use 0.66 and it works perfectly.
The wrong width in the media type is caused by some fallback code thats supposed to be used for buggy renderers, however it didn't expect this kind of buggyness. :)
Apparently madVR fails to change the allocator, so the buffer is too small for P010, and LAV Video just crashes ... i should probably verify that the buffer is big enough, but that really was never a problem before.
roytam1
21st July 2011, 15:45
I found that I can't connect LAV Audio to MPC Audio Renderer.
With same file but different decoder (CoreAAC/ffdshow/DivX AAC/etc.) I can connect to MPC Audio Renderer.
Pin info with LAV:
Pin
Name Output
Direction PINDIR_OUTPUT
IsConnected FALSE
Offered MediaTypes
Count 1
Type 1 [MEDIATYPE_Audio / MEDIASUBTYPE_IEEE_FLOAT]
majortype MEDIATYPE_Audio
subtype MEDIASUBTYPE_IEEE_FLOAT
formattype FORMAT_WaveFormatEx
bFixedSizeSamples TRUE
bTemporalCompression FALSE
lSampleSize 8
cbFormat 40
WAVEFORMATEXTENSIBLE
WAVEFORMATEX
wFormatTag 65534 (WAVE_FORMAT_EXTENSIBLE)
nChannels 2
nSamplesPerSec 48000
nAvgBytesPerSec 384000
nBlockAlign 8
wBitsPerSample 32
cbSize 22
wSamplesPerBlock 32
dwChannelMask 3
SubFormat MEDIASUBTYPE_IEEE_FLOAT
Pin info from MPC MPA decoder:
Pin
Name Out
Direction PINDIR_OUTPUT
IsConnected FALSE
Offered MediaTypes
Count 1
Type 1 [MEDIATYPE_Audio / MEDIASUBTYPE_PCM]
majortype MEDIATYPE_Audio
subtype MEDIASUBTYPE_PCM
formattype FORMAT_WaveFormatEx
bFixedSizeSamples TRUE
bTemporalCompression FALSE
lSampleSize 4
cbFormat 18
WAVEFORMATEX
wFormatTag 1 (WAVE_FORMAT_PCM)
nChannels 2
nSamplesPerSec 48000
nAvgBytesPerSec 192000
nBlockAlign 4
wBitsPerSample 16
cbSize 0
nevcairiel
21st July 2011, 16:01
Could you also add support for YUY2 and RGB24?
Haali renderer does not support YV12 and prefers YUY2.
Some basic DirectShow apps/filters require RGB24.
Done, It can now output YV12, NV12, YUY2, RGB32, RGB24 for all formats - the preference on the best-matching type, of course.
Additionally, there are type specific types, of course. But those are generally only supported by madVR. ;)
I found that I can't connect LAV Audio to MPC Audio Renderer.
With same file but different decoder (CoreAAC/ffdshow/DivX AAC/etc.) I can connect to MPC Audio Renderer.
MPC Audio Renderer does not support float audio. I generally advice against using it, its not finished.
nevcairiel
21st July 2011, 18:17
WMV, still has AR issues, but didn't think much would change here yet, the MS asf reader outputs the AR as below for 1080p in 16:9,
I figured out why the AR is being lost between the two filters - the MS ASF reader connects with a media type that just says 1440x1080, and later on updates the type with the proper AR.
Source filters usually never update the media type after connection, so thats not supported right now. I'll dig into detecting the AR from the bitstream instead.
VipZ
21st July 2011, 19:00
I figured out why the AR is being lost between the two filters - the MS ASF reader connects with a media type that just says 1440x1080, and later on updates the type with the proper AR.
Source filters usually never update the media type after connection, so thats not supported right now. I'll dig into detecting the AR from the bitstream instead.
Thanks for looking into it, why does Microsoft stuff always have to be such a pain :)
VipZ
21st July 2011, 21:20
Nev, the latest changes with VC1 broke EVO playback. Before that change EVO was perfect.
nevcairiel
21st July 2011, 21:48
Nev, the latest changes with VC1 broke EVO playback. Before that change EVO was perfect.
Added a new check for EVO which should help. Only works if your file is actually named .evo, though. =) Stupid question though, can VC-1 tracks be in other kinds of MPEG-PS files? Not really, no?
VipZ
21st July 2011, 22:04
Added a new check for EVO which should help. Only works if your file is actually named .evo, though. =)
Thanks, you would hope that EVO's are named .evo, so if someone decided to be "smart" well their bad :)
roytam1
22nd July 2011, 03:45
Sorry to bother you but is there any new video branch build?
noee
22nd July 2011, 03:57
Sorry to bother you but is there any new video branch build?
THis is pretty fresh (ffmpeg with mingw4.6.1rel):
LAV_VideoBranch_19402a86b699 (http://www.mediafire.com/download.php?ecwq4c8cx55cqo8)
roytam1
22nd July 2011, 04:48
THis is pretty fresh (ffmpeg with mingw4.6.1rel):
LAV_VideoBranch_19402a86b699 (http://www.mediafire.com/download.php?ecwq4c8cx55cqo8)
Thanks. Just tested and my rmvb clip is still choppy.
nevcairiel
22nd July 2011, 07:03
Then i'll need a rmvb file which demonstrates the problem. All RV30 and RV40 clips i tested play much better now.
roytam1
22nd July 2011, 07:23
Then i'll need a rmvb file which demonstrates the problem. All RV30 and RV40 clips i tested play much better now.
You got a PM.
jmone
22nd July 2011, 11:20
nevcairiel, how does LAVSplitter determine which Audio Track to select by Default in a M2TS Container/Blu structure (if they player does not ask for one)? I've been test muxing content stripped from HD-DVD using eac3to into M2TS/Blu using tsMuxeR with the Video as track 1, E-AC3 as track 2, and a DTS as track 3. The default playback selects the DTS on track 3 over the E-AC3 on track 2. I take it LAVSplitter uses some logic to pick the audio track that is more than "the first one"...
Thanks
Nathan
:) right thread!
nevcairiel
22nd July 2011, 11:25
There is a format priority in place.
10 - Lossless & uncompressed
9 - DTS-HD MA/HRA
8 - DTS ES/96/24
7 - DTS
5 - AC3/EAC3/AAC
I could probably put EAC3 on the same level as DTS 96/24, because it can contain higher sample-rates/bitrate as normal AC3/DTS.
Note that before it reaches the format priority, it first selects the track matching your language, and the one with the highest channel count (more channel = more better, right?)
jmone
22nd July 2011, 11:37
Right, that makes sense to me (and it is great you don't just grab the first stream - something Arcsoft could not get their head around - we want the "best" track not the first).
Anyway - I'm trying muxing some HD-DVD conent to blu structure on BD25 and most of the time I'm able to decoding the EAC3 streams to LPCM but sometimes the result is to big for a 25GB BDR. In these cases, I'm keeping the E-AC3 track and adding a transcoded DTS track for those devices that will not play the E-AC3 track as it is really not part of the Blu spec (eg PS3). Of course on the HTPC this is not an issue with LAVSplitter/Audio as it supports EAC3 just fine but I'd prefer it to grab the EAC3 track instead of the DTS one. Then again I'm probably kidding myself that the original EAC3 track is "better" than the DTS 1.5MB transcoded track but ....
Thanks
Nathan
jmone
22nd July 2011, 11:42
Also - what format priority does TrueHD get (level 9?)
nevcairiel
22nd July 2011, 12:22
TrueHD is in the "Lossless" category (10), as is FLAC.
DTS-HD is 9 because its not easily decodable like TrueHD or FLAC, however most files wont have both TrueHD/FLAC and DTS-HD.
jmone
22nd July 2011, 12:51
The logic works for me... it is great you have thought the priority through and implemented it in this order IMO. FYI - the PS3 is another "dumb" HW device that defaults to playing the first Audio track on a disc, so as it does not like EAC3 (tries to play it as AC3 and you get slo mo video and no audio) it is best to mux the DTS track first.
nevcairiel
22nd July 2011, 16:09
You got a PM.
There doesn't seem to be anything i can do to fix the file. It plays perfectly for a while, then in some small parts it stutters - but the timestamps just are like that...
Real Video is just not designed to be decoded by anything other then the Real Software. All Real Codecs will be off by default in LAV Video - use them at your own risk. :)
clsid
22nd July 2011, 16:16
Can you submit your findings regarding to the RV timestamps upstream? They might already be aware, but perhaps it can trigger them to work on the issue.
Another item for the todo-list: make the splitter compatible with the MS wmv decoder.
nevcairiel
22nd July 2011, 16:18
I dont care enough about Real to do that, sorry.
BelowSky
22nd July 2011, 18:11
How about posting your findings about rv and letting someone ELSE report it to ffmpeg.
"+ Can fully play all Real media without a problem on (x64) and x86"
Having that as a feature is a big fat plus.
VipZ
22nd July 2011, 18:54
Hi Nev
Would it be possible to support Bink files?
I am not sure how easy this may be, but whats the possibility to have an option to automatically add ffdshow video/audio processing in the graph so we may still use LAV for decoding and ffdshow for post processing until LAV has this natively?
Could you let me know what code is responsible to clearing the media extensions on dllreg, did a little looking in demuxer\LAVSplitter\dllmain.cpp but didn't see anything with my useless coding knowledge.
Sorry for the long list :)
Underground78
22nd July 2011, 18:56
I am not sure how easy this may be, but whats the possibility to have an option to automatically add ffdshow video/audio processing in the graph so we may still use LAV for decoding and ffdshow for post processing until LAV has this natively?
That's already possible, just configure ffdshow so that it connects to uncompressed input.
nevcairiel
22nd July 2011, 18:59
Would it be possible to support Bink files?
Samples.
I am not sure how easy this may be, but whats the possibility to have an option to automatically add ffdshow video/audio processing in the graph so we may still use LAV for decoding and ffdshow for post processing until LAV has this natively?
I had the plan a while ago to allow for some smartness so that users could specifiy some filters that get loaded into the graph automatically, mostly for ffdshow video/DirectVobSub, so people get subs.
I should put that in some ticket..
Edit: http://code.google.com/p/lavfilters/issues/detail?id=32
Could you let me know what code is responsible to clearing the media extensions on dllreg, did a little looking in demuxer\LAVSplitter\dllmain.cpp but didn't see anything with my useless coding knowledge.
You were in the right file, you just need to remove the extensions you dont want cleaned from the RegisterSourceFilter calls.
VipZ
22nd July 2011, 19:07
Samples.
I had the plan a while ago to allow for some smartness so that users could specifiy some filters that get loaded into the graph automatically, mostly for ffdshow video/DirectVobSub, so people get subs.
I should put that in some ticket..
Edit: http://code.google.com/p/lavfilters/issues/detail?id=32
You were in the right file, you just need to remove the extensions you dont want cleaned from the RegisterSourceFilter calls.
Thanks. There are some bink samples here http://samples.mplayerhq.hu/game-formats/bink/
in dllmain.cpp to remove the removal on mkv/webm keys,
// MKV/WEBM
RegisterSourceFilter(CLSID_AsyncReader,
MEDIASUBTYPE_Matroska,
L"0,4,,1A45DFA3",
L".mkv", L".mka", L".mks", L".webm");
Would I delete that entirely or just the last line or something?
nevcairiel
22nd July 2011, 19:17
Added Bink.
in dllmain.cpp to remove the removal on mkv/webm keys,
// MKV/WEBM
RegisterSourceFilter(CLSID_AsyncReader,
MEDIASUBTYPE_Matroska,
L"0,4,,1A45DFA3",
L".mkv", L".mka", L".mks", L".webm");
Would I delete that entirely or just the last line or something?
You would make it something like this:
// MKV/WEBM
RegisterSourceFilter(CLSID_AsyncReader,
MEDIASUBTYPE_Matroska,
L"0,4,,1A45DFA3");
VipZ
22nd July 2011, 19:40
Added Bink.
You would make it something like this:
// MKV/WEBM
RegisterSourceFilter(CLSID_AsyncReader,
MEDIASUBTYPE_Matroska,
L"0,4,,1A45DFA3");
Thanks
wpoulson
22nd July 2011, 21:09
Nev,
Thanks a lot for the reply. I am looking forward to giving this all a try.
Does anyone know how to assign a video decoder to override WMF in WMC 64 bit? I know I can use MPC HC as an external player, but would like to use the WMC7 internal player if possible with the LAV filters. Later, when I decide to bitstream HD audio, I will probably use MPC HC for everything.
Thanks for the help
Warren
wpoulson
22nd July 2011, 21:15
You'll need a filter tweaker application thingy to over-rule the default MS filters, and you'll have to find a way to access the filters configuration, because WMC7 does not allow you to open it.
But once thats all done, you will be able to simply play your files and pass the audio directly to your receiver.
Note that at this time LAV Filters do only contain an Audio Decoder, not Video yet - so you can stick with the default decoders there, or grab ffdshow, or wait for LAV Video, which is due soon. :)
You don't need ffdshow. LAV Audio can do all the audio work you require. Pass-through DD and DTS, decode everything else - even pass-through HD audio, if you ever get any.
I should probably implement an option to open the configuration dialog from the start menu, so that part of the whole setup is easier to handle.
Sorry...first reply did not have quote as reference.
Thanks Nev for the reply and answers.
Does anyone know how I can override WMF in WMC7 64 bit so I can assign the LAV video decoder to the default WMC7 player.
Thanks for the help
Messiah
22nd July 2011, 21:34
Does anyone know how I can override WMF in WMC7 64 bit so I can assign the LAV video decoder to the default WMC7 player.
Skark007 3.0beta has added LAV Splitter. Video decoder is not yet in his release, as far as I know.
P.S. it's a shame that WMP is so closed.
Shark007
22nd July 2011, 22:15
Skark007 3.0beta has added LAV Splitter. Video decoder is not yet in his release, as far as I know.
P.S. it's a shame that WMP is so closed.
The video decoder is also included in the current beta release (version 3 - beta 3) which is only 32bit at this time and can be enabled on the H264 TAB.
nevcairiel
22nd July 2011, 22:16
The video decoder is not even included in my release yet. :d
VipZ
22nd July 2011, 22:54
The video decoder is not even included in my release yet. :d
I am already busy coding out ffdshow for decoders in my pack, I anticipate good things from LAV Video :P
noee
22nd July 2011, 23:23
VipZ, just curious, how are you going to handle downmix to Stereo in your pack? Will you retain FFDshow Audio for that function?
VipZ
22nd July 2011, 23:55
VipZ, just curious, how are you going to handle downmix to Stereo in your pack? Will you retain FFDshow Audio for that function?
I am playing with the idea to not dllreg ffsshow.ax and do the video and audio processing reg entries manually, then move over my current reg keys from decoder's to processing and insert into mpc as a manual filter for now. Not the most elegant approach and only suitable for use in MPC, but time will tell how this will play out. I have always preferred to output audio as native and let OS do the up/down mixing as appropriate tho.
Nev's decisions pretty much dictate the direction of my pack now :)
roytam1
23rd July 2011, 09:46
There doesn't seem to be anything i can do to fix the file. It plays perfectly for a while, then in some small parts it stutters - but the timestamps just are like that...
Real Video is just not designed to be decoded by anything other then the Real Software. All Real Codecs will be off by default in LAV Video - use them at your own risk. :)
That files plays quite well in VLC 1.2.0-git.
Can you submit your findings regarding to the RV timestamps upstream? They might already be aware, but perhaps it can trigger them to work on the issue.
I wonder if someone can express what vlc was done about RV30/RV40 codec to libav developers.
EDIT: It seems that VLC did same thing as nevcairiel. Maybe rmvb B-frame timestamps have different meaning (i.e. not useless) that provide stutter-less playback?
nevcairiel
23rd July 2011, 10:25
The b-frame timestamps are useless, they are basically the same as the last P/I frame befoer that. What VLC does is the same, drop the timestamps of all frames that are not references, which are b-frames in Real Video. I don't know why it works with VLC, but looking at the timestamps of the video, its not like there are gaps somewhere to compensate, i just get the frames like this. Its not dropping any frames when its stuttering, they just come in with time-gaps in them, like there are frames missing.
Maybe its the ffmpeg rmvb demuxer which actually has this problem, and not the decoder. VLC has its own demuxer for Real files - maybe that makes the difference.
VipZ
23rd July 2011, 12:29
Nev just some info for you on the recent AR code
MKV /w h264, with the recent AR option to disabled the AR from stream. AR is now correct, so issue #8 is pretty much done, unless you want to hard code this option for MKV /w h264
WMV video decoding still has AR issue when connecting to WM ASF Reader, with the option on or off. But I would guess this wasn't really to address WMV yet.
madshi
23rd July 2011, 12:49
MKV /w h264, with the recent AR option to disabled the AR from stream. AR is now correct, so issue #8 is pretty much done, unless you want to hard code this option for MKV /w h264
Hmmmm... I'm a bit confused. Isn't the bitstream AR generally more reliable than the container AR?
nevcairiel
23rd July 2011, 12:56
Hmmmm... I'm a bit confused. Isn't the bitstream AR generally more reliable than the container AR?
Not in MKV files. Haali has a hacky solution for this, so it overwrites the stream AR in the H264 headers with the MKV container AR.
I will probably implement this "hack" sooner or later as well (thats what ticket 8 is about), because there is otherwise no good solution. On MPEG-TS you want the AR from the stream, because the contaienr doesnt have any, and in broadcasts it can even change mid-stream - but on MKV, its kind of common that the container AR is correct, but the stream AR is wrong. I have multiple samples for this.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.