- การแก้ไข "ไม่อนุญาตการเข้าชมแบบ HTTP สำหรับ cleartext" "ข้อผิดพลาด"
- การแก้ไข "SSLHandshakeException", "CertPathValidatorException" และ "ERR_CERT_AUTHORITY_INVALID" "ข้อผิดพลาด"
- เหตุใดไฟล์สื่อบางไฟล์จึงค้นหาไม่ได้
- ทำไมการค้นหาไฟล์ MP3 บางไฟล์จึงไม่ถูกต้อง
- ทำไมการกรอวิดีโอจึงช้า
- ทำไมไฟล์ MPEG-TS บางไฟล์จึงเล่นไม่ได้
- ทำไมไม่มีคำบรรยายในไฟล์ MPEG-TS บางไฟล์
- ทำไมไฟล์ MP4/FMP4 บางไฟล์จึงเล่นไม่ถูกต้อง
- ทำไมสตรีมบางรายการจึงล้มเหลวด้วยรหัสการตอบกลับ HTTP 301 หรือ 302
- ทำไมบางสตรีมจึงล้มเหลวเมื่อใช้ UnrecognizedInputFormatException
- ทำไม setPlaybackParameters ไม่ทำงานอย่างถูกต้องในอุปกรณ์บางประเภท
- สิ่งที่ "มีการเข้าถึงผู้เล่นในชุดข้อความที่ไม่ถูกต้อง" หมายความว่าอย่างไร
- ฉันจะแก้ไข "บรรทัดสถานะที่ไม่คาดคิด: ICY 200 OK" ได้อย่างไร
- ฉันจะค้นหาได้อย่างไรว่าสตรีมที่กำลังเล่นเป็นสตรีมแบบสดหรือไม่
- ฉันจะเล่นเสียงต่อไปเมื่อแอปของฉันอยู่ในเบื้องหลังได้อย่างไร
- ทำไม ExoPlayer ถึงรองรับเนื้อหาของฉัน แต่คลัง ExoPlayer Cast ไม่รองรับเนื้อหาของฉัน
- ทำไมเนื้อหาเล่นไม่ได้ แต่ข้อผิดพลาดไม่ปรากฏขึ้น
- ฉันจะโหลดไลบรารีการถอดรหัสเพื่อโหลดและใช้สำหรับการเล่นได้อย่างไร
- ฉันเล่นวิดีโอ YouTube ด้วย ExoPlayer โดยตรงได้ไหม
- การเล่นวิดีโอกระตุก
- ข้อผิดพลาดจาก Lint ใน API ที่ไม่เสถียร
การแก้ไข "ไม่อนุญาตการเข้าชม HTTP แบบล้างข้อความ" ข้อผิดพลาด
ข้อผิดพลาดนี้จะเกิดขึ้นหากแอปขอการเข้าชม HTTP แบบข้อความธรรมดา (กล่าวคือ
http://
แทนที่จะเป็น https://
) เมื่อการกำหนดค่าความปลอดภัยของเครือข่ายมี
ไม่อนุญาต หากแอปกำหนดเป้าหมายเป็น Android 9 (API ระดับ 28) ขึ้นไป ให้ล้างข้อความ
การเข้าชม HTTP จะปิดใช้อยู่โดยการกำหนดค่าเริ่มต้น
หากแอปต้องทำงานกับการเข้าชม HTTP แบบข้อความธรรมดา คุณต้องใช้
การกำหนดค่าความปลอดภัยของเครือข่ายที่อนุญาต ดูของ Android
เอกสารด้านความปลอดภัยของเครือข่าย
เพื่อดูรายละเอียด หากต้องการเปิดใช้การรับส่งข้อมูล HTTP แบบ cleartext ทั้งหมด คุณเพียงแค่เพิ่ม
android:usesCleartextTraffic="true"
ลงในองค์ประกอบ application
ของแอป
AndroidManifest.xml
แอปเดโม ExoPlayer จะใช้การกำหนดค่าความปลอดภัยเครือข่ายเริ่มต้น ดังนั้น ไม่อนุญาตการเข้าชม HTTP แบบข้อความธรรมดา คุณจะเปิดใช้ได้โดยทำตามวิธีการ ที่ด้านบน
การแก้ไข "SSLHandshakeException", "CertPathValidatorException" และ "ERR_CERT_AUTHORITY_INVALID" ข้อผิดพลาด
SSLHandshakeException
, CertPathValidatorException
และ
ERR_CERT_AUTHORITY_INVALID
ทั้งหมดระบุว่าเกิดปัญหากับ SSL ของเซิร์ฟเวอร์
ใบรับรอง ข้อผิดพลาดเหล่านี้ไม่ได้เกี่ยวกับ ExoPlayer โดยเฉพาะ โปรดดู
เอกสารประกอบ SSL ของ Android
เพื่อดูรายละเอียดเพิ่มเติม
เหตุใดไฟล์สื่อบางไฟล์จึงค้นหาไม่ได้
โดยค่าเริ่มต้น ExoPlayer ไม่สนับสนุนการค้นหาสื่อที่มีวิธีการเดียวที่ เพื่อดำเนินการค้นหาให้ถูกต้องนั้น โปรแกรมเล่นจะสแกนและจัดทำดัชนี ทั้งไฟล์ ExoPlayer จะถือว่าไฟล์ดังกล่าวเป็นไฟล์ที่ค้นหาไม่ได้ สื่อที่ทันสมัยที่สุด รูปแบบคอนเทนเนอร์มีข้อมูลเมตาสำหรับการกรอวิดีโอ (เช่น ดัชนีตัวอย่าง) ที่มีแอตทริบิวต์ อัลกอริทึมการค้นหาที่ชัดเจน (เช่น การค้นหาส่วนย่อยของส่วน Ogg) หรือ ระบุว่าเนื้อหามีอัตราบิตคงที่ การดำเนินการค้นหาที่มีประสิทธิภาพ และรองรับโดย ExoPlayer ในกรณีเหล่านี้
หากคุณต้องการการกรอวิดีโอ แต่มีสื่อที่ไม่สามารถดูได้ เราขอแนะนำให้แปลง เนื้อหาเพื่อใช้รูปแบบคอนเทนเนอร์ที่เหมาะสมยิ่งขึ้น สำหรับไฟล์ MP3, ADTS และ AMR คุณยังสามารถเปิดใช้งานการกรอวิดีโอภายใต้สมมติฐานที่ว่าไฟล์มีค่าคงที่ อัตราบิต ตามที่อธิบายไว้ ที่นี่
ทำไมการค้นหาไฟล์ MP3 บางไฟล์จึงไม่ถูกต้อง
ไฟล์ MP3 อัตราบิตแปรผัน (VBR) ไม่เหมาะสำหรับกรณีการใช้งาน จำเป็นต้องมีการกรอวิดีโอที่ถูกต้อง ซึ่งเกิดจากสาเหตุ 2 ประการ ดังนี้
- สำหรับการกรอวิดีโออย่างละเอียด รูปแบบคอนเทนเนอร์จะให้ การจับคู่เวลาต่อไบต์ในส่วนหัว การแมปนี้ช่วยให้โปรแกรมเล่น ขอเวลาที่ระบุสำหรับการชดเชยไบต์ที่เกี่ยวข้อง และเริ่มส่งคำขอ การแยกวิเคราะห์และเล่นสื่อจากออฟเซ็ตนั้น ส่วนหัวที่ใช้ได้สำหรับ แต่บ่อยครั้งที่มีการระบุการแมปนี้ใน MP3 (เช่น ส่วนหัว XING) ไม่แน่นอน
- สำหรับรูปแบบคอนเทนเนอร์ที่ไม่ได้ระบุการแมปเวลาต่อไบต์ที่แม่นยํา (หรือ การจับคู่เวลากับไบต์ได้ตลอดเวลา) ก็ยังคงเป็นไปได้ที่จะดำเนินการ ค้นหาว่าคอนเทนเนอร์มีการประทับเวลาตัวอย่างสัมบูรณ์ในสตรีมหรือไม่ ใน ในกรณีนี้ ผู้เล่นจะสามารถจับคู่เวลาที่กรอวิดีโอเพื่อคาดเดาเวลาที่เกี่ยวข้องให้ใกล้เคียงที่สุด ไบต์ออฟเซ็ต, เริ่มขอสื่อจากออฟเซ็ตนั้น, แยกวิเคราะห์ส่วนแรก การประทับเวลาตัวอย่างสัมบูรณ์ และดำเนินการค้นหาไบนารีแบบมีคำแนะนำได้อย่างมีประสิทธิภาพ ลงในสื่อจนกว่าจะเจอตัวอย่างที่เหมาะสม ขออภัย MP3 ไม่มี รวมการประทับเวลาตัวอย่างสัมบูรณ์ในสตรีม เพื่อไม่ให้วิธีการนี้ เท่าที่จะเป็นไปได้
ด้วยเหตุนี้ วิธีเดียวในการค้นหาไฟล์ VBR MP3 ก็คือ
เพื่อสแกนทั้งไฟล์และสร้างการแมปเวลาต่อไบต์ด้วยตนเองใน
โปรแกรมเล่นวิดีโอ คุณเปิดใช้กลยุทธ์นี้ได้โดยใช้ FLAG_ENABLE_INDEX_SEEKING
,
ซึ่งสามารถตั้งค่าใน DefaultExtractorsFactory
โดยใช้
setMp3ExtractorFlags
โปรดทราบว่าขนาดอาจไม่เหมาะกับไฟล์ MP3 ขนาดใหญ่
โดยเฉพาะหากผู้ใช้พยายามจะย้อนดูตอนใกล้จบของสตรีมไม่นานนัก
หลังจากเริ่มเล่น ซึ่งโปรแกรมเล่นจะต้องรอจนกว่าการดาวน์โหลดจะเสร็จสมบูรณ์
และทำดัชนีสตรีมทั้งหมด ก่อนทำการกรอวิดีโอ ใน ExoPlayer
เราจึงตัดสินใจเพิ่มประสิทธิภาพด้าน
ความเร็วเหนือความถูกต้องแม่นยำ
ดังนั้นระบบจึงปิดใช้ FLAG_ENABLE_INDEX_SEEKING
โดยค่าเริ่มต้น
หากคุณควบคุมสื่อที่เล่นอยู่ เราขอแนะนำให้คุณใช้ รูปแบบคอนเทนเนอร์ที่เหมาะสม เช่น MP4 ไม่มีกรณีการใช้งานที่เราทราบ โดย MP3 คือตัวเลือกที่ดีที่สุดของรูปแบบสื่อ
ทำไมการกรอวิดีโอจึงช้า
เมื่อโปรแกรมเล่นจะหาตำแหน่งการเล่นใหม่ในวิดีโอ จะต้องทำ 2 อย่าง สิ่งต่างๆ:
- โหลดข้อมูลที่เกี่ยวข้องกับตำแหน่งการเล่นใหม่ลงในบัฟเฟอร์ (อาจไม่จำเป็นหากข้อมูลนี้ได้รับการบัฟเฟอร์แล้ว)
- ล้างตัวถอดรหัสวิดีโอและเริ่มถอดรหัสจาก I-Frame (คีย์เฟรม) ตำแหน่งการเล่นใหม่ เนื่องจากวิดีโอส่วนใหญ่ใช้การเขียนโค้ดภายในเฟรม รูปแบบการบีบอัด เพื่อให้แน่ใจว่าการค้นหาถูกต้อง (กล่าวคือ การเล่นจะเริ่มต้นที่ตำแหน่งกรอวิดีโอพอดี) เฟรมทั้งหมดระหว่าง I-frame ก่อนหน้าและตำแหน่งกรอวิดีโอต้องได้รับการถอดรหัสและทันที ทิ้ง (โดยไม่แสดงบนหน้าจอ)
เวลาในการตอบสนองที่เกิดจาก (1) สามารถบรรเทาได้ด้วยการเพิ่มจำนวน ของข้อมูลที่โปรแกรมเล่นใส่บัฟเฟอร์ไว้ในหน่วยความจำ หรือการแคชข้อมูลไว้ในดิสก์ล่วงหน้า
เวลาในการตอบสนองที่เกิดจาก (2) สามารถบรรเทาได้โดยการลดความถูกต้อง
ของการค้นหาโดยใช้ ExoPlayer.setSeekParameters
หรือการเข้ารหัสวิดีโออีกครั้ง
มี I-Frame บ่อยขึ้น (ซึ่งจะทำให้ไฟล์เอาต์พุตใหญ่ขึ้น)
ทำไมไฟล์ MPEG-TS บางไฟล์จึงเล่นไม่ได้
ไฟล์ MPEG-TS บางไฟล์ไม่มีตัวคั่นหน่วยเข้าถึง (AUD) โดยค่าเริ่มต้น ExoPlayer ใช้ AUD เพื่อตรวจหาขอบเขตเฟรมราคาถูก ในทำนองเดียวกัน ไฟล์ MPEG-TS ไม่มีคีย์เฟรม IDR โดยค่าเริ่มต้น ข้อมูลเหล่านี้จะเป็นประเภทเดียว ของคีย์เฟรมที่ ExoPlayer พิจารณา
ExoPlayer จะค้างอยู่ในสถานะบัฟเฟอร์เมื่อระบบขอให้เล่น
ไฟล์ MPEG-TS ที่ไม่มี AUD หรือ IDR คีย์เฟรม ถ้าคุณจำเป็นต้องเล่นไฟล์เหล่านี้
คุณสามารถทำได้โดยใช้ FLAG_DETECT_ACCESS_UNITS
และ
FLAG_ALLOW_NON_IDR_KEYFRAMES
ตามลำดับ ค่าสถานะเหล่านี้สามารถตั้งค่าได้ใน
DefaultExtractorsFactory
โดยใช้ setTsExtractorFlags
หรือบน
DefaultHlsExtractorFactory
โดยใช้
เครื่องมือสร้าง
การใช้ FLAG_DETECT_ACCESS_UNITS
ไม่มีผลข้างเคียงนอกเหนือจากการ
การประมวลผลที่มีราคาแพงเมื่อเทียบกับการตรวจจับขอบเขตเฟรมตาม AUD การใช้
FLAG_ALLOW_NON_IDR_KEYFRAMES
อาจทำให้ภาพเสียหายชั่วคราวใน
เริ่มเล่นและทันทีหลังจากค้นหาเมื่อเล่นไฟล์ MPEG-TS
ทำไมถึงไม่พบคำบรรยายในไฟล์ MPEG-TS บางไฟล์
ไฟล์ MPEG-TS บางไฟล์มีแทร็ก CEA-608 แต่ไม่ได้ประกาศไว้ในไฟล์
ข้อมูลเมตาของคอนเทนเนอร์ ExoPlayer จึงไม่สามารถตรวจหาได้ คุณสามารถดำเนินการด้วยตนเอง
ระบุแทร็กคำบรรยายด้วยการระบุรายการที่คาดไว้
รูปแบบคำบรรยายของ DefaultExtractorsFactory
ซึ่งรวมถึงการช่วยเหลือพิเศษ
ช่องที่สามารถใช้ระบุช่องในสตรีม MPEG-TS ได้ ดังนี้
Kotlin
val extractorsFactory = DefaultExtractorsFactory() .setTsSubtitleFormats( listOf( Format.Builder() .setSampleMimeType(MimeTypes.APPLICATION_CEA608) .setAccessibilityChannel(accessibilityChannel) // Set other subtitle format info, such as language. .build() ) ) val player: Player = ExoPlayer.Builder(context, DefaultMediaSourceFactory(context, extractorsFactory)).build()
Java
DefaultExtractorsFactory extractorsFactory = new DefaultExtractorsFactory() .setTsSubtitleFormats( ImmutableList.of( new Format.Builder() .setSampleMimeType(MimeTypes.APPLICATION_CEA608) .setAccessibilityChannel(accessibilityChannel) // Set other subtitle format info, such as language. .build())); Player player = new ExoPlayer.Builder(context, new DefaultMediaSourceFactory(context, extractorsFactory)) .build();
ทำไมไฟล์ MP4/FMP4 บางไฟล์จึงเล่นไม่ถูกต้อง
ไฟล์ MP4/FMP4 บางไฟล์มีรายการแก้ไขที่เขียนไทม์ไลน์สื่อใหม่ดังนี้ การข้าม การย้าย หรือการทำซ้ำรายการตัวอย่าง ExoPlayer รองรับบางส่วน สำหรับการใช้รายการแก้ไข เช่น อาจหน่วงเวลาหรือกลุ่มตัวอย่างซ้ำ เริ่มที่ตัวอย่างการซิงค์ แต่ไม่ได้ตัดตัวอย่างเสียงหรือ สื่อโฆษณาตอนต้นสำหรับการแก้ไขที่ไม่ได้เริ่มต้นในตัวอย่างการซิงค์
หากคุณพบว่าสื่อส่วนนั้นหายไปหรือซ้ำกันโดยไม่คาดคิด
ลองตั้งค่า Mp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS
หรือ
FragmentedMp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS
ซึ่งจะทำให้
เพื่อละเว้นรายการแก้ไขทั้งหมด สามารถตั้งค่าใน
DefaultExtractorsFactory
โดยใช้ setMp4ExtractorFlags
หรือ
setFragmentedMp4ExtractorFlags
ทำไมสตรีมบางรายการจึงล้มเหลวเมื่อมีรหัสการตอบกลับ HTTP 301 หรือ 302
รหัสตอบกลับ HTTP 301 และ 302 ทั้งคู่ระบุการเปลี่ยนเส้นทาง คำอธิบายสั้นๆ ได้ใน Wikipedia เมื่อ ExoPlayer ส่งคำขอและได้รับคำขอ การตอบกลับด้วยรหัสสถานะ 301 หรือ 302 โดยปกติแล้วจะเป็นไปตามการเปลี่ยนเส้นทาง แล้วเริ่มเล่นตามปกติ มีกรณีหนึ่งที่กรณีเช่นนี้ไม่เกิดขึ้นโดยค่าเริ่มต้น คือการเปลี่ยนเส้นทางข้ามโปรโตคอล การเปลี่ยนเส้นทางข้ามโปรโตคอลคือการเปลี่ยนเส้นทาง จาก HTTPS เป็น HTTP หรือกลับกัน (หรือไม่บ่อยนักระหว่าง โปรโตคอล) คุณสามารถทดสอบว่า URL ทำให้เกิดการเปลี่ยนเส้นทางข้ามโปรโตคอลหรือไม่ โดยใช้ เครื่องมือบรรทัดคำสั่ง wget ดังนี้
wget "https://yourserver.com/test.mp3" 2>&1 | grep Location
ผลลัพธ์ควรมีลักษณะเช่นนี้
Location: https://second.com/test.mp3 [following]
Location: http://third.com/test.mp3 [following]
ในตัวอย่างนี้มีการเปลี่ยนเส้นทาง 2 รายการ การเปลี่ยนเส้นทางแรกมาจาก
https://yourserver.com/test.mp3
ไปยัง https://second.com/test.mp3
ทั้ง 2 ประเภท
HTTPS และไม่ใช่การเปลี่ยนเส้นทางข้ามโปรโตคอล การเปลี่ยนเส้นทางที่สองมาจาก
https://second.com/test.mp3
ไปยัง http://third.com/test.mp3
การเปลี่ยนเส้นทางนี้
จาก HTTPS ไปยัง HTTP
จึงเป็นการเปลี่ยนเส้นทางข้ามโปรโตคอล ExoPlayer จะไม่
ทำตามการเปลี่ยนเส้นทางนี้ด้วยการกำหนดค่าเริ่มต้น ซึ่งหมายความว่าการเล่นจะล้มเหลว
หากจำเป็น คุณสามารถกำหนดค่า ExoPlayer ให้ติดตามการเปลี่ยนเส้นทางข้ามโปรโตคอลได้
เมื่อสร้างอินสแตนซ์ DefaultHttpDataSource.Factory
ที่ใช้ใน
แอปพลิเคชัน ดูข้อมูลเกี่ยวกับการเลือกและกำหนดค่ากลุ่มเครือข่าย
ที่นี่
ทำไมสตรีมบางรายการจึงล้มเหลวด้วย UnrecognizedInputFormatException
คำถามนี้เกี่ยวข้องกับการเล่นไม่สำเร็จในรูปแบบต่อไปนี้
UnrecognizedInputFormatException: None of the available extractors
(MatroskaExtractor, FragmentedMp4Extractor, ...) could read the stream.
ความล้มเหลวนี้มีสาเหตุที่เป็นไปได้สองประการ สาเหตุที่พบบ่อยที่สุดคือ
คุณกำลังพยายามเล่น DASH (mpd), HLS (m3u8) หรือ SmoothStreaming (ism, isml)
แต่โปรแกรมเล่นจะพยายามเล่นเนื้อหาแบบโพรเกรสซีฟ เพื่อเล่น
คุณต้องอ้างอิงโมดูล ExoPlayer ที่เกี่ยวข้อง ในกรณีที่
URI ของสตรีมไม่ได้ลงท้ายด้วยนามสกุลไฟล์มาตรฐาน คุณยังสามารถส่งผ่าน
MimeTypes.APPLICATION_MPD
, MimeTypes.APPLICATION_M3U8
หรือ
MimeTypes.APPLICATION_SS
ถึง setMimeType
จาก MediaItem.Builder
ถึงอย่างชัดเจน
ระบุประเภทของสตรีม
สาเหตุที่พบไม่บ่อยนักคือ ExoPlayer ไม่รองรับคอนเทนเนอร์ ของสื่อที่คุณพยายามเล่น ในกรณีนี้ ความล้มเหลวคือ ทำงานตามที่ต้องการแล้ว แต่คุณสามารถส่งคำขอฟีเจอร์ไปที่ เครื่องมือติดตามปัญหา รวมถึงรายละเอียดของรูปแบบคอนเทนเนอร์และสตรีมทดสอบ โปรดค้นหาคำขอฟีเจอร์ที่มีอยู่ก่อนส่งคำขอใหม่
เหตุใด setPlaybackParameters จึงทำงานไม่ถูกต้องในอุปกรณ์บางประเภท
เมื่อเรียกใช้บิลด์การแก้ไขข้อบกพร่องของแอปใน Android M และเวอร์ชันก่อนหน้า คุณอาจต้อง
พบปัญหาประสิทธิภาพกระตุก สิ่งแปลกปลอมที่ได้ยินเสียง และการใช้งาน CPU สูงเมื่อ
โดยใช้ setPlaybackParameters
API นั่นก็เพราะการเพิ่มประสิทธิภาพ
ที่สำคัญต่อ API นี้ถูกปิดใช้สำหรับบิลด์การแก้ไขข้อบกพร่องที่ทำงานใน
เวอร์ชัน Android
โปรดทราบว่าปัญหานี้ส่งผลต่อบิลด์การแก้ไขข้อบกพร่องเท่านั้น แต่ไม่ ส่งผลต่อบิลด์ที่เผยแพร่ ซึ่งเปิดใช้การเพิ่มประสิทธิภาพอยู่เสมอ ดังนั้น รุ่นที่คุณส่งให้กับผู้ใช้ปลายทางจะไม่ได้รับผลกระทบจากปัญหานี้
"มีการเข้าถึงผู้เล่นในชุดข้อความที่ไม่ถูกต้อง" ว่าอย่างไร ข้อผิดพลาดหมายถึงอะไร
โปรดดูหมายเหตุเกี่ยวกับการแยกชุดข้อความในหน้าเริ่มต้นใช้งาน
ฉันจะแก้ไข "บรรทัดสถานะที่ไม่คาดคิด: ICY 200 OK" ได้อย่างไร
ปัญหานี้อาจเกิดขึ้นหากการตอบสนองของเซิร์ฟเวอร์มีบรรทัดสถานะ ICY แทนที่จะเป็นรูปแบบที่เป็นไปตาม HTTP เลิกใช้งานเส้นสถานะ ICY แล้ว และ ไม่ควรใช้ ดังนั้นหากคุณเป็นผู้ควบคุมเซิร์ฟเวอร์ คุณควรอัปเดตเซิร์ฟเวอร์ให้มี การตอบกลับที่สอดคล้องกับ HTTP หากคุณทำไม่ได้ ให้ใช้ ไลบรารี ExoPlayer OkHttp จะช่วยแก้ปัญหาเนื่องจากจัดการ ICY ได้ บรรทัดสถานะอย่างถูกต้อง
ฉันจะค้นหาได้อย่างไรว่าสตรีมที่เล่นเป็นสตรีมแบบสดหรือไม่
คุณสามารถค้นหาเมธอด isCurrentWindowLive
ของโปรแกรมเล่นได้ นอกจากนี้ คุณยัง
สามารถตรวจสอบ isCurrentWindowDynamic
เพื่อดูว่าหน้าต่างเป็นแบบไดนามิกหรือไม่
(ซึ่งมีการอัปเดตอย่างต่อเนื่อง)
ฉันจะเล่นเสียงต่อไปเมื่อแอปของฉันอยู่ในเบื้องหลังได้อย่างไร
ทำตามขั้นตอนเหล่านี้เพื่อให้การเล่นเสียงอย่างต่อเนื่องเมื่อแอปอยู่ใน พื้นหลัง:
- คุณต้องมีบริการที่ทำงานอยู่เบื้องหน้าที่ใช้งานอยู่ ซึ่งจะป้องกันระบบ ตั้งแต่การทำลายกระบวนการทำงาน เพื่อเพิ่มพื้นที่ว่างสำหรับทรัพยากร
- คุณต้องเก็บ
WifiLock
และWakeLock
ไว้ ซึ่งช่วยรับประกันว่า จะทำให้วิทยุ Wi-Fi และ CPU เปิดอยู่ ซึ่งสามารถทำได้ง่ายหากใช้ExoPlayer
โดยโทรไปที่setWakeMode
จากนั้นระบบจะ รับและปล่อยล็อกที่กำหนดในเวลาที่เหมาะสม
คุณต้องปล่อยล็อก (หากไม่ได้ใช้ setWakeMode
) และหยุดล็อก
บริการทันทีที่เสียงไม่ได้เปิดอีกต่อไป
ทำไม ExoPlayer จึงรองรับเนื้อหาของฉัน แต่คลัง ExoPlayer Cast ไม่รองรับเนื้อหาของฉัน
เป็นไปได้ว่าเนื้อหาที่คุณพยายามเล่น เปิดใช้ CORS เฟรมเวิร์กการแคสต์กำหนดให้เนื้อหาต้องเปิดใช้ CORS ใน เพื่อเล่น
ทำไมเนื้อหาเล่นไม่ได้ แต่ไม่มีข้อผิดพลาดปรากฏขึ้น
เป็นไปได้ว่าอุปกรณ์ที่คุณใช้เล่นเนื้อหาไม่
รองรับตัวอย่างสื่อบางรูปแบบ ซึ่งสามารถยืนยันได้อย่างง่ายดายโดยการเพิ่ม
EventLogger
ในฐานะผู้ฟังโปรแกรมเล่น และมองหาเส้น
คล้ายกับรายการนี้ใน Logcat:
[ ] Track:x, id=x, mimeType=mime/type, ... , supported=NO_UNSUPPORTED_TYPE
NO_UNSUPPORTED_TYPE
หมายความว่าอุปกรณ์ไม่สามารถถอดรหัสสื่อ
รูปแบบตัวอย่างที่ mimeType
ระบุ ดูรูปแบบสื่อสำหรับ Android
เอกสารสำหรับข้อมูลเกี่ยวกับรูปแบบตัวอย่างที่รองรับ ฉันต้องทำอย่างไร
ไลบรารีการถอดรหัสเพื่อโหลดและใช้สำหรับการเล่นก็อาจเป็นประโยชน์เช่นกัน
ฉันจะโหลดไลบรารีการถอดรหัสเพื่อโหลดและใช้สำหรับการเล่นได้อย่างไร
- ไลบรารีตัวถอดรหัสส่วนใหญ่มีขั้นตอนการตรวจสอบและสร้างทรัพยากร Dependency ด้วยตนเอง ดังนั้น โปรดทำตามขั้นตอนใน README สำหรับไลบรารีที่เกี่ยวข้อง ตัวอย่างเช่น สำหรับไลบรารี ExoPlayer FFmpeg จะต้องทำตาม วิธีการใน libraries/decoder_ffmpeg/README.md ซึ่งรวมถึงการส่ง แฟล็กการกำหนดค่าเพื่อเปิดใช้ตัวถอดรหัสสำหรับรูปแบบที่คุณต้องการเล่น
- สำหรับไลบรารีที่มีโค้ดเนทีฟ โปรดตรวจสอบว่าคุณใช้
Android NDK ตามที่ระบุใน README และมองหา
ที่ปรากฏระหว่างการกำหนดค่าและการสร้าง คุณควรจะเห็น
.so
จะปรากฏในไดเรกทอรีย่อยlibs
ของเส้นทางไลบรารีสำหรับแต่ละไฟล์ ที่สนับสนุนหลังจากทำตามขั้นตอนใน README - หากต้องการลองเล่นโดยใช้ไลบรารีในแอปพลิเคชันสาธิต โปรดดู การเปิดใช้ตัวถอดรหัสแบบแพ็กเกจ ดู README สำหรับไลบรารีสำหรับ วิธีใช้ไลบรารีจากแอปของคุณ
- หากใช้
DefaultRenderersFactory
คุณควรเห็นระดับข้อมูล บรรทัดในไฟล์บันทึก เช่น "Loaded FfmpegAudioRenderer" ใน Logcat เมื่อตัวถอดรหัสโหลดขึ้นมา หากข้อมูลขาดหายไป โปรดตรวจสอบว่าแอปพลิเคชันมีทรัพยากร Dependency ของ ไลบรารีการถอดรหัส - หากคุณเห็นบันทึกระดับคำเตือนจาก
LibraryLoader
ใน Logcat ระบบจะดำเนินการต่อไปนี้ บ่งบอกว่าการโหลดคอมโพเนนต์ดั้งเดิมของไลบรารีล้มเหลว หากสิ่งนี้ ให้ตรวจสอบว่าคุณได้ทำตามขั้นตอนใน README ของไลบรารีอย่างถูกต้อง และไม่มีข้อผิดพลาดแสดงขึ้นมาระหว่างที่ทำตามคำแนะนำ
หากยังพบปัญหาในการใช้ไลบรารีการถอดรหัส โปรดตรวจสอบ เครื่องมือติดตามปัญหา Media3 สำหรับปัญหาล่าสุดที่เกี่ยวข้อง หากคุณจำเป็นต้องยื่นเรื่อง ปัญหานี้เกี่ยวข้องกับการสร้างส่วนเดิมของไลบรารี โปรด รวมเอาต์พุตบรรทัดคำสั่งแบบเต็มจากการเรียกใช้คำสั่ง README เพื่อช่วยให้เรา วินิจฉัยปัญหา
ฉันเล่นวิดีโอ YouTube ด้วย ExoPlayer โดยตรงได้ไหม
ไม่ได้ ExoPlayer ไม่สามารถเล่นวิดีโอจาก YouTube เช่น URL ของแบบฟอร์มได้
https://www.youtube.com/watch?v=...
แต่คุณควรใช้เครื่องมือ YouTube
API โปรแกรมเล่น iframe
ซึ่งเป็นวิธีอย่างเป็นทางการในการเล่นวิดีโอ YouTube บน Android
การเล่นวิดีโอกระตุก
อุปกรณ์อาจไม่สามารถถอดรหัสเนื้อหาได้เร็วพอ ตัวอย่างเช่น อัตราบิตหรือความละเอียดของเนื้อหาเกินความสามารถของอุปกรณ์ คุณอาจต้อง ใช้เนื้อหาคุณภาพต่ำเพื่อให้ได้ประสิทธิภาพที่ดีบนอุปกรณ์ดังกล่าว
หากพบปัญหาวิดีโอกระตุกในอุปกรณ์ที่ใช้ Android เวอร์ชันหนึ่ง ตั้งแต่ Android 6.0 (API ระดับ 23) ถึงและรวมถึง Android 11 (API ระดับ 30) โดยเฉพาะอย่างยิ่ง เมื่อเปิดเนื้อหาที่มีการป้องกันด้วย DRM หรือเนื้อหาที่มีอัตราเฟรมสูง คุณอาจลอง การเปิดใช้การจัดคิวบัฟเฟอร์แบบไม่พร้อมกัน
ข้อผิดพลาดจาก Lint ใน API ที่ไม่เสถียร
Media3 รับประกันความเข้ากันได้แบบไบนารีสำหรับชุดย่อยของแพลตฟอร์ม API
ส่วนที่ไม่รับประกันความเข้ากันได้ของไบนารีจะมีเครื่องหมาย
@UnstableApi
และเพื่อให้เกิดความแตกต่างอย่างชัดเจนนี้ การใช้งานที่ไม่เสถียร
สัญลักษณ์ API จะสร้างข้อผิดพลาด Lint เว้นแต่ว่าจะมีคำอธิบายประกอบด้วย @OptIn
คำอธิบายประกอบ @UnstableApi
ไม่ได้บอกเป็นนัยเกี่ยวกับคุณภาพหรือประสิทธิภาพของ API เพียงแต่ว่า API ไม่ได้อยู่ในสถานะ "API ถูกตรึงไว้"
คุณมี 2 ตัวเลือกในการจัดการกับข้อผิดพลาด Lint ใน API ที่ไม่เสถียร ดังนี้
- เปลี่ยนไปใช้ API แบบคงที่ซึ่งได้รับผลลัพธ์เดียวกัน
- ใช้ API ที่ไม่เสถียรต่อไปและใส่คำอธิบายประกอบการใช้งานด้วย
@OptIn
ดังตัวอย่างต่อไปนี้ แสดงภายหลัง
เพิ่มคำอธิบายประกอบ @OptIn
Android Studio สามารถช่วยคุณเพิ่มคำอธิบายประกอบได้ ดังนี้
![ภาพหน้าจอ: วิธีเพิ่มคำอธิบายประกอบการเลือกใช้](https://developer.android.com/static/media/media3/exoplayer/images/unstable-api.png?authuser=19&hl=th)
นอกจากนี้ คุณยังใส่คำอธิบายประกอบในเว็บไซต์การใช้งานที่เฉพาะเจาะจงใน Kotlin ด้วยตนเองได้ด้วย โดยทำดังนี้
import androidx.annotation.OptIn
import androidx.media3.common.util.UnstableApi
@OptIn(UnstableApi::class)
fun functionUsingUnstableApi() { ... }
และใน Java:
import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;
@OptIn(markerClass = UnstableApi.class)
private void methodUsingUnstableApis() { ... }
คุณเลือกใช้ทั้งแพ็กเกจได้โดยการเพิ่มไฟล์ package-info.java
ดังนี้
@OptIn(markerClass = UnstableApi.class)
package name.of.your.package;
import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;
คุณสามารถเลือกใช้ทั้งโปรเจ็กต์ได้โดยการระงับข้อผิดพลาด Lint ที่เฉพาะเจาะจงใน
lint.xml
ไฟล์:
<?xml version="1.0" encoding="utf-8"?>
<lint>
<issue id="UnsafeOptInUsageError">
<option name="opt-in" value="androidx.media3.common.util.UnstableApi" />
</issue>
</lint>
นอกจากนี้ยังมีคำอธิบายประกอบ kotlin.OptIn
ที่ไม่ควรใช้ ตอนนี้
สำคัญในการใช้คำอธิบายประกอบ androidx.annotation.OptIn