Opened 14 years ago
Closed 13 years ago
#1741 closed defect (duplicate)
lavf demuxer incorrect stream info
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Component: | demuxer |
| Version: | HEAD | Severity: | normal |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Reproduced by developer: | no | Analyzed by developer: | no |
Description
When using the now default lavf demuxer on an mkv or mov file mplayer will always print something like
[lavf] stream 0: audio (ac3), -aid 0
[lavf] stream 1: audio (ac3), -aid 1
[lavf] stream 2: video (h264), -vid 0
[lavf] stream 3: video (h264), -vid 1
Now like in the above example if video isn't stream 0 then adding -vid 0 (like suggested by this helpful message) to the command line actually results in no video being played since the demuxer only sees 2 and 3 as valid options.
Interestingly audio still plays even when an invalid id is given.
This might seem trivial but it is most annoying when using smplayer which apparently expects information given to be correct.
When using the mkv demuxer the numbers are the same but valid numbers seem to count up from 0 for each type so this issue doesn't appear.
Attachments (1)
Change History (3)
by , 14 years ago
| Attachment: | wrong_video_id.diff added |
|---|
comment:1 by , 14 years ago
I was probably wrong about the ids being reported wrong since subs and audio tracks work fine even when there are many and the order is random. Video streams just don't start from 0 for some reason. I still don't understand how it works after starting at it for a bit.
This diff is wrong and I wouldn't dream of proposing it as a fix to anything but I've been using it to work around the issue caused in smplayer and haven't witnessed any adverse effects so far. Perhaps someone else will find it useful or even better find the inspiration to fix the real bug.
workaround