Precisione di MediaPlayer.seekTo (int msecs)

Perché MediaPlayer.seekTo(int msec) così impreciso?

È a volte 30 secondi in anticipo (con mp3 di bitrate variables e costanti)! Sta cercando con audio inerentemente problematico o è questo metodo rotto? È che fare con il buffering o cosa?

  • Android: Come mettere l'icona di croce in cima al text di autocompletamento di text
  • Come funziona il disegnatore ProgressBar?
  • Quiz a scelta multipla random Android: come identificare la risposta corretta
  • Come faccio a implementare lo spostamento tra tabs su Android?
  • Modifica del colore del cursore in SearchView senza ActionBarSherlock
  • Posso leggere una row di file di text locale per row in una matrix di stringhe?
  • Ho anche notato che il runtime getDuration() può essere sbagliato (che non è un grosso problema) e ho provato che getCurrentPosition() è abbastanza preciso (come in each n secondi di riproduzione, aumenta di n mila ). Sono su Android 2.2.

    Infine, chiunque conosca quali formati, se funziona effettivamente in modo coerente (preferibilmente diverso da wav che presumibilmente lo fa)?

    EDIT:

    Prendo soprattutto i podcast. Smodcast e Thinking Allowed sono stati problematici più volte, anche dopo essere stati convertiti / ri-codificati in CBR. I file non sono danneggiati.

    QuickMediaConverter (Windows) sembra funzionare bene ma Sound Converter (Ubuntu) ha generato alcuni file danneggiati. Cercherò di attaccarmi all'ex …

    AGGIORNAMENTO: QuickMediaConverter funziona molto bene, ma non ha idea di perché. Nessun problema da allora!

  • Qual è la differenza tra ANR e crash in Android?
  • Attività di background, dialogo di avanzamento, cambiamento di orientamento - esiste una soluzione di lavoro al 100%?
  • Come sostituire le risorse delle stringhe con Gradley di Android
  • Problema di parsing JSON
  • Modalità di lancio "singolo" Android e metodo onNewIntent
  • NoSuchFieldError: Nessun field statico MapAttrs di tipo quando si utilizza MapFragment con Play Services 6.5
  • 2 Solutions collect form web for “Precisione di MediaPlayer.seekTo (int msecs)”

    Ci sono due modi in cui un framework multimediale eseguirà un'operazione di ricerca su un file multimediale (AV).

    1. Cerca il fotogramma chiave – Il video quando codificato di solito ha qualcosa chiamato come canvasio I o fotogramma chiave, significa che questo fotogramma ha un sacco di informazioni e può essere utilizzato per decodificare un fotogramma nella sua interezza. Per ridurre la quantità di spazio, tutti i frame non vengono codificati come fotogrammi chiave, invece sono codificati come fotogrammi P (Predicted) o frame predefiniti, ovvero è ansible decodificare un fotogramma P con l'aiuto del fotogramma chiave.

      Così durante l'operazione di ricerca, in questo caso la ricerca viene fatta al fotogramma chiave più vicino per una data durata. Ad esempio se l'utente cerca 40sci e il frame più vicino è al 35 sec, la ricerca viene fatta al 35 ° sec e non al 40esimo secondo.

    2. Cerca al tempo – Questo è alla ricerca del tempo preciso richiesto dall'utente.

      La ricerca viene ancora fatta in corrispondenza del più vicino fotogramma chiave in quanto altrimenti si vedrà le patch verdi o la pixelazione del video che è altamente indesiderabile. Quindi, invece, la ricerca viene fatta al fotogramma chiave e quindi i fotogrammi vengono decodificati fino all'ora richiesta, ma questi fotogrammi vengono eliminati e non vengono mostrati all'utente. Nell'esempio precedente, tutti i frame decodificati dal 35 al 40 secondo sono scartati e solo i fotogrammi al di là del quarantunesimo sec vengono mostrati all'utente.

    Nel caso di file audio solo ci possono essere due casi (se non esiste un parser o un parser che non costruisce la tabella timestamp allora -)

    1. CBR – Frequenza bit costante – Poiché la velocità del bit è costante possiamo saltare il numero necessario di byte a una data data (bitrate * timeToSeek = byte da ignorare)

    2. VBR – Velocità di bit variabile – La velocità del bit non è costante che continua a variare. Quindi, in questo caso, scopri il bitrate medio del file e poi utilizzi il metodo sopra, in questo caso la ricerca non sarà esatta.

    Ora tornando alla tua domanda, posso dire con fiducia che funziona bene e che è accurata per la maggior parte dei file multimediali.

    L'unico motivo per cui si potrebbe affrontare tali problemi è perché il file multimediale è danneggiato. (Non è ansible avere una differenza di 30 secondi durante la ricerca + si sta dicendo che la durata non viene restituita correttamente e nessuna delle API di Mediaplayer è rotta per Android 2.2)

    A proposito di quali formati è supportto da Android vedi questo link

    Quindi puoi provare con un altro file mp3?

    Non so niente di android. Ma so che nella maggior parte dei formati di file multimediali c'è una sola disposizione che ha chiamato la ricerca di voci o di cues entry .. che mostra per questo momento particolare da qui il video e l'audio dovrebbero iniziare a suonare

    se al di sotto del tempo è richiesto il segnale 10 sec
    12 sec
    14 sec

    allora se cercate 11 secondi allora giocherai sempre da 10 secondi se cercate 12 secondi, allora giocherai sempre da 12 secondi

    per un file di ricerca migliore dovrebbe essere muxed con voce alta cues.

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.