Ticket #193 (closed enhancement: invalid)

Opened 2 years ago

Last modified 2 years ago

loadfile from offset in one command

Reported by: Abu Abdullah Owned by:
Priority: normal Milestone:
Component: Audio Decoder Version: devel
Severity: minor Keywords:
Cc: Platform: All

Description

Hi,

I'm loading a file from specific position in slave mode:

loadfile <filename> 0
seek <seconds> 2

This results in many cases with voice interference between the beginning of the file (for short period) and from the position I'm seeking. I'm hearing both voices at the same time. I tried to overcome this by:

  • nocache
  • Having both commands executed at once i.e. in one line with "\n" between them
  • pausing loadfile ...

Non are working. I'm using demuxer=lavf
It seems the first command "loadfile" will play unwanted frames in all cases until "seek" is taking place.

In summary: command which can load a new file and start playing
from a given offset in idle slave mode (atomic operation for loadfile / seek).

Thanks

Change History

comment:1 Changed 2 years ago by uau

  • Status changed from new to infoneeded_new

This is starting from false assumptions. Sound from position before seek should not continue, and AFAIK it does not in any normal circumstances.

In a previous report you talked about .rm format, which has some special demuxing issues. Does this happen with other formats? Though I could not hear "both voices at the same time" in the rm case either; some audio just incorrectly continued after the seek, but not mixed with new one. If it happens with just rm, did you use the --hr-seek-demuxer-offset switch I mentioned?

If you hear such "mixed" audio in general, there's nothing in the normal audio decoding chain which could produce such an effect. Either you must be using some weird filtering, or your audio output system is broken outside mplayer2.

comment:2 Changed 2 years ago by Abu Abdullah

  • Status changed from infoneeded_new to new

I used hr-seek-demuxer-offset=1 and it solved this effect. It seems it is false assumptions from my side. I'm not sure if it is related to my environment since I'm shooting these commands (loadfile/seek) from my Java application in a thread. The application is a bit complex to prepare a test sample to reproduce this effect.

Again thanks for your continuous explanations and workarounds

comment:3 Changed 2 years ago by uau

  • Status changed from new to closed
  • Resolution set to invalid

1 second might not be enough to skip over the part where the demuxer misbehaves.
Anyway, closing.

Note: See TracTickets for help on using tickets.