VideoHelp Forum
+ Reply to Thread
Results 1 to 25 of 25
Thread
  1. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    I have been capturing FLVs using Replay Media Catcher (RMC), and I have found that some videos end up having crazy long running times (hundreds of hours) which is not indicative of the actual amount of video captured.

    I know the reason for this is that the time codes for the frames are not consistent, there are randomly large jumps in time were the video freezes until the timer catches up with more data in the file.
    RMC has an option called Fix FLV, which makes the total duration more realistic and allows it to play without freezing, however it also messes up the audio, causing it to somewhat stutter. I believe this is because the audio and video packets in the file must be played simultaneously, but the fix FLV option just auto-increments each packet by a fixed amount.
    Ideally I would like a tool which can just detect these gaps (eg. larger than 1 second) and reduce the timecode values from that point on to close the gaps, but leave the rest as-is.

    I have attempted a couple of things which haven't produced the desired results:
    - Splitting the audio and video, auto-incrementing them individually to have matching durations then re-muxing them - results in continuous audio, but out of sync because there are sections of audio without video and vice-versa due to dropped packets.
    - Auto-Incrementing the whole file, splitting out the audio, re-auto-incrementing the original and split audio to have matching durations, splitting out the video and combining with the previously split audio. This seemed to get me a bit closer, but still not very good syncing as most files have an audio gap at the start (the video packets are at least spaced out better).

    I have looked at some injectors, but they only seem to inject general metadata, and just extract timecodes, not inject the timecodes which is what I need.

    I need to do this in relative bulk, so the process can't be too labour intensive like manual editing of each file, and I'd like to try and avoid re-encoding.

    I'd appreciate any help or ideas you guys can provide, I've been trying to figure this out for a while and I think I'm stuck now.
    Thanks
    Quote Quote  
  2. I'm a MEGA Super Moderator Baldrick's Avatar
    Join Date: Aug 2000
    Location: Sweden
    Search Comp PM
    What happens if you just remux the flv? Like with ffmpeg, from command line run ffmpeg -i video.flv -vcodec copy -acodec copy new.flv

    But I doubt it works....and I don't think you will find any easy method to batch fix this at all.
    Quote Quote  
  3. I would try to extract the time codes using FLVExtract, try adjusting the time codes and them mux the output to mkv or mp4.
    If you know how to do what you want manually, there probably is a way to do it automatically,...
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  4. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Originally Posted by Selur View Post
    I would try to extract the time codes using FLVExtract, try adjusting the time codes and them mux the output to mkv or mp4.
    If you know how to do what you want manually, there probably is a way to do it automatically,...
    I have downloaded FLVExtract, YAMDI and FLVMDI and extracted the timecodes to a txt or xml file, but I didn't understand how you're supposed to mix them back in. The GUI for FLVMDI had no 'XML input' field, and when I tried specifying an input, output and xml with YAMDI it just ended up the same as the input.

    I can make an Excel Spreadsheet to correct the timecodes the way I want (I did it already when I was attempting it before), I just need help restoring them to the file. I couldn't find any tutorials for that and the 'help' screens on the command line tools didn't explain it clearly if at all.

    I would appreciate it if you could guide me with how to do this.

    Thanks for the replies
    Quote Quote  
  5. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    If the original FLV is in sync, you won't be able to "fix" it by editing timecodes only. You would have to edit the timecodes AND cut audio correspondingly
    Quote Quote  
  6. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    My understanding was that audio and video packets had timecodes so reducing large gaps in timecodes might alleviate the problem.

    I have just tried using the timecode txt from FLVextract with mkvtoolnix and the original file, but I only get the video track listed, not audio. The codec is Nellymoser, which I realise is a bit crappy, and not widely supported. Does anyone know if mkvtoolnix supports muxing this codec?
    Quote Quote  
  7. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    nellymoser isn't supported in MKV container (at least not by official specs), it's a proprietary format

    The timecodes that you extract are v1 or v2 timecodes for video. The audio isn't affected by these timecodes - it's treated as a continuous recording. The timecodes tell the player to speed up or slow down in sections, aka "VFR" or variable frame rate. Thus the FPS drops or rises in sections according to those timecodes. eg. A large gap in activity might be represented by a single frame and very low fractional FPS. If you mess with those timecodes, you have to do the equivalent manipulation to the audio, or it will be out of sync (assuming the original FLV was in sync to begin with)
    Quote Quote  
  8. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    OK, so yes, the original is in sync. I have seen the timecodes for both audio and video in RMC so I know it is specified for each packet. I have also successfully edited these values using RMC as I described in my first post. My issue is that it's uniform and doesn't allow me to change it the way I need to.

    I have used FFMPEG to re-encode the flv to mp3, which has worked and is still in sync (lots of yellow/fuschia messages while encoding, presumably because of gaps) and mkvtoolnix now recognises it. My issue now is that the timecode file I specify is for video or audio, not both. If what you say is correct, and I can only correct the timestamps for the video, what are my options with the audio (please don't say cut it manually, as there is no way I can get it in sync easily after)

    I don't understand why there's not a tool that works the way RMC does, except allowing more control over how the values are changed via timecode import/export or a formulaic rule.

    When I split the audio and video with FLV Editor Lite, I could use the Fix FLV option in RMC to edit timecodes for both of them just as I could before with the whole file. The file durations changed to reflect the new timecode interval, so it seems like it should be possible to set timecodes for flv audio, just maybe not using mkv?
    Quote Quote  
  9. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    What I'm saying is correct for V1, V2 style timecodes. Those are the types of timecodes you "extract" with FLVExtract and other tools. Those are the types of timecodes used in mkvmerge/mkvtoolnix. You can read section 18 on "external timecode files" in the mkvmerge documentation . I have never seen audio timecodes being used with mkvmerge. If it works for you , please make a followup post


    EDIT:
    But it looks like V3 can deal with audio timecodes , because it gives an example of audio only file. But I have no idea how to mix that with video. Maybe use V1 for the video, V3 for the audio ? or V3 for both ?

    18.3. Timecode file format v3

    In this format each line contains a duration in seconds followed by an optional number of frames per second. Both can be floating point numbers. If the number of frames per second is not present the default one is used. For audio you should let the codec calculate the frame timecodes itself. For that you should be using 0.0 as the number of frames per second. You can also create gaps in the stream by using the 'gap' keyword followed by the duration of the gap. Example for an audio file:

    # timecode format v3
    assume 0.0
    25.325
    7.530,38.236
    gap, 10.050
    2.000,38.236
    Last edited by poisondeathray; 28th Jul 2014 at 19:45.
    Quote Quote  
  10. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Do you have one of these problematic FLV's you can upload somewhere ? You can upload files directly to this site <500MB
    Quote Quote  
  11. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    No, I'm afraid it's not really something I can share.

    The only other thing I could think of was finding a programming API that can interpret the file and allow me to edit the values. I couldn't find anything myself, but I'm not sure exactly what to search for. Most things I came up with were just for playback. Even just some documentation on the file structure would allow me to write something to do what I need if I can get hold of it. It just surprises me that there is nothing which can do it already.
    Quote Quote  
  12. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    So is your problem just the gaps ? The sections of idle activity or drop outs where nothing happens ?

    Or is the running time (hundreds of hours) actually correct when you include the gaps? If you play file from beginning to end, does it actually run hundreds of hours ?

    If the total running time indicated is just wrong, but file is otherwise fine, that suggests an issue with the header

    What about random seeking in the FLV ? any problems ?

    Have you tried other players or the remuxing trick ?





    Can you post mediainfo report (view=>text) of one of the problem FLV's ? copy & paste

    When you re-encode using ffmpeg, it copies the timecodes over, that's why it's still in sync . Now if you demux the re-encoded mp3, what is the duration ? and in relationship to what mediainfo said about the duration ,and the actual file duration ?

    The mkvmerge docs imply you can use audio & video timecodes (not just v3), although I 've never ever seen audio timecodes being used


    A frame in this case is the unit that mkvmerge(1) creates separately per Matroska(tm) block. For video this is exactly one frame, for audio this is one packet of the specific audio type. E.g. for AC3 this would be a packet containing 1536 samples.
    Quote Quote  
  13. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    No, the files aren't hundreds of hours long. the biggest ones are a couple of hours. the playback just freezes for a few seconds and then the seek bar jumps (quite a lot) to the timecode for the video packet being read. If there is just audio (dropped video packets) the video freezes until it finds another video packet and the audio continues, which is acceptable. It's just where the reported timecode is wildly inaccurate that I want to correct it, I guess it's not an issue with live playback in the browser as it just plays it as it receives it.

    When seeking, it freezes but usually recovers with normal playback when there is a gap, when playing on fast forward or attempting to jump forward or backward (particularly backward) VLC will just completely lock up for a while (sometimes a long while). As with jumping, seeking by selecting points on the timeline occasionally has a delay, but usually it will manage to jump to the next nearest frame and continue.

    I have been estimating the actual running time based on looking at the usual interval of the demuxed audio in RMC, then using that value with 'Fix FLV' which gives me a constant audio stream without stuttering or gaps and a reasonable sounding running time.

    It sounds like I just need an application which can manage exporting audio timecodes.

    One thing I tried which seemed odd was exporting the video, calculating the number of packets (frames?) by applying a uniform interval and dividing the total duration by it, I then compared this to the number of timecodes in the txt file from FLV extract, and there were about half as many packets/frames as entries in the timecode file.

    Is there an explanation for this? I don't think it can be audio as there's generally more of those than video packets so it should be much less than half.

    I will attempt your other suggestions when I'm back from work, thanks.
    Quote Quote  
  14. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Ok, so I extracted the audio, video and timecodes after I converted the audio to MP3 with ffmpeg. The mp3 corrected its length to about an hour, which is close to what I was getting when I set the timecodes with RMC. So, I doctored the timecodes to remove large gaps and have an approximate total matching the length of the MP3 and then muxed them together with mkvtoolnix.

    The good news is it muxed ok and it plays, but the bad news is it's all out of sync, which doesn't surprise me. Oddly the duration of the final MKV was double what it should have been and cuts out half way through.

    I feel like a solution that works will require not separating the two files, as the order of the packets in the original file are the key to making it sync up.

    Here's the media info output for the file I'm testing on (the converted mp3 version):
    Code:
    General
    Format                                   : Flash Video
    File size                                : 276 MiB
    Duration                                 : 194h 42mn
    Overall bit rate                         : 3 306 bps
    Writing application                      : Lavf55.18.100
    liveXML                                  : <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
    
    Video
    Format                                   : Sorenson Spark
    Codec ID                                 : 2
    Duration                                 : 194h 42mn
    Width                                    : 320 pixels
    Height                                   : 240 pixels
    Display aspect ratio                     : 4:3
    Frame rate mode                          : Constant
    Frame rate                               : 1 000.000 fps
    Bit depth                                : 8 bits
    
    Audio
    Format                                   : MPEG Audio
    Format version                           : Version 2
    Format profile                           : Layer 3
    Codec ID                                 : 2
    Codec ID/Hint                            : MP3
    Duration                                 : 194h 42mn
    Bit rate mode                            : Constant
    Bit rate                                 : 32.0 Kbps
    Channel(s)                               : 1 channel
    Sampling rate                            : 22.05 KHz
    Compression mode                         : Lossy
    Delay relative to video                  : 182ms
    Stream size                              : 2.61 GiB
    Writing library                          : LAMEUUU’Pð\
    Last edited by Nintynuts; 29th Jul 2014 at 17:50.
    Quote Quote  
  15. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Good News Everyone!


    I have figured out how to get it working!

    I have also made two batch scripts to help automate the process (there's still manual steps). Here goes:
    1st script
    1 - Separate audio into separate FLV with FFMPEG
    Manual
    2 - Using Replay Media Catcher, identify the MODE interval between audio packets and apply it across both FLVs (original and audio)
    2nd script
    3 - Export timecodes with FLV Extract (the interval can be assumed from the first frame)
    4 - Adjust timecodes using t=t-n*i (t=timecode, i=interval, n=frame number)
    5 - MKVmerge the new timecodes with the original video
    6 - Using FFMPEG, mux the new video with the separate audio file (convert to MP3 for compatibility)
    Done!

    Extract Audio.bat
    Code:
    ffmpeg.exe -i %1 -vcodec copy -acodec copy -map 0:1 "%~n1 - audio.flv"
    Convert.bat
    Code:
    @echo off
    Setlocal EnableDelayedExpansion 
    call flvextractcl.exe -t -o %1
    set _n=0
    set _b=0
    set output=
    set LF=^
    
    
    for /F "usebackq tokens=*" %%A in ("%~n1.txt") do (
    	set _v=%%A
    	if !_n! equ 1 (
    		set /a "_i=!_v!"
    	)
    	if !_n! gtr 0 (
    		set /a "_v=!_v!-(!_n!*!_i!)"
    	)
    	set output=!output!!_v!!LF!
    	if !_b! gtr 1000 (
    		echo !output!>> "%~n1 FIXED.txt"
    		set output=
    		set /a "_b=0"
    	)
    	set /a "_b+=1"
    	set /a "_n+=1"
    )
    echo !output!>> "%~n1 FIXED.txt"
    del /q "%~n1.txt"
    @echo on
    call mkvmerge.exe -o "%~n1.mkv" --timecodes 0:"%~n1 FIXED.txt" %1
    del /q "%~n1 FIXED.txt"
    call ffmpeg.exe -i "%~n1 - audio.flv" -i "%~n1.mkv" -vcodec copy -acodec mp3 -map 0:1 -map 1:0 "%~n1 - FIXED.flv"
    del /q "%~n1.mkv"
    You can drag a file onto or call the batch scripts to run them. EXEs for mentioned apps must be in same folder as batch file.

    Thanks for the inspiration, please let me know if you have any further ideas for improvement!
    Quote Quote  
  16. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Congrats on figuring it out.

    Can you explain in more detail what is involved with the manual step? Identifying the MODE interval ? Not everyone has Replay Media Capture
    Quote Quote  
  17. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Congrats on figuring it out.

    Can you explain in more detail what is involved with the manual step? Identifying the MODE interval ? Not everyone has Replay Media Capture
    MODE means the most common occurrence of a number in a sequence. So for example I have found most (possibly all) nellymoser audio tracks have a MODE interval of 46ms. I don't know of any other software (except for clones) that would allow you to see the timecodes for the first 100 packets and 'fix' them like Replay Media Catcher. The other thing I have found after doing a couple of them, is that RMC doesn't always do it properly first time, and sometimes the UI doesn't update so it's hard to tell if it's worked.

    I have encountered another issue however. Like I said, I am getting familiar with the properties of nellymoser, however I haven't been bothering to re-encode to MP3 because it works fine with VLC. The other half of my videos are Speex, and that doesn't work with VLC (possibly a header issue). I have tried converting to MP3 at the end of my process like I said, and while it starts out almost in sync, is slowly drifts.

    I was going to try adjusting the interval afterwards, which is essentially stabbing in the dark, but I think it's the conversion that messes up the sync. The Speex packets are ~20ms apart and FFMPEG reports 16000 Hz, but it won't convert it into MP3 without specifying 44100, 22050 or 11025 Hz. After conversion the packets are ~26ms apart, but at least they did have the same duration (although this was coupled with video, which I suspect might cause clipping if the audio overran). I was going to try converting the audio to MP3 before muxing and see if that helps, but I have no other ideas.
    Quote Quote  
  18. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    LOL - You mean "mode" as in mean, median , mode. I thought it was something with specific reference to RMC.

    So it sounds to me like you're forcing CFR for both audio & video with timecodes, because the ms interval will be constant between all entries



    16000Hz is an uncommon sampling rate, I'm wondering if it's misreading. Did you try updating vlc or ffmpeg ? ffplay can play speex as well

    Instead of converting to MP3, temporarily use uncompressed audio to elminate if it's a confounding factor
    Quote Quote  
  19. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Originally Posted by poisondeathray View Post
    So it sounds to me like you're forcing CFR for both audio & video with timecodes, because the ms interval will be constant between all entries
    The audio ends up with CFR, but because the video frames retain the however many audio packets separating them, the video is VFR, but still multiples of the inverval used for the audio. The timecode editing I do basically makes sure a video packet is in time with the preceding audio packet rather than between them, and therefore the audio is continuous. I actually lose a couple video frames at the start where there's no audio. I could probably find a way of keeping them and offsetting the audio, but I can't be bothered for less than a second of video.

    Originally Posted by poisondeathray View Post
    16000Hz is an uncommon sampling rate, I'm wondering if it's misreading. Did you try updating vlc or ffmpeg ? ffplay can play speex as well
    I already discovered ffplay and confirmed the syncing is ok in the original file. It's no good for general use though. VLC is fairly up to date and it does have a Speex codec, but as I said, I think it might be the header being invalid. I googled it and found a ticket saying Speex support had been fixed (assuming default values with missing header) in VLC about 3 months ago, and i'm sure my version is newer than that. I will try updating anyway.

    Originally Posted by poisondeathray View Post
    Instead of converting to MP3, temporarily use uncompressed audio to elminate if it's a confounding factor
    I will give this a try. What do I use in FFMPEG "-acodec raw" or "-acodec uncompressed"?

    Would it be useful if I posted a media info output for a Speex file?
    Quote Quote  
  20. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Originally Posted by Nintynuts View Post

    Originally Posted by poisondeathray View Post
    Instead of converting to MP3, temporarily use uncompressed audio to elminate if it's a confounding factor
    I will give this a try. What do I use in FFMPEG "-acodec raw" or "-acodec uncompressed"?
    "-acodec pcm_s16le" for 16bit little endian .

    If you leave out -ar (audio sampling rate) and -ac (audio channels) switches , it should be copied from the source characteristics

    Would it be useful if I posted a media info output for a Speex file?
    Probably not, it will just say what mediainfo thinks the sampling rate, channel configuration and bit depth are. If it doesn't say 16Khz similar to VLC, then post what it says
    Quote Quote  
  21. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Originally Posted by poisondeathray View Post
    "-acodec pcm_s16le" for 16bit little endian .

    If you leave out -ar (audio sampling rate) and -ac (audio channels) switches , it should be copied from the source characteristics
    I tried this, the audio still didn't play in VLC. I also updated VLC, which made no difference.

    Originally Posted by poisondeathray View Post
    If it doesn't say 16Khz similar to VLC, then post what it says
    Media Info reported 44.1KHz, not 16KHz, so don't know what's going on there. (Also it was ffmpeg that said 16KHz, not VLC)

    I was trying to separate out the Speex audio by itself to an audio file (without a video container) so I could convert it and see if it the duration changed, but when I tried to do it I only got errors. I thought it needed to be OGG format. What command would you use to do this? I used something like:
    Code:
    ffmpeg.exe -i %1 -acodec copy "%~n1.ogg"
    Quote Quote  
  22. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Originally Posted by Nintynuts View Post
    Originally Posted by poisondeathray View Post
    "-acodec pcm_s16le" for 16bit little endian .

    If you leave out -ar (audio sampling rate) and -ac (audio channels) switches , it should be copied from the source characteristics
    I tried this, the audio still didn't play in VLC. I also updated VLC, which made no difference.
    What about ffplay ?

    How about audio only ? Was it a problem with decoding audio in the first place, or problem with playing it in FLV container ?

    ffmpeg -i input.flv -vn -c:a pcm_s16le output.wav


    Originally Posted by poisondeathray View Post
    If it doesn't say 16Khz similar to VLC, then post what it says
    Media Info reported 44.1KHz, not 16KHz, so don't know what's going on there. (Also it was ffmpeg that said 16KHz, not VLC)
    That is weird. And you can't post a small sample from this other batch somewhere ?


    I was trying to separate out the Speex audio by itself to an audio file (without a video container) so I could convert it and see if it the duration changed, but when I tried to do it I only got errors. I thought it needed to be OGG format. What command would you use to do this? I used something like:
    Code:
    ffmpeg.exe -i %1 -acodec copy "%~n1.ogg"

    What was the error message?

    Just try one at time first. This works on speex/flv samples, but ogg is a container format. I don't know what "raw" or native speex samples are supposed to have for an extension

    Code:
    ffmpeg -i input.flv -vn -c:v copy output.ogg
    Quote Quote  
  23. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Originally Posted by poisondeathray View Post
    What about ffplay ?
    How about audio only ? Was it a problem with decoding audio in the first place, or problem with playing it in FLV container ?
    ffmpeg -i input.flv -vn -c:a pcm_s16le output.wav
    I'm not sure what we're achieving using this format. It doesn't matter whether it plays in ffplay because I'm not using that to play them. It needs to be compatible with VLC.

    Originally Posted by poisondeathray View Post
    That is weird. And you can't post a small sample from this other batch somewhere ?
    Nope, sorry.

    Originally Posted by poisondeathray View Post
    What was the error message?

    Just try one at time first. This works on speex/flv samples, but ogg is a container format. I don't know what "raw" or native speex samples are supposed to have for an extension
    Code:
     ffmpeg -i input.flv -vn -c:v copy output.ogg
    I managed to convert the audio I already separated and used 'Fix FLV' on, but I couldn't do it with the original 'fixed' file. I think the error was a problem with the frame interleaving or something, which kind of makes sense.

    Converting the separated audio to both MP3 (-ar 44100) and OGG (-acodec libspeex) files (not FLV) I found that with the sample I used had a duration of 3:02 ish (when it was converted using my script/the audio was extracted to an FLV) but when I separated them the MP3 was 2:56 ish and the OGG 3:08 ish. So I'm not sure if these differences have any effect on the conversion process or if it's just a product of removing the container.

    I will attempt to convert the MP3 and OGG back into an FLV and 'Fix FLV' to get the same duration, but because the difference is quite small, I am doubtful I will get it synced properly using this method.
    Quote Quote  
  24. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Originally Posted by Nintynuts View Post
    Originally Posted by poisondeathray View Post
    What about ffplay ?
    How about audio only ? Was it a problem with decoding audio in the first place, or problem with playing it in FLV container ?
    ffmpeg -i input.flv -vn -c:a pcm_s16le output.wav
    I'm not sure what we're achieving using this format. It doesn't matter whether it plays in ffplay because I'm not using that to play them. It needs to be compatible with VLC.
    If uncompressed pcm wav cannot play, then something is seriously wrong or corrupted with your VLC. If it works in ffplay , but not vlc, then again, that indicates something is wrong

    You're testing to see if your mp3 conversion had anything to do with the sync issues. Are you introducing some other problems/issues ? Is converting to mp3 (which only supports certain sample rates) introducing other problems on top of the original issues ? If so, there might be another suitable audio format or method

    You might try decoding with the official nellymoser (maybe through a directshow graph) and speex decoders as well (I think libspeex in ffmpeg is the official one)

    Originally Posted by poisondeathray View Post
    What was the error message?

    Just try one at time first. This works on speex/flv samples, but ogg is a container format. I don't know what "raw" or native speex samples are supposed to have for an extension
    Code:
     ffmpeg -i input.flv -vn -c:v copy output.ogg
    I managed to convert the audio I already separated and used 'Fix FLV' on, but I couldn't do it with the original 'fixed' file. I think the error was a problem with the frame interleaving or something, which kind of makes sense.
    BTW There was a typo in that commandline should be -c:a copy, not -c:v copy
    Quote Quote  
  25. Member
    Join Date: Mar 2010
    Location: United Kingdom
    Search Comp PM
    Ok, I've realised that the Speex videos don't actually have the timecode issues like the nellymoser ones did, so all I should need to do is make the audio compatible with VLC.

    If I try what you suggest about exporting the audio only I get this error message:
    Code:
    Could not write header for output file #0 (incorrect codec parameters ?): Error
    number -1 occurred
    however, if I specify the codec as libspeex, it works, and plays in VLC.
    It's worth noting it only worked when contained inside an OGG file, not in a FLV.
    But, converting to MP3 in a FLV container works just fine with the -ar 44100 setting.

    So I tried converting a fresh video but re-encoding to speex, but it gives me the error message:
    Code:
     [flv @ <address>] pts (<negative number>) < dts (42) in stream 0
    av_interleaved_write_frame(): Invalid argument
    So then I tried separating the two and recombining them, then I realised the previous error was still occuring, so the error relates to the processing of the video, not the audio.

    When I look at the timecode output from FLV Extract, there is an odd pattern where every other frame seems to have the same timecode as the previous. could this be why it's breaking?

    Anyway, just before posting this I thought 'well if the original video is the problem, why not try re-encoding it. The videos I had worked on previously were Sorenson Spark h263, so I tried that but it complained about the video dimensions and stuff being incompatible (which seems weird as it obviously works with the other videos). So I tried h264, which turned out to be the original codec anyway, and... it works. MP3 and h264 FTW.

    I would expect re-encoding should take longer than copying streams, so I would like to understand this issue, but at least I'm not stuck any more.
    Quote Quote