Ticket #27 (closed defect: fixed)
switch_video doesn't work with MKV files
| Reported by: | Hermi | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | General | Version: | devel |
| Severity: | minor | Keywords: | switch_video |
| Cc: | Platform: | All |
Description
set_property switch_video vid doesn't work because DEMUXER_CTRL_SWITCH_VIDEO isn't implemented in mplayer/libmpdemux/demux_mkv.c. The attached diff resolves this problem, although after switching the video exhibits momentary corruption when seeking (switching back to the original video track removes the corruption).
Also included in the patch is a fix to the OS X corevideo vo which removes a crash when switching video tracks.
Attachments
Change History
comment:1 Changed 2 years ago by Hermi
Edit: ignore the (now removed) part about corevideo. The change was required for mplayer, but mplayer2 is failing to call uninit somewhere that mplayer did, so the mplayer fix actually introduced a crash with mplayer2. I am worried that using a different demuxer than mkv will still crash though, but I don't have any sample files to test.
comment:2 Changed 2 years ago by uau
Please create patches with "git format-patch" or otherwise indicate what name should be used to indicate authorship in the commit (I saw your mplayer-dev-eng mail, from that I guess it would be "Hermi Mercury <hermi.hg@gmail.com>").
I see no corruption after seeking with this patch (using a sample I created myself with mkvmerge). There is corruption immediately after the track switch (that's expected because the track switch is done without jumping to a keyframe on the new track). Are you sure you tested things correctly? If so, maybe it's a problem in your video; does the track in question work any better if you specify that track on the commandline and never switch tracks?
I see no corevideo part in your patch, relevant or not. VO use should not depend on demuxer. I wonder how the video track switch case would differ from switching between files from VO point of view. Do you see a problem in mplayer2 if you use the option -nofixed-vo? That should make the behavior closer to MPlayer 1 default behavior.
comment:3 Changed 2 years ago by Hermi
Sorry about the patch format, I am not very familiar with git or svn. I don't really care about commit credit, but Hermi is the pseudonym I prefer to use when posting online.
You are right about the corruption - after testing again I found that only mplayer1 exhibits the corruption after seeking; it was never present in mplayer2, I just didn't notice.
Re: corevideo: I re-uploaded the patch when I realized the corevideo portion was not helpful in mplayer2, but could not edit my initial post.
