Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th March 2011, 22:10   #801  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by nevcairiel View Post
I support this just fine, the problem he has is with ffdshow profiles, which are only based on the initial connection, so he needs that to be correct.
ffdshow video can switch profiles on the fly, but ffdshow audio can't, it's picked once and for all at the DS graph initialization...I wish it could

PS: It seems to be due to HMS indeed, everything's recognized as it should using your splitter

PPS: You don't provide any option to change the "input buffer size" like in HMS? When seeking within a MKV on a DVD-R, it can be jerky...I can even completely lose the audio for a few secs.

Also, HMS has good error resilience when seeking in broken MKV's..does yours too?

Anyway, PotPlayer has a lot of options to have the audio/video bitrate/bitdepth/number of channels displayed on the skin...and very often all HMS had to tell PotP was "0", duh. Now I get my magic numbers each time, too cool

Last edited by leeperry; 7th March 2011 at 01:45.
leeperry is offline   Reply With Quote
Old 7th March 2011, 11:43   #802  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Input Buffer doesn't really help that much when seeking on a slow medium. Once the seek request finishes, LAV Splitter will immediately start demuxing again, and run the demuxer constantly until the buffer is filled again (around 100 packets), while another thread starts dispatching those packets to the decoders while the demuxer is still powering through the file to fill the buffer. I don't see how any buffer changes can reduce that latency.

I'm always open to improving seeking, as its usually one of the things a splitter either shines at, or is total crap. LAV Splitter supports key-frame/index seeking as used by MPC-HC, which greatly improved seeking performance in MKV (and some other formats).
I've also got some feedback that seeking is really working well, at least with MKV. MPEG-TS seeking is always a bit weird, but it feels "ok" to me, at least on BluRay media, which is usually "good" MPEG-TS. DVB captures are most of the time just broken, because the capture apps have incomplete or broken muxing tools. :/

For the error resilience, thats all in the hands of ffmpeg. Feel free to throw some corrupted files at it, and see what happens.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 7th March 2011 at 13:21.
nevcairiel is online now   Reply With Quote
Old 7th March 2011, 20:47   #803  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by nevcairiel View Post
I'm always open to improving seeking, as its usually one of the things a splitter either shines at, or is total crap. LAV Splitter supports key-frame/index seeking as used by MPC-HC, which greatly improved seeking performance in MKV (and some other formats).
I've enabled keyframe seeking in PotPlayer, it works like a charm w/ HMS and the built-in MKV splitter. Very fast seeking, no hiccup and I never lose audio. Lemme know if there's any way I could provide you w/ logs or something? I've encountered the problem when reading MKV(h264+1.5mbit DTS) from DVD-R, and I was using CDBremse to slow down the 16X Liteon XJ-HD166S drive to 6X(it becomes hardly audible).
leeperry is offline   Reply With Quote
Old 7th March 2011, 21:25   #804  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
I can burn some MKV to a DVD-R and test with that, i guess. AnyDVD offers a slow-down option, i'll run it on the slow & quiet preset, not sure what speed that is effectively.

I should also add some logging for users to see, right now all logging is only with a proper debugger *shrug*
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 01:45   #805  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
So as I said, PotPlayer has an option for keyframe seeking:

Seeking in MKV(h264+448kbit AC3) w/ this option checked, I've got the exact same problems as when seeking from a DVD-R...I lose the audio for a few secs after seeking, it also stutters and sometimes stalls for a second or two.

If I uncheck the option, I can easily get it to freeze PotPlayer completely. HMS works fine w/ both options, but seeking is slower if it's unchecked.


I run XPSP3, and here's my active filter list:
Quote:
[Used Filter List]
(1) LAV Splitter
(2) CoreAVC Video Decoder (CUDA in use)
(3) ffdshow Video Decoder
(4) Madshi Video Renderer
(5) ffdshow Audio Decoder
(6) ReClock Audio Renderer
I'll be glad to run any debug version, and if you wanna try to recreate the problem, you can find PotPlayer here(I'd advise to use 7-Zip and only extract PotPlayerMini.exe & PotPlayer.dll...the rest is just bloat).

I mentioned error resilience because HMS copes a lot better w/ broken MKV's than the built-in PotPlayer/KMP MKV splitters...the latters usually freeze the player when encountering broken frames, OTOH HMS allows you to reseek easily.

Last edited by leeperry; 8th March 2011 at 01:53.
leeperry is offline   Reply With Quote
Old 8th March 2011, 08:00   #806  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by leeperry View Post
Seeking in MKV(h264+448kbit AC3) w/ this option checked, I've got the exact same problems as when seeking from a DVD-R...I lose the audio for a few secs after seeking, it also stutters and sometimes stalls for a second or two.
On a file from HDD, seeking in MPC-HC with Key-Frame seeking is always instant for me, without its not instant, but audio resumes right away, video is a bit jerky until the decoder gets the next keyframe .. but thats the same with any splitter i tried.
As i mentioned earlier, alot of people confirmed these findings with MPC-HC. Not sure if its really a player thing.

I'll test from a slow optical medium, and try that PotPlayer.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 8th March 2011 at 08:05.
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 08:17   #807  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Just a thought: Any splitter can issue a seek command through the graph interface methods. Maybe it would be a nice trick for the splitter to "fine tune" any user seek request by issuing a correction seek command to the nearest video key frame? The net effect should be similar to seeking in MPC-HC with Key-Frame seeking enabled. However, it should work with any media player.
madshi is offline   Reply With Quote
Old 8th March 2011, 08:20   #808  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
I actually had something like that planned for the future, but as MPC-HC is my main target, i didn't give it any high priority.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 08:40   #809  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Nice.
madshi is offline   Reply With Quote
Old 8th March 2011, 08:45   #810  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
In theory it shouldn't even be needed to issue another seek request. The IMediaSeeking::SetPosition call is not guaranteed to end up on that spot exactly, i could just change the target position before doing the actual seek, and the player would then receive the new current position either through the argument it put in (its a pointer for a reason), or by calling GetCurrentPosition afterwards.

I hope the filter graph is smart enough to fix the reference clock in this case. Something to test.

This of course depends on the player being developed sanely.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 8th March 2011 at 08:50.
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 09:02   #811  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by nevcairiel View Post
In theory it shouldn't even be needed to issue another seek request. The IMediaSeeking::SetPosition call is not guaranteed to end up on that spot exactly, i could just change the target position before doing the actual seek, and the player would then receive the new current position either through the argument it put in (its a pointer for a reason), or by calling GetCurrentPosition afterwards.
As far as I understand the MS documentation, your SetPositions implementation should only modify the position value if the "AM_SEEKING_ReturnTime" is set.

Quote:
Originally Posted by nevcairiel View Post
I hope the filter graph is smart enough to fix the reference clock in this case. Something to test.

This of course depends on the player being developed sanely.
What does the player have to do with it? The true playback position is maintained by the graph, not by the media player. The media player doesn't call SetPositions on your filter directly, instead it calls SetPositions on the graph's IMediaSeeking interface. The graph will then as a result loop through all filters in the graph and call their IMediaSeeking::SetPosition methods. Which means that it probably doesn't matter how the media player is written. You returning a different seek position in your SetPositions implementation will require the graph to accept the change - not the media player. So whether your idea will work should not depend on the media player, but on the OS.

FWIW, I rather doubt it will work, but it might be worth a try. If it does work, I would recommend to test it in all OSs, just to be safe...
madshi is offline   Reply With Quote
Old 8th March 2011, 09:07   #812  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by madshi View Post
As far as I understand the MS documentation, your SetPositions implementation should only modify the position value if the "AM_SEEKING_ReturnTime" is set.
I understand AM_SEEKING_ReturnTime somewhat differently. To me it sounds like that when its set, the return value should always be converted to REFERENCE_TIME, no matter what the time format of the stream currently is.

In any case, dispatching a new seek request would work as well.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 09:14   #813  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by nevcairiel View Post
I understand AM_SEEKING_ReturnTime somewhat differently. To me it sounds like that when its set, the return value should always be converted to REFERENCE_TIME, no matter what the time format of the stream currently is.
Yes yes, that's correct. What I meant to say is that AM_SEEKING_ReturnTime is the only thing in the documentation that mentions modifying the position values. When AM_SEEKING_ReturnTime is not set, the doc does not mention that you could/should change the position values.
madshi is offline   Reply With Quote
Old 8th March 2011, 09:58   #814  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
You're right, its not really documented like that.
Oh well, i'll just do it with another seek request, just have to be careful to not create a loop there.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 10:28   #815  |  Link
pankov
Registered User
 
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 661
guys,
I might be guessing here but would this change from "precise seek" to "key frame seek" break the frame by frame stepping that ZoomPlayer and other players have?
Excuse my ignorance if this has nothing to do with your conversation.
pankov is offline   Reply With Quote
Old 8th March 2011, 10:30   #816  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by pankov View Post
guys,
I might be guessing here but would this change from "precise seek" to "key frame seek" break the frame by frame stepping that ZoomPlayer and other players have?
Yes it would. But i wouldn't have it always on, but offer an option to enable/disable it.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 10:30   #817  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Frame by frame *forward* stepping is realized in a different way, without seeking, I believe (at least in MPC-HC). To be honest, I'm not sure how stepping backwards is done, though.
madshi is offline   Reply With Quote
Old 8th March 2011, 12:50   #818  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Well, to me the point of using your splitter is rather clear...here I get the AC3 bitrate right on the PotPlayer transport bar(as I've always dreamed about):

HMS simply says "0":

I've spoken to Haali about those problematic samples, and his splitter simply repeats verbatim what's written in the MKV itself. If I demux/remux those 2 samples using mkvtoolnix 4.0, then they're both properly detected as 5.1

These 2 samples were muxed by 2 different ppl using different versions of mkvmerge, so I dunno wth is going on(even MediaInfo sees them as stereo)....anyway, it's only a side effect of the fact that HMS simply repeats what's written in the container header, when OTOH your splitter actually checks for the bitrate/number of channels of the streams...which provides all the right infos about bitrate/number of channels to the DS graph filters. I would very much appreciate if you could bring the seeking operations(using PotPlayer) to the foolproof status of HMS.

PS: HMS tells the bitrate of FLAC soundtracks(using madFlac), but your splitter simply says "0". I can make a sample.

PPS: humm yeah, I've seeked in a MKV(h264+20bit 7.1 FLAC, authored w/ mkvtoolnix 4.0) a few times, and then seeking didn't work anymore...no picture/no sound. PotPlayer hadn't locked up, though.

Last edited by leeperry; 8th March 2011 at 13:04.
leeperry is offline   Reply With Quote
Old 8th March 2011, 14:07   #819  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Bitrate info is purely cosmetic and not really my main concern. Some ffmpeg codecs don't export bitrates, maybe flac is one of those. I can check if it somewhere stores the container supplied bitrate value, though.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 8th March 2011, 16:26   #820  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Okay, i tried alot of my files with PotPlayer (all from local HDD or my network storage), and seeking is as smooth as it is in MPC-HC, no issues whatsoever.
This was with ReClock, madVR, ffdshow audio and video. Switching to CoreAVC for decoding, its still fast, but takes maybe half a second after seek to produce an image - does not matter if i have ffdshow raw video processor in there, or not. I would guess flushing the hardware pipeline could possible be slightly slower.

Vanilla PotPlayer settings, except filter choices (decoders mostly set to system default instead of internal, renderers to reclock and madvr respectively)

I could not produce any freezes, or anything of that sort. Seeking was a pleasure as i know it from MPC-HC. I can try from an optical media on the weekend, but seeking in BluRays was working just fine the last times i tried.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 8th March 2011 at 16:30.
nevcairiel is online now   Reply With Quote
Reply

Tags
decoders, directshow, filters, splitter

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.