Splitter - Problematic files

[GoogleCodeExporter]

Please get 3 files from:
http://65.23.154.147:8080/Exchange/

The .f4v files are two files that come with an installation of Adobe Flash 
Media Server. In both of these files your splitter assigns incorrect audio 
sample rate (twice more than the correct value)
and also assigns incorrect timestamps for media samples.

The .mp4 file has an audio-video synch problem. Haali splitter plays this file 
OK (apart from the issue that it detects incorrent total time), but your 
splitter ends up with 3-4 seconds sync. problems.

On a side note, if your video decoder is registered in the system, GraphEdit 
crashes when you expand a "DirectShow filters" category node.

Thanks a lot for looking into these issues.

Original issue reported on code.google.com by mersht...@gmail.com on 23 Feb 2012 at 4:51

[GoogleCodeExporter]

Hi there,

I tested your files, and the two f4v files seem to play fine.
The splitter identifys them as 48000Hz and the audio decoder agrees. It also 
sounds OK, not too fast. Since the audio is only music its also impossible to 
detect any A/V sync issues, so what makes you think there are incorrect 
timestamps? Seems to play perfectly smooth.

The MP4 throws alot of warnings about some invalid timestamps, which could 
explain the A/V sync issues. I'll try to look into it.

Original comment by h.lepp...@gmail.com on 23 Feb 2012 at 5:26

• Changed state: Accepted
• Added labels: Component-ffmpeg, Filter-Splitter, Usability

[GoogleCodeExporter]

Hi,

1. The two .f4v files play OK with DirectShow, that is correct. However, your 
splitter still detects incorrect sample rate - one of the files is 44100, and 
another id 48000. Haali splitter assigns 22050 and 24000 respectively.
What makes me think Haali is correct? The thing is, I am streaming these files 
to Flash player, and RTMP is very sensitive to sample rate - if you set it 
incorrectly, the music plays broken. With 22050 and 24000 music plays great by 
Flash player, but still video plays bad in the file 1.f4v - that makes me think 
the timestamps are also bad. I think DirectShow doesn't care about audio sample 
rate, and audio timestamps as long as decoder can live with it.

2.Can you please shed some light on these incorrect timestamps in mp4 file?

Original comment by mersht...@gmail.com on 23 Feb 2012 at 6:16

[GoogleCodeExporter]

The f4v files are HE-AAC, which means they use Spectral Band Replication (SBR). 
If decoded by a "stupid" decoder, they are 24000Hz, if decoded with a decoder 
that supports SBR, they are 48000Hz. Hence, both values are correct. A decoder 
really shouldn't need this information anyway, because its contained in the 
bitstream.

This is working as intended.

Regarding the MP4 file, the STTS Atom seems to be screwed up, but i haven't 
looked in detail yet.

Original comment by h.lepp...@gmail.com on 23 Feb 2012 at 6:23

[GoogleCodeExporter]

Well, first of all, one of the files is 44100, another one is 48000.
We really need them as 22050 and 24000, for "stupid" decoder. (Flash)
How can I tell HE-AAC from LE-AAC drom DirectShow Media Type, so that we can 
adjust that on our side?

For mp4 file, Haali plays it with perfect sync, despite these problems. How can 
you explain it?

Original comment by mersht...@gmail.com on 23 Feb 2012 at 6:35

[GoogleCodeExporter]

48000 or 44100 doesn't matter, the fact remains that both the full sample rate 
and the "half" sample rate are valid, and the result depends on the decoder 
used.
Sadly, I can't make everyone happy - but it'll keep it display the "full" 
sample rate (anything else would probably be quite complicated).

You can probably parse the Audio Specific Config in the Media Type, which 
contains the Object Type and the Sample Rate of the Low Complexity part, which 
should give you the "half" sample rates.

Original comment by h.lepp...@gmail.com on 23 Feb 2012 at 6:47

[GoogleCodeExporter]

Yes, agreed and understood with .f4v files.

Would like to get your analysis on mp4 file.

Original comment by mersht...@gmail.com on 23 Feb 2012 at 6:51

[GoogleCodeExporter]

Hi,

Please get the file "audio.asf" from the same location.

When it is playing in GraphEdit using your splitter, and you do a Seek, 
everything hangs. With Microsoft splitter it seeks OK.

Original comment by mersht...@gmail.com on 24 Feb 2012 at 10:28

[GoogleCodeExporter]

I do not recommend using LAV for ASF/WMV splitting, its just too unreliable. 
Its also off by default when you install it. Stick with the MS Splitter.

Original comment by h.lepp...@gmail.com on 24 Feb 2012 at 10:41

[GoogleCodeExporter]

Hi,

Should we expect any updates on the .mp4 file?

Original comment by mersht...@gmail.com on 27 Feb 2012 at 6:34

[GoogleCodeExporter]

The MP4 file should be fixed in the next version. At least it seems to play 
fine for me.

Original comment by h.lepp...@gmail.com on 9 Mar 2012 at 9:50

• Changed state: Fixed

[GoogleCodeExporter]

Great! Looking forward to get the next version, it's not on your site yet...
Can you drop couple of words - what was the problem?

Original comment by mersht...@gmail.com on 10 Mar 2012 at 2:18

[GoogleCodeExporter]

The entries in the CTTS atom were invalid. Just dropping them seemed to fix the 
problem.

Original comment by h.lepp...@gmail.com on 10 Mar 2012 at 1:47

[GoogleCodeExporter]

Hi,

Nope, the issue is not fixed with your latest binary.
Downloaded the zip today, the date on LAVSplitter.ax is March 10.
But same problem is there when playing this .mp4 file in GraphEdit (Windows 7 
64 bit)
Note that when playing in Windows Media Player, or in GraphEdit with Haali, on 
the same system, this file plays with perfect synch.

Are you sure this fix made it to the release :) ?

Original comment by mersht...@gmail.com on 10 Mar 2012 at 3:46

[GoogleCodeExporter]

Hi Hendrik,

Thank you for your great work on LAV splitter which is very useful for our 
development. We have just sent you a donation. 

Your filter is already a handy tool for us; however, we really need the fix on 
the .mp4 files, because our software records these files (from live streaming 
sources) and we need to be able to play them via the DirectShow.

Since Windows Media Player and Haali play these files OK, the fix should be 
doable.
We will send you another donation when you finally fix it!

Original comment by mersht...@gmail.com on 12 Mar 2012 at 8:27

[GoogleCodeExporter]

Thanks for the generous donation.
Try this version, i tried something else and on the first glance it seemed to 
improve:

http://files.1f0.de/lavf/LAVFilters-0.49-mp4fix.zip

Original comment by h.lepp...@gmail.com on 12 Mar 2012 at 9:15

• Changed state: Started

[GoogleCodeExporter]

The synch is good now! At least on this particular .mp4 file.
However, file duration reports some enormous value in seconds (millions), 
whereas the duration is 3 min 56 sec. Same problem exist in Haali splitter. 
Windows Media Player shows correct duration. Also, audio and video bitrate are 
reported incorrectly.

Original comment by mersht...@gmail.com on 12 Mar 2012 at 9:36

[GoogleCodeExporter]

The duration reported when playing the file is 3:57 for me, where do you get 
your number from?

The Bitrate is reported as 601 kbps for video and 128 kbps for audio. Such 
values are really mostly cosmetical and i don't know how its determining this 
exactly, however they do match what MediaInfo says about the file.

Original comment by h.lepp...@gmail.com on 13 Mar 2012 at 10:52

[GoogleCodeExporter]

Ooops...looks like Haali took over and the numbers I have seen were from Haali 
splitter. Yes, the problem seems to be fixed. Tested number of files, all good.
Is this fix generic enough, does it affect other files (non-mp4), is it safe to 
put it into your main version, or this is a special version for our "ugly" mp4 
files?
Do you prefer to split regular mp4 movies without this fix or with it?

In any case, we need a source code for this fix to make final conclusion if the 
problem is fixed.

Original comment by mersht...@gmail.com on 13 Mar 2012 at 2:30

[GoogleCodeExporter]

The fix is generic, i'll push it into the main version later today.

For the record, your files violate the MP4 spec.
They have negative values in the STTS atoms, which according to the spec is not 
valid.
The code used to enforce positive values, and i just changed it to allow 
negative values as well.

Original comment by h.lepp...@gmail.com on 13 Mar 2012 at 2:37

• Changed state: Fixed

[GoogleCodeExporter]

Unfortunately, that's what MP4v2 library produces; we use it to create mp4 
files.
It has this bug, but yet that's the best library we could find for creating mp4 
files from network streams.

Original comment by mersht...@gmail.com on 13 Mar 2012 at 3:22

[GoogleCodeExporter]

The fix is now in the main code, and will be available in future releases. 
(technically, the fix was in my modified version of ffmpeg, not LAV itself)

Original comment by h.lepp...@gmail.com on 13 Mar 2012 at 4:05

[GoogleCodeExporter]

Can you please tell me what exact source file was changed for this fix, what 
function?

Original comment by mersht...@gmail.com on 13 Mar 2012 at 7:19

[GoogleCodeExporter]

Never mind, I have found it.
mov.c

Thanks!

Original comment by mersht...@gmail.com on 13 Mar 2012 at 7:33

[GoogleCodeExporter]

Just some info to correct what I said before:
MP4v2 library is not guilty, it is our code that sometimes sends negative frame 
durations to it. However, the fix you made is still correct and valuable for 
us, since lots of our users still use our existing programs that produce these 
files.
So they will be able at least to play these files correctly.
We will try to fix our side, of course, so that it will not produce negative 
timestamps.

Original comment by mersht...@gmail.com on 14 Mar 2012 at 4:52

[GoogleCodeExporter]

Hello,

The splitter leaks; after splitting a single file, about 300-400 bytes leak; it 
happens on any file. There are 10-12 small blocks of memory that are not 
getting deallocated. One of them is Format block in Videoinfoheader structure. 
Please take a look. 

Thanks,
Maxim

Original comment by mersht...@gmail.com on 28 Mar 2012 at 1:44