Encoding fails if no cache-initial is used (in some cases)

[olifre]

mpv version and platform

git master as of 2017-09-24
combined with youtube-dl from 2017.09.15

Reproduction steps

Run:

mpv -profile enc-to-nok-n900 http://www.ardmediathek.de/tv/dings-vom-dach/dings-vom-dach-ganze-Sendung/hr-fernsehen/Video\?bcastId\=14847140\&documentId\=41161108  -o 2017-03-05.mpg

I explicitly renamed by ~/.mpv/config and encoding-profiles.conf.

This fails (see "actual behaviour" below), while running:

mpv -profile enc-to-nok-n900 http://www.ardmediathek.de/tv/dings-vom-dach/dings-vom-dach-ganze-Sendung/hr-fernsehen/Video\?bcastId\=14847140\&documentId\=41161108  -o 2017-03-05.mpg --cache-initial=2000

i.e. just adding --cache-initial=2000, makes things work.

Expected behavior

Things work.

Actual behavior

Playing: http://www.ardmediathek.de/tv/dings-vom-dach/dings-vom-dach-ganze-Sendung/hr-fernsehen/Video?bcastId=14847140&documentId=41161108
Can not open external file http://www.ardmediathek.de/subtitle/140626.
 (+) Video --vid=1 (*) (h264 960x540 25.000fps)
 (+) Audio --aid=1 --alang=deu (*) (aac 2ch 48000Hz)
Opening video filter: [lavfi graph=scale=floor(min(min(800\,dar*480)\,in_w*max(1\,sar))/2+0.5)*2:floor(min(min(800/dar\,480)\,in_h*max(1/sar\,1))/2+0.5)*2,setsar=sar=1]
VO: [lavc] 800x450 yuv420p
[encode-lavc] option --ofps not specified and fps could not be inferred, using guess of 24000/1
[encode-lavc] Opening video encoder: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [libx264]
[ffmpeg] libx264: MB rate (34800000) > level limit (40500)
[encode-lavc] no audio stream succeeded - invalid codec?
[encode-lavc] vo-lavc: encoded 0 bytes
[encode-lavc] ao-lavc: encoded 0 bytes
[vo/lavc] NOTE: skipped initial video frame (probably because audio is not there yet)


Exiting... (Quit)

Log file

Failing log file:
http://sprunge.us/jheD

With cache, things work:
http://sprunge.us/XNRT

Sample files

I think the URL I used is publicly accessible for free (at least it is in Germany, not sure if they have geoblocking).

[olifre]

I digged slightly deeper.
This is not reproducible on a low-latency DSL connection.
On my home connection (no fastpath, "only" 25 MBit/s) it fails almost each time if cache is not used, but sometimes, rarely, it magically works.

I guess the reason is some limit to the stream analyze duration / probesize.
However, whatever I set for the demuxer-lavf- parameters in my config file, I do not see any effect.

Also, setting e.g. cache-initial=2000 in the config file appears to be non-effective when encoding, it only has an effect if specified on the commandline. Is this a bug, or a feature?

That really seems strange - this shouldn't affect encoding mode at all. Is it a regression of some sort? Maybe the recently added partial reading for AVIO broke something.

[olifre]

Mhhhm... downgrading to 9f0e358 (which is the commit right before usage of avio_partial in 449d972 ) does not help the problem, i.e. it seems unrelated.
I did not try to encode directly from those more high-res stream ever, I think, so it could well be this problem always existed.

The interesting thing is that, in non-verbose mode, I get if things fail:

Playing: http://www.ardmediathek.de/tv/dings-vom-dach/dings-vom-dach-ganze-Sendung/hr-fernsehen/Video?bcastId=14847140&documentId=42828068
 (+) Video --vid=1 (*) (h264 960x540 25.000fps)
 (+) Audio --aid=1 --alang=deu (*) (aac 2ch 48000Hz)
Opening video filter: [lavfi graph=scale=floor(min(min(720\,dar*576)\,in_w*max(1\,sar))/2+0.5)*2:floor(min(min(720/dar\,576)\,in_h*max(1/sar\,1))/2+0.5)*2,setsar=sar=1]
VO: [lavc] 720x406 yuv420p
[encode-lavc] option --ofps not specified and fps could not be inferred, using guess of 24000/1
[encode-lavc] Opening video encoder: MPEG-2 video [mpeg2video]
[encode-lavc] no audio stream succeeded - invalid codec?
[encode-lavc] vo-lavc: encoded 0 bytes
[encode-lavc] ao-lavc: encoded 0 bytes

If things work:

Cache fill:  1.33% (2048000 bytes)   
 (+) Video --vid=1 (*) (h264 960x540 25.000fps)
 (+) Audio --aid=1 --alang=deu (*) (aac 2ch 48000Hz)
Opening video filter: [lavfi graph=scale=floor(min(min(720\,dar*576)\,in_w*max(1\,sar))/2+0.5)*2:floor(min(min(720/dar\,576)\,in_h*max(1/sar\,1))/2+0.5)*2,setsar=sar=1]
[encode-lavc] option --ofps not specified and fps could not be inferred, using guess of 24000/1
[encode-lavc] Opening audio encoder: MP2 (MPEG audio layer 2) [mp2]
AO: [lavc] 48000Hz stereo 2ch s16
VO: [lavc] 720x406 yuv420p
[encode-lavc] Opening video encoder: MPEG-2 video [mpeg2video]
[encode-lavc] Opening output file: 2017-05-14.mpg
[encode-lavc] Opening muxer: MPEG-1 Systems / MPEG program stream [mpeg]

I.e. the detection problem appears to happen for the audio channel.
However, even in the failing case, I still get (verbose):

[ad] Opening audio decoder aac
[ad] Requesting 1 threads for decoding.
[ad] Selected audio codec: aac (AAC (Advanced Audio Coding))

so it seems the detection is fine, but the encoder somehow is unhappy...?

[olifre]

And another piece of information: If I download the single mp4 file (which youtube-dl extracts), and try to encode that, it always works. It really appears to be some kind of "giving up too early" thing.

I can reproduce it. I suspect another player/audio.c data flow issue (terrible code).

[olifre]

I can reproduce it.

Perfect, thanks for looking into it! Best of luck in hunting it down - the code indeed looks a bit messy to follow.

Not looking into it yet, there's no time for that.

[olifre]

Not looking into it yet, there's no time for that.

No problem, just leave the issue open - it's not critical at all for me, and in any case, specifying cache-initial is an easy enough workaround.

Any idea though why specifying cache-initial=2000 in mpv.conf is ignored when using an encoding profile (and only passing --cache-initial=2000 on the commandline works)? Is this a bug or a feature?

[mia-0]

On 2017 M09 28, Thu 00:23:38 CEST olifre wrote: Any idea though why specifying `cache-initial=2000` in `mpv.conf` is ignored when using an encoding profile (and only passing `--cache-initial=2000` on the commandline works)? Is this a bug or a feature?

Ignoring the *playback* config in encoding mode is a feature. You can make a base encoding profile and inherit that setting by using profile=whatever in your encoding target profiles.

[olifre]

Ignoring the playback config in encoding mode is a feature. You can make a base encoding profile and inherit that setting by using profile=whatever in your encoding target profiles.

Many thanks, that's a reasonable thing, and the described trick works perfectly fine. Thanks! 👍

By the way, in my experiments I also found that specifying --no-cache-pause when encoding, one triggers an AV-desync message once cache runs empty - likely also some dataflow issue.

Looking at this again, it seems like without encoding everything is fine. Encoding seems to expect a specific order of events (maybe?) which is not necessarily guaranteed (apparently). There is no real data flow issue, just different behavior.

I think the specific part it dislikes is that it can happen that the first video frame is drawn before audio is initialized. This can happen because the player tries to prepare both outputs during startup, and drawing the first video frame can be part of that, even if playback doesn't start properly. When the first video frame is "drawn" but the audio part is not yet initialized (ao_lavc not created), the encoding code seems to error out. If I comment the audio failure in encode_lavc_start, it actually works.

I'm not sure what to do about this. Leaving it to @divVerent.

[divVerent]

This is indeed very tricky - we need all streams to be initialized before we can write any data. I'll have to think about this later - at least for now we have a workaround (the cache). On Sep 28, 2017 20:44, "V. Lang" <notifications@github.com> wrote: Looking at this again, it seems like without encoding everything is fine. Encoding seems to expect a specific order of events (maybe?) which is not necessarily guaranteed (apparently). There is no real data flow issue, just different behavior. I *think* the specific part it dislikes is that it can happen that the first video frame is drawn before audio is initialized. This can happen because the player tries to prepare both outputs during startup, and drawing the first video frame can be part of that, even if playback doesn't start properly. When the first video frame is "drawn" but the audio part is not yet initialized (ao_lavc not created), the encoding code seems to error out. If I comment the audio failure in encode_lavc_start, it actually works. I'm not sure what to do about this. Leaving it to @divVerent <https://github.com/divverent>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4917 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPWsMxzfPBfrE_2UvDZbV1UlqaOgTdcks5snD1fgaJpZM4PhvY4> .