A playlist that stops while using Android phone recordings can have several causes, and the word “playlist” does not identify which one. First establish whether you mean an FFmpeg concat list, an HLS playlist, or a YouTube playlist of separate uploads; then inspect the files and logs before changing formats.
A different container or stream layout may matter, but there is no evidence here that a particular Android codec is responsible. The useful fix depends on what the playlist contains, where playback stops, and what ffprobe and FFmpeg report.
Start by identifying the playlist
These three things are often all called a playlist, but they behave differently. An FFmpeg concat list is a text file listing inputs for FFmpeg. An HLS playlist is a .m3u8 manifest that points to media segments. A YouTube playlist groups separate uploaded videos on YouTube; it is not itself an FFmpeg media input format.
If your command includes -f concat or -f concat -i list.txt, investigate the concat demuxer path below. If the player opens a .m3u8 file, investigate its manifest, referenced segments and supported media formats. If you mean a YouTube playlist, say whether the failure is that a video upload ends, one item will not play, or a live broadcast stops: those are separate problems.
Note exactly where the stop happens. Does the output stop at the boundary between two phone recordings, at a particular HLS segment, or at the end of a YouTube item? A repeatable stop at a source boundary is useful evidence, but does not prove a codec mismatch. A missing segment, a bad path, a timestamp discontinuity, a playback-app limitation, or another error may fit the same symptom.
For a concat-specific walkthrough of a continuous YouTube output, see how the FFmpeg concat demuxer is used for a 24/7 playlist. That article is relevant only if your playlist is an FFmpeg concat input; an HLS manifest or a YouTube playlist needs a different investigation.
Gather the evidence before changing anything
Before suggesting a root cause, collect the exact FFmpeg command, the relevant log output, and details for at least two adjacent recordings. Include the full command as run, with input paths redacted if needed, rather than a paraphrase such as “I concatenate the videos”. Options and their order can affect which streams FFmpeg selects and how it writes the output.
Include the playlist type and its contents where practical. For a concat list, share the list lines, preserving quoting and file order. For HLS, share the media playlist around the segment that fails and the corresponding segment names. If the manifest points to private material, redact credentials or sensitive paths without removing the structure needed to diagnose it.
Describe the playback context as well: the Android device or Android version if known, the player app, whether the file is played locally or received over a network, and whether another device reaches the same failure point. A stop in one player is not proof that the file is corrupt; another player may support a different set of containers or contained samples.
Save the first useful error and several lines around it, rather than only the final summary. Look for messages mentioning stream parameters, timestamps, invalid data, missing files, or failed reads, but do not treat any one phrase as conclusive without the surrounding command and input details. If it is an intermittent failure, note whether the stop is at the same boundary on each attempt.
Do not overwrite the original phone files during a test. Make a short working copy or write a separate output file, so you can compare the original metadata with the result and repeat the test if a particular change helps.
Inspect every recording with ffprobe
Use FFmpeg’s companion tool ffprobe to inspect the actual media instead of inferring from the filename. For example:
ffprobe -hide_banner -i phone1.mp4
Run it on each recording that goes into the playlist, including the clip immediately before and after the point where the stream stops. Record the detected container and the number and order of streams. For video, compare codec and profile, dimensions, frame rate and pixel format. For audio, compare codec, sample rate and channel layout. Note duration and any unusual timestamps or warnings too.
The extension does not settle these questions: two .mp4 files do not necessarily contain the same streams or parameters. Conversely, different extensions do not by themselves establish that the files cannot be used together. The metadata tells you what FFmpeg found in the media; the playlist and command tell you how the media is being combined.
If the command maps only video, audio differences may not explain the failure. If it expects audio and one file has no audio stream, or a different channel layout, that is a concrete mismatch worth addressing. Keep track of stream ordering as well: 0:v:0 selects the first video stream of the first input, while 0:a:0 selects its first audio stream. Do not assume every input has both.
The FFmpeg FAQ on concatenation distinguishes the concat filter, concat demuxer and concat protocol. That distinction matters: they do different jobs, so there is no universal “concat format” conversion to apply. The FAQ recommends the filter when re-encoding is needed and describes the demuxer as an option when avoiding re-encoding.
Check the container and samples for the workflow
A container is the wrapper that holds streams; the audio and video sample formats are the encoded contents. For HLS, a manifest can look structurally valid while a particular Android player cannot decode the container or one of its contained samples. Android’s Media3 HLS guide explicitly notes that supported HLS playback depends on support for the contained audio and video sample formats as well as the HLS container.
If this is HLS, inspect both the manifest and the referenced segment that fails. Confirm that the URI resolves, the segment exists and is complete, and that the failing segment has the expected media streams. Compare it with a segment that plays. A missing file or inaccessible URI is a path or publishing issue, not evidence that the phone codec needs conversion.
If you generate multiple HLS variants, check the output naming pattern against the FFmpeg formats documentation: its HLS guidance requires %v in the output filename pattern when producing two or more variants. That condition applies only to multi-variant output; it is not a general remedy for a single-variant playlist that stops.
Android’s recording options also vary. The MediaRecorder API reference gives a narrow example: it recommends 3GP when using H.263 video with AMR audio, and warns that MPEG-4 with that combination may confuse some desktop players. This is a conditional warning, not evidence that your phone used those codecs or that the warning explains an Android playback stop.
The MediaRecorder overview also describes MPEG-2 TS support as added in Android 8.0/API 26 and useful for streaming. Again, this does not identify the output format of a recording made by your device or app. Probe the file rather than guessing from the phone brand, filename or Android version.
Choose concat demuxing or re-encoding
If the playlist is an FFmpeg concat list, choose the method after comparing the input streams. Stream-copy concat can avoid re-encoding, but it depends on the files being suitable to concatenate with compatible stream layouts and parameters. If the layout or relevant parameters differ, a copied output may not behave reliably; it is not enough that all clips have the same extension.
The concat demuxer is the stream-copy-oriented choice when the inputs are suitable. A basic list looks like this:
file 'phone1.mp4'
file 'phone2.mp4'
Then a command may take this shape:
ffmpeg -f concat -safe 0 -i list.txt -c copy combined.mp4
Treat this as a pattern, not a guaranteed repair. Confirm that each listed path is correct, that FFmpeg reads the intended streams, and that the output passes the checks in the next section. -safe 0 affects how the concat demuxer accepts paths; it does not make incompatible streams compatible. Only use it when you understand and trust the list entries.
When inputs need normalising, the concat filter is the re-encoding route. The following illustrates a two-input, video-only workflow; adapt dimensions, frame rate, audio handling and output settings to your inspected files rather than pasting it blindly:
ffmpeg -i phone1.mp4 -i phone2.mp4 \
-filter_complex "[0:v:0][1:v:0]concat=n=2:v=1:a=0[v]" \
-map "[v]" -c:v libx264 -pix_fmt yuv420p normalized.mp4
This example deliberately excludes audio. If both recordings include audio and the output needs it, add and map audio inputs using a layout appropriate to the files. If one clip is silent or audio layouts differ, decide how to handle that explicitly before concatenating. Normalising can make inputs more alike, but takes processing time and may alter quality; it does not guarantee that an unrelated path, timestamp or player problem will disappear.
If the command already uses the concat filter, inspect its input labels, stream selections and filter errors rather than switching to the demuxer by habit. If it uses the concat protocol, establish why: FFmpeg’s FAQ distinguishes that file-level method from the demuxer and filter. For a channel that also needs a dependable operating setup, consider whether keeping your computer running is part of the problem; StreamNeo removes that specific burden by running an uploaded video as a YouTube live stream with your computer switched off, but it does not identify or repair a faulty source playlist.
If instead you mean a YouTube playlist of uploads, neither concat method changes the playlist’s membership or playback order. Verify the affected upload and the playlist entry in YouTube, then investigate any live-stream ingest issue separately. A useful background distinction is the difference between video formats such as MKV and MP4, but the file extension alone still cannot diagnose the stopped playback.
Test the result before sending it live
Write a test output to a new filename and inspect it with ffprobe again. Confirm that it contains the intended streams, that the stream properties match the target workflow, and that its duration is plausible for the inputs. Read the FFmpeg log from the beginning of processing and check for warnings or errors around the boundary, not just whether the process returned an output file.
Play across the exact former stop point in the Android player that matters to you. Also try another player if available, and note whether the result changes. If the output is HLS, test the manifest and the specific segment boundary rather than checking only that the first segment begins. If it is for YouTube Live, do a controlled private or unlisted test according to your channel’s current options, and verify the stream and playback before relying on it for an unattended run.
Avoid changing several things at once. If you change the container, re-encode audio, alter frame rate and rewrite the playlist in one pass, a successful test will not tell you which change mattered. Make one evidence-based adjustment, save the new command and log, then retest the same boundary. If it still stops, return to the source files and compare their metadata with the failure point.
For an always-on channel, a local conversion is only one part of the operational check. A successful short playback test cannot establish that a long broadcast will never stop. If the remaining concern is the machine or connection staying on overnight, compare VPS and cloud streaming approaches for a lecture channel; that is an operating choice, separate from diagnosing the media format.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does an Android recording always need converting before concat?
No. Inspect the actual streams first. If the inputs are suitable for the concat demuxer and stream copy, re-encoding may be unnecessary; if their layouts or parameters differ in a relevant way, the concat filter with normalisation may be appropriate. The stop alone does not tell you which case applies.
Is MP4 the cause if the playlist stops at a clip boundary?
Not by itself. The .mp4 extension does not establish that two files have matching streams, but it also does not prove that the container caused the stop. Compare ffprobe output, the exact command and the first relevant FFmpeg or player log before choosing a format change.
What should I send when asking for help?
Send the playlist type and text or manifest excerpt, the full FFmpeg command, logs around the failure, and ffprobe output for adjacent clips. Include the Android player and version if known, and say whether another player reaches the same point. Redact private paths or credentials while preserving the file order and command structure.
Can I use a YouTube playlist as an FFmpeg concat list?
No. A YouTube playlist groups uploads; an FFmpeg concat list is a local text input describing files to combine, while HLS uses a manifest and media segments. Identify which one you have before applying concat commands or changing a recording’s format.