I am trying to figure out how to use libav to receive streaming mp4 that contains moov atom at the end of a file. I found that, libav has problems decoding such files from https://d.tube. To identify this problem, I have used AtomicParsley to see the position of moovatom. Furthermore, I have tested with qt-faststart. The problematic files processed with qt-faststart have no problem with libav at all.
I also looked into how browsers handle this kind of file as mentioned in how HTML5 video handle video with moov atom at the end. I tried download the first and the last chunk of a file to check first before streaming, but avformat_open_input() cannot open only the last chunk of the file. I think it needs some information from other atoms as well.
So, I would like to ask if anyone knows that libav can somehow handle this problem.
Related
I discovered some damaged AVI files that VLC complains about broken index when I try to play them. I can play directly without ability to scroll the timeline or wait...wait... for the index to be built (but not saved) and play normally. Some other players can play them without complaining, others refuse to play.
I can solve the problem seamlessly in VirtualDub by opening the .avi with "extended options" in Open with "re-derive keyframe flags" and then saving a new .AVI file with
direct-stream-copy for video and audio. The resulting file plays perfectly.
I can also solve the problem with ffmpeg but not without problems.
ffmpeg -i INFILE -vcodec copy -acodec copy OUTFILE
Important: only stream copy and same container are of interest.
The resulting file plays in VLC without complaints or the next problem, but in many other players when jumping on the timeline the video gets distorted immediately at the jump destination and stays heavily distorted until the next I frame in the stream. All this doesn't happen when it was processed with VirtualDub.
ffmpeg is faster but most importantly it is scriptable and one could make automation for many files. With VirtualDub one has to manually process each file and wait a looooooong time for the open process to re-derive keyframe flags first. Wouldn't mind if ffmpeg speed was lost because of the automation it can provide.
So far I only found a very old unanswered mailing list post here
Can ffmpeg fix such files, without the afore mentioned problem? If yes, how?
Thank you.
AVI file indexes contain all frames (key or not), but they have a flags field (which FFmpeg fills in) which should help players seek only to keyframes. I don't have access to your exact file (ffprobe information would be helpful), but we can assume the flags field is not written correctly, e.g. it might be set for every frame or for none at all.
VLC likely parses the codec packets to derive the keyframe flag if absent in the container, but other players might not. I think what you're looking for is to derive keyframe flags while stream-copying. The exact commandline depends a bit on the codec. For example, for H264 you'd want to dump to annex-B as intermediate file format, and then re-read that so the H264 parser is invoked, which sets the keyframe flag, and then re-mux that into AVI - but H264 in AVI is rare so that's probably not what's happening here.
So for a solution, I will need the output of ffprobe $file so I know what codec the AVI file contains.
I have a video in fragmented form which is an output of an Azure Media Services Live Event (Smooth Streaming).
I'm trying to concatenate the segments to get a single MP4 file, however I've run into a A/V sync problem - no matter what I do (time-shifting/speeding up/slowing down/using FFmpeg filters), the audio delay is always floating. To get the output MP4 file, I tried concatenating the segments for video and audio streams (both at OS file level and with FFmpeg) and then muxing with FFmpeg.
I've tried everything I found on the web and I'm always ending up with exactly the same result. What's important, when I play the source from the manifest file, it's all good. That made me skim through the manifest once again, and I realized there's CodecPrivateData value which I'm not using anywhere in the process. What is it? Could it somehow help solving my problem?
Mystery solved: the manifest file contains the list of stream discontinuities, which need to be taken into account when concatenating the streams.
I'm developing a system using ffmpeg to store some ip camera videos.
i'm using the segmentation command for store each 5 minutes a video for camera.
I have a wpf view where i can search historycal videos by dates. In this case i use the ffmpeg command concat to generate a video with the desire duration.
All this work excelent, my question is: it's possible concatenate the current file of the segmentation? i need for example, make a serch from the X date to the current time, but the last file is not generated yet by the ffmpeg. when i concatenate the files, the last one is not showing because is not finish the segment.
I hope someone can give me some guidance on what I can do.
Some video formats can always be playable during the build process. That is, you can make a copy of the unfinished segmentation directly and use it to merge.
I suggest you use flv or ts format to do this. mp4 is not supported. Also note that there is a delay from encoding to actually writing to the disk.
I'm not sure if direct copy will cause some data problems at the end of the segmentation file, but ffmpeg will ignore this part of the data during the merge process, so the merged video should be fine.
Now I used C language and ffmpeg realize a multiplex real-time audio and video to MP4 files of the program and everything works fine, but when in the process of reuse of sudden power failure, the recording is MP4 file is damaged, VLC can not play this file.
I think reason is no call to write the trailer function av_write_trailer , causing index and time stamp information lost, I use araxis merge tool compared the successful call av_write_trailer function of file and a no av_write_trailer to call the damaged files and found two different points:
1. Damaged files in the file header box number value not right
2. The damaged file no end of file.
Now I want to repair after power on my program can automatically repair the damaged files, in Google did not find effective methods.
my train of thought is in the normal recording process saves per second a damaged file is missing two information: box number and end of file, save it to a local file, when writing the MP4 file integrity delete this file after, if power off damaged, then in the next power, read the file and the corresponding information to write the damaged files corresponding position to. But now the problem is that I don't know how to save the number of box and the end of the file, I this is feasible? If possible, what should I do? Looking forward to your reply!
The main cause of MP4 file damage is due to header or trailer not written properly on the file , then , whole file become a junk data. Thus none of the media player able to play the broken mp4 file.
So,
First , broken file has to be repaired before playing the file.
there are some applications and tricks available to repair and get the data back
links are given below :
http://grauonline.de/cms2/?page_id=5 (Windows / Mac)(paid :( )
https://github.com/ponchio/untrunc (Linux based OS)(ofcourse,free!!!)
Second, Manually repairing the corrupt file using HEX editor.
Logic behind this hack :
This hack requires a broken mp4 file and good video file where both videos are captured from the same camera .Also its size should be larger than the broken mp4 file.
Open both video file in any HEX editor. Copy trailer part from good video file to broken video file and save it!Done!!
Note : Always have a backup of video file.
follow these links for detailed informations :
http://janit.iki.fi/repair-corrupted-mp4-video/
https://www.lfs.net/forum/thread/45156-Repair-a-corrupt-mp4-file%3F
http://hackaday.com/2015/04/02/manual-data-recovery-with-a-hex-editor/
http://www.hexview.org/hex-repair-corrupt-file.html
Third, Even tough MP4 file has many advantages , this kind of error is unpredictable and difficult to handle it.
Thus , Using format such as MPG and AV_CODEC_ID_MPEG1VIDEO/AV_CODEC_ID_MPEG2VIDEO (FFMPEG) may help to avoid this kind of error. The mentioned MPG format does not require any header/trailer.if there is any sudden power failure MPG file can play the file whatever frames are stored so far.
Note : there are other formats and codec also available with this kind of properties.
So, here I have a demo file from my website
http://members.shaw.ca/darolynk/breakup/html5game/snd_music.ogg
I am running off of Firefox Beta 30.0 and this issue does not persist in Google Chrome. In Firefox, when I play the file back, the length is displayed at around twice of its actual length as 32:13 when it is only 12:52 in length. Even worse, the audio stutters, playing one second of noise, one second of silence. This issue is not persistent in Chrome nor Opera. It is not a streaming issue (the song is streamed by the time it is played back in fact).
I am wondering if this is an issue with the codec or with Firefox's intrepretation of the codec, but more importantly, I want to know how to fix it. Some information about the file: the file is in OGG Vorbis format, 44100 Hz, 32 kbps Mono (yes, I am running out of storage space). It was encoded with SUPER, which in turn uses FFMpeg and MEncoder as necessary.
This does not apply to all files of this format, making the issue even stranger. Are OGG Vorbis files over a certain length not allowed or interpreted differently by Firefox? This must be the case for someone else and not just me...
Any help is appreciated, thanks in advance!
The problem has nothing to do with Firefox, it's an issue with your file. Also, I've reproduced the issue in VLC... that'd a bad sign as VLC can usually play any corrupt file you throw at it but I wouldn't be surprised if Firefox used the same libvorbis or whatever for the codec.
Some observations:
What we have here is sort of a codec issue. However, the audio being played back is listenable, sort of, meaning it's likely just an issue with some flags.
The sample rate is correct as all the pitches sound correct.
The gaps in the audio are at regular intervals, so it isn't likely you have a plainly corrupt file.
The time on/off in audio is exactly the same length.
Your file is in mono.
It seems to me like the decoder is looking for stereo interleaved channels, but your file is in mono so it cannot decode the bitstream properly. VLC tells me the audio is in mono, but if I remember correctly, Ogg and Vorbis can disagree which might be happening here.
I would recommend simply using FFmpeg to do the encoding. If you still have the problem, at least then we know what version of FFmpeg you have and what the command line was.