I recorded a video with my mobile which had the format ".mp4". Now if I load that video in HTML5 video tag, I get an error HTTP "Content-Type" of "video/3gpp" is not supported. Why does Firefox consider the file as 3gpp although it is an mp4 file?
If I log the file properties when it is loaded on to browser, I see the following
{ name: "test.mp4", lastModified: 1434536249000, lastModifiedDate: Date 2015-06-17T10:17:29.000Z, size: 41151959, type: "video/mp4" }
This means firefox identifies the type as mp4 only. But doesn't play it giving the error HTTP "Content-Type" of "video/3gpp" is not supported.
Try converting the mp4 to a mp4 with another codec. I recommend xMediaRecode. If the converted file is working, it must have something to do with your mobile.
Related
MediaRecorder.isTypeSupported() returns true for 'video/webm', 'video/webm;codecs=avc1', and 'video/webm;codecs=vp9'.
However, only mimeType='video/webm;codecs=vp9' results in a valid webm file ('video/webm;codecs=vp9,opus').
Setting mimeType to either 'video/webm' and 'video/webm;codecs=avc1' results in 'video/x-matroska;codecs=avc1,opus' file, which is not a valid webm video.
Is this a MediaRecorder bug, Chrome bug or am I missing something?\
Software: Chrome 85, MacOS 10.15. I have not tried this on Windows or Linux.
Reproduction:
const wantMimeType = 'video/webm;codecs=h264,opus';
if (MediaRecorder.isTypeSupported(wantMimeType)) {
let mediaRecorder = new MediaRecorder(stream, {
mimeType: wantMimeType,
});
// ...drive the recorder
mediaRecorder.onstop = (event) => {
try {
// returns 'video/x-matroska;codecs=avc1,opus' in Chrome,
// and the binary file content also says Matroska instead of WebM
let mimetype = mediaRecorder.mimeType;
if (!mimeType.startsWith('video/webm')) {
throw new Error(`We requested "${wantMimeType},
but the browser gave us "${mediaRecorder.mimeType}"`);
}
let blob = new Blob(chunks, { type: mimeType });
// ...convert to data: URL
// ...play it in <video src="data:..."> // won't work, if Matroska
} catch (ex) {
alert(ex);
}
};
}
Observations:
Chrome responds true to isTypeSupported('video/webm;codecs=h264,opus'), but Chrome actually does not support this combination, i.e. the response is factually incorrect and defeats the entire purpose of isTypeSupported().
Chrome ignores the mimetype that we pass in the MediaRecorder constructor, and instead returns video/x-matroska;codecs=avc1,opus. Which then doesn't work, because <video> won't play the Matroska mimetype.
2 solutions:
Hacky: After recording, just change the mimetype back to video/webm;codecs=h264,opus. The file content will still say "Matroska", but <video> on Chrome will play it. It's a bad solution, because we're passing in the wrong mimetype, it doesn't match the content. Other software - or Chrome in later versions - might break over it.
Proper: Don't use H.264, but VP9 or VP8. Chrome supports both, and Firefox supports VP8, and they work properly. As a bonus, they are open, while H.264 is riddled with software patents. Depending on the hardware encoder implementation, VP8/9 also may give better image quality results.
However, only mimeType='video/webm;codecs=vp9' results in a valid webm file.
Is this a MediaRecorder bug, Chrome bug or am I missing something?
WebM is the correct a/v media container for the VP8 and VP9 video codecs.
AVC1 video codec belongs into an MPEG container (.mp4, .m4v).
This video codec can also be contained inside an MKV media file (Matroska .mkv).
I am making a desktop application based on Electron + Vue. I need to play a video inside my application. The video source is always located locally, i.e. on the user's computer. And everything was great until I found out that HTML5 <video> tag does not support all video formats. After studying the theory, I learned that I can create a stream using a local video as a source and streaming it to a local address and than I can use this address as video tag's source. Before that, I had no experience with video decoding or streams. But I already did a preview using the fluent-ffmpeg framework which can also stream. I managed to split the video into chunks in .ts format and get outputed a .m3u8 file (this process is faster than I expected) which I can connect to the video tag's source. as I found out later, this requires a player with support for the HLS stream. I used video.js with plugin "videojs-contrib-hlsjs" but got the error "videojs-contrib-hlsjs.min.js? 8852: 1 Error loading media: File could not be played". And now I'm stuck again. I don't know if this will work at all. maybe there is another way to play the unsupported video formats in browser? in the future, I would like to not only play the video, but also add time stamps to the track, perhaps somehow manage the video, that's why it is so important for me to play the video in the browser. I think even if I can stream into video.js player that's not give me support for formats like .avi .mkv .flv and others.
<video controls>
<source :src="local\path\outputfile.m3u8" type="application/x-mpegURL">
</video>
ffmpeg(local\path\to\video.mp4)
.audioBitrate(96)
.outputOptions([
'-codec: copy',
'-hls_time 10',
'-hls_playlist_type vod',
'-hls_base_url http://localhost:8080/',
`-hls_segment_filename \local\path\%03d.ts`
])
.output(`\local\path\outputfile.m3u8`)
.on('progress', function(progress) {
console.log('Processing: ' + progress.percent + '% done')
})
.on('end', function(err, stdout, stderr) {
console.log('Finished processing!' /*, err, stdout, stderr*/)
})
.run()
My extension creates 2 anchor links to download 2 files from a server. An mp4 video file and an m4a audio file.
The server has changed the Content-Type in the header of the m4a audio file from "audio/m4a" to "audio/mp4"
When you click on the download link for the m4a audio file, it saves it as ".mp4" because of the new Content-type "audio/mp4"
I've tried playing around with the "download" and "type" attributes of the links but chrome ignores them and only follows the Content-type.
How can I get the m4a file to download as .m4a instead of .mp4 because it causes confusion with the mp4 video file.
Can an ajax call initiating the download help specify the mime-type? or is this one of chrome's security measures that wont allow you to save the file as different than the specified content-type?
You can specify the explicit filename in the header:
$file="test.m4a";
header('Content-Disposition: inline;filename="'.$file.'"');
That works for me.
I am in a situation where I have my flv video converted to mp4 and then I am streaming this as http url using my nginx server. For multibitrate supoport on html5 I have created a m3u8 file like this :
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200111, RESOLUTION=512x288
http://streamer.abc.com:8080/videos/arvind1.mp4
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3000444, RESOLUTION=400x300
http://streamer.abc.com:8080/videos/arvind1.mp4
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=400777, RESOLUTION=400x300
http://streamer.abc.com:8080/videos/arvind1.mp4
#EXT-X-ENDLIST
But jwplayer is not playing this saying playlist not loaded. Specifically "No playable sources found". Please help.
No, HLS only supports segmented transport streams in an m3u8 playlist. You may find it to works in some players, but it is not part of the standard, and will not work in iOS.
It works with me as:
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1
http://streamer.abc.com:8080/videos/arvind1.mp4
#EXT-X-ENDLIST
I need to play .m4a files (recorded on iPhone) in IE(9+) and Safari (iPad, iPhone). I am facing problem with setting correct MIME Type. For playing in IE10 I need to set audio/mp4 but for Safari audio/aac.
With audio/mp4 I am getting Cannot play audio file on iPad.
With audio/aac I am getting Error: Unsupported audio type or invalid file path in IE
Is there a type I can set for both?
<audio controls="controls" autoplay="autoplay">
<source src="play.aspx?filename=sound.m4a" type="audio/mp4" />
</audio>
Notes
Using an alternative player is not a solution for me.
I serve the files thorough .aspx page so I can control HTTP headers.
From observing the page HTML 5 Audio Across All Browsers using m4a, oga, mp3 and Flash it seems that possible solution is to give type="audio/mp4" and NO conten-type header. However removing HTTP header in aspx is rather too complex for problem I am trying to solve(see Removing/Hiding/Disabling excessive HTTP response headers in Azure/IIS7 without UrlScan).
Audio is still in working draft, so browser experience will vary.
Having said that, the mime type that's most prevalent is audio/x-m4a. Some sites show audio/m4a-latm as a valid mime type for m4a audio but as of this writing, even Chrome doesn't recognize that mime type.
You can try this snippet in different browsers to see if it works - I verified it in IE11, Chrome (v37) and IE9 (emulated via Dev Tools).
Audio Tag sample
I've also found (personal observation) that audio recorded on iPhone doesn't play most of the time on web. Almost all browsers say the file is invalid and if you download the recorded file, it doesn't even play in media players (e.g Windows Media Player). I suspect iOS core audio is to blame here but haven't found anything conclusive yet. Audio recorded from Android works fine though.
At this point, having a flash fallback seems like the best option (won't help on iHateFlash devices though).